Tu peux effectuer ta connexion SSH, puis taper :
tcpserver 0 ftp /usr/local/sbin/pure-ftpd &
Et voilà, ton serveur FTP tourne et il n'y a aucune différence avec un "standalone".
Les super-serveurs comme tcpserver, g2s et xinetd possèdent de quoi prendre correctement en charge les connexions, maintenir des fichiers d'historique, effectuer du filtrage IP, ... Bref, tout ce qui se passe entre le moment où un client demande une connexion et celui où la session commence réellement avec le serveur.
Tout les serveurs "standalone" doivent réimplémenter tout ça. Et la configuration de ces éléments redondants se fait pourtant chaque fois d'une façon totalement différente d'un logiciel à l'autre.
Pure-FTPd n'a actuellement pas de mode "standalone" pour cette raison : il doit rester simple, petit, et se concentrer sur le protocole FTP et non la négociations des connexions, que d'autres logiciels font très bien. Si je commence à y ajouter la gestion de bases de données CDB (pour le filtrage IP, comme TCPServer), on va obtenir un produit plus lourd. Et ceux qui n'utilisent pas le filtrage en subiraient quand meme les conséquences.
Et même au niveau sécurité, c'est intéressant de séparer chaque tâche. Ainsi, g2s/xinetd/tcpserver/rlinetd/etc... sont audités de leur coté, et les serveurs qu'ils lancent, d'un autre côté. Si un bug ou une faille de sécurité se produit, on ne perd pas de temps à la localiser ("zut, ça a planté... il y a un D.O.S... est-ce-qu'il vient des fonctions qui acceptent les connexions TCP et du filtrage IP ? Est-ce dans les fonctions qui demandent le login du client FTP ?" - Le problème ne se pose pas si ces parties sont séparées) .
D'autre part... Avoir un mode "standalone" pour des logiciels comme Apache et Proftpd est intéressant car ils possèdent un fichier de configuration avec une syntaxe complexe. Le déchiffrer prend du temps. S'il faut le déchiffrer à chaque fois qu'un client se connecte (en mode non-standalone), c'est forcément plus lent que si ces fichiers sont analysés une fois pour toutes.
Maintenant, dans le cas de Pure-FTPd, le démarrage est immédiat : les options sont en ligne de commande, le cache des uid/gid se construit dynamiquement, et les serveurs virtuels ne sont détectés que s'ils sont réellement utilisés. Donc lancer Pure-FTPd en standalone ou à partir d'un super-serveur revient sensiblement au même pour les performances.
Cela dit, il y aura peut-etre effectivement un mode standalone avant la version 1.0, mais uniquement pour avoir une architecture encore plus blindée niveau sécurité. En gros, il y aura un "serveur de bind" qui n'aura aucune capacité (au sens des "capabilities" du noyau Linux) si ce n'est celle d'ouvrir des connexions sur des ports privilégiés et de passer les descripteurs au réel serveur. Résultat : *aucune* partie du serveur ne tournera sous l'identité "root" (la cause de tous les soucis des autres logiciels) .
[^] # Re: Pure-FTPd
Posté par j . En réponse à la dépêche Un virus attaque les machines RedHat. Évalué à 1.
tcpserver 0 ftp /usr/local/sbin/pure-ftpd &
Et voilà, ton serveur FTP tourne et il n'y a aucune différence avec un "standalone".
Les super-serveurs comme tcpserver, g2s et xinetd possèdent de quoi prendre correctement en charge les connexions, maintenir des fichiers d'historique, effectuer du filtrage IP, ... Bref, tout ce qui se passe entre le moment où un client demande une connexion et celui où la session commence réellement avec le serveur.
Tout les serveurs "standalone" doivent réimplémenter tout ça. Et la configuration de ces éléments redondants se fait pourtant chaque fois d'une façon totalement différente d'un logiciel à l'autre.
Pure-FTPd n'a actuellement pas de mode "standalone" pour cette raison : il doit rester simple, petit, et se concentrer sur le protocole FTP et non la négociations des connexions, que d'autres logiciels font très bien. Si je commence à y ajouter la gestion de bases de données CDB (pour le filtrage IP, comme TCPServer), on va obtenir un produit plus lourd. Et ceux qui n'utilisent pas le filtrage en subiraient quand meme les conséquences.
Et même au niveau sécurité, c'est intéressant de séparer chaque tâche. Ainsi, g2s/xinetd/tcpserver/rlinetd/etc... sont audités de leur coté, et les serveurs qu'ils lancent, d'un autre côté. Si un bug ou une faille de sécurité se produit, on ne perd pas de temps à la localiser ("zut, ça a planté... il y a un D.O.S... est-ce-qu'il vient des fonctions qui acceptent les connexions TCP et du filtrage IP ? Est-ce dans les fonctions qui demandent le login du client FTP ?" - Le problème ne se pose pas si ces parties sont séparées) .
D'autre part... Avoir un mode "standalone" pour des logiciels comme Apache et Proftpd est intéressant car ils possèdent un fichier de configuration avec une syntaxe complexe. Le déchiffrer prend du temps. S'il faut le déchiffrer à chaque fois qu'un client se connecte (en mode non-standalone), c'est forcément plus lent que si ces fichiers sont analysés une fois pour toutes.
Maintenant, dans le cas de Pure-FTPd, le démarrage est immédiat : les options sont en ligne de commande, le cache des uid/gid se construit dynamiquement, et les serveurs virtuels ne sont détectés que s'ils sont réellement utilisés. Donc lancer Pure-FTPd en standalone ou à partir d'un super-serveur revient sensiblement au même pour les performances.
Cela dit, il y aura peut-etre effectivement un mode standalone avant la version 1.0, mais uniquement pour avoir une architecture encore plus blindée niveau sécurité. En gros, il y aura un "serveur de bind" qui n'aura aucune capacité (au sens des "capabilities" du noyau Linux) si ce n'est celle d'ouvrir des connexions sur des ports privilégiés et de passer les descripteurs au réel serveur. Résultat : *aucune* partie du serveur ne tournera sous l'identité "root" (la cause de tous les soucis des autres logiciels) .