Fixing A Mangled PDF With Some Pages Requiring Rotation

 Working Notes  No Responses »
Apr 032013
 

Scanning paper documents is such a tedious task that I tend to lose concentration when doing it. And as a result I recently ended up with two PDF documents needing post-processing. In the worst case, the PDF consisted of three pages – one in the correct orientation, and two rotated 180°!

As usual, there’s a Unix command to help out with that – pdftk. Specifically :-

pdftk \
  input-file.pdf \
  cat 1 2-endS \
  output out.pdf

The interesting operation is contained within the cat 1 2-endS which translates as copy the input page 1 to the output unaltered, and copy the remaining pages rotated 180° (or “S”) to the output. This is of course only the tiniest fraction of what this tool can do.
 

Awesome: Fixing The Titlebar

 Computing, Working Notes  1 Response »
Mar 242013
 

The default title bar provided by Awesome is not quite to my taste. And this posting is about fixing that.

The first part is to select some colours. For me, I prefer window decorations to be subtle … grey scale; the window decorations should disappear until you focus on them. And I’m choosing to have a lighter grey for focused windows, and darker for others. The colours are set in the default-theme.lua file :-

theme.titlebar_fg_normal = "#000000"
theme.titlebar_fg_focus = "#000000"

theme.titlebar_bg_normal = "#cccccc"
theme.titlebar_bg_focus = "#e8e8e8"

The next step is to restrict the number of buttons that appear in the title bar – this is of course a matter of choice, but personally I believe that there are too many buttons by default. This is done within the main configuration file and by deleting the buttons you wish removed, which in my case means removing the lines :-

right_layout:add(awful.titlebar.widget.floatingbutton(c))
right_layout:add(awful.titlebar.widget.ontopbutton(c))

Lastly, and in keeping with making the titlebar less obtrusive, there’s shrinking the titlebar to a sensible size :-

awful.titlebar(c, { size=16 })

Which is added after the line: awful.titlebar(c):set_widget(layout) (it could be merged). There are two features I’d like to use with no method easy enough for a thicko like me to spot :-

  1. There seems no obvious way to put the title bar on the left (or right) side of the window; it seems an obvious thing to try given that screens are usually far wider than tall. There are hints that there is an attribute (if that’s the right word) called “position”, but I don’t see a way of setting it.
  2. I have removed a certain number of options for controlling the window, partially because I can never remember what those silly icons mean. But I would quite happily add a menu with all of the relevant methods – and this would be a good place to add the keyboard shortcuts (us old foggies need some helpful hints like that).

 

FreeBSD: Increasing The Size Of Disks In A ZFS Pool

 Computing, Working Notes  No Responses »
Feb 112013
 

One of the obvious things to do with a ZFS storage pool is to increase the size of the disks in it – after all disks get bigger and cheaper over time. Not that it is a very difficult thing to do, but it is always worth doing a quick search to find out what others have done before setting forth. And if nobody blogs their own experience, there’s nothing for anybody to find!

So I started off with four 2Tbyte drives configured as two vdevs each of which was a mirror. And I had two 3Tbyte disks to swap in. So I was going to be swapping one of the vdevs (consisting of two 2Tbyte drives) with the 3Tbyte drives.

In the details below, I have a storage pool called zroot and the two disks being replaced are gpt/disk3 and gpt/disk2. As you will notice, I am growing the storage pool I boot off; however the disks I am using do not contain a boot partition with the boot code.

The first job was to swap out one of the 2Tbyte drives. This was done by :-

  1. Take disk to be swapped out offline: zpool offline zroot gpt/disk3
  2. Shut down the server and take the selected drive out. Swap over the disk caddy onto a new 3Tbyte drive, and swap that back in.
  3. Power on the server.
  4. Create an EFI partition table: gpart create -s gpt ada3
  5. Optionally create a swap partition: gpart add -t freebsd-swap -s 4G -l swap3 ada3
  6. Create a ZFS partion: gpart add -t freebsd-zfs -l disk3 ada3
  7. Replace the device: zpool replace zroot gpt/disk3

Now is the time to wait for the resilvering process to complete. Once that has finished, the steps above can be repeated for the other drive in the vdev. Once the resilvering for that replacement has finished, you may want to check the size of the pool.

If the size has not increased, you may need to do: zpool online -e zroot gpt/disk2 gpt/disk3.

Linux Volume Manager: Growing Filesystems

 Computing, Linux, Working Notes  No Responses »
Feb 062013
 

If you have previously used Linux’s volume manager (LVM) to set up disk storage, you may want to know about how to grow a filesystem safely.

Which is probably the big feature of any decent volume manager because accurately predicting the size of filesystems is a black art, and the only alternative – to make the root filesystem contain all of the storage is a dumb idea.

It’s actually really easy and can be done non-disruptively. It is done in two parts – effectively growing the “disk” device and then growing the filesystem itself.

Extending The Volume

First identify the volume you need to extend. You can of course simply run lvscan which will show a list of the volumes, and if you have named them sensibly will allow you to pick out the volume to extend. But the simplest way is simply to run df to look at the filesystem you want to extend :-

/dev/mapper/ssd-opt         7.9G  5.5G  2.1G  73% /opt

The device (in the first column) is what we extend. Now to decide how much to grow the volume by; just for the case of this example, we’ll assume that 2Gbytes is a sensible amount to grow the volume by. The command needed is :-

lvextend --size +2G /dev/mapper/ssd-opt

And that’s it. No need to shut down the server, dismount the filesystem, etc. Of course we haven’t quite finished yet.

Growing The Filesystem

What we have done at this point is the equivalent of making the disk bigger. We also need to tell the filesystem it is sitting on a bigger disk, and to do so we need to know the type of the filesystem. The canonical place for checking that is the file /etc/fstab (actually it’s the filesystem itself but that is going too far) :-

# grep opt /etc/fstab
/dev/mapper/ssd-opt	/opt		ext4	noatime		0 3

It is probable that you are looking at growing an ext3, ext4, or xfs filesystem. If not you will have to look up the details yourself.

Growing ext3, or ext4 Filesystems

This is done with the resize2fs command :-

resize2fs /dev/mapper/ssd-opt

Several points :-

  1. Yes it can be done “online” whilst the filesystem is mounted (and applications are busy using it).
  2. You need to specify the device containing the filesystem to grow and not the mount point.
  3. There is no need to specify the size … the size will be determined from the size of the device underneath the filesystem.

Growing xfs Filesystems

This is done with the xfs_growfs command :-

# xfs_growfs /opt

Several points :-

  1. Yes, it can be done “online”. In fact you have to do it with the filesystem mounted.
  2. You need to specify the mountpoint of the filesystem and not the device. Irritatingly different from the above!
  3. There is no need to specify the size.

How Reliable Is This?

Very.

There is always the chance that something could go wrong especially if you are operating “at the edge” (say you have a filesystem that is unusually large – several petabytes). But I’ve done online filesystem resizing for years in countless circumstances without an issue.

I’ll quite happily do it on the most important systems during working hours without losing a moment’s thought. However I do work in a place that takes backups seriously!

Adventures in Cisco IOS Land: A Route For “Unknown” Internal Networks

 Cisco, Computing, Working Notes  No Responses »
Jan 262013
 

First defining the problem. Let us say that I have a network with plenty of space for subnets (perhaps 10/8) and I am only using a very small number of the possible subnets – for this example, perhaps 10.0/16, 10.1/16, 10.2/16. What happens when I ping something like 10.52.1.3? Or perform a network scan of 10/8 ?

Well logically if a packet is destined for an unknown network, it will get routed to the default gateway (or “gateway of last resort” in Cisco’s rather gloomy terminology). Given that in most cases, the default gateway is going to be pointed in your ISP’s direction, this is probably not a sensible choice. In most circumstances it probably doesn’t matter, but there are a number of scenarios where it could be an issue :-

  • If the default gateway thinks that the route to 10/8 is back down to the router, then you’ll have packets bouncing back and forth for a while. This may not be a major issue … or it could be if someone tries to flood all your unknown networks as quick as possible.
  • Your default gateway could be a firewall of some kind which helpfully blocks such packets itself. However it may also helpfully log all these in your log files as problems which unhelpfully conceals other issues. You do inspect your log files, don’t you?

There are quite possibly other problems I cannot think of on a lazy Saturday, but it’s also the case that preventing packets destined for unknown packets leaking is the right thing to do.

So how to do it ? With a static route of course :-

conf t
> ip route 10.0.0.0 255.0.0.0 Null0 254
> ipv6 route 2001:db8:beef::/48 Null0 254

The choice of the device Null0 is a bit problematic; it should really be a “device” that returns a ICMP destination unreachable immediately. However it’s better than nothing.

The choice of the “metric” 254 (or “administrative distance”) is specifically chosen to allow any other route learnt by any mechanism to overrule this route.

Having a route to Null0 that covers all your internal subnets may seem alarming, but it seems to work – at least for my network. It is also documented that routing will choose the most specific route in preference to the least specific route – or in other words a route to 10.0/16 is used in preference to the route to 10/8.

Of course if some Cisco routing guru comes along, I’d be more than willing to be corrected. I’ve also tried to check this against Cisco’s “routing for dummies” document.

 Older Entries  Newer Entries