Sylvain Beucler <[EMAIL PROTECTED]> tapota : > Hi, > > Attached is a cvs diff of what I currently did to externalize the > local Savannah changes from Savane itself. Those are the parts I could > not separate from Savane, or added because they can be useful outside > of Savannah. The next step for me is to write some separate cron-jobs > to perform the remaining Savannah-specific tasks. > > Overview: > > - Done: > > * added a prefix to authorized keys: new configuration variable: > $sys_authorized_keys_prefix, changes in User.pm (GetUserSSHRealKey, > UserAddSSHKey) and sv_users (the way to compare ssh keys in the system > and in the database regarding newlines).
What do you mean by prefix? Does it means that the authorized_keys is name like ~/.ssh/$prefixauthorized_keys? If not, prefix is not the correct name for this configuration option. I realize we already have a case of configuration option with the word "prefix" misused, but this is a bug, not an example :) For cohesion sake, when a configuration option designate a directory, it should be naname $sys_somethingdir Apart from that, I'm not sure to understand the whole thing. The standard way to get authorized_keys with open ssh is ~/.ssh/authorized_keys. Do you have something different than that? If so, why (wouldn't it be the thing to fix?)? Do I miss something? > And incidentally, > > Remaining not in Savane (should be doable in separate cron jobs, > unless I'm mistaken): > > * (1) create a chroot'd /etc/passwd and /etc/group -> separate cron > job. Copy /etc/group and /etc/passwd in each cvs root, provided /etc/ > is more recent that in an arbitrary cvs root. We have such system at Gna. But I'm not sure it should be part of Savane. It is easily doable with Savane, we could document that. But making Savane handling that stuff itself > > * (2) Is group 'www' properly supported? -> Yes, old hardcoding.. >Could be added in (1) before the copy if not working > > * (3) sv_gatekpr -> separate cron_job, recreates all keyrings, > provided /etc/group is more recent that the current keyring. > > > Any comments? I felt free to make comments when I estimated it necessary :) > > How should we proceed for the commit, given the current work on the >CERN branch? >From what I understand, most of your changes are done on the backend. There's no major task planned on the backend on the CERN branch. So you can commit on the backend directories without much risk of conflicts. However, I'd like to release Savane 1.0.5 by the end of the month, so it means you _must_ create a branch (see doc/devel for details). Before the release 1.0.5, we'll have the possibility to merge your branch, if it is ready and tested, or not. (as usually, in fact only bugfixes and cosmetics should be done directly on the trunk). Regards, -- Mathieu Roy +---------------------------------------------------------------------+ | General Homepage: http://yeupou.coleumes.org/ | | Computing Homepage: http://alberich.coleumes.org/ | | Not a native english speaker: | | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english | +---------------------------------------------------------------------+ _______________________________________________ Savane-dev mailing list [EMAIL PROTECTED] https://mail.gna.org/listinfo/savane-dev
