Apr 302014

As much work has been done on LXQt, PCMan has just proposed an alpha release soon.
I have updated the build scripts for Slackware in my git, and this is the sbopkg queue (using my git repository with it) that you can run to install all of its components


Beware that everyhting is still a rough and some things needs to be adjusted, but if you choose to install this now is also to help testing it (and report problems upstream) :)

sample screenshot

a sample screenshot

I won’t prepare packages for now, but I’ll do it after this will be tested a little ;)

Mar 072014

I have updated the build script for lxc: now it builds the just released 1.0.1, with the added support for the new cgmanager from Serge Hallyn (this depends on libnih).
Remember that optional dependencies for the new lxc are also python3 and lua.


for some interesting articles on this new version have a look at this series of blog post from Stephane Graber. ;)

Dec 232013

In 1997 I worked in a very big press farm: we did lot of works related to drugs packaging and we worked on high volumes, so they eventually decided to try a new technology (at the time), one of the first models of Computer To Plate from Krause.
That was an amazing (and huge: more than 15 meters!) machine, it totally revolutioned our work at the time: for most of our commissions we hadn’t no need anymore to do computer -> prints -> films -> plates but we could go straight from computer to plates (and use them on the presses): we printed on a postscript printer exported by a Sun Ultra, on which we assembled the print layout and then we imposed it (with a laser) on 70cmx100cm plates (in a granite tub).
As Krause sent german technicians and I was the only one that knew english enough in that department, I was the one who was teached to use the machine :)
That was fun, and I also got in touch with X-Windows on the Ultra boxes, running SunOS and a desktop environment I was seeing also for the first time, CDE.


CDE running on Slackware

After a while I moved to another job and I never had the possibility to work on CDE again.
Then, last year, the Open Group released it as open-source \o/
As the released codebase was 15 years old, a lot of work had to be done to make it usable on modern computers, but much has already been done and recently a beta has been released.
So, despite it being still unripe and driven by curiosity and nostalgia, I decided to package the version they got in their git


If you want to try it, read very well the README in that folder, as some (and a little invasive) manual steps have to be taken before building/installing.

Hope the older ones of you will got the same weird feeling as me, watching it running on Slackware :D

And, while I am at it… Merry Christmas and happy new year! ;)

Dec 032013

Maybe someone of you had heard about the fact that LXDE developers didn’t want to get dragged into the GTK+3 mess and that they decided in march of this year to merge efforts with the Razor-qt people to develop together a lightweight DE based on Qt (see the various post on the LXDE blog and on their mailing list for more informations on this).
So they picked some stuff from Razor and PCMan wrote much other from scratch: as he says, they haven’t reached a point in which this is usable in a production environment but, left away some bugs (pcmanfm-qt doesn’t seem to show icons at all here), I think it’s already looking acceptable. :)
So I decided to prepare build scripts and packages for Slackware 14.1 from what’s available on their git to let you try it and eventually report bugs upstream: read very well what’s written in the download folder, keep the expectations low and grab ‘em while they’re still hot. ;)

Nov 092013

I tried to find a little time to build fresh sets of packages to have an LXDE desktop on the just released version of Slackware: you can find them in the usual place :)

64bit 32bit

as a lot of people seems to use slackpkg+, the folders linked above contain repositories compatible with Zerouno’s slackpkg extension ;)

hope that I’ll find some time to install a fresh slackwarearm-14.1 on one of my raspberries and prepare them also for that platform.

Oct 102013

As we are developing a php database interface for a project here at work and some related functions are being deprecated starting with php 5.5.x I considered upgrading our php installs on our servers and test if it works fine with our stuff.

As I’m using Slackware on my servers I managed to update the existing build scripts to build from a php 5.5.x tarball and I installed the new package on slackware64-14.0 and slackware64-current: in the next days some tests will be done with the new things we’re working on but, as for now, wordpress seems already to behave fine with it (also the plugins we use, but your mileage may vary).

If you want to test it yourself just get a copy of the sources from a slackware mirror: you will need two folders, source/n/alpine and source/n/php; then place the tarball (5.5.4 ATM) in the php folder, removing the old one.

To build it on the above platforms the needed modifications are very marginal and are listed in this diff

EDIT (23 november 2013): I just checked the current build scripts for 14.1/current (to build a newer version) and they have been adapted to build also php-5.5.x, so the modifications below aren’t needed anymore :)

--- php.SlackBuild.orig 2013-10-10 12:04:55.901416000 +0200
+++ php.SlackBuild      2013-10-10 11:15:59.859783000 +0200
@@ -24,8 +24,8 @@
-VERSION=${VERSION:-$(echo php-*.tar.xz | rev | cut -f 3- -d . | cut -f 1 -d - | rev)}
+VERSION=${VERSION:-$(echo php-*.tar.?z* | rev | cut -f 3- -d . | cut -f 1 -d - | rev)}
 # Automatically determine the architecture we're building on:
@@ -65,16 +65,16 @@
 # we need to compile alpine to get c-client.a for IMAP support:
-if [ -r $IMAPLIBDIR/lib${LIBDIRSUFFIX}/c-client.a ]; then
+if [ -r $IMAPLIBDIR/lib${LIBDIRSUFFIX}/libc-client.a ]; then
   echo "Using IMAP library:"
-  ls -l $IMAPLIBDIR/lib${LIBDIRSUFFIX}/c-client.a
+  ls -l $IMAPLIBDIR/lib${LIBDIRSUFFIX}/libc-client.a
   sleep 5
   ( cd $CWD/../alpine ; ./alpine.SlackBuild || exit 1 ) || exit 1
   ( cd $TMP/re-alpine-${ALPINE}/imap/c-client
     strip -g c-client.a
     mkdir -p $IMAPLIBDIR/lib${LIBDIRSUFFIX}
-    cp c-client.a $IMAPLIBDIR/lib${LIBDIRSUFFIX}
+    cp c-client.a $IMAPLIBDIR/lib${LIBDIRSUFFIX}/libc-client.a
     mkdir -p $IMAPLIBDIR/include
     cp *.h $IMAPLIBDIR/include
Feb 102013

I’m fiddling with the staging branch of LXC (stuff that will go in 0.9, now at alpha state) and there are some news to report.

They are migrating to python3 scripts and a corresponding API and some stuff in LUA too to substitute many of the lxc helpers (I’m using python3 and lua from slackbuilds.org).
People is already doing interesting stuff with the API.

Plus, lxc-attach, used to execute commands in the containers (for example, I use it for an rc.lxc script), needs a kernel with full namespaces support (>=3.9).

Work is still in progress (and they just added new features), but it’s usable already :)

a testing slackbuild

EDIT (2013-02-17): I modified the testing stuff to avoid some problems shutting down containers (and more) ;)
EDIT (2013-03-04): changed the kernel version as namespaces support for many filesystems has just been included only with 3.9-rc1

Nov 122012

As the new slackware is out, I wanted to try a clean install on my rasperry-pis.
I referred to the super-detailed guide from dave (thanks!), but his build scripts needed just a little refreshing as upstream moved to a new firmware (boot changed slightly) and kernel version (ditching 3.1.9): more, they are committing on two kernel branches, one based on 3.2.27 (the default) and another based on 3.6.1.
So, at first I forked dave’s build script to build a 3.6.1 kernel, just to test, added some patches, rebuilt, and all went pretty well, but the installer wasn’t working.
Then I decided to go for the 3.2.27 branch, following upstream’s default: so I took the kernel config suggested by raspberrypi’s devs, added some modules to support various hardware, patched the kernel to support the BFQ I/O scheduler setting it as default.
The result are these new build scripts


and these premade packages/disk images


I’ll probably play with it a little in the next days to build a 3.6.1 kernel (and an installer with that) switching there too to a new .config with additions, but consider that times needed for building this stuff grows on the raspi, and running the complete build takes nearly 11 hours to complete.

Ah, while I was there I found some time to build a full LXDE, a Razor-qt/qtdesktop and other various packages for slackwarearm-14.0 using slackbuilds.org‘s scripts (I’ll try to organize this stuff as a repository soon)


Nov 022012

It has been some time since last post and many things happened: one of those is that I have been invited to work with the people at slackbuilds.org and I gladly accepted :)
Work there is really interesting and I feel like I’m learning a lot.

But the thing I felt most urgent, as I had chosen Slackware to host the services I administer at work and a new version of slackware is out, is to upgrade the lxc host and containers to slackware-14.0.

So I made some tests to adapt the procedure I described for slackware-13.37 (you might want to have a look at that too, mainly for the network setup) to the new version, trying at first to run a minimal slackware64-14.0 container on a slackware64-14.0 host.

I switched to slackpkg to install the packages in the container as I think, with just little modifications, it can be safely used as debootstrap is used on Debian: it also supports itself templates, so they can be used to install custom selections of packages (creating /etc/slackpkg/templates/mytemplate.template and passing the variable TEMPLATE=mytemplate to the lxc-create command).
So I patched it: here you can find the patched version for slackware and slackware64, and here is the one for slackwarearm.

I assembled a new template, placed it in my host filesystem as /usr/lib64/lxc/templates/lxc-slackware

cd /usr/lib64/lxc/templates
wget --no-check-certificate https://raw.github.com/Ponce/lxc/lxc-slackware-slackpkg/templates/lxc-slackware.in
mv lxc-slackware.in lxc-slackware
chmod +x lxc-slackware

and installed my minimal slack with it

MIRROR= lxc-create -f /path_to/chuckd.config -n chuckd -t slackware
  • arch defaults to the host’s one. The template supports slackware{,64,arm} but this option makes sense only specifying arch=i486 on a x86_64 host to install a 32 bit container – only case possible/tested ATM
  • SUITE defaults to “14.0” (and it’s tested with that ;) )
  • TEMPLATE defaults to “minimal-lxc” (in the previous article you can see the list of packages used)
  • MIRROR defaults to “http://www.slackware.at/data” and points to a slackpkg mirror, the main tree, withouth the /slackware-$SUITE/ at the end.
    You can use also a local folder: supposing you have a mirror of the latest slackware64-14.0 in /my/path/slackware64-14.0 use MIRROR=cdrom://my/path. As this will be set as the default mirror in the container (during creation), in this case you surely have to edit it after (that path won’t be accessible by the container).
  • chuckd.config is the configuration file for the container (two examples are available in the previous article, depending on the chosen network setup)
  • chuckd is the name of the container
  • slackware is the linux flavour of the container

Then I edited /var/lib/lxc/chuckd/rootfs/etc/rc.d/rc.inet1.conf and /var/lib/lxc/chuckd/rootfs/etc/resolv.conf, the network configuration files of the container, with its network settings (IPADDR[0], NETMASK[0], GATEWAY and nameserver) and I started it with

screen -dmS init-chuckd /usr/bin/lxc-start -n chuckd

because launching it using a detached screen session leaves me an usable console (and I can reattach it, if needed).
And I happily connected to it through the network via ssh (or “lxc-console -n chuckd”) :)

While chatting with Alien Bob, he suggested me to try to install a full slackware on a lxc container, as a friend had tried it and got some problem logging in after.
I thought that happened because devices are defined outside of the containers and generally they don’t like manual adding or things like udev messing around, so I adapted the template also to disable an eventual /etc/rc.d/rc.udev and blacklisted the devs package (don’t install it in a container).
After that, I was able to install a full slackware64 in the container

slackpkg update
slackpkg install slackware64

While I was there, I tested also a remote connection through the nx protocol, installing freenx in the container with sbopkg

wget http://sbopkg.googlecode.com/files/sbopkg-0.36.0-noarch-1_cng.tgz
installpkg sbopkg-0.36.0-noarch-1_cng.tgz
sbopkg -r
sbopkg -i nx
sh /var/lib/sbopkg/SBo/14.0/network/freenx/preinstall.sh
sbopkg -i freenx

and I connected to it from the host with nxclient.

Jul 172011

I’m using some lxc containers to offer services with less resources than full virtualization (like kvm, virtualbox, etc.) demands for.
At first I was creating the containers I needed basically following Chris Willing’s guide but, being jealous :P of the existing templates for the debian based distributions that allow creation of containers with a single command, I tried to assemble one for slackware 13.37, that I personally use at work and at home as a virtualization platform.

The concept is simply reapplying the steps that the slackware setup normally follows but with the necessary changes (mainly omissions) to fit our container environment: so I uncompressed the slackware setup initrd to check Patrick Volkerding’s work

gzip -dc /data/slackware/slackware64-13.37/isolinux/initrd.img | cpio -i -d -H newc --no-absolute-filenames

and had a look at the install shell scripts in /usr/lib/setup.
Then I took as a base the existing lxc-debian template and modified it to:
– download some slackware packages for a minimal installation (many thanks to Vincent Batts for the selection);
– install them in a folder;
– apply all the standard postinstall routines;
– apply the necessary container fixes (many thanks to Chris Willing that pioneered on this and documented it well :) ).

I published the result on github

“…ok, that’s enough!
we want to play with containers too!”

I was getting to it :)

If you want to try them you have to decide which kind of networking you want for them: choices are basically between using:
– a network bridge on your network interface, with the containers in the same network segment as the host;
– a network bridge on a dummy interface used as gateway with NAT: the containers will be in a private network segment.

If you want to offer services and you have plenty of ips to use (like in an home network), maybe the first solution can be easier, as you don’t have to use iptables to redirect incoming connections to the private network of the containers.

Slackware-13.37 kernel already supports all you need, so let’s setup our interface, assuming our host eth0 (the primary ethernet interface, in the example) address is and that we are in a class C network with as our gateway.
Here are the step to follow in each situation:

containers on the same network segment as the host

We have to put the interface down because we are going to add it to the bridge, so if you’are doing this through an ssh connection, I suggest you to run this as a script in a screen session, to avoid being cutted off ;)

/sbin/ifconfig eth0 down
/sbin/brctl addbr br0
/sbin/brctl setfd br0 0
/sbin/ifconfig br0 netmask promisc up
/sbin/brctl addif br0 eth0
ifconfig eth0 up
route add default gw
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/conf/br0/proxy_arp

At the end the bridge setup should be ok: you can find a version of the script above (to be included in /etc/rc.d/rc.local) here; I also modify /etc/rc.d/rc.inet1.conf on my nodes where I use this configuration to omit eth0 config (the script is enough to bring up the interface on the host running the containers).

Next, we create a configuration file, let’s call it chuckd.config, for the chuckd virtual container that we are going to do: decide a custom hardware address (anything valid should do) and ip (as we said, in the same range)

lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.hwaddr = 00:aa:11:bb:22:cc
lxc.network.ipv4 =
lxc.network.name = eth0

containers on a natted private network

In this case the script to bring up the private network is this

/sbin/brctl addbr br0
/sbin/brctl setfd br0 0
/sbin/ifconfig br0 netmask promisc up
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/conf/br0/proxy_arp

/usr/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# examples of redirections
iptables -t nat -A PREROUTING -p tcp --dport 51 -i eth0 -j DNAT --to
iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j DNAT --to

at the end of the script you can see some example of redirection of incoming connections toward the containers in the private network.

also the config file changes (with an ip on the same network)

lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.hwaddr = 00:aa:11:bb:22:cc
lxc.network.ipv4 =
lxc.network.name = eth0

– – –

Now we’ll setup our template so we can use it to create the container: change directory to /usr/lib/lxc/templates if you are on a 32 bit system

cd /usr/lib64/lxc/templates
wget --no-check-certificate https://raw.github.com/Ponce/lxc-slackware/master/lxc-slackware
chmod +x lxc-slackware

We are ready to create our first container, chuckd, using lxc-create and a slackware mirror: if not specified, defaults to the main one; here I’m using a local copy

MIRROR= lxc-create -f /path_to/chuckd.config -n chuckd -t slackware

wait some seconds (25, here) and you will have your slackware-13.37 minimal container in /var/lib/lxc/chuckd/rootfs :)

But you have to do another step before firing it up, and it’s setting the network parameters in /var/lib/lxc/$container/etc/rc.d/rc.inet1.conf to the one of your network, if you don’t have a dhcp server available


(, and, in the nat example above) and a nameserver in /var/lib/lxc/$container/etc/resolv.conf (here I’m using google’s one)


Then launch a screen session and fire up the container

lxc-start -n chuckd

you’ll see something like this

INIT: version 2.86 booting
INIT: Entering runlevel: 3
Going multiuser...
Updating shared library links:  /sbin/ldconfig &
Starting sysklogd daemons:  /usr/sbin/syslogd /usr/sbin/klogd -c 3 -x
Starting OpenSSH SSH daemon:  /usr/sbin/sshd
Generating public/private rsa1 key pair.
Your identification has been saved in /etc/ssh/ssh_host_key.
Your public key has been saved in /etc/ssh/ssh_host_key.pub.
The key fingerprint is:
27:ac:44:47:c6:9d:a7:c3:e0:1a:5d:44:a5:d7:1e:69 root@chuckd
The key's randomart image is:
+--[RSA1 2048]----+
|       .o+oo.    |
|       oo +... . |
|      .o.+.o. E  |
|     ..oo +. o . |
|      .oS ..  .  |
|     ... o       |
|      .          |
|                 |
|                 |
Generating public/private dsa key pair.
Your identification has been saved in /etc/ssh/ssh_host_dsa_key.
Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub.
The key fingerprint is:
dd:37:4d:fb:59:0f:06:da:e7:23:0a:55:3b:50:34:d0 root@chuckd
The key's randomart image is:
+--[ DSA 1024]----+
|          .++    |
|           .E.   |
|          . o   .|
|         . * o o.|
|        S + = *.o|
|         .   * o=|
|        .   . o.o|
|         . . . . |
|          .      |
Generating public/private rsa key pair.
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
ac:2e:04:67:ba:11:3a:17:fe:6b:4c:80:95:65:26:e9 root@chuckd
The key's randomart image is:
+--[ RSA 2048]----+
|  .++            |
|  ++             |
| +               |
|. E o  .         |
| o O    S        |
|o = o  .         |
| o B  .          |
|  . =.           |
|   ..o.          |
Generating public/private ecdsa key pair.
Your identification has been saved in /etc/ssh/ssh_host_ecdsa_key.
Your public key has been saved in /etc/ssh/ssh_host_ecdsa_key.pub.
The key fingerprint is:
a5:e2:95:07:42:fc:ed:62:e7:c6:29:4a:45:54:17:2d root@chuckd
The key's randomart image is:
+--[ECDSA  256]---+
|     .. ... oo   |
|     ...   .E .  |
|      ..o..  .   |
|       o.=.      |
|      . S..      |
|     . +o.o      |
|      o. = .     |
|     .  . =      |
|      .. o       |

* container chuckd started. *

and the console output will stop there: that means that the container fired up successfully! :)
Having it in a screen session means that you can detach the session (ctrl-A D) and reattach when needed (screen -D -r), it’s optional but useful.

After launching, you can connect to its ip via ssh or open a console with

lxc-console -n chuckd

You can install whatever package you use (also full package sets) with slackpkg, but you can alternatively use slapt-get, if you like.

Enjoy virtual containers!

Considerations: lxc aims to process isolation and at the moment it’s not full: the template sets in the default config to start the containers with lxc.cap.drop=sys_admin, but that line can be commented out from the template or per container, if needed.

P.S. if you want to specify your own set of packages for the container, just create a text file with a modified version of this list, following the same syntax

export arch=x86_64
export PACKAGES=" \
a/aaa_base-13.37-$arch-3.txz \
a/aaa_elflibs-13.37-$arch-7.txz \
a/aaa_terminfo-5.8-$arch-1.txz \
a/bash-4.1.010-$arch-1.txz \
a/bin-11.1-$arch-1.txz \
a/bzip2-1.0.6-$arch-1.txz \
a/coreutils-8.11-$arch-1.txz \
n/dhcpcd-5.2.11-$arch-1.txz \
a/dialog-1.1_20100428-$arch-2.txz \
ap/diffutils-3.0-$arch-1.txz \
a/e2fsprogs-1.41.14-$arch-1.txz \
a/elvis-2.2_0-$arch-2.txz \
a/etc-13.013-$arch-1.txz \
a/findutils-4.4.2-$arch-1.txz \
a/gawk-3.1.8-$arch-1.txz \
a/glibc-solibs-2.13-$arch-4.txz \
n/gnupg-1.4.11-$arch-1.txz \
a/grep-2.7-$arch-1.txz \
a/gzip-1.4-$arch-1.tgz \
n/iputils-s20101006-$arch-1.txz \
a/logrotate-3.7.8-$arch-1.txz \
n/net-tools-1.60-$arch-3.txz \
n/network-scripts-13.0-noarch-3.txz \
n/openssh-5.8p1-$arch-1.txz \
a/openssl-solibs-0.9.8r-$arch-3.txz \
a/pkgtools-13.37-noarch-9.tgz \
a/procps-3.2.8-$arch-3.txz \
a/sed-4.2.1-$arch-1.txz \
a/shadow-$arch-2.txz \
a/sharutils-4.11-$arch-1.txz \
ap/slackpkg-2.82.0-noarch-5.tgz \
a/sysklogd-1.5-$arch-1.txz \
a/sysvinit-2.86-$arch-6.txz \
a/sysvinit-functions-8.53-$arch-2.txz \
a/sysvinit-scripts-1.2-noarch-43.txz \
a/tar-1.26-$arch-1.tgz \
a/udev-165-$arch-2.txz \
a/util-linux-2.19-$arch-1.txz \
n/wget-1.12-$arch-1.txz \
a/which-2.20-$arch-1.txz \

then source it before launching lxc-create

. packages_I_need_list

you can also pass to the script a custom SUITE variable to use other versions than 13.37 (but this is untested, as PACKAGES has to be changed too for each SUITE).
P.P.S. 14.9.2011: edited the nat bridge script following Chris Willing’s hints (thanks again! :) ).

Linux Containers (LXC) on Slackware© 13.37 (Chris Willing)
LXC HOWTO (Dwight Schauer)
lxc-users mailing list
lxc-devel mailing list