If you’re thinking about making the switch to Linux, Jack Wallen is all for it — but only if you approach the migration with your eyes open. He recommends that you evaluate a number of key issues before taking this big step.
They really don’t know when it’s time to quit.
The Department of Justice’s Trustee program, which has finally had enough of SCO’s stalling tactics and failed reorganization attempts, has filed a motion to transition the company to Chapter 7. SCO CEO Darl McBride says that the company will oppose the motion and will present a new reorg plan to the court.
As I already said, there’s a little problem when trying to update your ReadyNAS with software from the “Sarge” repository: There’s almost no copy of that left on the net. However, even if you find one (or use my “Sarge mirror”), there’s a problem with files that were already outdated even while “Sarge” was still maintained. One of these is
, the IMAP client. This poses an interesting problem:
While playing with my old but trusty ReadyNAS NV I found that most if not all official Debian mirrors by now have deleted their archives of “Sarge”. No wonder, since that release is quite dated now. However, the operating system of the ReadyNAS is based on “Sarge” which makes installation of addons almost impossible. Luckily I found some mirrors in Taiwan and Croatia that still had all the files.
The folks from Videolan.org some days ago released a new version of the best video player for the Mac (and other platforms, too): VLC 0.9.9a – where the “a” is a Mac only version. Besides improved RealMedia playback on the Mac, there are several other enhancements and fixes in this version.
Today one of my MySQL servers started to behave really strange: It would process all requests just fine with the exception of one: It wouldn’t allow one of the forums to display any message threads. What it did instead was to hang there until the connection timeout dropped in. Even stranger was the fact that once I used my patched up PHP which has auto-reconnect capabilities the problem went away with the second request. So once the original request timed out and the re-connect kicked in, the result of the query was delivered in no time.
Resolution? Well, I just restartet the whole MySQL server. I suspect this is yet another problem of the 64-bit MySQL servers I’m using. Going to replace them with the 32-bit version step by step now.
Just so I don’t forget it when the next beta cycle for ZenOSS is due:
To successfully have ZenOSS generate graphs on Ubuntu one needs to do
apt-get install libgcj-common
and restart the system afterwards.
When testing out Ubuntu 8.04 “Hardy Heron” today, it was a quite smooth ride except for my network card not being detected correctly. Well, it’s an Intel PCIe Gigabit NIC equipped with the 82572EI chip. This poses two problems: First, the adapter is incorrectly identified as a standard Intel PRO/1000, thus ubuntu picks the wrong driver and uses e1000.ko instead of e1000e.ko.
This can be easily fixed by adding the line “alias eth0 e1000e” to /etc/modprobe.d/aliases. Unfortunately I had to find out that the driver shipped with Hardy’s kernel is a bit dated, so I also had to compile a new kernel driver. Downloaded the sources from Intel’s engineering driver download site at Sourceforge, unpacked and ran “sudo make install”. Afterwards I just had to restart networking and lo and behold, I had network connectivity.
Update: As I had to learn the hard way, the e1000 driver will get loaded on every restart, thereby blocking the e1000e driver from accessing the NIC. To fix this, I had to add the following code to /etc/rc.local:
Uh. Well. Not really ;) But in case you’re using bonded network interfaces with Linux you may have noticed that they’ll always report a network speed of 10Mbps – no matter what NICs you used to create the bond. Technically this isn’t a real problem for the bond will always work at the full speed supported by the hardware. But it can pose a management problem when you’re using SNMP to monitor your devices.That’s because a common monitoring technique is to set limits after reaching which the system will send off an alert. And it’s easy to imagine that an assumed 10Mbps link will reach a saturation point of, say, 75 percent a lot earlier than, say, the 1Gbps interfaces you’re actually using to create to bond.
Now for the bad news: There’s nothing you can do locally to change the speed reported by the bond (or, to be fair, by the various tools used to determine the link speed of any given interface). The good news is that you can do something to have at least your SNMP daemon report the correct link speed. As long as you’re using net-snmp, that is.The first step is to determine the index number of your bond interface(s). This can be easily done using
snmpwalk -v 2c -c <community> -Os 192.168.0.1 interfaces | more
Just replace <community> with the name of your SNMP community (in general, “public” is a good guess) and the 192.168.0.1 with the IP address of the system you’re monitoring. You should get something like this:
ifDescr.1 = STRING: lo
ifDescr.2 = STRING: eth0
ifDescr.3 = STRING: eth1
ifDescr.4 = STRING: eth2
ifDescr.5 = STRING: eth3
ifDescr.6 = STRING: eth4
ifDescr.7 = STRING: eth5
ifDescr.8 = STRING: bond0
ifDescr.9 = STRING: sit0
As you can see, in this example our bond interface is located at ifDescr.8. Write down the number or try to remember it for a few seconds. Now, on the machine where the bond is running, open the file /etc/snmp/snmpd.conf. Somewhere in that file, insert
override ifSpeed.X uinteger 1000000000
Don’t forget to replace the X with the actual number from the snmpwalk output. And make sure not to type ifDescr but ifSpeed instead. This is telling your SNMP daemon to overwrite the netlink speed as reported by the operating system for interface X with 1.000.000.000 – which translates to 1Gbps.
Now all that’s left to do is to restart your SNMP daemon – and possibly to rebuild the device data for this server in your management application. Ah, and there’s one drawback: In case you ever change the bond or add or remove a NIC to/from that server, the order of the interfaces and thus their numbering will change. So you’ll then have to repeat the steps outlined above.
And one final note: In theory, you should be able to achieve the same result using the line “interface bond* 6 1000000000” in your snmpd.conf. This would have the benefit of always changing the value for all interfaces named bond… — however, I couldn’t make this work on any machine I’ve been experimenting with. Ymmv.
A while ago I posted an entry about â€œHow to fix SuSE 10.0 for the Adaptec ATA 2400A RAID controllerâ€. This went quite unnoticed except for one rant from Hannes Reinecke who seemed to be a bit pissed about me writing a blog entry instead of reporting the bug to the OpenSUSE developers. Well, I replied that my experiences with (Open)SuSE weren’t the best when it came to fixing bugs. Since there was no further reply, I left it at that. Now that OpenSUSE 10.1 is available I gave it a spin today.Â Now guess what’s *not* fixed in this release … Most likely Hannes Reinecke still waits for me to officially report the bug before he can do anything about it. See, same procedure as ever at (Open)SuSE. Didn’t I say so?Anyway. In case your I2O controller doesn’t behave with OpenSuSE 10.1, the fix is still the same: Move the directory /lib/modules/<kernel-revision>/kernel/drivers/messages/i2o out of the way by renaming it.