Viraj's Weblog

I've decided to ditch Debian Testing on my home desktop system. Im tired of downloading 200megs of updated packages every time I boot Linux. It was turning out to be very risky, because many times some package would break. I thought it was fun, because I would have the challenge to figure out how to fix it . Tonight I just got fed up. This particular instance resulted in my MySQL database not starting:

Jan 12 22:41:27 localhost mysqld[1607]: 050112 22:41:27 [ERROR] bdb: unable to initialize mutex: Function not implemented
Jan 12 22:41:27 localhost mysqld[1607]: 050112 22:41:27 [ERROR] bdb: process-private: unable to initialize environment lock: Function not implemented

Debian Testing is changing so much it's just not worth it for me. I think Stable is the only one to run, and that is better for servers, not desktops. I'm going to switch to Ubuntu Linux. I've heard good things about it, and it is based on Debian.

I've been testing a few things on Debian that require additional daemons to be started (ldap, apache, samba, exim). I left them on and my bootup was getting kinda slow. So began my quest to understand the Debian initscripts.

Generally they are the same as Red Hat, with /etc/rcN.d/ directories corresponding to the runlevels. Now what I wanted to do was disable the inetd service from starting. On Red Hat, I would do something like:

chkconfig --level 2345 inetd off

How to do it in Debian? After a bit of searching on Google, I came across some recommendations to do:

update-rc.d -f inetd remove

Which actually works, but you lose the original startup order. Let's say inetd used 33 (i.e. S33inetd), the 33 appears not to be stored anywhere. On Red Hat, this was stored in the rc script itself for chkconfig. The only way I could restore this information is re-installing the package, which is kinda lame. Worse, if ever the inetd package is updated, the initscripts would be recreated! This is just retarded and I was beginning to see that update-rc.d should not be used for administration.

I did some more research and it turns out the remove method of update-rc.d is not recommended for what I'm trying to do. In fact, the Debian Security HOWTO cautions against it as well. That text and some users recommend that the /etc/rcN.d/S??service script be removed. Ok I can do that, but how does that remember the startup order? I still have to resort to re-installing the package to get it in the original state.

Ugh, I hate when only half of my question is answered. Yes, Debian truly is an elitist distro.

With how easy it is to install things on Debian, I decided to check out Mediawiki, the wiki used for the large encyclopedia site Wikipedia.

It required PHP 4.1.2 or higher, and MySQL 3.2 or higher. The Debian package notes for libapache2-mod-php4 stated that the package only works with Apache's prefork MPM. I had earlier installed Apache 2 with its threading MPM (apache2-mpm-worker) to play with mod_python. PHP is not thread-safe, so requires the MPM preforking model (apache2-mpm-prefork). I selected that package, expecting some problems 'converting' to the different Apache MPM, but it ran flawlessly. Then selected the libapache2-mod-php4 package, which brought in all the needed requirements. Man, I remember when I had to use Apache Toolbox to get everything working properly. Debian packages are a huge timesaver.

Anyhow, there was no Mediawiki Debian package, so grabbed the tar and went through the install. These days, PHP projects are coming with their own PHP web-based installation. That's nice for installing on webhosting providers that don't give you shell access. Within a few minutes I had Mediawiki running on my system.

It's a very nice wiki, storing most data in the database. I liked how simple it was, and it had a very usable markup toolbar when editing pages. This would help alot for new users. I know that it is scalable from the massive Wikipedia site.

My major gripe with it is how it stores attachments. It seems the only attachments Mediawiki expects are images. This can be changed by allowing different extensions, but why the concentration on images only? More importantly, there is one namespace for all filenames. So you cannot have 2 wiki pages with the files meeting.doc on both of them. The 2nd upload would overwrite the first one. This makes uploading attachments rather unusable in my opinion. Contrasting with Twiki, which stores the attachments in a separate namespace for each wiki page.

Because of the above, I feel Twiki is still the best wiki out there.

As mentioned, I recently installed Debian Testing, aka sarge, on a home PC. It had defaulted to the GNOME desktop, and I had noticed that the volume applet was not working properly. I attributed this to Debian not detecting my soundcard at install, and didn't bother with it as I don't have much need for sound.

I decided this morning to see how difficult it was to get sound working. Doing an lsmod showed an emu10k1 module loaded. It actually did detect my soundcard! But why was the GNOME volume applet not working? It was always going back to zero volume level, and trying to start the mixer resulted in some device not found error. Well is sound actually working?

cat /bin/ls > /dev/audio

Ahh, yes I actually heard the sweet sound of /bin/ls. xmms even works, but rhythmbox, which is the default player for certain files, had a similar complaint about my device not being found.

Now I wanted to find out where my emu10k1 module was configured to load. On Red Hat systems, I would see this in /etc/modules.conf, but I didn't find it in the file on Debian. I searched all of /etc:

grep -ril emu10 /etc

and still came up with nothing. Wtf? Is Debian storing system configuration elsewhere? I decided to forget about that and look into the real problem: GNOME audio apps not working.

After some Googling, I saw some mention on this page that I needed to create a /dev/sound/mixer the same as /dev/mixer. Well that didn't do shit. Maybe it's trying to open something else. I brought out good old strace on the volume app:

strace -o /tmp/blah gnome-volume-control

I looked for any /dev opens or stats, hoping to see it trying to find a missing mixer device. I saw it trying to open /dev/snd/control* and /dev/aload* devices. I remember seeing something about ALSA and these devices. Well I am not using ALSA, and don't really see a need to install it. I just want the volume control working damnit.

About an hour more of searching I finally came across a bug report from someone who went through my pain, almost exactly to the tee. From that bug I saw mention of gstreamer-properties. I have no idea what this is used for, but after running it showed it was configured for ALSA sound output and input. There was no other selection.

The bug mentioned the gstreamer0.8-oss package needing to be installed. Started up Synaptic, installed the package, and gstreamer-properties now has an OSS selection. OSS is the standard Linux sound driver. After selecting that and restarting GNOME, my volume, mixer, and rhythmbox worked fine. strace on the volume app show it correctly opening /dev/mixer and other devices. It turns out the main problem was a result of a bug in the new Debian installer. What a pain!

Lesson learned, Debian still has a ways to go for a usable desktop. I still don't know where my sound module is being loaded from...

Update: Digging around for sound in /etc led me to a /etc/discover.conf. It turns out discover is like kudzu on Red Hat, and does hardware detection. So now I know how my emu10k1 module is being loaded.

I've been pretty much a die hard Red Hat Linux guy, so much that I even have an RHCE, which unfortunately will expire soon. Red Hat has always been a solid distribution on the corporate environment. Nowadays, because of Red Hat's cost, I usually use Whitebox Linux.

I experimented with Debian in the past and loved its package management. I recently installed Debian Testing on my home system. I still do not feel Debian is good for new users. Configuring X is something I had to do manually, and only could have because of past experience. Also, my sound does not work, and I haven't even begun to look into that.

I think Debian is great for servers. I've been learning Python and the book I'm reading has a chapter on mod_python. Well I figure'd I would try out Apache and mod_python on my Debian box. I could not believe how simple this was to install. Synaptic is a great GUI package management tool that is simple and works. So I looked for mod_python, and had a good selection of versions to use. Some work with Apache v1, v2, Python 2.2, 2.3, etc. I just selected the one I wanted, and then since I didn't have Apache, it was selected as a dependency and installed/downloaded flawlessly. What was very cool is when I looked at the /etc/apache2 directory for how the server is configured I saw a very elegant directory structure with the sysadmin in mind. You will have to check it out for yourself to appreciate it. The Debian packages are of very high quality. In all, it took me about 10 minutes.

Doing the above on a Red Hat system ends up with dependency hell, with RPMs not playing well with each other. I am constantly impressed with how well Debian packages the software, and I think I have found a new distribution for servers I setup. For workstations however, there is some ways to go for proper auto-detection of hardware.