On Mon, Sep 20, 2004 at 09:59:37PM +0200, Mathieu Roy wrote:
> > 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.
That's what netscape4 does, actually:
In approve.php:
"?param" => ./?param => index.php?param
It should be
"?param" => ./approve.php?param
> I guess the idea was to avoid having exim installed on the same chroot
> than apache.
Maybe we could use ssmtp then, so as to forward the local mail to... localhost.
> >> > => 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?
No, DBI uses the sockets in the built-in default path, ie
/var/run/mysqld. We want to overide this and use another path. And, of
course, I do not want it to be hardcoded in DB.pm like it is now :/
> 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).
I just hope that all the GPG stuff, which didn't exist before, will
not be too slow.
> 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.
We should do some benchmarks at a point.
> > 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.
Maybe some people at Boston wants to export their DISPLAY?
Anyway, it is not the only option.
> 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.
I agree, and we will have to change that soon for Arch (sftp) support.
Nevertheless, we need it at the moment :/
> > 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.
The problem is that some backups (cvs tarballs with RCS files) are
publicly available.
> > 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.
AFAIK it doesn't.
Thanks for your feedback,
--
Sylvain
_______________________________________________
Savane-dev mailing list
[EMAIL PROTECTED]
https://mail.gna.org/listinfo/savane-dev
