A priori, ce serait une bonne piste, le système de gestion de tickets par rapport à ton besoin.
Il faudra s'adapter aux concepts propres à l'outil (rôle, groupe, ...) et jongler avec la terminologie (ouvert, attribué, clôt, ...) ;-)
Pour info, j'ai pratiqué WREQ [http://www.math.duke.edu/~yu/wreq/] dans une précédente mission et il est assez simple (spartiate ? non il est efficace ^__^ !).
Pour un panel des outils actuels disponibles, un tour sur [http://freshmeat.net] est un bon point de départ.
Posté par Steve Azriel .
En réponse au message lftp.
Évalué à 5.
Bonjour,
Je pense que ton script pourrait fonctionner en changeant les les appostrophes "simples" ' en guillemets " au niveau de l'appel à lftp, pour que le shell évalue le contenu, soit:
lftp zbla:zbla@ftpperso.free.fr -e "cd lj/window-root/; put ~/tmp/$FILE; exit"
Bon courage !
Cdlt,
NB: J'éviterais d'utiliser des caractères "spéciaux" (espaces, accents, ...) parce que je ne suis pas sûr que cela fonctionne.
La solution décrite dans ce document est très proche du commentaire de "Mickaël L" [https://linuxfr.org/comments/917689.html#917689] et utilise les accolades pour entourer la lettre accentuée (malheureusement je n'ai pas le contexte des packages utilisés pour le faire).
J'ai trouvé un document qui semble répondre à ta demande (plutôt failover que load balancing) et ce, de manière assez (voir trop ^__^) simple: Using a Linux failover router [http://www.linux.com/articles/113988]
En fait, il s'agit de mettre 2 passerelles par défaut et de "tunner" un des temporisateurs pour accélérer la bascule :-)
Sinon et pour info, il faudrait t'assurer que tu n'aits pas un routage asymétrique au niveau de ton serveur (entrée via une interface et sortie via l'autre 8-S). C'est pas obligatoire (je m'avance peut-être un peu là), mais cela peut te faciliter l'exploitation par la suite.
Bon courage !
Cdlt,
PS: Pourrais-tu regarder ta table de routage (netstat -rn ou équivalent) par rapport à tes tests sur les 2 eth* ?
Il s'agit de celle dans le cas "nominal" de départ, ie avant de couper quoi que ce soit.
Juste par pur curiosité (par exemple en message privé)
Comme le souligne fosco dans son commentaire ([https://linuxfr.org/comments/913936.html#913936]), il faut bien décorréler l'export NFS des ressources par rapport aux différents montages (locaux ou distants).
Autrement dit, le fait d'exporter /home en NFS au niveau de B n'est pas lié au montage de la ressource /home/toto en CIFS depuis A sur B.
Ainsi, tu constates que le répertoire /home/toto est vide sur C car seule la ressource /home est exportée depuis B et elle ne contient qu'un répertoire vide pour /home/toto.
Es-tu "contraint" d'utiliser NFS au niveau de ton serveur B ?
En CIFS (Samba) sur B, cela pourrait (à tester) fonctionner.
Voici quelques petits points sur tes scripts:
1) Pour sécuriser un peu plus l'application des chown, je t'invite à utiliser l'apostrophe ' plutôt que le guillemet " pour encadrer les noms des fichiers car le shell (type BaSH) a une légère tendance à regarder dedans (entre les ") pour évaluer ce qu'il peut y trouver (un caractère spécial '!', '*', ...)
2) Quid si lorsque tu exécutes le script de restauration des droits (celui avec les chown), il y a des erreurs d'exécution (chown peut échouer même en root) ?
En effet, le script indique toujours une fin "avec succès" (en passant, quel bonheur ^__^) ?
J'avais pas vu que l'on pouvait avoir ce type de problématique avec un Zip (je croyais naïvement que c'était considéré comme un lecteur "amovible" tant au niveau de linux qu'au niveau du bios ?!?).
En creusant un peu plus mes recherches, j'ai trouvé une petite documentation chez Ubuntu [https://help.ubuntu.com/community/IomegaZIPDrive] qui parle de udev et surtout qui utilise une "convention" pour le partitionnement (tout en 4ème position ^__^).
Imagines que tu partitionnes tes Zip en ext3 (partition n°1) et que tu soit amené à utiliser (ponctuellement) un Zip vfat "standard ie d'origine" (partiton n°4).
=> Est-ce que tu pourrais échanger de Zip (un ext3 en un vfat) ?
(la table de partition lue au boot sur le Zip ext3 serait incompatible avec la table du Zip vfat)
Si à l'occasion, tu tentes l'expérience, ça m'interesserait d'avoir l'info :-)
Cdlt,
PS: Bien sûr, tu pourrais aussi lui régler son compte en le reformattant comme il faut, mais pour transporter des données, le type vfat reste un bon candidat ^__^
Voici une petit document qui pourrait t'aider : Zip Drive Mini-HOWTO disponible, par exemple, sur TLDP
[http://www.tldp.org/HOWTO/ZIP-Drive.html]
Plus particulièrement, la section "Using the ZIP drive"
A priori, tu utilises rsyncd sans passer par un remote shell (type ssh) ou si tu préfères en direct tel n'importe quel autre service.
Le serveur rsyncd tourne sous l'identité que tu fixes dans le fichier /etc/rsyncd.conf via les paramètres uid et gid ou par défaut sous l'identité: nobody:nogroup (ou équivalent sur ton OS).
Peux-tu vérifier que, sur le serveur (192.168.X.X), les fichiers sont bien présents dans l'aborescence du module "portable" avec les bons droits d'accès mais avec pour identité nobody:nogroup ?
La restauration en mode preserve se base sur le référentiel du serveur qui est alors nobody:nogroup
=> cela correspond bien à ce que tu obtiens à l'arrivé sur ton portable.
Une autre piste serait d'abandonner le service rsyncd pour utiliser rsync+ssh (ou toute autre combinaison du type rsync+remote shell) avec pour contrainte d'avoir les mêmes utilisateurs de part et d'autre (client / serveur) ou une convention (monlogin sur le portable <-> loginbackup sur le serveur rsync). Un système de clés partagés (cas de ssh) pourra te faciliter l'automatisation.
Il y a un projet nommé GSMLib [http://www.pxh.de/fs/gsmlib/index.html] (et même un peu plus en allant dans "Home") qui offre quelques outils pour manipuler un GSM.
De mon côté, j'ai eu une idée pour toi et tes clients en échec: un accès Web à ton serveur FTP !
A priori, tu devrais rencontrer moins de problème dans la mesure où les flux Web (http, https) sont plus courants que les flux FTP :-)
Par exemple:
¤ net2ftp [http://www.net2ftp.com]
¤ web-ftp [http://web-ftp.sf.net/]
En espérant que tu puisses rapidement dire:
scoubi38: Quiescence reached :-)
Malheureusement, sans avoir la main sur le réseau de ton client, tu ne pourras que tester des cas particuliers qui fonctionnent chez certains et pas chez d'autres :( !
Ton objectif étant d'offrir un service FTP Passif à un ensemble de clients.
A priori, de ton côté, tu as fait le nécessaire (routage, flux, service).
=> Si cela est possible, il faudrait peut-être "formaliser" ton service avec, pour chaque client (en échec ou non), une demande explicite d'ouverture de flux de type FTP (Passif) à destination de ton serveur.
Après, tu réalises une petite "recette" telle que celle que nous (tu) avons(as) faite et qui a montré que le client en échec [voir ci-dessus]:
1) accède bien à ton serveur FTP pour le canal de controle (port 21)
2) échoue dans l'établissement du canal data sur un port dans le range [50000, 55000].
1) Lignes 1 à 3
Il y a le début de la connexion vers le serveur FTP (séquence SYN, SYN+ACK, ACK)
=> Les deux clients se connectent bien au serveur sans problème mais on le savait déjà ;-)
2) Lignes 4 à 24
Même dialogue pour les deux clients qui poursuivent l'avancement de la session FTP (authentification, message du jour, ...)
=> Jusqu'ici ça va ! :-) NB: Le masquage des informations "sensibles" n'est pas complet ^__^ (cf Lignes 8+9 du client 2)
3) Lignes ABSENTES
Il manque la séquence TCP { SYN, SYN+ACK, ACK } pour l'ouverture de la connexion sur le port donné par le serveur ?!?
=> Cette séquence est équivalente à celle de départ (cf point n°1), sauf que la destination est l'adresse IP du serveur et un port dans l'intervalle [50000, 55000] NB: Serait-ce du au fait que tu ais appliqué un filtre sur l'écoute réseau du type "port 21" ? Cela pourrait expliquer pourquoi on ne voit pas tous les échanges liés au protocole FTP Passif.
4.a) Ligne 25 du client 1
Le client aurait détecté un dépassement de timeout (env 50 secondes) lors de sa tentative de mise en relation passive avec le serveur FTP et initie une fin de connexion via le flag TCP ReSeT.
=> Je pense que le serveur a du lui répondre positivement.
4.b) Lignes 25 à 27 du client 2
Evénements d'informations échangés sur le canal de contrôle ouvert préalablement en 1 signalant aucune erreur particulière :-)
=> Comme tu l'as si bien résumé, nous ne voyons pas les raisons de l'échec du client 1.
Pourrais tu lever le doute sur ma question soulevée au point n°3 concernant un éventuel filtre type "port 21" ?
Si tel est le cas, il faudrait recommencer la trace en utilisant un filtre plus adapté pour ce type de protocole qu'est FTP, comme "host X.X.X.X" où X.X.X.X est l'adresse IP du client.
Il ne sera pas nécessaire d'avoir les messages déjà analysés mais bien regarder ce qui se passe à partir de l'entrée en mode Passif (point n°3).
Bon courage !
Cdlt,
PS: Dernière petite question, la trace a lieu à quel niveau ? Sur le serveur lui-même ?
[mode=blabla]
D'après les traces applicatives que tu donnes, le serveur ProFTPD ne semble pas faire pas de distinction par rapport aux clients potentiels (par exemple avec des ACLs au niveau des commandes disponibles ou autre).
En outre, un client en échec sur ton serveur FTP, ne l'est pas sur un autre serveur FTP (ovh?) dans un mode opératoire semblable (même application + même configuration de l'application [même mode de transfert passif]).
Côté serveur, a priori, il ne devrait pas y avoir de filtrage concernant ProFTPD (notamment par le fait que des clients différents arrivent à utiliser pleinement le service FTP).
Côté client, il semblerait (oui, c'est bien une hypothèse) bien que les flux sortant à destination de ton serveur (@IP=195.X.Y.Z) pour le range de ports définit [50000-55000] ne soit pas autorisé...
... mais à quel niveau (directement sur le poste client via son firewall personnel, sur le firewall au niveau de la sortie internet du client, ...)
[/mode=blabla]
En l'état, je te suggère, dans la mesure du possible, de réaliser une trace réseau, au plus proche de l'extrémité entrante d'internet du côté de ton serveur FTP.
Un telnet depuis le poste client vers ton serveur FTP sur un des ports du range [50000, 55000] devrait (encore une hypothèse, désolé !) au moins arriver jusqu'à l'entrée de ton réseau et sera traitée conformément à la politique de sécurité/filtrage (drop ou return reset ou autre).
A moins qu'il y ait une corrélation entre les différents clients (en échec, ou en succès comme par exemple, un regroupement par FAI ou par version OS), il serait peut-être intéressant de faire une petite trace réseau (wireshark ou tcpdump ^__^) de part et d'autre (client & serveur).
Est-ce que la commande "PASV" envoyée par l'un des clients en échec obtient-elle une réponse semblable (227 - Entering in Passive Mode (@IP, Port_Part1, Port_Part2) à celle d'un client OK ? En particulier, au niveau IP mais aussi numéro de port (conformité entre le range de IP+ports ouvert côté firewall et côté ProFTPD [entre autre, le paramètre PassivePorts] ?
Il y aurait à voir aussi du côté de l'utilisation ou non du(des) module(s) "ip_nat_ftp/ip_conntrack_ftp".
Sinon, la trace réseau reste un bon moyen de comprendre le comportement du client et de ses échanges avec le serveur surtout dans ce type de problématique.
Le fichier temporaire créé via mktemp sert à stocker (temporairement) la sortie de la commande, pour laquelle aucun traitement immédiat n'est nécessaire.
Ainsi, après avoir "redirigé" les écritures sur 2(stderr) vers là où est écrit la sortie 1(stdout), tu peux faire de même en envoyant 1(stdout) vers le fichier temporaire.
L'important est de conserver l'ordre des redirections sinon ca ne fait pas ce que l'on souhaite :-)
Une fois que la commande est terminée et que write_log a fini, tu peux lire le contenu du fichier temporaire pour le charger dans une variable (dans ton exemple initial, il s'agissait de TAR).
En espérant avoir pu éclaircir les dernières ambigüités de mon premier commentaire ^__^
Bon courage !
Cdlt,
PS: Pour donner une solution à ton problème, voici le code que je propose et qui utilise un "wrapper" (A TESTER !).
Par avance, je vous remercie pour votre indulgence:
# Les constantes
# HOSTNAME - Nom de la machine
declare -r HOSTNAME="${HOSTNAME:-$(hostname)}"
function execute_et_log_stderr {
# Argument 1: Le fichier de log ou /dev/null :-)
local -r log_stderr="${1:-/dev/null}"
shift
# Une ressource temporaire pour stdout
local -r cmd_stdout=$(mktemp -q)
if [ ${?} -ne 0 ]; then
echo Impossible d"'"allouer une ressource temporaire '!'
return 255
fi
${@} 2>&1 1>"${cmd_stdout}" \
| while read cmd_stderr; do
echo "$(date +%b" "%d" "%T) ${HOSTNAME} backupeur[$$]: ligne :${cmd_stderr}"
done >> ${log_stderr}
cat ${cmd_stdout} && rm -f ${cmd_stdout}
return 0
}
# La pas de log de stderr
SANS_LOG=$(execute_et_log_stderr "" ls -al /home)
# La, il y aura log de stderr dans ${LOGFILE}
LOG_FILE=/var/log/backupeur
AVEC_LOG=$(execute_et_log_stderr "${LOGFILE}" tar -czf /tmp/net.tar.gz /ne)
PS2: Tiens, je revois presque le code proposé à mon premier post :P
PS3: Promis, j'arrête ! C'est mon dernier post sur cette demande (H)
D'où mon idée "à l'envers" pour traiter ton problème :-)
Après moult relectures (et à tête reposée), je n'ai pas été assez "clair" dans mon explication :/
Voici ce que je te propose pour une commande lancée avec les bonnes redirections (cf message précédent) :
1) lire les logs stderr "au fil de l'eau" pour les formatter comme bon te semble via une boucle while read
2) renvoyer la sortie stdout (qui liste les fichiers archivés dans le tar) dans un fichier (temporaire).
=> Ainsi, tu formatteras chaque ligne d'erreur de la commande avec l'ajout du timestamp "au plus proche" de l'arrivé du message.
Ensuite, tu récupères la liste des fichiers dans ta variable shell pour faire ton traitement dessus.
[humour]
Bien sûr, je ne peux te certifier de la précision de l'horodatage des messages car je n'ai pas prise sur l'ordonnancement des processus de ton serveur ^__^, mais, à priori, dans des conditions normales, cela devrait convenir :-)
... (à suivre)
[/humour]
Bon courage !
Cdlt,
[humour]
... (suite)
PS: Si tu veux assurer un peu plus de précision, voici des pistes:
1) augmenter virtuellement la priorité de ton shell en diminuant la priorité de la commande tar (man nice)
Par exemple: nice -n 19 tar ... | while read
2) passer à un Linux Temps Réel
[/humour]
Je verrais bien une solution "à l'envers" à ton problème :P
Comme tu n'as pas forcément besoin immédiatement de la sortie de la commande tar pour tes logs, c'est celle-ci que j'enverrais dans un fichier temporaire.
Après, il suffit de lire les messages stderr et de les formatter comme bon te semble.
Voici ce que cela donnerait (à tester !):
# Je crée un fichier temporaire
sortie_de_tar=$(mktemp -q)
if [ ${?} -ne 0 ]; then
echo Pas de bol '!'
fi
# Je lance l'archivage (attention a l'ordre des redirections !)
tar -czvf /home/MonHome.tar.gz /tmp/ 2>&1 >"${sortie_de_tar}" \
| while read ligne_erreur; do
# Ici, formattage de la ligne
echo $(date) $(hostname) ${ligne_erreur} >> "${LOGDIR}"
done
# Après, soit:
TAR=$(< "${sortie_de_tar}")
# ou
TAR=$(cat "${sortie_de_tar}")
...
Name Server: NS17.ZONEEDIT.COM
Name Server: NS2.ZONEEDIT.COM
...
=> Identifier les "Name Servers" qui vont bien :-)
2) dig 11vm-serv.net
...
;; ANSWER SECTION:
11vm-serv.net. 42956 IN A 91.121.12.176
;; AUTHORITY SECTION:
11vm-serv.net. 43066 IN NS ns2.zoneedit.com.
11vm-serv.net. 43066 IN NS ns17.zoneedit.com.
11vm-serv.net. 43066 IN NS dns.11vm-serv.net.
;; ADDITIONAL SECTION:
dns.11vm-serv.net. 42957 IN A 91.121.12.176
ns2.zoneedit.com. 1025 IN A 69.72.158.226
ns17.zoneedit.com. 956 IN A 209.126.159.118
...
=> Le résultat correspond bien avec l'entrée whois (au niveau DNS)
sauf qu'on remarque l'apparition "en plus" de "dns.11vm-serv.net".
La résolution DNS semble à ce niveau OK.
3) dig fcojean.11vm-serv.net
...
;; ANSWER SECTION:
fcojean.11vm-serv.net. 85987 IN A 127.0.0.1
;; AUTHORITY SECTION:
fcojean.11vm-serv.net. 85987 IN NS ns.fcojean.11vm-serv.net.
;; ADDITIONAL SECTION:
ns.fcojean.11vm-serv.net. 85987 IN A 127.0.0.1
...
=> Le résultat est étonnant car il n'y a plus aucun des 3 DNS vu au n°2 et il y a l'apparition de "ns.fcojean.11vm-serv.net" avec pour adresse 127.0.0.1 !
La résolution DNS ne me paraît pas celle souhaitée à ce niveau (elle "fonctionne", mais pas comme il faudrait ?)
4.a) dig fcojean.11vm-serv.net @ns2.zoneedit.com
...
;; ANSWER SECTION:
fcojean.11vm-serv.net. 43200 IN CNAME host.11vm-serv.net.
;; AUTHORITY SECTION:
11vm-serv.net. 43200 IN NS ns2.zoneedit.com.
11vm-serv.net. 43200 IN NS ns17.zoneedit.com.
11vm-serv.net. 43200 IN NS dns.11vm-serv.net.
...
=> Je suppose que c'est le résultat attendu car host.11vm-serv.net a pour résolution DNS, l'adresse IP 91.121.12.176
4.b) dig fcojean.11vm-serv.net @ns17.zoneedit.com
(même résultat que 4.a)
4.c) dig fcojean.11vm-serv.net @dns.11vm-serv.net
(même résultat que 3 !)
=> Pourrais-tu jetter un oeil sur ta configuration DNS "local" (à priori du côté de dns.11vm-serv.net) ainsi que sur ZoneEdit.Com pour vérfier leur cohérence (paramétrage, transferts & co) ?
Il se pourrait que ton problème de résolution DNS soit lié avec le delta constaté dans la résolution DNS (voir n°3 & n°4.*).
Je rajouterais bien une vérification au niveau du DNS pour la résolution inverse ce qui peut ralentir l'établissement de la connexion en SSH.
Pour cela, un moyen de tester consiste à rajouter [temporairement] une entrée dans le fichier /etc/hosts avec ton adresse IP de connexion (avec peut-être une relance du service ssh ?) et retenter une connexion...
Sinon, un peu en vrac:
1) la configuration (speed, duplex, autonegociation, ...) et les statistiques (ifconfig, netstat, ...) des interfaces réseaux pour identifier éventuellement des collisions/erreurs
2) la configuration (par exemple configuration ATA0[Petite Tortue] au lieu de ATA7 [Petite Tortue Boostée], ...) et les statistiques (iostats & co) des disques durs en usage lors des transferts.
J'ai rencontré un problème identique sur mon portable Acer (modèle Aspire 5562) qui s'arrêtait brutalement, à priori par protection à cause de la chaleur atteinte et ce, quelque soit le système d'exploitation.
Le redémarrer le fait quasiment aussitôt arrêter car il est encore bien chaud et n'a pas eu le temps de refroidir...
=> Aller/retour SAV Acer (une quinzaine de jours) pour le retrouver à nouveau.
Pour peu que ce soit une panne matérielle (par exemple un ventillo qui ne réagit plus...), il serait intéressant de ne pas passer à côté et de laisser passer la (précieuse) garantie :/.
En outre, pourrais-tu faire un delta de "ssh -vv" (cf post de Barnabé [https://linuxfr.org/comments/895806.html#895806]) entre une connexion OK et une NOK à partir de la même source (pour avoir le même paramétrage côté initiateur de la connexion) ?
Enfin, pour compléter ma (longue) demande, pourrais-tu jeter un oeil sur le diff des configurations serveur (/etc/ssh/sshd_config ou autre) associé aux tests précédents afin de lever un doute sur le paramétrage côté serveur (voir [http://ubuntuforums.org/archive/index.php/t-7842.html]).
Merci d'avance & Bon Courage !
Cdlt,
PS: Merci à tous les autres posts pour leurs suggestions & leurs remarques :-)
[^] # Re: Système de tickets
Posté par Steve Azriel . En réponse au message Webmail spécial. Évalué à 1.
A priori, ce serait une bonne piste, le système de gestion de tickets par rapport à ton besoin.
Il faudra s'adapter aux concepts propres à l'outil (rôle, groupe, ...) et jongler avec la terminologie (ouvert, attribué, clôt, ...) ;-)
Pour info, j'ai pratiqué WREQ [http://www.math.duke.edu/~yu/wreq/] dans une précédente mission et il est assez simple (spartiate ? non il est efficace ^__^ !).
Pour un panel des outils actuels disponibles, un tour sur [http://freshmeat.net] est un bon point de départ.
Bon courage !
Cdlt,
# Changer les appostrophes "simples" en guillemets
Posté par Steve Azriel . En réponse au message lftp. Évalué à 5.
Je pense que ton script pourrait fonctionner en changeant les les appostrophes "simples" ' en guillemets " au niveau de l'appel à lftp, pour que le shell évalue le contenu, soit:
lftp zbla:zbla@ftpperso.free.fr -e "cd lj/window-root/; put ~/tmp/$FILE; exit"
Bon courage !
Cdlt,
NB: J'éviterais d'utiliser des caractères "spéciaux" (espaces, accents, ...) parce que je ne suis pas sûr que cela fonctionne.
# Une piste ...
Posté par Steve Azriel . En réponse au message caractères accentué, lettrine, et LaTeX. Évalué à 3.
J'ai trouvé cette petite doc via Google:
[http://www.tug.org/teTeX/tetex-texmfdist/doc/latex/lettrine/(...)]
La solution décrite dans ce document est très proche du commentaire de "Mickaël L" [https://linuxfr.org/comments/917689.html#917689] et utilise les accolades pour entourer la lettre accentuée (malheureusement je n'ai pas le contexte des packages utilisés pour le faire).
Bonne Lecture & Bon Courage !
Cdlt,
# Ou alors :-)
Posté par Steve Azriel . En réponse au message 2 ip de 2 operateurs sur 2 cartes reseau. Évalué à 1.
J'ai trouvé un document qui semble répondre à ta demande (plutôt failover que load balancing) et ce, de manière assez (voir trop ^__^) simple:
Using a Linux failover router [http://www.linux.com/articles/113988]
En fait, il s'agit de mettre 2 passerelles par défaut et de "tunner" un des temporisateurs pour accélérer la bascule :-)
Sinon et pour info, il faudrait t'assurer que tu n'aits pas un routage asymétrique au niveau de ton serveur (entrée via une interface et sortie via l'autre 8-S). C'est pas obligatoire (je m'avance peut-être un peu là), mais cela peut te faciliter l'exploitation par la suite.
Bon courage !
Cdlt,
PS: Pourrais-tu regarder ta table de routage (netstat -rn ou équivalent) par rapport à tes tests sur les 2 eth* ?
Il s'agit de celle dans le cas "nominal" de départ, ie avant de couper quoi que ce soit.
Juste par pur curiosité (par exemple en message privé)
# Je ne crois pas que cela soit possible...
Posté par Steve Azriel . En réponse au message problème montage CIFS/NFS. Évalué à 1.
A l'instar de CIFS (du moins via Samba), je ne crois pas que le partage de ressources par "rebond" soit possible en NFS (cf [http://fixunix.com/nfs/61772-nfs-exporting-samba-share.html]).
Comme le souligne fosco dans son commentaire ([https://linuxfr.org/comments/913936.html#913936]), il faut bien décorréler l'export NFS des ressources par rapport aux différents montages (locaux ou distants).
Autrement dit, le fait d'exporter /home en NFS au niveau de B n'est pas lié au montage de la ressource /home/toto en CIFS depuis A sur B.
Ainsi, tu constates que le répertoire /home/toto est vide sur C car seule la ressource /home est exportée depuis B et elle ne contient qu'un répertoire vide pour /home/toto.
Es-tu "contraint" d'utiliser NFS au niveau de ton serveur B ?
En CIFS (Samba) sur B, cela pourrait (à tester) fonctionner.
Bon courage !
Cdlt,
[^] # Re: Solutions alternatives
Posté par Steve Azriel . En réponse au message Rsync : restaurer une sauvegarde. Évalué à 1.
Voici quelques petits points sur tes scripts:
1) Pour sécuriser un peu plus l'application des chown, je t'invite à utiliser l'apostrophe ' plutôt que le guillemet " pour encadrer les noms des fichiers car le shell (type BaSH) a une légère tendance à regarder dedans (entre les ") pour évaluer ce qu'il peut y trouver (un caractère spécial '!', '*', ...)
2) Quid si lorsque tu exécutes le script de restauration des droits (celui avec les chown), il y a des erreurs d'exécution (chown peut échouer même en root) ?
En effet, le script indique toujours une fin "avec succès" (en passant, quel bonheur ^__^) ?
Cdlt,
[^] # Re: Un p'tit Comment-Faire...
Posté par Steve Azriel . En réponse au message Formater disquette Zip. Évalué à 1.
J'avais pas vu que l'on pouvait avoir ce type de problématique avec un Zip (je croyais naïvement que c'était considéré comme un lecteur "amovible" tant au niveau de linux qu'au niveau du bios ?!?).
En creusant un peu plus mes recherches, j'ai trouvé une petite documentation chez Ubuntu [https://help.ubuntu.com/community/IomegaZIPDrive] qui parle de udev et surtout qui utilise une "convention" pour le partitionnement (tout en 4ème position ^__^).
Imagines que tu partitionnes tes Zip en ext3 (partition n°1) et que tu soit amené à utiliser (ponctuellement) un Zip vfat "standard ie d'origine" (partiton n°4).
=> Est-ce que tu pourrais échanger de Zip (un ext3 en un vfat) ?
(la table de partition lue au boot sur le Zip ext3 serait incompatible avec la table du Zip vfat)
Si à l'occasion, tu tentes l'expérience, ça m'interesserait d'avoir l'info :-)
Cdlt,
PS: Bien sûr, tu pourrais aussi lui régler son compte en le reformattant comme il faut, mais pour transporter des données, le type vfat reste un bon candidat ^__^
# Un p'tit Comment-Faire...
Posté par Steve Azriel . En réponse au message Formater disquette Zip. Évalué à 3.
Voici une petit document qui pourrait t'aider :
Zip Drive Mini-HOWTO disponible, par exemple, sur TLDP
[http://www.tldp.org/HOWTO/ZIP-Drive.html]
Plus particulièrement, la section "Using the ZIP drive"
Bonne Lecture & Bon courage !
Cdlt,
[^] # Re: Copie
Posté par Steve Azriel . En réponse au message Rsync : restaurer une sauvegarde. Évalué à 2.
A priori, tu utilises rsyncd sans passer par un remote shell (type ssh) ou si tu préfères en direct tel n'importe quel autre service.
Le serveur rsyncd tourne sous l'identité que tu fixes dans le fichier /etc/rsyncd.conf via les paramètres uid et gid ou par défaut sous l'identité: nobody:nogroup (ou équivalent sur ton OS).
Peux-tu vérifier que, sur le serveur (192.168.X.X), les fichiers sont bien présents dans l'aborescence du module "portable" avec les bons droits d'accès mais avec pour identité nobody:nogroup ?
La restauration en mode preserve se base sur le référentiel du serveur qui est alors nobody:nogroup
=> cela correspond bien à ce que tu obtiens à l'arrivé sur ton portable.
Une piste pourrait être de passer le serveur rsyncd sous l'identité root:root (ou root:wheel) accompagné d'une authentification proposée par rsync comme décrit par exemple, dans [http://web.mac.com/millerdc/iWeb/DMC/HOWTO/395271A7-2C08-4DC(...)]
Une autre piste serait d'abandonner le service rsyncd pour utiliser rsync+ssh (ou toute autre combinaison du type rsync+remote shell) avec pour contrainte d'avoir les mêmes utilisateurs de part et d'autre (client / serveur) ou une convention (monlogin sur le portable <-> loginbackup sur le serveur rsync). Un système de clés partagés (cas de ssh) pourra te faciliter l'automatisation.
Bon courage !
Cdlt,
PS: Pourquoi ne pas utiliser un outil déjà prêt à l'emploi type:
¤ BackupPPC [http://backuppc.sf.net/]
[http://bruno.vernay.free.fr/HowTo/backuppc/index.html]
¤ RSnapShot [http://www.rsnapshot.org/]
? (donnés à titre d'exemple, liste non exhaustive ^__^)
A peine plus long à installer et à configurer, mais avec un UI pour BackupPPC :-)
# Plus sioux
Posté par Steve Azriel . En réponse au message Problème réseau DNS mandriva 2008 avec freebox.. Évalué à 2.
Après mon Message Privé, j'ai trouvé plus sioux !
Les DNS de Free ne m'ont pas l'air OK....
En effet, je crois que l'une des plages IP de Free est 212.* et non 217.* (via la base whois de RIPE).
Peux tu mettre à jour du fichier /etc/resolv.conf avec des adresses en 212., par exemple:
# dns3.proxad.net
nameserver 212.27.53.252
# dns2.proxad.net
nameserver 212.27.54.252
et, bien sûr, tester :-)
Bon courage !
Cdlt,
PS: Sinon, la configuration donnée par ifconfig pour eth0 (192.168.0.1 cf message [https://linuxfr.org/comments/906802.html#906802]) ne correspond pas à la description initiale (192.168.0.3 cf message [https://linuxfr.org/forums/14/24117.html])
# gsmlib ?
Posté par Steve Azriel . En réponse au message Commandes AT et Script Shell. Évalué à 1.
Il y a un projet nommé GSMLib [http://www.pxh.de/fs/gsmlib/index.html] (et même un peu plus en allant dans "Home") qui offre quelques outils pour manipuler un GSM.
Sinon, chez OpenMoko, il y a un petit wiki qui explique brièvement comment utiliser les commandes AT pour un GSM [http://wiki.openmoko.org/wiki/Manually_using_GSM] et il y aussi leur daemon GSM [http://wiki.openmoko.org/wiki/Gsmd].
Bonne Lecture & Bon courage !
Cdlt,
[^] # Re: Port interdit
Posté par Steve Azriel . En réponse au message Problème avec connexion FTP. Évalué à 1.
Le post de Kerro [https://linuxfr.org/comments/901668.html#901668] te donne déjà des tests "prêts à l'emploi"...
... quel est le sens de ta demande ?
De mon côté, j'ai eu une idée pour toi et tes clients en échec: un accès Web à ton serveur FTP !
A priori, tu devrais rencontrer moins de problème dans la mesure où les flux Web (http, https) sont plus courants que les flux FTP :-)
Par exemple:
¤ net2ftp [http://www.net2ftp.com]
¤ web-ftp [http://web-ftp.sf.net/]
En espérant que tu puisses rapidement dire:
scoubi38: Quiescence reached :-)
Bon courage !
Cdlt,
[^] # Re: Port interdit
Posté par Steve Azriel . En réponse au message Problème avec connexion FTP. Évalué à 1.
Malheureusement, sans avoir la main sur le réseau de ton client, tu ne pourras que tester des cas particuliers qui fonctionnent chez certains et pas chez d'autres :( !
Ton objectif étant d'offrir un service FTP Passif à un ensemble de clients.
A priori, de ton côté, tu as fait le nécessaire (routage, flux, service).
=> Si cela est possible, il faudrait peut-être "formaliser" ton service avec, pour chaque client (en échec ou non), une demande explicite d'ouverture de flux de type FTP (Passif) à destination de ton serveur.
Après, tu réalises une petite "recette" telle que celle que nous (tu) avons(as) faite et qui a montré que le client en échec [voir ci-dessus]:
1) accède bien à ton serveur FTP pour le canal de controle (port 21)
2) échoue dans l'établissement du canal data sur un port dans le range [50000, 55000].
Voili, voilou.
Sur ce, bon courage !
Cdlt,
[^] # Re: Une trace réseau ?
Posté par Steve Azriel . En réponse au message Problème avec connexion FTP. Évalué à 1.
Comme l'a dit Kerro (en première reponse, ou plus bas ^__^), ça ressemble bien à un filtrage de port côté client !
A toi de voir ce qui t'arrange le mieux parmi les 2 propositions de Kerro :-)
Bon courage !
Cdlt,
[^] # Re: Une trace réseau ?
Posté par Steve Azriel . En réponse au message Problème avec connexion FTP. Évalué à 1.
Essayons de voir ce que nous avons là:
1) Lignes 1 à 3
Il y a le début de la connexion vers le serveur FTP (séquence SYN, SYN+ACK, ACK)
=> Les deux clients se connectent bien au serveur sans problème mais on le savait déjà ;-)
2) Lignes 4 à 24
Même dialogue pour les deux clients qui poursuivent l'avancement de la session FTP (authentification, message du jour, ...)
=> Jusqu'ici ça va ! :-)
NB: Le masquage des informations "sensibles" n'est pas complet ^__^ (cf Lignes 8+9 du client 2)
3) Lignes ABSENTES
Il manque la séquence TCP { SYN, SYN+ACK, ACK } pour l'ouverture de la connexion sur le port donné par le serveur ?!?
=> Cette séquence est équivalente à celle de départ (cf point n°1), sauf que la destination est l'adresse IP du serveur et un port dans l'intervalle [50000, 55000]
NB: Serait-ce du au fait que tu ais appliqué un filtre sur l'écoute réseau du type "port 21" ? Cela pourrait expliquer pourquoi on ne voit pas tous les échanges liés au protocole FTP Passif.
4.a) Ligne 25 du client 1
Le client aurait détecté un dépassement de timeout (env 50 secondes) lors de sa tentative de mise en relation passive avec le serveur FTP et initie une fin de connexion via le flag TCP ReSeT.
=> Je pense que le serveur a du lui répondre positivement.
4.b) Lignes 25 à 27 du client 2
Evénements d'informations échangés sur le canal de contrôle ouvert préalablement en 1 signalant aucune erreur particulière :-)
=> Comme tu l'as si bien résumé, nous ne voyons pas les raisons de l'échec du client 1.
Pourrais tu lever le doute sur ma question soulevée au point n°3 concernant un éventuel filtre type "port 21" ?
Si tel est le cas, il faudrait recommencer la trace en utilisant un filtre plus adapté pour ce type de protocole qu'est FTP, comme "host X.X.X.X" où X.X.X.X est l'adresse IP du client.
Il ne sera pas nécessaire d'avoir les messages déjà analysés mais bien regarder ce qui se passe à partir de l'entrée en mode Passif (point n°3).
Bon courage !
Cdlt,
PS: Dernière petite question, la trace a lieu à quel niveau ? Sur le serveur lui-même ?
[^] # Re: Une trace réseau ?
Posté par Steve Azriel . En réponse au message Problème avec connexion FTP. Évalué à 1.
Merci pour ce retour d'information :-) !
[mode=blabla]
D'après les traces applicatives que tu donnes, le serveur ProFTPD ne semble pas faire pas de distinction par rapport aux clients potentiels (par exemple avec des ACLs au niveau des commandes disponibles ou autre).
En outre, un client en échec sur ton serveur FTP, ne l'est pas sur un autre serveur FTP (ovh?) dans un mode opératoire semblable (même application + même configuration de l'application [même mode de transfert passif]).
Côté serveur, a priori, il ne devrait pas y avoir de filtrage concernant ProFTPD (notamment par le fait que des clients différents arrivent à utiliser pleinement le service FTP).
Côté client, il semblerait (oui, c'est bien une hypothèse) bien que les flux sortant à destination de ton serveur (@IP=195.X.Y.Z) pour le range de ports définit [50000-55000] ne soit pas autorisé...
... mais à quel niveau (directement sur le poste client via son firewall personnel, sur le firewall au niveau de la sortie internet du client, ...)
[/mode=blabla]
En l'état, je te suggère, dans la mesure du possible, de réaliser une trace réseau, au plus proche de l'extrémité entrante d'internet du côté de ton serveur FTP.
Un telnet depuis le poste client vers ton serveur FTP sur un des ports du range [50000, 55000] devrait (encore une hypothèse, désolé !) au moins arriver jusqu'à l'entrée de ton réseau et sera traitée conformément à la politique de sécurité/filtrage (drop ou return reset ou autre).
Bon courage !
Cdlt,
# Une trace réseau ?
Posté par Steve Azriel . En réponse au message Problème avec connexion FTP. Évalué à 1.
A moins qu'il y ait une corrélation entre les différents clients (en échec, ou en succès comme par exemple, un regroupement par FAI ou par version OS), il serait peut-être intéressant de faire une petite trace réseau (wireshark ou tcpdump ^__^) de part et d'autre (client & serveur).
Est-ce que la commande "PASV" envoyée par l'un des clients en échec obtient-elle une réponse semblable (227 - Entering in Passive Mode (@IP, Port_Part1, Port_Part2) à celle d'un client OK ? En particulier, au niveau IP mais aussi numéro de port (conformité entre le range de IP+ports ouvert côté firewall et côté ProFTPD [entre autre, le paramètre PassivePorts] ?
Il y aurait à voir aussi du côté de l'utilisation ou non du(des) module(s) "ip_nat_ftp/ip_conntrack_ftp".
Sinon, la trace réseau reste un bon moyen de comprendre le comportement du client et de ses échanges avec le serveur surtout dans ce type de problématique.
Bon courage !
Cdlt,
[^] # Re: à l'envers ;-)
Posté par Steve Azriel . En réponse au message stderr dans une variable. Évalué à 1.
Le fichier temporaire créé via mktemp sert à stocker (temporairement) la sortie de la commande, pour laquelle aucun traitement immédiat n'est nécessaire.
Ainsi, après avoir "redirigé" les écritures sur 2(stderr) vers là où est écrit la sortie 1(stdout), tu peux faire de même en envoyant 1(stdout) vers le fichier temporaire.
L'important est de conserver l'ordre des redirections sinon ca ne fait pas ce que l'on souhaite :-)
Une fois que la commande est terminée et que write_log a fini, tu peux lire le contenu du fichier temporaire pour le charger dans une variable (dans ton exemple initial, il s'agissait de TAR).
En espérant avoir pu éclaircir les dernières ambigüités de mon premier commentaire ^__^
Bon courage !
Cdlt,
PS: Pour donner une solution à ton problème, voici le code que je propose et qui utilise un "wrapper" (A TESTER !).
Par avance, je vous remercie pour votre indulgence:
# Les constantes
# HOSTNAME - Nom de la machine
declare -r HOSTNAME="${HOSTNAME:-$(hostname)}"
function execute_et_log_stderr {
# Argument 1: Le fichier de log ou /dev/null :-)
local -r log_stderr="${1:-/dev/null}"
shift
# Une ressource temporaire pour stdout
local -r cmd_stdout=$(mktemp -q)
if [ ${?} -ne 0 ]; then
echo Impossible d"'"allouer une ressource temporaire '!'
return 255
fi
${@} 2>&1 1>"${cmd_stdout}" \
| while read cmd_stderr; do
echo "$(date +%b" "%d" "%T) ${HOSTNAME} backupeur[$$]: ligne :${cmd_stderr}"
done >> ${log_stderr}
cat ${cmd_stdout} && rm -f ${cmd_stdout}
return 0
}
# La pas de log de stderr
SANS_LOG=$(execute_et_log_stderr "" ls -al /home)
# La, il y aura log de stderr dans ${LOGFILE}
LOG_FILE=/var/log/backupeur
AVEC_LOG=$(execute_et_log_stderr "${LOGFILE}" tar -czf /tmp/net.tar.gz /ne)
PS2: Tiens, je revois presque le code proposé à mon premier post :P
PS3: Promis, j'arrête ! C'est mon dernier post sur cette demande (H)
[^] # Re: à l'envers ;-)
Posté par Steve Azriel . En réponse au message stderr dans une variable. Évalué à 1.
D'où mon idée "à l'envers" pour traiter ton problème :-)
Après moult relectures (et à tête reposée), je n'ai pas été assez "clair" dans mon explication :/
Voici ce que je te propose pour une commande lancée avec les bonnes redirections (cf message précédent) :
1) lire les logs stderr "au fil de l'eau" pour les formatter comme bon te semble via une boucle while read
2) renvoyer la sortie stdout (qui liste les fichiers archivés dans le tar) dans un fichier (temporaire).
=> Ainsi, tu formatteras chaque ligne d'erreur de la commande avec l'ajout du timestamp "au plus proche" de l'arrivé du message.
Ensuite, tu récupères la liste des fichiers dans ta variable shell pour faire ton traitement dessus.
[humour]
Bien sûr, je ne peux te certifier de la précision de l'horodatage des messages car je n'ai pas prise sur l'ordonnancement des processus de ton serveur ^__^, mais, à priori, dans des conditions normales, cela devrait convenir :-)
... (à suivre)
[/humour]
Bon courage !
Cdlt,
[humour]
... (suite)
PS: Si tu veux assurer un peu plus de précision, voici des pistes:
1) augmenter virtuellement la priorité de ton shell en diminuant la priorité de la commande tar (man nice)
Par exemple: nice -n 19 tar ... | while read
2) passer à un Linux Temps Réel
[/humour]
# à l'envers ;-)
Posté par Steve Azriel . En réponse au message stderr dans une variable. Évalué à 3.
Je verrais bien une solution "à l'envers" à ton problème :P
Comme tu n'as pas forcément besoin immédiatement de la sortie de la commande tar pour tes logs, c'est celle-ci que j'enverrais dans un fichier temporaire.
Après, il suffit de lire les messages stderr et de les formatter comme bon te semble.
Voici ce que cela donnerait (à tester !):
# Je crée un fichier temporaire
sortie_de_tar=$(mktemp -q)
if [ ${?} -ne 0 ]; then
echo Pas de bol '!'
fi
# Je lance l'archivage (attention a l'ordre des redirections !)
tar -czvf /home/MonHome.tar.gz /tmp/ 2>&1 >"${sortie_de_tar}" \
| while read ligne_erreur; do
# Ici, formattage de la ligne
echo $(date) $(hostname) ${ligne_erreur} >> "${LOGDIR}"
done
# Après, soit:
TAR=$(< "${sortie_de_tar}")
# ou
TAR=$(cat "${sortie_de_tar}")
# Petit ménage
rm "${sortie_de_tar}"
# La suite ici...
Qu'en penses tu ?
Bon courage !
Cdlt,
# Dig moi tout :-)
Posté par Steve Azriel . En réponse au message Résolution dns étrange. Évalué à 2.
Je me lance avec votre bienveillance :-)
1) whois 11vm-serv.net
=> Identifier les "Name Servers" qui vont bien :-)
2) dig 11vm-serv.net
=> Le résultat correspond bien avec l'entrée whois (au niveau DNS)
sauf qu'on remarque l'apparition "en plus" de "dns.11vm-serv.net".
La résolution DNS semble à ce niveau OK.
3) dig fcojean.11vm-serv.net
=> Le résultat est étonnant car il n'y a plus aucun des 3 DNS vu au n°2 et il y a l'apparition de "ns.fcojean.11vm-serv.net" avec pour adresse 127.0.0.1 !
La résolution DNS ne me paraît pas celle souhaitée à ce niveau (elle "fonctionne", mais pas comme il faudrait ?)
4.a) dig fcojean.11vm-serv.net @ns2.zoneedit.com
=> Je suppose que c'est le résultat attendu car host.11vm-serv.net a pour résolution DNS, l'adresse IP 91.121.12.176
4.b) dig fcojean.11vm-serv.net @ns17.zoneedit.com
(même résultat que 4.a)
4.c) dig fcojean.11vm-serv.net @dns.11vm-serv.net
(même résultat que 3 !)
=> Pourrais-tu jetter un oeil sur ta configuration DNS "local" (à priori du côté de dns.11vm-serv.net) ainsi que sur ZoneEdit.Com pour vérfier leur cohérence (paramétrage, transferts & co) ?
Il se pourrait que ton problème de résolution DNS soit lié avec le delta constaté dans la résolution DNS (voir n°3 & n°4.*).
Bon courage !
Cdlt,
[^] # Re: config réseau
Posté par Steve Azriel . En réponse au message Problème réseau lent : Erreur de configuration ?. Évalué à 2.
Je rajouterais bien une vérification au niveau du DNS pour la résolution inverse ce qui peut ralentir l'établissement de la connexion en SSH.
Pour cela, un moyen de tester consiste à rajouter [temporairement] une entrée dans le fichier /etc/hosts avec ton adresse IP de connexion (avec peut-être une relance du service ssh ?) et retenter une connexion...
Sinon, un peu en vrac:
1) la configuration (speed, duplex, autonegociation, ...) et les statistiques (ifconfig, netstat, ...) des interfaces réseaux pour identifier éventuellement des collisions/erreurs
2) la configuration (par exemple configuration ATA0[Petite Tortue] au lieu de ATA7 [Petite Tortue Boostée], ...) et les statistiques (iostats & co) des disques durs en usage lors des transferts.
Bon courage !
Cordialement,
# Est-il encore sous garantie ?
Posté par Steve Azriel . En réponse au message Temperature trop elevé et arrêt brutal. Évalué à 1.
J'ai rencontré un problème identique sur mon portable Acer (modèle Aspire 5562) qui s'arrêtait brutalement, à priori par protection à cause de la chaleur atteinte et ce, quelque soit le système d'exploitation.
Le redémarrer le fait quasiment aussitôt arrêter car il est encore bien chaud et n'a pas eu le temps de refroidir...
=> Aller/retour SAV Acer (une quinzaine de jours) pour le retrouver à nouveau.
Pour peu que ce soit une panne matérielle (par exemple un ventillo qui ne réagit plus...), il serait intéressant de ne pas passer à côté et de laisser passer la (précieuse) garantie :/.
Bon courage !
Cdlt,
# Côté TCPWrapper ?
Posté par Steve Azriel . En réponse au message ssh possible uniquement depuis le réseau local. Évalué à 1.
Pourrais tu regarder du côté du TCPWrapper (/etc/hosts.allow|deny) du serveur "capricieux" pour voir s'il n'y aurait pas ***par le plus grand des hazards *** un filtrage à ce niveau (voir [http://www.linuxforums.org/forum/suse-linux-help/37274-ssh-a(...)])
En outre, pourrais-tu faire un delta de "ssh -vv" (cf post de Barnabé [https://linuxfr.org/comments/895806.html#895806]) entre une connexion OK et une NOK à partir de la même source (pour avoir le même paramétrage côté initiateur de la connexion) ?
Enfin, pour compléter ma (longue) demande, pourrais-tu jeter un oeil sur le diff des configurations serveur (/etc/ssh/sshd_config ou autre) associé aux tests précédents afin de lever un doute sur le paramétrage côté serveur (voir [http://ubuntuforums.org/archive/index.php/t-7842.html]).
Merci d'avance & Bon Courage !
Cdlt,
PS: Merci à tous les autres posts pour leurs suggestions & leurs remarques :-)
# Doc Lea-Linux
Posté par Steve Azriel . En réponse au message Cluster Haute Dispo avec loadbalancing sans SAN ?. Évalué à 1.
Je suis tombé sur un document de Lea-Linux qui me paraît correspondre à ton besoin:
[http://www.lea-linux.org/cached/index/Leapro-pro_sys-dispo.h(...)]
=> Il contient une section (n° II) "La disponibilité des données".
Bonne Lecture & Bon Courage !
Cdlt,