Hi,
Hmm, in the previous mail I made a brief summary of the current
changes, and then added (with '=>') the planned changes. It seems you
read both kinds of items as if they had the same meaning. Well, for
sure I was not perfectly clear :/
So,
On Mon, Sep 20, 2004 at 07:36:56PM +0200, Mathieu Roy wrote:
> > - 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 :)
Here's an example:
<A HREF="?approve=1..."> => not well supported
<A HREF="$PHP_SELF?approve=1..."> => well supported
> > => 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.
The code is also not very stable, since mails lack the Date header,
and e-mails to 'user' does not get rewritten as
'[EMAIL PROTECTED]' - which can cause the mail to be tagged as
spam.
I'll try to see exactly why the code is there and how we could get rid
of it, if appropriate.
> > 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.
>
> > => Add a variables for mysql options in the configuration file
>
> Like for instance?
Add a $db_options variables in savannah.conf.pl
For example:
$db_options = "mysql_socket=/savannah/mysqld/mysqld.sock"
Then in DB.pm, use something like:
our $dbd =DBI->connect('DBI:mysql:database='.$sys_dbname
.':host='.$sys_dbhost
.':'.$options,
...
> For gpg keys, it should work more or less like ssh key, doesn't it?
It depends. Paul and Jim used, for all the GPG-related code, a
slightly different approach than in the rest of Savane. For example,
all SSH keys are rewritten if the database and ~/.ssh/authorized keys
differ (*); here GPG keys to be created are queued in a table.
Likewise, when creating the project pubring.gpg, there is a comparison
of the database as it was last time the cron job was run, and as it is
now, to determine whether the pubring should be regenerated.
This adds I think 2 more tables to the database.
pros: it is IMHO way faster
cons: if there is any problem during a cron_job, then the database
will not be in sync with the system; therefore, an admin has to
temporarily hack the code to make it regenerate all the accounts, so
it is harder to maintain eventually
I think we will drop this solution and rather regenerate everything,
even if it is resources-consuming. The code will be simpler, and
consistent with Savane, which is good for the merge. Later, we could
implement that kind of solution in Savane if appropriate.
Any comment?
(*) Incidentally, when reading the code, I wondered what was the point
of comparing the SSH keys in the system and in the database to
determine whether to regenerate them. Indeed, to compare the keys set,
you have to read ~/.ssh./authorized_keys, which is time
consuming. IMHO it would be faster to directly overwrite
~/.ssh./authorized_keys without reading it first.
> > => 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?
Currently, the code writes the SSH key directly in athorized_keys. At
savannah, we prefix it by 'command="cvs server"' and various SSH
parameters (eg no-X11-forwarding). That is hardcoded, which is
bad. The purpose of what I described is to externalize this.
> > Backend:
> > - sv_cvstarballs [Sylvain]
>
> How does it differs from sv_backup and sv_daily_cvs_tarball?
I have yet to check :) I wrote that in February I think, and neither
Rudy nor I knew about an existing script for the job.
Well let's check now...
So, I get the list of projects from the database instead of a
directory. This allows me to avoid doing tarballs of private
projects. Another fix would be to create an appropriate .htaccess with
passwords for such projects. Or to more simply have the list of
private projects added to /etc/daily_cvs_tarball.disallow.
I use hardcoded directories, but it seems you do quite the same using
command-line parameters.
Using the database also made me re-set $SIG{PIPE} to 'DEFAULT': it was
modified by the database library, and caused the script to hand when
tar failed with a "broken pipe" error. Maybe it is needed for
sv_backup.
> > => rewrite sv_groups and sv_users with minimal changes against
> > Savane's; use hooks or temporarily hardcoded functions in lib/
>
> ?
This is related to items I had written above regarding GPG. I meant
that the code was modified a lot, and I'll just try to add a minimum
of changes on sv_groups from Savane, instead of doing an heavy merge.
--
Sylvain
_______________________________________________
Savane-dev mailing list
[EMAIL PROTECTED]
https://mail.gna.org/listinfo/savane-dev
