Adjusting the service shutdown sequence on Debian

I manage a few virtual Debian (Wheezy) machines that mount an iSCSI volume. These hold websites and mysql data.

The problem is that in the default shutdown sequence, umountiscsi.sh is called before shutting down cherokee (or apache2) and mysql. So the umount fails because the filesystem is busy and the machine doesn't shutdown properly from the CLI, requiring a reset at the VMWare console.

I searched around for the way to adjust the dependency based boot and shutdown sequence and after reading a lot of web and manual pages I finally understood the way to do it.

First edit /etc/init.d/cherokee (or /etc/init.d/apache2) and /etc/init.d/mysql so that the line:

# Required-Stop:

contains umountiscsi.sh

The logic of Required-Stop is that the services named on the line depend on the current service (webserver, database) being stopped first.

Now run:

insserv -d -v umountiscsi.sh

Despite the warnings on the man page that this is too low level, this is the right command to use. It will rebuild the symlinks in the runlevel directories as well as regenerate the files /etc/init.d/.depend.{boot,start,stop} Next time you shutdown, the webserver and database will be shutdown before unmounting the iSCSI volume.

This assumes that the default start and stop sequences expressed in the INIT lines are correct for you. If you have added services manually using update-rc.d at particular runlevels and sequence points then I cannot guarantee that you will get the desired result.

Shrinking an ext4 filesystem from the CentOS 5.x CD/DVD in rescue mode

Unfortunately this cannot be done because the resize4fs program is missing from the rescue filesystem. You'll have to use a rescue distro, for example gparted-live, where the ext4 capabilities are already incorporated into the up to date resize2fs. CentOS/RHEL 5 ships with an old resize2fs and ext4 capabilities are in separate programs.

If it were a matter of expanding the filesystem this could be done on a live system.

If it were not the root filesystem you might be able to unmount the file system and do this on a live filesystem.

If it were not ext4 you could use resize2fs.

In any case a shrink involves downtime for that filesystem.

There is however a fsck.ext4 in the rescue filesystem so you can still do fscks in rescue mode.

DOS 6.22 printing to Samba fails with Path not found

My workplace wanted a NT server for DOS 6.22 clients replaced by a Samba server. No problem. Disk shares worked fine. But when it came to printing, this happened:

>net use lpt1 \\samba-server\printername
>copy con lpt1
Testing
^Z

Blah blah Path not found

I looked at the log file for the client in question and found these lines:

[2013/10/01 14:02:22.820899,3] smbd/vfs.c:905(check_reduced_name) check_reduced_name [DEV/LPT1] [/var/spool/samba]
[2013/10/01 14:02:22.820941,3] smbd/vfs.c:944(check_reduced_name) check_reduce_name: couldn't get realpath for DEV/LPT1 (NT_STATUS_OBJECT_PATH_NOT_FOUND)

Ah, was it trying to create a file called DEV/LPT1 in /var/spool/samba? But there is no subdirectory called DEV. So I did this:

# cd /var/spool/samba
# ln -s . DEV

Voila, printing worked from DOS. I can only surmise that DOS sends the whole path rather than just LPT1 to Samba or indeed any SMB server.

Hope this helps you if you need to convert any DOS clients to use Samba instead of NT.

Dumont d'Urville time?

When adding a new entry into Google Calendar on my Android phone, I noticed it defaulted to Dumont d'Urville time (UTC+10), although Sydney/Melbourne was also offered. What?!

A search shows that this is the time zone of a French Antarctic station which happens to be in the same time zone as the Eastern Australian seaboard. When I went into settings and chose Use Home Time Zone, all was good again. Pretty bizarre but amusing bug. I'm glad my appointments are in warmer climes.

It seems somebody has hit this bug before. Maybe it's because my phone has a rather old version of Android.

Installing phpMyAdmin 3 on RHEL/CentOS 5.9 running PHP 5.3

If you are running the PHP 5.3 (php53-*) packages on RHEL/CentOS 5.9 and try to install the phpmyadmin package from CentOS Base or RPMForge, you will get messages about installing the ancient PHP 5.1 packages. This was not what I wanted to happen, so I looked for a ready made phpmyadmin package that would work with PHP 5.3. I was prepared to install from a phpMyAdmin tarball, but I hoped to avoid that because an official package would stay up to date with patches.

It wasn't well publicised but the answer is to add the EPEL repository by downloading the epel-release RPM from here and installing that. After that you can do yum install phpMyAdmin3 (case important). This is the package you want.

The Russians are not that interested in you(r blog)

When I started publishing on this blog and others years ago, I was initially gratified to see in the statistics referrals from certain sites. Of course, my vanity was punished when I discovered that these sites had nothing at all about my posts.

Some searching showed it's a practice called referer spam. No human has actually read your post for those hits. A web bot has fetched your page, but supplied a fake referral URL. So when you look at your statistics you think somebody has linked to you. You click on the link and the spammers get another page view.

The most blatant fake referrals had query terms promoting dubious products. The less blatant ones had query terms with a unique ID that let the site know you had clicked on the link. And serve up some spam after that. Some spammers used URL shorteners to conceal the source of the fake referral. At some point about a third of my "hits" were from Russia. I don't think I have that many readers there, even though I provide a translation button. Also it seems they have a way of detecting when a new blog has started up so they can target a fledgling blog. After I had published the last post of a travel blog, they lost interest in my blog.

What can you do about these fake hits? Basically nothing. Just ignore the fake hits in your statistics. Don't click on the links. Don't reward them with traffic.

By the way it isn't just the Russians doing it, there is one Korean site that attempts to get page views this way. Also some spammers use servers or hijacked PCs in the US to make it look like the hits came from there.

RAID UUID != filesystem UUID

I had copied a RAID filesystem onto larger disks using a second computer and wanted to mount it on the original computer with minimal disruption. To this objective, I made the UUID of the new RAID array the same as the previous RAID using the assemble command of mdadm, like this:

mdadm -A /dev/md1 -U uuid --uuid=<old RAID UUID> /dev/sdb3 /dev/sdc3

(If the array is currently assembled, you have to disassemble it it first with mdadm -S /dev/md1)

This worked fine and I was able assemble the RAID on the second computer using the /etc/mdadm.conf from the first computer.

At the same time I decided to change to mount by UUID, so I edited /etc/fstab to look like this:

/dev/disk/by-uuid/<RAID UUID> /home xfs default 1 2

Alas when I booted, the RAID array wouldn't mount and I had to reboot in rescue mode to fix it up.

I wondered why the discrepancy between the symlink to /dev/md1 in /dev/disk/by-uuid and the RAID UUID. Eventually after some red herrings I understood. RAID UUID != filesystem UUID. They are distinct UUIDs. The filesystem UUID is that of the XFS (or ext4, btrfs, whatever) filesystem on it and is what is reported by blkid when udev runs it to populate the by-uuid directory. On the other hand the RAID UUID is what mdadm uses to match against entries in /etc/mdadm.conf when assembling the array.

The second lesson I learnt (again) is that you should not change two things in your config at once. I should have booted the machine up with /dev/md1 in /etc/fstab and then explored by-uuid later.

I could have kept the random RAID UUIDs generated by mdadm for the new disks and just run mdadm --examine --rescan > /etc/mdadm.conf in rescue mode to rebuild the metadata, but I want to be able to swap in the old RAID disk in an emergency and it's one less step to make the RAID UUIDs the same.