CentOS 5.3 Released

For those who might not be familiar with enterprise linux distributions, CentOS is a rebranded free version of Red Hat Enterprise Linux (RHEL). For enterprise usage Red Hat supports each release for 7 years, while carefully updating packages for backwards compatibility. Each .1 “point release” is an Service Pack update. RHEL 5.3 was released at the end of January.

Typically it takes a few weeks for the CentOS team to repackage, build and distribute the source of RHEL into a CentOS release. Last night CentOS 5.3 release was announced. The seemingly long delay was due primarily to some personal issues within the CentOS team.

I have been running a personal server on CentOS for 1 year now and I could not be more pleased with the results. I plan to update my server tonight when I am at the console. The following are some tips I’ve read online for a smooth (and fast) upgrade:

# yum update glibc

The glibc update is due to a RHEL 5.3 known issue.

After that, I would generally do the following. This basically updates the YUM installation system first to take advantage of any improvements in a newer YUM release. :

# yum update yum rpm
# yum clean all
# yum -y update

Even though past updates have been flawless for me, please do make proper backups, and read the Release Notes for more information.

Wikipedia Migrates from Fedora to Ubuntu

The admins running Wikipedia are almost complete in migrating their servers from a mix of RedHat and Fedora to Ubuntu. The primary reasons behind the switch, according to Brion Vibber (Wikimedia CTO), were personal preference, Ubuntu availability on the desktop and better support/stability compared to Fedora. As a server, one might think that an enterprise option like RHEL or CentOS might make for a better choice, however both of these lack the appeal of Ubuntu and the flexibility in support.

Regardless of the reasons for the switch, this is another opportunity for people to question Fedora’s fast moving development pace (i.e. “bleeding edge”). Fedora user know that Fedora requires constant updating/upgrading and Fedora developers are obviously quite accustomed this and welcome it. An interesting thread on the Fedora development mailing list raised this topic and spawned a great deal of discussion. Some users/developers think that if Fedora provided a LTS stable release then perhaps situations like Wikipedia’s could have been avoided. Jesse Keating, Fedora Release Engineer, chimed in with a very well worded point:

Given the amount of churn we allow maintainers to introduce into our
“stable” releases, I highly doubt Fedora would be suitable for any
situation where a “LTS” was desired. There is just too much major
version upgrading
, behavioral changes, massive amounts of updates,
rapidly invalid documentation, and high chance of regression in the
“stable” updates. We should address *that* problem before ever thinking
about extending the life.

Even if Fedora could address that problem, big organizations most likely won’t change their opinions. However if those issues could be addressed, many users probably wouldn’t be migrating away, and more importantly they would just have a much better operating system!

(As a personal point, I no longer use Fedora as a server. I recommend CentOS.)

MPlayer compile on RedHat 8.0

I have a 4yr old Athlon-XP machine which I use as a Media Center/Home Theater PC. It is running RedHat 8.0 (heavily modified) with a Hauppauge PVR-250, MPlayer and some simple/buggy front end. Seeing as I designed it at the end of 2003, quite a bit of software is out of date.

The most critical componets are the ivtv driver that runs the PVR-250 and MPlayer. I won’t update the ivtv because I built it for a 2.4.24 kernel and I had to write my own recording application and my own scheduler daemon for recording TV. So as with all interdependent software – its easy to break something.

My MPlayer has been giving a great deal of trouble recently. It is running version 1.0pre5 which I beleive was released in 2004(?). Some of the MPEG2 recordings from the PVR-250 have some issues during playback. I’m hoping the problem will go away with an updated MPlayer, although I know I will get improvement with ivtv, but I can’t afford to do that.

The last “released” version of MPlayer was 1.0RC2. There are no available packages for RedHat 8, so I used my MPlayer compile guide. Since MPlayer only recently supported a GTK2 gui I chose to use a GTK1 gui since that’s what I had in Redhat 8. Virtually everything else was properly autodetected. So my configure step looked like this (quite simple):

[root@proteus MPlayer-1.0rc2]# ./configure --enable-gui \
	--enable-largefiles \
	--enable-gtk1

Unfortunately the make step (the compiling) broke with this error:

In file included from /usr/include/netdb.h:28,
                 from network.h:16,
                 from stream.h:65,
                 from stream_dvd.c:32:
/usr/include/netinet/in.h:259: parse error before '(' token
/usr/include/netinet/in.h:259: parse error before "__u32"
/usr/include/netinet/in.h:260: parse error before '(' token
/usr/include/netinet/in.h:260: parse error before "__u16"
/usr/include/netinet/in.h:262: parse error before '(' token
/usr/include/netinet/in.h:262: parse error before "__u32"
/usr/include/netinet/in.h:264: parse error before '(' token
/usr/include/netinet/in.h:264: parse error before "__u16"
stream_dvd.c: In function `dvd_parse_chapter_range':
stream_dvd.c:168: warning: passing arg 2 of `strtol' from incompatible pointer type
make[1]: *** [stream_dvd.o] Error 1
make[1]: Leaving directory `/root/dvr/mm/mplayer/MPlayer-1.0rc2/stream'
make: *** [stream/stream.a] Error 2

I hunted through the mplayer-users mailing list and found out that this is a problem with a Redhat being very old and basically no longer support. Someone suggested doing the following.
Edit /usr/include/netinet/in.h and at line 259, add following:

//mjm - to compile for MPlayerRC2
#undef ntohl
#undef ntohs
#undef htonl
#undef htons
//mjm

Then I was able to rerun the make. Then I reverted the file back to its original.

Some other things: I did also update to the latest release of XviD. I’m pretty sure that the ancient version of Xine is probably broken as well, but since I only used that to play DVD’s, I’d much rather use my Samsung DVD Player.

I know that RedHat 8 is forever out of date, so I’m updating the system to CentOS, but that’s been quite troublesome, more on that later.

Daylight Savings Time Change RedHat 8.0

In the past I’ve never actually changed my time settings on my computer, usually when booting into Linux the NTP (Network Time Protocol) server does the trick. However the local operating system (whether Linux or Windows) usually retains timezone settings in some way. I do not know if the RedHat/Fedora method is consistent with other Linux distributions. My personal desktop is running Fedora, Ubuntu, Windows 2000 and XP – all rather modern software with updates, so I wasn’t the least bit worried. However I seem to have forgotten my PVR (Personal Video Recorder) computer.

In 2004 I built a home theater type PC to play and record digital media (DivX, MP4, MPEG2, MP3, etc.) and set it up with my television and my amplifier. I had made the original draft of the idea in 2003, and even though RedHat 9.0 was available I had built my design on RedHat 8.0. So essentially I forgot about the DST change, until today, when I found out some TV shows were all 1 hour off.

I really did not do any form of investigation on how to fix this. My first thought was that I needed to update the NTP rpm and that would fix it. So I foolishly uninstalled the previous RPM and pulled a RHEL (Red Hat Enterprise Linux) source rpm and installed it. That’s when it occurred to me it had nothing to do with NTP. I knew that NTP uses UTC (Universal Time Coordinates), but I wasn’t thinking. So a quick look on the web tells me that timezone data in RedHat is directly handled by glibc. How nice, one of the core parts of the operating system. I wasn’t in the mood to do that much updating. So I followed the instructions provided here. Basically all I needed to do was replace the timezone data filestzdata and restart the NTP daemon.

Worked for me.
Good thing I’m not a server administrator.

Mar 17, 2007: Looks like Jason had the same issue on his Myth box. :-)