Several quick notes on this:

1) PAM is a piece of @&&#!!#!!: try the following if your Solaris machine is under LDAP:

bash-3.00# grep -i ^ftp /etc/pam.conf
ftp auth sufficient pam_nldap.so.1 debug
ftp auth requisite pam_authtok_get.so.1
ftp auth required pam_dhkeys.so.1
ftp auth required pam_unix_cred.so.1
ftp auth required pam_unix_auth.so.1 try_first_pass
ftp auth required pam_dial_auth.so.1
ftp account sufficient pam_nldap.so.1 debug
ftp session sufficient pam_nldap.so.1 debug
ftp password sufficient pam_nldap.so.1 debug

2) Man pages are good. The in.ftpd manpage of Solaris is good. Read it.

3) There must be an /etc/shells file present on your machine. Otherwise, everything else fails. Make an /etc/shells file like this one:

bash-3.00# cat /etc/shells
/usr/local/bin/bash
/usr/bin/csh
/usr/bin/bash
/usr/bin/ksh
/usr/bin/sh
/usr/bin/tcsh
/usr/bin/zsh

I knew all of this, but it still took me two days to figure it out. I'll blame the lack of sleep and too long workdays.

This being said, I am not sure anyone read this, so I have been considering moving all sysadmin entries on this journal to a wiki (probably oddmuse) hosted on my personal site. I have also noticed that Googling this Journal yields 0 answers, while I get a lot more hits on my personal site. Since I am trying to advertise myself as a sysadmin, I'd like to get more hits, and a google-crawled wiki seems like a good idea.

I mean, come on, there is a recession going on right now, and even with Network/UNIX sysadmin supposedly a recession-proof job (Yeah, right), it's always good if you can justify some serious experience... and a serious Internet site to prove it.

What do you think? Is it worth it to create a wiki?

Not a long post this time, just a link to the best summary about changing IP addresses, under Solaris, that I have seen so far.

Do what the man says, enter /usr/sbin/reboot and, presto! Your Solaris machine just changed its IP address.

Even newbies can follow this document, which is why I used when explaining what to do to a newbie, in another country, who has to modify the configuration of a local (distant for me) machine.

If you have never tried it, Dillo is a great lightweight browser. It is fast, fairly complete (except for nagging CSS and frames non-display) and simple to use.

While it is not - in my opinion - the best browser around, it has some very interesting uses, especially for reading documentation or browsing the web on very limited hardware.

And, finally, Dillo has released its 2.0 version, which is a complete rewrite, using FLTK2 for its GUI, and tons of enhancements (such as tabbed browsing, anti-aliasing, etc.).

I can testify that the speed of Dillo 2.0 is simply unbelievable: launching the program is instantaneous on my little machine at work. And this is a Pentium III 800Mhz, with 190MB of RAM, running fluxbox 0.9.1: hardly the most powerful machine on Earth.

Now, compiling Dillo 2.0 on OpenBSD 4.3 is surprisingly easy. To do this, follow the three easy steps below:

• First things first: make sure you have GNU tar and GNU make installed from the OpenBSD packages. This will help a great deal.
• Download FLTK2, version 2.0.x-r6403, from its home site, compile and install that (configure && /usr/local/bin/gmake && sudo /usr/local/bin/gmake install should take care of that). Compiling and installing both complain with a lot of warnings, but you can safely ignore these.
• Download Dillo 2.0 source code from its home site, and compile and install (see above: the same commands work for both). Again a lot of warnings during the compilation, but the software itself works like a charm.

And... That's it! If, like me, you installed Dillo-0.8.6 from the OpenBSD packages, just remember to rename /usr/local/bin/dillo as /usr/local/bin/dillo-0.8, or somesuch before running the Dillo installation, and you are done.

Since I am a godless atheist, I'll swear on the holy names of both J.R. "Bob" Dobbs and Eris that the following is absolutely, 100% true.

Only the names have been changed to protect the guilty. And my employment.

From: DumbIdiot <dumbidiot@ch.megacorp.com>
To: Manager1@ch.megacorp.com, Manager2@ch.megacorp.com, Manager3@ch.megacorp.com
Cc: UnixAdmins@fr.megacorp.com
Subject: I think I made a mistake on galactus.
 
Hi,
 
I was connected as root on galactus, and I entered the command rm * in /
 
I though that I was in /home/programmers/dev/3.14/backup instead.
 
Is this bad?
 
--
Clueless DumbIdiot.

Yes, gentle reader, the above email is (almost) 100% true.

If you understand (heck, this is Slashdot, you should understand it) what "rm *" does, as root, in the / directory of a UNIX machine, you are probably already screaming: "Oh, the humanity!".

But WAIT! There is more to come. The horror has just started.

From: Manager1@ch.megacorp.com
To: dumbidiot@ch.megacorp.com, Manager2@ch.megacorp.com, Manager3@ch.megacorp.com
Cc: UnixAdmins@fr.megacorp.com
Subject: Re: I think I made a mistake on galactus.
 
Nah, it's OK.
 
Galactus is a Tru64 machine, and these machine have nothing important under /
only a few login shells.
 
UNIX admins: could you restore the shells? Or just copy them from Kraken,
it's another Tru64 machine.
 
--
Manager1

Yes, I told you so, gentle reader. The horror has just started.

Please note that the anonymous "Manager1" above is not just any manager.

No, he is the head of the programming team at "ch.megacorp.com". Most of his work day is spent on UNIX machines. He is the kind of guy who is supposed to have a clue , for Pete's sake!

On the other hand, he is the one who insists on giving all his programmers the root password on all the machines, because, well, because "they need it to update the software".

Anyway, I tried to compose as polite a reply as I could. Here is what I came up with:

From: me@fr.megacorp.com
To: Manager1@ch.megacorp.com, dumbidiot@ch.megacorp.com, Manager2@ch.megacorp.com, Manager3@ch.megacorp.com
Cc: UnixAdmins@fr.megacorp.com
Subject: Re: Re: I think I made a mistake on galactus.
 
Hi,
 
Actually, Tru64 stores the kernel and a lot of system information in /
 
For example, on a Tru64 machine we have here, I have this:
 
me@sauron$ ls -alF /*unix*
-rwxr-xr-x 1 root system 12887904 Sep 29 2003 /genvmunix*
-rwxr-xr-x 1 root system 18784112 Mar 29 2004 /vmunix*
-rwxr-xr-x 1 root system 18357024 Mar 29 2004 /vmunix.PrePatch*
 
So, I think your machine may well crash pretty soon.
 
--
me (just a UNIX admin doing his job, ma'am).

Yes, my friends, my situation was already dire.

But it goes without saying that a good deed cannot go unpunished:

From: Manager1@ch.megacorp.com
To: me@fr.megacorp.com, dumbidiot@ch.megacorp.com, Manager2@ch.megacorp.com, Manager3@ch.megacorp.com, (longest list of managers you have ever seen)
Cc: UnixAdmins@fr.megacorp.com, UnixAdminsManager@fr.megacorp.com
Subject: THIS IS CRITICAL!!! Re: Re: Re: I think I made a mistake on galactus.
 
People,
 
Galactus is a CRITICAL MACHINE. IT CANNOT BE ALLOWED TO FAIL.
 
I don't think me@fr.megacorp.com understands the seriousness of the situation:
galactus could EXPLODE at ANY MOMENT and we HAVE to deliver a new version of the
software to our clients TOMORROW!!!
 
THIS HAS TO BE FIXED NOW!!!
 
--
Manager1

OK, it can really get any worse than that... Right?

Wrong.

From: dumbidiot@ch.megacorp.com
To: me@fr.megacorp.com, Manager1@ch.megacorp.com, Manager2@ch.megacorp.com, Manager3@ch.megacorp.com, (longest list of managers you have ever seen)
Cc: UnixAdmins@fr.megacorp.com, UnixAdminsManager@fr.megacorp.com
Subject: Re: THIS IS CRITICAL!!! Re: Re: Re: I think I made a mistake on galactus.
 
Sorry,
 
I just tried to connect to galactus and here is the reply from the machine:
 
$ ssh dumbidiot@galactus
SSH: Connection timed out.
 
Is this bad?
 
--
Clueless DumbIdiot

Oooops. The "critical" machine, that "must not fail"... Just did.

Yes, sirree, it crashed.

This server is no more! It has ceased to be! It has expired and gone to meet 'is maker! It is a stiff! Bereft of life, it rests in peace! (Etc... etc...)

And here is why I am still at work right now (8:30pm), trying very hard to restore this machine instead of being home to kiss my wife and kids.

And here is also why, gentle reader, I can make every single person at HP European Tech Support laugh. Nervously. Some of these techies could not believe it. Some believed it. But they all laughed.

Now, if something like this happens to you, here are two solutions:

If your machine is still on (and the machine renamed as "galactus" in the emails above stayed on for a couple of hours before crashing):

There is a copy of the Tru64 kernel in /usr/sys/MACHINE_NAME/vmunix.sys: copy this in the / of your main disk, and you should be OK. Theoretically.

If your machine crashed... Remember that /usr/sbin/advscan is your friend. And not just your friend, but your best friend. Your sugar daddy. And not just your sugar daddy, but your saviour. Trust me: it truly is THAT great.

Now, I hope my tape restore has fnished while I was typing this... Then again, probably not.

Nope, tar is still sitting there...

I have to say, I am always impressed by software that is well done. And vsftpd is definitely one.

To get back to the subject at hand: to compile vsftpd on IBM AIX 5.3, here is what you can try.

Download and install the following software on the target machine:

1. gcc-4.2.0-3.aix5.3.ppc.rpm
2. libgcc-4.2.0-3.aix5.3.ppc.rpm
3. coreutils-5.2.1-2.aix5.1.ppc.rpm
4. m4-1.4.1-1.aix5.1.ppc.rpm

All of these can be download as RPM packages, courtesy of IBM Corporation, from this page.

Once all of these are installed, using, for instance : rpm --install -vvv --percent, you should find yourself with the GNU make command in /opt/freeware/bin. The GCC compiler itself has a symbolic link in /usr/bin:

bash-3.00$ ls -alF /usr/bin/gcc
lrwxrwxrwx 1 root system 26 Sep 17 11:09 /usr/bin/gcc@ -> ../../opt/freeware/bin/gcc*

Therefore, simply type the following: /opt/freeware/bin/make in the vsftpd directory. The program is then compiled automatically.

Here is the output:

bash-3.00$ pwd && /opt/freeware/bin/make
/home/teamsys/packages/vsftpd-2.0.7
gcc -c main.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c utility.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c prelogin.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c ftpcmdio.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c postlogin.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c privsock.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c tunables.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c ftpdataio.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c secbuf.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c ls.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c postprivparent.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c logging.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c str.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c netstr.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c sysstr.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c strlist.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c banner.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c filestr.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c parseconf.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c secutil.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c ascii.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c oneprocess.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c twoprocess.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c privops.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c standalone.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c hash.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c tcpwrap.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c ipaddrparse.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c access.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c features.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c readwrite.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c opts.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c ssl.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -c sysutil.c -O2 -Wall -W -Wshadow -idirafter dummyinc
sysutil.c: In function 'vsf_sysutil_accept_timeout':
sysutil.c:1672: warning: passing argument 3 of 'naccept' from incompatible pointer type
sysutil.c: In function 'vsf_sysutil_getsockname':
sysutil.c:1775: warning: passing argument 3 of 'ngetsockname' from incompatible pointer type
sysutil.c: In function 'vsf_sysutil_getpeername':
sysutil.c:1800: warning: passing argument 3 of 'ngetpeername' from incompatible pointer type
gcc -c sysdeputil.c -O2 -Wall -W -Wshadow -idirafter dummyinc
gcc -o vsftpd main.o utility.o prelogin.o ftpcmdio.o postlogin.o privsock.o tunables.o ftpdataio.o secbuf.o ls.o postprivparent.o logging.o str.o netstr.o sysstr.o strlist.o banner.o filestr.o parseconf.o secutil.o ascii.o oneprocess.o twoprocess.o privops.o standalone.o hash.o tcpwrap.o ipaddrparse.o access.o features.o readwrite.o opts.o ssl.o sysutil.o sysdeputil.o -Wl,-s `./vsf_findlibs.sh`

That's all there is to it. Follow the instructions in the INSTALL and you should have a working vsftpd installed on your AIX machine in no time.

As, I said: impressive.

Would you like to know what's going to happen to the United States if McCain/Palin are elected?

Read it and weep.

It requires connecting a few dots here and there, so here is my take on it:

Let's start by saying American citizens elect McCain and Palin. This may seem far-fetched, but don't be fooled: it could happen. Please note that I am not making a judgement or criticism here: Americans are free to elect whomever they want. Just don't tell me who to vote for in my own country, OK?

The United States are -- right now -- in the middle of a painful economic crisis. I think we all agree on this. After all, when even the biggest investment banks in the USA are in trouble, it's time to start worrying.

The United States also own a lot of money to the rest of the world.

Now, connect the dots: if the USA elect McCain, and, essentially, decide to have four more years of the same, the rest of the world is going to vote, too. It's going to vote with its MONEY.

Right now, a lot of [smaller] banks and companies in the USA are suffering since they can't borrow money. The situation is difficult enough, but what would happen if all foreign investors start pulling their money out of the USA? Nothing less than a default on the biggest debt in world's history.

Now, of course, if Barack Obama is elected, the exact same thing could happen, but it would probably happen a lot more slowly, and that would give time to the global economy -- and to the US economy -- to adapt. It's true I don't have a lot of faith in the USA financially and economically speaking, as I don't see how it could pull itself out of the hole it has been very busy digging. But there is a difference between "totally implode and terminate with extreme prejudice" and "slowly adapt to the painful new realities" (meaning: the United States are not the world's Big Kahuna anymore).

OK, that was the end of my rant for today. Feel free to disagree with me in the comments.

Dear reader,

Since you are reading this journal on Slashdot, I'll suppose you are familiar with the Fermi Paradox.

If not, allow me to explain: since there is life on the planet we call "Earth" -- I prefer the name "Sol III" personally -- and given that Earth is just one planet in the universe, it seems logical that many, many other planets harboring life exist out there. And, out of these many planets, there must be quite a lot who have developed intelligent life.

Hence the famous cry attributed to Fermi: "Where is everybody?"

The solution to this paradox, given our current predicament (global warming), based on simple enough problem (the tragedy of the commons) is quite evident: every time intelligent life arises somewhere, there is what I will call a "industrial/scientific window": a time where pollution and reckless exploitation of natural resources is not counterbalanced by enough scientific knowledge on ecology and feedback loops.

In other words: any civilization will go through a stage where its industrial development - and lack of scientific understanding - will simply destroy its planetary habitat. The civilization then crashes and is either wiped out completely (complete extinction) or has to be restarted at a much lower technological level, therefore preventing it to "reach the stars". It is possible that an industrial civilization is smart enough to destroy its planet through pollution, but not smart enough to understand it is actually doing so. Think 19th century here, with gigantic, polluting industries but no real scientific understanding of the consequences of this pollution.

We are, right now, at this very stage: the pollution, the slow exhaustion of natural resources, the slow disappearance of fertile soil, clean water and the progression, year after year, of ocean's dead zones. And that's pretty scary.

If all of this took place on a planet with less resources, or a more fragile ecosystem, it is definitely possible that the ecological crash would actually wipe out the civilization and render the planet inhabitable.

On the other hand, the good news is that nature has a way of bouncing back... Once its uses are severely rationed. As pointed out in "Collapse" by Jared Diamond, some civilizations were able to survive very well, even with limited land and natural resources, simply by managing resources (land, water, forests, etc) much better than some others.

So, faithful readers, what is your take on this? I suppose plenty of other people have already drawn the parallel, but I wanted to sound off before I get back to system administration, which seems to be the main subject of this Journal these days...

[Edit: the title of Jared Diamond book was "Collapse", and not Crash, the otherwise excellent novel by J.G. Ballard]

Back from holidays. Sunny vacation, how quickly you were gone... *sigh*

One of my colleagues succeeded in messing up PAM authentication on a Red Hat 3 machine, locking the machine and preventing anyone from logging onto it, including root on the system console.

Yet another reason why PAM sucks. But I digress.

Here is the best way to do it:

1. Reboot the machine
2. On the GRUB main screen, stop the countdown, and 'edit' the normally selected boot sequence.
3. Without changing anything, just add the word 'single' (without the quotes) at the end of the kernel definition (See here for more information).
4. Exit the editor, boot the kernel with GRUB.
5. After the device initialization phase, but before PAM is started, the kernel should drop into single user mode.

This allowed my co-worker to correct the problem by replacing his messed-up PAM config with a backup of the latest good configuration.

Morals:

• Always make a copy of the configuration you are about to change.
• PAM sucks. It sucks, it sucks, it sucks.

There, I feel better... :-)

So... OpenBSD programmers are masturbating monkeys, right? Right?.

While I have the utmost respect for Linus Torvalds -- and I even agree with some of the things he has to say about security and the "3133t" crowd it attracts -- I have to say this troll was worthy of Theo de Raadt himself.

Seriously, though: OpenBSD programmers are focused on security... So what? How is this a problem for Linus? How does it impact the Linux kernel we all know and love? Sheeesh, no wonder some people think open source is this immature, nerdy, stupid thing: with that kind of flames, who has time to convince The Man that Open Source is worth investing in...

Sometimes, configuring new (and old) software can be a pain in the... backside.

Anyway, I finally upgraded Firefox to 3.0 and, so far, everything looks good. Some extensions did not work (nothing crucial), some needed to be updated, but everything worked smoothly. Firefox 3 looks good, and seems a bit smaller than 2.0.0.15, so I am going to upgrade on all machines.

Except for Brief. If you don't know Brief, let's just say this is THE Firefox extension that made me understand why RSS feeds are the next best thing since sliced bread. It's cool, it's fast, it's great.

And it did not work with Firefox 3.0, even after I updated Brief to version 1.2, which is supposed to work with FF3.

Now, RSS reading does not work anymore. Aaaaaaaaargh. It really sucks when something that great does not work. Fortunately, the answer was just a few clicks away, on the Brief support forums.

The answer is simple: go to your Mozilla Firefox profiles folder, delete the file named "brief.sqlite" and rename the file brief-backup-*.sqlite as brief.sqlite. That's it, Brief now works as usual and it feels so good to have it back!

I have decided to go "old school" on my newest OpenBSD 4.3 machine. Instead of Vim 7.1, I have installed Elvis 2.1.4 on it, straight from the official OpenBSD package.

So far, I like what I have seen. While I haven't used Elvis much in the past, it's fast, complete and a very good clone of vi. It is the standard vi on Slackware, which is a very high recommendation in my book indeed (see this post for more explanation). While the syntax colouring is not as good as the one used in vim, it is good enough for my needs, and the speed is excellent. Also interesting is the size of the executable:

-bash-3.2$ ls -alhF $(which vim) && ls -alhF $(which elvis)
-rwxr-xr-x 1 root wheel 1.2M Mar 10 22:44 /usr/local/bin/vim*
-r-xr-xr-x 1 root bin 349K Mar 12 14:03 /usr/local/bin/elvis*

And please note that the elvis executable also has X11 display, while the vim binary is terminal/plain text only:

-bash-3.2$ pkg_info | grep -i vim
vim-7.1.244p0-no_x11 vi clone, many additional features
-bash-3.2$ pkg_info | grep -i elvis
elvis-2.1.4p2 clone of the ex/vi text editor

One third of the size for a fully fledged editor is enough to make you think.

Anyway, to configure Elvis, here is what I have put in my ~/.elvisrc file:

-bash-3.2$ cat .elvisrc
:set ruler
:set backup
:set flash
:set showmode
:set showname
:set undolevels=100
:map gg :1
:color cursor blue
:set blinktime=0
:courier 14

Simple, small, fast, complete and easy to configure... What more can you ask for?

[EDIT: of course, the Elvis configuration should be in ~/.elvisrc and not in ~/.exrc, and the X11 configuration should be dead last. Other than that, elvis is great.]

It's a tragedy to work with useless software such as this deep fried piece of ..... named MQSeries, for verily, I tell thee, rarely have I seen such a useless piece of spaghetti application.

OK, enough ranting, here is the nitty-gritty of it:

If you get MQSeries messages -- on a Red Hat Linux platform -- such as:

06/02/2008 09:11:58 PM - Process(10406.238) User(mqm) Program(amqrmppa)
AMQ6184: An internal WebSphere MQ error has occurred on queue manager Wolfenstein.
 
EXPLANATION:
An error has been detected, and the WebSphere MQ error recording routine has
been called. The failing process is process 10406.
ACTION:
Use the standard facilities supplied with your system to record the problem
identifier, and to save the generated output files. Contact your IBM support
center. Do not discard these files until the problem has been resolved.

Or a bit like this:

06/03/2008 09:20:10 AM - Process(4092.20) User(mqm) Program(runmqlsr)
AMQ9999: Channel program ended abnormally.
 
EXPLANATION:
Channel program 'JAVA.CHANNEL' ended abnormally.
ACTION:
Look at previous error messages for channel program 'JAVA.CHANNEL' in the error
files to determine the cause of the failure.

HINT#1: check the files named /var/mqm/errors and /var/mqm/qmgrs/wolfenstein/errors, for instance... (replace 'wolfenstein' by the name of your queue, of course).

HINT#2: if you only see two mqm processes when you type ps faxu | grep -i mqm, something is wrong...

Well, my friend, your MQSeries just crashed and crapped all over itself. Information about this is sparse on the Internet, but Google is your friend and should be able to give you more links than you can shake a stick at.

Fortunately, getting MQSeries unstuck is not too difficult, just follow the four easy steps below... All of these steps should be performed as root:

1. Check that all 'mqm' processes are stopped with ps faxu | grep -i mqm | grep -v grep, if there are processes left, kill them all with pkill -9 -u mqm.
2. Delete all sockets left in /tmp with: rm -v /tmp/MQ*, but watch out, as there may be a very large number of them...
3. Clean up all temporary files and whatnot with the command: su - mqm -c "/opt/mqm/bin/amqiclen -x -m QMGR" (return code should be zero).
4. Finally, clean up all used IPCS resources with the commands ipcs -a and ipcrm (do a man ipcrm for more information).

That's it! MQM should now be able to restart without any problem. Ain't that helpful?

The task: install ASAP a small mail server on a VMWare Virtual machine running SuSE Linux Enterprise 10 SP1. It's urgent.

One of my user soon goes to a client site to make a demo of our latest product. That product is supposed to offer several reporting options, one of which is email. So, the physical machine, running Windows XP, is supposed to receive email from the SuSE virtual machine.

The only problem is, SuSE is an over-engineered, byzantine piece of @&**!! And its default (POP/IMAP) server is Cyrus, which I have come to hate with a vengeance (the SMTP server is Postfix, and I have no problem with it). Basically, I spent an entire day fiddling with the Cyrus configuration, and not getting anywhere. That thing just sat there and did not do anything. After a while, I felt like jumping naked in a huge pile of thumstacks rather than deal with Cyrus ever again.

Usually, under SuSE, you are supposed to go through YaST (Yet another Stoopid -- and Stoopidly capitalized -- Tool) to install and configure everything... Except for Cyrus, which is NOT managed by YaST. Great. See, people, that's how you do it: "German engineering" at its best.

Did I mention this was supposed to be urgent? Like, it had to be done yesterday?

I was hoping Google would be able to help me. Nope. No relevant information, except some poor schmucks who have the same problem that I have. This is urgent. The user is almost breathing down my neck, starting to panic about his oh-so-important demo.

Then it hits me: what I'll call from now on "The Slackware Rule": "When in doubt, see how Slackware does it, and copy that" .

So, a POP mail server. Slackware uses a package of POPA3D as its default POP server.

This is the description of popa3d from Solar Designer, its programmer: "popa3d is a tiny POP3 daemon designed with security as the primary goal."... Hmmmm... Tiny, secure. What's not to like?

Downloading and compiling popa3d 1.0.2 under SuSE is done in a few minutes. The instructions contained in the "INSTALL" file are clear and simple. In a nutshell, you are supposed to edit the Makefile (only to uncomment a Linux-related line) and "params.h" (I configured the SuSE mail spool directory and the stand-alone daemon mode), compile and install.

I also had to create a small script in /etc/init.d to make sure popa3d was launched each time the machine was restarted. The default Postfix configuration, which uses /var/spool/mail/ worked perfectly with popa3d, without any modifications. And, the best part: popa3d does not require any configuration file! Now, that's what I call tiny, and convenient!

About 30 minutes of work later, my user reported that email was now working between Outlook and the virtual machine. Mission accomplished! One less problem to deal with.

The moral of the story is:

1. SuSE is a piece of &@^**++!!
2. Slackware ROCKS! If you want another proof of this, using Slackware from the very beginning helped me compile requested software on UNIXes as different as AIX, Solaris and others. Slackware is the Linux distro that will teach you.
3. popa3d ROCKS!
4. When in doubt, see how Slackware does it, and copy that.

I feel like I can relax now, knowing that horrendous Cyrus thingie is behind me. Friday night, here I come!

I have been asked to make a (really) small Jabber server on a small HP machine.

Installing OpenBSD 4.3 on the machine was fairly simple and uneventful, but the fecal matter hit the rotating oscillator when I first rebooted the machine.

Almost as soon as the machine was starting, the OpenBSD kernel crashed and dropped me into its integrated debugger (with a ddb> prompt).

Not good.

Thankfully, Google is your friend, and entering "OpenBSD HP PC crash kernel" immediately gives you the correct answer. By the way, do read the entire page, as it contains a fairly nice explanation on how to recover from a crash, not just an ACPI-related one.

So, if you install OpenBSD 4.3 on an HP machine, and the kernel crashes almost immediately, try the following, it worked for me:

1. Once at the ddb> prompt, type boot reboot (Try typing help for more information on the functions of the integrated debugger).
2. Once the machine has rebooted, you have a few seconds to type -c at the boot> prompt. The kernel itself is booted very fast, so hurry up as soon as the boot> prompt appears!
3. The OpenBSD kernel is then launched, but does not probe the hardware. Instead, it stops and displays a UKC>/ (User Kernel Configuration) prompt.
4. On the UKC> prompt, type disable 426 or disable acpiprt*. The kernel should then respond "426 acpiprt* disabled".
5. Type quit to quit the UKC> prompt and save your changes temporarily. You can try list to see all the drivers contained in the OpenBSD kernel or help for more information on the functions of the UKC.
6. The kernel should then boot normally.
7. To make this change permanent, and avoid having to do this every time you reboot the machine, make sure you read the excellent OpenBSD FAQ, and enter config -u -f -e /bsd as root.
8. Your OpenBSD kernel is now in activity and should avoid crashes at the next reboot.

That's it! Hope this helps someone...

Once again: OpenBSD rocks and its documentation really is top-notch.

Doing this under Linux would require passing boot arguments (disable acpi?) at the LILO or GRUB prompt, but this is pure speculation on my part.

[Warning: this post contains rude language, sexual innuendoes and all-around crappy attitude. You have been warned.]

So, there you go, another stoopid Leenoox distribution: Exherbo.

This was announced on /. frontpage, for Pete's sake.

A new Linux distribution. Not even an interesting one, I am afraid.

It's based on Gentoo. In my book, Gentoo is crap. I mean, really.

The funny thing is, the creators of Exherbo seem to agree. Go ahead and read the front page, and, especially, the QA section. It's impressive. It's childish, petulant, intellectually limited and just plain dumb in its mindless criticism. It's also completely, pointlessly megalomaniac. I mean, a new 'init' system? Pleaaaaaaaase. Yet another vanity project, that's going to fade soon into irrelevancy.

But, apart from attitude, what does Exherbo has to offer to this Slacker? Nothing, or close to nothing.

Everything that Gentoo (and Exherbo) do, Slackware does better. An order of magnitude better. I use Red Hat Enterprise Linux, SuSE Enterprise Linux, Debian, Ubuntu and several others, both at work and at home. And they are all crap. Sure, I'll work with them, I'll administer them and I'll even make them sing and dance. But they all SUCK .

I'll repeat this one last time, so that it penetrates the thick and moist intelligence-less brain matter of most Linux system programmers out there: most Linux distributions out there just plain suck . Yes, even Ubuntu (especially Ubuntu!). If you want something smooth and really well done, stop wasting my time with Linux and switch to BSD: OpenBSD and NetBSD are the way to go.

As far as Linux is concerned, the only one that works properly and does not consider you have the I.Q. of a unicellular life form is Slackware. Experience counts, and Slackware is the oldest surviving distribution. It's simple (yes, simple!), it's stable and it just plain works . And that's what I want: something that just plain works.

Using anything else is simply asking for pain and suffering, RPM hell and badly maintained packages, ridiculous limitations and agreements (read: rimming Microsoft collective assh*le) and all-around insecurity.

Period. End of story. I wish all the best to the Exherbo developpers, but they are re-inventing the wheel... for the millionth time. And re-inventing crap one million time, and hoping for a different result every time is the basic definition of madness.

Another Leenoox distribution. Sheesh. Kids, these days.

All right, posted here a second time, since Slashdot seems to have swallowed the first version. My apologies if it appears two times...

This is, of course, possibly incomplete and/or totally crazy, but it solved a problem others may have had, so I hope an AIX Grandmaster somewhere out there will correct me if I am wrong.

A user at my job requested a GNU screen with ncurses compiled in to be installed on an AIX 5.3 server we have, since it seems the default version does not have ncurses. And, of course, that horrible job fell squarely on my lap.

First things first: go here and make sure you get glibc, gcc, GNU make, and both ncurses and ncurses-devel packages installed on the target machine. Since these are RPM packages, installing them is as simple as entering, as root:

rpm --install --percent -vv ./package.rpm

Now, compiling screen should be simple enough (after you have done your configure) but it turns out not to be that simple, since a simple gmake gives you the following cryptic result:

misc.c:648: error: too few arguments to function `setenv'

A quick Google search (since Google Is Your Friend) returned this page as the most promising result, which, in turn, led to this screen-related page on Savannah. That last page gave me the "solution" I'll detail below.

It seems the problem is that the operating system should be defined in the file misc.c, so that it can be compiled correctly.

More specifically, the problem is located in the following lines of misc.c:

# if defined(linux) || defined(__convex__) || (BSD >= 199103)
  setenv(var, value, 1);
# else
  setenv(var, value);
# endif /* linux || convex || BSD >= 199103 */

The (quick & dirty) solution to this problem is to edit the file as follows:

# if defined(linux) || defined(__convex__) || (BSD >= 199103)
  setenv(var, value, 1);
# else
  setenv(var, value, 1);
# endif /* linux || convex || BSD >= 199103 */

Of course, this means that setenv does not take into account the operating system anymore... Which is a very dirty hack indeed, but, hey, it solved my problem!

After making a backup copy of this file, and restarting gmake, the compilation now works without any problem. A quick gmake install later, as well as a tic screeninfo.src (to install the proper screen termcap), I was able to report success to my user.

Screen 4.0.2 now works, with ncurses support compiled in, on AIX 5.3.

Again, if anyone has a better solution to this issue, please let me know: I'll glad to learn of a better way!