Nous avons recemment migré un serveur de fichier sur un SAN (NETapp).
Le tout est redirigé par DFS. La redirection s’exprime de cette façon “\serveur\dossier” et a partir de la ça va sur le SAN.
Mon problème c’est qu’un serveur FTP (WarFTPD Freeware) etait installé par notre client et permettait a des users d’aller trafiquer par FTP des fichiers se trouvant sur les DD du serveur (I:\dossier).
Le problème c’est que ces fichiers ne sont plus sur les DD du serveur maintenant mais sur ceux du SAN. Et on y accede par le DFS en utilisant des chemins UNC (\serveur\dossier\ pointe directement sur le SAN grace a DFS) mais malheureusement, je n’arrive pas a déclarer de chemin de type UNC dans les paramètres FTP de WarFTPD. Je peux bien sûr ajouter \serveur\dossier dans les files acces mais cela ne marche pas. Impossible apres la connexion d’acceder au Root.
Avez vous une idée pour faire fonctionner cela ?
La solution qui fonctionne consiste a mapper un lecteur pointant sur le chemin UNC. Mais malheureusement, un lecteur ne se mappe qu’après la connexion d’un user et que je ne veux pas de cela et que le serveur FTP est lancé comme service.
Sous windows il est normalement possible de declarer des lecteurs virtuels “reseau”, dans le cas ou sa serait possible avec le SAN, declare par exemple un lecteur K: qui pointe vers “//server/dossier”.
Et regle ton démon FTP pour aller sur “K:” et si tout se passe bien le noyau fera sa cuisine interne pour aller sur le serveur.
C’est ce que j’ai fait pour mes sauvegardes automatique (j’ai pas un SAN non plus quand meme B))
[quote=« Le_K, post:4, topic: 32392 »]Sous windows il est normalement possible de declarer des lecteurs virtuels « reseau », dans le cas ou sa serait possible avec le SAN, declare par exemple un lecteur K: qui pointe vers « //server/dossier ».
mais quid : les personnes utilisant le ftp ne sont pas hors reseau en se connectant en VPN dans le reseau d’entreprise ( voila pkoi le ftp de ma question)
Ils sont assis dans leur chaise.
en gros c’est dans le script qu’il se connecte.
dans le script il se connectait donc au C$ du serveur.
Pkoi dans le script tu ne rajoute pas un net use sur le repertoire dont ils ont besoin et le deconnecte à la fin ?
Car en gros tu veux que le server FTP reconnaisse le DFS, ca va etre dur à gerer.
Il y a surement un autre moyen, plus « windows inside » de le faire.
Notres client avait un serveur qui hébergait des fichiers sur un de ses disques qui faisait tourner un serveur FTP.
Ils ont un AS400 et un serveur Unix qui sont en WAN et qui produisent des fichiers de stat au format csv et qu’ils plaçaient sur le serveur de fichier par l’intermédiaire du FTP. Les utilisateur AD pouvaient ensuite aller consulter les fichiers en question déposés dans un dossier réseau.
Le changement, c’est que le client nous a fait installer un SAN (une unité de stockage réseau autonome, un IBM NETapp) sur lequel nous avons basculé les données du serveur de fichiers. Pour éviter de perturber les machines clientes, nous avons monté un DFS qui redirige les machines sur le SAN quand elles font appel a \serveur\dossier. Le probleme, c’est que le serveur FTP ne peut enregistrer les données que sur un disque local a la machine et pas un disque réseau d’ou notre problème pour rediriger cela sur le SAN.
Les machines qui viennent déposer des fichiers sur le FTP ne sont pas de type Windows et nous n’avons pas l’administration de celle-ci. Donc pas question de monter un Samba sur le Linux ni un accès pour l’AS400. Le FTP marchait tres bien.
J’espère m’être fait mieux comprendre B)
En gros comment demander a un serveur FTP de faire pointer son root sur un support réseau (\serveur\dossier) et pas sur un disque local (I:)
La solution qui consiste a mapper le dit chemin réseau sur une lettre de l’explorateur (Z: = \serveur\dossier) fonctionne mais n’est pas viable vu que le serveur FTP fonctionne en tant que service et qu’il n’est pas question d’avoir la console logué sous un user pour mapper ce lecteur.
En se qui concerne la modification d’un quelconque script, elle n’a pas lieu d’être vu qu’il n’y en a pas. Seules les machines étrangères utilisent un script du genre
FTP
Open Serveur login mdp
Cd /root/Dossier
Put ./dossier/truc.csv
bye
Donc pas possible de faire un Net use z: \serveur\dossier a aucun moment.
Utilisateurs mappaient
\serveur\dossier\FTP et Serveur partageait I:\Dossier
Le serveur FTP pointait son root sur I:\dossier\FTP
Maintenant avec le Netapp
DFS -> \serveur\dossier => \Netapp\dossier
donc les utilisateurs font toujours
\serveur\dossier\FTP mais se retrouvent réelement (et de façon transparente pour eux) sur \Netapp\dossier\FTP
Par contre le serveur FTP lui continu a pointer sur I:\dossier\FTP (que les utilisateurs ne voient plus car redirigé sur le SAN) et impossible de lui dire que le root est maintenant \serveur\dossier (en utilisant le DFS) ou \Netapp\dossier (en vrai)…
Si je comprends bien, c’est le serveur FTP qui ne sait pas gerer autre chose que des lecteurs locaux.
Peut etre changer de logiciel serveur FTP ???
Et ton histoire de server FTP en tant que service.
As tu testé par gpo à" l’ouverture de l’ordinateur" de mapper un lecteur ?
J’avoue ca parait peu propable mais qui sait, ca peut peut etre marché.
Et donc pas de user connecté.
Ben j’ai trouvé un logiciel serveur FTP XLight FTP, tout léger et tout beau, qui sait mapper des lecteur virtuel réseau. Du coup bah ca marche nickel chrome et ça prend même en compte le DFS… que demander de mieux ??
Ha ben si c’est freeware (enfin ya des limitations mais elles me conviennent)