Sylvain Beucler <[EMAIL PROTECTED]> tapota : > On Mon, Sep 20, 2004 at 03:58:46PM +0200, Mathieu Roy wrote: >> Sylvain Beucler <[EMAIL PROTECTED]> tapota : >> >> > Hi, >> > >> > After upgrading to Savane a while ago, we had to reinsert a lot of >> > custom changes made at Savannah by various people. >> > >> >> backend only? > > We have some small changes in the frontend as well. > > Let's try to detail the current situation: > > Frontend: > - robots.txt: added all admin/ and include/ directories [Elfyn]
I guess that could be added without much discussion, despite the fact that theoretically robots cannot get there. > > - account/change.php: updates a list of pending GPG keys to create > on the system [sysadmins] Seems specific to your stuff but could be included, if the counterpart comes along. > - include/sendmail.php: code to send mail in a chroot's environment > [corvus] - include/smtp.inc: library using by sendmail.php [corvus] I took a look to that code a while ago and I do not think it's a must have. I'm not even sure it's a security improvement, if not the contrary. > - news/approve.php: unfortunately uncommited change, using URL like > 'file.php?param' instead of '?param', which is not supported well by > netscape 4 [Sylvain] netscape 4 does not support blabla/ links? I'm not sure that I understood the point :) > + mail/admin/index.php and files/add.php: "temporarily unavailable" notices > Sure, this kind of hacks cannot be included. > => Check how to add the new sendmail code I'm not in favor in including this code in Savane (Savane does not need to reimplement the way PHP send mails, it's not it's purpose). But if you cannot configure PHP to achieve the behavior you're looking for (it's strange that PHP cannot be configured to use a distant SMTP daemon, especially since it runs on Microsoft Windows), I'm sure we can find a way to make your think working with Savane. >=> Commit the approve.php and robots.txt fixes if wanted I have nothing against the approve.php thing but I'm a bit puzzled by it. > => Check >whether we keep the GPG keys pending list system > > Lib [sysadmins]: - DB.pm: functions to manage the list of pending >GPG keys to create; hardcoded path to the MySQL socket; Hardcoded path to mysql socket cannot be included. There's no point in reinventing Perl DBI. For gpg keys, it should work more or less like ssh key, doesn't it? >- Groups.pm: GPG-related functions: creation of keyrings, and >maintainance of a backup of what the system was last time sv_groups >was started, allowing to update only the groups' keyrings that did >change; we're unsure whether we will keep this complicated, abeilt >resource-saving, solution from the sysadmins No problem to include it, as long as it does not break anything. >- User.pm: adding >various access restrictions in the beginning of all SSH keys; code to >create ~/.gnupg/pubring.gpg No problem to include it, as long as it does not break anything. > > => Add a variables for mysql options in the configuration file Like for instance? > => Add GPG-related functions and determine what updating method > we'll use ? > => Allow the user to customize the authorized_keys file, either via a > template (something like $template =~ /<SSH-KEY>/$key/) defined in the > configuration file, or using a hook. What purpose does it serve? > Backend: > - sv_cvstarballs [Sylvain] How does it differs from sv_backup and sv_daily_cvs_tarball? > > - sv_users & sv_groups: currently difficult to determine exactly > what changed; 2 weeks ago, only sv_groups was modified, with lots of > hardcoded stuff, to create the projects, compare the groups and > determine which ones should have their GPG info updated, and a > clumpsy hack that that makes the project type ignored during project > creation. This code was not meant to be integrated in Savane *at > all*, and is the main difficulty. Moreover, Elfyn worked on the code > to fix the last week's issues at Savannah, and I'm a bit lost right > now [all the team] > > => check if sv_cvstarballs contains interesting code to merge with > sv_nightly_cvs_tarball Ok. > => rewrite sv_groups and sv_users with minimal changes against > Savane's; use hooks or temporarily hardcoded functions in lib/ ? > > gnu-specific [sv hackers]: > => maybe include our version of savannah.el, and some of our scripts; > or, remove that directory from Savane Up to you. -- 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 | +---------------------------------------------------------------------+
