Recently in Linux Category

Adding Environment Variables Automatically On Login

This website:

Documents this solution to auto-adding proxy or environment information to your user's profiles or shells. This works for RedHat Enterprise Linux 6.2.

create the following files in /etc/profile.d, and then this will work in *any* shell for *any* user of the system
export http_proxy=
export ftp_proxy=
export HTTP_PROXY=
export FTP_PROXY=

setenv http_proxy
setenv ftp_proxy
setenv no_proxy
setenv FTP_PROXY

The files don't have to be set executable. When the next person logs in, those environment variables are automatically added to the user's environment, so the proxy is auto-configured for them.

Where did my hard drive go?

I've been trying to rsync a 1TB filesystem for a few days, mostly from firewire and most recently from USB. Running Firewire, here's what popped up in the logs:

[5776217.857647] Filesystem "sdb1": xfs_log_force: error 5 returned.

And of course, rsync bombed, there was gnashing of teeth, and the kernel/XFS weren't happy. /dev/sdb had disappeared. I tried moving it to a different controller (I have three firewire ports on that PC), and finally to USB with the same results every time... The drive/rsync would go for a while, then fail. And not recover. I reset the hard drive by unplugging the 12V power input cable from the back, and later noticed that simply unplugging it from firewire/USB was enough, provided I left it disconnected long enough for the devices to be deleted from /dev & friends. The drive was a Firewire/USB Western Digital MyBook drive I had borrowed. I haven't had a lot of faith in the devices since I bought a MyBook2 and found it was completely unable to be used as a boot device for a Mac. Unfortunately, that's the one sure-fire way to backup a Macintosh -- install Mac OSX to an external drive, then move over the applications and preferences of the users.

Here's the dmesg when I moved it to USB:

[5788570.588332] usb 5-6: new high speed USB device using ehci_hcd and address 8
[5788570.737577] usb 5-6: configuration #1 chosen from 1 choice
[5788570.742572] scsi25 : SCSI emulation for USB Mass Storage devices
[5788570.743242] usb-storage: device found at 8
[5788570.743246] usb-storage: waiting for device to settle before scanning
[5788570.744481] usb 5-6: New USB device found, idVendor=1058, idProduct=1112
[5788570.744486] usb 5-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[5788570.744489] usb 5-6: Product: My Book 1112
[5788570.744493] usb 5-6: Manufacturer: Western Digital
[5788570.744496] usb 5-6: SerialNumber: 574341563539313134373334
[5788575.820168] usb-storage: device scan complete
[5788575.826172] scsi 25:0:0:0: Direct-Access     WD       My Book 1112     1009 PQ: 0 ANSI: 4
[5788575.830661] scsi 25:0:0:1: Enclosure         WD       SES Device       1009 PQ: 0 ANSI: 4
[5788575.835334] sd 25:0:0:0: [sdb] 1952151552 512-byte hardware sectors (999502 MB)
[5788575.836495] sd 25:0:0:0: [sdb] Write Protect is off
[5788575.836495] sd 25:0:0:0: [sdb] Mode Sense: 23 00 10 00
[5788575.836495] sd 25:0:0:0: [sdb] Assuming drive cache: write through
[5788575.842777] sd 25:0:0:0: [sdb] 1952151552 512-byte hardware sectors (999502 MB)
[5788575.844493] sd 25:0:0:0: [sdb] Write Protect is off
[5788575.844493] sd 25:0:0:0: [sdb] Mode Sense: 23 00 10 00
[5788575.844493] sd 25:0:0:0: [sdb] Assuming drive cache: write through
[5788575.844493]  sdb: sdb1
[5788575.863526] sd 25:0:0:0: [sdb] Attached SCSI disk
[5788575.863650] ses 25:0:0:1: Attached Enclosure device

Then mounted the XFS file system..

[5788585.568840] XFS mounting filesystem sdb1
[5788586.331150] Ending clean XFS mount for filesystem: sdb1

And then when the device decided to go to sleep, doing 15MB/s.

[5790392.964797] usb 5-6: reset high speed USB device using ehci_hcd and address 8
[5790905.294369] usb 5-6: reset high speed USB device using ehci_hcd and address 8


I started doing some Googling, which lead me to a number of pages about
hdparm and sdparm.

This one gave me the basic idea, but the syntax didn't work except for "sdparm -al $device".

This command foreshadowed most of my investigation:

# sdparm -c STANDBY -6 /dev/sdb1
    /dev/sdb1: WD        My Book 1112      1009
change_mode_page: failed setting page: Power condition

This one provided some ideas and a little more clue.

This one proved exceptionally useful, once I got the syntax down and figured out how to set the flags and save them.

First I had to set the drive to auto_restart using :

"echo 1 > /sys/class/scsi_disk/$id/allow_restart"

# echo 1 > /sys/class/scsi_disk/25\:0\:0\:0/allow_restart
# echo 1 > /sys/class/scsi_disk/3\:0\:0\:0/allow_restart

Then set the STANDBY flag to zero, so the drive will start...

But first, I figured out how to set the SCT (Standby Timer) to a high value. It maxed out at 288000. 288000 in 100ms chunks is 28800 seconds, double of 14,400, which is one day.

# sdparm -al /dev/sdb
    /dev/sdb: WD        My Book 1112      1009
    Direct access device specific parameters: WP=0  DPOFUA=1
Power condition [po] mode page:
  IDLE        0  [cha: n, def:  0, sav:  0]  Idle timer active
  STANDBY     1  [cha: y, def:  1, sav:  1]  Standby timer active
  ICT         0  [cha: n, def:  0, sav:  0]  Idle condition timer (100 ms)
  SCT      6000  [cha: y, def:6000, sav:6000]  Standby condition timer (100 ms)

Well, that's no good. Set is -s, so let's see if that can be turned up.

# sdparm -s STANDBY=0 -6 --save /dev/sdb
    /dev/sdb: WD        My Book 1112      1009

# sdparm -al /dev/sdb
    /dev/sdb: WD        My Book 1112      1009
    Direct access device specific parameters: WP=0  DPOFUA=1
Power condition [po] mode page:
  IDLE        0  [cha: n, def:  0, sav:  0]  Idle timer active
  STANDBY     1  [cha: y, def:  1, sav:  1]  Standby timer active
  ICT         0  [cha: n, def:  0, sav:  0]  Idle condition timer (100 ms)
  SCT       288000  [cha: y, def:6000, sav:288000]  Standby condition timer (100 ms)

Bonus. But wait, that means that STANDBY can be set to 0, and saved...

# sdparm -s STANDBY=0 -6 --save /dev/sdb
    /dev/sdb: WD        My Book 1112      1009

No errors... looks good.

# sdparm -al /dev/sdb
    /dev/sdb: WD        My Book 1112      1009
    Direct access device specific parameters: WP=0  DPOFUA=1
Power condition [po] mode page:
  IDLE        0  [cha: n, def:  0, sav:  0]  Idle timer active
  STANDBY     0  [cha: y, def:  1, sav:  0]  Standby timer active
  ICT         0  [cha: n, def:  0, sav:  0]  Idle condition timer (100 ms)
  SCT       288000  [cha: y, def:6000, sav:288000]  Standby condition timer (100 ms)

The system started behaving as if the drive were online. Imagine my surprise when I switched terminals and found that rsync was happily copying data!  

So that's how you turn off the power management for a Western Digital MyBook portable hard drive.

Edit: It's not always effective. Sometimes it still refuses to wake up. But now it takes a long time to go to sleep. 

Resetting a DVD Burner gone wonky

After attempting to burn a DVD, I started receiving these messages in the log, and all over the root terminal. Naturally, this made it hard to be root and fix the problem.

Feb 18 22:19:31 secondlt kernel: [5643777.542654] hdb: status error: status=0x58 { DriveReady SeekComplete DataRequest }
Feb 18 22:19:31 secondlt kernel: [5643777.542659] ide: failed opcode was: unknown
Feb 18 22:19:31 secondlt kernel: [5643777.542719] hdb: status error: status=0x58 { DriveReady SeekComplete DataRequest }
Feb 18 22:19:31 secondlt kernel: [5643777.542724] ide: failed opcode was: unknown
Feb 18 22:40:19 secondlt kernel: [5645187.666411] hdb: status error: status=0x58 { DriveReady SeekComplete DataRequest }
Feb 18 22:40:19 secondlt kernel: [5645187.666411] ide: failed opcode was: unknown

Well, this wasn't made any easier because hald was polling that device every two seconds:

# ps -ax | grep "hal"
Warning: bad ps syntax, perhaps a bogus '-'? See
19265 ?        Ss     0:00 /usr/sbin/hald
19266 ?        S      0:00 hald-runner
19284 ?        S      0:00 hald-addon-input: Listening on /dev/input/event3 /dev/input/event2 /dev/input/event1
19292 ?        S      0:00 /usr/lib/hal/hald-addon-cpufreq
19293 ?        S      0:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
19298 ?        S      0:00 hald-addon-storage: polling /dev/hdb (every 2 sec)
19372 pts/1    S+     0:00 grep hal

So step 1 was to kill -HUP the hald process, 19298. Fortunately, it didn't come back. Next was to head into the man pages on hdparm and see if there was a flag that could reset the device. There is, it's "-w". The man page notes it is an extremely dangerous flag.

# hdparm -w /dev/hdb
device reset

Then restart hald:

# /etc/init.d/hal restart

Check the logs again:
Feb 18 22:40:19 secondlt kernel: [5645187.666751] hdb: DMA disabled
Feb 18 22:40:19 secondlt kernel: [5645187.714462] hdb: ATAPI reset complete
Feb 18 22:40:50 secondlt kernel: [5645221.270844] cdrom: This disc doesn't have any tracks I recognize!

Ok, that last one means I have a burnable DVD loaded and can restart the burning program.

This is all well and good, because I really didn't want to shut the virtual machines down to reboot the system.

Which brings me to another topic: always run ntpd on your virtual machines. When the system suspends them, they loose track of time. So much so that it may be easier to stop ntp, ntpdate, and then restart ntp after a reboot/suspend action.

VMotion is damn cool technology, but not worth the $50,000 if you're just lazy and don't care to take a chance with losing a system. OTOH, if you're doing VMotion, you already bought shared storage of some kind.

Packet Radio / TNCs


Speed is important. Baud rates are limited by law, but Baud doesn't equal signal rate; baud is the baseband. Using QPSK, you can double throughput, and you can still throw bits away in FEC if you need to. Phil Karn is a huge proponent of this and for good reason; he had a critical role in developing Qualcomm's satellite-based terminal systems used by truckers everywhere.

6m might be good for this, but easily obtained radios (Motorola Syntor Xs, GE Deltas, etc.) are starting to disappear. Also, they are large, and without a small TNC/node hardware that fits inside the radio, there is little reason to deploy equipment because more parts can break. Of course, the radios themselves need about 30A on transmit, so that would also need to be dealt with in a manner that doesn't impact size and site power requirements.

There's very little reason why we can't push soundcard packet into smaller systems like the Alix line of micro-PCs. We can dedicate an Arduino to software packet detection, another to node/routing, and pass the data on to a host if need be. Or we can load the sound-card engine into memory as a TSR and boot the thing using DOS and a G8BPQ stack. With TNC-X, a KISS TNC, it's possible to do that and more. Ideally, speeds upwards of 19200 and full-duplex are desired. However, full-duplex generally requires real hardware on the "node" side of things, and duplexers are a generally fixed commodity.

Also, proxy ARP may be a better way to use TCP/IP over AX.25, stealing information directly from the NETROM maps or something. For instance, my state net is 44.100.x.x, but good luck trying to actually get any of that to route outside of

Really, something closer to the mesh-networking systems used for the next generation wireless networking systems would be better. To gracefully handle losing a node and multiple routes present in the network stack. You can't really do that on a Z80 with 16k of RAM at 10 MHz.

IPv6 needs to be implemented at some point, with a graceful handling of IPv6 addresses to allow for compacting unnecessary zeros.

Software TNCs/Minimal TNCs:





Packet general:
Buck's articles: (look down on the left-hand side)

Ham general:

- IP use in TheNet nodes:
 - TheNet replaced by NOS:
 - JNOS:
 INP something. I dunno...
edit: Ah, here it is. A European internode protocol:
Intro to NOS: (packet sizes, numbers)

DX cluster:


Old Huntspac stuff:

Most of the older stuff I saw fall out of use as people got older and fell into different modes / cliques / clubs

Linux, oh Linux, the bane of my existence

At $dayjob, we, like so many other companies use FibreChannel LUNs to provide stable, dependable storage to servers. From organization to organization, the use of LUNs varies. Some organizations simply place the file system on the raw device, others insist on a BSD disklabel or DOS partition table. In the Solaris world, the disk may be equipped with a disklabel and a several character label which the format command displays with the disk description.

As a part of a routine server deployment, I had several small LUNs 'attached' to several servers in a one-to-one configuration. However, after mkfs'ing the raw device, I discovered that the manager's preference was to install a DOS partition table and mkfs the partition. While updating the LUN to match the manager's expectations, I skipped over updating /etc/fstab accidentally, and issued the always fateful "reboot" command. The system came back up, failed to check /dev/sdc, and promptly ceased booting, waiting for the root password to proceed to maintenance mode. After entering the root password, I found I could not update /etc/fstab because the filesystem was mounted read-only. vim was very aware of this, as were command-line tools (e.g.: touch), but mount reported that the root filesystem was mounted read-write. After a few minutes of Googling and searching the old neural filing cabinets, I arrived on a few operands to place in the kernel line while booting from GRUB:

and so on.

But none of these delivered the result I was seeking. I needed the root to be read-write, and I was NOT going to search out a CD to boot from. Booting from the CD would have allowed me to use 'rescue' to mount the filesystem read-write and update /etc/fstab, but I adamantly knew in my brain that there was NO WAY that it was acceptable to *have* to have a Linux CD on hand to fix the problem.

Back to the Googles, I struck a bit of magic with some keywords. The magic phrase is this:

mount -t ext3 -o remount,rw /

Once completed, vim would edit the file, save the changes, and allow the system to be returned to service without performing some hack to boot the CD image on the server.

I picked up a few other things along the way:

fdisk /dev/sdc
mkfs -t ext3 -v 1 /dev/sdc1
tune2fs -i 10000 /dev/sdc1

(add LUN to /etc/fstab as /slice)
mkdir /slice
fsck -p /dev/sdc1
mount /slice

/slice would be the name in /etc/fstab for the LUN

mkfs -v 1 sets the free space percentage kept by root to 1% of the disk space. I set this because our users usually fill the disk and keep it full.

tune2fs -i 10000 sets the fsck interval to 10,000 days. As a fan of the band Tool, I know that this is a period of time of some twenty-seven years; at the least this directive, while not recommended, will keep the system from pausing on startup for an unexpected fsck.

Experience has shown that these fscks always happen at unanticipated times, especially when the system must be returned to service as soon as possible. '

Good luck, keep calm, and carry on.

The Worst Possible Idea Must Be Implemented

No, I don't mean this in a sarcastic sense. I mean that when you have the worst possible idea, you must implement it. In my case, it was while building a Jumpstart server after building a Kickstart server. I have a Dell Optiplex GX1p (450MHz) missing most of the plastic (so it's really more of a Dell T1000 Optiplex). While DBAN'ing any number of SCSI and IDE hard drives (of almost every interface variety imaginable), the Optiplex would routinely reconfigure it's BIOS to change the boot order. After enough times of overriding it and seeing the PXE boot banners go by, I figured, what the hell?

Download pfSense, Debian Linux, setup a router and firewall in a virtual machine and provision another DHCP and TFTP server for PXEBOOT. Download a copy of DBAN. Put in blender. Three days later (and all typos removed one by one), I have DBAN in the boot menu for the PXEBOOT server. And it's set for auto-timeout. Yes, the worst possible idea must be implemented. Plug into my network and don't ask me, hope that you don't have your box configured to PXEBOOT. >=D

Original idea comes from Joako  over at DSL Reports and this post:

However, I found I kept having issues with DBAN booting. Finally, I cut it down to as few menu items as possible:

label DBAN
        kernel dban/dban.bzi
        append nuke="dwipe"

label DBANautonuke
        MENU LABEL DBAN Autonuke
        kernel dban/dban.bzi
        append nuke="dwipe --autonuke" silent

And thus it was dangerous. Once ONTIMEOUT is set to DBANautonuke and DEFAULT set to DBANautonuke, only the TIMEOUT value saves you. Timeout is in tenths of seconds, so a TIMEOUT of 200 is 20 seconds.

So the recap here is that you configure a PXEBOOT server in your favorite fashion (everyone uses different paths, pick a tutorial (RedHat, IBM, etc.) and go through it), mount the DBAN CD on a mountpoint (/media/cdrom or /mnt or /cdrom or whatever) and copy over the contents of the CD to your tftpd home directory. I tar'd the files up into a dban.tgz tarball and put them into a directory named "dban". dban/isolinux.cfg tells you everything you need to plug into the pxelinux.cfg/default file for menu.c32 to know about.

Good luck, and happy trails.

The other fun part of this was configuring pfSense to do some routing and firewall work. Where I usually work, DHCP server are verbotten, so one must take a few precautions to make sure that evil DHCP packets aren't forwarded. Also, if there is a internet-facing port, one must take pains to assure that packets go in the correct direction. Download pfSense install CD image, fire up VMWare; install pfSense to the hard drive of the virtual machine. Give the virtual machine four interfaces; LAN, WAN, OPT1, and OPT2. LAN is, WAN is the internets feed, and OPT1 is a /30 ( to the ethernet switch ( for out-of-band management. pfSense handles the NAT and knows about routing.

In another virtual machine, a Debian Linux server sits with two ethernet cards. But I ran out of ethernet ports on the physical hardware, so the PXEBOOT server is a one-armed router. To accomplish this feat against ISC-DHCPD3's best wishes, I had to think a bit.

My first hurdle was getting interface aliases configured to start automatically in Debian. Not so difficult with The Googles:


iface eth0 inet static
    dns-search lan

auto eth0:1
iface eth0:1 inet static

So is the pfSense router (with DHCP turned off and DNS Forwarder on), is the "outside" IP of the PXEBOOT server, and is the "inside" IP of the PXEBOOT server.

Then DHCPD had to complain:

pxeboot:/etc/dhcp3# /usr/sbin/dhcpd3
Internet Systems Consortium DHCP Server V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit
Wrote 3 leases to leases file.
Interface eth0 matches multiple shared networks

What the deuce?

Googling was marginally useful. I've seen this problem before however. I couldn't remember what the exact reasoning behind why it behaves this way, but I remembered reading a message from Paul Vixie about it that explained the rationale or behavior. And I believe it was a compile time option or some oddball flag that one had to set to get rid of the error message. After racking my brain for a bit, I settled on the idea that DHCPD had too much information. So I commented out the first subnet definition (

#subnet netmask { }
subnet netmask {
        default-lease-time 14400;
        max-lease-time 38400;
        option subnet-mask;
        option broadcast-address;
        option routers;
# comment below out if the machine's name will be something else.
        option domain-name "lan";
        filename "pxelinux.0";

Of course, the PXEBOOT server still has the default route set to, so if packets get there, pfSense should know what to do with them (and if it doesn't, I don't care because this server was designed for DEATH ;). In all seriousness, this server will have to coexist in the near future with a Jumpstart server, so the ability to alter DHCP capabilities is welcomed.

So the PXEBOOT server is a one-armed router/DHCP server, serving out DHCP for a network that isn't routeable while another network on the same wire is.  And the pfSense firewall provides inward connectivity for SSH, while keeping off-LAN users out. Through the OPT1 interface, some NAT work and a firewall rule, telnet and the web interface for the HP Procurve 4000 are made accessible to the LAN, while denying remote users the ability to get to it.

Some of the complicated stuff I enjoy, other things I needlessly complicate. But for good reason. =D

Open Source software is worth what you pay for it

Going about my daily thing, working on building a RHEL 6 PXE boot server when I ran into an issue with Kickstart and wanted to check a few things out. First I installed system-config-kickstart, which (finally) pulled X in, bringing along 88MB and 196 packages of dependencies. Glad to see *that* hasn't changed in UNIX work. /sarcasm. Fire up system-config-kickstart and I'm greeted with boxes where the letter should be, and this cryptic message:

/usr/share/system-config-kickstart/ PangoWarning: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='common'

What the hell? At least that was somewhat truthful: the output was ugly as hell. So much for modern OSes getting all the crufty bits out of the way. Off into /etc/fonts/fonts.cfg I went and added


To the directories part, then ran fc-cache. Magically, sh*t starts working.

The actual cause of the error is that Pango V1.24 isn't compatible with previous version of Pango. This has actually caused that error to match almost every platform imaginable, as it breaks anything that might want to use fonts, like GD, rrdtool, and cacti.

Normally, I'm more verbose, but if you run into this error, you probably just want the solution, so here it is. By the way, this was on RedHat Enterprise Linux Server 6 (RHEL 6). There, I just saved you 20 minutes of googling at $250/hr.

VMWare Tools on Debian 6 / gcc bug

VMWare's ESXi 4.1 Hypervisor and Debian 6 didn't quite want to cooperate when it came to installing VMWare Tools. A little Google-Fu brought out this gem:

But what you need to know is this:

# aptitude install linux-headers-$(uname -r)  build-essential

After running that, will execute without halting for gcc issues.

The Moving Ethernet Interface

I've experienced the phenomenon of a moving Ethernet interface more than twice on more than two Linux distributions. Of course, since they are both using the same kernel, it is somewhat understandable. What is not immediately understandable is how each of those successive distros choose to address or solve the problem.

Since one of the distros was proprietary, I solved the problem with a second CAT5 patch cable to the common core switch. On RHEL, this is easy enough to solve, but at the moment I can't remember how I did it.  On Debian, the following resource was useful: Basically, go into /etc/udev/rules.d/70-resistent-net.rules and look for your ethernet card entries. In my case, I looked for eth3 since eth0's MAC Address was in a physically identical server that I swapped my server out for. When the new MAC Address was detected on eth0, udev decided that it should use eth3 since eth0 might come back. Nice thought, but since I'd swapped the entire chassis, eth1 should have changed as well. Yet that didn't quite seem to happen.

Change eth3 to eth0, remove original eth0 line, reboot... done.


One of the entities for whom I regularly do work has requested that a server of theirs uses LDAP for authentication, and not the local password file. However, the system depends on the files to provide the user information (home directory, uid, gid, and so on). While the process has been documented in previous versions of RHEL, the process was again changed in RHEL 5. One of the fundamental requirements was that any access to LDAP use encryption. To this end, it was determined that the TLS method was sufficient, and supported by the LDAP vendor. The customer further dictated that the password changes would be implemented through a different mechanism. In RHEL 3 and RHEL 4, this alters the /etc/pam.d/system-auth file, adding or uncommenting the following primitives which have been highlighted:

# Redirect users to a URL or somesuch on password
# changes.
#pam_password_prohibit_message Please visit http://internal to change your password.
# OpenLDAP SSL mechanism
# start_tls mechanism uses the normal LDAP port, LDAPS typically 636
#ssl start_tls
#ssl on

In RHEL 5, these primitives have been moved to the /etc/ldap.conf file.  So to effect the same change, update /etc/ldap.conf, not /etc/pam.d/system-auth.

About this Archive

This page is an archive of recent entries in the Linux category.

Hacker is the previous category.

Maker is the next category.

Find recent content on the main index or look in the archives to find all content.