Yet more on “Life is Good..“: This same hardware can be gotten up and running on Ubuntu 9.04 by manually downloading the debs for the 2.6.30 kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30/ . Things got a little hairy when I hit the nvidia drivers. The theory runs that DKMS should handle all those details automatically. For me, DKMS choked on the nvidia module. One reader on Launchpad suggested installing the drivers first, then the drivers. This didn’t quite work when I tried it. I had to install the new kernel (probably for the source and headers), then run the updated drivers that the reader referenced, then reinstall the kernel (so that DKMS would pick up the new module and use it). I’m sure there’s more rhyme and reason to it all than that, but this is what I had to do to get it running.
Archive for the ‘Linux’ Category
Further Addendums
Thursday, July 2nd, 2009Setting up Bridged Networks (in Linux) For Dummies
Monday, January 26th, 2009I set up VirtualBox to do virtualize some odds and ends testing I was doing (specifically, with the intent of freeing up a laptop to be reissued) and encountered the wonderful problem of trying to bridge the connections to the network at large. With VMWare Server, this is delightfully trivial. The bridged connections are already set up and all you have to do is pick it off the list when setting up the virtual adapter. VirtualBox works the same way, but you have to set up the adapters yourself. So, here are my notes on doing it.
At the system level, what you are doing is creating a bridge (which enslaves a hardware interface) and creating virtual adapters off of it. What you get is something like this:
On Debian (and, by extension, Ubuntu) you can create the devices by editing the /etc/network/interfaces file and adding the following sections:
-
auto br0
-
iface br0 inet dhcp
-
bridge_ports all tap0 tap1
-
-
auto tap0
-
iface tap0 inet manual
-
up ifconfig eth0 0.0.0.0 up
-
down ifconfig eth0 down
-
tunctl_user <user>
The first section creates the bridge and enslates eth0 to it. The second section creates a TAP interface that is assigned to that bridged device.
Alternatively, you can manually run commands like the following to accomplish this task. If you go this route, you will want to take your commands, put them in a shell script, and rerun them at boot time so that your interfaces are recreated after booting up. The utilities are brctl (for the bridge) and tunctl (for the TUN interface). Given the sections above, it is actually pretty easy to know what sequence of commands to run, so I’ll leave that as an excercise for the reader (with the help of the man pages/help section).
There you have it. All you need to know to go crazy and create seven million bridged network devices. While my reason and example here is setting up VirtualBox, it is not the only use for it. Other uses include operating system virtualization, running multiple services on different IPs (i.e. bridging Apache to another address than the main system one), and other general tomfoolery.
Packaging: Debian vs. Gentoo
Saturday, April 7th, 2007If you have read this blog, you know that I have been playing with Debian packaging. I have created packages on both Debian and Gentoo systems and so, here and now, I offer my final manifesto on how they compare.
So, what is the difference? Debian packaging basically archives an installed version of the tree (etc/, usr/, usr/bin, etc.) with a couple of text files that describe the package. What it is, what it depends on, etc. Gentoo doesn’t really package anything. Ever. Gentoo’s Portage system is a network of Python and bash scripting that tells the system where to get the parts for the package, how to configure it, how to build it, and how to install it.
There is a deep philosophical divide here. For the package creator, the tasks are almost completely different. In both cases you have to build the package, but in the case of Debian that is almost all you are doing. You are going to build the package, roll the install into one tarball and pass it around. In Gentoo, you are scripting the build for every single user thereafter. You don’t give them a finished product, you give them a machine-readable build manual. From the package creator’s point of view, it can be a pain in the neck either way. From the user’s point of view it’s a case of convenience versus flexibility. Debian packages are nice and easy to install. No fuss, no waiting. It’s just done. Gentoo’s portage system offers endless configurability and flexibility to build your system the way you want it. Ultimately, it comes down to user preference. Do you want the flexibility or do you want it now? There is no right answer here.
There are other concerns for the package creator. With Gentoo, you are more or less recording the build process. Sure, you sometimes have to do some tinkering to get it to play nice in the sandbox, buut those times are relatively rare and for good old fashioned autotools software, it is a piece of cake. Maybe it’s just me, but Debian seems far more fussy. There has been some software that I just said “oh, heck. I’ll just make install.” rather than fiddle any more with the package.
All in all, I like Gentoo’s system better. It is simple, clean, elegant, and flexible. That’s not to say it is without caveat, but my experience with it has been smoother than Debian. But, hey, who knows? I may write here in not to long about the glories of deb packages–but I doubt it.
Chicken Package–Updated
Thursday, April 5th, 2007In my continued travels on the subject of Debian Packages, I came across a discussion of checkinstall. Basically, the high and low of it is that checkinstall is quick and easy–but the packages will not necessarily work all that well in a clean room environment. This combined with the fact that the paths in the previous package are not quite right, prompted me to build a new package “the right way”. It is now available.
Before I talk about the solution, I wanted to mention a couple of things that researching this problem brought into greater perspective for me.
That out of the way, here is what I did: First, I downloaded and extracted the source. Then I cd’d into the base source directory. Then I ran:
$ dh_make -n -e my-email@my-domain.dom
This command generates default build scripts for the Debian package (note: you will need to ensure that the package for dh_make is installed). The next step is to edit the control file. This will, by default, be created under debian/control. The main changes needed are to the description and to the dependencies. The documentation on the specifics can be found here. As it is relatively straight forward I will not go into detail on it here. Once you have finished with that, you would need to edit the various rules in the rules file. If, however, your software is fairly standard automake
then you probably don’t need to do anything. If, on the other hand, you were using NAnt, Ant, HMake, or some other custom build system you would have to modify the rules file to build properly. After all of this is squared away, simply run
$ fakeroot debian/rules binary
If the previous step was completed correctly, dh_make will spit a shiny new Debian package out
in the parent directory. A good old fashioned dpkg run and the package will install on your system.
Sorta-Seamless Virtualization
Saturday, March 31st, 2007I’d seen an article before about using VMWare to run Windows programs “seamlessly”–as though they were being run from the user’s own desktop. I say sorta because you can try to make the themes and widgets match up, but it just won’t always work. Anyway, today I stumbled across another article and so, with little else to do, took the plunge. I won’t regurgitate the article. This is the link:
https://help.ubuntu.com/community/SeamlessVirtualization
Though the one comment I will make is make absolutely sure that you are logged out before trying to launch your app of choice–if you don’t, you will get the whole Windows desktop.
If I won’t regurgitate, then what am I writing about? Well, after the whole thing worked I got to thinking: normally, if I am not using a VM in any way shape or form, I shut it down. I don’t have limitless resources on this Dell laptop and those CPU cycles are precious. Wouldn’t it be nice if we could boot the VM whenever it is not running but we try to run the program? Why yes, it would and we can do make it happen with VMWare Server’s command line tools. I wrote this in Python, as bash does not have a sleep function (which is needed if the VM boots up so that it will wait until the boot process is finished before trying to connect). In all its glory, with some machine-specific redactions, is the nifty little script I wrote:
#!/usr/bin/python
import os
import time
onoffStream = os.popen('vmware-cmd /
[pathto]/Windows XP Professional.vmx getstate | cut -d " " -f 3')
onOff = onoffStream.read().strip()
if onOff == 'off':
os.popen('vmware-cmd /
[pathto]/Windows XP Professional.vmx start')
time.sleep(60) # wait 1 minutes
os.system('rdesktop -A -s "c:seamlessrdpseamlessrdpshell.exe C:
[path]MyExe.exe"
[privateIP]:3389 -u iuser -p ipass')
Chicken Package
Monday, March 26th, 2007As I was heading out for lunch today, I was thinking about my good old project Latrunculi. I wrote earlier that I was going to put it on hold until I finish Ocean. As Ocean is coming along (at the moment I am rewriting a great deal of the macro expander; the code is coming along cleaner and more elegant than before, but not as quickly as I should long), this could be a while and no wonder. While compilers are not magic, they are not done overnight, either. This leaves Latrunculi hanging. I don’t like to leave projects hanging even though I routinely do it. So I decided to do a quick code audit and see how quickly I could push a first release out the door. I went to do a quick rebuild of the source and then remembered: since switching (for how long, we’ll see) to Ubuntu, I hadn’t installed Chicken Scheme. It is included in the repositories but, like Gentoo, the package was not up to date. The solution was obvious: do what any red-blooded OSS user would do: download the source.
The compilation went down without a hitch and as gobbledy-gook scrolled across my screen, I googled the creation of Debian packages. Why? Well, the whole point of a package manager is to manage your packages. As I quickly learned as a Slackware user (my fault, not Slackware’s) if you do not do this properly, things can quickly become unmanageable, by man or machine. Towards the build’s end, I came across an article on the use of checkinstall (http://www.debian-administration.org/articles/147),
a semiautomated method of generating Debian packages. The basics of Debian packages are easy to understand: a couple of control files and tars containing the actual files for the install–that doesn’t mean that I felt like doing it by hand. Like all programmers, I am fundamentally lazy when it comes to computers. There are bigger, better things to do than haggle with control files. So I decided to give checkinstall a spin. The usage is trivially simple: after building, issue this command as root:
# checkinstall -D installcmd
Where the -D flag instructs checkinstall to make a Debian package (instead of an RPM or tgz) and installcmd is the command to run the install (make install, in most cases). I went ahead and generated the Chicken 2.6 package attached to this blog post. By default, checkinstall automatically installs the package after building it. Sure enough, it worked. The one caveat I did hit was when Chicken tried to load a module that I generated from SWIG it failed, unable to find libpcre. I am not sure of the extent to which this is a problem, but here is the fix. As root, run:
# ln -s /usr/lib/libpcre
That solved the problem on my box.