Something that has been annoying me recently with my bank has been that their website tells me that they will never ask for my password over the phone. And then their call centre asks me for my password. Over the phone. Of course the call centre doesn't mean my website password - they mean the special 'ultra-secure 5ekr1t code phrase', but they don't have a good, universally understood word to use for that. Hopefully they'll work one out, but they appear to have got the message anyway. This got me to thinking about how these phrases are used, and how insecure they are in reality. After all when I store a website password I go to significant lengths to ensure that the same password is not represented by the same string of characters in my database. How vulnerable are our secrets in the databases of organisations we do business with?
<!--break--> Simple Password Storage Surprisingly often people do store passwords in databases in plain text, so that should their website get hacked someone would quite possibly be able to download the whole password database. Please feel free to name and shame these organisations in the comments below. My own pet hate in this regard is the 'Mailman' mailing list software: by default on 'mailman day' - the first day of each month - it sends me my password. In plain text. Of course many developers recognise this flaw, and work around it by using a one-way hash to obscure the password. Usually they choose md5 for their hashing algorithm though, and they often fail to use a 'salt' to randomise the plaintext prior to hashing. This means that even though a password might seem obscure like 'Supercalifragilisticexpialidocious!', and no doubt it will hash to something that seems obscure like 'a7290d426b6a1764af6fd7fba5db214e', but you can often find it straighforwardly by looking it up through one of the friendly reverse hash lookup websites. There's even a Digest::MD5::Reverse perl module on CPAN to interface to a bunch of these in a more automated way! Oh dear. One way to go beyond this is using a 1-way hashing algorithm, with a random salt included into the plaintext before the hashing, so that if (god forbid) two users had 'password' for their password I might see two rows in my database like:

davical=# select username, password from usr;
  username                       password                          
-------------+------------------------------------------------
 user1          SSHA qCctCH5dirYCf29uxJiE68LvmLRDdnBkbldiWlE=
 user2          SSHA y8yOzjoh9fSkVwLaXGoVtWdiIYxmU2FCb2dOZXc=
(2 rows)

When the user wants to log in I apply the same transformation to their incoming password (appending the same salt) and compare against my stored hash. If they match then it must be the same password they used previously. Storing passwords in this way secures them from casual, or even reasonably determined access, although naturally they can still be logged at the beginning and end of the communication - or even in the middle, if we didn't encrypt that bit! The PHP function I use to salt and hash the password is as follows:

/**
* Make a salted SHA1 string, given a string and (possibly) a salt.  PHP5 only (although it
* could be made to work on PHP4 (@see http://www.openldap.org/faq/data/cache/347.html). The
* algorithm used here is compatible with OpenLDAP so passwords generated through this
* function should be able to be migrated to OpenLDAP.
*
* If no salt is supplied we will generate a random one.
*
* @param string $instr The string to be salted and SHA1'd
* @param string $salt Some salt to sprinkle into the string to be SHA1'd so we don't
*                     get the same PW always hashing to the same value.
* @return string  SSHA  followed by a base64 encoded SHA1 of the salted string.
*/
function session_salted_sha1( $instr, $salt = "" )  
  if ( $salt == "" )  
    $salt = substr( base64_encode(sha1(rand(100000,9999999),true))), 2, 9);
   
  return ( sprintf(" SSHA %s", base64_encode(sha1($instr.$salt, true) . $salt)));
 

What about Secret Code Phrases? The problem with these secret code phrases, apart from all of the forgetability and guessability problems that have repeatedly been identified elsewhere, is that they are much less likely to be stored in a one-way hash. Are you going to ask your call-centre staff to type in the customer's secret code phrase? Didn't think so. And if you did it's going to add pronouncability issues to the whole mix. So this means that those organisations who have our secret code phrases in their database will, in all likelihood, have them stored directly as plain text, displaying them to the random call-centre staffer along with all of our other account details, and especially making them vulnerable to accidental disclosure. Disclosure of a sort that doesn't necessarily involve knowing they have been disclosed. Proliferation of Use These things provide the appearance of security - 'Security Theatre' as Bruce Schneier terms it - and because of that they're taken up in a kind of a cargo cult of security: "if the banks do it that way it must be a really good form of security". This makes the problem much worse, because now I have to remember a secret code phrases not only for banks, but for ISPs, phone companies, online auction websites, and so on. How many mother's maiden names, favourite teachers and friend's phone numbers do I have? I'm sure I'm at well up whatever curve it is that measures the number of passwords a person has, because five years ago I had so many I started to store them all in an encrypted database - protected by a yet another password, of course. Now in order to get my story straight I have to store my 'secret code phrases' in there too. If I didn't store my secret code phrases in that database, I'd obviously be re-using them everywhere, from a very small set - perhaps the same one that everyone around me overhears, every time I have to ring my bank to authorise another payment from my account. Because the proliferation of use is not just the breadth of wannabe thespians hoping to climb on the stage of this latest play, but the way they want to use it all the time, too. In fact the only conversation I've had recently with my bank where they didn't want it was when they rang me. Obviously I was the only person who could answer a phone in my house, right? It isn't just security theatre: I think we can see that this analogy belongs much deeper into the sub-genre of 'Security Farce'. Is there a solution? I don't have any easy answers - other than the ones to my security questions, of course - but some improvements are possible. Other banks have quizzed me about stuff like recent expenditure or credit card limits from time to time, but I've usually passed those tests by reading my last bank statement - or failed them by not having it to hand! I don't really think that the answers can lie in that direction because the information is only quite loosely tied to my identity. For some parts of the call-centre handling of secret code phrases there are changes that could make them more secure, but in the fairly short term these organisations need to find a different way to perform these out of band identity checks. For the actual storage of the code phrases it would be a marginal improvement if the database did not contain the actual phrase. Perhaps it could be encrypted with some application-known key, so that it can be unencrypted when it needs to be displayed, but never stored in the clear. Of course there's still the problem with that key... Verification of the secret code phrase could be done by someone not involved in the transaction, so that the call could be temporarily passed into a 'verification stream' where a different person performed the verification step without the context of the account details or enquiry. Though this sort of complexity seems unlikely with call centres seemingly being outsourced to the cheapest supplier. One thing does seem likely to become increasingly true: there is less and less private data in our lives, and every time we share one of these little nuggets with our bank, or our electricity company, or our on-line associates-we-call-friends, is one more chance that it escapes into the hands of the foaming-at-the-mouth-terrorist-cracker-communist-nazi-right-wing-religious-fruitcake hordes. The highest bar for personal verification which any of my banks currently sets for me is a random choice from a set of personally entered questions, with a set of personally entered answers, for which I have to enter two randomly selected characters using my mouse. That's not bad for safe verification, and I'd have to be really impressed with their security if that was stored in the database by a passphrase-protected encryption key. With that bank I don't know what they do over the phone - I assume they've concluded they can trust my logged on persona enough that I can do what I want online, consequently I haven't had to call them and share those secrets with everyone in earshot. Maybe paranoid freaks like me will go back to a chequebook and close down on-line access to their bank accounts entirely when they find themselves having to supply a skin scraping in order to authorise their next $500 payment. "Please insert your finger in the AccuYou(tm) BloodSucker(tm) to proceed with this payment" - well, I guess it might cut down my spending! In any case, biometrics need to be understood before they can be used effectively and appropriately - and remotely over the phone is probably not one of the ways that they can be trusted to work.

It s that time of the year again. Everything is changing, and maybe for the better. The days are getting shorter. When I left for work on my bicycle yesterday morning, it was still dark outside, and a little nippy. There s nothing quite like riding a bicycle down a deserted country road at night, a cool breeze at your back, and having the sun come up as you ride. And with the cooler weather, we can open our windows at night instead of running the air conditioner. It s also nice to have a pleasant cool breeze flowing through the house, and hear the frogs, crickets, owls, coyotes, and other wildlife at night. Out here, we certainly don t hear sounds of traffic, or loud car radios, though on a really clear night we might hear the rumble and whistle of a train from a few miles away. This is also sunflower season in Kansas. The wild sunflowers, when their smaller-than-most-people-think flowers, grow everywhere. Some ditches turn into a sea of person-height yellow. Sunflowers are on the sides of bridges, around people s mailboxes just about anywhere that isn t mowed or farmed. Then you also pass the sunflower fields, with their larger flowers, even more sea-like. The beans are getting tall in the fields this time of year, and it won t be long before the milo starts to turn its deep, dark reddish brown. But, you know, we re Kansans. We can t really let ourselves enjoy it all that much. Just today, I heard a conversation apparently the Farmer s Almanac is predicting a brutally frigid winter this year. Gotta keep our sense of pessimism about weather alive now

I met my friend Josef Daberning, who did his Austrian Social Service working with Drupal at the Casa de los Tres Mundos NGO, in Granada, Nicaragua, at the Central American Free Software Encounter, last May. He told me that, when going back to Austria, he would spend some days in Mexico, and wanted to give a workshop on Drupal. The course has just started, and will take place today and tomorrow You can follow the live stream at http://www.iiec.unam.mx:18000/drupal.ogg The videos will be uploaded soon as well, I will post them on this same node. This node will be used for whatever is needed to make public for people following the talk. As of right now, you can download his presentation http://gwolf.org/files/gira-drupal.odp and http://gwolf.org/files/gira-drupal.pdf [update](s):

• If you are following the stream and want to say something, connect via IRC to OFTC (irc.debian.org) and join the #edusol channel.
• The videos for the talks will be made available soon, licensed under CC-BY 3.0 (generic)
• If you want to come, you are more than welcome. There is still space! We are in Ciudad Universitaria, South of Mexico City. Instituto de Investigaciones Econ micas - UNAM. We are starting the second session (16:00-10:00), tomorrow we have a third and final session (10:00-14:00).
• Of course,it is all over by now. I will be processing the videos and uploading them to Archive.org's Open Source Movies archive. The first video is already available, the rest will follow soon.

Attachment	Size
Basic introduction to Drupal presentation (ODP format)	306.07 KB
Basic introduction to Drupal presentation (PDF format)	214.62 KB
Drupal themes presentation	1.09 MB

The Washington Monthly has an interesting article about healthcare and Free Software [1]. It seems that a free system named VistA from the US Veterans Affairs department (not to be confused with the unpopular OS Vista that Microsoft released a few years ago) is competing against a range of proprietary software for managing patient data. VistA has apparently performed very well, it s cheap and easy to install, the data can be shared with other programs, and it was largely written by doctors and nurses so it s optimised to their needs. It has been proven that VistA has saved many lives through better management of medicines and through permitting statistical analysis of the results of various treatments. It has also allowed medical staff to work more quickly which reduces waiting times and medical expenses. But as you would expect in the US, whenever there is a way of saving lives while also saving money there are companies lobbying for the opportunity to make money while allowing innocent people to die. Of course there are established medical companies who are doing this now and have been doing so for some time. But the latest news is that Microsoft, Intel, Cisco, and Allscripts, are sponsoring the Electronic Health Record Stimulus Tour an aggressive measure to railroad doctors into buying proprietary software now. MS is known for totally ignoring the law when it gives them an opportunity to gain market share, but this is a new low. What will MS do next? Sell drugs to children?

• [1] http://www.washingtonmonthly.com/features/2009/0907.longman.html

Once in a while I get this urge to use SELinux on some of the servers I manage, but almost always run in to something that puts me back enough to never finish the project. This time I managed to figure out the last few glitches. In the end, SELinux still has a really steep learning curve, so it's not for the impatient ones. Even though enabling SELinux in Debian has become a lot easier since the first time I tried to get things running, it's still just the tip of the iceberg. In Debian it is just a matter of installing the right packages and running a few commands, but that's just where the troubles start. Most of the howtos focus on single user or shared installations where all users are created locally. Also most howtos fail to mention that you need to relabel files in certain cases. One of the most annoying problem I ran in to was changing all non-system users away from the unconfined_u class. This is of course done like this (found here):

semanage -m -s user_u __default__

The problem here is that it changes the existing user as well and you start to get errors like these:

denied    read   for  pid=32258 comm="bash" name=".profile" dev=dm-5 ino=185474 scontext=user_u:user_r:user_t:s0 tcontext=unconfined_u:object_r:unconfined_home_t:s0 tclass=file

The problem here is that the home directory for the user is still labeled for the wrong class. The fix is to relabel the home. Sadly this is something that you just need to know, it's not explained anywhere. At least I haven't found an explanation anywhere. Another good thing to do before you continue is to change the already existing user to the staff class. Staff class has a bit more relaxed security controls and you get to change the security roles (details here).

semanage login -m -s staff_u myuser
fixfiles relabel /home/myuser

This gets you a semi working setup, next problem usually is that some daemons are denied access to parts of your system. For me, this was postfix trying to access my home directory that was mounted over NFS. For such cases, you should persuade the maker of the module package to update the global policy if it's a common use case. Or you need to create a policy package that allows access to the given files. The process itself is documented in the audit2access manual page. In general you should study the audit2why and audit2allow packages. The former tells you if there is an easier way to fix something (like enable a boolean) and latter will create the required policy lines. Only problem is to compile the policy and load it. The only problem here was to find the right tool and the right lines from the manual. In general the SELinux learning curve is way too steep. It's a system that works pretty well once you learn all the tricks and start to completely understand the toolset. The community should continue working on lowering the bar for new users. There has been some major improvements since I first tried SELinux, so it's the right direction.

While git is a completely distributed revision control system, sometimes the lack of a central canonical repository can be annoying. For example, you might want to make your repository published publically, so other people can fork your code, or you might want all your developers to push into (or have code pulled into) a central "golden" tree, that you then use for automated building and continuous integration. This entry should explain how to get this all working on Ubuntu 9.04 (Jaunty). Gitosis is a very useful git repository manager, which adds support like ACLs in pre-commits and gitweb and git-daemon management. While it's possible to set all these things up by hand, gitosis does everything for you. It is nicely configured via git; to make configuration changes, you push the config file changes into gitosis repository on the server. Gitosis is available in Jaunty, but unfortunately there is a bug in the version in Jaunty, which means it doesn't work out of the box. Fortunately there is a fixed version in jaunty-proposed that fixes the main problem. This does mean that you need to add the following to your sources.list:

deb http://gb.archive.ubuntu.com/ubuntu/ jaunty-proposed universe

Run apt-get update && apt-get install gitosis. You should install 0.2+20080825-2ubuntu0.1 or later. There is another small bug in the current version too, as a result of git removing the git-$command scripts out of /usr/bin. Edit /usr/share/python-support/gitosis/gitosis/templates/admin/hooks/post-update and replace

git-update-server-info

with

git update-server-info

With these changes in place, we can now set up our gitosis repository. On the server you are going to use to host your central repositories, run:

sudo -H -u gitosis gitosis-init < id_rsa.pub

The id_rsa.pub file is a public ssh key. As I mentioned, gitosis is managed over git, so you need an initial user to clone and then push changes back into the gitosis repo, so make sure this key belongs to a keypair you have available to the remote user you're going to configure gitosis. Now, on your local computer, you can clone the gitosis-admin repo using:

git clone gitosis@gitserver.example.com:gitosis-admin.git

If you look inside the gitosis-admin directory, you should find a file called gitosis.conf and a directory called keydir. The directory is where you can add ssh public keys for your users. The file is the configuration file for gitosis.

[gitosis]
loglevel = INFO
[group gitosis-admin]
writable = gitosis-admin
members = david@david
[group developers]
members = david@david
writable = publicproject privateproject
[group contributors]
members = george@wilber
writable = publicproject
[repo publicproject]
daemon = yes
gitweb = yes
[repo privateproject]
daemon = no
gitweb = no

This sets up two repositories, called publicproject and privateproject. It enables the public project to be available via the git protocol and in gitweb if you have that installed. We also create two groups, developers and contributors. David has access to both projects, but George only has access to change the publicproject. David can also modify the gitosis configuration. The users are the names of ssh keys (the last part of the line in id_dsa.pub or id_rsa.pub). Once you've changed this file, you can run git add gitosis.conf to add it to the commit, git commit -m "update gitosis configuration to commit it to your local repository, and finally git push to push your commits back up into the central repository. Gitosis should now update the configuration on the server to match the config file. One last thing to do is to enable git-daemon, so people can anonymously clone your projects. Create /etc/event.d/git-daemon with the following contents:

start on startup
stop on shutdown
exec /usr/bin/git daemon \
   --user=gitosis --group=gitosis \
   --user-path=public-git \
   --verbose \
   --syslog \
   --reuseaddr \
   --base-path=/srv/gitosis/repositories/ 
respawn

You can now start this using start git-daemon So now, you need to start using your repository. You can either start with an existing project or an empty directory. Start by running git init and then git add $file to add each of the files you want in your project, and finally git commit to commit them to your local repository. The final task is to add a remote repository and push your code into it.

git remote add origin gitosis@gitserver.example.com:privateproject.git
git push origin master:refs/heads/master

In future, you should be able to do git push to push your changes back into the central repository. You can also clone a project using git or ssh, providing you have access, using the following commands. The first is for read-write access over ssh and the second uses the git protocol for read-only access. The git protocol uses TCP port 9418, so make sure that's available externally, if you want the world to be able to clone your repos.

git clone gitosis@gitserver.example.com:publicproject.git
git clone git://gitserver.example.com/publicproject.git

Setting up GitWeb is left as an exercise for the reader (and myself because I am yet to attempt to set that up).

Listening to Martin Krafft s talk at Debconf (related to his PhD) shed some new light on the idea that I expressed last year I wanted that each maintainer regularly answers a questionnaire so that he has to ask himself whether he does a good enough job with his packages. When thinking of this idea, I only saw the QA side of ensuring good maintenance on all packages, however I believe that the root problem lies further and this project would not be enough: we are interdependent but we are not equipped to deal with this reality. Martin s only merit has been to mention that we are interdependent, but it s worth analyzing a bit. Our organization is centered around individuals acting as package maintainers, and in theory each package maintainer can work on his corner and all goes well. We know that this model doesn t hold any more: transitions to testing require coordination of uploads and timely fixes of RC bugs, keeping up with the work frequently requires several volunteers that have to coordinate, etc. More and more of the work requires a level of availability that a single individual can t offer, yet in our day-to-day work we mainly interact with individuals. Wouldn t it be better if we could immediately know what we can expect from any Debian developer:

• mean time to reply to Debian mail (reading every day or once a week is not the same);
• amount/periods of time spent on Debian (knowing that they spend up to 4 hours mainly on Saturday can be useful);
• current availability for Debian (if they are currently busy with life, we should be able to know it, if they know when it will end, it would also be good to share);
• best way to get in touch for issues (they might have preference between IRC or mail);
• kind of relationship they have with packages where they are listed in Maintainer/Uploaders (an active maintainer that uses the software daily is not the same than a passive maintainer that only packaged the software because it was a build-dependency for some other software that they care about);
• any other information that the maintainer wants to share (about his habits/constraints/values/goals/whatever).

All this information should be shared by all Debian maintainers (some of it is already available but either not publicly or not in any machine-parseable way) and we should actively use it. Here are some examples of use: for each RC bug report, you could look up if at least one maintainer is available and you could ping him explicitly if needed. When you plan an NMU, you could look up if the maintainer is likely to respond in the next day or not, and possibly adjust the number of days spent in the DELAYED queue. When organizing a large-scale transition, you could extract a list of packages whose maintainers are not available and arrange immediate NMUs. Furthermore there are many cases where the project s usual expectation exceed what the maintainer is ready to do. Documenting what part of the job is done (or not) by the maintainer makes it clear for volunteers whether their help is needed and whether they could/would be a better maintainer for a given package. Designing solutions to all these problems is going to be the scope of the DEP2 that I reserved some time ago. It s likely to be some sort of dedicated web interface. I would welcome supplementary drivers for this DEP, so if you re interested, get in touch with me. Partagez cet article / Share This

While git is a completely distributed revision control system, sometimes the lack of a central canonical repository can be annoying. For example, you might want to make your repository published publically, so other people can fork your code, or you might want all your developers to push into (or have code pulled into) a central "golden" tree, that you then use for automated building and continuous integration. This entry should explain how to get this all working on Ubuntu 9.04 (Jaunty). Gitosis is a very useful git repository manager, which adds support like ACLs in pre-commits and gitweb and git-daemon management. While it's possible to set all these things up by hand, gitosis does everything for you. It is nicely configured via git; to make configuration changes, you push the config file changes into gitosis repository on the server. Gitosis is available in Jaunty, but unfortunately there is a bug in the version in Jaunty, which means it doesn't work out of the box. Fortunately there is a fixed version in jaunty-proposed that fixes the main problem. This does mean that you need to add the following to your sources.list:

deb http://gb.archive.ubuntu.com/ubuntu/ jaunty-proposed universe

Run apt-get update && apt-get install gitosis. You should install 0.2+20080825-2ubuntu0.1 or later. There is another small bug in the current version too, as a result of git removing the git-$command scripts out of /usr/bin. Edit /usr/share/python-support/gitosis/gitosis/templates/admin/hooks/post-update and replace

git-update-server-info

with

git update-server-info

With these changes in place, we can now set up our gitosis repository. On the server you are going to use to host your central repositories, run:

sudo -H -u gitosis gitosis-init < id_rsa.pub

The id_rsa.pub file is a public ssh key. As I mentioned, gitosis is managed over git, so you need an initial user to clone and then push changes back into the gitosis repo, so make sure this key belongs to a keypair you have available to the remote user you're going to configure gitosis. Now, on your local computer, you can clone the gitosis-admin repo using:

git clone gitosis@gitserver.example.com:gitosis-admin.git

If you look inside the gitosis-admin directory, you should find a file called gitosis.conf and a directory called keydir. The directory is where you can add ssh public keys for your users. The file is the configuration file for gitosis.

[gitosis]
loglevel = INFO
[group gitosis-admin]
writable = gitosis-admin
members = david@david
[group developers]
members = david@david
writable = publicproject privateproject
[group contributors]
members = george@wilber
writable = publicproject
[repo publicproject]
daemon = yes
gitweb = yes
[repo privateproject]
daemon = no
gitweb = no

This sets up two repositories, called publicproject and privateproject. It enables the public project to be available via the git protocol and in gitweb if you have that installed. We also create two groups, developers and contributors. David has access to both projects, but George only has access to change the publicproject. David can also modify the gitosis configuration. The users are the names of ssh keys (the last part of the line in id_dsa.pub or id_rsa.pub). Once you've changed this file, you can run git add gitosis.conf to add it to the commit, git commit -m "update gitosis configuration to commit it to your local repository, and finally git push to push your commits back up into the central repository. Gitosis should now update the configuration on the server to match the config file. One last thing to do is to enable git-daemon, so people can anonymously clone your projects. Create /etc/event.d/git-daemon with the following contents:

start on startup
stop on shutdown
exec /usr/bin/git daemon \
   --user=gitosis --group=gitosis \
   --user-path=public-git \
   --verbose \
   --syslog \
   --reuseaddr \
   --base-path=/srv/gitosis/repositories/ 
respawn

You can now start this using start git-daemon So now, you need to start using your repository. You can either start with an existing project or an empty directory. Start by running git init and then git add $file to add each of the files you want in your project, and finally git commit to commit them to your local repository. The final task is to add a remote repository and push your code into it.

git remote add origin gitosis@gitserver.example.com:privateproject.git
git push origin master:refs/heads/master

In future, you should be able to do git push to push your changes back into the central repository. You can also clone a project using git or ssh, providing you have access, using the following commands. The first is for read-write access over ssh and the second uses the git protocol for read-only access. The git protocol uses TCP port 9418, so make sure that's available externally, if you want the world to be able to clone your repos.

git clone gitosis@gitserver.example.com:publicproject.git
git clone git://gitserver.example.com/publicproject.git

Setting up GitWeb is left as an exercise for the reader (and myself because I am yet to attempt to set that up).

To the person driving the black Acura SUV with the vanity plate ZEPHNET south on I-5 Saturday: HELLO. I COMPLETELY APPROVE OF YOUR LIFESTYLE CHOICES. PLEASE MAKE USE OF THE DWIGHT D. EISENHOWER NATIONAL SYSTEM OF INTERSTATE AND DEFENSE HIGHWAYS IN ANY MANNER YOU SEE FIT. IT IS YOUR RIGHT AS A PAYING TAXPAYER AND NO ONE SHOULD STIFLE YOUR CREATIVITY IN SUCH ENVIRONS.

I would like to point out that my last article was in no way meant to be critical towards libvirt, rather on the contrary. I think it's an awesome technology the way it provides a common management platform for various virtualization solutions available on Linux and even other platforms.

For reference, expensive proprietary virtualization solutions don't necessarily fair better.
I've in fact recently ran into a problem in a Vmware ESX / Virtual Center environment which, while rather different in manifestation, in the end was similar in nature: diverging state change in the environment and in configuration.

The Vmware problem surfaced after kernel changes on Linux guests, where, after rebooting into the new kernel and running the vmware-config-
tools script to rebuild the modules, nightly backups with help of the vcbmount utility would fail.
The only cryptic error message was:

Creating a quiesced snapshot failed because the (user-supplied) custom pre-freeze script in the virtual machine exited with a non-zero return code.


It didn't help that there wasn't any "user-supplied pre-freeze script" to begin with.

Searching for this error message returned lots of hits, several going at least one year back. However, aside from a few references to a documented Solaris guest issue, which was not applicable, none would actually provide any insight into what the problem might actually be. Unt
il I found following post on the Vmware communities site, which pointed out that
changes to the uuid.location weren't propagated properly to the vmx definition.

For the time being, the best way to work around this (in Linux guests) is to add another reboot right after rebuilding the vmtools modules.
Since you should be rebuilding
But Vmware should provide a proper fix their stuff, really. I've got this strong feeling that the libvirt bug will be resolved in less time than a year...

Made some time to hack... the results: config-manager 0.4 released, re-uploaded to debian (it was removed due to some confusion a while back). This most notably drops the hard dependency on pybaz and adds specific-revision support for bzr. subunit snapshot packaging sorted out to work better with subunit from Ubuntu/Debian. This latest snapshot has nested progress and subunit2gtk included. PQM got a bit of a cleanup:

The status region shown during merges is ~ twice as tall now.

if the precommit_hook outputs subunit it will be picked up automatically and shown in the status region.

all deprecation warnings in python2.6 are cleaned up

Pending bugfixes were merged from Tim Cole and Daniel Watkins - thanks guys!

Belkinsauce is plotting against me, hiding my items and mismanaging his soundfont. Such is his wont.

Voice-controlled waypoints I have it in my TODO list to implement taking waypoints when pressing the headset button of the openmoko, but that is not done yet. In the meantime, I did some experiments with audio mapping, and since I did not manage to enter waypoints while recording them, I was looking for a way to make use of them anyway. Enter findvoice:

$ ./findvoice  --help
Usage: findvoice [options] wavfile
Find the times in the wav file when there is clear voice among the noise
Options:
  --version             show program's version number and exit
  -h, --help            show this help message and exit
  -v, --verbose         verbose mode
  -p NUM, --percentile=NUM
            percentile to use to discriminate noise from voice
            (default: 90)
  -t, --timestamps      print timestamps instead of human readable information

You give it a wav file, and it will output a list of timestamps corresponding to where it things that you were talking clearly and near the FreeRunner / voice recorder instead of leaving the recorder dangling to pick up background noise. It does not use sound statistics because I have no background whatsoever in audio processing, but it basically finds those parts of the audio file where the variance of the samples is above a given percentile: the higher the percentile, the less timestamps you get; the lower the percentile, the more likely it is that it picks a period of louder noise. For example, you can automatically extract waypoints out of an audio file by using it together with gpxinterpolate:

./findvoice -t today.wav   ./gpxinterpolate today.gpx > today-waypoints.gpx

On the timestamps that it outputs, it will add the modification time of the .wav. This means that if you touch -d "@timestamp" the .wav file with the date you started recording, then you can get decently accurate waypoints provided your system clock is decently synchronized. For example:

START= date +%s 
arecord file.wav
^C
touch -d "@$START" file.wav
./findvoice -t file.wav   ./gpxinterpolate today.gpx > today-waypoints.gpx

In record-audio-on-freerunner I even set the .wav mtime using the GPS time at the start of the recording.

Specific guarantees in the Bill of Rights have penumbras, formed by emanations from those guarantees that help give them life and substance. SC justices can be so poetic.

I've always prided myself in the fact that I didn't have any fillings. That's about to change, sadly. One of the teeth at the back, top right of my mouth has a deep valley, which makes it hard to get at with a toothbrush, and there's a small cavity at the bottom of that. Dentist trips for me have always just involved the cleaning and scaling and an exam. Aside from having my wisdom teeth out (which I had done under general anaesthesia) I've never had a dental procedure before. Eeek.

Since this afternoon, bts-link is able to interact with Google Code issue tracker.

So, if you're upstream code & bugs are maintainer there and what to keep them monitored, just drop us an email to the devel mailing list (see link above).

You can also write us if your tool uses another upstream issue tracking still not managed by bts-link and we will see what we can do.

Soon before leaving NYC for the summer, Sumana invited me to see a monologue on facebook by Mike Daisy. It was a good show and he has since provided an mp3 of it. There are some classic moments in there, especially toward the middle of the audio. I am looking for am mp3 of his Great Men of Genius where he addresses Mr Hubbard among others (I find stuff on it
but not it). Anyone have it or pointers to where it might be?

Soon before leaving NYC for the summer, Sumana invited me to see a monologue on facebook by Mike Daisy. It was a good show and he has since provided an mp3 of it. There are some classic moments in there, especially toward the middle of the audio. I am looking for am mp3 of his Great Men of Genius where he addresses Mr Hubbard among others (I find stuff on it
but not it). Anyone have it or pointers to where it might be?

In the spirit of Thomas Limoncelli's Time Management for System Administrators, this is my checklist for setting up a new Debian system. I have added a few notes to the original list to justify their existence and to provide some background information. Whilst you should avoid performing repetitive interactive configuration and defer to the multitude of tools designed for this task, constructing and sharing a checklist can still be an instructive step. It can also be useful in situations where a machine has already been partly configured for you.

So, the latest buzz on the web is all about Google Wave. I would urge everyone developing stuff for the Internet and technological people depending on the Internet for their daily work, to watch that introductory video. The concept is frankly mind-blowing. If this is done right and embraced by all the right people, Google Wave could be the new platform concept that could be used to create new generation of email, instant messaging, collaboration software (CMS, wiki, Sharepoint, workflow, ), blogging software and forum software and do all that while integrating back with current technologies, like Twitter and RSS feeds. It remains to be seen what parts will be open source and federated and what parts will remain Google-only services. For example, I am convinced that Spelly the spellchecker bot and Rozy the automatic translation bot will be hard to impossible to federate. This being Google, it is practically a given that the code will be good, but a bit hard to understand and contribute to. Management of the free software community and proprietary community relations will likely be the key to the success of this technology. I love the technology itself - imagine that you have a web blog. The blog software makes each your blog post a wave. When people leave comments on the post, these comments show up in your email inbox. You can reply to people right from there. By default your replies will show up on your blog and also show up in the email inboxes of the commenter, but you also have the option to mark your reply private and only send it to the commenter. Also it looks to be possible to choose to host all the data yourself or to make Google host all your blog and comment data and make your blog just be a frame where this data is displayed in, possibly allowing you to use very, very minimal system resources to maintain the blog even in a case of Slashdotting. I hate blogs without comments, let s replace them all. I would also love to see replacements to Microsoft Exchange and Microsoft Sharepoint be built using Wave technology with a full support to ODF if possible. Imagine collaborative document editing in OpenOffice using this technology in the backend. It would be one huge project, but it should be possible. Companies currently pay hundreds of thousands of dollars to set up MS Exchange+Sharepoint+Active Directory to be able to simply share documents in their Intranet and see who edited a document (no live editing, no change tracking). It is possible to make a much better product with ODF and Google Wave and it is possible to earn a bunch of money supporting such a product for companies that need support contracts. If it would be possible to licence spellchecking and translation services from Google in a way where a box is installed in customers data centre and the data to be spellchecked and translated never leaves that data centre, then I believe that people would be willing to pay for this superior spellchecking and translation experience. We need open source products that people can depend on. We also need ways for business people to sell services with an easily visible added value so that they can make money and contribute their developer work hours back to the open source projects. We (the free software community) have great ways to get a positive feedback loop with users that can develop software, but when our users have no interest in developing anything, the feedback loop breaks and free software growth slows down. There is a lot of untapped potential in this area - we just need to find a way to convert needs and demands of non-developers into code. I m gonna stop this rant before it diverges even further off topic, but the main point is - go watch the Google Wave demo, read the tech specs and think how you could integrate that into your free software project. Useful wave discussions (will update as I find more):

• About Wave from the TG2 guy
• SMB CRM on Wave (ideas)
• A Twitter feed with more useful links