Skip to main content

munin: add timezone to timestamp on html pages

That's what I was looking for. Until our distribution of choice includes this fix, we can use:
--- /usr/share/munin/munin-html.orig    2010-01-26 19:22:09.000000000 +0100
+++ /usr/share/munin/munin-html 2010-01-26 19:26:59.000000000 +0100
@@ -311,7 +311,7 @@ foreach my $file( (@files) ) {
 #make domain list
 my @domainlist = map { { DOMAIN => $_ } } @domainorder;
-my $timestamp = strftime("%Y-%m-%d T %T", localtime);
+my $timestamp = strftime("%Y-%m-%d T %T %z", localtime);
 for my $domain (@domainorder) {
     logger("processing domain: $domain");
     my %domain;


Whadayaknow, our shell of choice still has its limits:
# echo $((2**63-1))

# echo $((2**63))

# file $SHELL
/bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) [...]
Zsh seems to have the same limit; ksh93 does:
ksh93$ echo $((2**1023))

ksh93$ echo $((2**1024))
And csh seems to need some magic to do exponentiation at all.

Security theater has come to town!

I always wondered what the blogosphere was babbling about regarding the shiny new security measures recommended by the TSA. Well, now I know what Security theater feels like: half-assed "everything must be checked" searches for everyone boarding a plane to the US.

So there are two security checks at LHR now: the first one is the usual metal detector and hand-baggage scanning, with random individual checks which takes about a minute per person. The other one is *at the gate*, starts at boarding time (expect major delays!) and takes 3-5min per person. Yes, these are made-up numbers, since TSA's Wait Time Calculator is out of order at this time, probably due to unforseen security checks. And "half-assed", because the search drones are trying so hard to do as instructed in their classroom, that they're looking diligently at laptops and little baby-bottles, as if they could spot "dangerous looking items" with their bare eyes.

And even if they found something: will the security guys from the first checkpoint be fired then? Why not? FYI, neither of them found the matches in my hand luggage - and yes, I must've left them there by accident, I did not study their Airport Screening Manual that was leaked some time ago :-)

Welcome to the future!

Oh, what a nice way to begin the new year: apparently, all incoming mails are tagged with FH_DATE_PAST_20XX, meaning:

  The rule matches the year (a string of four numbers) in the Date header,
  and checks if it is between 2010 and 2099. 
...which is a silly thing to do in 2010 :-) This has been fixed upstream a few months ago, our distribution of choice is already on it.

scselect FTW!

Having a portable computing device, I tend to switch network locations fairly often. While the configuration of these locations is really comfortable and easy (YMMV), switching between different locations is a real clickfest. Sure, there's a tool called NetworkLocation, where you can switch locations and even more, but installing yet another application just to switch network locations? I wish Apple had thought of this. Well, they did - kinda, for the geeks, at least:

$ scselect
   5BD6CDE3-1F56-15D5-B0EE-38D661618EDD (foo)
 * D193EEBE-7E81-1173-9E0B-D9EDE1331D39 (bar)
   111891B8-8CE1-1EBC-B15E-36F01689DD77 (Automatic)
There's also an AppleScript helper app for all you mouse people. Hey!

umask & symbolic links

Oh, this is fun - not: apparently ln behaves quite differently on Linux and on MacOSX (using stock Darwin/ln or ln from GNU/coreutils):

$ uname -s && ln --version | head -1
Linux 2.6.33-rc1
ln (GNU coreutils) 6.10

$ umask 0022
$ mkdir test
$ umask 0066
$ ln -s test a

$ ls -ldog test a
lrwxrwxrwx 1    4 2009-12-25 13:01 a -> test
drwxr-xr-x 2 4096 2009-12-25 13:00 test
and on the Darwin side:
$ uname -sr
Darwin 10.2.0

$ umask 0022
$ mkdir test
$ umask 0066
$ ln -s test a

$ ls -ldog test a
lrwx--x--x  1    4 Dec 25 13:02 a -> test
drwxr-xr-x  2   68 Dec 25 13:02 test

$ /opt/local/bin/gln --version | head -1
ln (GNU coreutils) 7.6
$ /opt/local/bin/gln -s test b

$ ls -ldog b
lrwx--x--x  1   4 Dec 25 13:12 b -> test
So, who's right?

Grrr, s9y mag kein HTML in Kommentaren, dann muss ich das hier loswerden: Danke fuer das Feedback, gnarf, trotzdem ist das inkonsistent:
$ umask 0666
$ ln -s test a
$ touch b

$ ls -ldog test a b
ls: a: Permission denied
l--x--x--x  1    4 Dec 25 15:01 a
----------  1    0 Dec 25 15:01 b
drwxr-xr-x  2   68 Dec 25 14:58 test

$ rm a b
override ---------  christian/staff for b? y
....but rm doesn't ask for permission to remove "a". I'm looking up symlinks in die POSIX documents, but so far no word on messing around with umasks. And why should they, given that permission checks are done on the target anyway. When using creating a file in Linux, strace(1) shows:
while creating a symlink simply does
  symlink("test", "b")                    = 0
And the symlink() part looks pretty much the same as the POSIX reference.

bonnie++ and the -n switch

Maybe I'm st00pid, but the -n switch in bonnie++ always confused me. While other switches like -s or -r expect "megabyte", -n is a bit different:

# bonnie++ -d /mnt/disk -s 128 -b -n 8:1048576:1024:1 -m `uname -n`
Apparently the -s 128(MB) is only used for I/O performance. I/O as in throughput only. It has nothing to do with the file creation tests, that's what -n is for:
-n 8       - multiples of 1024, we'll create 8192 files here 
   1048576 - max filesize in bytes - 1MiB here
   1024    - min filesize in bytes - 1KiB here
   1       - spread files evenly across that many subdirectories
So, in our case, bonnie++ would create 8192 files à 1MiB (max) files in one directory, which sums up to 8 GiB. Gotta remember that now. Grrr.