Skip to main content

All your pma controlusers are belong to us!

phpMyadmin told me today:
Connection for controluser as defined in your configuration failed
Luckily I came across a helpful post telling me to change:
$cfg['Servers'][$i]['controluser'] = 'pma'; $cfg['Servers'][$i]['controlpass'] = 'pmapass';
$cfg['Servers'][$i]['controluser'] = ''; $cfg['Servers'][$i]['controlpass'] = '';
....and the error was gone :-)

ksh vs. bash

We all know that our shell of choice (c'on, admit it :-)) is "too big and too slow" (quote from its manpage). But I was surprised to see *how* slow it was for this particular operation:

Update: Thanks to an observing commenter I had to find out that 'expr' is NOT a shell builtin but a simple binary. I always wondered *if* it was a shell builtin and always wondered if scripts with 'expr' would be portable and all but I never got around to do just 'which expr'. Damn. Anyway, here are the updated results now. Thanks again Roland for pointing this out! The gap between bash and ksh is not so big any more, although it's still visible:

# cat
while [ "$i" -lt 10000000 ]; do

# for i in ksh zsh pdksh mksh bash; do (echo "SHELL: $i"; time $i; done
SHELL: ksh
real	0m45.196s
user	0m44.676s
sys	0m0.070s

SHELL: zsh
real	1m13.755s
user	1m5.651s
sys	0m7.402s

SHELL: pdksh
real	1m7.300s
user	1m6.013s
sys	0m0.092s

SHELL: mksh
real	1m8.922s
user	1m8.013s
sys	0m0.091s

SHELL: bash
real	3m10.721s
user	3m0.016s
sys	0m6.372s
This was done with ksh from AT&T Research (1993-12-28), zsh 4.3.4, PDKSH v5.2.14, MIRBSD KSH R32 and GNU bash 3.2.39(1) on a MacMini.

Update #2: as pointed out in the comment section, "(())" should be faster, so let's try again:
$ cat 
while (( i++ < 10000000 )); do
$ for i in ksh zsh pdksh mksh bash; do echo "SHELL: $i"; time $i; done
SHELL: ksh
real    1m59.642s
user    1m58.340s
sys     0m0.012s

SHELL: zsh
real    3m34.747s
user    3m4.588s
sys     0m25.616s

SHELL: pdksh
real    4m15.224s
user    4m10.056s
sys     0m0.028s

SHELL: mksh
real    4m48.835s
user    4m43.480s
sys     0m0.036s

SHELL: bash
real    10m9.914s
user    9m52.724s
sys     0m4.072s
This was done with ksh-93s+ from AT&T Research (2008-01-31), zsh 4.3.10, PDKSH v5.2.14, MIRBSD KSH R39c and GNU bash 4.1.5(1) on a PowerBook G4 (M9691LL/A) (throttled to 750MHz).

grep --color=tty

While I am using grep(1) with colours for some time now (it's soooo helpful), I did not know about the =ttymode. Ulrich explains:

Using tty as the color mode mean that if I pipe the output into another program there won't be any color escape sequences added which could irritate those programs.
Strangely enough, the manpage (from GNU grep 2.5.1-cvs) does not mention this mode. Btw, instead of just adding aliases, GNU grep honors the GREP_OPTIONS variable.

wpa_supplicant b0rked, NFS choking, CIFS barfing

Oh yes, it's a fun ride with Debian/sid. And with the (almost) latest kernel even more so. Since the wpa_supplicant breakage is pretty nasty, this will be reported later at a more useful place. I thought I could finally disable CONFIG_DNOTIFY since it says: There exist superior alternatives, but some applications may still rely on dnotify. But rpc.idmap broke, so I read again and it said "If unsure, say Y" too - and it worked. And once again, I came across: CIFS VFS: cifs_mount failed w/return code = -22 and once again it took me a while but strace(1) revealed:

lstat64("/etc/mtab", {st_mode=S_IFREG|0644, st_size=912, ...}) = 0
readlink("/", 0xbf9405db, 4096) = -1 ENOENT (No such file or directory)
stat64("/sbin/mount.cifs", 0xbf9423a0)  = -1 ENOENT (No such file or directory)
rt_sigprocmask(SIG_BLOCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0
stat64("/sbin/mount.cifs", 0xbf942380)  = -1 ENOENT (No such file or directory)
mount("//", "/mnt/", "cifs", MS_MGC_VAL, NULL) = -1 EINVAL
So we really *have* to install the smbfs package to mount CIFS volumes (don't bother with SMBFS, it's dead, Jim). Quick benchmark CIFS vs. NFSv3:
# dd if=/nfs/file.img of=/dev/null bs=8M
86+1 records in
86+1 records out
727306240 bytes (727 MB) copied, 66.6383 seconds, 10.9 MB/s

# dd if=/cifs/file.img of=/dev/null bs=8M
86+1 records in
86+1 records out
727306240 bytes (727 MB) copied, 112.473 seconds, 6.5 MB/s
The server (2.6.24-rc2/knfsd, smbd-3.0.26a) was pretty much idle, the file.img was cached already, so no disk i/o on the server. The client (2.6.24-rc2, smbfs-3.0.26a) had 100% iowait with NFS (network being the bottleneck) but with cifs the [cifsd] kernel thread was using up ~30% utime, while the box was idle (60%, with 8% iowait).


Sure, I could've just apt-upgrade'd to the newest ubuntu-release and be done with it - but that would've been too easy. Really, the ubuntu-installer is a must-have-experience: booting a LiveCD, clicking around like you just don't care ('cause you (almost) cannot break stuff) and then, when you realize that you can watch movies from a network share (yes, it'll install missing (read: ugly) codecs too) you can press PAUSE click on the INSTALL button on your desktop, answer a few question an continue watching this por^Wmovie again. When the movie is over, your installation is too :) But I wouldn't write a blogentry when all has been blue skies, now would I? No, booting the 7.10 bootcd did not work at all first. I had to choose "live-powerpc-nosplash", otherwise the display would just flicker (or: oscillating between black/grey). Since I'm running MacOS X on this same iBook and ext2fsx to access ext2/3 partitions from OS X, it'd be a good idea to install ubuntu-7.10 on ext3, not some other (better?) filesystem. OK, lesson learned, but too late. When installing again (while watching another movie, hehe), I thought it'd nice if the installer could grab packages from a local cache instead of fetching them all by himself (again). But the local cache was already wiped :( This time I've just setup Squid acting as a transparent proxy to cache package files: squid.conf:

http_port transparent
maximum_object_size 128 MB
minimum_object_size 512 KB
cache_dir ufs /var/spool/squid3 1500 16 256


iptables -A PREROUTING -s $LAN -d ! $LAN -p tcp -m tcp --dport 80 \
-j DNAT --to-destination
Instead of using Squid, you could use apt-cacher too. But again: too easy :)

[KERNEL]: no space in available paging segments

Today, Firefox on my iBook/G4 (with MacOS 10.4.10) started to swap and after consuming ~800MB of virtual memory, OSX said: (default pager): [KERNEL]: no space in available paging segments Some posts on the web explained what was happening. To summarize: * virtual memory is created by the dynamic_pager in /private/var/vm/swapfile* * disk I/O goes to the roof when the OS needs more swap * if the box cannot keep up the I/O and thus cannot satisfy the pager, it assumes -ENOMEM and will print the message above IOW: get more RAM (or faster disks) :) We could also play around with the pager: sudo dynamic_pager -H 40000000 -L 576870920 -S 536870912 -F /private/var/vm/swapfile

fun with squid and the loopback device

Sometimes I admire these online bookmarklists, being always available, not application bound and all but then again I refrain from using them, for privacy reasons. Not private at all are these two links:

  • Fun with squid, imagemagick and ARP spoofing which I found a pretty funny thing to do and reminded me of a similiar experiment back in 2001. Have a read!
  • Searching the web for how to specify a sectorsize on virtual/loop devices, I came across yet another wiki with lots of information and practical shell snippets messing around with loop devices. However, I still don't know how to solve the initial problem, blockdev --setss does not exist/work :(
  • grand unified failure

    When trying to re-install GRUB: # grub-install /dev/sda1
    The file /boot/grub/stage2 not read correctly.
    ...but the intertubes saved my day, when I came across: # grub
    grub> root (hd0,0)
    grub> setup (hd0)
    Checking if "/boot/grub/stage1" exists... yes
    Checking if "/boot/grub/stage2" exists... yes
    Checking if "/boot/grub/e2fs_stage1_5" exists... yes
    Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 17 sectors are embedded.
    Running "install /boot/grub/stage1 (hd0) (hd0)1+17 p (hd0,0)/boot/grub/stage2 /boot/grub/menu.lst"...
    grub> quit
    However, I still don't know why grub-install doesn't work anymore.

    rpc.idmapd woes

    Bug #87382 bit me: # mount -t nfs4 sheep:/nfs4 /mnt/nfs4
    Warning: rpc.idmapd appears not to be running.
    All uids will be mapped to the nobody uid
    ...although rpc.idmapd was running (on the client). Now I have to: /bin/pidof rpc.idmapd > /var/run/ But the real question is: why does mount(1) bother for pidfiles, rather than checking for functionality?