If you use LVM (Linux volume manager) you’ll be no doubt aware that the ability to place your volumes in groups and name the volumes accordingly makes administration much easier. Having a volume group called oracle and then a binaries and data volume means a tiny glance at a system identifies what is doing what (or so I was under the impression). When it comes to doing any sort of low level administration or system metrics, you may notice that device paths change. Using fdisk or looking at /proc metrics and you’ll suddenly come across dm-0 etc..  devices, which clearly are the lvm devices under another name. Scanning quickly through a ton of web pages and the lvm2 documentation turned up nothing.

Then I realised that the first two columns in /proc/diskstats where the major/minor device numbers, which when compared with the entries in /dev/mapper allowed me to match up the devices. This can also be achieved by looking at the major/minor numbers from lvdisplay and dmsetup ls. However the latter two tools require root privileges so clearly were not going to work with my current project.

Turned out that the simplest method is to look through the sysfs file hierarchy as the block devices can identify other names that they have. The following command will iterate all of the block devices with alternative names and print them in a format that can be piped into anything else, or in my case be read easily into an NSArray.

grep -H "." /sys/devices/virtual/block/*/dm/name \
| sed 's/\/sys\/devices\/virtual\/block\///g' \
| sed 's/\/dm\/name:/ /g'

I finally crumbled and gave the gimmicky disposable app a go, sharing some film with a friend(@Grizly_Chops) form New Zealand. Initially I found the experience a bit annoying as i’ve become so used to immediately viewing my results, usually deleting just as quick and lining up a shot for attempt 2/3/4/… I hadn’t really paid it a huge amount of attention just taking a pic here and there although was pretty excited when my phone dinged this morning telling me the roll was finished.

I think the results are pretty nice, a couple of duplicate shots have appeared I assume this is due to not being able to see results. Might try a different roll of film and try to recruit some more snappers.

The flooding in Thailand has been pretty horrible for a number of reasons (mainly deaths and loss of homes/possessions), but its also having a knock on effect in the area of hard drive manufacturers.

http://www.guardian.co.uk/technology/2011/oct/25/thailand-floods-hard-drive-shortage

This has had a further effect of having all of the resellers increase the price of hard disks quite significantly in some cases doubling the price in a couple of weeks. Quickly looking at a few places in the UK (at the current date 1st Nov ’11) you can see that the average 2Tb hard disk is currently priced at around £130

I fought with this about a year ago, and for some strange reason never managed to get things to compile or link. I chalk this down now to my lack of understanding with Objective-C/linking concepts. However it turns out that it is relatively simple (ensure you have Xcode 4 installed before trying).

1. Point browser to http://www.libssh2.org/ and download the latest snapshot to a temporary location.
2. Open a terminal window and navigate to the directory containing the the source files and run the following:

   dan$ ./configure

3. This will output numerous content to the terminal window, present a summary of the configuration options and create a header file needed for compilation. (Running make / make install is NOT required).
4. Open Xcode and create a new Xcode project, which should be a (Mac OS X -> Framework & Library -> C/C++ Library) and give it a Product Name (e.g. libssh2) and ensure that the type is Static then click create.
5. Xcode will open with an empty project displaying the Build Settings. At this point we can start adding the files that are part of the libssh2 source tree.

This is a technique I had to use numerous times for a previous job where I would need to transfer files from servers that could not be connected to directly. In the majority of companies there will be numerous networks, where “jump boxes” are required to get across various networks and get to the server in question.

The usual approach of moving files to servers would be through a variety of means (FTP/SCP/NFS/CIFS etc.), however in the case of numerous jump boxes and networks would mean that having to transfer the file between each jump/network. It is possible to use copy and paste however this would only work in the case of text files, trying to display or copy binary data can cause all manner of issue and really mess up your terminal window. So for me the best solution is to UUEncode the binary data into ansi text which can be safely copied out of the terminal window, pasted into a file on your local machine and UUDecoded back to binary data again.

To do this simply UUEncode a file, and the output will be presented to STDOUT i.e. the terminal window.

$ uuencode test.rpm test.rpm

Note: the double typing of the name is required as the first argument is the file to uuencode, whilst the second argument is the name of the file that will be outputted. The output will be presented to STDOUT as shown in an example :

begin 644 test.rpm
M"GP]+2TM+2TM+2T]6R!796(@=G5L;F5R86)I;&ET:65S('1O(&=A:6X@86-C
M97-S('1O('1H92!S>7-T96T@73TM+2TM+2TM+2T]?`I\/2TM+2TM+2TM+2TM

The next step is simply to copy everything from the word “begin” to the word “end” out from the terminal window and then paste it into a text editor of your choice on your local machine under a temporary name. This will then need opening with uudecode, which will then process the text and spit out the file under the filename specified with the encoder.

$ uudecode temporary.uua

In the same location will be the decoded file.