Thursday, November 22, 2012

OpenClonk

The Free and Open successor to the Clonk computer game series OpenClonk is now available in Debian sid and Ubuntu raring: just use sudo apt-get install openclonk to install it (backports to Ubuntu precise and quantal can be found in the OpenClonk Releases PPA).


It's still under development, but as you can see it's also already quite functional. The engine was made available freely under the ISC license after the original author of Clonk was no longer interested in creating new successors. Many of the old volunteer contributors then picked it up. Be aware that same computer multiplayer, which was available in the older parts of the series, is gone. If you play on the network, you need to ensure that both of you have the same version of the game.

Tuesday, October 2, 2012

How to maintain an OpenWRT installation

I wondered how to properly maintain an OpenWRT installation that needs to track trunk for one reason or another. For instance the OpenWRT release pace is quite slow and "new" devices or various fixes are only available in this particular branch.

Now the OpenWRT project does offer snapshot builds. These are images built with the default config for the particular device type. You can even upgrade most models using sysupgrade, which preserves a list of configuration files you specify when flashing the new image, instead of doing a dreadful tftp upload. But you still lose all the packages you installed and accumulate a bit of cruft when reinstalling them. If you do not flash new images, you will be unable to install kernel modules after a while, because the kernel version they're based upon was updated.

So what's suggested is this:
  • You checkout the trunk from svn. You enable all the feeds you need (e.g. packages and luci) and install the packages you want. (See scripts/feeds.)
  • Run make menuconfig and select the target system type and the device profile.
  • make defconfig will now give you the default configuration for the selected profile. It is important to use this as the starting point.
  • Again invoke menuconfig and select all the packages you need. You can get the current list of packages installed on your device with opkg list_installed. You can search in menuconfig as you would in a kernel build config screen.
  • If you're happy with the configuration, save the difference to the default configuration to a file: scripts/diffconfig.sh > my-own-config
  • Now start the build with make. With the package configuration I picked I need about 5 GB of disk space. It will start off compiling a toolchain, the kernel and then the packages you selected. If something seems to go wrong, you probably want to restart the build with make V=s to see the build messages (the default is pretty quiet). Some -jX option for parallel building might shorten your waiting time.
  • Finally you will get an image in bin/<system type>. You want to grab the squashfs & sysupgrade image.
  • Check /etc/sysupgrade.conf on the live system if files are missing. /etc/config, passwd, shadow and some other files are preserved even if they are not listed. Those are then the only files that are copied into a temporary ramdisk during upgrade and written back to the filesystem post-flash. You need to keep this file up-to-date if you include new packages that have non-UCI configuration.
  • For actually executing the upgrade process, you can either use the luci web interface or start sysupgrade over SSH. For the latter you will have to copy the image yourself. If you go via luci, you should check the md5 hash presented to you against the one of the image on your disk.
  • If you want to update your image, just svn update (in the hope that the OpenWRT developers did not break anything in trunk), get the new defconfig, append your saved configuration delta (the file "my-own-config" above) to .config and run make oldconfig. This will keep track of feature changes in the default configuration (like shadow password support). Update 2013-03-18: To avoid problems with unclean trees you should call make distclean before running make defconfig again. Make sure you have the config diff ready, because cleaning the tree will drop the .config.
The advantage of building an image that includes all the packages is that you don't get to reinstall them and due to the use of squashfs, all files provided by those packages are actually kept in compressed form in flash. The image I built has a size of about 7 MB and contains "heavyweight" packages like isc-dhcpd, bind, openvpn (using openssl), bash, vim-tiny, tcpdump-mini, luci, and a webserver with TLS support.

As always: Take great care when you're flashing devices. The devices I bought cannot be bricked, but this might not be true for all devices that run OpenWRT. You might need and go doing a tftp image upload if something goes wrong. Check the OpenWRT wiki for instructions and possibly make your computer ready for them before starting to play with your box. For my Buffalo WZR-HP-AG300H the sysupgrade procedure is stable.

Sunday, September 23, 2012

Call for testing: Upcoming Squeeze point release 6.0.6

We just sent out a new call for testing for the next point release of Debian Squeeze. The last one was back in May, hence there are a bunch of updates. Please test the packages in squeeze-proposed-updates on some machines running squeeze if possible, so that we don't screw up your production machines with bad updates in a week. The point release is scheduled for September 29th, i.e. next Saturday. Don't forget to copy the debian-release mailing list when you encounter regressions. Thanks for your efforts.

If you want to receive these notices by mail, please subscribe to the debian-stable-announce mailing list.

Saturday, September 22, 2012

IPv6 support in debian-installer, take 2

The IPv6 patch set for netcfg (part of debian-installer) has landed in Debian unstable. In follow-up uploads I diverged from the Ubuntu patch set a little bit:
  • I dropped the use of DUID-LL as the client identifier used by the DHCPv6 client. While basically a good idea, because it's predictable, it's also against the RFC to do that. We simply don't know if the network interface is permanently attached to the device. If the NIC that's used for DUID-LL generation is reused for installation in another box, the same identifier would be generated and stored on the machine. That's what DUID-LLT (the default in other software) avoids. As much as I loathe the replacement of the current MAC address-based scheme of DHCPv4 with DUID-LLT, it seems to be more correct to use that instead of DUID-LL, because that identifier is designed to be decoupled from the presence of the NIC. If you want predictable addressing, just enable SLAAC in your broadcast domain and use the EUI-64 address, which already contains the current MAC address.
  • If SLAAC is used, netcfg will activate IPv6 privacy extensions in the installed system by default. They can be turned off by editing /etc/network/interfaces post-installation. This will only affect outgoing traffic, incoming traffic can be addressed at the stable EUI-64 address. (We don't use a randomized interface identifier like Windows does.)
Thanks to Michael Tokarev's recent upload of busybox, we now also have a more featureful ping and ping6 in debian-installer's environment.

Known bugs:
  • As far as I can see, the DUID generated in the debian-installer environment is not copied into the installed system. Given the low prevalence of stateful DHCPv6 for servers I don't consider this a blocker, though.
  • If stateful DHCPv6 is requested by the router advertisement (other config flag being set), the DHCPv6 client will not time out and continuously retry to get an address.
  • According to Debian bug #688273 preseeding of netcfg/use_autoconfig does not work correctly. netcfg/disable_dhcp needs to be re-added as a deprecated preseeding option and mapped onto the use_autoconfig value until somebody comes up with a better scheme.
  • We should state in the installation guide that ftp.ipv6.debian.org and http.debian.net can both be used for IPv6-only installation. The installer does not show in the mirror list if a mirror is IPv6-capable.
If you could take another look at a current d-i daily, install a system with it and look if the installed system has a correct network configuration, that would still be appreciated. I also need somebody to test the GNU/kFreeBSD image. I fixed it up to build there but the result might be entirely wrong.

My sincere thanks go to Bernhard Schmidt and Karsten Merker, who successfully completed installations over IPv6 in various environments!

Monday, September 3, 2012

IPv6 support in debian-installer

I tried to continue netcfg's journey to support IPv6 in debian-installer. Matt Palmer wrote a large patch set many moons ago (kudos!) and Colin Watson polished it and included it into Ubuntu. The reason for it not being merged into Debian first was ifupdown. Version 0.7 finally supports IPv6 and only entered Debian unstable by the end of May. Due to a bunch of changes to netcfg, one reason being a Summer of Code project on it, I had to forward-port those 50 patches and add two bug fixes on top. Hence it's possible that I introduced some breakage, even if the result works well for me (apart from one DHCPv6 oddity that cannot be seen from within KVM). The tree can be found in the people/pkern/ipv6 branch. I was unable to check if Ubuntu has introduced any additional patches on top of the old patch set, as I'm not used enough to bzr.

This mini.iso (detached signature) netinst image contains a debian-installer current as of today and two additional patched udebs: netcfg with the aforementioned IPv6 patch set and busybox with ping6 enabled. I'd appreciate if you could go and test it in one (or more) of the following environments: IPv4-only (DHCPv4 / static), wireless (IPv4 / IPv6 as desired, there has been some refactoring), stateless IPv6 autoconfiguration (it even supports RDNSS and DNSSL), stateless IPv6 autoconfiguration with stateless DHCPv6, and stateful DHCPv6. It will try to configure dual stack if possible. Please note that many Debian mirrors are not yet IPv6-enabled. Even prominent ftp.CC.debian.org hosts like ftp.de.debian.org still do not support it. So you'll have to pick one carefully if you want to try IPv6-only installation. (Which worked for me!)

If you have any feedback for me, please leave it here as a comment or mail me at pkern@d.o. Thanks!

Tuesday, August 14, 2012

Debian s390x installation now working

With a current daily build of debian-installer you should now be able to install a VM with Debian s390x. I'm told that even installation within hercules works again. d-i's beta 1 for wheezy has a broken busybox and is hence unusable. But there were more issues:
  • zipl-installer was blacklisted from building on s390x by Packages-arch-specific which caused nobootloader to be selected during installation.
  • base-installer was unable to pick the correct kernel image due to it not having any rules for this architecture.
  • A netcfg fix was needed that removes a 50s timeout while d-i tries to arping the configured gateway. This check seems to be pretty new and if it fails the link is still considered up and the installation continues. The network driver commonly used on s390(x) (qeth) uses layer 3 configuration by default, which means that ARP is meaningless. The IPv4 and IPv6 addresses are configured in the network adapter which then does all the ARP if necessary (i.e. not within the same machine).
The resulting installation even boots. But it shares some problems with squeeze's s390 port:
  • udev's persistent network device naming is broken. It includes a volatile device ID that is incremented with each reboot. This is now tracked in Debian bug #684766.
  • The TERM variable is set to linux during boot-up instead of dumb (the s390(x) terminals are either line- or form-based, except for one HMC ASCII terminal). Together with the new fancy coloured LSB init output in wheezy the screen gets even more noisy with all those escape sequences. It's yet unclear where this should be fixed. The kernel provides the init system with a TERM=linux default and it's not yet fixed up afterwards (either in initramfs-tools, or busybox, or sysvinit).
Tip of the day: If you see funny characters in x3270, then you maybe selected the wrong EBCDIC code page. If you use Linux you want to select CP1047 instead of the default CP037 in Options → Character Set (→ Euro). That's the target of the in-kernel ASCII to EBCDIC converter.

Friday, June 22, 2012

The upcoming DebConf 12

Update 2: Richard and especially Moray debunked my statistics and given that they're actually on the DebConf team, they simply know it better what to look at and which numbers cannot be trusted. So look over to Moray's post for some numbers about DC11 and DC12.  

Oops. At least the average count of days per person seems slightly higher. (But then the stats may likely be off, given that any part of the day counts as full.)
This year's DebConf will have remote participation through video streams and IRC chat, as usual. But they will be late at night for Europeans. Despite those hurdles, let's make this conference a success! The same procedure as every year. ;-)

Update: I don't have any privileged access to Pentabarf and hence I was just working on the exported data at the link above. When perusing the "Statistics for ONLY people who have both dates in Penta" I get this:
That's because this year seems to have a much higher percentage of people filling out both fields (~58% for DC10/DC11 and 85% for DC12). I'm still unsure if Penta was set to filter out those who did not reconfirm. But after all the others would not be very meaningful for room planning.

Sunday, June 10, 2012

s390x accepted as release architecture

Yay, so we made it: s390x got added as a release architecture. What this means:
  • If the package already exists on that architecture and fails to build, that issue is deemed RC. You can debug the issue on the porterbox (zelenka), chroot sid_s390x. Build dependencies are installed by a team, just follow the request guidelines.
  • If your package is not installable on s390x, it will not migrate to testing anymore. So if a package does not exist on s390x, you need to make sure not to generate a dependency on it or prevent your package from building on s390x (by e.g. build-depending on a package that's not available on s390x or by getting it into Packages-arch-specific).
This will also help other 64bit big-endian ports (like powerpc64 and sparc64) to enter the archive more easily, as most issues left are indeed related to endianness, not to specialities of the System z hardware.
Many thanks go to Aurélien Jarno, without whom this would not have been possible. I also want to take this opportunity to thank all our s390(x) machine sponsors: ZIVIT, IIC@KIT and Marist College. There are not many mainframe owners who let free software projects work on their machines.

Thursday, June 7, 2012

Adding zFCP drives on Debian GNU/Linux

If you want to add System z zFCP drives to a Debian GNU/Linux system, you first need to make the HBA known to the system. For this you add an (initially empty) file with the (lowercase) device ID of the zFCP HBA to /etc/sysconfig/hardware. There should already be files for the ECKD/FBA disks and the network adapters.

Then you need to list the drives to initialize by placing the following array in it with a list of WWPN:LUN, seperated by spaces within the parentheses:

ZFCP_DEVICES=(0x1234567890abcdef:0x4000400000000000)

Please keep in mind that the WWPN and LUN need to be specified in hex and again entirely in lower case. This will cause hwup ccw 0.0.4000 (with 4000 being the CHPID) to instruct the HBA to add the drive after setting it online. Then you should regenerate your initrd, so that it happens on-boot, by running update-initramfs -u -k all.

With current kernels the available WWPNs should be probed and listed in /sys/bus/ccw/devices/0.0.4000 without further intervention after the HBA is initialized.

Sadly there's no way to set up a zFCP disk in debian-installer.

Thursday, May 17, 2012

Lazyweb question: How to avoid leaking process info?

Dear Lazyweb,

is there a simple way to block some users who login with SSH to read /proc/<pid>/cmdline of processes they don't own? Or better yet: don't see these pids at all?

I know that there are PID namespaces, but they seem to require a special PID 1. Seems hard to get for a simple SSH login. (I wouldn't mind changing a user's shell. But brittle shell startup scripts wouldn't cut it.) systemd-nspawn wants to boot a full Linux distribution in a container and even then I'd be unsure how to wire it up so that it cannot be skipped. I wouldn't mind a read-only bind mount of the outermost Linux installation into a chroot environment, as long as the parent SSH process can get the user jailed into it securely. (No need for someone to be root in the chroot.)

I know that there are RBAC frameworks, but they're cumbersome to use. I don't need file labelling or path-based access control, as I do trust the Linux file permissions for this. I think SMACK wouldn't help here, AppArmor isn't really useable in Debian testing and TOMOYO is a tad crazy to use with its domain transitions through process invocations.

I bet that grsecurity would have something for me up its sleeve. But it's not in a Debian kernel. Even though I know how to compile my own kernel I'd only do that if everything else fails.

Thanks in advance for your help.

UPDATE: That was quick, thanks to everyone who participated! Vasiliy Kulikov came up with a kernel patch to my problem (a hidepid mount option for procfs) that landed in 3.3. I tested it with the kernel in experimental and it works just fine and as expected. With hidepid set to 1, it will still leak the process count and their euids and egids. With hidepid set to 2, you only see your own processes, unless you're root. For ps there's no visible distinction between the two. So to test it you can just invoke this as root on a host running 3.3+:
mount -o remount,hidepid=1 /proc
There's even a backport request in the Debian BTS to get the feature into the wheezy kernel (3.2).

Tuesday, April 3, 2012

The state of Debian s390x

When we added s390x to the main archive, coming from Debian Ports, we were unlucky. A new glib release had assumptions that weren't true on 64bit big endian architectures and it entered the archive just a few days before we made the initial import. This weekend we finally got a new major release into Debian unstable that fixed these issues. So we're almost on par with s390 now. It all untangled quite nicely after glib-networking was able to complete its testsuite. Only one build-dependency loop between nautilus and tracker had to be broken manually.

So what's left? There's a bunch of usertagged bugs (with both general FTBFSes and arch-specific issues; kudos to Aurélien Jarno providing a lot of patches) and we still need to file some, like iceweasel segfaulting during its build. That's important because another bunch of packages needs it to build (well, mozjs and/or xulrunner, or some package that needs those).

Wednesday, March 7, 2012

Daily builds of debian-installer/s390x now available

Thanks to klibc being fixed, rootskel finally built in the archive and hence we've now finally enabled the daily builds of debian-installer for s390x. They're still untested, though, and I hope to come around to that in the near future.

In other news I've spent some more time chasing weird 64bit big endian issues in glib. Newer versions have regressed in their support and again assume that certain fields are either 32bit/64bit little endian or 32bit big endian, which is unhelpful. Sadly the testsuite is guilty as well, which doesn't make debugging any easier. I still suspect a bug in either gio or GClosure's interface to libffi, let's hope that when that one's found that the remainder of the archive is building just fine… (Currently a lot is blocking on glib-networking which fails in its testsuite. And of course there are still usertagged bugs that need to be fixed.)

It would be cool if we could run more testsuites during package building and find the bugs in them. glib does have one, but its failures are non-fatal for the build (also because there are so many failures). That would make porting to future architectures a tad easier.

Saturday, February 25, 2012

gobby.debian.org

TL;DR: Since a few months Debian also hosts a Gobby server. You can find it at gobby.debian.org. To use it, install gobby-0.5.

Gobby is a realtime collaborative editor, much like Etherpad, but as a standalone desktop application. (It's also open source since the beginning.) It resembles gedit somewhat. In retrospect plugging into gedit would've made more sense than to develop yet another editor.

Sadly there's a catch: Gobby had multiple iterations at getting its protocol right. So there are two incompatible versions: Gobby 0.4 and Gobby 0.5. But to confuse you, Gobby 0.4.9x is currently called Gobby 0.5. The lead developer wants to get self-hosting (i.e. the one-click creation of a server) back into the application before he calls it stable.

So to use the aforementioned server you need to apt-get install gobby-0.5, invoke gobby-0.5 and type gobby.debian.org into the "direct connection" field in the lower left bottom. This will give you a document tree on the left, where you can create new documents and folders. Please don't be destructive.

If you have a problem, if no one else can help, and if you can find them, you might contact the admins at admin@$service.

Monday, January 23, 2012

Call for testing: Upcoming Squeeze point release 6.0.4

Adam sent a new call for testing for the next point release of Debian Squeeze. Please test the packages in squeeze-proposed-updates on some machines running squeeze if possible, so that we don't screw up your production machines with bad updates in a week. The point release is scheduled for January 28th, i.e. next Saturday. Don't forget to copy the debian-release mailing list when you encounter regressions. Thanks for your efforts.

If you want to receive these notices by mail, please subscribe to the debian-stable-announce mailing list.