There are a number of documents about how to permit ssh access to run rsync or unison for remote synchronisation by an appropriate configuration of the authorized_keys file. Of these the best two are probably those by St phane Kattoor and Christian 'Greek0' Aichinger. Joey Hess also explains some of the pitfalls. The problem is the familiar one: to limit the file-system hierarchy accessible. The humble chroot is a natural way to implement such restrictions which is probably what led "Greek0" to suggest the use of dchroot. This is indeed a fine solution ... except, how does one implement it if one is not root on the server machine? WARNING: The rest of this entry is wrong as was pointed out by Joey Hess. See the update at the bottom. The package fakechroot by Piotr Roszatycki provides a way out. The problem I had was as follows:

• I want to share a certain sub-tree of $HOME using unison.
• I am OK with sharing whatever access I give to /bin, /lib and /usr in the process.
• I do not have root access to the machine.

A recent enough version of fakechroot (version 2.8 worked) allows one to do make use of environment variables as follows:

LD_PRELOAD=libfakechroot.so
LD_LIBRARY_PATH=/usr/lib/fakechroot:/usr/lib64/fakechroot:/usr/lib32/fakechroot:/usr/lib:/lib
FAKECHROOT=true
FAKECHROOT_VERSION=2.8
FAKECHROOT_EXCLUDE_PATH=/bin:/lib:/usr
export LD_LIBRARY_PATH LD_PRELOAD
export FAKECHROOT_EXCLUDE_PATH FAKECHROOT FAKECHROOT_VERSION

After this setup one can run

HOME=/ chroot $HOME/some/dir /usr/bin/unison -server

and the unison server¹ will only be able to view /bin, /lib, /usr and $HOME/some/dir; the latter will be mapped to /. (One needs to set the $HOME variable to something sensible for unison to function.) One should not be tempted to create subdirectories of $HOME/some/dir containing only the "relevant" portions of the system directories for unison. The reason is that those files will be created as me and so could be overwritten by unison. The creation of a suitable entry in authorized_keys to use this is an easy exercise! UPDATE: As Joey Hess has noted:

Taking a program, be it fakechroot or unison, that was never designed with security in mind, and trying to use it as a security barrier, is an open invitation to pain.

I had thought about the problem of uploading static-linked binaries and had imagined that it had been overcome. However, the basic facts in this case are:

• unison -server does not have an option to limit its view of the directory heirarchy. The upstream authors are aware of this but it is not clear whether they perceive it as a bug.
• fakechroot is meant to give a different view of the directory heirarchy to programs that use standard libc calls. It does not block access to part of the tree as the real chroot does; again, this is not necessarily a bug.

Some time ago I wrote a note about VSTi on Linux. Today I tried to run FL Studio with WINE and... it works almost ;) perfectly! I'm really impressed. Now almost all VSTi plugins works seamlessly and even external plugins can be used, i.e. my favourite Superwave P8 :) I think it might be an issue with registration of full version copy but at least there are some cracks working. It's good to see the real audio software run on Linux. WINE developers, you've done an amazing job. Thank you!

I made a new release of YADA, the packaging helper different than others. New version of YADA supports Homepage field in debian/control file which appeared in dpkg last time. Wow. The YADA supported Home-Page field many years ago. YADA is very different that other Debian packaging helpers. Most important is that no Makefile have to be edited at all. This is the strongest and the weakest point of the YADA. People loves it or hate it. Some people even have a vendetta against YADA. Other people find the tool is very simple. Well, I think the YADA is some kind of prosthesis for native Debian packaging system, but even this prototype is much better than any Makefile-based aids just because I don't need to edit any Makefile. YADA had a black PR and much of bad FUD. There was opinion that it violates Debian policy, it is problematic for NMUs and security updates and maintaining of Debian patches is very difficult. This tool is very powerful and has some pitfalls but it doesn't mean it is evil by design. I really don't know how to make i.e. the iceape-l10n package without using YADA and its macro engine. It have to be more complicated and with much redundancy for metainformations. I think I could switch from YADA to another packaging tool, but please... Just create it! :)

The geek like me should have a special birthday cake. And my girl knows it :)

Some time ago, I needed a small but helpful tool which could start some shell command with bounded time and kill spawned process if it was timed out. There is timeout package in Debian but it has very serious bug #187092. In fact, this tool can't intercept the proper status of called command and can't kill processes spawned by called command. I've tried to fix the Debian's timeout package but the bug is still opened over 4 years. So I decided to code the own Perl implementation. The result was attached to bug report. I've noticed that my script is currently used by Exim packagers. It's nice to see that my work is still useful. I think more people can find this script helpful so I set the Google Code project: timeout-pl. You can download the newest version of this script from Google or CPAN. Have a fun.

I maintain the HenPlus interface for databases. The tool is written in Java but it didn't work with non-Sun implementation of Java. The reason was sun.misc.Signal class. It is used for trapping Ctrl+C in application. I wonder why the GNU Classpath does not support this class. Does it mean the Sun Java is not really standarized? I've found the workaround. I unpacked some of sun/misc/*.java files from official Sun Java sources. Fortunatelly they was published under GPL license. The trick made possible to compile the HenPlus with GCJ+ECJ, so I could change the build-time dependency to java-gcj-compat-dev. It really worked! Even if the signal couldn't be handled with GCJ or SableVM, the application started with non-Sun Java runtime:

Hen*Plus> system-info
----------------------------------------+---------------------------------------------+
            System Property                                  Value                     
----------------------------------------+---------------------------------------------+
 Diff. of used memory (now-before) [KB]                                      1.932,00  
 Java VM                                     GNU libgcj 4.1.2 (Ubuntu 4.1.2-0ubuntu5)  
 Java Vendor                                           Free Software Foundation, Inc.  
 Java Home                                /usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre  
[...]

I've found that the GCJ and Kaffe doesn't work with Oracle JDBC driver. I'm suprised that SableVM works without problems. It's good to see that there is a reasonable alternative for Sun's imlementation.

A few weeks ago I filled a ShipIt form. Today I've got 6 CD-s with Ubuntu and Kubuntu: I wonder why I didn't get the Kubuntu AMD64 edition. Well, it might be better because I didn't use 64-bit on my NEC and I can give somebody one more CD. I'm trying to imagine the ShipIt for Debian. Well, I supose that Debian has not enough funds for such an action...

Some time ago I've filled ITP for libtool-cvs. I needed the new libtool for fakechroot project. The stable release of libtool is badly broken and causes that autoconf generates ./configure script which fails if C++ compiler is not installed in system. The cure is the newest libtoolize taken directly from CVS. I rather want to see the libtool package in Debian because it is hard to install it manually. So I decided to make the new package. Fortunatelly, the current stable libtool maintainer (Kurt Roeckx) is very helpful person and he don't see any problem if I prepare the experimental release of his package :) So here it is: fresh and brand new libtool Debian packages. There was some controversy with versioning schema. The current CVS snapshot is labeled as 2.1a. The upstream's authors promised that the next release should the version number greater than previous. I hope they really don't release new libtool i.e. as a version 2.0. Whatever. This is the experimental package at least. I don't know, why the package is not indexed by packages.debian.org yet. It is strange as fara as it came into ftp.debian.org.

I like very much a Test::Unit framework. I've found it as a very handy tool for organising the tests. I really don't like the standard Test::Simple and its deriveratives. I don't understand why I have to see the output for each failed test. I rather like the do-or-die tests grouped logically as test units. Somebody write me a note for Exception::Base module that it depends on non-core Perl modules. It is not for runtime but build dependency. Even that, it is true, because Test::Unit is a somewhat heavy module and it depends on i.e. Errors. I decided to reimplement Test::Unit. So it is available Test::Unit::Lite already! It is much lighter replacement for original Test::Unit. It should be compatible for existing test suites. The intention was possibility of bundling the Test::Unit::Lite with other module distributions:

$ perl -MTest::Unit::Lite -e bundle

It copies the Test::Unit::Lite module to the inc directory in the distribution source. The Test::Unit module isn't perfect. The most annoying behaviour is the random order for calling test cases. The Test::Unit::Lite sorts the function names and calls it always in the same order. There is not so many Perl modules distributions that use Test::Unit. I hope a little that my package could change this situation and the test units will be more popular and easier to use.

I just configured my Kubuntu so it can be a printer server for my girl's notebook. She works on Windows XP and she's connected via wi-fi. It was looking very simply. "Export the driver for Windows users" in KDE's Control Panel. Huh... I've download the necessary files from CUPS site. It was not enough. I had to upload some files from Windows into /usr/share/cups/drivers. Soon it was clear that cupsaddsmb command needed root privileges. Then the smbpasswd command was needed. After all, I had to edit smb.conf. I think I might reconfigure my Samba server just because I have 10 years experience in Linux technology and I was desperate. There was a success after one hour of browsing the documentation, downloading the many files from Internet and local systems, manually editing some system files and calling some mysterious commands. Success? I think it was a failure. The printing technology is still for hackers.

I'm working on some interesting project in Perl. I decided to make it fully OO, XP and other buzzwords-friendly. I just implementing some Registry Pattern which is just a Singleton Pattern. The Perl Design Patterns site is very useful, but I wanted more. The beauty of Perl is its flexibility. I'd like to call the class directly and by object. So it is my version:

  package System::Path;
  use File::Spec ();
  # Class attributes
  my %attrs = (
      home => undef,
      root  => undef,
      tmpdir  => undef
  );
  # Private constructor used by singleton
  sub _new  
      my $class = shift;
      my $self =   %attrs  ;
      bless($self, $class);
      $self;
   
  # Instance of singleton class
  my $Self;
  # Singleton constructor
  sub instance  
      $Self  = (shift)->_new;
   
  # Returns a string representation of the temporary directory
  sub tmpdir  
      my $self = shift;
      $self = __PACKAGE__->instance
          unless ref $self eq __PACKAGE__;
      return $self-> tmpdir 
          if $self-> tmpdir ;
      $self-> tmpdir  = File::Spec->tmpdir;
   
  # (...)
  1;

Then I can call: $dir = System::Path::tmpdir; or $dir = System::Path->tmpdir; or $obj = System::Path->instance; $dir = $obj->tmpdir; ...and each way is correct. BTW, they are great tunes on chillout@DI.FM radio at the moment :) "Sacred Cycles", "Greece 2000" and beautiful set of Marco Torrance vs. Xerxes... Oh my! :)

Yesterday I uploaded new ossp-uuid packages. Today I was worried why they weren't in incoming.debian.org nor archived in sid... I forgot that new upstream brought new binary package (libossp-uuid15), so it came to NEW and BYHAND packages queue. The Iceweasel stucked there for 90 minutes. My package is still in queue for 15 hours. All packages are equal, but some packages are more equal than others :)

There was very funny thread about CDBS and kitten. I think any other solution is better than plain Makefile. Long time ago I adopted the YADA. It's wonderful tool for anybody who hates Makefiles. Yes, the project is still alive. Unfortunately I don't have too much time for promoting this project. Just one month ago some developer did NMU for my package (see Bug#391753). He wrote that YADA is quite unfriendly for NMUers. I really wonder, how it could be unfriendly as far as plain Makefile don't support even separate patch files... I think it would be much better if Debian had only one tool for packaging. The RPM's SPEC file as single source for package is more friendly for maintainer than thousands of separate debhelper's files. So the YADA came. But... I understand it is just an option. It is my choose how to package my packages. My own right to decide. I can live with Debian and CDBS, YADA or other packaging helpers.

I've just installed dssi-vst. I tried to use Linux as music instrument one year ago, but it failed. It was not so hard just now. I googled and found very usable site about VST on Linux. I did not receive the USB-MIDI connector yet, that I bought on Allegro , so I used the vkeybd. It was pretty cool. The first instrument that I tested was SUPERWAVE. I started the jack-dssi-host dssi-vst.so:SUPERWAVEP8.dll and the instrument appeared as another MIDI and audio client in JACK Audio Connection dialog. Now I'm missing FL Studio on Linux badly...

I'm spending the Saturday at home sorting the CDs collection. A lot of stuff is going to trash can, especially some warez like illegal Windows copies. I don't need them as far as I can use Debian, Knoppix or Kubuntu. At least there is a Windows 2003 Server trial which can be legally used for 180 days. I need the backup for some CDs on harddisk. I tried to use the K3b. Unfortunatelly, the K3b doesn't allow to choose the ISO image file name. I had to write some tool. It uses the standard command from mkisofs package. By the way, I've noticed that bs parameter in dd command has a big impact for copying speed. So I'm calling the dd twice time. First, with a large buffer size and another time for end of file. The code for isocat script:

BUFSIZE=$((128*1024))
bsize= LC_ALL=C isoinfo -d   sed '/^Logical block size is:/!d; s/.*: //' 
vsize= LC_ALL=C isoinfo -d   sed '/^Volume size is:/!d; s/.*: //' 
size=$(($bsize*$vsize))
if which pv >/dev/null 2>&1 && tty -s; then
    cat="pv -s $size"
else
    cat=cat
fi
( dd $ 1:+if=$1  bs=$BUFSIZE count=$(($size / $BUFSIZE)); \
  dd $ 1:+if=$1  bs=$bsize
    count=$(($size / $vsize - $size / $BUFSIZE * $BUFSIZE / $vsize))
    skip=$(($size / $BUFSIZE * $BUFSIZE / $vsize))
)   eval $cat $ 2:+> $2 

Yes! Yes! Yes! My first blog note at planet.debian.org :) It was not so easy, because the jogger.pl service does not feed separate categories. I had to use some trick. Each note for Planet Debian is marked with hidden feed:Debian tag. So I used Perl. Yes, there is a module for handling the RSS files. The code (comments was stripped):

use IO::Handle;
use XML::RSS;
my ($version, $pattern, $title) = @ARGV;
die "Usage: $0 version pattern [title]\n" unless $pattern;
my $stdin = IO::Handle->new;
$stdin->fdopen(fileno(STDIN),"r") or die;
my $rss = new XML::RSS;
$rss-> output  = $version unless $version eq 'default';
$rss->parse($stdin);
$rss-> items  = [grep($_-> description  =~ /$pattern/,
    @ $rss-> items )];
$rss-> channel -> title  = $title if $title;
print $rss->as_string;

Perl is great, as always.