Skip to main content

ggrep --devices=skip

Every now and then I'd like to (recursively) search for patterns in a directory tree. Since Solaris' grep(1) does not understand -r, I used SUNWggrep. But grep'ing through e.g. /etc never seems to come to an end, and truss(1) knows why:

$ /usr/sfw/bin/ggrep --version | head -1
grep (GNU grep) 2.5
$ truss -elfda /usr/sfw/bin/ggrep -D skip -r foo /etc
[...] 
8341/1:          0.0448 open64("/etc/cron.d/FIFO", O_RDONLY)            = 3
8341/1:          0.0454 fstat64(3, 0xFFBFFA78)                          = 0
8341/1:         read(3, 0x00044000, 32768)      (sleeping...)
Well, I won't comment on the fact that we have devices in /etc at all, but I explicitly told grep to skip devices. Apparently this option is just being ignored. Using the latest GNU/grep CVS checkout does help and the changelog does indeed mention a fix for the --devices option.

Oh, of course: this could be done with find too, but GNU/grep is so much easier than:
$ find /etc -type f -exec grep foo '{}' +
Hint: add "-D skip" to your GREP_OPTIONS environment variable, that way it's passed to GNU/grep automatically.

Update: a careful reader noticed that I confused SUNWggrep and SMCgrep - I did indeed and corrected it, finally. Thanks for the hint! For the record, the current version of SMCgrep does NOT have this problem, it's all good! :-)

binding cherokee to a single network address

Well, this is my first attempt with Cherokee and I thought server!listen was a valid configuration key. However, the latest GIT checkout gave:

$ /opt/cherokee/sbin/cherokee -C ./cherokee.conf 
ERROR: Server parser: Unknown key "listen"
Couldn't read the config file: ./cherokee.conf
This has been reported already and is said to be fixed with changeset 2766, so why is this still happening?

Update: As an observing reader pointed out, the correct key is named server!bind!1!interface now. The changelog is rather quiet about this, but searching in the commits reveals that this change has been made last year already, though the documentation still mentions server!listen.

Fedora: which which

Oh, come on, Fedora 11, a base install with no X11 contains almost 1000 packages but you don't have "which"? Better yet, you have an extra package for this? Wow:

$ yum info which
[...]
Name       : which
Arch       : i586
Version    : 2.19
Release    : 4.fc11
Size       : 40 k
Summary    : Displays where a particular program in your path is located
Something like "fedorautils" might help, hm?
$ dpkg -S `which which`
debianutils: /usr/bin/which
Oh, and while we're at it: here's how to get httpd running on a different port:
# service httpd start
Starting httpd: (13)Permission denied: make_sock:
could not bind to address 192.168.10.104:1080
no listening sockets available, shutting down
Unable to open logs                                    [FAILED]

# tail /var/log/audit/audit.log
[...]
type=AVC msg=audit(1242447992.170:51): avc:  denied  { name_bind } for  pid=6144 \
comm="httpd" src=1080 scontext=unconfined_u:system_r:httpd_t:s0 \
tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket

# /usr/sbin/semanage port -a -t http_port_t -p tcp 1080
# service httpd start
Starting httpd:                                          [  OK  ]
A detailled explanation can be found in the Fedora SELinux User Guide.
Note: semanage comes with the policycoreutils-python package.

Rainforest Schmainforest

After stumbling over yet another celebritiy to speak out about the (dying of our) precious rainforests, I just couldn't help myself and wanted to see if the numbers add up. I'm talking about the rate at which the rainforests are destroyed, as they rank from "the size of a football" field every second or every four seconds.

A standard football pitch is about 7000 sqm in size. The size of the rainforest was much harder to come by, the number I have now is 2.6 million square miles or 6.73*10^12 sqm. Well, by that rate we should be out of trees in 122 years resp. 30 years with the more scarier number. Still, wouldn't that be just enough time to plant new trees as they are cutting them down? Then again, I don't know jack about envrionmental issues, but this play on numbers got me curious :-\

chmod octal form of sgid/suid removal fails

The was a disturbance in the force today:

$ mkdir dir
$ touch file
$ chmod +s dir file
$ ls -l
drwsr-sr-x 2 root root 4096 Apr 30 11:54 dir
-rwSr-Sr-- 1 root root    0 Apr 30 11:54 file

$ chmod 0750 dir
$ chmod 0640 file
$ ls -l
drwsr-s--- 2 root root 4096 Apr 30 11:54 dir
-rw-r----- 1 root root    0 Apr 30 11:54 file
Yes, this is even documented behaviour and conforms to POSIX as well - still, I find it far from being intuitive. There's a quite an interesting posting at the bug-coreutils list, stating:
> This topic came up when I first added that feature, and originally I
> agreed with you, but others did not and their arguments were
> persuasive.  The counterargument is that it's strange if a leading
> zero changes the semantics of a number, as this is not what many
> people expect.
...mentioning an earlier discussion on the same list. Oh well...

mod_mime_magic: invalid type 0 in mconvert()

I remember having these messages in my Apache logs before:

mod_mime_magic: type search/400\t\\\\section\ttext/x-tex invalid
mod_mime_magic: type search/400\t\\\\setlength\ttext/x-tex invalid
[...]
mod_mime_magic: invalid type 0 in mconvert().
....and I even remember setting up a workaround for this one. Now, years later this issue comes up again. Here's a rather ugly, semi-automatic attempt to remediate this (cosmetic) error:
$ awk '/mod_mime_magic:.*invalid$/ {print $9}' /var/log/apache2/error.log | \
   sort -u | \
   sed -e 's/search\/400.*\\\\/search\/400.*/;s/^regex.*tory\\t/regex.*/;\
   s/\//./g'  > /tmp/1
$ mkdir /usr/local/share/file/
$ cp /usr/share/file/magic.mime /usr/local/share/file/
$ for i in `cat /tmp/1`; do
     sed "s/^.*$i/# &/" -i /usr/local/share/file/magic.mime
  done
Now we can point MIMEMagicFile in mime_magic.conf to the new magic file and the errors should go away. Of course, fixing libmagic1 would be cool too :-)

HFS+

I just noticed that I could not chown files on this newly created HFS+ disk. Using diskutil, I could only see a few noteworthy differences:

$ diskutil info /
[...]
   File System:       Journaled HFS+
                      Journal size 8192 k at offset 0xe2000
   Owners:            Enabled
   Partition Type:    Apple_HFS
   Protocol:          ATA

$ diskutil info /Volumes/disk4
[...]
   File System:       Journaled HFS+
                      Journal size 81920 k at offset 0x1d1e000
   Owners:            Disabled
   Partition Type:    Apple_HFS
   Protocol:          Disk Image
As someone else suggested, I was able to use vsdbutil to enable ownerships/permissions again:
$ mount | grep /Volumes/disk4
/dev/disk4 on /Volumes/disk4 (hfs, local, nodev, nosuid, journaled, noowners)

$ vsdbutil -a /Volumes/disk4
$ vsdbutil -c /Volumes/disk4
Permissions on '/Volumes/disk4' are enabled.

$ mount | grep /Volumes/disk4
/dev/disk4 on /Volumes/disk4 (hfs, local, nodev, nosuid, journaled)

raw disk access in VirtualBox

With VirtualBox being the only open source virtualization suite for MacOS X at the moment, I'm running it from time to time to test new stuff. Currently there's a two disk storage box standing at my desk and I wanted to attach both disks to a VirtalBox Guest OS. Although documented in the manual and in the blogosphere, I found it hard to find the (few) commands needed to do this:

darwin$ diskutil list
[...]
/dev/disk3
   #:                  TYPE NAME              SIZE       IDENTIFIER
   0:      GUID_partition_scheme             *931.5 Gi   disk3
   1:       Microsoft Basic Data              931.5 Gi   disk3s1

darwin$ VBoxManage internalcommands createrawvmdk \
            -filename disk0.vmdk -rawdisk /dev/disk3 -register
The resulting .vmdk file will only hold metadata but not contain any actual data - exactly what we want :-)

Oh, and while we're at it: disk performance sucks in MacOS X. IMHO, sequential read/write bandwidth from/to the raw device should only be limited by its HBA respectively the device attached to it. Well, this SATA disk (WD10EACS) is specified with 3Gb/s or ~375 MB/s and is attached via Firewire 800 which in turn should be able to deliver speeds up to 100MB/s. But under MacOS 10.5 (fully patched), dd only scores ~16MB/s. It's good to know though that the VirtualBox Guest OS (Linux 2.6) with raw access to this disk is receiving these 16MB/s as well, so no overhead here. Accessing the same disk on the same box (iMac, MB323LL/A) natively under Linux 2.6 gives us ~66MB/s - a far more reasonable number.

Resizing a VMware disk for WinXP

This WindowsXP installation in VMware Server virtual machine was low on diskspace. So I looked at vmware-vdiskmanager which comes with VMware Server to resize the boot disk. The fact that my VMware disk was split into 2 GB slices (sigh) did not matter at all:

# ls -lgoh *vmdk
-rw------- 1 1.9G 2009-04-22 20:25 winxp-s001.vmdk
-rw------- 1 2.0G 2009-04-22 20:25 winxp-s002.vmdk
-rw------- 1 706M 2009-04-22 20:25 winxp-s003.vmdk
-rw------- 1  457 2009-04-22 20:11 winxp.vmdk

# vmware-vdiskmanager -x 6GB winxp.vmdk
Using log file /tmp/vmware-root/vdiskmanager.log
The old geometry C/H/S of the disk is: 9752/16/63
The new geometry C/H/S of the disk is: 12483/16/63
Disk expansion completed successfully.

# ls -lgoh *vmdk
-rw------- 1 1.9G 2009-04-22 20:25 winxp-s001.vmdk
-rw------- 1 2.0G 2009-04-22 20:25 winxp-s002.vmdk
-rw------- 1 706M 2009-04-22 20:25 winxp-s003.vmdk
-rw------- 1 415M 2009-04-22 20:25 winxp-s004.vmdk
-rw------- 1  457 2009-04-22 20:11 winxp.vmdk
I guess these are sparse images, growing dynamically in size. Now, we still have to tell WinXP that its boot disk has been resized. As it is the boot disk and we cannot use WinXP magic, I've decided to go with the GParted LiveCD. However, booting failed with strange SCSI errors. Chaning the VMware SCSI driver helped: simply set/add scsi0.virtualDev = "lsilogic" to your .vmx file - now GParted was booting and I was able to resize the parition. After doing that I found a resize-windows.txt on the LiveCD, stating that WinXP may have a problem when partition sizes change. Well, too late for that no as I already resized the disk. Luckily, WinXP was booting (after a chkdsk run has been forced), presenting me with a 6GB C: drive - nice :)

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...