Check out my latest product, BuildFactory

CentOS, at least it's free, right?
I'm somewhat forced to use CentOS for testing on some code I've got to fix for a client, CentOS in case you don't know, is the open and free version of Red Hat Enterprise Linux (RHEL, as in rhel stupid, ok, so that reference didn't work). I currently work on FreeBSD, OpenBSD, and Mac OS X (10.4.7) and gleefully use ssh(1) and various terminals, I'm no stranger to bash(1) and he's no stranger to me. In my customary fashion for setting up a new machine, I plug it into the network, and then just use secure shell for the rest of my work, there's something magical about using vim(1) on a remote machine that just makes me feel all warm and fuzzy inside. I've not used a Linux distribution in a year or so, and I haven't used a redhat distribution in over 3 years, so this was admittedly going to be different, but I was expecting it to...suck.The machine I have to use for this is an older dual Pentium II (2x450Mhz) with 512MB RAM, a few ethernet cards, USB, etc. It's an older machine, but definitely no 386. I grabbed the latest CentOS, 4.3, from the website, and tried to install...shortly after the install CD's kernel was loaded, it kernel paniced. I trying adding some boot loader arguments, such as 'linux noapic', still kernel paniced. Of course this left me with one place to go, backwards. When in doubt, install an older version and hope to god that it works.
This is a rant, just in case you were expecting something else :)
After waiting another 15 minutes or so to download and burn the CentOS 3.7 Server CD ISO from a CentOS mirror, I popped it into my 'they-dont-make-them-like-they-used-to' dual Pentium II PC. Luckily CentOS 3.7 worked fine, it installed smoothly and made me feel like I had come out victorious in round one versus CentOS. Alas, my victory would be short lived, I needed to upgrade the OS as much as possible, aiming specifically at 4.xx with a 2.6 linux kernel, so I set forth with yum as my companion and discovered that the default yum repositories for CentOS don't work! I'm not completely certain as to why the CentOS team decided to distribute their OS without the GPG key needed to use their yum repositories, but I'm pretty sure the monkey decided to do it. Either that, or there's a grizzled CentOS developer somewhere in a dark basement that needs to be beaten with a rolled newspaper (CentOS' actual explaination of this decision).
now the fun starts
After running 'yum update' and making sure I had all the latest gizmos and gadgets installed for CentOS 3.7 from the CentOS yum repositories, I set about getting some work done. First thing to do was try out and see if I could replicate an NFS bug I have been working with on FreeBSD and OpenBSD. To make sure my CentOS machine could "see" the NFS server (FreeBSD 6.1-STABLE), I fired up 'rpcinfo'
[root@localhost tyler]# rpcinfo
bash: rpcinfo: command not found
bash: rpcinfo: command not found
Alright, what the hell, I'm almost certain no modern *nix OS is going to ship without NFS tools...so I called upon 'which'
[root@localhost tyler]# which rpcinfo
/usr/bin/which: no rpcinfo in (/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/tyler/bin)
/usr/bin/which: no rpcinfo in (/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/tyler/bin)
Are you kidding me? Maybe it's hidden away somewhere, or it's got a completely different name! I know how those Linux folks like to rename things on a whim, so how about 'apropos'
[root@localhost tyler]# apropos rpc
rpc: nothing appropriate
rpc: nothing appropriate
Aha! I think I know what's wrong, the database that apropos feeds off of hasn't been generated (nice going CentOS), I guess I'll have to generate it myself, through a spiffy little command called 'makewhatis'.
[root@localhost tyler]# makewhatis
bash: makewhatis: command not found
bash: makewhatis: command not found
This was getting frustrating (thus the rant), so I poked around, and I finally looked at my default PATH variable in bash, and noticed something was missing:
[root@localhost tyler]# echo $PATH
/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/tyler/bin
[root@localhost tyler]#
/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/tyler/bin
[root@localhost tyler]#
In case you're not seeing it, I'll go ahead and elaborate, there's one crucial directory that's missing from the default PATH variable on this CentOS 3.7 installation, /usr/sbin. This left me in an awkward spot, what set of mentally handicapped gorillas leaves /usr/sbin out of the default root path? Especially when it's got all the good commands in it! Long time favorites like, cupsd, sshd, rpcinfo, makewhatis, chroot, crond, visudo, tcpdump and up2date.
I'm certain somebody's going to pipe up and say "that's been fixed in 4.3" or something to that nature, I'm sure it has, but I can't bloody install it to see for myself. :(
[tags: centos, linux, freebsd, openbsd, redhat, rhel]
Replies
Shotts is correct, but rather un-informative. "su -" will load a clean root enviroment with all the correct paths. Making a plain "su" not include /sbin and /usr/sbin is RedHat's way to apply a clue bat to the side of your head in an attempt to make you not use root in an insecure way. Apparently it didn't work.
Write reply
This item is closed, it's not possible to add new comments to it or to vote on it



So true!