Of course the reason that it changed was that I was looking at the documentation for GRUB, not GRUB Legacy.
Bummer. I was looking forward to the use of the 'ls' command too!
So why did I want GRUB Legacy documentation and not GRUB docs? Of the three "top" Enterprise Linux distributions only Ubuntu currently ships GRUB. Both SUSE and Red Hat use GRUB Legacy. Oh well. There was some cool stuff I found though.
Aside from the 'ls' command being available one of the other advantages to GRUB that I am waiting to see with Red Hat and SUSE is the ability to use a software raid and/or LVM boot device. Until they implement the newer revision of GRUB you will still have to create a separate /boot partition. Such a bummer.
There were a few other cool items that I saw and thought were worth a mention (lifted directly from the GFD Licensed online manual, see links below):
14.3.32 parttool-- Command: parttool partition commands
Make various modifications to partition table entries.
Each command is either a boolean option, in which case it must be followed with '+' or '-' (with no intervening space) to enable or disable that option, or else it takes a value in the form 'command=value'.
Currently, parttool is only useful on DOS partition tables (also known as Master Boot Record, or MBR). On these partition tables, the following commands are available:
When enabled, this hides the selected partition by setting the hidden bit in its partition type code; when disabled, unhides the selected partition by clearing this bit. This is useful only when booting DOS or Wwindows and multiple primary FAT partitions exist in one disk. See also DOS/Windows.
- 'boot' (boolean)
- When enabled, this makes the selected partition be the active (bootable) partition on its disk, clearing the active flag on all other partitions. This command is limited to primary partitions.
- 'type' (value)
- Change the type of an existing partition. The value must be a number in the range 0-0xFF (prefix with '0x' to enter it in hexadecimal).
- 'hidden' (boolean)
Plays a tune
If the argument is a file name (see File name syntax), play the tune recorded in it. The file format is first the tempo as an unsigned 32bit little-endian number, then pairs of unsigned 16bit little-endian numbers for pitch and duration pairs.
If the arguments are a series of numbers, play the inline tune.
The tempo is the base for all note durations. 60 gives a 1-second base, 120 gives a half-second base, etc. Pitches are Hz. Set pitch to 0 to produce a rest.
And one of my favorites:
Do nothing, successfully. This is mainly useful in control constructs such as
while(see Shell-like scripting).
So it looks like the developers of GRUB have a bit of a sense of humor and a serious side.
I felt a little confused and almost betrayed when I say what ls told me: dwrsdwrsdwrt.
Wait? What? How could this be?
I tried again and again. Sure enough this was real. There was no typo for me to fix or blurry vision to blame it on. I checked for FACL and file attributes but there were none!
I decide it was time to fall back to my old school skills and try chmod ug-s and check again, expecting the worse. There it was: dwrxdwrxdwrt.
So a quick check and sure enough chmod 7777 will set the permissions as you would think but, according to the man page on RHEL6, chmod will not unset the SetUID or SetGID bit when expressed numerically.
From the Coreutils announcement:
chmod, install, and mkdir now preserve a directory's set-user-ID and set-group-ID bits unless you explicitly request otherwise. E.g., `chmod 755 DIR' and `chmod u=rwx,go=rx DIR' now preserve DIR's set-user-ID and set-group-ID bits instead of clearing them, and similarly for `mkdir -m 755 DIR' and `mkdir -m u=rwx,go=rx DIR'. To clear the bits, mention them explicitly in a symbolic mode, e.g., `mkdir -m u=rwx,go=rx,-s DIR'. To set them, mention them explicitly in either a symbolic or a numeric mode, e.g., `mkdir -m 2755 DIR', `mkdir -m u=rwx,go=rx,g+s' DIR. This change is for convenience on systems where these bits inherit from parents. Unfortunately other operating systems are not consistent here, and portable scripts cannot assume the bits are set, cleared, or preserved, even when the bits are explicitly mentioned. For example, OpenBSD 3.9 `mkdir -m 777 D' preserves D's setgid bit but `chmod 777 D' clears it. Conversely, Solaris 10 `mkdir -m 777 D', `mkdir -m g-s D', and `chmod 0777 D' all preserve D's setgid bit, and you must use something like `chmod g-s D' to clear it.
Now if your wondering when this change was implemented you may be surprised.
This was a feature implemented in 2006 for release 6.0 of coreutils.
This package was released with RHEL6 so you don't see the behaviour in RHEL5.
So who knew you could set but not unset SetUID and SetGID bits numerically?
The drama is a dramatization.
* 2011.09.29 - Minor formatting update.
Every flight I take I am reminded how much I have become tied into a network. It seems that each trip I try to grab new email, a website or do an SSH connection before remembering that for one reason or another, on the ground or in the air, that I can't.
Fortunately there are industrious types out there that have fixed this problem for me.
The foundation for the solution has been in place since 1991 with a simple napkin.
From the History of AirCell at www.aircell.com: "The idea for Aircell began in 1991 in a barbecue restaurant in Denison, Texas, where company founder Jimmy Ray first made sketches on a paper napkin for an affordable telephone system for airplanes. Ray's subsequent investigation of the market and exploration of alternate technologies resulted in the formation of Aircell."
Since then AirCell has created a network of cellular towers across the US. The main difference between sprint, at&t, t-mobile or any other cellular carrier is the frequency and the direction of their antennas.
A traditional carrier will point their antenna towards the horizon. AirCell points their antenna towards the sky.
On the underside of the plane is placed an antenna. Inside the plane is a high end server.
AirCell even uses Linux: "With a Linux-based operating environment and standard connectors, other aircraft components and avionics can be connected to the AirCell system."
Wow, how cool is that?
Since Delta announced it was going to deploy GoGo Inflight Internet on its entire US fleet back in August of 2008 I have been hoping to find myself on one of these wifi enabled flights.
The last time that I flew out to BWI from Salt Lake City and got one of the coveted First Class upgrades, I had been told that I would have power (which there was, but the connection sucked) and wifi. Turns out that there was no wifi.
I knew though that it was going to simply be a matter of time since they were working their way through their fleet. The MD88 commuter jets were already done.
So you can imagine my excitement when the flight form BWI to ATL was on an MD88.
Not being sure if the next segment (the vast majority of time home would be from ATL to SLC) I had to take a chance to explore GoGo.
On the whole it was fairly useful, if overpriced.
So the nitty-gritty details:
Gogoinflight.com was free.
Delta.com was free.
Download speed was over 2mbps.
Very little seemed to be blocked.
Available at and above 30k feet.
Upload was around 300kbps.
SIP / VoIP appeared to be blocked. --> This could go into the pro section actually.
Cost was prohibitive.
Pay for one flight segment at a time.
Have to create an account.
Apparently there is some content filtering in response to employee concerns.
Not available for the whole flight, including being stuck on the runway.
The service(s) you are connecting to should be encrypted as the "hotspot" isn't.
Ironically GoGo hypes their pricing on their website as "down-to-earth". One of the things that I really dislike about their pricing is that, with the exception of the 30 day pass, they charge for access per flight. So if your flight is made up several flight segments, for instance going from BWI to ATL, wait two hours in Atlanta before flying ATL to SLC, well you get to pay twice and different amounts.
I have been struggling to determine who GoGo thinks they are going to get to pay for their service out of this deal. Clearly there are going to be people that pay for the novelty of it. Then there is going to be the highly wired business professionals that want to stay connected as long as possible.
Finally there will be the people that are on vacation and willing to spend the extra money to make the trip a little more bearable. These are the same people that will buy an $8 cold sandwich on the plane.
The price structure is going to be a bit prohibitive from most travelers and even the average, occasional business traveler.
GoGo uses the following pricing structure, again per flight:
Mobile devices on any length of flight is $7.95. Unfortunately not all phones (mine included) will let you turn off all radios except wifi.
Laptops and other devices on a flight shorter then 3 hours pay $9.95.
Laptops and other devices on a 3 hours or longer (regardless of the remaining length of the flight) pay $12.95.
For those that travel frequently you can pay $49.95 for 30 day unlimited access on one airline (only Delta or Virgin America). If you frequently ride both of those airlines you can buy a 30 day pass for each.
So in the end it was a very decent connection. In fact I found myself looking forward to having a better connection then in the terminal waiting to board. The price was a bit much and I wish I had known for certain that wifi would be available on the longer of the two flights. Of course if they offered a 24 hour pass instead of per flight payment I would have been all set.
If I was still travelling two to three weeks a month I might find it worth paying the 50 bucks for an unlimited access every month, but I don't and I would miss my alone time.
So for the time being I am going to resign myself to the fact that at 30,000 feet I MIGHT have the option of watching Hulu or working on that cross country flight, but won't whip out the credit card to quickly to pay for the experience.
Delta Announcement: http://aircell.mediaroom.com/index.php?s=43&item=86
Delta to Filter Internet from AJC: http://www.ajc.com/news/content/business/stories/2008/10/03/wifi.html
**Note: on 07/16/2009 made some minor grammatical and spelling updates.
** Please Read **
Now before going any farther I would like to point out that what is involved may result in voiding of any warranty and support from the manufacturer. You may also "brick" your new toy, i.e. you will break it to the point of requiring a soldering iron to fix it. I wasn't worried about this, but you might be. Please consider this before continuing.
** End Please Read **
For those of you that are not familiar with dd-wrt, open-wrt, or even Tomato, let me explain.
These are projects that have been developed to replace the current operating system (OS) from the manufacturer with a Linux based system. Giving you more control and flexibility with your hardware. For those that think the original system is better then a possible replacement with Linux, I would like to point out that the existing system is already Linux based.
In order to do this the Firmware must be replaced through a process known as flashing. What this entails doing is taking a binary image, transferring it to the device and then having the device rewrite the firmware with this new image. The process itself is automated and the worst part is transferring the image(s).
So first we have to obtain the images. Go to the project of your choice and see if your hardware is supported. I found out fairly quickly that there was a design change with the WRT54G2. Linksys, now owned by Cisco, had changed the OS image since the WRT54G.
The original plan had been to use Tomato. Unfortunately these changes prevented that. Fortunately I was able to use dd-wrt.
A quick look at dd-wrt and I was able to locate the specific instructions and links to the appropriate images. In this case I had actually had to get several different images and a specialized tool.
Images used, in order of use:
Micro Generic Image
Micro Image with sshd
And one very specific tool for the tftp transfer
** Please note that the tool I used was from redsands directly. It is the same tool however.
Once these have been downloaded we need to build the modified tftp tool. The reason that we have to use the modified tool is because Linksys modified tftp to require a password as an argument. This still boggles my mind since tftp was never meant to require any authentication and is completely done through clear text.
Since the tool is nicely packaged in a tar ball we simply need to untar it:
$ tar -xvjpf linksys-tftp.tar.bz2
Now we will change into the linksys-tftp-1.2.1 directory:
$ cd linksys-tftp-1.2.1/
A quick use of ls will reveal that we have several files:
main.c Makefile README tftp.c tftp.h tftpsubs.c
Be sure to read the README for any recent notices and changes in the instructions. This is a C program so make sure that you have GCC installed and available.
Next we need to use the command make to build the binaries:
Once this is done we have the tool for transferring the images over a modified tftp session to the device.
Next make sure that you have a WIRED connection to the device. We don't want the connection to get garbled part way through transmission. Make sure that the computers IP address is 192.168.1.10 with a net mask of 255.255.255.0 and NOT dynamically assigned. The wap/router is going to be 192.168.1.1.
Also ensure that if you have a firewall set that it is not going to block a successful transmission. The default firewall on a Fedora 10 installation will. Please be sure to make the appropriate adjustments.
TJ Shelton redsand [at] redsand.net
Mike Lynn abaddon [at] 802.11ninja.net
Linksys TFTP Client for *BSD/Linux The Firmware gets sexier
Modified Berkeley TFTP client Release: !(@) 1.2.1 (10/01/03)
At this point we need to go ahead and establish a conection:
linksys-tftp> connect 192.168.1.1
And finally we are going to put up the image:
linksys-tftp> put ../VxWorksPrep-G2V1.bin password
Replace password with whatever your password is. The default is admin. Again this is being sent as plain text and you should consider it a temporary password to be replaced later on.
Once the transmission is done the router will automatically begin a flash and reboot. This can take up to three minutes. Once it is completed with the prep image we are going to use the kill image. Again it is automatically going to reboot and we are going to have to wait for it to finish. Once that is done you can put in the dd-wrt image.
When I did this I first did the dd-wrt image that was generic and then followed with the other image since the first one was less then desirable. It should be possible to skip the first dd-wrt image. I have not done that and will not guarantee any results.
Be sure to change your password over a secure connection. Probably the best way to do this to first establish an ssh port forwarding session:
$ ssh -L 8080:192.168.1.1:80 email@example.com
DD-WRT v24-sp2 micro (c) 2009 NewMedia-NET GmbH
Release: 02/18/09 (SVN revision: 11650)
BusyBox v1.13.2 (2009-02-18 17:58:33 CET) built-in shell (ash)
Enter 'help' for a list of built-in commands.
Now simply open up a browser and point it to http://localhost:8080.
Now we have a secure connection for administration. One downside I have noticed with dd-wrt is the lack of a secure connection. This is a great way to ensure the security for your administrative password.
And that is it. Configure it to your hearts content and enjoy your new dd-wrt router!