Well, it seems to be getting a “trend” for me, to integrate stuff into our Active Directory. Now that I know why, and how easy that is, I expect to add more stuff. The good thing about the integration is, that you only need to maintain a single source for authorization. The bad thing about that is, that stuff becomes dependent on the Active Directory (we do have four domain controllers, so that should be fine). ...
Recently I got the task, to implement unixODBC/freetds on one (well, it’s really three) of our web servers, as someone wanted to use Microsoft SQL Server 2005 with PHP (without using the MSSQL functions, which PHP provides soo nicely; don’t ask me why). With that I also got a set of " instructions" on how to install freetds from source (remember, I was a Gentoo dev, so I know my way around, when it comes to building from source), as well as a small set of instructions on how to create the connection. ...
Okay, so I ended up toying with subversion via WebDAV on SLES today (I know, I know .. it’s bloody Sunday). It wasn’t much of a hassle though, after reading this. Sure, I made a few errors at first (simply confused the logic behind " Location" and " Directory"), but after that plain subversion commits via WebDAV (thus utilizing Apache) worked fine. For POC or as a hint to myself, here’s where and what I needed to add/change: ...
Remember, I talked about building RPM’s on SLES10SP2 on ppc64 ? Well, turns out I was rather stupid .. and it was rather simple (don’t ask me why I didn’t think of that). I tried asking solar, I used Google (apparently with the wrong search parameters), nothing though. Not a clue. Today it bugged me again, so I used Google again. This time with " ppc64 suse rpmbuild", and guess what I saw within the preview of the second hit .. ...
As I was building the updated RPMs for SLES10, though needed to refresh my old patch. Also, I was getting strange messages from autotools and fixed these quirks, Now, I prepped a patch for it, and finished building new RPMs for i586 and x86_64.
Well, to begin with we had this really weird problem that the thin clients as well as the terminal server would only load user based group policy if you are a member of the group of local administrators. While that’s ok for the thin clients (users can’t actually change something unless they log in as “Administrator” - don’t ask me why), it’s a real no-no on the terminal server. ...
OK, so about an hour (yeah, yeah; I know .. I shouldn’t be working at that time, but it really gave me sleepless nights) ago, I finally figured out why the hell both my Windows XP Embedded thin clients as well as my Windows Server 2003 systems where showing this real weird behaviour when applying group policies, or more precise the user based configuration of a group policy. ...
One of my co-worker approached me today with a weird problem. Yesterday he had a disk in a 900GiB array failing which he replaced. After that, he run a rebuild/verification, fsck’ed the file system and tried to mount the volume again. Apparently the mount produced a kernel oops (guess what, the 900GiB is running reiserfs), thus leaving the kernel tainted (or what do they call it ?). So he tried to reboot the box but it didn’t reboot. It started rebooting but then hung (as in not continuing the reboot). He tried to ssh back to the box, and it worked just fine. ...
Here I am, preparing our environment for the first (of hopefully many) tester for our upcoming VTL project. So I ended up installing the ISC and Administration Center for Tivoli Storage Manager on a 64bit guest (that is SLES10 for AMD64), just because I forgot to include support for later versions with our current running one. Guess what, na- na na na na. Exactly, didn’t work, the same errors I got while trying it before in a virtual environment. “Portlet is not available.” ...
If you’re using a 2.6 based distribution, the FC HBA (or more correctly the corresponding driver) should create entries in /sys/class/scsi_host. Now you only need to get the host-number (basically the # of the host bus adapter) and you can get started .. Simply doing this, is going to tell the FC HBA “rescan” and discover new devices .. 1 echo "1" > /sys/class/fc_host/host/issue_lip That should do the trick, and you should be able to get udev to recognize the new devices attached via FibreChannel without the need to reboot the whole box (which might be a bit tricky).