Julien Danjou: OpenStack meets Lisp: cl-openstack-client
A month ago, a mail hit the OpenStack mailing list
entitled "The OpenStack Community Welcomes Developers in All Programming
Languages".
You may know that OpenStack is essentially built using Python, and therefore
it is the reference language for the client libraries implementations.
As a Lisp and OpenStack practitioner, I used this excuse to build a
challenge for myself: let's prove this point by bringing Lisp into
OpenStack!
- Download quicklisp.lisp
- Run a Lisp program to install the dependencies using Quicklisp
- Run a Lisp program running the test suite using FiveAM, that exit with 0 or 1 based on the tests results.
* (require 'cl-openstack-client)
* (use-package 'cl-keystone-client)
* (defvar k (make-instance 'connection-v2 :username "demo" :password "somepassword" :tenant-name "demo" :url "http://devstack:5000"))
K
* (authenticate k)
((:ISSUED--AT . "2013-07-04T05:59:55.454226")
(:EXPIRES . "2013-07-05T05:59:55Z")
(:ID
. "wNFQwNzo1OTo1NS40NTQyMthisisaverylongtokenwNFQwNzo1OTo1NS40NTQyM")
(:TENANT (:DESCRIPTION) (:ENABLED . T)
(:ID . "1774fd545df4400380eb2b4f4985b3be") (:NAME . "demo")))
* (connection-token-id k)
"wNFQwNzo1OTo1NS40NTQyMthisisaverylongtokenwNFQwNzo1OTo1NS40NTQyM"
Unfortunately, the implementation is far from being complete. It only implements for now the Keystone token retrieval. I've actually started this project to build an already working starting point. With this, future potential contributors will be able to spend efforts on writing code, and not on setting up the basic continuous integration system or module infrastructure. If you wish to help me and contribute, just follow the OpenStack Gerrit workflow howto or feel free to come by me and ask any question (I'm hanging out on #lisp on Freenode too). See you soon, hopping to bring more Lisp into OpenStack!
Okay, so imagine this: you just generated an SSH RSA key and threw its public part on system B into ~foo/.ssh/authorized_keys and its private part on system A into ~bar/.ssh/id_rsa but can t login. Why?
Automated processes (Jenkins *cough*) often need you to ssh(1) manually once, to accept the remote host s server key. Do that.
The id_rsa file on system A must be owned by the user bar and chmod 0600 or 0400 (similarily, the .ssh directory has strict permission checks, and everything in the path until there). Check those.
And, the most surprising one of the day: if there s an id_rsa.pub it will be used for offering a key to the remote host (B) even if it does not match the secret key. Deleting A:~bar/.ssh/id_rsa.pub apparently makes OpenSSH generate the public part from the secret key each time (or just put the correct pubkey there), but if one s there, it seems to like to use them. (That was the only part of this post that was news to even me, of course )
And, as bottom line: hello to Planet Debian from mirabilos at work , too. I ll occasionally tag posts so they show up here, if I think they re of interest, since I m doing Debian work at the dayjob, too.
Recent Intel-based systems often implement something called Intel Rapid Start Technology. Like many things with the word "Technology" in the name, there's a large part of this that's marketing. The relatively small amount of 
A backup run takes time. During a backup run the live data may
change. This can mean that the snapshot of the live data may
not be internally consistent.
For example, suppose you're writing an e-mail when the backup
starts automatically. If the timing goes wrong in exactly the
right way, the backup might capture both the draft e-mail you
were writing when the backup started, and the sent e-mail, when
you finished the draft and sent the mail before the backup
ended.
Or, worse, the backup might miss both the draft and the sent
e-mail. The next backup run will, certainly, get the sent e-mail,
but what if you have a disaster before that happens?
Internal consistency of data can be quite difficult to achive.
Some programs, such as MySQL, don't do a good job of keeping the
data consistent on-disk, making it difficult for the backup program
to get a proper setup. (In that case, a standard trick is to
"dump" or "export" the data in a consistent form, and back that up
instead.)
In an ideal situation, when the backup starts, the system would have
a way to tell all running programs to store all their state on disk in
a recoverable manner (save all open documents, dump data base content,
etc), and once that is done, the backup program creates a snapshot of
the filesystem. Unfortunately, I don't know of any operating system that
can request consistent state from running applications.
Snapshotting, however, is easy-peasy. It can be achieved by the filesystem
(e.g., btrfs), or using LVM. Doing the snapshots requires root privileges,
but that can probably be arranged. However, snapshotting like this,
without getting all programs to commit their state to disk first, is not
a guarantee of consistency.
A thorough way to be consistent is to shut down the computer, and then
reboot it into a special backup mode (similar to single-user mode),
where no services or applications are running. However, this is, for
most people, much too heavyweight a procedure to be worth it.
Does consistency really matter? It matters a lot when the live data
is being changed actively and consistency of the data is critical. For
example, a bank's database of the amount of money in each account is quite
critical: if data is not backed up consistently, money can be lost or
created spontaneously, and that's probably a bad thing.
Most people, however, don't need to worry a lot, and merely need to
be aware of the issue, and perhaps mitigate it by backing up when the
computer is mostly idle, and run backups often enough.
Oh dear. This blog post contains too few jokes. I seem to have run
out of jokes to make, so that will conclude this series of blog posts.
I hope it was useful to some.
So I have a new desktop computer. I installed Wheezy on it via a USB stick, and everything worked. All the hardware. Yay. I guess we take it for granted when things like sound, disks, and network cards just work these days. I remmeber fighting with distros in the past, where such things were not necessarily straightforward.
The only minor complication is the graphics card. I bought a cheap/random GeForce card for the new machine ( 30):
A few months ago, I was looking for a piece of software to spawn
long-running tasks on behalf of some daemon with the benefit of
the tasks not being interrupted when this daemon is restarted. Here
are the specifications:
