Moving forward

Due to an outage of our old server yesterday, we’ve been forced to switch monotone’s main site, wiki, documentation and the remaining infrastructure earlier than expected to the new server. While not every automatism is in place for the new server, we think that it is actually already usable and decided to not switch back to the old one.

This has one important implication though: The monotone instance running on the new server does no longer allow connections without a path, i.e. pulling like this

$ mtn pull ‘montone.ca’ ‘net.venge.monotone’

will fail. Instead, you have to use a slightly changed URI syntax for monotone clients up to 0.48:

$ mtn pull ‘mtn://monotone.ca/monotone’ \
‘net.venge.monotone’

or, if `mtn` is not in your `/etc/services` and you cannot add

mtn 4691/tcp # Monotone Network Protocol
mtn 4691/udp # Monotone Network Protocol

to it either, use

$ mtn pull ‘monotone://monotone.ca/monotone’ \
‘net.venge.monotone’

because there are a couple of URI parsing bugs in this version which prevent an action with the standard URI syntax unfortunately.

If you don’t want to go through this hassle, you’re also free to push / pull just from the now back-to-life old server:

$ mtn pull ‘old.monotone.ca’ ‘net.venge.monotone’

The **leading server** is however the new one and since both aren’t yet synchronized, it might take a little longer until we see changes which are only pushed to the old one.

Please also note that the new monotone instance separates projects from each other, so if you don’t find a branch at the monotone instance, you might want to try a different one. A list of projects and all of their served branches is available via code.monotone.ca: select a project and click the “Source” tab, you’ll see the branches then listed on the left.

If you are a monotone committer, ensure that you also **do not push unrelated branches** into project databases which do not belong there. (It has proven to be helpful to use different local databases for different projects…) We have no way of enforcing that on the server level as of now, but are working on a solution.

Thanks for reading!

Server keys of the code forge changed

If you previously pulled from code.monotone.ca, you’ll probably get a SERVER IDENTIFICATION warning the next time you sync with it. The problem was that I issued keys with wrong key names previously (which pointed to the temporary DNS) and I had to drop and re-add new keys with the proper DNS name.

Please execute therefor

$ mtn unset known-servers mtn://code.monotone.ca/

e.g. for the monotone project

$ mtn unset known-servers mtn://code.monotone.ca/monotone

on the particular local databases and you’ll be able to pull / sync again.

Sorry for the inconvenience.

50 for 1

Its official. I’m becoming a vegetarian. Since three or so weeks I have lowered my meat consumption to almost zero now. It was easier than I first anticipated. Being a “carnivore” for more than two decades makes you know every possible taste of meat and sausage, so I actually don’t miss anything. My family is – of course – not with me. Especially not my wife, but hey, we have different opinions on almost everything anyways. (Sometimes I think this is the reason why “it works”, we have both quite strong egos.)

Why I’m suddenly becoming a vegetarian, you ask? Three important points to note here:

1. *Money:* Meat will get way more expensive in the mid- to long-term, since the demand from Asia will raise rapidly in the next years as people gather more welfare. On the opposite, we – the “developed world” – will have to reduce our excessive meat consumption sooner or later, simply because we can no longer afford it. I’m just starting a little earlier.
2. *Ecology:* To produce one kilogram meat you need about 50 kilogram of corn. Think about this number for a second. Again, the demand for corn raises rapidly especially in Asia and so do the prices, additionally fired by speculants. At the same time the places where crop can be cultivated shrink, more and more forests have to be cleared. I will simply get sufficiently harder to feed eight billion people by the year 2025, especially if more and more of them become carnivores.
3. *Health:* I’m simply too fat, I cost myself, my family and my environment too much money, now and even more in the future. By reducing the animal fat, I hope to do something good for myself as well (though I know I won’t loose much without changing other parts in my life as well).

There might be more for other people, for example animal rights, hunger in the third world, but the above ones are the most honest for me. (How much have you spent to organizations like “Bread for the World” recently?)

I strongly believe that everbody can change something, in his own life, his direct surrounding and even beyond. You _just_ have to start it. And you know what? It feels right and good.

Monotone's new project forge officially online

I’m proud to announce that we’re almost done with one big entry in our TODO list for the ongoing server migration: Our indefero forge instance, a web-based project management software, is now set up and online under code.monotone.ca!

The forge contains several monotone-related projects, each with their own bug tracker, wiki, code browser and review module. Here is monotone’s one, and here the one for guitone. We’re planning to add more projects as the need arises and people demand them.

Each of the current and future setups also includes automatic access management for the underlying monotone repository which is served over usher – our proxy. Repositories can simply be accessed by their project name – so if you want to pull from the monotone repository, just trigger

$ mtn pull ‘mtn://code.monotone.ca/monotone?*’

Please note that with the advent of indefero, the main bug tracker of the monotone project is no longer Savannah, but Indefero. All the of the existing open bugs have been imported into monotone’s indefero project, so Savannah’s bug tracker should no longer be used (we’ll leave it online for reference for a little longer, though).

So I said “almost done” – whats missing? A few things actually:

* automatic mirroring of selected repositories with the designated mirrors
* push notifications for IRC / mailing list updates
* a better visual integration into the rest of our setups

While the first two things are on Richard’s TODO list, the last one is on my own schedule, though I want to wait a little longer until indefero’s redesign is through (expected sometime this fall).

And finally, the indefero monotone plugin needed a couple of extensions to core monotone, which I’ll likely blog later about, so stay tuned. If you’re interested in hosting your own monotone-related project on our forge, just drop me a note.

Thanks for reading.

Qt with Cocoa

If you build your Qt app on Mac OS X the first time with the Cocoa version of Qt and you receive weird UI lockups / freezes while your CPU and memory is eaten step by step, ensure you replaced any existing

QMAKE_MACOSX_DEPLOYMENT_TARGET = 10.4
QMAKE_MAC_SDK = /Developer/SDKs/MacOSX10.4u.sdk

with

QMAKE_MACOSX_DEPLOYMENT_TARGET = 10.5
QMAKE_MAC_SDK = /Developer/SDKs/MacOSX10.5.sdk

in your project file, because on Mac OS X 10.4 Qt Cocoa is officially unsupported. So if you need OSX 10.4 compatibility, stick with the Carbon version of Qt (4.7 will be the last version which comes with that), otherwise raise the bar to 10.5 or later and use the Cocoa build.

Ich schäme mich

Der 58-jährige Slawik C. – ein Aserbaidschaner, der in seinem Heimatland zur verfolgten armenischen Minderheit gehört – stirbt in deutscher Abschiebehaft nach 11 Jahren “Duldung” durch deutsche Behörden und vorbildlicher Integration in sein Wohnumfeld.

Ich schäme mich – für das Land, in dem ich wohne und in dem ich ein Bürger bin, seit gestern noch mehr als zuvor.

(Quelle, HAZ-Artikel)

Dies ist für mich ein weiterer Grund, warum ich meine Zukunft auf Dauer nicht mehr in diesem Land sehe.

ACLs on a jailed ZFS volume with FreeBSD

While setting up a couple of things on the new monotone server, which is bascially a FreeBSD jail on a physical server kindly provided by Lapo Luchini, I stumbled upon a quite basic use case: I needed to give one user group read and write access to files created and modified by another group.

On a Linux system I’d have simply enabled POSIX ACLs for the volume and call

$ setfacl -m d:user:foo:rwx /path/to/directory
$ setfacl -m d:user:bar:rwx /path/to/directory

and voila, all new files and directories underknees the path would have received the default ACLs with read and write rights for the `foo` and `bar` user.

It turns out that on FreeBSD, which gained zfs ACL support in its 8.1 release recently, the call is quite similar – just that `NFSv4` ACLs are used instead of `POSIX` ACLs, which are a bit more powerful (read more on the topic here):

$ setfacl -m user:foo:rwxp:fd:allow /path/to/directory
$ setfacl -m user:bar:rwxp:fd:allow /path/to/directory

Instead of `d:` for `default` which is used in the `POSIX` version, `fd` is used, which stands for `file_inherit` and `directory_inherit` and is exactly what we need. And while `POSIX` ACLs are add-only, you can either specify `:allow` or `:deny` to also explicitely deny access to a user or usergroup. Finally, you might have seen the little `p` which stands for the `append_data` right. This was needed for me in one case, so I added it here. It is actually one of many more rights beside the well-known `rwx` that `NFSv4` ACLs defines here – if you’re curious, just read more on the aforementioned link.

“So if everything works, what is the point of this blog?” you might ask. Well, unfortunately it did not all work out so nicely. One thing caused me some headaches which is actually dubbed a feature of FreeBSDs NFSv4 ACL implementation – namely that the `umask` (the create mask for new files) is taken into account on file creation, which leads to an unwanted recalculation of the default (inherited) ACLs. So if you have a file foo created by user `u1` and the ACLs should also give write access to user `u2`, then you might end up with something like this:

$ getfacl foo
   # file: foo
   # owner: u1
   # group: users
              user:u1:--x-----------:------:deny
              user:u1:rwxp----------:------:allow
              user:u2:rwxp----------:------:deny
              user:u2:rwxp----------:------:allow
               owner@:--x-----------:------:deny
               owner@:rw-p---A-W-Co-:------:allow
               group@:rwxp----------:------:deny
               group@:--------------:------:allow
            everyone@:rwxp---A-W-Co-:------:deny
            everyone@:------a-R-c--s:------:allow

The file was created with `rw- — —` (i.e. umask 077) which lead to a :deny rule for user `u2` and since deny rules take precendence over allow rules, `u2` gets no access to `foo`. I contacted the author of FreeBSD’s NFSv4 ACL implementation, Edward Tomasz Napierała, and thankfully he drawed a way out of the mess:

Your problem is umask. When you create a file, ACL entries are inherited,
and then the new ACL is modified according to some (pretty complicated)
rules. You probably want to disable that, so that entries are simply
inherited, without further messing and adding deny entries. To do this,
set aclmode=passthrough and aclinherit=passthrough ZFS properties.

The only downside to this approach is that you cannot change these settings inside the jail, but only from the outside. Luckily, the host part is also under our control, so Lapo remounted the jail volume with the new settings, and voilá, the ACLs now work as expected.

You can learn something new every day.

mtn support for indefero got merged

It took us quite a while, but Loic d’Anterroches finally merged my monotone support fork back into indefero. Its expected that the upcoming 1.1 release of indefero is the first release which ships with mtn support.

Most of the things I talked about in the earlier blog post have now been implemented, i.e. you are now able to use remote_stdio to access remote databases or databases behind an usher instance. Furthermore, a forge-level control panel for usher and monotone public key support have been added.

The documentation has also been improved, there is a separate README file which lets you get started and the documentation on the new IDF configuration variables is also exhaustive.

What is kind of missing right now are support scripts for the forge-level setup of monotone. I plan to add these and even more documentation when I set up monotone’s new home server in the next couple of weeks. Yes, you’re reading right, monotone gets a different address, a fancier bug tracker and also a nicer revision browser (thanks to indefero) and if everything goes right, we’ll even offer monotone hosting support for selected projects.

Stay tuned for more updates!