Si on peut faire tout ca, c'est cool, sinon ben je retourne a mon serveur FTP en php!!!
Etienne
j'ai l'impression que tu as ces possibilités quand on regarde la doc. Sauf que le droit 'm' n'existe pas, je suppose que c'est le droit 'w' (write)
sinon je pense que tout le reste y est !
bruno modulix
Etienne SOBOLE wrote:
http://www.proftpd.org
donc d'apres toi: avec proFTPd je vais pouvoir : - utiliser un fichier pour y stocker les user/password (je passe sur le format, si faut que je le mette en forme ca ira) - lire des fichers du HD en fonction de droit qui ne sont pas linux
Non, pas "d'après moi" !-)
Je ne suis pas admin, je n'ai jamais tenté d'installer un serveur FTP, et les seules infos que je peux te donner sur proftpd sont celles qui figurent sur leur site... Donc ce serait probablement plus simple que tu ailles directement à la source !-)
NB : Je ne te garantis en rien que proftpd réponde à ton besoin, ça c'est à toi de voir. Je te signale juste qu'il existe au moins un serveur ftp qui permet d'utiliser un système d'authentification distinct de celui du système hôte et - a priori, après un rapide survol de la doc - pluggable. Si ça te permet de résoudre ton problème sans devoir réinventer la roue, tant mieux. Sinon, pas mieux :(
(snip)
-- bruno desthuilliers ruby -e "print ''.split('@').collect{|p| p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
Etienne SOBOLE wrote:
http://www.proftpd.org
donc d'apres toi:
avec proFTPd je vais pouvoir :
- utiliser un fichier pour y stocker les user/password (je passe sur le
format, si faut que je le mette en forme ca ira)
- lire des fichers du HD en fonction de droit qui ne sont pas linux
Non, pas "d'après moi" !-)
Je ne suis pas admin, je n'ai jamais tenté d'installer un serveur FTP,
et les seules infos que je peux te donner sur proftpd sont celles qui
figurent sur leur site... Donc ce serait probablement plus simple que tu
ailles directement à la source !-)
NB : Je ne te garantis en rien que proftpd réponde à ton besoin, ça
c'est à toi de voir. Je te signale juste qu'il existe au moins un
serveur ftp qui permet d'utiliser un système d'authentification distinct
de celui du système hôte et - a priori, après un rapide survol de la doc
- pluggable. Si ça te permet de résoudre ton problème sans devoir
réinventer la roue, tant mieux. Sinon, pas mieux :(
(snip)
--
bruno desthuilliers
ruby -e "print 'onurb@xiludom.gro'.split('@').collect{|p|
p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
donc d'apres toi: avec proFTPd je vais pouvoir : - utiliser un fichier pour y stocker les user/password (je passe sur le format, si faut que je le mette en forme ca ira) - lire des fichers du HD en fonction de droit qui ne sont pas linux
Non, pas "d'après moi" !-)
Je ne suis pas admin, je n'ai jamais tenté d'installer un serveur FTP, et les seules infos que je peux te donner sur proftpd sont celles qui figurent sur leur site... Donc ce serait probablement plus simple que tu ailles directement à la source !-)
NB : Je ne te garantis en rien que proftpd réponde à ton besoin, ça c'est à toi de voir. Je te signale juste qu'il existe au moins un serveur ftp qui permet d'utiliser un système d'authentification distinct de celui du système hôte et - a priori, après un rapide survol de la doc - pluggable. Si ça te permet de résoudre ton problème sans devoir réinventer la roue, tant mieux. Sinon, pas mieux :(
(snip)
-- bruno desthuilliers ruby -e "print ''.split('@').collect{|p| p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
Etienne SOBOLE
j'ai l'impression que tu as ces possibilités quand on regarde la doc. Sauf que le droit 'm' n'existe pas, je suppose que c'est le droit 'w' (write) sinon je pense que tout le reste y est !
non mais de toute façon je suis parti de nanoftp et j'ai modifier le script en fonction de mes besoins. ca ne m'a pris qu'une journée et ca fonctionne tres bien. merci encore pour avoir filé ce lien. je sais pas comment tu l'as trouvé. j'avais cherché dans google en vain.
AJOUT : de toute façon mon problème etait bien plus compliqué. les chemin aussi ne sont pas des chemin système. par exemple lorsque l'utilisateur paul se connecte et va dans le répertaoire mes articles, et bien il n'existe pas forcément un répertoire "mes articles". enfin bref. je suis obligé de passer par des scripts pour mouliner les chemin, les droits, et meme certain fichier qui n'existe pas physiquement...
Enfin bref. Si quelqu'un cherche un serveur FTP en PHP, ben il peut soit partir de celui de nanoftp qui est tres simple a comprendre (y quelque petits bugs mais bon) Soit me contacter et je lui filerai la version simplifiée que j'ai faite à partir du leur.
voila. c'est sympa de pouvoir faire des serveurs en PHP ca ouvre pas mal de perspectives. bon apres faudrait que j'arrive a faire une gestion correcte du démarrage et de l'arret du serveur, mais la c'est autre chose ;)
j'ai l'impression que tu as ces possibilités quand on regarde la doc.
Sauf que le droit 'm' n'existe pas, je suppose que c'est le droit 'w'
(write)
sinon je pense que tout le reste y est !
non mais de toute façon je suis parti de nanoftp et j'ai modifier le script
en fonction de mes besoins.
ca ne m'a pris qu'une journée et ca fonctionne tres bien.
merci encore pour avoir filé ce lien. je sais pas comment tu l'as trouvé.
j'avais cherché dans google en vain.
AJOUT : de toute façon mon problème etait bien plus compliqué. les chemin
aussi ne sont pas des chemin système.
par exemple lorsque l'utilisateur paul se connecte et va dans le répertaoire
mes articles, et bien il n'existe pas forcément un répertoire "mes
articles". enfin bref. je suis obligé de passer par des scripts pour
mouliner les chemin, les droits, et meme certain fichier qui n'existe pas
physiquement...
Enfin bref.
Si quelqu'un cherche un serveur FTP en PHP, ben il peut soit partir de celui
de nanoftp qui est tres simple a comprendre (y quelque petits bugs mais bon)
Soit me contacter et je lui filerai la version simplifiée que j'ai faite à
partir du leur.
voila.
c'est sympa de pouvoir faire des serveurs en PHP ca ouvre pas mal de
perspectives.
bon apres faudrait que j'arrive a faire une gestion correcte du démarrage et
de l'arret du serveur, mais la c'est autre chose ;)
j'ai l'impression que tu as ces possibilités quand on regarde la doc. Sauf que le droit 'm' n'existe pas, je suppose que c'est le droit 'w' (write) sinon je pense que tout le reste y est !
non mais de toute façon je suis parti de nanoftp et j'ai modifier le script en fonction de mes besoins. ca ne m'a pris qu'une journée et ca fonctionne tres bien. merci encore pour avoir filé ce lien. je sais pas comment tu l'as trouvé. j'avais cherché dans google en vain.
AJOUT : de toute façon mon problème etait bien plus compliqué. les chemin aussi ne sont pas des chemin système. par exemple lorsque l'utilisateur paul se connecte et va dans le répertaoire mes articles, et bien il n'existe pas forcément un répertoire "mes articles". enfin bref. je suis obligé de passer par des scripts pour mouliner les chemin, les droits, et meme certain fichier qui n'existe pas physiquement...
Enfin bref. Si quelqu'un cherche un serveur FTP en PHP, ben il peut soit partir de celui de nanoftp qui est tres simple a comprendre (y quelque petits bugs mais bon) Soit me contacter et je lui filerai la version simplifiée que j'ai faite à partir du leur.
voila. c'est sympa de pouvoir faire des serveurs en PHP ca ouvre pas mal de perspectives. bon apres faudrait que j'arrive a faire une gestion correcte du démarrage et de l'arret du serveur, mais la c'est autre chose ;)
Marc Quinton
bruno modulix wrote:
NB : Je ne te garantis en rien que proftpd réponde à ton besoin, ça c'est à toi de voir. Je te signale juste qu'il existe au moins un serveur ftp qui permet d'utiliser un système d'authentification distinct de celui du système hôte
j'ai vu qu'il est possible de decrire des users, avec des groupes. A quoi bon le faire dans une base de données si c'est pour ne pas en tenir compte a l'execution et la connexion de users.
donc, OUI, ce produit gere des users virtuels dont la liste est en base de données. (enfin j'ai pas testé).
voici un extrait d'un fichier de configuration donné a titre d'exemple.
# Specify our connection information. Both mod_sql_mysql and # mod_sql_postgres use the same format, other backends may specify a # different format for the first argument to SQLConnectInfo. By not # specifying a fourth argument, we're defaulting to 'PERSESSION' # connections -- a connection is made to the database at the start of # the session and closed at the end. This should be fine for most # situations. SQLConnectInfo :port username password
# Specify our authentication schemes. Assuming we're using # mod_sql_mysql, here we're saying 'first try to authenticate using # mysql's password scheme, then try to authenticate the user's # password as plaintext'. Note that 'Plaintext' isn't a smart way to # store passwords unless you've got your database well secured. # THIS DIRECTIVE IS REQUIRED FOR MOD_SQL TO WORK. SQLAuthTypes Backend Plaintext
# Specify the table and fields for user information. If you've # created the database as it specifies in 'README.mod_sql', you don't # need to have this directive at all UNLESS you've elected not to # create some fields. In this case we're telling mod_sql to look in # table 'users' for the fields 'username','password','uid', and # 'gid'. The 'homedir' and 'shell' fields are specified as 'NULL' -- # this will be explained below. SQLUserInfo users username password uid gid NULL NULL
# Here we tell mod_sql that every user it authenticates should have # the same home directory. A much more common option would be to # specify a homedir in the database and leave this directive out. Note # that this directive is necessary in this case because we specified # the homedir field as 'NULL', above. mod_sql needs to get homedir # information from *somewhere*, otherwise it will not allow access. SQLDefaultHomedir "/tmp"
# This is not a mod_sql specific directive, but it's here because of # the way we specified 'SQLUserInfo', above. By setting this to # 'off', we're telling ProFTPD to allow users to connect even if we # have no (or bad) shell information for them. Since we specified the # shell field as 'NULL', above, we need to tell ProFTPD to allow the # users in even though their shell doesn't exist. RequireValidShell off
# Here we tell mod_sql how to get out group information. By leaving # this commented out, we're telling mod_sql to go ahead and use the # defaults for the tablename and all the field names. # SQLGroupInfo groups groupname gid members
# For small sites, the following directive will speed up queries at # the cost of some memory. Larger sites should read the complete # description of the 'SQLAuthenticate' directive; there are options # here that control the use of potentially expensive database # queries. NOTE: these arguments to 'SQLAuthoritative' limit the way # you can structure your group table. Check the README for more # information. SQLAuthenticate users groups usersetfast groupsetfast
bruno modulix wrote:
NB : Je ne te garantis en rien que proftpd réponde à ton besoin, ça
c'est à toi de voir. Je te signale juste qu'il existe au moins un
serveur ftp qui permet d'utiliser un système d'authentification distinct
de celui du système hôte
j'ai vu qu'il est possible de decrire des users, avec des groupes.
A quoi bon le faire dans une base de données si c'est pour ne pas
en tenir compte a l'execution et la connexion de users.
donc, OUI, ce produit gere des users virtuels dont la liste
est en base de données. (enfin j'ai pas testé).
voici un extrait d'un fichier de configuration donné a titre
d'exemple.
# Specify our connection information. Both mod_sql_mysql and
# mod_sql_postgres use the same format, other backends may specify a
# different format for the first argument to SQLConnectInfo. By not
# specifying a fourth argument, we're defaulting to 'PERSESSION'
# connections -- a connection is made to the database at the start of
# the session and closed at the end. This should be fine for most
# situations.
SQLConnectInfo dbname@host:port username password
# Specify our authentication schemes. Assuming we're using
# mod_sql_mysql, here we're saying 'first try to authenticate using
# mysql's password scheme, then try to authenticate the user's
# password as plaintext'. Note that 'Plaintext' isn't a smart way to
# store passwords unless you've got your database well secured.
# THIS DIRECTIVE IS REQUIRED FOR MOD_SQL TO WORK.
SQLAuthTypes Backend Plaintext
# Specify the table and fields for user information. If you've
# created the database as it specifies in 'README.mod_sql', you don't
# need to have this directive at all UNLESS you've elected not to
# create some fields. In this case we're telling mod_sql to look in
# table 'users' for the fields 'username','password','uid', and
# 'gid'. The 'homedir' and 'shell' fields are specified as 'NULL' --
# this will be explained below.
SQLUserInfo users username password uid gid NULL NULL
# Here we tell mod_sql that every user it authenticates should have
# the same home directory. A much more common option would be to
# specify a homedir in the database and leave this directive out. Note
# that this directive is necessary in this case because we specified
# the homedir field as 'NULL', above. mod_sql needs to get homedir
# information from *somewhere*, otherwise it will not allow access.
SQLDefaultHomedir "/tmp"
# This is not a mod_sql specific directive, but it's here because of
# the way we specified 'SQLUserInfo', above. By setting this to
# 'off', we're telling ProFTPD to allow users to connect even if we
# have no (or bad) shell information for them. Since we specified the
# shell field as 'NULL', above, we need to tell ProFTPD to allow the
# users in even though their shell doesn't exist.
RequireValidShell off
# Here we tell mod_sql how to get out group information. By leaving
# this commented out, we're telling mod_sql to go ahead and use the
# defaults for the tablename and all the field names.
# SQLGroupInfo groups groupname gid members
# For small sites, the following directive will speed up queries at
# the cost of some memory. Larger sites should read the complete
# description of the 'SQLAuthenticate' directive; there are options
# here that control the use of potentially expensive database
# queries. NOTE: these arguments to 'SQLAuthoritative' limit the way
# you can structure your group table. Check the README for more
# information.
SQLAuthenticate users groups usersetfast groupsetfast
NB : Je ne te garantis en rien que proftpd réponde à ton besoin, ça c'est à toi de voir. Je te signale juste qu'il existe au moins un serveur ftp qui permet d'utiliser un système d'authentification distinct de celui du système hôte
j'ai vu qu'il est possible de decrire des users, avec des groupes. A quoi bon le faire dans une base de données si c'est pour ne pas en tenir compte a l'execution et la connexion de users.
donc, OUI, ce produit gere des users virtuels dont la liste est en base de données. (enfin j'ai pas testé).
voici un extrait d'un fichier de configuration donné a titre d'exemple.
# Specify our connection information. Both mod_sql_mysql and # mod_sql_postgres use the same format, other backends may specify a # different format for the first argument to SQLConnectInfo. By not # specifying a fourth argument, we're defaulting to 'PERSESSION' # connections -- a connection is made to the database at the start of # the session and closed at the end. This should be fine for most # situations. SQLConnectInfo :port username password
# Specify our authentication schemes. Assuming we're using # mod_sql_mysql, here we're saying 'first try to authenticate using # mysql's password scheme, then try to authenticate the user's # password as plaintext'. Note that 'Plaintext' isn't a smart way to # store passwords unless you've got your database well secured. # THIS DIRECTIVE IS REQUIRED FOR MOD_SQL TO WORK. SQLAuthTypes Backend Plaintext
# Specify the table and fields for user information. If you've # created the database as it specifies in 'README.mod_sql', you don't # need to have this directive at all UNLESS you've elected not to # create some fields. In this case we're telling mod_sql to look in # table 'users' for the fields 'username','password','uid', and # 'gid'. The 'homedir' and 'shell' fields are specified as 'NULL' -- # this will be explained below. SQLUserInfo users username password uid gid NULL NULL
# Here we tell mod_sql that every user it authenticates should have # the same home directory. A much more common option would be to # specify a homedir in the database and leave this directive out. Note # that this directive is necessary in this case because we specified # the homedir field as 'NULL', above. mod_sql needs to get homedir # information from *somewhere*, otherwise it will not allow access. SQLDefaultHomedir "/tmp"
# This is not a mod_sql specific directive, but it's here because of # the way we specified 'SQLUserInfo', above. By setting this to # 'off', we're telling ProFTPD to allow users to connect even if we # have no (or bad) shell information for them. Since we specified the # shell field as 'NULL', above, we need to tell ProFTPD to allow the # users in even though their shell doesn't exist. RequireValidShell off
# Here we tell mod_sql how to get out group information. By leaving # this commented out, we're telling mod_sql to go ahead and use the # defaults for the tablename and all the field names. # SQLGroupInfo groups groupname gid members
# For small sites, the following directive will speed up queries at # the cost of some memory. Larger sites should read the complete # description of the 'SQLAuthenticate' directive; there are options # here that control the use of potentially expensive database # queries. NOTE: these arguments to 'SQLAuthoritative' limit the way # you can structure your group table. Check the README for more # information. SQLAuthenticate users groups usersetfast groupsetfast