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.

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)

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.

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.

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/

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.

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

* 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

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.

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.

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.

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.

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. :)