debian-sf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Debian-sf-devel] comments on debian 2.6+13


From: Christian Bayle
Subject: Re: [Debian-sf-devel] comments on debian 2.6+13
Date: Wed, 16 Oct 2002 18:41:11 +0200

Mathieu Peltier wrote:
Hi,

Some comments on the new package debian 2.6+13:

- it seems that links to documentation in /usr/share/doc/ are missing in /usr/doc/?
  
dunno
- the directory /var/lib/sourceforge/ftp/ is not used (?) and should be deleted?
Original sf make user upload in file release system with anonymous ftp
We changed this.
This stay for historical reason and we should before remove $FTPINCOMING_DIR = '/usr/lib/sourceforge/ftp/incoming'
in local.inc

- 2 typos in www/include/languages/Base.tab: here the cvs diff:
  *  please log a<a href="">support request</a> ->  please
log a <a href="">support request</a> (line 29)
  * approrpiate tool -> appropriate tool (line 81) 
  
done
- For info, I can test now my patch
(https://savannah.nongnu.org/patch/index.php?func=detailpatch&patch_id=518&group_id=259)
which allows to notify the admin user which a new project is submitted, it is
working on debian 2.6+13!
  
done and modified to handle all members of admin group
- ftp anonymous acces is broken: I have submitted a patch to fix that. I think
also that a template for sf-proftp.conf should be provided in order to set the
ServerAdmin directive (should be {server_admin} in
/etc/sourceforge/sourceforge.conf instead of address@hidden). What do you think of
that?
  
done partly, We now don't change welcome.msg if file is there
- the usage command for install.db.sh is not complete:
should be:
echo "Usage: $0 {configure-files|configure|purge|purge-files|dump|restore}"
instead of:
echo "Usage: $0 {configure|purge}"
  
done
- typos in www/admin/database.php, www/admin/index.php , www/admin/unsubscribe.php

Maintanance -> Maintenance

  
rgrep Maintanance .
    
./database.php:site_admin_header(array('title'=>"Site Admin: Groups' DB Maintanance"));
./index.php:<LI><A href=""><?php echo $GLOBALS['sys_name']; ?> Site Mailings Maintanance</A>
./unsubscribe.php:  * Site Mailings Subscription Maintanance page
./unsubscribe.php:                site_admin_header(array('title'=>'Site Mailings Subscription Maintanance'));
./unsubscribe.php:site_admin_header(array('title'=>"Site Mailings Subscription Maintanance"));
./unsubscribe.php:Site Mailings Subscription Maintanance
  
done
- with my config, I can access the SSH server with protocol 2. I have checked
the documentation, it seems that, for recent ssh packages, the authorized key
file is now by default: ~/.ssh/authorized_keys for protocol 2 (instead of
autorized_keys2 used before). So the web interface can handle keys generated
with protocol 2 without problem.

If this is correct, I suggest to change the www/account/editsshkeys.php file to
warn the user:

Remplace:
	<P>
	To avoid having to type your password every time for your CVS/SSH
	developer account, you may upload your public key(s) here and they
	will be placed on the CVS server in your ~/.ssh/authorized_keys file.
	<p>
	To generate a public key, run the program 'ssh-keygen' (or ssh-keygen1).
	The public key will be placed at '~/.ssh/identity.pub'. Read the ssh
	documentation for further information on sharing keys.
	</p>

by 
	<P>To avoid having to type your password every time for your CVS/SSH
	developer account, you may upload your public key(s) here and they will
	be placed on the CVS server in your ~/.ssh/authorized_keys file.</P>

	<P>To generate a public key, run the program 'ssh-keygen' (you can use
	both protocol 1 or 2). The public key will be placed at
	'~/.ssh/identity.pub' (protocole 1) and '~/.ssh/id_dsa.pub' or
	'~/.ssh/id_rsa.pub' (protocole 2). Read the ssh documentation for
	further information on sharing keys.</P>
  
done
(it supposes of course that both protocol 1 and 2 are allowed in
/etc/ssh/sshd_config: warning I think that SSH now uses by default only protocol
2...)
  
The default protocol seems to be a choice for both users and servers
By default debian choose 2,1 for both users and servers, but I could see the folowing case
If server is 1,2
and client is 2,1 client seems to supercede and this make that he has to enter a password to connect
even if he has a key for  ssh1 only
This is annoying, because you can't control client, and if client upgrade from ssh1 to ssh2, things start to fail
Worst, if server upgrade and even put priority on 1, ssh2 client formally working with protocol 1 suddenly don't work
if their priority was 2,1 (what is common)
  



reply via email to

[Prev in Thread] Current Thread [Next in Thread]