shivan.org

Mark Cox from Red Hat has published an analysis of the security updates release for RHEL 5.0 through 5.2:

• Enterprise Linux 5.0 to 5.1
• Enterprise Linux 5.1 to 5.2 risk report

The blog posts cover the effects of various exploit mitigation technologies. Sadly it seems the same software keeps having security holes over and over again. It would be a good idea not to use a web browser from an important server (No duh!). It also seems like Samba and Kerberos related daemons have some major issues and should be locked down with a MAC system like SELinux and removed from any system where they are not specifically needed.

Bloglines, an online RSS feed reader, offers an easy way to export your RSS feed subscriptions in OPML format. The following extremely trivial Python script will spit out the OPML file to stdout:

#!/usr/bin/python
import mechanize

b = mechanize.Browser()

b.open("https://www.bloglines.com/export")

b.select_form(name="login")
b["email"] = "email@address"
b["password"] = "password"
b.submit()

print b.response().read()

Hopefully this will save someone else a few minutes of their time…

For those of us who plan and maintain wireless networks you are well aware of the problems presented by how limited you are with 802.11b/g in the 2.4ghz band. One way that many network administrators attempt to work around this is to leverage 802.11a which is in the much more wide open and spacious 5ghz bands. A common way to configure the wireless network is to have dual radio access points that support both 802.11b/g and 802.11a and have both radios broadcast the same SSID for the convenience of your end-users.

I’m beginning to give up on the idea of using the same wireless SSID for both 802.11a and 802.11b/g radios. On all three platforms that I care about getting the wireless driver to prefer 802.11a over 802.11b/g is a waste of time. The vast majority of drivers for all three platforms seem to blindly check the SNR (Signal to Noise Ratio) of all visible APs advertising the desired SSID and ignore which band they are on. Because signals in 2.4ghz attenuate less than 5ghz signals this means 802.11b/g radios will always have the highest SNR and thus will always be preferred with a simple SNR check. This means the band you really want your users to use more is used the least.

On Windows you can manually configure some drivers to prefer 802.11a for the same SSID shared between 802.11a and 802.11b/g radios but it’s specific to the driver and many drivers do not even offer the option. And some drivers that do offer the option sometimes choose to ignore it for reasons unknown. (I’m looking at you Intel.) On Mac none of this is exposed in the UI and I’ve yet to even get Google to cough up a command line way of influencing what band and channel to pick.

On Linux it depends on if you choose to use NetworkManager and let the wireless driver select the channel itself. Depending on the driver quality you have the ability to specify the channel manually. To do this requires you to set it each time you wish to use wireless and this prevents roaming in many cases. It also turns what should be a two click and wait operation into something involving multiple manual commands and watching dmesg. It’s simply not a viable option for anyone except the network administrator himself.

So I’ve given up on that front and I’ve decided the best thing to do is to just offer an SSID that is only served from 802.11a radios. Within most of our buildings 802.11a signal should be sufficient for roaming so while it’s not a great solution its a usable one at least. So now we have the usual SSID that is advertised from all of our 802.11b/g and 802.11a AP radios and in addition to that we have an SSID labeled with “(802.11a)” thats only advertised from 802.11a radios. The Aruba gear we use makes it pretty trivial to have both SSIDs dump clients onto the same VLANs with the same AAA profiles so all it takes is about 5 lines of configuration to have no outside visible differences between the SSIDs.

I really wish there was a more auto-magical way to get clients to prefer 802.11a but I’ve yet to find a viable way to do it. So for now the SSID kludge will have to do.

A certain someone poked me enough times over the last 11 months that I finally decided to get around to uploading the slides of a presentation I gave back in June of 2007 to the MHVLUG. The topic was basic SELinux concepts.

The following lines of code when used within Zenoss’s zendmd environment will take a list of IP addresses from a text file and spit out a list of those IP addresses that do not yet have a corresponding object in Zenoss.

import string

print [devip for devip in map(string.strip, open("iplist.txt", "r").readlines())
    if not [True for device in dmd.Devices.getSubDevices() if device.manageIp == devip]]

This is useful for those cases where you are sure Zenoss discovery missed a few network switches due to a network administrator screwup and find that it’s too time consuming to find the handful among hundreds the manual way.

As for the code quality I beg forgiveness from the Pythonic gods for thinking a list comprehension within a list comprehension with a map thrown in was a good idea. But then again I’m sure there are some Ruby fanatics out there that think that looks like Hello World.

Update on May 13th: A kind poster pointed out the presence of find() in zendmd and thus dmd.Devices.findDevice(). That means one can just do this instead:

import string

print [devip for devip in map(string.strip, open("iplist.txt", "r").readlines())
    if not dmd.Devices.findDevice(devip)]

Not only is it shorter its also a magnitude of order faster which shouldn’t be too surprising considering the evil in the original version. Thanks Erik!