March 2005 Archives

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.