Tag Archives: linux

istatd, rhel5, init.d and me

Posted on by
Reply

Recently, while configuring two new RHEL5 webserver nodes at VSU, I decided to install the Linux server for the iStat program.  The iStat program is an iPhone app that will allow you to receive vital stats on your remote servers.  It also gives you a nice interface for both the ping and traceroute network tools.

The installation of the istatd daemon, an open source server for Linux, Solaris and FreeBSD, was quite easy.  The configuration file is easily understood and edited for your particular installation needs, allowing you to change the defaults when necessary, for example I did not want to add an additional user, so I configured istatd to use the monitor account I created for use with Nagios.

One thing that was missing from istatd was an init script to allow for easily controlling the startup and shutdown of the daemon as well as determining what runlevels the daemon should be active in.

To solve this I wrote an init.d script.  These scripts are fairly self-explanatory.  I used the script that starts the xinetd service as my base, since I knew that this one checks to ensure that the networking service is active before it starts the service.

The location of both the binary and the configuration file may vary depending on the installation itself. When I built istatd I used the following configure command:

./configure --sysconfdir=/etc

Here’s how to install the script

  1. Copy the file into /etc/init.d/ 
    cp istatd /etc/init.d/
  2. make a symbolic link to this file in the rc.d directories for each runlevel specified in the script (note: this may differ based on the runlevels you use in the script.) 
    ln -s /etc/init.d/istatd /etc/rc3.d/S99istatd
ln -s /etc/init.d/istatd /etc/rc4.d/S99istatd
ln -s /etc/init.d/istatd /etc/rc3.d/S99istatd

Here is the script in it’s entirety, and you can download it as well.

#!/bin/bash
#
# istatd        This starts and stops istatd.
#
# chkconfig: 345 99 01
# description: istatd is a daemon serving statistics to your \
#              iStat iPhone application from Linux, Solaris & FreeBSD. \
#              istatd collects data such as CPU, memory, network and \
#              disk usage and keeps the history. Once connecting from \
#              the iPhone and entering the lock code this data will be \
#              sent to the iPhone and shown in fancy graphs.
#
# processname: /usr/local/bin/istatd
# config: /etc/istat.conf
# pidfile: /var/run/istat/istatd.pid
 
# Source function library.
. /etc/init.d/functions
 
# Get config.
test -f /etc/sysconfig/network && . /etc/sysconfig/network
test -f /etc/istat.conf
 
# Check that we are root ... so non-root users stop here
[ `id -u` = 0 ] || exit 1
 
# Check that networking is up.
[ "${NETWORKING}" = "yes" ] || exit 0
 
[ -f /usr/local/bin/istatd ] || exit 1
[ -f /etc/istat.conf ] || exit 1
 
RETVAL=0
 
prog="/usr/local/bin/istatd"
 
start(){
    echo -n $"Starting istatd: "
 
    $prog -d --pid=/var/run/istat/istatd.pid
    RETVAL=$?
    echo
    touch /var/lock/subsys/istatd
    return $RETVAL
 
}
 
stop(){
    echo -n $"Stopping istatd: "
    killproc $prog
    RETVAL=$?
    echo
    rm -f /var/lock/subsys/istatd
    return $RETVAL
 
}
 
reload(){
    stop
    start
}
 
restart(){
    stop
    start
}
 
# See how we were called.
case "$1" in
    start)
     start
     ;;
    stop)
     stop
     ;;
    status)
     status $prog
     ;;
    restart)
     restart
     ;;
    reload)
     reload
     ;;
    *)
     echo $"Usage: $0 {start|stop|status|restart|reload}"
     RETVAL=1
esac
 
exit $RETVAL

If you need any assistance creating your own scripts, you might find this link from Novell’s Cool Solutions site: Creating Custom init Scripts.

RHEL5 Password Policy Enforcement

Posted on by
Reply

Image Credit: Ohio State University

Yesterday in my post on Solaris 10 Password Policy Enforcement, I outlined the steps necessary to implement the password requirements that have been decided upon in my system environment.  This post will outline the same process on the RHEL5 systems that I admin.  While the policy requirements are the same, the implementation is vastly different.

Desired Policy

To re-cap, here is the policy that is to be applied to normal users:

  • at least 8 characters in length
  • no more than 20 characters in length
  • contain at least on letter
  • contain at least one number
  • forced to change at least every 180 days
  • 15 minute lockout after 5 unsuccessful attempts

Implementation Differences with Solaris 10

While there were a couple of pieces of the desired password policy that I was unable to implement on Solaris 10, the ease of which the others were configured wins the game hands down.  The PAM module setup on Solaris makes it dead simple to update the policy.  All you have to do is to change the various tunable settings.  And they are all listed in fairly understandable verbiage, no complex or arcane settings.

On the RHEL5 systems I had to delve into the vagaries of PAM module attributes and ordering.  As always, it is important to make backups of any files to protect yourself and allow for disaster recovery. To implement the requirements, I had to edit two files on the system:

  1. /etc/login.defs
  2. /etc/pam.d/system-auth

Implementation Process

It is important during this process to recognize that if you set the PAM requirements incorrectly you can get burned to the point that the root user will be unable to login, forcing you to boot into single-user mode to recover or to boot the system from a live cd and revert the authentication files.

Setting the password expiration requirement and length setting

Before we get into this please note the warning notice from the login.defs file manpage on a RHEL5 system

Much of the functionality that used to be provided by the shadow password suite is now handled by PAM. Thus, /etc/login.defs is no longer used by programs such as: login(1), passwd(1), su(1). Pleaserefer to the corresponding PAM configuration files instead.

It is still important to configure the password length in the login.defs file so that we can account for legacy codebases.

  1. Open /etc/login.defs in your favorite editor
  2. Set the attribute of PASS_MAX_DAYS to be 180
  3. Set the attribute of PAS_MIN_LEN to be 9

Setting the password complexity requirements

Now here is where the going gets real interesting.  Before we look at /etc/pam.d/system-auth a strong caution

Backup up the file before you alter it and open a backup terminal session as the root user before continuing.  If you put the wrong attributes in place or put the PAM directives in the wrong order you will lock yourself, root user and all, out of the system.  At that point you have two options: single user mode recovery from the console or use a live cd to boot the machine and revert to the backup after mounting the filesystem.  Oh, and it is wise to give yourself a delay with either GRUB or LILO because without the delay you won’t be able to change the boot option to allow the single user mode recovery option.

So, the file involved in this process is /etc/pam.d/system-auth and before I go into some of the nitty gritty, here’s the configuration I ended up using:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        required      pam_tally2.so deny=6 unlock_time=900
auth        sufficient    pam_unix.so nullok try_first_pass nodelay
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so
 
account     required      pam_unix.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so
account     required      pam_tally2.so per_user
 
password    required      pam_passwdqc.so min=disabled,disabled,12,9,9 max=20 similar=deny enforce=users retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so
 
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

The retries requirement is implemented using the following line

auth        required      pam_tally2.so deny=6 unlock_time=900

The complexity and length requirements are implements using the following line

password    required      pam_passwdqc.so min=disabled,disabled,12,9,9 max=20 similar=deny enforce=users retry=3

The following line is set to ensure that the retries count is maintained even if the counter for the pam_tally2 module is corrupted

account     required      pam_tally2.so per_user

References

Rather than go into the details of each individual attribute and how they interact, here are the resources used to develop this ruleset.  They contain an large amount of valuable information.

  1. http://wiki.centos.org/HowTos/OS_Protection#head-c6bf533e4f6de1ff3e13d556053fc40bc121e5cc
  2. http://www.openwall.com/passwdqc/README.shtml
  3. http://www.puschitz.com/SecuringLinux.shtml#LockingUserAccountsAfterTooManyLoginFailures
  4. http://www.linux.com/archive/feature/113807

Openfiler LVM to RAID conversion

Posted on by
Reply

As many of your know, I have a Plex-based Mac Mini media center setup which has enabled me to to the cord with the cable monopoly. Part of this setup is the Openfiler NAS that I use to store all of the digital copies of my dvd collection.

Lately I have been wishing that I had configured the NAS with a RAID setup instead of just using an all-eggs-in-one-basket approach with three drives in a LVM configuration. In the process of cleaning out a bunch of videos that I was never going to watch I managed to free enough space to be able to disband the existing volume group and setup my two 1TB drives in a RAID 1 set. The happy result was that I was also able to re-purpose the 500GB drive for use with my ever growing iTunes library. (Thanks, Apple and Steve Jobs for making all my music DRM free!)

The problem I ran into was that Openfiler will not allow you to create a RAID set in a degraded state. This was necessary to enable me to work with the drives I owned and not spend additional funds. After discovering this I began investigating the possibility of doing the RAID configuration by hand and completing the rest of the setup in the Openfiler web console. Here is the process I used.

A few steps were left out, mainly the pieces revolving around moving the data from one logical volume to the other then pruning the volume group of the old volume. Excpet for the copy process, all of this can be easily accomplished in the Openfiler web console. The only piece that I couldn’t easily determine from the console interface was which physical devices were used in which logical volume. That information can be easily found using the following command:

[root@mangrove ~]# lvdisplay -m

Create the RAID 1 set with a missing drive and prepare the physical volume

Step 1: SSH as root into your Openfiler setup

arfore$ ssh root@192.168.2.55

Step 2: As root, partition the RAID member using fdisk. You will want to create a single, primary partition. Accept the defaults on the partition size so that it uses the whole drive.

[root@mangrove ~]# fdisk /dev/sda
 
The number of cylinders for this disk is set to 121601.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
 
Command (m for help): n
Command action
e   extended
p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-121601, default 1):
Using default value 1
Last cylinder, +cylinders or +size{K,M,G} (1-121601, default 121601):
Using default value 121601

Next change the partition type to be Linux raid autodetect (Note: the hex code is fd)

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): fd
Changed system type of partition 1 to fd (Linux raid autodetect)
 
Now exit saving the changes.  This will write the new partition table to the drive.
 
Command (m for help): w
The partition table has been altered!
 
Calling ioctl() to re-read partition table.
Syncing disks.

Step 3: Create the RAID 1 set using your newly partitioned drive. Normally when creating a RAID 1 set you would specify two drive since this minimum number for a RAID 1 set in a clean, non-degraded state. However in our case we need to start out with a set containing one drive, which will show up in Openfiler as a RAID 1 set in a clean, degraded state.

[root@mangrove ~]# mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 missing

If it all worked, you should see the following result from the mdadm command:

mdadm: array /dev/md0 started.

To check the status of your newly created RAID 1 set, execute the following command:

[root@mangrove ~]# cat /proc/mdstat

The result should look like this:

Personalities : [raid6] [raid5] [raid4] [raid10] [raid1]
md0 : active raid1 sda1[0]
      976759936 blocks [2/1] [U_]
 
unused devices:

What this means is that your system supports RAID levels 1, 4, 5, 6, and 10. By extension this means it also supports RAID level 0. The [2/1] entry on the md0 line means that your RAID set is configured for two devices, but only one device exists. In a clean, non-degraded state, a RAID 1 set would show [2/2].
Step 4: Initialize a partition (in this case the RAID 1 partition) for use in a volume group.

[root@mangrove ~]# pvcreate /dev/md0

If the command completed successfully, you should see the following result:

Physical volume "/dev/md0" successfully created

Create the Volume Group and Logical Volume

Note: The next parts are done in the Openfiler web console.

Step 1: First check the status of your RAID set by selecting the Volumes tab then clicking on Software RAID in the Volumes section.

Step 2: On the Software Raid Management screen you will see your new RAID 1 set listed with a state of Clean & degraded. Normally, this would indicate a possible drive failure, however in this instance it is expected.

Step 3: The next step is to create a new volume group using the physical volume created during the previous command line steps. Click on the Volume Groups link in the Volumes section.

Create your new Volume Group and select the physical volume to be added to the group. Then click the Add volume group button.

Notice that now your new volume group shows up in the Volume Group Management section.

Step 4: Next you need to add a new volume to your newly create volume group. You can do this on the Add Volume screen. Click on the Add Volume link in the Volumes section.

On the Add Volume screen, setup your new volume and click the create button. The suggestion from Openfiler is to keep the default filesystem (which currently is xfs). Also, make sure to increase the volume size or Required Space to create the desired volume. In my case I am going to select the maximum available space.

The system now sends you to the Manage Volumes screen which will show you that you now have a volume group containing one volume.

At this point you can copy all your data over from the old LVM setup into the new LVM with RAID 1 setup. This may take some time. In my case, given that may hardware is far from the latest and greatest, it took just over an hour to copy 900GB of data.

Adding the empty drive to the RAID 1 set

The next steps assume that you have migrated your data from the last remaining volume group from the old setup into you degraded RAID 1 set. At this point what we are going to do is to add the free disk into the RAID set and start it syncing the disks.

Step 1: The first thing you need to do is to make sure that the partitioning structure of the new disk matches the structure of the RAID 1 member. In a RAID set the parition structure needs to match.

This can be easily accomplished using the following command:

[root@mangrove ~]# sfdisk -d /dev/sda | sfdisk /dev/sdb

The output from the command should look something like this:

Checking that no-one is using this disk right now ...
OK
 
Disk /dev/sdb: 121601 cylinders, 255 heads, 63 sectors/track
Old situation:
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0
 
   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sdb1          0+ 121600  121601- 976760001   fd  Linux raid autodetect
/dev/sdb2          0       -       0          0    0  Empty
/dev/sdb3          0       -       0          0    0  Empty
/dev/sdb4          0       -       0          0    0  Empty
New situation:
Units = sectors of 512 bytes, counting from 0
 
   Device Boot    Start       End   #sectors  Id  System
/dev/sdb1            63 1953520064 1953520002  fd  Linux raid autodetect
/dev/sdb2             0         -          0   0  Empty
/dev/sdb3             0         -          0   0  Empty
/dev/sdb4             0         -          0   0  Empty
Warning: no primary partition is marked bootable (active)
This does not matter for LILO, but the DOS MBR will not boot this disk.
Successfully wrote the new partition table
 
Re-reading the partition table ...
 
If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes:  dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)

As long as the process doesn’t throw any wonky error messages then you are good to move on to the next step.

Step 2: Now we need to add the disk /dev/sdb into the RAID 1 set /dev/md0.

[root@mangrove ~]# mdadm --manage /dev/md0 --add /dev/sdb1

If the command completes successfully, you will get the following result:

mdadm: added /dev/sdb1

Step 3: At this point the system show automatically begin syncing the disks. To check on this run the command:

[root@mangrove ~]# cat /proc/mdstat

The result show look like so:

Personalities : [raid6] [raid5] [raid4] [raid10] [raid1]
md0 : active raid1 sdb1[2] sda1[0]
      976759936 blocks [2/1] [U_]
      [>....................]  recovery =  0.0% (535488/976759936) finish=182.3min speed=89248K/sec
 
unused devices:

Notice that it now shows that the RAID 1 set is in recovery mode. This indicates that the set is in the process of being synchronized. During this process the data shown on the RAID Management screen in the Openfiler web console will show that the state of the RAID is Clean & degraded & recovering. It will also show the progress of synchronization.

Step 4: Once the RAID set has finished syncing the mdstat results will look as follows:

[root@mangrove ~]# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] [raid10] [raid1]
md0 : active raid1 sdb1[1] sda1[0]
      976759936 blocks [2/2] [UU]
 
unused devices:

As you can see, the RAID identity now shows that there are 2 volumes in the set with /dev/sda1 being the primary and /dev/sdb1 being the mirror. Also, it now shows that there are 2 fully synced disks, indicated by [2/2] [UU].

In the Openfiler web console the RAID Management screen now shows the state of the array as Clean with a sync status of Synchronized.

Final Steps

Step 1: Now that you have a completely clean RAID 1 set you will need to ensure that the /etc/mdadm.conf file has the correct information concerning the array. Normally this is created automatically for you by the Openfiler administration tool, however since we built the array by hand we will need to add this information into the existing file. (Note: backup the existing mdadm.conf file!)

This can be accomplished by the following commands:

[root@mangrove ~]# cp /etc/mdadm.conf /etc/mdadm.conf_orig
[root@mangrove ~]# mdadm --examine --scan >> /etc/mdadm.conf

The mdadm.conf file now contains the following (Note: the UUID entry will be unique to your system):

#
# PLEASE DO NOT MODIFY THIS CONFIGURATION FILE!
#   This configuration file was auto-generated
#   by Openfiler. Please do not modify it.
#
# Generated at: Sat Jul 24 19:43:42 EDT 2010
#
 
DEVICE partitions
PROGRAM /opt/openfiler/bin/mdalert
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=542fa4dc:c920dae9:c062205a:a8df35f1

Testing the RAID set

Testing the RAID set is the next step that I would recommend. Now, if something really bad(TM) goes wrong here, then you could end up losing data. If you are extremely worried, make sure that you have a backup of it all somewhere else, however if you don’t actually test the mirror then you don’t know that it all works and then you could be relying on a setup that will fail you when you need it the most.

Step 1: Get the details of your existing RAID set first prior to testing the removal of a device, that way you will have something to compare it to.

[root@mangrove ~]# mdadm –detail /dev/md0

This should yield some valuable data on the health of the array.

/dev/md0:
        Version : 00.90.03
  Creation Time : Sat Jul 24 19:55:44 2010
     Raid Level : raid1
     Array Size : 976759936 (931.51 GiB 1000.20 GB)
  Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent
 
    Update Time : Sun Jul 25 13:41:07 2010
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0
 
           UUID : 542fa4dc:c920dae9:c062205a:a8df35f1
         Events : 0.3276
 
    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1

Step 2: The next step is to actually remove a device from the array. Now, since /dev/sda was the initial disk I put into my set, I am going to remove it and see what happens.

To remove the device from the array and mark it as failed, use the following command:

[root@mangrove ~]# mdadm --manage --fail /dev/md0 /dev/sda1

You should receive the following result:

mdadm: set /dev/sda1 faulty in /dev/md0

Step 3: Check the status of the array by using the following command:

[root@mangrove ~]# cat /proc/mdstat

You will see that the device /dev/sda1 is now marked as failed and that the status of the array is degraded:

Personalities : [raid6] [raid5] [raid4] [raid10] [raid1]
md0 : active raid1 sdb1[1] sda1[2](F)
      976759936 blocks [2/1] [_U]
 
unused devices:

Also, in the RAID Management screen in the Openfiler web console you will see the state of the array change to be Clean & degraded.

Step 4: The next step is to test the mirroring of the data. What you should do now is to remove the drive that you marked as failed, then add the drive back into the mirror. In a real world scenario you would also replace the actual drive itself, however that is not necessary in this test. Also, if you were replacing the actual drive you would need to repeat the duplication of the partitioning structure.

First, remove the failed drive from the set /dev/md0 using the following command:

[root@mangrove ~]# mdadm --manage --remove /dev/md0 /dev/sda1

The result that you get back will show a hot remove since this command was executed while the system was live. In an enterprise environment where the storage array supported hotplug devices you could then replace the failed drive without shutting the system down.

Next, add the new drive into the array like so:

[root@mangrove ~]# mdadm --manage --add /dev/md0 /dev/sda1

The result from this command will be:

mdadm: re-added /dev/sda1

Step 5: If nothing has gone horribly wrong with the test, the array will now begin the mirroring process again. As you can see from the output of mdstat, the recovery process will be indicated in the same manner as the initial mirror was:

[root@mangrove ~]# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] [raid10] [raid1]
md0 : active raid1 sda1[2] sdb1[1]
      976759936 blocks [2/1] [_U]
      [>....................]  recovery =  0.0% (834432/976759936) finish=175.4min speed=92714K/sec
 
unused devices:

Note: this is not a smart recovery process. When you break the mirror, the entire mirroring process has to complete, even if it was a test where the data had not actually disappeared. As you can see, the recovery process is going to take about the same length of time that initial build of the mirror did.

Also, in the RAID Management screen, the state of the array will now be shown as Clean & degraded & recovering, just as before when we built the mirror in the first place.

Step 6: Once the mirroring process of the testing has completed, the results of mdstat should look similar to the following:

Personalities : [raid6] [raid5] [raid4] [raid10] [raid1]
md0 : active raid1 sda1[0] sdb1[1]
      976759936 blocks [2/2] [UU]
 
unused devices:

If you had actually replaced a drive you might need to update mdadm.conf to reflect the changes. At the very least it is wise to run the scan command again to ensure that the UUID of the array matches the file after the rebuild has completed.

Final Thoughts

One of the big lessons that I learned from this whole process, both using Openfiler and with handling storage arrays in general, is that more thought and planning on the frontend can save you a lot of tedium later. Had I initially planned my storage setup, I would have configured the drives in a RAID 1 set in the beginning. Another thing I learned is that while managing your NAS with an appliance type of setup (whether you use ClarkConnet, FreeNAS or Openfiler) is a great convenience, it doesn’t give you the insight and understanding that can be gained by doing everything, at least once, the manual way. I now have a much better understanding of how the software raid functions work in Linux and of the LVM process as a whole.

References

This whole process would have been much more difficult had it not been for the input of a friend as well as a series of postings on the Internet. Thanks, Joe for your help on this, given that it was my first foray into software raid on Linux.

  1. InstallationRAID1+LVM. Ubuntu Community Documentation, https://help.ubuntu.com/community/Installation/RAID1%2BLVM.
  2. Managing Physical & Logical Volumes. Jeffrey M. Hunter, Senior DBA at The DBA Zone, Piitsburgh, PA, http://www.idevelopment.info/data/Unix/Linux/LINUX_ManagingPhysicalLogicalVolumes.shtml.
  3. Linux Create Software RAID 1 (Mirror) Array. nixCraft, Vivek Gite, http://www.cyberciti.biz/faq/linux-creating-software-raid-one-arrays/.
  4. How To Set Up Software RAID1 On A Running System (Incl. GRUB Configuration) (Debian Etch). HowtoForge Linux Howtos and Tutorials, Falko Timme, http://www.howtoforge.com/software-raid1-grub-boot-debian-etch.
  5. various linux man pages on the LVM and mdadm commands

Xephyr, RHEL5 and Mac OS X 10.5

Posted on by
Reply

When doing system administration it is often more convenient to connect to a server through some sort of remote connection setup rather than having to sit at a console in a datacenter.  The comfort of one’s office (or living-room) is often far superior in terms of noise and temperature than the environs of the datacenter itself.

When setting up the RHEL5 server this week here at VSU, I was forced to use the Sun iLOM connection to do the initial install of the server.  While I generally use command-line only tools, the ease of use one gains from the GUI tools can often make some tasks much simpler.  Towards this end I decided to setup the server and my client to allow XDMCP sessions so that I could have full access to the GUI when necessary.

On the server there are a couple of things that you need to configure in order to make this workFirew:

  1. Firewall ports
  2. GDM configuration options

On the client you will need to configure the OS X firewall, as well as use the correct Xephyr connection syntax.
Continue reading →

WPA2 bug in Network Manager not fixed

Posted on by
Reply

Over the weekend I setup a Ubuntu 8.04 installation in my apartment.  The main purpose was to have a box to use to connect to my Tivo, but I am also going to use it to play with Java servlet and jsp development.

Of course none of this is any fun without Internet access.  So I started configuring my Linksys pci wireless adapter.  Turns out that the longstanding bug that affects the WPA2 passphrase store in Gnome Network Manager is still not fixed.

Continue reading →