> > * 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?
Rather, you're forgetting it :) https://mail.gna.org/public/savane-dev/2004-09/msg00241.html Anyway, $sys_authorized_keys_options or $sys_ssh_user_options would be indeed more appropriate. > > 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 I think your sentence is 'cut' :/ Currently, I plan to do it using a separate cron job. Once we have a better (non-harcoded) way to call CvsMakeArea and the like, we should be able to provide some optional 'plug-ins' to cleanly handle CVS' roots. I still follow the "2-steps" merge plan we discussed in the conversation linked above. To be continued.. > > Any comments? > > I felt free to make comments when I estimated it necessary :) Thanks :) > > 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). Ok. I will certainly do it tonight (when I'll be back home). -- Sylvain
