Shared directories in Ubuntu using ACLs

A nifty article on how to use ACLs in Ubuntu to share directories effectively between user accounts.

http://brunogirin.blogspot.com.au/2010/03/shared-folders-in-ubuntu-with-setgid.html

I read in another blog on the way to the above link, that Ubuntu has a fairly prescriptive user permissions model, and I just wish they'd spell out what it is... Instead, users and administrators are left to pull together blogs, like this...

Viewing D-Link DCS-932L IP camera from Ubuntu

In a word (line) ...

avconv -r 15 -f mjpeg -i http://USERNAME:PASSWORD@IP-ADDRESS/video.cgi -i http://USERNAME:PASSWORD@IP-ADDRESS/audio.cgi -vcodec mpeg4 -f mpegts file:///dev/stdout | vlc file:///dev/stdin

Now, if only the audio didn't crash avconv, we'd be cooking with gas! The silent version is here, and seems stable.

avconv -r 15 -f mjpeg -i http://USERNAME:PASSWORD@IP-ADDRESS/video.cgi -vcodec mpeg4 -f mpegts file:///dev/stdout | vlc file:///dev/stdin

File upload and copy pattern

I was asked a different question; but then ended up with this instead. Shame to waste it...

The pattern that I've used in the past has directories like this (under some root directory like /var/lib/uploads):

/partial
/ready
/working
/success
/error

This set of directories are required for all traffic to a given recipient. Essentially, a file makes its way through the directories, from top to bottom. All directories should be on a single file system. File uploaders/clients should be able to write to /partial and /ready. File receivers/servers should be able to write to everything, except /partial.

Step 1: A file is uploaded/copied into the /partial directory; with a (globally) unique file name. This step completes when there's sufficient confidence that the file has been copied (usually that just means that the expected number of bytes has been written without an error being thrown).
Step 2:  The file uploader/client moves the newly uploaded file into the /ready directory. DO NOT COPY THE FILE!!!! In general, moving/renaming a file within a file system is guaranteed to be an atomic operation, but copying is not. This signifies that the file is ready (from the perspective of the client).
Step 3: When the recipient application/process is ready to process a file in /ready, it should first move the file into its /working directory.
Step 4: When the recipient application has finished processing a file (due to completion, or error) it should move the file into the /success, or /error, directory.

Things to watch
- more than one file in the working directory is likely to indicate a failure.
- Any file in the error directory is likely to indicate a failure.
- "old" files in the partial directory indicate unsuccessful copies/uploads.
- "old" files in the ready directory indicate that processing has failed/slowed.
- "old" files in the working directory indicate a failure/ABEND.
- Make sure the file system doesn't fill.
- Archiving is not covered here; that's a different pattern.

Other notes;
- If there is more than one recipient (e.g.: a multi-process server) there should be multiple working directories (working01 working02, working03, etc. - one for each process.
- this is essentially a queue implementation with single phase commit transactions.
- You can implement exactly the same pattern using file renaming, rather than separate directories. I prefer directories.

TIBCO fiddles

In brief:

1. When fiddling with TIBCO Software, use an OpenSUSE virtual machine, it hurts less.
2. Oracle XE is very handy for fiddling with TIBCO software - Here's a great web page explaining how to set it up on OpenSUSE - http://forums.opensuse.org/install-boot-login/414654-how-install-oraclexe-opensuse-11-1-a.html
3. Give your VM about 2GB RAM, or more.
4. Create a different Unix user for each 'build' (ActiveMatrix v2 suite, ActiveMatrix v3 suite, BusinessWorks/Administrator suite, etc.). Don't let them read/write to each other's files, ever.
5. Do not install gcj, OpenJDK, or anything remotely like Java and not made by Sun and/or Oracle.

Further Time Machine-esque behaviour

My earlier post on Time Machine-esque backups ( http://lastinfinitetentacle.blogspot.com/2009/06/backups-for-lazy.html )  has some useful links for getting regular differential backups going. However, it can be done more neatly, particularly when it come to Windows, and I've come across a nifty solution here http://www.robgolding.com/blog/2009/01/14/leveraging-vss-and-robocopy-for-robust-backups/

This approach requires the vshadow.exe application, which is its own can of worms. Typically, vshadow ships with a/the Windows SDK - ServerFault has some info ( http://serverfault.com/questions/137126/vss-error-521-when-attempting-backup/137254#137254 ) which suggests getting the Vista era SDK (v6.1, from http://www.microsoft.com/downloads/details.aspx?FamilyID=e6e1c3df-a74f-4207-8586-711ebe331cdc&displaylang=en ). You will only need to install the "Win32 Developer Tools" component; you can ignore everything else.

Using VSS (Volume Shadow Service) will allow an internally-consistent copy to be made of a Windows drive. All I then need to do is port the script here ( http://serverfault.com/questions/27397/sync-lvm-snapshots-to-backup-server/168034#168034 ) to Windows. I could use the script to push the image onto the file server, where it can update SVN repository (a physical backup, for bare metal recovery). Handling the (Windows) shadow drive can be achieved using the Windows-native 'dd' from http://www.gmgsystemsinc.com/fau/ . The same dd tool can be used for an 'easy' recovery. If I get this right, it should be Windows native, and easy to install/maintain.

A separate job will pick out user directories for the Time Machine treatment (more of a logical backup, also on my file server, for basic file recovery) via the mercifully short script I previously linked to, thus: http://blog.interlinked.org/tutorials/rsync_time_machine.html

Technically, I could use Zumastor/ddsnap on the file server to get snapshots/revisions, and I still might...

Virtualisation and Service Oriented Architecture

I was reading over at the TIBCOmmunity site regarding the impact of virtualisation on architecture
( http://www.tibcommunity.com/blogs/soa-architecture/2009/07/24/virtualization-and-its-affect-on-architecture ). There's some handy information here, but it feels a bit lost under a heading of "SOA architecture"; so I thought I'd have a go, under the heading of "I think...".

Virtualisation is the capability to encapsulate arbitrarily complex environments (by adding yet another layer of abstraction, naturally). Virtualisation is a means of utilising commodity hardware in ways that were previously the preserve of esoteric, expensive, proprietary systems.

What does this mean in the context of SOA?

I think the eventual result is that services can/will be built as software appliances. The moves around OSGi are heading in this direction, allowing a more 'focussed' environment to be built. I'll expand on my view of a software appliance life cycle in a later post.

I do believe that the eventual goal around a SOA (at a technical level) should be something like an AMI virtual machine (the lingua franca of the cloud), with defined "production", and management,  services. This could/should be hosted in some cloud (public/private), or combination of clouds. The services/VMs may depend on other defined services (provided in a SaaS, or other, manner). Some overarching management environment will be required to manage the relationships between services (and I believe that this is where VMware is heading, fast).

USB dead device fix

I have a slug (NSLU2) at home, serving out a big USB hard disk. I like my slug. It's small, and it runs Debian, and so long as I remember that it's really small, it runs really well.

It looks like USB drives suffer from lots of issues with dodgey firmware and drivers. Certainly, I haven't escaped them. Every few months I lose the USB drive:
kern.log:

Apr 12 20:32:54 slug kernel: scsi 1:0:0:0: rejecting I/O to dead device

...

This can cause filesystem corruption as well, and is generally "A Bad Thing". Fixing this issue is (for me) a case of remounting the filesystem. I recall once I also had to cycle the power too. Fortunately, I found this page: http://www.mail-archive.com/linux-usb-users@lists.sourceforge.net/msg16510.html which has a very nifty technique for coaxing the USB stack back to life.

I've written a script to pull out the sysfs name of the USB device for a given mount point. At some point I'll add this in to my slug so that it "just works". That just leaves a log scraper to pick up each mount and get the sysfs name, wait for a failure, unmount the dead file system, rebind the USB device, check the file system for damage, and remount the filesystem. Easy!

#!/bin/bash
# get_usb_name.sh 
# e.g.: ./get_usb_name.sh /media/usb2

USB_DEV=$(mount | grep ${1} | cut -f 1 -d ' ' | sed -e 's/[0-9]$//' -e 's(^/dev/((')
USB_ADDR=$(ls -l /sys/block/${USB_DEV}/device | sed -e 's(/host.*$((' -e 's(^.*/((')
if [ -e /sys/bus/usb/drivers/usb-storage/${USB_ADDR} ]
then
echo $USB_ADDR
else
echo "could not verify usb address of ${USB_ADDR} for device ${USB_DEV}" >&2
fi