Skip to main content

error: offset '3' outside bounds of constant string

When compiling the latest ZFS-on-FUSE checkout, GCC (Debian/sid, 4.4-20090329-1) barfs with:

cc1: warnings being treated as errors
lib/libzfs/libzfs_dataset.c: In function 'zfs_prop_get':
lib/libzfs/libzfs_dataset.c:2348: error: offset '3' outside bounds of constant string
lib/libzfs/libzfs_dataset.c:2355: error: offset '3' outside bounds of constant string
scons: *** [lib/libzfs/libzfs_dataset.o] Error 1
scons: building terminated because of errors.
As this is really a gcc bug, we'd have to wait for a real fix. But we're impatient and there are two workarounds here:
1) compile w/o optimizations (i.e. no -On options)
2) compile w/o the -Werror flag.
The latter is probably what you want here...

chroot SSH login on MacOS 10.4

While I was looking for a chroot'ed SSH setup on MacOS X, I've came a cross a few postings but most of them were basically "yeah, it's hard, and you have to recompile, bla..." or were dealing with sftp/scp - not what I wanted. I really want users to get an interactive shell, but not snoop around on the real filesystem. Here's a short howto:

$ sudo su -
$ port install jailkit
$ mkdir -p /mnt/chroot/usr/bin /mnt/chroot/usr/lib/system /mnt/chroot/etc \
           /mnt/chroot/home /mnt/chroot/dev/fd /mnt/chroot/home/dummy
$ chown -R root:wheel /mnt/chroot
$ ln /bin/bash /mnt/chroot/bin/bash
$ ln /usr/bin/telnet /mnt/chroot/usr/bin/telnet
$ cp -R /usr/lib/libncurses*dylib /mnt/chroot/usr/lib
$ cp /usr/lib/libSystem.B.dylib /mnt/chroot/usr/lib
$ cp /usr/lib/system/libmathCommon.A.dylib /mnt/chroot/usr/lib/system
Note: there's no ldd in MacOS X, but we can use otool to list dynamic (library) dependencies:
$ otool -L /bin/bash 
        /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0)
Be aware that these dependencies may have dependencies on its own, you can do something like this to grab all of them - although it's not entirely recursive.

We're not quite ready yet:
  • create a user ("dummy") via NetInfo, set a password.
  • set her home to /mnt/chroot/./home/dummy
  • set her shell to /opt/local/sbin/jk_chrootsh
  • create an /etc/passwd inside the jail
$ id -u dummy
$ echo "dummy:x:505:505::/home/dummy:/bin/bash" > /mnt/chroot/etc/passwd
$ chown -R dummy:dummy /mnt/chroot/home/dummy
And for the sake of completenes, we're even creating a few devicefiles:
$ cp -R /dev/fd/[012] /mnt/chroot/dev/fd
$ cp -R /dev/std* /dev/null /dev/zero /dev/tty /dev/*random /mnt/chroot/dev
Now everything should be in its place. jk_chrootsh is *very* picky about ownership/permissions (rightfully so!) and when something goes wrong, it logs to auth.log, e.g.:
  abort, home directory /dummy differs from jail home directory 
   /mnt/chroot/./dummy for user dummy (505),
   check /etc/passwd and /mnt/chroot/etc/passwd
  ERROR: failed to execute shell /bin/bash for user dummy (505), 
  check the permissions and libraries of /mnt/chroot//bin/bash
NB: Tiger's OpenSSH_5.1p1 comes with an option called ChrootDirectory for quite a while now. And after struggling with the procedure above (sigh...), this option looks quite comfortable:
Match user dummy
    ChrootDirectory /mnt/chroot
This worked for me after two small fixes:
$ chown root:wheel /
$ chmod 0755 /
Btw, for a few weeks now SunSSH does support this option too in OpenSolaris. Nice :)

cannot run C compiled programs

Every now and then I come across this message, but apparently far too seldom, otherwise I would've remembered:

$ uname -sr
NetBSD 4.0.1
$ ./ tools
No nonexistent/bin/nbmake, needs building.
Bootstrapping nbmake
checking for sh... /bin/sh
checking for gcc... cc
checking for C compiler default output... a.out
checking whether the C compiler works... configure: error:
 cannot run C compiled programs.
If you meant to cross compile, use `--host'.
That's a weird way for saying that /tmp is mounted noexec :-\

scp between two different hosts

Every now and then I try to scp files between two hosts with just one command. But it mysteriously fails with:

$ scp bob@saturn:/tmp/foo alice@pluto:/tmp/bar
bob@saturn's password: 
Permission denied, please try again.
But the password for bob@saturn is definitely right (I promise!), so what's going on here? Let's take a closer look:
$ scp bob@saturn:/tmp/foo alice@pluto:/tmp/bar
bob@saturn's password: 
$ ps -ef | grep [s]cp
[...] scp bob@saturn:/tmp/foo alice@pluto:/tmp/bar
[...] /usr/bin/ssh -x -oClearAllForwardings yes -n -l bob saturn \
       scp /tmp/foo alice@pluto:/tmp/bar
Now we see that scp(1) was actually executed on the saturn. The Permission denied was already pluto's response to the connection attempt. After stumbling over this issue a few times I finally found a nice explanation describing all this.

Git plus Perl 5.10 with MacPorts on MacOS 10.4

Since the Fink Project looks a bit stale (last release from 06/2008), I switched to MacPorts, which does not come with a neat dpkg toolset, but the port command is usable too (and looks more BSD-like anyway ;)). One of the tasks left was to compile git-core. Of course, git-core has runtime dependencies on perl and a package called p5-error. However, there are 3 different "perl" packages available: perl, perl5.8, perl5.10. Since perl5.10 was already installed, I was looking for a way to convince git-core to depend on perl5.10 instead. Since p5-error also had a library dependency on perl5, I had to add a depends_lib port:perl5.10 to its Portfile. Run "portindex" once more, now we should be ready to install git-core (for perl5.10). Here's the full procedure:

$ cd
$ mkdir -p .ports/devel/git-core/files .ports/perl/p5-error
$ cd .ports
$ cp $macports/.../release/ports/devel/git-core/Portfile \
$ cp $macports/.../release/ports/devel/git-core/files/patch-Makefile.diff \
$ cp $macports/.../release/ports/perl/p5-error/Portfile \
* Change depends_run to path:bin/perl:perl5.10 in devel/git-core/Portfile
* Add depends_lib port:perl5.10 to perl/p5-error/Portfile
$ portindex
$ sudo port install git-core
....and that should be all, for building git-core that is.

unable to set superblock flags

An ext3 filesystem would not mount today :(
Running e2fsck (under MacOS 10.4/ppc) only gave:

$ e2fsck -fv /dev/rdisk0s4
fsck.ext3: unable to set superblock flags on /dev/rdisk0s4
Then I remembered to try with a dfferent superblock, and it worked perfectly:
$ mkfs.ext3 -n /dev/disk0s4 
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
Note: Don't forget the -n option, otherwise mkfs.ext3 will really format the partition!
$ e2fsck -b 32768 -fv /dev/rdisk0s4 
$ mount_ext2 /dev/disk0s4 /Volumes/disk0s4/
Now mounting succeeds again. Yeah, ext3 ;-)


I wonder why this parameter has been turned on. It confuses users and does things like:

# apt-get install mdadm
The following extra packages will be installed:
  citadel-common citadel-mta citadel-server db4.6-util libcitadel1 
  libcurl3 libglib2.0-0 libglib2.0-data libical0 libpcre3 libsieve2-1
  libssh2-1 libxml2 sgml-base shared-mime-info xml-core
0 upgraded, 17 newly installed, 0 to remove and 0 not upgraded.
I mean, what the hell, man? Why would I need citadel-server, which apparently is described as "a complete and feature-rich open source groupware platform" - huh? I only wanted to install mdadm! Fortunately one can set APT::Install-Recommends "false"; in apt.conf, and it'll just install with Depends: from now on.

tcpd &

I really like the tcpwrapper. Without messing with ipfilter, one can easily set up quite a few access rules. While running seccheck, I noticed that TCP wrappers were not enabled on my system. A quick edit of hosts.allow and hosts.deny did the trick - except for sendmail:

[ID 801593] n28820cE016260: from=root, size=247, class=0, nrcpts=1, 
                      msgid=<200903080802.n28820cE016260@node1>, relay=root@localhost
[ID 801593 mail.notice] n28820u0016261: tcpwrappers (localhost, rejection
So, why would sendmail reject mail from localhost? Well, sendmail is linked against the TCP wrapper too:
$ ldd /usr/lib/sendmail | grep wrap =>  /usr/sfw/lib/
$ grep -v ^\# /etc/hosts.allow 
Apparently sendmail (or, to be correct: tcpd) does not like the subnet after, despite the manpage where it expects an "expression of the form `n.n.n.n/m.m.m.m' ". Well, removing the subnet helped, now sendmail delivers to localhost again.

~/Desktop pollution

Sigh, when will it end? The most userfriendly (Desktop)OS on earth right now still has so many issues. But why wouldn't it, considering the rather large userbase. Hmpf. As Safari does not fit my needs (don't ask) I'm stuck with Firefox (sometimes even Minefield). But every time I click on a document which a helper application is about to open (.m3u, .pdf, etc.), Firefox stores a temporary copy on my desktop. Only that it's not temporary at all, but stays there until I delete it. So after a long browsing session, the desktop is cluttered with not-so-temporary documents. Oh, there's #302433 (opened 07/2005, marked "fixed" while it's actually not) and then there's #374184 (opened 03/2007, still open) but apart from a proposed workaround there really is no solution in sight. Bummer.

Update: A comment in #311292 proposed a new about:config option ( to be set to "1", so that downloaded files will temporary go to the system's default download directory. See also Comment #55 in the same report, that suggests to set this default download directory with Camino. Yes, "wow!" indeed. But it worked.

Conversion from character set '646' to 'UTF-8' is not supported

While trying to setup syslog-ng on Solaris 10, I've come across:

# /usr/local/sbin/syslog-ng
Error parsing command line arguments: Conversion from character set '646'
to 'UTF-8' is not supported
Several places on the net lead me to suspect a missing charset.alias file. And indeed, syslog-ng was looking for one:
# truss -elfda /usr/local/sbin/syslog-ng 2>&1 | grep charset
29850/1:  1.9301 open64("/usr/local/lib/charset.alias", O_RDONLY) Err#2 ENOENT

# locate charset.alias
# ln -s /usr/lib/charset.alias /usr/local/lib/charset.alias
...Now syslog-ng is working fine. This does not seem to be syslog-ng related, but may help other applications as well. To be confirmed though....