Recently I've been teaching python to some high school students. It has been going well, but the development environment we had access to left a little bit to be desired. We were working with ages old solaris, vi only, and no real access to newer gnu (or other) tools. So a new setup was required, I went off to investigate.

I started with chroot, since a buddy, Daniel Thau, had used it extensively for running multiple operating systems side by side. He'd pointed me in the directions of febootstrap and that seemed like it'd work fine. I was able to make a sandbox, get ssh running on 2022 and then have my dlink route that to my box. Success!

But I found that a bit messy, and a bit limited. I wanted to lock down how much of my resources they could use, and I didn't want to have to give access to some of my root file systems directly; /proc, /dev, etc. So I looked around a bit more, and stumbled on using KVM indirectly via the new virt-manager toolset that fedora 12 and 13 provide. Installation was as simple as:

$ yum install qemu-kvm virt-manager virt-viewer python-virtinst

But it also seems that from the techotopia article I followed for some of this that one could also just do:

$ yum groupinstall 'Virtualization'

I have to say it's a pretty swank set of tools. It's free, it works on KVM or Xen. KVM usage requires no special kernel and as such, no reboot. The setup was simple, and gave out a vnc port to connect to from the get go. It is also trivial to connect to a setup on machine A with virt-manager on machine B over ssh. If you want more information, fedora has a nice writeup, and libvirt has a more distro agnostic set of docs.

Problem was though that the networking was virtual, and didn't pull an IP address from my router, so it wasn't public. There were a few sections here and there describing how to switch to bridged, and I tried them. They didn't work for me, either I suck at following directions, or they just won't work how I expect them to. You can see for yourself here at how I attempted network bridging.

What I did was much more in my realm of knowledge, is simpler than all the other options, and is something I can make changes to w/o killing my network connectivity. iptables! I just used NAT forwarding. It was 2 lines, put in my pre-existing firewall script. So to get my local box 192.168.1.199 on port 2022 to forward to its internal virtual network of 192.168.100.2 at port 22 was as plain as this:

$ iptables -t nat -I PREROUTING -p tcp --dport 2022 -j DNAT\
    --to-destination 192.168.100.2:22
$ iptables -I FORWARD -p tcp --dport 22 -d 192.168.100.2 -j ACCEPT

One preroute rule to grab the port incoming, and one forward rule to pass said packets along. Now I have connectivity into my class virtual machine, and I don't have to do much to add more ports as needed. I am pretty happy with the setup so far. It's really nice to be able to connect remotely, vnc or ssh now, as well as know that I've limited the ram and cpu time the class can use on my box. I am interested to hear if anyone else is doing similar things with virtualization on their desktops.

I have recently gotten into tiling window managers. Awesome being the one I've found I like to use the most. There are others and they all have their merits, I just settled on this one, and then got comfortable. I also am a bit of a mutt in what distro's I use. Work they put ubuntu on my box, home I have usually used fedora but now it's fedora on the desktop and arch on the laptop.

So the issue was arch and ubuntu both had awesome in the package repos, and fedora did not. There is discussion out there as to why this was, and you might be interested in it. Me, I just wanted to use awesome. So using the directions from the awesome wiki and grabbing the required source rpms cairo-1.8.8-3.fc12.src.rpm and awesome-3.4.4-1.fc12.src.rpm, I now have awesome on my desktop.

Here are some of the docs and sources I used:

• directions from awesome's wiki
• awesome src.rpms for fedora
• the cario src.rpm
• discussion on package inclusion

The other day, I gave a presentation to the Ohio State University, Open Source Club. It was on a smattering of command line utilities that I use on a daily basis, as well as a quick intro to regex usage.

It is all accessible on my site here and in pdf form.

It was pretty long, and presenting it took a little over an hour. I plan on distilling the parts I liked talking about into more concise presentations, and also a blog post or two.

Awk and find will most likely be their own posts/presentations. I think I need to learn some more of the advanced uses of sed, and revisit that section to make it a bit more clear.

The other day @shuckins mentioned that

I'm finding the MX Revolution quite awesome except that I really miss my scroll wheel click button.

This was an issue that I had when I started using this mouse as well. The key feature of the mouse being that a middle click will switch the scroll wheel from smooth movement to discrete (chunky?) movement and back again. This is actually very cool to use once you've gotten accustomed to having the option of scrolling down a page with fine control of speed/distance and then click once to then flick back up to the top of a page.

What I did to make my life easier with this mouse was setup the thumb scroll wheel to act as my middle click that I was accustomed to having. I accomplished this via the btnx-config program as available from the btnx website.

Configuration for thumb wheel press/click

Once I found out how easy it was to get the middle click from the thumb wheel I decided to make the thumb up/down also have some functionality. If you use firefox and/or gnome terminal I find the most useful thing to map was thumb up to shift pageup and thumb down to shift pagedown.

Configuration for thumb wheel down

With these set this way I can switch tabs on both firefox and gnome-terminal w/o moving back to the keyboard. The other neat thing I found (when I actually noticed) was that this mapping holds even when using synergy to control two (or more) machines.

The mouse works great, and I haven't in recent memory ever like a mouse as much as I have this one. Couple the nice manufacturing with the ease of button configuration provided by the great programmers of btnx and I think its the perfect mouse for a programmer. Especially one who doesn't like to have to constantly switch between using the mouse and keyboard.

Newbeuter is my preferred way to browse RSS feeds. Its a great CLI app that is 'Mutt Of Feed Readers', and being a user of mutt I love this app for being so similar. I wanted to use the newest version of newbeuter, because recently I have been on a kick to get all of my apps: screen, vim, mutt, and now newsbuter; setup with 256 colours.

I read on the development blog that the newest version in the git repo was able to use 256 colours, so I immediately cloned the repo and started the install process. I was stopped immediately at the config.sh. It wanted the stfl libraries and wasn't able to find them, and neither could yum.

Looking into the config.sh I saw that it was querying pkg-config for the flags to use on compilation to see if the library was present. It wasn't, and so I also read further on the notes for the git repo version, and saw the bit about using the latest svn copy of stfl. So I checked that out, made it and installed it onto my machine. But this didn't get me any further into making newsbueter, because pkg-config was still unable to find libstfl.

So I decided to try and figure out what the issue was with stfl and pkg-config. First thing I saw was that the stfl.pc file that pkg-config uses to make its responses was in the wrong place for my system. It was in /usr/local/lib/pkgconfig, instead of with the other libraries on my system in /usr/lib64/pkgconfig. This resolved the issue of pkg-config not knowing where the pc file for stfl was, and pkg-config was now returning actual data about libstfl. A recompilation of newsbeuter did show that there was still a problem. I now received: error while loading shared libraries: libstfl.so.0: cannot open shared object file: No such file or directory.

I did another updatedb, and ran a locate for all stfl files, and found that the make install for stfl was putting the libs in a strange place as well. I then updated both the Makefile.cfg and the stfl.so.in to reflect the locations of other libs:

Makefile.cfg changed lines

export libdir ?= lib64
export prefix ?= usr
export DESTDIR ?= /

stfl.pc.in changes lines

prefix=/usr
exec_prefix=/usr
libdir=/usr/lib64
includedir=/usr/include

This got me pretty far I think, because now the system looked like the other libraries. The stfl.pc lines were taken almost verbatim from the sqlite3.pc file in fact. I was still getting the shared library issue though, and after not thinking about the problem for a bit I realized that the stfl makefile had made libstfl.so.0.21 and the error message was not able to find libstfl.so.0, so I too the logical leap and made a symlink named libstfl.so.0 that pointed to libstfl.so.0.21 in the /usr/lib64/ directory. After making sure that this worked, I made a change to the makefile for stfl, and added another line to make a second symlink, that ended in 0:

Makefile

ln -fs libstfl.so.$(VERSION) $(DESTDIR)$(prefix)/$(libdir)/libstfl.so.0

I do admit that there may be a better way to do this, and some of it may be done with command line config or make flags. I don't know them, and was able to successfully build with these changes.

So I've been attempting to make a suite of cli scripts for work. I recently discovered the multiprocessing module for python, and really liked its simplicity, and started using it, with great success. Everything was faster.

This then spurred me to take the scripts that were for the most part, copy common-ish bits and then modify to suite, and turn them into a library of sorts. The neat part then arose when I wanted to import a argument parser, as well as pass off to a proc creation component.

In doing this I had in mind that the 'script' would need to only define a function to make a list of commands to run on a given server, and a __main__ section that would pass in a list of servers, the function to make a command list and some other info. This way the script itself would only be two definition sections, and only the parts that were going to be unique for the most part.

The problem that came up in doing this is when I wanted the function that makes the command list to have more arguments that normal. How would I pass them in, and how would I define them so that I don't have to edit my libraries to accommodate this argument passing. It was kwargs that saved me there, that and some optparse tweaking.

Here is a basic example:

def get_commands(host, **kwargs):
    command_list = []

    user = kwargs['user']
    key_file = kwargs['key_file']

    command_list.append("echo %s" % user)

    return command_list

if __name__ == '__main__':
    import automation

    hosts = []

    (hosts, options) = automation.process_args(sys.argv)

    automation.thread_hosts(
            hosts,
            get_commands,
            options,
            user="test"
            )

def thread_hosts(hosts, get_commands, options={}, **kwargs):
    import multiprocessing

    kwargs.update(options)

    jobs = []

    for host in hosts:
        p = multiprocessing.Process(
                target=run_commands,
                args=(
                    host,
                    get_commands(host, **kwargs),
                    ), )

        jobs.append(p)
        p.start()

The project management app Trac is something that was new to me a while back. I'd just installed t for a side project, and used the yum install without any issues. It took care of all the grunt work, and got me to the point where I could now create and use a trac project.

Trac is set up like what I see web frameworks go with. A main program that will install the framework in a project directory. In this case trac-admin , which is killer when you want to make multiple projects, and offers a cli interface to the project s framework configuration, etc.

This setup becomes awesome I found when you want to upgrade. Yum installed what it had packaged, the .10 version, but I had decided that I wanted to toy with bitten their automated build tool, which required .11 and up. So an upgrade was needed, yum couldn t be used, but I found that trac-admin has an upgrade command.

So I was poised to make the fun and scary transition into mixing a package managed install with a source install, not something that always goes well. I ve found that sometimes packagers change to install location from where the src install goes (looking at you nagios), and make some conflicts or at least confusion.

The upgrade process for the server then my app was as simple as:

wget http://ftp.edgewall.com/pub/trac/Trac-0.11.5.tar.gz
tar zxvf http://ftp.edgewall.com/pub/trac/Trac-0.11.5.tar.gz
cd Trac-0.11.5
python setup.py install
trac-admin /path/to/project upgrade
trac-admin /path/to/project wiki upgrade
/etc/init.d/httpd restart

This blew me away. I ve have never had a complicated app (relativily of course) upgrade so simply, and without any issues. The main install of trac from empty folder to working project manager was simple too, so perhaps I should have expected this, but really I think it is a testimony to how well the developers of Trac have though of the whole process of using their framework.

Recently got the woot.com deal on the eeepc 900, sans webcam. I tried to use the xanadros os that was bundled with it for a few days, but the lack of normal gnu tools and normal packages made me want to switch. So I decided to to look into putting my os of choice fedora onto it.

Installing:

Found that is was a dooable project, exciting and surprising. Since the netbook doesn't have a dvd-rom drive, and I lent out my external, I decided to go the usb live stick route.

Directions for this were easy to find, I did have to use the command line version of them, and found through trial and error that only my name brand Kingston drive would get the netbook to boot.

To get the usb drive to boot, hit escape while booting or hit f2 and set the main drive to be the usb drive. After it boots and finishes and installs, everything pretty much works.

When I brought up the machine I started to follow Gavin's_directions and run a general update. This failed, only because it filled the small hard drive up. I then had to find the /var/cache/yum/updates/packages/ directory and clear it by hand, because yum didn't have the room to run and remove the rpms itself.

Removing things to make space:

So now I had to sleuth around to find out what was taking up all the space on the drive. Using

du -Hs -si /*

found that the largest folder in the root dir was usr. And walking down that path structure I found that the three largest folders, that I could do something about, were:

• /usr/share/locale @332MB
• /usr/share/doc @106MB
• /usr/share/fonts @223MB

So I really went through and removed a whole lot of this stuff, which depending on ones needs, may not be advisable.

I removed all fonts that could using yum instead of just deleting them, as that just really seemed like a bad idea. It took a bit of grep'ing, so this line is a little long, but it basically strips out all the extra fonts, and keeps liberation as well as core font tools and libs. I personally use Anonymous, for all my coding, and terminal work, and I put that in .fonts dir, so really even this is a bit liberal for me.

rpm -qa | grep font \
| grep -ve'xorg' -ve'core' -ve'liberation' -ve'fontconfig' -ve'lib' -ve'bitmapfonts' -ve'ghostscript' \
| xargs yum -y erase

Note also that this removes these apps:

• gimp
• abiword
• evince
• ghostscript (even though I tried not to)

This frees up most of the 200MB that the fonts dir takes up, so we're off to a good start.

The locale directory I was unfamiliar with, but some searching found that this is where data for other language support is stored. I only speak one, and found that removing these doesn't cause irreparable harm. So delete them I did. Since these are installed with every program, and the language packs don't have their own RPMs yum wasn't useful in this case.

ls /usr/share/locale/* -d \
| grep -ve'locale.alias' -ve'default' -ve'en' \
| xargs rm -rf

This frees up about another 300MB. But it is also something that will crop up again, since any new program you install will add it own locale information. For apt-get there is a nice plug-in that will automatically strip out this information for you on install, but in my shallow searching for this for yum there didn't seem to be a substitute. Might be a good weekend project.

The share doc directory I just cd'ed into and wiped out its contents. This is a netbook, and I can ssh into my home machine to read those if I need to, so I freed up another 100 or so MB with this wipe.

This brings us a lot closer to a good 1 GB of free space. I went further and removed a few apps I won't be using:

• evolution
• rhythmbox
• cheese

Now to try and get the services under control.

Found this great listing of what each service does, so if you're unsure if you want to stop as many as I chose to, look it up and make sure. I also chose to use the command line service conf tool:

/sbin/chkconfig  --list

So its a bit time consuming but I went through the chkconfig list and grepped out the 5:on states and checked them against my list below and set them to off one at a time for every run time level. There might be a quicker way, but I couldn't think of one that didn't involve making a script, so I let it be, and stuck with manual.

• cron, atd, anacron
• auditd (also disabled SELinux)
• avahi-daemon
• bluetooth
• btseed, bttrack
• capi
• cups[*]
• firstboot
• ip6tables
• irda
• irqbalance
• isdn
• kerneloops
• lm_sensors
• mdmonitor
• multipathd
• netconsole
• netfs
• nfs
• nfslock
• nmbd
• nscd
• pcscd
• portreserve
• restorecond
• rpcbind
• rpcgssd*
• sendmail
• smb
• ypbind

Now not all of those services were up, but I just made the list of what I would remove, and didn't take note of what was not running in that list.

Then I installed my must haves: xfce, vim, htop, all the dvcs', tilda, and tomboy. I rsync'ed over my dot dirs that I wanted, and I was good.