Re: augmenetation taille /tmp
Bonjour, Le mardi 22 septembre 2015, BERBAR Florian a écrit... > Pourrais-tu préciser les options que tu as passer à l'utilitaire > "xfs_repair" ? D'autre part, si cela n'as pas été le cas lors de ta > dernier utilisation de l'utilitaire "xfs_repair", pourrais-tu donner > la sortie de la commande en ajoutant l'option "-v" qui permet de > d'activer une sortie un peu plus bavarde ? Voilà pour xfs_repair sur le VL monté sur /tmp Phase 1 - find and verify superblock... - block cache size set to 567104 entries Phase 2 - using internal log - zero log... zero_log: head block 6 tail block 6 - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... XFS_REPAIR SummaryThu Sep 24 06:54:31 2015 Phase Start End Duration Phase 1:09/24 06:54:30 09/24 06:54:30 Phase 2:09/24 06:54:30 09/24 06:54:31 1 second Phase 3:09/24 06:54:31 09/24 06:54:31 Phase 4:09/24 06:54:31 09/24 06:54:31 Phase 5:09/24 06:54:31 09/24 06:54:31 Phase 6:09/24 06:54:31 09/24 06:54:31 Phase 7:09/24 06:54:31 09/24 06:54:31 Total run time: 1 second done > # xfs_db -c 'blockget -v -p' /dev/tondevice Ne donne rien sur le VL monté sur /tmp. Pas de sortie. Pour mon autre volume, c'est quand même un peu trop gros pour mettre sur la liste. Et je ne sais pas vraiment ce qu'il faut chercher dedans. Un `df -h` hier soir avant extinction : Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur udev10M 0 10M 0% /dev tmpfs 1,2G 24M 1,2G 2% /run /dev/md2 5,4G1,1G 4,1G 21% / /dev/dm-0 30G 13G 18G 42% /usr tmpfs 3,0G 12K 3,0G 1% /dev/shm tmpfs 5,0M4,0K 5,0M 1% /run/lock tmpfs 3,0G 0 3,0G 0% /sys/fs/cgroup /dev/md088M 36M 47M 44% /boot /dev/mapper/debian-lvvar50G 17G 34G 34% /var /dev/mapper/debian-lvhome 60G 50G 11G 83% /home /dev/mapper/debian-lvtmp 797M 33M 765M 5% /tmp /dev/mapper/debian-lvlaurena 2,0G901M 1,2G 45% /home/laurena tmpfs 598M4,0K 598M 1% /run/user/1000 tmpfs 598M 0 598M 0% /run/user/0 Un `df -h` ce matin après xfs_repair sur /tmp et /home/laurena : Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur udev10M 0 10M 0% /dev tmpfs 1,2G9,0M 1,2G 1% /run /dev/md2 5,4G1,2G 4,0G 22% / /dev/dm-0 30G 13G 18G 42% /usr tmpfs 3,0G 12K 3,0G 1% /dev/shm tmpfs 5,0M4,0K 5,0M 1% /run/lock tmpfs 3,0G 0 3,0G 0% /sys/fs/cgroup /dev/md088M 36M 47M 44% /boot /dev/mapper/debian-lvhome 60G 50G 11G 84% /home /dev/mapper/debian-lvvar50G 17G 34G 34% /var tmpfs 598M4,0K 598M 1% /run/user/1000 /dev/sdd1 31G8,3G 22G 28% /mnt/usbstick /dev/mapper/debian-lvtmp 797M 33M 765M 5% /mnt/tmp /dev/mapper/debian-lvlaurena 2,0G837M 1,2G 42% /home/laurena On voit que le xfs_repair a regagné 64M sur le VL monté sur /home/laurena. Et le `du -sh` du VL de /tmp : espinasse:~$ mount /dev/mapper/debian-lvtmp /mnt/tmp espinasse:~$ du -sh /mnt/tmp/ 24K /mnt/tmp/ 24K, alors que le df montre 33M -- jm
Re: Trouble sur une configuration openvpn
Le mercredi 16 septembre 2015 à 13:29 +0200, Yann Cohen a écrit : > Bonjour, > > Je rencontre des problèmes de connexions de temps en temps sur une > architecture avec un serveur openvpn. > > Le serveur est directement sur Internet. > Il y a deux clients sur 3G sans adresse publique, et un qui se balade > sur des réseaux domestiques ou professionnels toujours en connexion > filaire. > > De temps en temps les clients n'arrivent pas à se connecter sur le > serveur avec des TLS handcheck error pendant un certain temps (plusieurs > heures) puis la connexion revient et reste "stable" plusieurs jours. > > Il n'y a aucune manipulation sur des firewall entre les clients et le > serveur. > > La dernière perte de connexion a eu lieu après que le routeur 3G ait > changé d'adresse IP, le client détecte une perte du ping et tente une > réconnexion qui n'aboutie pas sur le serveur (aucune trace dans les log > serveur, mais des traces d'erreur TLS dans le log client). IL s'avère que le problème est ailleurs : la machine arm linux est configurée en bridge avec deux interfaces (eth0 et eth1) et je constate que lorsque eth0 perd le lien (reboot du routeur par exemple), le trafic depuis et vers cette interface est stoppé alors que le bridge la déclare en état forwarding. la sortir du bridge et l'ajouté rétabli la situation (généralement..) > > Je cherche à comprendre sur le client linux qui héberge le client > openvpn, ce qui ne fonctionne pas : voit-il le routeur de sortie ? > voit-il le serveur openvpn au travers routeur 3G ?... > > Quelles autres pistes puis-je tester ? > > Cordialement. > > Yann. > > > >
Re: augmenetation taille /tmp
Bonjour, Le mardi 22 septembre 2015, BERBAR Florian a écrit... > Pourrais-tu préciser les options que tu as passer à l'utilitaire > "xfs_repair" ? D'autre part, si cela n'as pas été le cas lors de ta > dernier utilisation de l'utilitaire "xfs_repair", pourrais-tu donner > la sortie de la commande en ajoutant l'option "-v" qui permet de > d'activer une sortie un peu plus bavarde ? D'accord, je recommencerai. Le truc c'est que, ce matin, pas d'augmentation… > Toujours au sujet de ton système de fichier xfs, as tu tenté > d'examiner les volumes toucher par ton problème d'accroissement de > taille avec les utilitaire "xfs_io" ou "xfs_db" qui permet de déboguer > un système de fichier XFS. > Par exemple : > # xfs_db -c 'blockget -v -p' /dev/tondevice J'essaierai xfs_db juste avant, et juste après le reboot. Savoir si je saurai interpréter la sortie est une autre histoire… Merci de ton aide. -- jm
Bonding wifi - ethernet , wifi multiple ssid
Bonjour, Est-il possible (un tuto pour les nuls ?) de faire du bonding concernant wlan0 (wifi) et eth1 (ethernet) - les 2 interfaces sont dhcp - la solution de mettre en dur la conf wifi dans /etc/network/interfaces ne me convient pas car j'utilise plusieurs points d'accès wifi (travail, perso, chez des amis, ...) En hors sujet, je précise que j'arrive sur un serveur un faire du bonding filaire en mode ip static (!=dhcp). Sur le web, la seule réponse qui semble répondre à ma demande est pour arch linux : http://www.codekoala.com/posts/bonding-eth0-and-wlan0-arch-linux/ Mais je n'arrive pas à transposer à la sauce debian J'utilise network manager sous openbox, j'ai essayé avec l'ihm gtk de créer un lien, mais : - je ne peux ajouter que mon interface eth - le mode reste circulaire, même si je sélectionne "active backup" (qui je pense est le bon mode dans mon cas : priorité filaire, puis wifi. ma conf /etc/network/interfaces (a force de modifier, y'a ptet des incohérences) ressemble à cela auto lo iface lo inet loopback allow-hotplug eth1 auto eth1 #iface eth1 inet manual #bond-master bond0 auto wlan0 # iface wlan0 inet manual # bond-master bond0 iface bond0 inet dhcp slave eth1 wlan0 #mode=1 (active-backup) bond_mode 1 # volontairement redondant avec /etc/modprobe.d/bonding.conf bond-primary eth0 bond_miimon 100 bond_downdelay 200 bond_updelay 200 auto br0 iface br0 inet static address 192.168.1.1 netmask 255.255.255.0 bridge_fd 0 bridge_ports none cat /etc/modprobe.d/bonding.conf alias bond0 bonding options bonding mode=1 miimon=100 lacp_rate=1 ci-dessous juste pour info, car temps que je ne suis pas sur d'avoir mon mode wifi (multissid)<->filaire possible, je ne rends pas le bonding fonctionnel... cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Bonding Mode: fault-tolerance (active-backup) Primary Slave: None Currently Active Slave: None MII Status: down MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0
