fediary

chkconfig, et al

2006-04-11T09:51:00.000-07:00

Following on from the other day, while cleaning out my tabs this morning I found some added info on disabling services. Some great advice on cleanly disabling things, with the added benefit of not having to remember anything!

1) to save the current state of you services(so that if some dependecies are bork you can still revert back) chkconfig --list > services.states 1) dump the service names chkconfig --list | awk '{print $1}' > services.txt 2) del services you want to turn off from services.txt, save it as services.on . you can check what the service does before making a decision with rpm -qi `rpm -qf /etc/init.d/$SERVICE_NAME` 3) run a script like this #!/bin/sh FILENAME='services.on' MODE='on' cat $FILENAME | while read SERVICE_NAME do chkconfig --level 345 $SERVICE_NAME $MODE done exit 4) repeat 2)3) for services you wanna turn off, just save the config to another file and edit $FILENAME on aforesaid script.

Just a question of time

2006-04-10T19:25:00.001-07:00

My clock is/was off and ntpd wasn't even running (even though /etc/init.d/ntpd was set +x), so this is how I fixed it: I copied over the server line from my FreeBSD machine. Not very independent with this Linux thing, am I? Apparently the default servers listed in FC4's /etc/ntp.conf are bunk, so listen up.

Seriously though, there are time servers all over the place, so if you don't have a favorite already go ahead a pick one to use. Just take your server (preferably by IP address because there may be a time when DNS is down and you still need to have good time), look for the lines in /etc/ntp.conf that say server and plunk it down in the first position.

# /sbin/service ntpd start
Starting ntpd:                                             [  OK  ]

It may take a few minutes for it to kick into polling and actually change the time. You can issue a /usr/sbin/ntpd -q to force the synchronization if you're impatient.

ntp

2006-04-10T19:25:00.000-07:00

Okay, the default servers listed in FC4's /etc/ntp.conf are apparently bunk. My clock is/was off, so this is how I fixed it: I copied over the server line from my FreeBSD machine. Not very independent with this Linux thing, am I? Seriously though, there are time servers all over the place, so if you don't have a favorite already go ahead a pick one to use. Just take your server (by IP, preferably), look for the lines in /etc/ntp.conf that say server and plunk it down in the first position.

# /sbin/service ntpd start
Starting ntpd:                                             [  OK  ]

It may take a few minutes for it to kick into polling and actually change the time. You can issue a /usr/sbin/ntpd -q to force the synchronization if you're impatient.

Hostname

2006-04-10T13:43:00.000-07:00

I thought I'd be smart and use my intuition, finding some page a week or so ago telling me that to set the hostname all I needed to do was to put the hostname into the textfile /etc/hostname and run hostname -F /etc/hostname. This isn't the first time I've read advice that fixes the immediate problem but doesn't survive a reboot. Linux may not be Windows, but for sure it's necessary to have a machine rise from the dead in a workable state. Combing through man hostname gives me a notion that indeed /etc/hostname should be read at boot by /etc/init.d/boot or /etc/rc.d/rc.inet1, except that neither of those scripts exist on my vanilla FC4 system!

As I read on I make special note not to ignore what seems to be finer points of manpages (always a struggle), I bear down and realize that even though /etc/rc.d/rc.sysinit says

# Set the hostname.
update_boot_stage RChostname
action $"Setting hostname ${HOSTNAME}: " hostname ${HOSTNAME}

and /etc/host.conf says order hosts,bind that perhaps there's a middle value there. /etc/hosts doesn't have a hostname, is there anything I'm missing while scanning through man hostname? Why yes! There's a little mention of /etc/sysconfig/network, which in hindsight must not be rewritten by hostname -f [file], but alas:

# more /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=localhost.localdomain

I have now changed this li'l bit to the correct value and sure enough, a reboot confirms that I'm now clean. Well, as clean as can be even if this method doesn't exactly ping my elegance genes with its failure to jibe with the manpages.

Zaps

2006-04-06T12:48:00.000-07:00

# cd /etc/init.d
# ll | grep -v x
total 472
-rw-r--r--  1 root root  1352 May  2  2005 bluetooth
-rw-r--r--  1 root root  1502 Mar  1  2005 dc_client
-rw-r--r--  1 root root  1344 Mar  1  2005 dc_server
-rw-r--r--  1 root root   970 May  2  2005 dund
-rw-r--r--  1 root root  1525 Mar  2  2005 irda
-rw-r--r--  1 root root  6248 May 27  2005 isdn
-rw-r--r--  1 root root  4278 Sep 27  2005 nfs
-rw-r--r--  1 root root  2860 Sep 27  2005 nfslock
-rw-r--r--  1 root root  1146 May  2  2005 pand
-rw-r--r--  1 root root  3978 Mar  2  2005 pcmcia
-rw-r--r--  1 root root  1877 Apr 11  2005 portmap
-rw-r--r--  1 root root  2177 Sep 27  2005 rpcgssd
-rw-r--r--  1 root root  1801 Sep 27  2005 rpcidmapd
-rw-r--r--  1 root root  2153 Sep 27  2005 rpcsvcgssd
-rw-r--r--  1 root root  2493 Jan 24  2005 ypbind

A lot of this stuff didn't seem to be listed in ps aux, but I figured I should chmod -x them anyway. By no means an exhaustive list, most of these things are laptop/Bluetooth oriented. Good to know that FC4 will make its best attempt to work with a laptop, if'n ever I use it on one. For now, good bye to these and hello to a less-chatty startup/shutdown.

Updates

2006-04-03T21:42:00.000-07:00

Moving right along.

My goals for this machine right now are threefold: I'd like to move all of my mail, web, and coding stuff off of my other server to this one. In the process I'll be learning me some Linux, which is not much different than FreeBSD so far. Now that I can log in remotely I don't have to futz with moving keyboard cables around with my KVM and I can leave a terminal open all the time, just waiting for me to tackle another step. So now I update.

Sometimes I'll fly by the seat of my pants, especially when learning, so I decided to take the advice of the Fedora Core documentation and update the machine their way:

# yum update

After several screens of downloading and listing and generally informing me of a zillion things that are going to be done, I am asked a question:
Transaction Summary ============================================================================= Install 10 Package(s) Update 155 Package(s) Remove 0 Package(s) Total download size: 145 M Is this ok [y/N]:

Of course the first thing I notice is that "No" is the default selection! Additionally, I'm not sure what these 10 packages are that yum says I'm going to be installing. Scrolling up I see a few headings that illustrate things nicely:

============================================================================= Package Arch Version Repository Size ============================================================================= Installing: kernel i686 2.6.16-1.2069_FC4 updates-released 15 M Updating: ... Installing for dependencies: dhcdbd i386 1.9-1.FC4 updates-released 63 k gphoto2 i386 2.1.6-1.1 updates-released 1.1 M hicolor-icon-theme noarch 0.8-2 base 24 k libexif i386 0.6.12-3 base 97 k libieee1284 i386 0.2.9-2 base 30 k libsane-hpaio i386 0.9.8-3.2 updates-released 111 k net-snmp-libs i386 5.2.1.2-fc4.1 updates-released 1.8 M python-numeric i386 23.7-2 base 679 k sane-backends i386 1.0.17-0.fc4.1 updates-released 3.0 M

The numbers of items in each of these correspond perfectly to the count above, the kernel being one item and there are nine dependencies to update. There's a lot of garbage in there if you ask me, since I'm not even running any X business yet, but I'll probably get there anyway even if just for fun. This is a basic server at the moment but it doesn't harm anything for a windowing environment to take up a little space. So hicolor-icon-theme can just knock itself out for all I care.

Is this ok [y/N]: Y

Remember, I'm here to make mistakes so that they're documented for the whole of eternity and we find out how little one can know about Linux and still survive!
Downloading Packages: (1/165): glib2-2.6.6-1.i3 100% |=========================| 568 kB 00:02 (2/165): audit-1.0.14-1.f 100% |=========================| 198 kB 00:00 (3/165): acl-2.2.32-1.FC4 100% |=========================| 64 kB 00:00 ...
While I wait for the downloads to move along, I notice that this process is fairly similar to using cvsup on FreeBSD, and in fact is a touch easier. Similarly to apt-get (which I became familiar with during a short stint with Debian Linux a few years ago), cvsup requires one to configure it beforehand. When I started using FreeBSD several years ago I was fortunate enough to know a few people who were willing to handhold me along the first baby steps I took. This boiled down mostly to compiling ports, killing processes, and updating via cvsup. Thing is, when you don't know much about a new operating system - even a Unix(-like) one - tracking down viable repository information can be a little like hunting in the dark. This isn't to say that it's not obvious to those who know, since these things always are, but the process is slightly arcane and tends to use common terms such that search engines don't provide immediate help. So what I'm trying to get at here is that it's nice that yum comes with a basic setup that allowed me to run the updater and it kicked off without any guff. I imagine I'll be fine-tuning it later, finding a closer/faster repository, so on and so forth, but at least I didn't have to go "Uhhhhh...." for three hours until I break down and brave IRC in order to find a kind soul who will offer the correct couple of sentences of help.

(158/165): kernel-2.6.16- 36% |========= | 5.5 MB 00:46 ETA ...
So then I'm dumped unceremoniously back to the command prompt. I'm guessing that there's another command I should run to actually install this stuff. That Fedora site page up there doesn't mention anything about this, unless the cron job that they suggest has some extra voodoo inside of it that gets the junk installed.

As I comb through various pages looking for this mysterious command, I notice that a lot of the yum pages use a lot of space to describe the upgrade process from, say, Fedora Core 4 to FC5. Similar to cvsup on FreeBSD, my goal here is to merely patch the machine up to whatever latest iteration of FC4 exists this evening. So I continue reading and have one of those "I bet the man page would be useful here" moments.

yum update kernel

Yeah, well. So I read the manpage and it's all very englishlike. I type yum install and get a helplist of commandline options. I take a shot in the dark and throw yum install all out there. This generates a little activity through which it becomes apparent that it's processing a cache.
# yum install all Setting up Install Process Setting up repositories http://mirror.averse.net/fedora/linux/core/updates/4/i386/repodata/repomd.xml: [Errno 4] IOError: Trying other mirror. updates-released 100% |=========================| 951 B 00:00 extras 100% |=========================| 1.1 kB 00:00 base 100% |=========================| 1.1 kB 00:00 Reading repository metadata in from local files primary.xml.gz 100% |=========================| 1.2 MB 00:17 extras : ################################################## 3494/3494 Added 17 new packages, deleted 15 old in 5.70 seconds Parsing package install arguments No Match for argument: all Nothing to do

Ah, but "No match" means "no match", so perhaps an asterisk would help?
# yum install * Setting up Install Process Setting up repositories updates-released 100% |=========================| 951 B 00:00 extras 100% |=========================| 1.1 kB 00:00 base 100% |=========================| 1.1 kB 00:00 Reading repository metadata in from local files Parsing package install arguments Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Downloading header for python-dialog to pack into transaction set. python-dialog-2.7-1.fc4.n 100% |=========================| 3.2 kB 00:00 ---> Package python-dialog.noarch 0:2.7-1.fc4 set to be updated ---> Downloading header for fltk-devel to pack into transaction set. fltk-devel-1.1.6-1.fc4.i3 100% |=========================| 47 kB 00:00 ...Yup! A few minutes later, though, this is all still going on. I think it's installing everything it its catalog! Several minutes pass and it's just a constant stream of packages going by, many more than 165. So...back to the drawing board.

Slowing down, I start from the beginning.

# yum install kernel

Which goes through an identical process, midway asking me if the RedHat GPG key was okay to add to the keyring (slightly fancy). It zips through the rest of the process

... Installed: kernel.i686 0:2.6.16-1.2069_FC4 Complete! [root@localhost eric]# reboot
It comes back up just fine, and with the new kernel to boot

$ uname -a Linux localhost.localdomain 2.6.16-1.2069_FC4 #1 Tue Mar 28 12:19:10 EST 2006 i686 athlon i386 GNU/Linux

Now to figure out how to deal with the rest of those updates...

On SSH and iptables

2006-04-02T20:16:00.000-07:00

It turns out that the default Fedora Core 4 install (or mine, anyway) forbids remote SSH logins. This becomes a problem when the KVM switch becomes more of a hassle than it's worth. For me, it becomes more of a hassle than it's worth when your KVM cause key repeats to stop after about one second. Causing key-repeats to stop after about one second is a problem when you like to play Unreal Tournament 2004 and your character stops moving after about one second because your KVM switch is getting in the way.

After an evening of troubleshooting from the ground up and figuring out that the cable is okay and there isn't a problem with the machine being plugged into a wireless AP, I slept on it. While I slept, I let nmap do it's thing on the box to find some more evidence for this mystery:

# nmap -vvvvv -P0 particle

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-04-03 00:45 PDT
Initiating SYN Stealth Scan against 192.168.20.21 [1663 ports] at 00:45
SYN Stealth Scan Timing: About 8.78% done; ETC: 00:50 (0:05:14 remaining)
Increasing send delay for 192.168.20.21 from 0 to 5 due to max_successful_tryno increase to 4
Increasing send delay for 192.168.20.21 from 5 to 10 due to max_successful_tryno increase to 5
Increasing send delay for 192.168.20.21 from 10 to 20 due to max_successful_tryno increase to 6
Increasing send delay for 192.168.20.21 from 20 to 40 due to max_successful_tryno increase to 7
Increasing send delay for 192.168.20.21 from 40 to 80 due to max_successful_tryno increase to 8
Increasing send delay for 192.168.20.21 from 80 to 160 due to max_successful_tryno increase to 9
Increasing send delay for 192.168.20.21 from 160 to 320 due to 11 out of 12 dropped probes since last increase.
Increasing send delay for 192.168.20.21 from 320 to 640 due to 11 out of 11 dropped probes since last increase.
Increasing send delay for 192.168.20.21 from 640 to 1000 due to 11 out of 19 dropped probes since last increase.
SYN Stealth Scan Timing: About 20.79% done; ETC: 01:12 (0:21:56 remaining)
The SYN Stealth Scan took 1960.37s to scan 1663 total ports.
Host 192.168.20.21 appears to be up ... good.
All 1663 scanned ports on 192.168.20.21 are: filtered

Nmap finished: 1 IP address (1 host up) scanned in 1960.493 seconds
Raw packets sent: 4762 (190KB) | Rcvd: 1664 (113KB)
#

So..."filtered." Of course. Thankfully I've intended my writing here to be a true ground-up experience. So a little bit of search-and-scan gives me the information I'm looking for: iptables

Flushing firewall rules:                                   [  OK  ]
Setting chains to policy ACCEPT: filter                    [  OK  ]
Unloading iptables modules:                                [  OK  ]

So now I can log in remotely.

While iptables will prevent you from logging in while the default iptables config is running, it apparently doesn't mind if y ou stop the process, login via ssh, then start up iptables again. This makes the next part easier, which is to start up iptables:

# /etc/init.d/iptables start

Flushing firewall rules:                                   [  OK  ]
Setting chains to policy ACCEPT: filter                    [  OK  ]
Unloading iptables modules:                                [  OK  ]
Applying iptables firewall rules:                          [  OK  ]

...add your ssh filter

# /sbin/iptables -A INPUT -p tcp --dport ssh -j ACCEPT

...list your iptables config to m ake sure everything is in there (ssh, specifically):

# /sbin/iptables -L
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ssh

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain RH-Firewall-1-INPUT (2 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     icmp --  anywhere             anywhere            icmp any
ACCEPT     ipv6-crypt--  anywhere             anywhere
ACCEPT     ipv6-auth--  anywhere             anywhere
ACCEPT     udp  --  anywhere
224.0.0.251         udp dpt:5353
ACCEPT     udp  --  anywhere             anywhere            udp dpt:ipp
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited#

...and save your configuration so that this all still works if you reboot:

/sbin/iptables-save > /etc/sysconfig/iptables

...which I'll now do just to be sure.

# reboot

Broadcast message from root (pts/0) (Mon Apr  3 13:01:24 2006):

The system is going down for reboot NOW!

...and once the machine comes back up it doesn't work

This is the same error that I got before I started all of this, so I'm thinking my iptables rules are incomplete, regardless of what I've read. Looking back at the installed ruleset above, I notice something that could be affecting my happiness here, that my ssh rule comes after the default block of rules from the default config:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ssh

Looking at the block of rules denoted by "RH-Firewall-1-INPUT", I notice that the last rule in the block is

REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

which is a catchall rule to block everything not explicitly allowed by previous rules. In the grand-iptables-scheme of things, this will cause my ssh rule never to be seen by the machine. Sure, eventually I imagine that I will be doing away with the default ruleset and make my own, but until then I will see if I can fix this with an edit.

# vi /etc/sysconfig/iptables

I notice here a possible fix:

-A INPUT -j RH-Firewall-1-INPUT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

...I'll try reversing these two lines

-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -j RH-Firewall-1-INPUT

...and restarting the daemon.

[root@particle sysconfig]# /etc/init.d/iptables stop
[root@particle sysconfig]# /etc/init.d/iptables start
Applying iptables firewall rules:                          [  OK  ]

I disconnect PuTTY and reconnect, then go for the Windows method and actually reboot...and in both cases it works!

Consolation

2005-12-14T18:30:00.000-08:00

There's a fundamental disconnect between working in console mode and aesthetics. What I'm trying to say is that there isn't any easy way of finding out what font is best to use in the console because screenshots are more trouble than they're worth (right now, I'll see how I feel in a bit). However, it doesn't matter because after going through the motions of setfont, it becomes apparent with a bit of cursor-up-and-backspace that all of the fonts that Fedora come with are visually the same. I'm sure there's some codepage business behind the scenes, but seeing as I'm just whiling my time away ASCII-style I don't think I'll come up against these subtleties until I'm dealing with the rarefied world of email. We'll see, of course.

[root@localhost consolefonts]# setfont iso01.08

That's right, I'm in a console of squishy characters of questionable legibility. So much for aesthetics, but I'm sure there's better fonts out there if I'm willing to install a frame-buffer or something.

Ooops. I seem to have only ran `ls iso*` and by restricting my learning to the little bit of information I found in the first place I looked (after Google), I wound up less-than-informed. It's all the same, since I wasn't satisfied with blocky DOS-era text, I found that there is some built-in graphics support, which went a long way toward solving this seemingly minor problem. I'm sure there's a Jargon File entry for this spiralling into fixing the minorest of problems, but here I am.

A little more experimentation goes a long way toward happiness in this venue. From the framebuffer HOWTO above, one learns of the "vga=" directive in the GRUB boot loader. Copying and pasting the existing section to an area right below it (be sure to comment out "hiddenmenu"), you can experiment all you like with different values of vga=. After first booting with 'vga=788' (800x600) and making sure that nothing blows up, I juice the load line up to the max.


# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
#          initrd /initrd-version.img
#boot=/dev/hda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
#hiddenmenu
title baba (2.6.11-1.1369_FC4)
 root (hd0,0)
 kernel /vmlinuz-2.6.11-1.1369_FC4 ro root=/dev/VolGroup00/LogVol00
 initrd /initrd-2.6.11-1.1369_FC4.img
title baba-vga (2.6.11-1.1369_FC4)
 root (hd0,0)
 kernel /vmlinuz-2.6.11-1.1369_FC4 ro root=/dev/VolGroup00/LogVol00 vga=794
 initrd /initrd-2.6.11-1.1369_FC4.img

This obviates setfont and gives me a nice field of CLI to play in without killing my eyes. So there you have it, the wisdom of the day: vga=794.

In related news, I was able to mail grub.conf over to the windows machine no problem.

apropos

2005-12-12T09:51:00.000-08:00

It takes about 12 seconds for me to start wondering about how my life is going to adapt to a 25-line console. Normally I'm 10 seconds from ssh'ing into the box and not having to deal with it. The FreeBSD box in the closet stares at me with my history of su's and ssh password failures from random internet creeps with a glow that only a pixellated DOS font can offer.

[root@localhost /]# apropos console|grep font

Okay, so 'setfont' exists in this *nix as well. Now there's always the dance of the "which font should I use?" This is always succeeded by "which font can I use?" Typing "setfont foo" is fun enough the first time you try it, but if you

[root@localhost /]# cd /lib/kbd/consolefonts

...there's like a jillion files in there, or at least it seems like a jillion because they're displayed 25 lines at a time.

The manpage for setfont uses an example with "cybercafe." Well that sounds cool. I'm a hip and Linux-installing guy who, while I've never actually been to a cybercafe, might actually blend into a place like that.

[root@localhost consolefonts]# setfont cybercafe

Now this is disgusting. I don't know how this ever made it into the distribution, but my eyes are starting to bleed. Imagine the first draft of the poster for a mediocre sci-fi movie, writ in senior-quality LARGE TYPE EDITION and you're getting an idea of what I wound up with. So, as the world of setfont goes, I have to loop through and check a million fonts until I get tired and just go with whatever has been the least crappy in the previous half-hour. The Peter Principle of screen typography.

Googling is no help. It's all manpages and problems. Someone (hint, hint) needs to come up with a page with images of all of these files. Would it be so hard? Heck, it could be the Rosetta Stone of the anti-GUI crowd. I See A Great Need.

First blush with Fedora 4

2005-12-12T01:27:00.000-08:00

So here we are. This blog is ostensibly about my travails with getting to know Fedora 4 Core. Fedora Core 4? I don't know, I'm a Windows guy by trade, and a FreeBSD guy by interest. 10 years or so I've been using the BSD with occasional forays into Slackware and Debian, always to get frustrated by their illogical layout. It's truly a cliche that FreeBSD just works, but here I am. I have some spare time lately so I figure I should get some Linux under my belt rather than muddling through whenever it comes up on the job.

Sitting around last night figuring out what I'm going to do with this spare box, I started to download OpenBSD to get a feel for the guts of BSD and the spirit of Theo. This came to a screeching halt once I realized that I would have to deal in some way with a floppy disk. None of my machines has one of these and my stance on this issue is irreconcilable with Theo's attitude toward the non-free aspects of bootable CDs. So be it.

What's next? Well, Linux is always breathing down my neck. Seeing as how it's everywhere I want to be, including powering the hamster-like doppelganger behind this blog service, perhaps it is time to tackle a piece of the Linux homestead. There, I said it. And I'm doing it. And here I am talking about it.

Thinking for two seconds I figured that Fedora core was the distribution I hear people mumbling about most often. RHEL is in there, too, but I couldn't figure out what ISO's to download by looking at RedHat's site, so I settled on Fedora 4. My lovely ISP, sonic.net, has mirrors of a zillion things, and RedHat's products are one of them. So I commence downloading ISOs. Two hours later I see that all three of them have taken up residence on my hard drive, yet when I parse the FTP site listing, I see that there are four ISOs comprising the Fedora 4 (gotta be F4 from now on, sorry Googlesearchers) distribution. That's okay, I always wanted a set of RedHat 9 CDs (whatever distribution or permutation of RH's offerings that might be). If this F4 thing doesn't work out we just may see what RH9 is all about, but for now it's gonna be a few more hours of sucking down ISOs. This is the part where I go to bed.

Next day, I commence installation. Step one is to drag out the cheapy KVM and hook it up to the box I normally sit at. I throw in CD1 of the F4 set and let it roll out. I play BSD expert and lay out some kind of groovy partitioning scheme that my intuition tells me would work. Luckily for my intuition, the box freezes halfway through and spontaneously reboots. I click the KVM over, see that there's some "Operating System not found" type error and blame the Athlon 1700. That fan looks pretty weak, you know. Three more attempts throughout the afternoon get me to various stages of freezing, once in the middle of kernel copying, another fully at the end of its installation process which mysteriously did not ask for CD2 or CD4 which it has assured me would be necessary for completion. A jumble of reboots all day, basically. Never mind that I was otherwise indisposed with the latest on the Plamegate story and tweaking of my Windows game rig (running your RAM at its rated 333MHz is quite an improvement over 266MHz, by the way).

Round midnight, I remembered that I had an 80-pin IDE cable in the front room, languishing next to a dozing case waiting to be freecycled. Normally this wouldn't be cause for interest, except that I had both the hard drive and the CD-ROM of this machine running off of the same cable. 10 minutes later, the machine had fully installed the server-install of F4 and I was now wondering how to change that dang console font. I have to look it up every time for FreeBSD too, so I guess it'll have to become part of my personal UNIX Rosetta Stone.

Beginnings and how to create smoke signals

2005-12-12T01:08:00.000-08:00

Step one in using a power supply of unknown provenance is to know what each of the wires does. Or at least the connectors. Most of the time with a standard ATX power supply it's fairly straightforward that some connectors are meant for the motherboard and others are destined for the various hard, floppy and disc drives in the system. Where you need to be careful is when there is a strange pair of wires with a jumper header on the end that looks for sure like it's supposed to be one of the "motherboard" cables. One of the big-block ATX power connectors' friends.

Sure, you RTFM, check and double-check the jumper diagrams to make sure this wire has a claim to its rightful place on the motherboard. "Thermal sensor" you see. This is a nice way of saying that there is sometimes a way for the motherboard to tell the powersupply to cut it out, to take a chill pill because there's enough juice to go around so it needn't be going off whole-hog. Sounds pleasant and simple enough until you try it.

If you've never forced a motherboard to generate smoke before, let me tell you that it's a strange experience. A world of wonder and confusion mixed with fear and stinky air. This stuff is surely toxic by way of one EPA regulation or another. It's at least part of the reason that Americans prefer to send their computer detritus to far-off countries in hopes that someone can get some value out of their garbage. Or at least die trying. Suffice it to say that if you're ingesting this stuff regularly, you might as well take up smoking so that you look cool doing it. It won't make a difference when your lungs are bloody stumps competing with your liver for white blood cells.

Safety tip: be sure you know where the power from the wall enters into the power for the computer system. This makes it easy to yank the life out of the smoke bomb you've just created at 1am on a Sunday night (Monday morning, really). The wisdom of the ages, handed down from generation to generation from back when the original IBM-PC would have taken up a hangar the size of Manhattan if it had been built with vacuum tubes (valves to the Limeys out there) and wire-wrapped coils. I'm sure those guys had a story or two about mismatched voltage and expectations thereof.