adding range support to python’s http server to kickstart with anaconda

I’ve been working on automatic installs using kickstart and puppet. I’m using a modified python httpserver because it’s lightweight, and easy to integrate into my existing python code base. The server was churning away perfectly until anaconda started downloading the full rpm’s for installation. What was going wrong?

Traceback (most recent call last):
[...]
error: [Errno 32] Broken pipe
BorkedError: See TTBOJ for explanation and discussion

As it turns out, anaconda first downloads the headers, and then later requests the full rpm with an http range request. This second range request which begins at byte 1384, causes the “simple” httpserver to bork, because it doesn’t support this more elaborate feature.

After a bit of searching, I found rangehttpserver and was very grateful that I wouldn’t have to write this feature myself. This work by smgoller was based on the similar httpserver by xyne. Both of these people have been very responsive and kind in giving me special permission to the relevant portions of their code that I needed under the GPLv2/3+. Thanks to these two and their contribution to Free Software this let’s us all see further, instead of having to reinvent previously solved problems.

This derivative work is only one part of a larger software release that I have coming shortly, but I wanted to put this out here early to thank these guys and to make you all aware of the range issue and solution.

Thank you again and,
Happy Hacking,

James

learn how to do one minute hacks, in three minutes

I write this technical blog for you to enjoy, and to help me remember. So where do I get all this knowledge? I figure it out! Here’s how I learned to fix a small gedit annoyance in one minute, and within the next three, you’ll be able to do the same for other types of problems too. Ready? Set? Go!

I use gedit enough, that when I hack, I often end up using up more than the five allotted spaces in the “recent files” sections. I wanted to see eight. Since I knew it would have been silly for the developers to hard code the number five, I decided there was a chance that they stored it in the dconf settings. (BTW, there’s also an amazing “Dashboard” plugin which I use for more complex recent-files searching…)

Enter dconf-editor. Run this, and start browsing through the hierarchy. You’ll notice that the org.gnome.* hierarchy has a lot going on. Look around, and you’ll find a “gedit” section. Once there, you’ll probably recognize some of the key names, as preferences you’ve seen. I searched for the number 5 and I found it next to a ‘max-recents’ key.

You can edit this with the editor, or for your convenience, just run:

gsettings set org.gnome.gedit.preferences.ui max-recents 8

the corresponding ‘read’ command is:

gsettings get org.gnome.gedit.preferences.ui max-recents

of course. The interesting thing about these settings, is that if coded properly, their actions are “live”. Which means, you can toggle them on and off, and in most cases, you’ll see the results immediately. Similarly, if you toggle a particular setting in gedit, you should see the changes instantly in dconf-editor.

Have fun playing with this and,

Happy hacking,

James

 

A quick anaconda trick

Here’s a quick anaconda solution that I am now using in some of my kickstart files…

I wanted to bootstrap a machine and do all the partitioning and logical volume creation, but not format or mount one of the logical volumes. The magic parameter I needed was:

--fstype=none

This seems to work perfectly for me. It’s not 100% intuitive to me, but it does work. I hope it’s not an accidental bug in the anaconda code! The full text of my partitioning is:

clearpart --all --drives=sda
part /boot --fstype=ext4 --size=1024
part pv.01 --grow --size=1024
volgroup VolGroup00 --pesize=4096 pv.01
logvol / --fstype=ext4 --name=root --vgname=VolGroup00 --size=65536
logvol swap --name=swap --vgname=VolGroup00 --size=16384
logvol /foo --name=foo --vgname=VolGroup00 --fstype=none --grow --size=1

Now all that anaconda is missing is support for RAID1 EFI /boot.

Happy hacking,

James

Automatic hiera lookups in puppet 3.x

Dear readers,

I’ve started the slow migration of code from puppet 2.6 all the way to 3.x+. There were a few things I wasn’t clear on, so hopefully this will help to discuss these and make your migration easier!

I used hiera in 2.6, and I actually like it a lot so far. I was concerned that automatic lookups would pull in values that I wasn’t expecting. This is not the case or a worry. Let’s dive in and let the code speak:

# create a class in a module or site.pp for testing...
class foo(
        $a = 'apple',
        $b = 'banana'
) {
        notify { 'foo':
                message => "a is: ${a}, b is: ${b}",
        }
}

and

# define it using :: as a prefix because we want to search in the
# top level, module namespace. optional if we only have one foo.
class { '::foo':
}

and

# /etc/puppet/hiera.yaml
:backends:
        - yaml

:hierarchy:
        - globals
        - whatever
        - youlike

:yaml:
        :datadir: /etc/puppet/hieradata/

and

# /etc/puppet/hieradata/whatever.yaml (because of - whatever above)
---
foo::a: 'somevalue' # this many colons is actually valid syntax
dude: 'sweet'

will produce:

[...]
Notice: a is somevalue, b is: banana
Notice: Finished catalog run in 3.14159265359 seconds

This is the automatic lookup. You probably have zero risk of collision with earlier data in your hiera yaml files, because these lookups use keys that match the classname::paramname pattern. If you had used :: (double colons) in your keys before, then you’re insane, and you should check for any collisions! The downside to this is that my whatever.yaml looks awkward with all those colons, but I got over that very quickly.

The full lookup order is first:

# directly specified values first (of course)
class { '::foo':
        a => 'this value is used first if set.',
}

and then:

# values matching an appropriate yaml key:
---
foo::a: 'this value is used next if found.'

and finally:

class foo(
        $a = 'this parameter default value is used last.'
        $b = 'b is still for banana...'
) {
        # do stuff...
}

all as detailed in: http://projects.puppetlabs.com/issues/11608. Finding this link and setting me down the path to knowledge was all thanks to eric0 in #puppet. Thanks Eric!

Make sure to reload your puppetmaster after you make any changes to /etc/puppet/hiera.yaml, and as always:

Happy hacking,

James

Picking up the pieces after a Fedora 18 install

I love GNOME and Fedora, but “upgrading” from Fedora 17 to 18 did not go well for me. I recommend you wait until either these are all fixed, or Fedora 19+ suits your needs. Here are a list of problems I had, and some workarounds. Hopefully proper patches to these bugs will get merged quickly, so that you don’t need to use these fixes.

Problem: Boot fails after upgrade from Fedora 17 to Fedora 18. I used the new “fedup” method.

Workaround: I did a fresh install. Make sure you have backups first, of course. I didn’t feel like spending a lot of time debugging why it broke.

Problem: The <Backspace> key no longer goes “up” in nautilus. I hope this wasn’t a “feature removal”.

Workaround: Add:

(gtk_accel_path "<Actions>/ShellActions/Up" "BackSpace")

to your: ~/.config/nautilus/accels and restart nautilus of course.

Problem: Split view (extra pane) functionality is missing in nautilus 3.6

Workaround: The GNOME developers plan to eventually replace this in a similar form. Until then, you can install the nemo file manager, which is a fork of nautilus 3.4 and is packaged in Fedora 18. (yum install nemo nemo-open-terminal)

Problem: GNOME Shell background is entirely black in overview mode.

Workaround: Using gnome-tweak-tool, under the “Desktop” section, set “Have file manager handle the desktop“, to “OFF“. Unfortunately, this disables viewing of files on your desktop. This wasn’t a problem in Fedora 17.

Problem: Restarting the X server with the familiar Control-Alt-Backspace, can’t be enabled in the keyboard shortcuts menu as it used to.

Workaround: This option is now hidden in the gnome-tweak-tool under typing: terminate.

I hope this scratches your itches!

Happy hacking,

James

How to send and receive files like a professional

Everyone needs to send and receive files sometimes. Traditionally people send files as email attachments. This still works great, and supports encryption, but many mail servers are slow and cap the upper file size limit.

ICQ was a great solution back in the 1990’s, but those days are now over. (I still remember my number.)

A lot of folks use dropbox, which requires a dropbox account, and for you to trust them with your files.

If you want a simple solution that doesn’t need internet access (if you’re on a LAN, for example) you can use droopy and woof. These are two shell scripts that I keep in my ~/bin/. Droopy lets you receive a file from a sender, and woof lets you send one their way. Unfortunately, they don’t support ssl. This could be a project for someone. (Hint)

I recently patched droopy to add inline image support. I’ve emailed my patch to the author, but until it gets merged, you can get my patched version here. (AGPLv.3+)

Hopefully these are helpful to you.

Happy hacking,

James

Renaming a GNOME keyring (for seahorse, the passwords and keyrings application)

The GNOME Keyring is a great tool to unify password management across the desktop. Sadly, Firefox is the one application that doesn’t support this natively. (Chrome actually does!)

Seahorse is a useful tool to browse and manage your keyrings. Each keyring is physically stored in: ~/.gnome2/keyrings/$something.keyring

Usually the “$something“, matches the name of the keyring, however the real name comes from within the file. I had an older ubuntu machine running GNOME, and I wanted to import my keyring. Here’s how I did it:

1. Copy ~/.gnome2/keyrings/login.keyring (from the ubuntu machine) to ~/.gnome2/keyrings/ubuntu.keyring (on the new machine)
2. Open up seahorse and change the keyring password of this “login” keyring to the empty string. This stores the passwords in a plain text format, which is briefly necessary.
3. Edit the ubuntu.keyring file. There will be an obvious “display-name” section at the top of the file to edit. I changed it to:

   [keyring]
   display-name=ubuntu

4. After restarting seahorse, I now changed the password back to something secure. If this process worked, you should already see the new keyring name in your keychain list.

Obviously this is a bit of a hack, and a proper rename function would be preferable, but until that exists, hopefully this will fill a niche if you’re stuck and you want to pull in an old keyring into your already populated $HOME.

Happy hacking,

James