Sylvain Beucler <[EMAIL PROTECTED]> tapota :
> 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 :/
In fact, I realized that only after reading the 2/3 of the mail. Shame
on me for reply without having read mails entirely.
> 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
I get the picture. But nowadays almost all website use the first kind
of links (short is beautiful?). And this kind of links are almost
everywhere in Savane.
<a href=".?approve=1..."> would maybe work.
>> > => 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.
I guess the idea was to avoid having exim installed on the same chroot
than apache.
>>
>> > => 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,
> ...
What's the interest this approach? Security? Execution/Read time?
>> 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?
I agree. I had the chance to be able to experiment by myself sv_groups
and sv_users on Savannah database with the previous machine, a
biprocessor Pentium III. On this computer, it was fast enough (less
than 5 minutes per cronjob), even if the computer was already well
loaded by cvs and apache.
So I do not expect load caused by these scripts to be a big big issue
-- if you have load problems, it cannot be the cause (and I'd say
it's rather strange that a brand new server is more loaded than an old
one).
All the installation of Savane seems small enough to avoid increasing
the need of manual intervention.
But the other approach could be interesting to study, at a later
point. I'm just a bit afraid of scripts that does not checks content
of users homes, opening the door to unnoticed malicious changes.
> (*) 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.
Overwriting the keys everytime? Well, I'm not sure writing is fast as
reading on all kind of harddisk. Overwriting everything is not very
clean -- maybe that could be a command line option (or even the
default), if it proves to be faster in most cases.
>
>> > => 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.
I find even strange to configure X11-forwarding there. Why not just
editing /etc/ssh/sshd_config? Normally on such server, nobody should
use X11-forwarding.
Restricting command via .authorized_key is not necessarily a bad idea
but it forces you to run sv_members on every distinct system (on
download area, on cvs, on arch...) in order to get the appropriate
content. Or you put all the kind of accesses inside an authorized_key
file shared on all system, and in this case, it's rather useless.
>> > 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,sv_backend was initially written by Loic Dachary in 1999/2000.
> So, I get the list of projects from the database instead of a
> directory. This allows me to avoid doing tarballs of private
> projects.
sv_backups does backups, so it have to take everything.
> 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 do not remember how sv_daily... handle private groups.
>
> 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.
That's the best approach I think.
Have fun :)
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 |
+---------------------------------------------------------------------+
