• 14:52 On my way to africa now. Expect tweets for 2 weeks. #

• 23:54 One of the new SFU-ZU ads on skytrain has chani+pete. #
• 23:58 Techbc/siat alumni event good. "rilli" looks v.promising. IsoHunt well recieved, ditto techbc.ca plans #

• 11:40 Bah SSSS on me #
• 11:53 SSSS faster than normal line #
• 13:39 On plane now #

• 06:28 Monty's vodka, while good (hangover free), i suspect is to blame for utterly weird dreams. #
• 11:10 No more conf now, maybe gentoo dinner tonight. #

• 20:17 Drinking w/ Rick of Pirate Party #
• 17:22 In mylvmbackup talk #

• 07:52 What do you get w/ 4 geeks driving silicon valley? Australian, south african, dutch, german? Lost w/ a sense of humor. #
• 09:25 Jonathan Swartz says zfs license may change #
• 15:38 Test to .ca #
• 15:40 Test to international (done .ca+.us already) #
• 16:10 So .us sms fail, & .ca depends on what gsm provider's tower i hit #

• 22:29 Salmon marinated in miso paste & sake = win #
• 10:58 Going to check out MtView farmers market #
• 17:32 CA boerewors mostly ok #

1st Annual SIAT TechBC Alumni Event: April 24. 2008

When: Thursday April 24th, 2008
Mingle 6-630 PM
Presentations 630-730 PM
Wrap up 730-745 PM
Where: Room 3400, SFU Surrey Campus

* Drinks at the pub afterwards for those interested (please add a note in your RSVP if you plan on going to the pub so we can arrange reservations)

1st Annual Alumni Event: Catch up with old school friends. See where people have been and what people have been doing since grad.

Casual atmosphere with food and beverages from 6-630. Short 3-5 minute presentations from siat alumni about what they are doing in the industry between 630-730. The 3-5 minute presentations will be a great opportunity to let everyone know what you are doing, help connect you with others who share similar career paths, and to connect alumni seeking jobs to the right people.

RSVP: We ask that anyone planning to come please RSVP to to Barinder Dhesi at bdhesi@sfu.ca / 778 782 8131.

RSVP Presenter: If you are interested in presenting (solo or as a group) please RSVP to Barinder Dhesi at bdhesi@sfu.ca / 778 782 8131 with your name(s), position, and what company you are representing.

Please circulate this invitation to other SIAT alumni you think would be interested.

p.s. If you are interested in becoming involved in future alumni event planning, please contact Ginger Deverell at ginger_deverell@sfu.ca.

This is more a reminder for myself, how I laid out the seeds for herbs and spices in the small corner of garden that I planted them in this year.

A few days ago, nicoj posted about using Gitosis on Gentoo, and as the developer that put the package into the tree. However, I don't think he realized at the time, that the Gitosis I packaged up, does differ from the original upstream version.

Why is is different? It is different because I decided to use Gitosis to power the new Gentoo Overlays, and found some limitations with Gitosis, so ended up hacking the codebase heavily to make it do what I wanted. It seems my original Christmas email to the upstream author went AWOL, so I wrote him another in the meantime. I hope that he will be able to merge the changed sanely, and make life easier for evertbody.

So what's different? A lot. Here's a partial list of the big stuff that is actually visible to most folk

• Relative git+ssh:// URLs! The original Gitosis required that you use : between the hostname and the repository for a relative URL, and assumed that you were using an absolute URL otherwise. This made URLs look a bit ugly, and also broke some classical URL parsers that expected a port number after the colon, then a path after the slash. So now Gitosis supports git+ssh://HOST/REPO style URLs, where the REPO is looked up directly in the Gitosis config to see if it is a valid relative URL.
• gitosis-init, you can use the default STDIN input of your key, or you can use actual command-line arguments: gitosis-init --adminkey=FILE --adminname=STRING. The latter argument is for when then username portion of your SSH key does not contain anything useful to you, and you wish for gitosis to place it in a more suitably named file in the keydir/ set of SSH keys.
• Handle SSH keys intelligently, validate the algorithm, supporting both SSH1 and SSH2 keys, extract the username (the field is actually a comment per the RFC) safely if possible, and handle the options correctly. Amongst the options, the from field of the key is now preserved, so that if you had a key (without a passphrase for example) that was limited to login from a certain location only, it does not become less secure.
• Allow setting of the initial directory permissions, globally and per-repository. Gitosis used chmod 0750 on directories it created before, which caused problems if you were running git-daemon as nobody:nobody. For the Gentoo overlays, the default repos now use 0755. If you set this globally, you should ensure that your gitosis-admin repo gets dirmode=0750, so that it does not get shared out by gitweb or git-daemon.

There are also two pending TODO items that I have for the Gentoo Gitosis-powered Overlays

• Gitweb has broken owner strings when UTF8 is involved
• The permissions handling needs an overhaul, adding a repo presently requires adding two config sections, each with 3 lines long. I'd like to refactor and make the [repo ...] section get a single line extra for the common case, which would totally do away with the [group ...] section per repo. Groups would remain JUST for defining groups, and the [repo ...] sections would get the lists of members and groups directly.

On a total lark, something like Gitosis for managing SVN users would be great too.

Not sure who out there can help, but I'm looking for a number of old Gentoo distfiles, that were located on the Gentoo mirrors directly, and not copied from some other location. I do have every other version of the mysql-extras, so I am only looking for those listed here.

I have every other version of that distfile, those are the only ones I'm missing, and I'm after making a nice Git repo to trace the history. The SVN tree that was used for a short while doesn't contain some of the details from these either, hence the need for the tarballs.

Beyond those tarballs, it would be interesting to try and build an archive of every distfile ever used in Gentoo. I've got the diskspace (and tape backup) to do it. I already have an LTO3 tape that is getting every bit of release media/stages from Gentoo, so distfiles would be the next logical step.

Edit: Thanks to Lisa for 20050904.

If you use 'PermitRootLogin no' in your sshd_config and a locked-down sudo (requiring a password to upgrade powers), logging in to a machine as root is not allowed. This can be a pain when you want to rsync files between two machines, as root on both sides to preserve permissions and ownership. There is a fun little hack that you can use to get around this, that I'll document here.

1. Ensure your SSH agent is running and has a key present.
2. Open two shells, we will call them A and B (instructions prefixed with either or 'Both' below)
3. We will use A to connect to the source, and B to connect to the destination.
4. Both: SSH to the relevant machines, forwarding your agent, using 'ssh -A hostname'
5. Both: Run 'sudo su', authenticating to sudo. Do not use 'sudo su -', as we need to preserve our SSH agent information.
6. B: Run your rsync command as normal, but include the following option: --rsync-path='sudo rsync'

You should not get a password prompt! If you do get one, your sudo authentication did not propagate on the source machine properly. You cannot enter a password at this prompt either, it will never reach sudo, as rsync does not pass your input to it.

Alternatively, if your rsync version does not have a usable 'rsync-path' option (non-existant or wants a full path to a single program), you can use the -e option as: -e 'ssh user@source sudo /usr/local/bin/ignorefirst'. /usr/local/bin/ignorefirst is the following tiny script:

#!/bin/sh
shift
exec "$@"

The '-e' method is a lot more flexible, you can chain SSHs in it for example. You only need the 'ignorefirst' script because rsync puts the the hostname as the immediate next argument to the contents of '-e' commands.