Recently in Guru Labs Category

Today I noticed that Flash 10 was released for Linux. The version is 10.0.12.36.

Still no 64bit version but, the the long standing bug of having flash menus appear behind other content has been finally fixed (assuming you have Firefox 3.0.2 or newer).

On systems that use RPM you can run:

$ sudo rpm -Uvh http://fpdownload.macromedia.com/get/flashplayer/current/flash-plugin-10.0.12.36-release.i386.rpm

Or if you have Adobe yum repo installed (recommended), just do a:

$ sudo yum update flash-plugin

Be sure to read the Flash 10 Tips for important info on using Flash 10.

Having owned several IBM T-series ThinkPads I've always been a fan. The ownership of T-series has spread throughout the troupe of Linux Training instructors here at Guru Labs as lesser laptops have fallen to the wayside.

I've had my current T42p for almost three years now. I've been very happy with it. The build quality is excellent, and it anyone looking at it would never guess it has been used daily for the last three years. The Linux support is superb. The only problem is that the 2.0 Ghz Pentium-m CPU in it doesn't support PAE so Xen in RHEL5/FC6 doesn't work.

Today I found that IBM has posted details on the new Santa Rosa chipset based T61 laptops to be released next month. I plan on picking one up to replace my T42p. Some of the highlights:

* All the benefits of Santa Rosa platform
* LCD roll cage
* Firewire port
* NVIDIA Quadro 140M replaces ATI as high video card option
* Four-in-one media reader
* New Intel 4965AGN WiFi card

More information is available in the Announcement Letter (HTML) or Announcement Letter (PDF)

There has been lots of activity the past little while on the software development front. Here is a sampling of few things that caught my eye.

SUSE Enterprise Linux 10

On Monday, Novell released the long awaited SUSE Linux Enterprise Server and Desktop version 10. Guru Lab's Linux courseware and classes cover both SUSE Linux Enterprise as well as Red Hat Linux Enterprise and we are working on releasing updated materials to cover this new version 10 release (and later this year, RHEL5).

Major Squid Release

The Squid web proxy server has a new major v2.6 release after several years. Some of the new features include better scalability, a "totally transparent" mode which rewrites layer 3 and 4 address and port numbers, support for Negotiate/Kerberos authentication, hardware assisted SSL support, and many other features. I authored the Squid chapter and lab used in our GL275: Enterprise Linux Services class and I'm excited about adding coverage the new v2.6 features. Too bad that none of the 2006 Enterprise Linux releases will include Squid v2.6.

Compiz in Fedora

On the Fedora Core v6 and Red Hat Enterprise Linux v5 development front there has been a few things of note. The OpenGL window and compositing manger, Compiz has been added to rawhide. It seems that 2006 is the year of ubber eye-candy in Linux. I doubt it will ship as part of RHEL5, but FC6 desktops should be all set. On difference between SUSE and Fedora is that Compiz sits on top of AIGLX instead of XGL. A Red Hat developer provides some more details in a post to the fedora-devel-list.

Essential Perl Modules now in Fedora

Several years ago when we added comprehensive LDAP coverage to the GL275 class we ran into a deficiency. We teach the best practice approaches to using LDAP as a NIS replacement. That often involves importing user accounts into LDAP from files in /etc. The PADL migration tools leave a lot to be desired from a functionality and user friendliness perspective. So I wrote a new migration tool in perl called "ldapmigrate". Of course when communicating with the LDAP server it is best to do so over an encrypted SSL/TLS connection. To that end my "ldapmigrate" script makes use of the perl modules IO-Socket-SSL and Net_SSLeay. By having those two modules installed the perl LDAP module can make the encrypted connections. Although SUSE included those modules as part of the distribution, Red Hat did not and I filed a bug report in 2003 to add them. In the interim we compiled and provided those modules in class. Finally, today they were added to rawhide so those modules will part of Fedora Core v6 and RHEL5.

I've had my shiny new Treo700p for the past week and I thought I share a few things I've noticed about upgrading from my Treo650.

By far, the best new feature is support for super fast (slightly less fast than DSL) data access via EVDO. The speed difference is incredible and the latency is about 1/2 of what it used to be.

Benefits of the speed increase (and latency decrease):

• SSH sessions have nearly no lag! (note that I use pssh as my PalmOS SSH client)


• IRC, VNC and RDP remote desktop sessions are also greatly improved with nearly zero lag.


• Web browsing is MUCH faster due to the lower latency, faster download speeds and improvements to cache handling in Blazer v4.5.


• Doing a new email check my IMAP inbox (with 24,000+ messages) now takes about 10 seconds versus a minute on the Treo650. New emails download very fast.


• High quality streaming audio and video is now possible. I know lots of people are going gagga over the fact that Orb works. The 3GP test page worked fine for me.


• Tethering your Laptop via Bluetooth DUN results in speeds around 250Kbs. If you tether your laptop via USB the speeds are around 950Kbs!

Besides the killer speed increase there has also been a large round of polishing. Some things I've noticed in that regard include:

• The "screen is locked" dialog now shows the time.


• Contacts can be assigned a custom ring tone in the Contacts app.


• The SMS app has seen a face lift.


• The excellent Documents To Go app with PDF, MS Word, MS Excel (incidentally, it does calculations on TEXT cells the same way as Excel), MS Powerpoint support is now included and installed the ROM.

All in all I'm very pleased with the upgrade to the Treo700p.

Server vendors like Dell love Linux as it helps them sell hardware. It is in their best interest to have their servers work well with Linux.

Dell has long had a server management software called Dell OpenManage Server Administrator (OMSA) which provides a command line and web interface to monitors hardware details and failures as well as has the ability to "plug-in" to various datacenter management platforms like HP OpenView, CA Unicenter, and Novell Zenworks.

Historically OMSA required several binary-only kernel modules for drivers to the system management chips. This meant that if you used OMSA, it would "taint" your kernel rendering your system unsupported by kernel developers (although you could still get support from your Enterprise Linux vendor and Dell).

Today I noticed that Dell OpenManage Server Administrator v5.0 was released. The press release didn't mention this, but digging deeper I discovered this tidbit:

Starting with OMSA 5.0, all necessary kernel components are now fully open source, GPL licensed, and included in kernel.org 2.6.x. This includes the OpenIPMI drivers/char/ipmi/ipmi* drivers, drivers/firmware/dell_rbu Remote BIOS Update driver, and drivers/firmware/dcdbas Dell Base Systems Managment driver. This should make it much easier to install and run OMSA on a variety of Linux distributions (userspace library incompatibilities, if any, notwithstanding).

That is very cool! Well done Dell.

I also found out today that Dell makes it easy (relatively so) to install OMSA via a "unofficial" yum repository. Do any other big hardware vendors have yum repos for their management tools?

Information on the repository is available at: http://linux.dell.com/repo/software/

Us folks at Guru Labs have long been Treo users and most everyone at the office has one.

There are extremely powerful communication tool and whenever we doing a Linux training gig on the road the Treo makes it easy to stay in touch (and even drop in on #utah).

The Treo700p will be official announced on Monday May 15th 2006. However, in some places of the world that time has already arrived and the press embargo has been lifted.

For official/non-rumor Treo700p details check out the first article to be published at Treo Central, titled "Palm Reveals Treo 700p Smartphone".

The 2nd article now online is from Palm themselves, see the "Treo 700p Smartphone". There is a PDF as well as a flash demo.

An anonymous Sprint employee posted page "4" of their weekly sales "playbook". It in it shows the Treo 700 launching on May 28th. In the thread discussing this new info it has also confirmed that this is the Treo 700p (and not the 700w).

This info is from www.TreoCentral.com which has the best forums for Treo owners and fans.

The Treo700p is soon to be released and I plan on upgrading. Some of the new (rumored) features to be included are:

* EV-DO support on CDMA networks
** Can receive incoming calls while actively using data
* Increase of built-in memory to 64MB
* Update of all built-in apps
** New "fast mode" in blazer
* 1.3MP camera
* FAT32 support (can be hacked into a Treo650 today with a custom rom)
* Enhanced keyboard

The EV-DO support is probably the "killer app" as it provides DSL-like speeds.

The N. Utah Sprint EV-DO coverage map shows EV-DO coverage available today in orange and future coverage in beige.

I look forward to the EV-DO Rev A rollouts as that greatly increases the speed down and up while providing much better latency that will make VoIP and interactive apps (such as ssh) a joy to use. Unfortunately I doubt the EV-DO radio in the Treo700p will support EV-DO Rev A. Oh well, it just gives me yet another reason to upgrade to a future Linux based Treo.

Palm has just announced a Trade-In Program for old PDAs and SmartPhones that can be used as credit towards the purchase of a new Treo 700p (or any Palm PDA).

Some of the Trade-In values I checked:

Treo 650 in excellent condition = $170
Treo 650 in good condition = $142
Treo 600 in excellent condition = $65
Treo 600 in good condition = $53

When installing and/or upgrading packages using the /usr/bin/rpm command you have several choices depending on the exact outcome desired and the pre-existing situation.

First one should be aware of one of the RPM rules that is the main factor in this choice, namely "A file can only be 'owned' by a single RPM package". As with all rules in the UNIX/Linux it is possible to override this rule, but you get to keep all the pieces when stuff breaks.

Because of this rule, for the vast majority of packages you might install, you can only have one version installed.

For example, lets say you have two RPMs for the Apache web server.

httpd-2.0.54-10.3
httpd-2.2.0-5.1.2

(the package names come from Fedora Core v4 and v5 respectively).

You can examining the packages (before installation) and see what files are contained. In this case we'll just look at what files have "sbin" in their path since the complete list is over 300 files.

First the package for Apache version 2.0:

$ rpm -qlp httpd-2.0.54-10.3*rpm | grep sbin
/usr/sbin/apachectl
/usr/sbin/httpd
/usr/sbin/httpd.worker
/usr/sbin/rotatelogs
/usr/sbin/suexec

And for Apache version 2.2:

$ rpm -ql httpd-2.2.0-5.1.2 | grep sbin
/usr/sbin/apachectl
/usr/sbin/htcacheclean
/usr/sbin/httpd
/usr/sbin/httpd.worker
/usr/sbin/httxt2dbm
/usr/sbin/rotatelogs
/usr/sbin/suexec

Out of the 300+ files if a single file is the same you can't have both packages installed at the same time. Really the constraint isn't the two Apache RPMs, but the entire set of RPMs that are installed or will be installed on a box. No files can "conflict" (be the same).

With this rule covered, now what RPM options are available and when would one use them. Pretty much you will always use the "vh" options to get verbose output and hash (#) marks. But of the primary action options are "-i", "-U", and "-F".

* "-i". Performs an installation without removing (aka upgrading) any older version of the package. If you have an older version of the package installed, most likely THE COMMAND WILL FAIL because of overlapping files (see the Apache example above). So, for the most part, you can only use "-i" if you know ahead of time that you don't have an older version of the package already installed.

This begs the question, "When can I have two versions of a package installed simultaneously?". There are two situations, one fairly common and the other not so common.

* With the "kernel" RPM package. It turns out that every file provided by the kernel RPM package has the kernel version string somewhere in the full path, for example:

/lib/modules/2.6.15-1.2054_FC5/kernel/arch/i386/crypto/aes-i586.ko

Because of that you CAN have multiple kernel RPM packages installed at the same time, and you might actually WANT to. You might want to because the kernel is very critical to the operation of the system and if you install a new kernel version, and for whatever reason (bad driver, bug, etc) it doesn't work properly or won't boot, by having your old "known good" kernel installed you can easily recover (reboot and select the old kernel from the GRUB menu).

* The other case is when trying to run an old binary you discover it is requires /usr/lib/libfoo.so.1 and you have /usr/lib/libfoo.so.2 installed. Like the kernel RPM, most (but not all), library packages have the version string embedded in the file name and therefore don't conflict.

By using "-i" you can install libfoo-1.0.18.i386.rpm alongside libfoo-2.0.22.i386.rpm.

Finally, for the sake of completeness another related question "How can I have two packages installed where both are supplying a file with same full path?". Here are some example scenarios:

* sendmail and postfix both trying to provide /usr/sbin/sendmail
* SUN Java, IBM Java, and GCJ trying to provide /usr/bin/java
* CUPS, LPRng both trying to provide /usr/bin/lpr

The answer is (as is often the case in computer science), don't have the files conflict and use an abstraction layer. This was first done by the Debian folks in the creation of the "alternatives" system, it is used very widely in Debian/Ubuntu for lots of different packages. Red Hat adopted it during the 7.x time frame but used it just with MTAs (sendmail, postfix) and printing subsystems. SUSE has now adopted it with version 10.0 but only for Java packages from the jpackage project. The complete discussion of the alternatives system is beyond the scope of this blog post. We do have excellent coverage in our Linux training classes though.

* "-F". Performs an installation and removes (aka upgrades) any older version of the package if and only if you DO have an older version of the package installed. This option I like to call the "upgrade only" option. It is relic of the olden days of updating a Linux box with errata. Back then you update your system with the updates by:

1. Download all available updates (using ftp and mget *rpm) into a local directory.
2. In that directory run "rpm -Fvh *rpm".

This way you wouldn't install any new software packages that happened to have an update and instead you would just update the packages you did have installed.

Today we keep our systems current with smarter methods such as "yum -y update, you, up2date, rug, etc".

* "-U". This option performs an install if you don't have an older version already installed, and an upgrade if you do. I call it the "install or update as needed" option.

So to answer the question, "What RPM option does Dax Kelson use to install or upgrade RPM packages?" the answer is, "I try not to use /usr/bin/rpm unless I'm installing packages I've created myself or manually downloaded." Instead to install software I use a front end that figures out and downloads the dependencies automatically for me. For example:

* yum install packagename ...
* yast -i packagename ...
* up2date packagename ...

In the case when I've created my own RPM or done a manual download of a RPM package I like to use the "-U" option. This way RPM does the right thing (install or upgrade as needed) for me and I don't have to keep track of mentally if I already have the package installed.

Today Novell/SUSE submitted the AppArmor patches to the Linux Kernel Mailing List (LKML). Following the discussion is likely to be interesting.

Red Hat has adopted the SELinux security framework (already accepted into the Linux kernel). The SELinux frameworks plugs into the kernel's LSM subsystem. Some people have complained of the complexity of SELinux. Because of the complexity and interference many people just turn off SELinux. The response from the SELinux folks is that Linux software has complex interactions and *any* solution to properly secure it will be, by definition, at least as complex. Furthermore, the SELinux developers say that they have worked hard on developing a clean foundation that is basically complete now and that all the easy to use front end management software can now appear.

Novell/SUSE has chosen an alternate, less complex security framework, AppArmor. The benefit is well, that is less complex and doesn't "interfere" as much as SELinux so it is less likely to get turned off. The complaint about AppArmor is that it doesn't provide full security and depends on file pathnames, and won't scale well because of required locking. If a file's name changes (hard link, mount, etc) the security goes out the window. Another issue brought up is that the use AppArmor precludes the use of filesystem namespaces support for which has been slowly added to the kernel. The use of namespaces is supposed to usher in a new era of flexible and wonderful abilities that could be very useful for desktop users and virtualization. Today however, nobody is making use of filesystem namespaces in any mainstream distribution.

Personally, as a system administration and user of Linux I encourage the distributions to "un-fork" as much as possible. Thanks to the Linux Standards Base (LSB) and other efforts managing Red Hat boxes and SUSE boxes is, for the most part, the same. So from this stand point I'm pretty disappointed to see this split. It becomes yet another thing I must wrap my brain around and keep up on. Also, from an efficiency and pace of innovation perspective I would have preferred all the resources and development pushing and pulling in the same direction.

At Guru Labs we already have extensive SELinux coverage in our GL550 Linux security training class. When we do the big rev for RHEL5 and SLES10 we will be adding extensive coverage of AppArmor as well.

Being a computer user on a network that uses single sign on (SSO) is very convenient. Another benefit is the "other thing" that users don't generally concern themselves with, increased security. The Kerberos Network Authentication Protocol developed at MIT in the 1980s is the open standard that has been adopted widely.

On your network, the more services that are using SSO authentication, the greater the benefit of SSO. This is commonly called the "Fax Effect" (the more people that own fax machines, the greater the benefit to each fax machine owner). Today many services are able to use Kerberos authentication either directly, or indirectly through GSSAPI or SASL+GSSAPI.

Some of these services include:

* SQL Servers (PostgreSQL, Oracle)
* SMTP (Postfix, Sendmail)
* IMAP (Cyrus-imapd, Dovecot)
* Email clients (Evolution, Thunderbird, Kmail)
* SSH (OpenSSH)
* telnet/ftp/rlogin/rsh
* rsync (via ssh)
* Web Applications (Apache +mod_auth_kerb or IIS plus Mozilla/Firefox/Konqueror/IE)
* File Servers (NFSv3/v4 with "sec=krb5" on Linux, or Samba)
* Print Servers (LPRng or later this year, CUPS)
* Network equipment (Cisco IOS and others)

Here at Guru Labs, we have been on a multi-year mission get every service on our network using Kerberos authentication. Not just with Kerberos, but across the board we try to develop best practices, "dog food" them and then write about them in our Linux courseware and training.

One service we recently Kerberized was our Jabber instant messaging server. Getting Jabber kerberized is very nice, particularly when using Gaim. If you configure Gaim to store your passwords (not the default, but very conveniently tempting), it stores them in plaintext in your ~/.gaim/accounts.xml file.

As of April, 2006 the GSSAPI+Kerberos Jabber landscape is as follows:

There are two open source Jabber server implementation that supports GSSAPI+Kerberos authentication.

* Jabberd v2.0 with Simon Wilkinson's Kerberos/GSSAPI/SASL patch. This is a mature well tested solution. This is what we are using at Guru Labs. The patch has been accepted into the CVS tree and will be in the future v2.1 release.

* The highly regarded and actively developed Java based Wildfire Server is just barely (days ago) starting to work with GSSAPI. Once the rough edges are polished off and a stable release is made with GSSAPI support we are going to strongly consider moving to this server.

On the client front there are patches for Psi and Coccinella and Gaim. I haven't used Psi or Coccinella so I don't know if the patches are current or have been accepted into the official trees.

For gaim v1.5.x there are two patches. Simon Wilkinson developed a SASL-GSSAPI patch that was later modified by Greg Hudson of MIT to support gracefull fallback by prompting for a password if a Kerberos ticket is not obtainable. This is something I wish more client software would do.

The soon to be released gaim v2.0 has Simon's patch integrated, so it will support GSSAPI/Kerberos authentication out-of-the-box. There are plans to add graceful fallback and other features.

Our experiences getting Jabber Kerberized will be rolled into our GL550 "Enterprise Linux Security Administration" training course. The course includes extensive Kerberos coverage both of MIT's implementation and KTH's Heimdal implementation (used on SUSE Linux Enterprise Server 9) as well as best practices for Kerberizing common services (see the list above). It is the only Kerberos training class that I'm aware of.

My laptop has the Intel 2200BG card and uses the ipw2200 driver. By default, when the driver loads, it tries to associate to any network that is open and accessible. This is the physical equivalent of your laptop automatically plugging itself into any network port in the area.

I don't like this behavior, both from a I-want-control-of-my-network-status as well as go-to-jail-or-pay-a-big-fine stand point.

Fortunately driver allows you to turn off this auto-associate behavior with a parameter. In my /etc/modprobe.conf I added the line:

options ipw2200 associate=0

Problem solved.

I take my laptop pretty seriously since I use it as my primary computer both at work and home. I'm picky about the performance, weight, screen and durability. It's the same for most of us at Guru Labs. A major line of work for us is lugging our laptops around the world delivering Linux training. The ThinkPad T series is a common sight around the office.

For years laptop hard drives ran at 4200RPM and were a major bottleneck in mobile performance. Fortunately 5400 and 7200RPM drives brought "desktop like" performance to laptops. Two years ago when I bought my ThinkPad T42p I went for the largest 7200RPM drive available at the time, 60GB. I have really enjoyed the speed and vowed that I wouldn't get anything slower than 7200RPM in my laptop. The only problem is that I have been a bit cramped by the space and, even today, the largest 7200RPM 2.5" laptop hard drive is only modestly larger at 100GB.

Not too long ago the Seagate Momentus 5400.3 ST9160821A 160GB Hard Drive was released and took the crown as the new champion in 2.5" laptop capacity. When I saw that it was a 5400RPM hard drive I was a bit bummed -- however when I found out it was the first hard drive to ship with perpendicular recording technology I was intrigued.

Reviews were hard to come by, and the ones I read didn't have any comparisons against 7200RPM laptop hard drives. I took a chance and bought one with the strong hopes that the high areal density would translate into performance that could match my 7200RPM drive.

Here are what the initial performance numbers (average numbers reported from several hdparm -tT runs) look like:

For my original 60GB 7200RPM drive:
/dev/hda:
Timing cached reads: 2104 MB in 2.00 seconds = 1051.93 MB/sec
Timing buffered disk reads: 114 MB in 3.00 seconds = 37.95 MB/sec

For the new Seagate Momentus 160GB 5400RPM drive:
/dev/hda:
Timing cached reads: 2112 MB in 2.00 seconds = 1055.82 MB/sec
Timing buffered disk reads: 122 MB in 3.00 seconds = 40.61 MB/sec

As you can see it exceeded, not just matched, the performance I have been used too. Additional benefits of the drive are quieter operation and the 5400RPM uses less power to increases my battery life. I'm very pleased.

At the Guru Labs office you can get easily blinded by all the shiny geek toys and I'm afraid I've triggered another round of upgrades. :)

Modern Palm PDAs connect to Linux via USB or Bluetooth. The pilot-link software provides the command line utilities and a library that GUI apps and frameworks (such a gnome-pilot) are built on top of.

Access to the Palm PDA hardware has traditionally been done via the visor kernel module. When the Treo 600 was released I submitted a minor kernel patch that accepted by Linus that enabled the visor kernel module to handle the new Treo 600.

With the visor kernel module, a character device such as /dev/ttyUSB1 used to access the Palm PDA.

A new method available with pilot-link v0.12 is direct USB access via libusb. Besides being twice as fast, access via libusb gets around the problem of tricky timing issues and UDEV being slow to create to the /dev files.

With Fedora Core v5 I decided to benchmark the exact difference in speed between the visor and libusb access methods. To do this I had to recompile pilot-link with libusb support, I filed a bug to have this be enabled by default in the future.

I used pilot-xfer to back my Treo650's 15,668KB of data.

Using the visor method:

pilot-xfer -p /dev/ttyUSB1 -b /tmp/Treo650-backup-visor

Results: 415 seconds or 37.75KB/sec

Using the libusb method:

pilot-xfer -p usb: -b /tmp/Treo650-backup-libusb

Results: 201 seconds or 77.95KB/sec

The results speak for themselves. Using the libusb method is more than twice as fast as using the visor kernel module. I can't wait for pilot-link v0.12 to be officially released.

The Linux kernel has quite capable software RAID support. In the last year RAID6 support was added. Using RAID6 is similar to RAID5 except that two disks can fail with the array still operational (with RAID5, the second failing disk would kill the array).

Two days ago Linus accepted patches from Neil Brown that allows resizing and growing of online RAID5 device. This functionality will be in the 2.6.17 kernel and will require the use of mdadm v2.4.

Here is an illustration:

1. First create a RAID5 device using three drives (each has a single partition that spans the whole drive):

mdadm -C -l5 -n3 /dev/md0 /dev/sda1 /dev/sdb1 /dev/sdc1

2. Now add an additional spare drive (initially) and then grow the array to use the four drives:

mdadm /dev/md0 -a /dev/sdd1

mdadm --grow /dev/md0 --raid-disks=4

3. Add three more drives and then grow the array to seven drives:

mdadm /dev/md0 -a /dev/sde1 /dev/sdf1 /dev/sdg1

mdadm --grow /dev/md0 --raid-disks=7

We have a ticket logged in our tracking system to expand our coverage of Linux software RAID in the GL250 class to cover this functionality.

Using a web interface to post blog entries is OK, however, a streamlined desktop application can be a faster and more pleasant experience.

I'm creating this post using, Drivel, a GNOME blogging client. It has support for various online journals as well as self-hosted blogs such as WordPress and MoveableType.

When using MoveableType it supports categories which the Guru Labs planet uses to only display relevant blog entries.

The drivel package exists in Fedora Extras making it an easy install.

Today a new version of X.org, 7.0 was released. A major change in this release of X.org is a new modular layout and integration of autotools for building. The 6.9 release is the same source code but using the old imake based build system.

One consequence of the modular system is that Linux distributions are now, for the first time, will now integrate X.org into the "normal" location on the filesystem such as /usr/lib and /usr/bin instead of /usr/X11R6. The Fedora development tree

All the announcements I read focused just on the modular change and none of them covered other changes. Here are some links to changes. The Release Notes and the changes since 6.8.

From those documents the following new features I found noteworth:

* EXA support included. EXA is a new accleration architecture to replace XAA to give fancy desktop graphics without the need for a full blown 3D driver.
* Radeon driver updates. Full 3D support for r3xx/r4xx series without having to use the binary only ATI driver.
* Multiseat support. One computer, 3 video cards (or a single multi-monitor video card, 3 keyboards, 3 mice. Check out a picture of the result here.

Cool stuff! For future changes coming to X.org, check this out.

The GIMP is getting a spiffy new feature in the upcoming v2.4 release. A way to easily select an object in an image.

It uses the new SIOX (Simple Interactive Object Extraction) algorithm.

Info here.

Gimp demo and a gimp movie.

I wrote and posted a new Guru Labs guide on using Linux (Fedora Core v4, though the directions are mostly agnostic to distro) with a Treo 650 upgraded with the newly released firmware that legally and offically enables Bluetooth Dialup Networking.

Credits must go to Stuart for getting this working first on his 64bit Ubuntu running laptop.

The Internet Assigned Numbers Authority is in charge of doling out IP address blocks. Last Friday, June 17th 2005, five previously unused /8 netblocks (same size as a class A network, aka 16 million addresses) were allocated.

Three netblocks went to North America via the American Registry for Internet Numbers.
74/8
75/8
76/8

Two netblocks went to Latin America and the Caribbean via the Latin America and Caribbean Internet Addresses Registry.
189/8
190/8

If you filter bogons on your firewall, update your filters accordingly.

Fedora Core v4 was released today. The announcment describes some of the changes and the Release Notes have even more details.

I used my rsync trick I mentioned earlier to snag a copy much quicker. The four ISO files total 2,663,610,368 bytes. By using rsync to covert my test3 ISOs into the final ISOs, I only had to download 1,155,789,380 bytes. That is basically 1.5GB of savings. Pretty substantial.

The Intel PRO/Wireless 2915ABG.

* It does A, B and G
* It has very low power consumption
* It has a 100% GPL, non-kernel tainting driver
* You can get it for less than $40
* It has actively developed and maintained drivers (WPA/WPA2 support
coming soon)
* The drivers are being prepped for inclusion into the official kernel
* It has it's own IRC channel (#ipw2100 on freenode) where the Intel
development team hangs out

I currently have the 2200BG part in my laptop which uses the same driver, but only supports B and G. I been using it exclusively ever since the v0.14 driver allowed associating to access points that are hosting multiple wireless networks (ala wireless VLANs) like we have in the Guru Labs office.

Today, May 18th 2005, the new driver v1.04 was released along with new firmware. One of the highly anticipated new features is the support for monitor mode. This also the operation of wireless sniffing tools such as kismet.

Many other bugs were fixed as well. Hopefully Fedora Core v4 will ship with this version of the driver.

Last week, rdesktop v1.4.1 was released.

Changes since version 1.4.0 are:

* persistent bitmap cache optimisations (-P)
* support for more RDP-orders (ellipse, polygon)
* libao sound-driver (for Mac OSX and others)
* Unicode support for transmitted strings/filenames
* Added korean keymap
* Xembed fixes to work with krdc correctly
* Portability fixes
* Support for RDP-compression (all depths)
* process RDP recv queue if send queue is full
* optimizations for the rdp compression at high depths
* fixes to the keyboard-handling regarding ctrl-alt-delete
* improvements to the sgi/irix sound driver
* mppc decompression fixes

Ever since Sunday, May 15th, I've been gettings LOTS of German SPAM.

I found out why last night.

Today the final test release (test 3) of Fedora Core v4 was released.

I used this trick to convert my FC4test2 isos into FC4test3. This way I'm not downloading the bits that haven't changed.

cd /path/to/your/FC4test2/isos
mv FC4-test2-i386-disc1.iso FC4-test3-i386-disc1.iso
mv FC4-test2-i386-disc2.iso FC4-test3-i386-disc2.iso
mv FC4-test2-i386-disc3.iso FC4-test3-i386-disc3.iso
mv FC4-test2-i386-disc4.iso FC4-test3-i386-disc4.iso

rsync -v --stats --progress rsync://name.of.mirror/fedora/linux/core/test/3.92/i386/iso/FC4-test3-i386-disc[1234].iso .

Watching the data transfer speed, I notice that pretty often it jumps up
much higher than the cap of my internet connection. This tells me that
that my trick was worthwhile.

Be sure to grab the SHA1SUM file and check your ISOs once the rsync
completes.

We have been working on updating our Linux courseware and training for the lastest Linux distributions. Recently we took a look at SUSE Linux Professional 9.3 and here are few quick things we noticed:

- blowfish encryption in /etc/shadow by default
- user created during install is "auto-login" by default
- Kerberos implementation switched from Heimdal to MIT
- New Package Group Selections available: Fonts, Voip, Xen, Laptop
- Deleted Package Group Selection: LSB (lsb RPM package exists)
- The original Korn Shell shipped
- The boot process starts the graphical login before daemons are launched
- Network config tied to hardware via physical path via "_nm_name='bus-pci-0000:03:01.0'"
- syslogd replaced with syslog-ng as default

It is possible that some of these changes first appeared in SUSE Linux 9.2.

For many years, on Red Hat distros, the common respository for SSL certificates has been the /usr/share/ssl/certs directory. You'll find the SSL certifcate for cyrus-imapd, dovect, exim, and OpenLDAP in that directory by default. Also, the bundle of trusted CA certicates is also located in that directory.

This is changing for Fedora Core v4 and the future Red Hat Enterprise Linux v5.

As of April 22nd, the Fedora development tree for the upcoming Fedora Core v4 changed the directory to:

/etc/pki

This initially caused some breakage in applications that hard coded the path to the CA bundle. One example was Postfix.

Applications shouldn't be hard coding the path, and instead should make use of the OpenSSL API functions X509_get_default_cert_file() or SSL_CTX_set_default_verify_paths().

Additionally, any HOWTO or documentation out there should be updated to reference the new path. We have already updated the development tree of our Linux courseware.

Ever wonder if an individual file is fragmented or not? The little known filefrag utility shipped as part of the e2fsprogs package can answer that question for files on ext2 and ext3 filesystems.

Examples:

# filefrag /usr/bin/bc
/usr/bin/bc: 5 extents found, perfection would be 1 extent

Or the verbose mode:

# filefrag -v /usr/bin/bc
Checking /usr/bin/bc
Filesystem type is: ef53
Filesystem cylinder groups is approximately 4976
Blocksize of file /usr/bin/bc is 4096
File size of /usr/bin/bc is 62636 (16 blocks)
First block: 350680
Last block: 354750
Discontinuity: Block 1 is at 352866 (was 350680)
Discontinuity: Block 5 is at 352981 (was 352869)
Discontinuity: Block 12 is at 352998 (was 352988)
Discontinuity: Block 13 is at 354748 (was 352998)
/usr/bin/bc: 5 extents found, perfection would be 1 extent

To examine fragmentation for an entire ext2/ext3 filesystem use the e2fsck command on the filesystem. When it finishes running it will report fragmentation details.

If you filter unassigned IP addresses (considered bogons) you should update it to allow IP addresses in the 48 netblock.

It has been allocated to Africa by the Internet Assigned Number Authority.

Here at Guru Labs, our border router has a multi-hop BGP peering session with the Team Cymru Bogon route servers so our router now allows these packets in automatically.

The problem with bio-metrics is that if the thief wants to take the "authenticator" with them, it is a bit more painful process then just giving them a set of keys or a pin number.

Anyone who has watched Demolition Man knows this and the following news story about finger stealing thiefs shouldn't be a surprise:

http://news.bbc.co.uk/2/hi/asia-pacific/4396831.stm

http://www.theregister.co.uk/2005/04/04/fingerprint_merc_chop/

The Windows universe has lots of applications and often there is one application that you can't live without. If WINE can't adequately handle the app, then one of the slickest ways to handle that is to deploy a Windows Terminal Server. Administering one Windows box is alot less headache then deploying VMware on everyone's workstation.

To connect to a Windows Terminal Server from Linux use rdesktop. There has been a major release, almost a year in the making.

The new release, v1.4.0, has the following new features (taken from the announcement):

* Basic disk-, parallel-, printer- and serial-redirection
* Fix timezone-redirection
* Backing-store fixes
* Fix client-IP sent to TS
* XEmbed support for embedding rdesktop in other applications (KRDC)
* Support for setting the RDP5 experience
* Keyboard and keymap fixes
* Performance improvements
* Report disconnect-reason
* Support for RDP-compression (currently only for 8bpp)
* Support for persistent bitmap caching
* Sound-driver for SGI/Irix

The support for serial port redirection will enable us to use a Linux box with serialy connected scale and run UPS Worldship remotely on the terminal server.

Have you ever wondered if your RPM dependency tree had any holes? It shouldn't have any holes if you have never used --nodeps.

On a FC3 box that I was building and installing rawhide packages for GNOME v2.10 I was forced to use --nodeps to get packages installed. Later dependencies were satisfied. I wanted to see if I had any holes left.

Here how I did it:

# rpm -Va 2>&1 | grep "Unsatisfied dependencies"

Unsatisfied dependencies for rhn-applet-2.1.16-1.i386: gnome-python2-gtkhtml2

Unsatisfied dependencies for system-config-printer-gui-0.6.116.1.1-1.i386: gnome-python2-gtkhtml2

Unsatisfied dependencies for openoffice.org-1.1.3-9.5.0.fc3.i386: libebook.so.8, libedataserver.so.3

Unsatisfied dependencies for bluez-pin-0.24-1.i386: libdbus-1.so.0, libdbus-glib-1.so.0

The -V option really needs a --just-check-deps or something as this takes a LONG time to run with all the md5 and file validation.

We have been using wireless ethernet at Guru Labs for sometime. It is a pretty advanced deployment as we have configured our Cisco access points to broadcast multiple ESSIDs, each with unique security settings. One requires WPA, another WEP, and another is completely open (yet firewalled). Each ESSID is bridged to separate 802.1q VLANs on our network. This is done via the frame tagging and ESSID mapping capabilities within each access point.

This setup is working very well for us.

The first step in deploying a wireless network for maximum performance is to use non-overlapping channels. With 802.11b and 802.11g there are 3 non-overlapping channels. Channels 1,6, and 11. The best practice is to use one of those three. Any "good" access point by default will select the least congested one. This knowledge is pretty widely known.

Today I did a scan and found another access point in the building operating on channel 3. The Guru Labs' access points are operating on channels 6 and 11. I was wondering how much channel 3 is overlapping into channel 6. I went searching to find a information on how the channels overlap with each other. It turns out that this information is not commonly known. After much digging, I finally found this nugget on the web page:

http://www.hyperlinktech.com/web/band_pass_filters.php

http://www.hyperlinktech.com/web/copyrighted_images/channel_chart.gif

I've created a new Guru Guide covering the creation of a boot.iso for initiating network installs on SLES/SL.

Check it out.

Yesterday I was feeling empty, and I wasn't sure why. I realized later in the day it was because there had been no batch of daily FC3 errata. Imagine my relief this morning when I logged in and saw the pulsing red panel applet.

There was a new update for the dmraid package with a fairly substantial changelog and nice surprise to boot. The changelog included:

- added NVidia metadata format handler (#130324)

This is neat. It mean that dmraid can now handle and use the Nvidia Nforce 3&4 chipset created RAID volumes.

My home World of Warcraft system has mirrored drives handled by a Nforce 4 motherboard.

With this dmraid change, the pieces are falling into place for me to be able get a Fedora Core (possibly Rawhide) install recongizing and using the motherboard built RAID volume instead of seeing the two drives separately.

The dirty little secret with onboard RAID and sub $100 RAID adapters is that they don't actually do any RAID processing themselves. The exist to hook into the BIOS and allow booting off of the RAID volume. The RAID configuration is stored in a little chunk of metadata at the begining of drive members.

The RAID functionality, ie writing to both drives at the same in the case of mirroring, or parity calculations are handled within the operating system driver.

If an operating system is installed without specific RAID drivers then the operating system will see all the individual drives. If the RAID support gets accidentally turn off in the BIOS then the operating sytsem will still likely boot and see all the individual drives. If the operating system continues running then it will just write to one of the drives, and the RAID volume becomes desynced.

If multiple operating systems are installed, then they need to all support the RAID meta data and see the volume as a single entity as instead of multiple drives.

True hardware RAID volumes don't have this problem as it is impossible for any operating system no matter the driver or BIOS state to see the individual drives.

Stuart blogged about secure GUI monitoring. I wanted add that ever since XFree86 v4.3 (circa RHL9 timeframe) that you can secure against switching out of X to a text terminal via CTL-ALT-Fn.

Edit your /etc/X11/xorg.conf and add a ServerFlags section with the contents:

Section ServerFlags
    # prevent the use of CTL-ALT-F1, etc
    Option DontVTSwitch On
    # prevent the use of CTL-ALT-BKSP
    Option DontZap On
EndSection

The GL250 course has coverage of this.

Cell phone cameras can come in very handy some times. In Jan the FC3 kernel died on my Thinkpad.

Transcribing the data can be a pain, but I did and filed a RH bugzilla bug.

At least I didn't have to decode morse code.

I noticed in last night's rawhide changelog that MIT Kerberos v1.4 has been merged.

MIT Kerberos v1.4 was released at the end of Jan 2005, and I note couple notable new features:

• Finally MIT Kerberos libraries get thread safetly.
  
• The ftp and telnet daemons can now be configured to *require* encryption.
  

See:
http://web.mit.edu/kerberos/www/krb5-1.4/
and
http://web.mit.edu/kerberos/www/krb5-1.4/README-1.4.txt

After creating the GL550 I've developed an appreciation for some of the "it's nice to work on" features of Heimdal that MIT Kerberos lacks such as readline support, GNU or GNU-like getopts support, less commands that require interactivity, and friendly interfaces for those that do. Many of the command line tools have saner defaults such as telnet requesting Kerberos authentication and encryption by default. The use of the -l switch to kadmin instead of a separate kadmin.local binary strikes me as more elegant as well.

Heimdal also has an interesting protocol encapsulation mode that lets clients communicate with the KDC over HTTP on port 80 (and also HTTP proxy support). This would be helpful for roadwarriors behind filtering firewalls that would otherwise block the normal Kerberos UDP port 88 traffic.

Unfortunately the kadmin protocol was never codified as a standard so a Heimdal kadmind daemon must be connected to with a Heimdal kadmin client.

It also bears mentioning that while I can appreciate the technical merits of Heimdal, I was less than impressed in how SUSE implemented it and integrated into their distro. The main warts are:

• All heimdal binaries installed under /usr/lib
  
• Only a single SysV init script for all daemons even though some daemons are only appropriate on a master or slave.
  
• No /etc/xinet.d/ files for the Kerberized telnet, ftp (and friends) daemons
  
• No SysV init script (or alternatively xinetd script) at all the for the propogation daemon that should run on slaves
  
• Kerberized replacements for telnet, ftp and other clients are not in the $PATH (first in the $PATH) by default. This should be implemented via a /etc/profile.d/kerberos file.
  
• The YaST kerberos_client module doesn't support more than one KDC and will mangle an existing correct /etc/krb5.conf if it has more than one KDC defined.
  

I reported these bugs to SUSE but I never heard anything back. It appears their bugzilla is not visable to outsiders so I have no way of knowing if the bugs are being acted on or ignored.

I wrote a patch to Planet ( a blog aggregator) to implements filtering based on category. This was my first Python hacking to add a new feature to an existing code base. Yah!

It will only filter based on the "primary category" as that is the only category information available in the RDF feed.

We will need this functionality when deploying the Planet on the main Guru Labs web page.

I just submitted the patch to the main developers. Hopefully they'll accept it and in the future we can just use a stock Planet install.

A little bit slow maybe, but Guru Labs is finally getting on board the blogging bus.

We hope that this will be a useful way for our partners, customers, and friends to tap into the fun 'Guru' atmosphere.

In the course of doing what we do, namely teaching advanced Linux classes and writing courseware manuals, we discover and gain insight on very interesting stuff!

Historically, this info was just passed back and forth on private internal mailing lists. Now we are going to make this info public via our newly installed blog server.

We are encourging all our Guru instructors to blog freely. Since most have Treo 650s picture phones, there should be some interesting impromptu and mobile blogging activity as well.

We hope to enjoy the ride. See you on board!