Should you have thought we are gone, let me assure you - we are not. I just blog a bit later than I did the last days. Anyways, we did have a good day yesterday. Turns out that, when Ansgar said I don t know much Python so might not be able to do much he actually meant Just point me at problems, no matter how complicated, and I come up with the python code to fix them . And so we did point him at various problems and got lots of code. And we intend to continue this until Sunday. Yesterday Mark got his Packages/Sources tool so far that we are about ready to ditch the old things, even though he took time to finalize my generate-release changes too. Not to speak about that database changes I wrote about in my last entry, which he now seems to have finally wrapped his brain around in a way to get those done. Short cite: good god, this will overhaul about all our code and database handling . And thats where he is currently working on too. He did draw a plenty complicated thats how it works onto the flip chart, and now seems to dump his brain into some form of python code. I m curious about the result, lets see. Torsten fixed up the code that generated the Maintainers and Uploaders files. The old code was just plain silly and took about 15 minutes just for the Uploaders file. It is now doing both of them in less than two. Of course there had been lots of bugfixes and code enhances too, not really good to list in a blog like this. My work, besides getting a bit sick in the evening, consisted of writing shell scripts to enable us and wanna-build admins to handle the keys needed for the automated signing of packages build on DSA maintained buildds. I have those ready now, so we are able to start doing the autosign stuff today/tomorrow. Phil - well, did whatever buildd related stuff he has to. Different place, I dont see much of it, but he has a blog himself, look over there.

Having Synology diskstation, notebook with XBMC and smart phone with Symbian, it should be possible to make all these talk together being able to play music stored on the diskstation using XBMC and controlled by phone, right? I tried to set it up some time ago, but I used samba export on the diskstatio and all I found for controlling was XBMC Symbian S60 Remote v2, which is indeed useful, but choosing what to play remotely is quite limited. Luckily yesterday I've discovered world of DLNA aka uPNP and was surprised that this works pretty well. I've configured diskstation to behave as a uPHP media server, XBMC is able to act as media renderer and my Nokia E52 has ability to act as a controller. If you are lost in these terms, good overview is available here. Well the control interface of Nokia E52 is far from perfect, but still provides good way to control all the stuff. Maybe I will look for some other solution in future, I'm sure it will exist as well.

Filed under: English 2 comments Flattr this!

If you are wondering, how we will manage to have the DebCamp preceding DebConf 11 in 2009, it's quite easy: Each attendee will find a time machine in his conference back. By the way: To make that happen, the DebConf orga team is looking for help in fund raising. Please consider helping us, or we will have to cancel the time machines and fall back to the boring DebCamp directly preceding DebConf solution.

Exactly a year after I switched from pre to droid, I broke another cell phone contract. So there seem to be three fool-proof ways to get out of a cell phone contract in the US, despite all the hype about them involving signing away your firstborn.

1. Switch to a different US cell phone company, and do it by going into a store and finding a hungry salesman in person, and making his sale contingent on him finding a way to break your old contract. What I did last year.
2. Simply move to a part of the map that doesn't have cell phone coverage. (You will have seen these parts of the map from a plane.) It probably helps to have your cell phone drop off the edge of their map repeatedly for some months, presumably they can look this stuff up. Call up technical support, go thru some mild rigamarole as they try to configure your phone to magically see cell towers that have several mountains and/or the curvature of the Earth blocking line of site to you. Magic words: "please note on account: no cell service"
3. Sell your contract on one of the existing cell contract exchanges, to someone who wants cell service with a shorter than usual contract. (Means giving up your number.) I haven't tried this one, maybe next time?

Unlike my Palm Pre which didn't survive being cut off the cell net, my Android phone is still fairly happy. While I'd really like to turn it into a proper Debian box, with X etc, I may just use it as a camera, web browsing (on wifi) and emergency 911 system. Pity though about the GPS stuff needing an internet connection when the phone has many gigabytes of free space that could hold a useful map. (If you want to phone me now, the number is 1-423-IKIWIKI. I only receive voice mail, and your call data and transcript will be absorbed by the Google Borg.)

I wrote this code today to verify setup branch pushes on Branchable. When I was writing it I was just down in the trenches coding until it worked, but it's rather surprising that what it does to git does work. The following code runs in git's update hook. The fast path of the hook (written in C) notices that the user is committing a change to the setup branch, and hands the incoming git ref off to the setup verifier.

                # doing a shared clone makes the setupref, which has
                # not landed on any branch, be available for checkout
                shell("git", "clone", "--quiet", "--shared",
                        "--no-checkout", repository($hostname), $tmpcheckout);
                chdir($tmpcheckout)   error "chdir $tmpcheckout: $!";
                shell("git", "checkout", "--quiet", $setupref, "-b", "setup");

I got lucky here, since I initially passed --shared only to avoid the overhead of a clone of the site's entire git repository (which can be quite large, since Branchable doesn't have any real limits on site size). Without the --shared, the clone wouldn't see the incoming ref at all. In the setup branch is an ikiwiki.setup file, and we only want to allow safe changes to be committed to it. Ikiwiki has metadata about which configurations are safe. Checking that and various other amusing scenarios (what if someone makes ikiwiki.setup a symlink etc) takes a hundred lines of fairly hairy code, but that doesn't matter here. Eventually it decides the setup file is ok as-is, or it's already died with an error message.

                # Check out setup file in toplevel. This is slightly tricky
                # as the commit has not landed in the bare git repo yet --
                # but it is available in the tmpcheckout.
                shell("git", "pull", "-q", $tmpcheckout, "setup");
                # Refresh or rebuild site to reflect setup changes.
                print STDERR "Updating site to reflect setup changes...\n";
                shell("ikiwiki", "-setup", "ikiwiki.setup", "-v",
                        ($rebuild_needed ? ("-rebuild") : ("-refresh", "-wrappers"))
                );

When this code runs there are three repositories, each with a different view of the setup branch. The main bare repository is waiting for the hook to succeed before it updates the ref to point to what was pushed. The temporary clone has what was pushed already checked out. And the site's home directory still has the old version of the setup branch checked out. Possibly even a version that has diverged from what's in the bare repository. It's rather odd that the update hook goes and causes that latter repository to be updated, before the change has finished landing in the bare repository. But it does work; it ensures that if there is some kind of bizzare merge problem the user doing the push sees it, and I probably won't regret it. The result certianly is nice -- edit ikiwiki.setup file locally, commit and push it, and ikiwiki automatically reconfigures itself and even rebuilds your whole site if you've changed something significant.

I know this is almost a cliche, but here goes. Just to show you that it still exists. Today my car needed some work. This morning I dropped it off at the mechanic, who lives right off a well-traveled state highway. They don t have a dropbox for keys because, well, they don t need one. I left the keys in the car. They called to say that they d have to close early this afternoon, but not to worry the keys were in the car along with the bill, which I could drop by and pay or put in the family s box at church. And sure enough, the car sat there the rest of the afternoon, and until about 9:45PM, with the keys in the ignition, bill tucked in under my ham radio speaker, ready to pick up. And it wasn t at risk for being stolen. Things just sort of happen that way out here sometimes. I remember one time we were taking a train out of Newton, KS, which departs at about 3:30AM. The only other train through there departs at 3:00AM. And back then, there was sometimes no station agent on some days. We got there our usual 15 minutes before the train departed, and struck up a conversation with a couple from California. They were almost beside themselves with shock. First off, they had arrived an hour and a half early, being used to doing that for getting on planes and, apparently, trains. But what really stunned them was the fact that the station was simply left unlocked all night. There weren t any cops there, and in fact there was nobody there at all for most of the night. And yet it had no signs of graffiti, no vandalism, and no apparent concern from anybody that it was unlocked. I think they also felt unsafe, having no guards or officials present. And they were literally the only people in the station for an hour, I m sure. And sure enough, along came the train. We all heard the whistle and had our things ready to go by the time the conductor got off the train, walked into the station, announced it, and led us all out to it. 3 minutes later, we were all on our way to California and the land of, apparently, locked doors. Back in 2002, when we bought a house in Kansas, the inspector commented that none of the outside locks worked. At closing, the sellers gave us a key, commenting We never use it and it took forever to find it. I guess that s why they didn t know the locks were broken. There s something good about a setting like this. I know that my car is safe at the mechanic with the keys in it. He knows that I ll pay his bill. We all take pride in our community institutions. And besides, if anybody did try to spray some graffiti in the train station, they ll be living with people that will remember it for the next 40 years. Accountability is implicit here.

I finally found some time to convert my backport script to support squeeze (mostly because I finally did my first backport to squeeze). The script now treats squeeze as the default target and knows that it's the current stable, treats lenny as oldstable, and knows the correct version suffix to use for squeeze backports. It also now uses regular expressions to try to determine what code name a backport is targetted at, which should work better for more non-Debian internal distribution cases. You can get the latest version from my scripts distribution page.

I'm experimenting with building Qt Embedded for armel using Emdebian toolchains and Debian packaging/patches. Initially, I've just "got it to build" with a few too many things nobbled and disabled - the results (using the package from Squeeze) are in Emdebian SVN - and the next task is to enable the missing bits and get closer to the standard Qt4-X11 binaries. Certain packages will simply not exist, even when finished, but it's been fun working out how to create a qmake.conf to map the Emdebian toolchain to what Qt expects from toolchains like CodeSourcery.

If it continues to work, it may be worth pushing upstream - but it may be better to wait until Multi-Arch supports cross-building, I'd only have to submit a different qmake.conf with updated paths otherwise.

I've also got a basic qmake.conf to help Qt applications cross-build using the Emdebian toolchains. This also needs updating once we finally get Multi-Arch-Cross.

The way I see this working is that the Qt Embedded packages would have to kept entirely separate from the Debian Qt4-X11 binaries from the KDE/Qt team because they use the same package names. That's relatively simple if the embedded packages are kept for cross-building only, either as -armel-cross packages generated by dpkg-cross or (eventually) as Multi-Arch packages. What won't work is having Qt-X11 and Qt-Embedded installed on the same architecture, without using a chroot or similar.

Initially, I hoped to keep the changes small enough that the Debian package could include the tweaks in a conditional part of debian/rules via a DEB_BUILD_OPTION. The current diff is a little too awkward (mainly in the .install files) but that's still worth keeping as a goal.

No warranty, created in the hope it's useful etc. etc., nothing to say it'll build on your system, no support for anything except the Debian armel port and only tested with the Emdebian toolchains from Lenny, not coming to a distribution near you anytime soon, don't blame me if it messes up your entire Qt-X11 installation on your desktop.... yada, yada.

It's just a bit of tinkering really, although it would be more fun if Qt didn't take quite so many hours to build each time I want to test a change....

In case you are using HP ProLiant G6-series or G7-series with Intel-based hardware and you are thinking about virtualistion (e.g. booting the hypervisor), you should have a look into this customer advisory. To make it short, the following should work:

# grep GRUB_CMDLINE_XEN /etc/default/grub
GRUB_CMDLINE_XEN= pci=use_crs
# update-grub It took me two workdays to discover this solution for a DL180G6. Anyways I m still having trouble on a DL160G6 when booting the hypervisor, suggestions are welcome.

And here we are, with another day of work ahead. And another huge unchecked/dinstall run about to finish. Yesterday evening Ansgar and later on Phil turned up, so we are now 5 persons sitting here and mostly coding happily away. Mark continued trying to wrap his brain around the changes we need to properly support multiple archives, with different sets of rights attached to them. It is a complex topic giving lots of headache. Besides that he is on a very good way of letting us completly remove apt-ftparchive by importing all the data we need to write Packages/Sources files on our own. And even better, the same work we can use to rewrite our rm and cruft-report commands in a sane way, not parsing Packages files anymore. Torsten did help with various database issues around the Packages/Sources issue and continued working on importing all the source filenames into the database, so we can soon provide a Contents file for sources. My own work, besides writing blog entries and preparing meeting minutes, consists of a rewrite of the script generating our Release files, the old one just wasn t up to it anymore. Especially not as we are on our way of having more and more of our tools use parallel processing, to fully use the power our ftp-master host has. And when I am done with this I will be off to tackle the keyring maintenance part we will need to enable autosigning by buildds to work. Should get interesting, with the shit of an interface one usually finds to gpg Ansgar started out by working on changes to our NEW handling, something I started with the dpkg bug #619131 and he just finished our site of the NEW handling scripts. Which means that, as soon as the dpkg maintainers added the code on their side and support this field in the .dsc files, NEW handling for packages like linux-2.6 will be much smoother. He is now implementing version control constraints into our control-suite tool. Phil is working on wanna-build stuff. And while this is just a short overview of what we did, there is always lots of discussion and bugfixing going on. It is incredibly useful to have a team sitting in one room for some days.

Update: Despite another email yesterday reasserting the 90-120 days lie, the source code has now landed on HTC's site.

As has been discussed before, HTC have a somewhat "interesting" interpretation of the GPL that allows them to claim they don't need to provide source code until between 90 and 120 days after the release of binaries. It's probably noteworthy that the FSF (who, you know, wrote the license and all) disagree with this interpretation, as do the kernel copyright holders (who, you know, wrote the code that the license covers) I've talked to about it. Anyway, after a pile of screaming and shouting from all sides HTC have tended to release their source code in a timely manner. So things seemed better.

HTC released the Thunderbolt last week and we're back to the 90-120 day song and dance. It's probably worth remembering that by behaving in this way HTC gain a competitive advantage over any vendors who obey the terms of their license - HTC can incorporate improvements made by others without releasing their own until through a significant portion of the lifecycle of their phone.

As far as I'm concerned, every single Thunderbolt sold so far embodies a copyright infringement. Wilfully engaging in copyright infringement for commercial benefit is typically frowned upon by courts, especially if by doing so a foreign company is gaining commercial advantage over a domestic one. If you think Microsoft's patent assault on Android is a problem, just imagine what they could do if they hired one significant Linux kernel developer and used their copyrights to attack the overwhelming majority of Android vendors who fail to comply with the GPL. It probably wouldn't be industry ending (companies would merely have improve their compliance procedures) but it'd do a huge deal of damage in the short term. It's insane for companies to behave this way. Don't reward them by giving them your money.

I'll be talking about this at the Linux Foundation Collaboration Summit next month, along with an update on my study of the compliance of Android tablets. I'm hoping that there'll be further developments after that.

I ve posted #Budget11 one #coops response on UK.coop because it s a bit long and I doubt many of the people reading this through software-related sites will want to read it. If you re interested in UK co-ops and the budget, click through to read points including:

• it s a mixed bag for co-op members and not really clear if we win or lose. The BBC reckons individuals will lose about 400 on average.
• Basically, the business measures which I can understand are bad for co-ops and seem to be aimed at private businesses, but some of the other things might be useful.
• Co-operatives UK general secretary Ed Mayo asked for changes to employee share ownership annual tax concessions, easier starts for co-operatives and encouragement for grassroots successes. I don t see any of those in this budget. Do you?

Comment here or there, as you prefer. I ll read both every day or so for the next little while.

Another release (1.1.90) by Conrad Sanderson for his wonderful Armadillo templated C++ library for linear algebra appeared yesterday. Consequently, a new release 0.2.17 of RcppArmadillo, our Rcpp-based integration into R is now on CRAN mirrors. The short NEWS file extract follows below containing just Conrad's entry for 1.1.90. No further changes from our side.

0.2.17  2011-03-22
    o   Upgraded to Armadillo Version 1.1.90  "Inside Job"
         * Added .min() & .max(), which can provide the extremum's location
         * More robust mean(), var(), stddev()

And courtesy of CRANberries, here are the diffs to the previous release.

 ChangeLog                                                    6 
 DESCRIPTION                                                  8 
 inst/NEWS                                                    7 
 inst/doc/RcppArmadillo-unitTests.pdf                     binary
 inst/doc/unitTests-results/RcppArmadillo-unitTests.html      6 
 inst/doc/unitTests-results/RcppArmadillo-unitTests.txt      36 +-
 inst/include/armadillo_bits/Cube_meat.hpp                  112 ++++++++-
 inst/include/armadillo_bits/Cube_proto.hpp                  14 -
 inst/include/armadillo_bits/Mat_meat.hpp                    98 +++++++
 inst/include/armadillo_bits/Mat_proto.hpp                   10 
 inst/include/armadillo_bits/arma_version.hpp                 4 
 inst/include/armadillo_bits/fn_prod.hpp                     12 
 inst/include/armadillo_bits/fn_stddev.hpp                   18 -
 inst/include/armadillo_bits/fn_var.hpp                      18 -
 inst/include/armadillo_bits/glue_mixed_meat.hpp             22 -
 inst/include/armadillo_bits/op_max_meat.hpp                199 ++++++++++------
 inst/include/armadillo_bits/op_max_proto.hpp                21 +
 inst/include/armadillo_bits/op_mean_meat.hpp               154 +++++++++++-
 inst/include/armadillo_bits/op_mean_proto.hpp               22 +
 inst/include/armadillo_bits/op_min_meat.hpp                199 ++++++++++------
 inst/include/armadillo_bits/op_min_proto.hpp                19 +
 inst/include/armadillo_bits/op_stddev_meat.hpp              44 ++-
 inst/include/armadillo_bits/op_stddev_proto.hpp              9 
 inst/include/armadillo_bits/op_var_meat.hpp                198 +++++++++++----
 inst/include/armadillo_bits/op_var_proto.hpp                14 -
 25 files changed, 925 insertions(+), 325 deletions(-)

More information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

I have been reading Linux Shell Scripting Cookbook by Sarath Lakshman, published by Packt, for a while. While most people I know learn shell scripts themselves, I was looking to refresh my concepts a little as well as have a reference lying around on the table for fast access. Since I was asked to review it for someone else, I thought I might as well post the review here.First of all, let me remark by saying that shell scripting is something learned more on a need basis than as a tool to solve the main problem. People would seldom write shell scripts as standalone programs (exceptions exist). However, what makes shell scripting invaluable to know is the fact that knowing some tricks can save several minutes, or hours, of work by automating and simplifying certain tasks, generally (but not restricted to) file management and data processing. Linux Shell Scripting Cookbook does go quite far in pursuing this goal, and is appropriate for both beginners who are looking to gain dexterity in shell scripting, as well as intermediate users who wish to polish their skills. The book also can double up as a quick reference, though I would argue that the "Advanced Bash Scripting Guide" would suit that more.At the outset, the author clarifies that the focus will be on Bash. This, people may or may not like, but the fact that bash has become ubiquitous in terms of the available shells on Unix-like systems today, starting out with bash is not a bad thing to do. Besides, learning other shell scripting languages while knowing bash isn't too hard, since the paradigm remains the same.Let's go through the books from the aspects I found most relevant.OrganizationThe book is organized into chapters based more on utility than scripting concepts themselves, although the language aspects are brought onto the reader gradually. For instance, the examples in the first chapter focus more on the basic data elements (variables, arrays, functions etc.) as well as operators (for numbers, files etc.), and all the examples demonstrate simple usage of these concepts, and he further chapters build upon these in a gradual manner.At the same time, if the reader has some familiarity with shell scripting and needs to only refresh or learn a certain concept, he/she needs to just read the relevant chapter. It is not too difficult to grasp the examples of the later chapters, provided some basic shell knowledge is assumed.Content and PresentationA positive trait in the presentation of this book is that it is all based on practical everyday examples which, with minor adaptation, can be used by many for their own daily tasks. For instance, there are several examples which describe searching for and processing files, which, I'd imagine, many users would want to do on a regular basis. Thus, providing realistic examples allows the book to double its utility. The language and approach used is simple and conversational, and the presentation is very clear, with each idea being described as a problem statement followed by a "How to do it" section with the actual code, and ending with a discussion of the nitty-gritties of the code. It is easy to go for a quick scan for those in a hurry, while those who with to read in more detail will not be disappointed either.The book also covers a wide array of applications. For instance, there are examples on automating fetching web pages and processing them, demonstrations of parsing and simplifying and even some queries around databases wrapped around in shell. It also spans to utilities and tasks connected to statistics, backups, compression, version control and many more.Breadth and DepthThe book goes into a fair amount of detail in terms of describing the shell scripting concept under consideration. The examples used go into a fair amount of detail in order to describe to the user all the aspects involved in the method or command being used. The concepts described are fairly complete, and would be sufficient for the reader to use immediately or with just a little bit of fine tuning. In terms of breadth, the book covers most of the features of shell scripting while also describing the various facilities the shell provides access to in a Unix-like environment. Thus, the book does not disappoint in this front either.In summary...In summary, probably the only thing I'd have liked to see more of is some emphasis on how to write more efficient shell scripts. Granted, most of the shell scripts described in the book are very simple and succinct, but a some words on how loops can be made better, or how to spot situations where pipes are not needed to solve a problem etc. might have been a nice addition. Some explanation of differences with dash, tcsh, zsh etc. might also have been nice, since a lot of users have different default shells. But all this isn't going to prevent me from giving this book a high rating, since it delivers quite well on the promises it makes at the beginning.This is definitely a good book to have near your desk, and kudos to the author for having taken the effort to put it together. I would highly recommend it to the beginner and occasional shell user for a thorough read, and to an intermediate to have on his/her desk for borrowing the cool scripting ideas and applications the author has written in this book.

The Abel prize for 2011 has been awarded to John Willard Milnor.[1] In response to a query from Dr. R. Ramachandran who writes about Science and Science Policy for The Hindu'' newspaper group, I wrote the following short piece which others may find interesting as well. Milnor is well-known for his work on topology and geometry. He has also made significant contributions to algebra and even number theory. In addition, he has written a number of books which are loved by graduate students in Mathematics all over the world. One of the striking early results of Milnor was the example he gave of a seven dimensional space which is topologically a sphere but its geometric (differentiable) structure is different. This was the first example of an "exotic sphere". A nice way to state his main result (due to Ajit Sanzgiri) is that "Groups of homotopy spheres are homotopy groups of spheres". Milnor received the Fields' Medal in 1962. In addition, the work of a number of later Fields' medallists such as Donaldson, Thurston, Mori and Voevodsky can be seen as having roots in the work of Milnor.

---

[1]The last time I wrote about the Abel Prize was to contribute to a guest post to Rahul Basu's science blog: The Far Side. Unfortunately, Rahul is no longer among us. This post is dedicated to the memory of Rahul Basu.

Yesterday I was hinted towards lxc when I wondered what happened to openvz in unstable (which unfortunately isn't documented at all in the kernel changelogs, but that's a different story). So I started off taking a look. From a bit of experimenting around with it I consider it something that I want to play more with, and I want to share the problems I stumbled upon with you so that you don't have to figure them out on your own. First of all, LXC uses the cgroup kernel facility for resource management. The according file system isn't mounted by default, and LXC doesn't care for where it is mounted, it just needs to be. It seems like /sys/fs/cgroup seems to be the proper place (see 601757), so add the line cgroup /sys/fs/cgroup cgroup defaults 0 0 to your /etc/fstab file and sudo mount cgroup it. Next, it seems like bridging is the defacto standard for networking with lxc, but given that I want to use it on my notebook while being mobile I can't bind the bridge to any specific interface. To make this happen, one needs the bridge-utils package installed, and secondly, this is the path that I chose. I've added to /etc/network/interfaces this snippet:

auto br0
iface br0 inet static
    bridge_maxwait 0
    bridge_ports dummy0
    address 10.80.80.1
    netmask 255.255.255.0

This will bring up the bridge and act as gateway. For the running system, call sudo ifup br0. To make the host universally being able to work as gateway, of course ip_forward needs to be enabled. For this I added the line net.ipv4.ip_forward=1 to /etc/sysctl.d/local.conf (and for the running system, echo 1 into /proc/sys/net/ipv4/ip_forward). As I am using ferm for configuring the firewall on my notebook I have to add some parts into its configuration. This is the raw part that needs to get added, mix it into your existing configuration:

table filter  
    chain INPUT  
        # allow DNS queries from LXContainers
        proto (udp tcp) dport domain source 10.80.80.0/24 ACCEPT;
     
    chain FORWARD  
        # allow LXContainers into the net
        source 10.80.80.0/24 ACCEPT;
     
 
table nat  
    chain POSTROUTING  
        # NAT LXContainers
        source 10.80.80.0/24 MASQUERADE;
     
 

For DNS I installed dnsmasq so that I won't have to touch the /etc/resolv.conf inside the containers whenever I switch networks. So far for the host part, now to the actual containers. There is the /usr/lib/lxc/templates/lxc-debian helper script which uses debootstrap to create you a lenny chroot at least in the squeeze package this is hardwired, likewise with using cdn.debian.net. Copy the script and edit it to your likes if you feel like it. From what I understood it expects you to store the containers below /var/lib/lxc, I haven't yet tested for different places. So this was my commandline for that:
sudo /usr/lib/lxc/templates/lxc-debian -p /var/lib/lxc/vm0 A while later you'll end up below that directory with two entries: The config file and the rootfs subdirectory which is actually the bootstrapped distribution part. Now comes the configuration of the container. Open the config file with your favorite editor and add the following lines to the end:

lxc.utsname = vm0
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
# lxc.network.name = eth0
lxc.network.hwaddr = 00:FF:80:80:80:80
lxc.network.ipv4 = 10.80.80.80/24

The network.name part is commented out, it defaults to that name internally; you though can change it to whatever you prefer. Caution, even though this is the documented approach, it does not work for Debian containers. It will always try to get its IP address through dhcp, lxc.network.ipv4 has no meaning for us. We need to change inside the rootfs the file etc/network/interfaces to read like this instead:

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
   address 10.80.80.80
   netmask 255.255.255.0
   gateway 10.80.80.1

I suggest to keep the config and the interfaces file aligned with respect to the ipv4 setting so if this gets fixed upstream you won't stumble into any surprises. Also like mentioned before, we need to change the nameserver entries inside the rootfs file etc/resolv.conf to read nameserver 10.80.80.1. Now it's time to start it up and log in! sudo lxc-start -n vm0 -d will start the container in the background, and sudo lxc-console -n vm0 will give you the login to the container. The default password for the root user is root, obviously you want to change that before you install any networking services into the container like ssh-server. In case you want to quit from that console notice the message upon starting it, it's bound to <Ctrl+a q>. One more issue that I had: The default route wasn't set. I had to manually call ip r a default via 10.80.80.1 dev eth0 to be able to use the network inside the container. It seems to be related to that netbase isn't installed by default. If you install it the default route will be set upon starting the container automatically. This should get you started, there is of course more to explore and experiment with. Actually it is also suggested to create a tarball from your vm0 after you did the basic setup and installed the basic components you want to have around so you won't have to bootstrap over and over again. Do this after you have shut down the container, either through a halt from a container shell or through sudo lxc-stop -n vm0. The tarball can then get extracted to a different directory and just needs minor tweaks in the config and rootfs/etc/network/interfaces file to not create any clash with other containers (lxc.rootfs, lxc.mount.entry, lxc.utsname, lxc.network.hwaddr and ipv4 address). About limiting the containers, you can do it dynamically through the cgroup file system, and set it permanently through the config file. See man lxc.conf about these settings, amongst others. Enjoy, use, experiment. With sudo lxc-checkconfig you will see what your kernel actually supports for your LXCs. You will most probably notice the missing for the memory controller, this is tracked in the Debian bug report 534964.

/debian permanent link Comments: 6 Flattr this

Good morning, and welcome to another day of archive damage, i mean hackery. Well, at least at the time of this writing it is morning and we are starting off into another day of work. As we promised to try to have at least a once-a-day-installation run I am currently processing the queue of uploaded packages, around 4gigabytes from 431 changes files. After that a dinstall will follow to push that all out. Lets see how often we can do this again today, yesterday we managed multiple times. Yesterday my work consisted of getting the ries sync into something nice and acceptable, starting to think of the change to only use the suite codenames in future (long term making lots of code issues easier, but short term a good headache) and doing the groundwork so we can upgrade the security and backports archive to squeeze/pg9 too. Mark finished of the Built-Using flag and then moved on to think about database file tracking changes related to multiple archives/locations. Which sounds simple in so few words but is definitely not simple at all. Torsten started to work on source contents and also on generating the packages/sources files out of our database. Both together is taking a good amount of time, so he continues to work on those today. In the evening we had a meeting with the Debian Hurd porters about the future of their port within the Debian archive. The perceived Hurd situation until then was that every port has to follow certain rules or gets thrown out but Hurd doesn t seem to ever get into a releasable state . Well, we did get a clean view on both sides standpoint and in the end emerged with a solution which works for both sides: The Hurd port stays on FTPMaster until Wheezy is released. Should they have managed to get the port into a state that it is released together with all the others (probably as a technology preview), it is kept in the archive. Should they not manage this, the port will be removed from the main archive and move fully to debian-ports.org. It may then reenter the main archive whenever it is ready to get released with the next release. For today we are all continuing in our parts, Mark is yelling at the insanity of the multi-location thing (something we DO need when we want to merge multiple archives, which we do want), Torsten curses the code for Packages/Sources and while I hope that DSA can find time today to upgrade our security- and backports-archive machines to Squeeze, I try to wrap my head around the code we kindly got provided by Serafeim Zanikolas - the dinstall programming fun task I asked a while ago. Im not sure yet I will succeed. :) And then we will get more arrivals this evening, so more people doing stuff tomorrow.

...and me. I turned 40 today and on such a momentous occasion I should pause
to take stock of my life. Executive summary: it's not bad at all. Last week I completed 13 years of marriage to Jyoti who loves me and always
looks out for my best interest even during the times when I do not. I have two lovely children who are kind, intelligent, Dharmic, and (mostly :-)
well behaved. Of course I can't forget all my dear friends and family who gave me their
blessings and good wishes today and indeed every day. My health is better now than it was in my twenties. Since last year I've been
exercising on the treadmill regularly and taken a lot of junk out of my diet.
I've lost about two stones and while I won't be joining the Debian marathon
runners just yet, I can at least jog briskly without collapsing in a puddle of
sweat, heart palpitations and shame. Mentally, I've been taking college level courses in Maths in an effort to
relearn the things I didn't pay proper attention to the first time I was in
college. I completed National Novel Writing Month for the first time with a
60,000 word philosophical science fiction blockbuster that other people might
actually consider readable once I finish revising it. And I am still training
for the day when I shall be granted the spot on Jeopardy which is rightfully
mine. Financially, the last few years have not been good for many people but we are
holding our heads above water and even slowly moving forwards. This is the
year Consolidated Braincells Inc. my little corporate empire will take off I
hope. As I begin preparing for Chaitra Navaratri I feel it will be extra special
this year because all these good things that are happening to me are solely
due to Her grace and krpa. Last thing I wanted to mention is that a present I gave myself today was to
make a donation to the Red Cross to help the victims of the tsunami in Japan.
If you have had good fortune in your life and have not already done so won't
you consider doing the same? (or to any of the other reputable charities
engaged in disaster relief.) Our shastras say that dana is the best insurance
against accidental sins and the guarantor of good luck.