Thank you very much for your explanation. I understand better.
I finally use sftp using this in the file /etc/ssh/sshd_config :
...
Match User site1
ChrootDirectory /var/www/htdocs/website1
ForceCommand internal-sftp
PasswordAuthentication yes
Match User site2
ChrootDirectory /var/www/htdocs/website2
ForceCommand internal-sftp
PasswordAuthentication yes
--EOF
And in each chroot there's a folder 'site'.
Your method using ftpd is easiest to achieve the goal, i will probably
apply it later.
Cheers,
Wesley.
Le 2012-05-08 16:48, Stuart Henderson a C)critB :
On 2012-05-07, Wesley <open...@e-solutions.re> wrote:
Test it, the chroot is not possible, the "%u" is not accepted.
Why would %u be accepted? Nowhere is this given in documentation.
"ftp-chroot A boolean value. If set, users in this class will
be
automatically chrooted to the user's login
directory.
ftp-dir A path to a directory. This value overrides the
login
directory for users in this class. A leading tilde
(`~') in
ftp-dir will be expanded to the user's home
directory based
on the contents of the password database."
So the easy way is to change the user's home dir in
/etc/master.passwd
to wherever you want them chrooted to (i.e. /var/www/whatever) and
just
set 'ftp-chroot'.
Or if you want them to have a *different* home directory than
ftp-directory you can have their home dir in master.passwd set how
you like it, and put each user in a separate class with an override
for ftp-dir (though this would be pretty insane).
and cap_mkdb /etc/login.conf
Running cap_mkdb on /etc/login.conf is for special cases. From
login.conf
with my highlighting:
"Sites with VERY LARGE /etc/login.conf files may wish to create a
database
version of the file, /etc/login.conf.db, for improved
performance. USING
A DATABASE VERSION FOR SMALL FILES DOES NOT RESULT IN A
PERFORMANCE
IMPROVEMENT. To build /etc/login.conf.db from /etc/login.conf
the
following command may be used:
# cap_mkdb /etc/login.conf
Note that cap_mkdb(1) must be run after each edit of
/etc/login.conf to
keep the database version in sync with the plain file."
The risk of not updating login.conf.db far outweighs the time saving
unless
you truly have a very large login.conf file and frequent logins. I
suggest
deleting it.
