Serveur FTP graphique sous Linux ? - Page 1

Je cherche un serveur FTP graphique (*PAS* un wrappeur de ligne de commande comme 'gproftp' qui est une vraie daubasse en gestion des utilisateurs) et je n'ai RIEN trouvé, tous les forums que j'ai épluchés (même ceux de Fedora) m'ont tous redirigés sur cette merde de 'gproftp' ! Alors je demande si en 2009 on ne pourrait pas avoir un équivalent de http://www.cerberusftp.com/ ou http://filezilla-project.org/ (serveur UNIQUEMENT sous Windows, c'est pas beau ça ?) ou http://www.g6ftpserver.com/ ? Etonnant que Linux le roi des réseaux ne soit même pas fichu de proposer un serveur graphique alors que Windows le peut sans problème, considérant le nombre d'alternatives disponibles ! Alors à quoi sert donc KDE ou GTK ? Enfin merci si vous disposez de la réponse...

Kochise

non, c'est pas étonnant, un serveur n'a pas à être graphique.

windows est un clicodrome, donc forcément y'a des filezilla serveur ou des cesarftp qui ont *besoin* d'un machin graphique,

mais sous linux y'en a pas. c'est proftpd ou vsftpd.

linux != windows, l'un ne remplace pas l'autre.

Ouais mais pour le configurer, c'est quand même mieux une interface graphique qui FONCTIONNE et pas un wrappeur ératique comme 'gproftp' ! Pourquoi donc les serveur FTP peuvent êtres graphiques sous Windows (avec le confort d'utilisation que ça apporte) et pas sous Linux (Gnome ou KDE) comme Ubuntu ou Fedora ? Pourquoi se coller un truc indigeste en ligne de commande en 2009 ?

Pouquoi pas The Gimp en ligne de commande pendant qu'on y est ? Ton raisonnement, je pas comprendre...

Kochise

the gimp en ligne de commande est aussi idiot qu'un serveur ftp graphique.

vi /etc/vsftpd/vsftpd.conf

Laisse tomber Kochise, c'est pas le raisonnement de squalyl en soi, c'est la philosophie Linux (et UNIX dans son ensemble).

The GIMP en ligne de commande, ça s'appelle ImageMagick.

Quant à la question de départ, as-tu essayé system-config-vsftpd? C'est aussi un frontend, mais tu ne trouveras pas autre chose, un serveur entièrement graphique, c'est absurde comme architecture, le serveur est un daemon à portée de système qui tourne soit en root, soit en tant qu'un utilisateur spécial et qui tourne même quand tu n'as aucune session X11 en cours, il ne va pas afficher une interface graphique dans ta session X11 utilisateur.

squalyl (./2) :
non, c'est pas étonnant, un serveur n'a pas à être graphique.

windows est un clicodrome, donc forcément y'a des filezilla serveur ou des cesarftp qui ont *besoin* d'un machin graphique,

mais sous linux y'en a pas. c'est proftpd ou vsftpd.

linux != windows, l'un ne remplace pas l'autre.

Euh filezilla server n'a pas *besoin* d'une interface graphique, tu peux très bien t'en servir sans... (d'ailleurs, tu peux sans aucun souci lancer l'interface graphique sur une autre machine que le serveur, ou t'amuser à changer le fichier conf à la main...)

Kochise (./1) :
Je cherche un serveur FTP graphique (*PAS* un wrappeur de ligne de commande comme 'gproftp' qui est une vraie daubasse en gestion des utilisateurs) et je n'ai RIEN trouvé, tous les forums que j'ai épluchés (même ceux de Fedora) m'ont tous redirigés sur cette merde de 'gproftp' ! Alors je demande si en 2009 on ne pourrait pas avoir un équivalent de http://www.cerberusftp.com/ ou http://filezilla-project.org/ (serveur UNIQUEMENT sous Windows, c'est pas beau ça ?) ou http://www.g6ftpserver.com/ ? Etonnant que Linux le roi des réseaux ne soit même pas fichu de proposer un serveur graphique alors que Windows le peut sans problème, considérant le nombre d'alternatives disponibles ! Alors à quoi sert donc KDE ou GTK ? Enfin merci si vous disposez de la réponse...

Kochise

Et encore, tu ne demandes pas un serveur SCP / SFTP / FTPS qui soit un peu évolué

Bah, SCP et SFTP sont proposés de base avec openssh-server, et la version la plus récente est plutôt flexible (elle permet d'avoir des répertoires racine séparés par utilisateur, par exemple).

Quant à FTPS, vsftpd le propose.

Oui, ça te fait 2 daemons, mais il faut savoir:
* que ce sont des protocoles assez différents - SFTP et SCP passent par SSH et sont différents du FTP, FTPS n'est que du FTP par SSL,
* qu'en principe un seul des 3 protocoles suffit: SCP, SFTP et FTPS proposent des fonctionnalités comparables. (Mais il est vrai que les clients ne gèrent pas toujours tout, donc être flexibles du côté serveur peut être un plus.)

Kevin Kofler (./8) :
Bah, SCP et SFTP sont proposés de base avec openssh-server, et la version la plus récente est plutôt flexible (elle permet d'avoir des répertoires racine séparés par utilisateur, par exemple).

Quant à FTPS, vsftpd le propose.

Oui, ça te fait 2 daemons, mais il faut savoir:
* que ce sont des protocoles assez différents - SFTP et SCP passent par SSH et sont différents du FTP, FTPS n'est que du FTP par SSL,
* qu'en principe un seul des 3 protocoles suffit: SCP, SFTP et FTPS proposent des fonctionnalités comparables. (Mais il est vrai que les clients ne gèrent pas toujours tout, donc être flexibles du côté serveur peut être un plus.)

Bah configure SSH pour faire du SFTP avec des quota (disques, bande passante, ...), des utilisateurs authentifiés sur LDAP ou AD, ... et compare le temps que ça te prend pour avoir la même configuration avec TitanFTP ^^
(et idem avec vsftpd... surtout que la moitié des options ne sont disponibles que si on lit le code source... )

Bah, tu configures un serveur dédié ou une machine virtuelle dans un serveur général pour qu'il récupère la liste des utilisateurs locaux à travers LDAP, tu configures OpenSSH et vsftpd pour qu'ils utilisent les utilisateurs locaux (pour OpenSSH, c'est le réglage par défaut) et tu mets un quota POSIX par utilisateur local et c'est fait. Réinventer le système d'utilisateurs dans le serveur FTP sux.

Kevin Kofler (./10) :
Bah, tu configures un serveur dédié ou une machine virtuelle dans un serveur général pour qu'il récupère la liste des utilisateurs locaux à travers LDAP, tu configures OpenSSH et vsftpd pour qu'ils utilisent les utilisateurs locaux (pour OpenSSH, c'est le réglage par défaut) et tu mets un quota POSIX par utilisateur local et c'est fait. Réinventer le système d'utilisateurs dans le serveur FTP sux.

Faudrait que tu acceptes un jour que tout le monde n'a pas les mêmes besoins que toi...

Bah, la solution que je propose répond à tes besoins (du moins ceux dont tu as parlé dans le ./9).
Mais je te signale que cette discussion est hors sujet.

Boaf, les wrapper/frontend n'intègrent que ce qu'ils ont envie par rapport à l'étendue des options de la ligne de commande et/ou le font plus ou moins bien. L'avantage d'un serveur TOUT graphique, en dehors d'être plus intuitif et ergonomique (le but d'une interface graphique après tout) est de gèrer correctement toutes les options disponibles. Comment ce fait-il que Windows réussisse bien (serveur FTP tout graphique) là où Linux n'a que des prétentions (fichiers de conf ou frontend mal lèché) ?

Si je voulais rester à l'ère de la ligne de commande, je n'aurais pas installé Fedora 10 mais Red Hat 4 ! Ah nan, c'est vrai, sous Linux on a des interfaces graphiques avec fenêtres flamby transparentes pour afficher le centre névralgique du système... : la console ! Ca me console pas... Sérieusement, vous êtes sûr qu'un serveur FTP tout graphique sous Linux, point de salut ? C'est pour faire de l'administration web à distance, et ça me fait ch... d'une force les lignes de commandes, à force !

Kochise

Kochise (./13) :
Boaf, les wrapper/frontend n'intègrent que ce qu'ils ont envie par rapport à l'étendue des options de la ligne de commande et/ou le font plus ou moins bien. L'avantage d'un serveur TOUT graphique, en dehors d'être plus intuitif et ergonomique (le but d'une interface graphique après tout) est de gèrer correctement toutes les options disponibles.

Tu te trompes, même les logiciels graphiques sous GNU/Linux ont souvent des options cachées dans le fichier de configuration.

GNU/Linux est très configurable et donc souvent il y a tellement d'options qu'une interface graphique qui les propose toutes serait le bordel. Enfin, il y a la philosophie KDE qui est de tout afficher (j'aime bien ça), mais aussi la philosophie GNOME qui est de ne proposer que les options essentielles, avoir quelques options cachées dans la base de données gconf et coder le reste en dur, et bien sûr la philosophie de la plupart des serveurs qui est de proposer des tonnes d'options, mais toutes dans le fichier de configuration.

Comment ce fait-il que Windows réussisse bien (serveur FTP tout graphique) là où Linux n'a que des prétentions (fichiers de conf ou frontend mal lèché) ?

Parce que pas tout le monde ne considère un serveur FTP graphique comme une réussite.

À mon avis, la bonne solution est un logiciel graphique pour la configuration et un serveur qui tourne comme un service système sans rien afficher. Les outils system-config-* correspondent tout à fait à cette attente. Une fois de plus: as-tu déjà essayé system-config-vsftpd avant de te plaindre de son caractère soi-disant inadéquat? (Mais il est vrai que les outils system-config-* ne proposent en général pas toutes les options possibles. Rien ne remplace KWrite et un bon coup de RTFM. )

Tu ne trouveras pas de serveurs graphiques parce que les admins de serveurs n'installent en général même pas X11 sur leurs serveurs, ils disent que ça ne sert à rien sur un serveur. Donc un logiciel serveur graphique ne trouverait pas grand chose comme utilisateurs.

Euuuh en fait, ce que demande Kochise existe bel et bien, mais il faut passer par un greffon webmin.
Concrètement, l'absence d'interface graphique sur un serveur est issue de la politique selon laquelle on évite d'installer plus de choses que nécessaires pour une machine devant offrir un service, afin d'éviter le plus de failles possibles. En pratique, ça marche plutôt bien (voire même carrément bien), mais ça n'est pas ce que cherchent les usagers désireux d'avoir une solution rapide à mettre en oeuvre. Cela dit, même Microsoft est en train de suivre cette voie (enfin, par vraiment en vrai, mais presque) puisque 2008 serveur permet de fonctionner sans interface graphique (ce qui n'est pas totalement vrai, puisqu'on est en console mais en mode graphique... disons que ça limite certains risques et évite de gaspiller de la ressource pour l'interface graphique).

Nil (./15) :
Euuuh en fait, ce que demande Kochise existe bel et bien, mais il faut passer par un greffon webmin.
Concrètement, l'absence d'interface graphique sur un serveur est issue de la politique selon laquelle on évite d'installer plus de choses que nécessaires pour une machine devant offrir un service, afin d'éviter le plus de failles possibles. En pratique, ça marche plutôt bien (voire même carrément bien), mais ça n'est pas ce que cherchent les usagers désireux d'avoir une solution rapide à mettre en oeuvre. Cela dit, même Microsoft est en train de suivre cette voie (enfin, par vraiment en vrai, mais presque) puisque 2008 serveur permet de fonctionner sans interface graphique (ce qui n'est pas totalement vrai, puisqu'on est en console mais en mode graphique... disons que ça limite certains risques et évite de gaspiller de la ressource pour l'interface graphique).

L'interface graphique n'est pas nécessairement sur le serveur même, hein ^^ si tu prends TitanFTP ou FileZilla Server, on peut très bien installer le serveur sans interface graphique, tout en le configurant avec une véritable interface graphique depuis une autre machine...

(et si je comprends bien, pour éviter d'installer un serveur X, on demande d'installer un serveur Apache ? )

Kevin Kofler (./12) :
Bah, la solution que je propose répond à tes besoins (du moins ceux dont tu as parlé dans le ./9).

Bah non, vu que tu crées des utilisateurs locaux alors qu'il n'y en a pas besoin...

Flanker (./16) :
(et si je comprends bien, pour éviter d'installer un serveur X, on demande d'installer un serveur Apache ? )

Bah non, normalement t'as pas besoin d'avoir un outil graphique c'est juste pour les feignasses (tiens, le dico de FF ne connait pas feignasse, mais connait feignantasse ).
Plus sérieusement, webmin ne demande pas l'installation de Apache, il est strictement autonome... donc ça revient à avoir la même chose que l'outil de Filezilla, mais "homogène" (ahah) pour tous les services.

Nil (./18) :

Flanker (./16) :
(et si je comprends bien, pour éviter d'installer un serveur X, on demande d'installer un serveur Apache ? )

Bah non, normalement t'as pas besoin d'avoir un outil graphique c'est juste pour les feignasses (tiens, le dico de FF ne connait pas feignasse, mais connait feignantasse ).

Bah pourquoi pour les feignasses ? je ne vois pas l'intérêt de perdre du temps à se taper un fichier de conf avec une syntaxe différente des autres fichiers de conf, alors qu'une interface graphique correctement fichue te permet d'avoir le même résultat bien plus rapidement

Plus sérieusement, webmin ne demande pas l'installation de Apache, il est strictement autonome... donc ça revient à avoir la même chose que l'outil de Filezilla, mais "homogène" (ahah) pour tous les services.

(pas besoin d'apache pour webmin ? je croyais que c'était des pages web ? )
Bah rien n'empêche d'avoir une interface graphique bien fichue homogène pour tous les services, hein Regarde donc celle de 2008 Server ou celle d'OS X 10.5 Server

Flanker (./19) :
(pas besoin d'apache pour webmin ? je croyais que c'était des pages web ? )

Ce sont des pages web, mais webmin embarque son propre serveur http et est régi comme un service indépendant.

Flanker (./19) :
Bah pourquoi pour les feignasses ? je ne vois pas l'intérêt de perdre du temps à se taper un fichier de conf avec une syntaxe différente des autres fichiers de conf, alors qu'une interface graphique correctement fichue te permet d'avoir le même résultat bien plus rapidement

En fait, ça c'est sujet à troll, donc je ne vais pas m'embarquer là dedans ^^. Avec de la pratique, je trouve que ça se vaut, surtout pour les applications avec énormément de paramètres (donc pour lesquels l'interface devient très lourde). en réalité, généralement, les fenêtres graphiques t'apportent la même chose que les lignes d'un fichier de conf ; les différences majeures sont
- vérification de la syntaxe au moment de la validation/de la saisie (contrebalancé par l'affichage en couleur des fichiers de conf, mais ça a ses limites)
- infobulles (ça, c'est vraiment un point fort, mais je trouve que, généralement, les infobulles n'aident pas forcément à mieux comprendre)
- limitations (dans le cas d'une interface graphique) des données saisies possibles (on ne peut pas toujours tweaker comme on veut)

Après, je suis d'accord que pour mettre rapidement en place un service, le clic est plus efficace. Mais quand il faut faire de la sécurisation ou qu'on doit faire du paramétrage fin, ça devient souvent bien plus compliqué dans le monde Windows (je suis fan des clés de registre au nom imbitable )

Nil (./20) :

Flanker (./19) :
(pas besoin d'apache pour webmin ? je croyais que c'était des pages web ? )

Ce sont des pages web, mais webmin embarque son propre serveur http et est régi comme un service indépendant.

Flanker (./19) :
Bah pourquoi pour les feignasses ? je ne vois pas l'intérêt de perdre du temps à se taper un fichier de conf avec une syntaxe différente des autres fichiers de conf, alors qu'une interface graphique correctement fichue te permet d'avoir le même résultat bien plus rapidement

En fait, ça c'est sujet à troll, donc je ne vais pas m'embarquer là dedans ^^. Avec de la pratique, je trouve que ça se vaut, surtout pour les applications avec énormément de paramètres (donc pour lesquels l'interface devient très lourde). en réalité, généralement, les fenêtres graphiques t'apportent la même chose que les lignes d'un fichier de conf ; les différences majeures sont
- vérification de la syntaxe au moment de la validation/de la saisie (contrebalancé par l'affichage en couleur des fichiers de conf, mais ça a ses limites)
- infobulles (ça, c'est vraiment un point fort, mais je trouve que, généralement, les infobulles n'aident pas forcément à mieux comprendre)
- limitations (dans le cas d'une interface graphique) des données saisies possibles (on ne peut pas toujours tweaker comme on veut)

Après, je suis d'accord que pour mettre rapidement en place un service, le clic est plus efficace. Mais quand il faut faire de la sécurisation ou qu'on doit faire du paramétrage fin, ça devient souvent bien plus compliqué dans le monde Windows (je suis fan des clés de registre au nom imbitable )

Tu oublies la génération automatique des bons paramètres (par exemple, si ton OS X est serveur LDAP, tu n'as rien à configurer pour que les serveurs s'authentifient en LDAP, il renseigne tout seul les adresses, les certificats SSL, les bases de recherches, etc... )

Flanker (./21) :
(par exemple, si ton OS X est serveur LDAP, tu n'as rien à configurer pour que les serveurs s'authentifient en LDAP, il renseigne tout seul les adresses, les certificats SSL, les bases de recherches, etc... )

Ca, dans un environnement sécurisé, c'est pas forcément un bien, ça veut dire que si ton service LDAP principal se fait hacker, les comptes du serveur le sont aussi ; ça veut dire aussi que les usagers créés peuvent se connecter directement sur le serveur. Disons que c'est tolérable dans une utilisation domestique ou machine serveur=machine cliente.
Bon, en pratique, de nombreuses distributions (Mandriva le faisait, en tout cas, je ne sais pas si ça a été conservé), au moment de l'installation on te demande où tu veux stocker les comptes locaux (shadow/passwd, LDAP local, LDAP distant...). Mais ça a dû être désactivé parce que ça posait pas mal de problèmes (quand tu dois mettre à jour ton service LDAP, ça casse des liens et les sudo se font mal, donc c'était interdit).

Nil (./22) :
Ca, dans un environnement sécurisé, c'est pas forcément un bien, ça veut dire que si ton service LDAP principal se fait hacker, les comptes du serveur le sont aussi ; ça veut dire aussi que les usagers créés peuvent se connecter directement sur le serveur. Disons que c'est tolérable dans une utilisation domestique ou machine serveur=machine cliente.
Bon, en pratique, de nombreuses distributions (Mandriva le faisait, en tout cas, je ne sais pas si ça a été conservé), au moment de l'installation on te demande où tu veux stocker les comptes locaux (shadow/passwd, LDAP local, LDAP distant...). Mais ça a dû être désactivé parce que ça posait pas mal de problèmes (quand tu dois mettre à jour ton service LDAP, ça casse des liens et les sudo se font mal, donc c'était interdit).

Euh.. t'es pas obligé de passer par LDAP (ou autre), c'est juste qu'il est capable de générer automatiquement les bons paramètres tout seul... De la même façon, il détecte tout seul les différents services sur le réseau local, si ta base LDAP est fournie par un autre OS X serveur sur le réseau local, elle te sera proposée dans la liste... Tout comme pour les certificats, tu n'as pas à t'emmerder à aller chercher les bons fichiers pem/crt/key pour chaque service (surtout si c'est les mêmes à chaque fois), tu renseignes une fois le champ kivabien et il va te permettre de le sélectionner facilement pour les autres services (et il va vérifier que les droits sont corrects sur les fichiers, accessoirement).

(valable pour Linux et certains autres Unices)

Flanker (./9) :
Bah configure SSH pour faire du SFTP avec des quota (disques, bande passante, ...)

Pour le quota disque, tu as (et c'est a mon avis le plus aproprié) des outils fourni avec l'OS directement pour faire ça pour la BP il y a des outils noyals pour ça

Flanker (./9) :
des utilisateurs authentifiés sur LDAP ou AD,

LDAP/SSH rien de plus simple (sic) -> jouer avec PAM Notre ex admin sys dans mon ex boite nous avais cassé completement certain serveurs suite a un passage a LDAP et jouage avec PAM )

Flanker (./17) :
Bah non, vu que tu crées des utilisateurs locaux alors qu'il n'y en a pas besoin...

-> VM
Les utilisateurs locaux n'ont besoin d'exister qu'à l'intérieur de la VM qui ne gère que les serveurs SCP/SFTP/FTPS/FTP.

mais quand tu ne veux pas avoir des utilisateurs locaux en plus ?

Kevin Kofler (./25) :

Flanker (./17) :
Bah non, vu que tu crées des utilisateurs locaux alors qu'il n'y en a pas besoin...

-> VM

Où est le problème? (Et cf. edit de ./25 aussi.)

Godzil (./24) :

Flanker (./9) :
des utilisateurs authentifiés sur LDAP ou AD,

LDAP/SSH rien de plus simple (sic) -> jouer avec PAM Notre ex admin sys dans mon ex boite nous avais cassé completement certain serveurs suite a un passage a LDAP et jouage avec PAM )

Oué, là, on n'a pas la même définition de "simple". PAM ça reste quand même assez lourd, surtout avec NSS.

simple était ironique dans le contexte

Ok