Nanawel a écrit 281 commentaires

Oui c'est ça, le cas classique de permissions incorrectes sur le dossier ./ssh/* et son contenu. SSH est très tatillon sur ça (à raison, bien sûr).

Pour un user toto, ça devrait être par exemple

ls -alR /home/toto/.ssh/
/home/toto/.ssh/:
total 24
drwx------ 2 toto users 4096 mai    2  2019 .
drwxr-xr-x 9 toto users 4096 janv. 25  2020 ..
-rw-r--r-- 1 toto users 1192 mai    2  2019 authorized_keys

Les permissions ne suffisent pas, il faut aussi le bon ownership.

Tu peux tester un

journalctl -u ssh -xe

pour avoir les raisons des erreurs de connexion ?

Sauf erreur, je crois que sur OMV les utilisateurs avec lesquels il est possible de se connecter en SSH doivent être dans le groupe système ssh au préalable.

usermod -aG ssh $ton_user

Très étrange. La partition est pourtant en ext4 sans options de montage exotiques donc ça ne devrait pas faire ça. Sauf si ce comportement est lié à une action qui se produit au démarrage uniquement.

Essaye de créer un fichier, puis de démonter la partition umount /data, et de la remonter ensuite mount /data pour voir si tu reproduis ce comportement sans redémarrer.

… mais 4 ko c'est beaucoup pour 2 octets de données.

Que donne la comment mount ?

À noter qu'il y a un documentaire sur le sujet actuellement en replay sur Arte :
https://www.arte.tv/fr/videos/093704-000-A/il-etait-une-fois-wikipedia/

(pas encore vu, donc je ne peux pas juger, mais je mentionne)

Alors pour info, j'ai un Postfix sur mon home-server, mais il ne me sert que pour les services hébergés dessus (donc il envoie beaucoup depuis du noreply), et un peu pour des autres besoins, mais mon "vrai" mail est chez un hébergeur dont je tairai le nom par pudeur.

Mon Postfix est configuré pour utiliser le SMTP d'Orange en relayhost.
J'ai ensuite créé des adresses (on a droit jusqu'à 5 alias) en fonction de mes besoins, et je les utilise dans une sender_canonical_maps qui va bien.

Bien sûr, ça n'est pas comme si c'était réellement envoyé depuis mon serveur, mais ça apparaît notamment sur Gmail comme Envoyé depuis trucmuche@monhomeserver.dyndns.com via orange.fr, ce qui n'est pas si mal.

Tellement trôlle :p

Je n'ai pas voulu non plus aborder ces aspects ni les opinions qu'elles sous-entendent, et qui apparemment n'avaient pas changées depuis 15 ans, hélas. C'était des points qui nous divisaient fortement et que nous prenions soin d'éviter dans nos discussions, lui le premier. À ses yeux je sais que j'étais probablement un hippie insouciant et aveugle des vrais problèmes du Monde, quand lui était aux miens un libertarien pur jus tendance alt-right qu'en d'autres circonstances j'aurais abhorré.

C'était néanmoins un camarade. Nos routes se sont croisées. Elles ne ne feront plus.

J'étais surpris de voir (enfin) un nouvel article de son blog sur mes RSS ce matin, mais la lecture de son message a été une sacrée douche froide.

Nous n'étions pas proches, mais nous avons fait l'IUT à Toulouse ensemble entre 2004 et 2006, et je me souviens d'un camarade - certes un peu nerd - avec beaucoup d'humour, et un membre précieux de notre petit groupe de travail à l'époque.

Il m'a fait découvrir Machinae Supremacy - du temps où le groupe était encore underground et donc "écoutable" par sa personne - et par là-même m'a permis de mettre un pied une oreille dans le metal, et rien que pour ça, je lui en suis éternellement reconnaissant.

Cette nuit j'ai perdu l'accès SSH à mon serveur chez Gandi.

Après un ticket inutile qui a confirmé que le problème était bien de mon côté, j'ai tenté de redémarrer la box.

Et évidemment tout remarche (IGN, Gmail, SSH). Probablement suite au changement d'IP de la box (de 90.76.235.192 à 86.206.2xx.xxx).

Alors impossible de comprendre ce qui a bien pu coincer, mais une chose est quasi-sûre c'est que ça peut recommencer à n'importe quel moment, et c'est bien handicapant.

Tu dis avoir changé l'IP et le nom des clones, mais as-tu changé aussi leur adresse MAC ? (je ne sais pas si avec le système que tu utilises c'est automatique ou non)

Ah un de plus… Maintenant y'a aussi imap.gmail.com en IPv6 qui passe plus (à supposer qu'il passait avant, j'ai pas vérifié).

Ni ping ni connexion TCP.

$ ping imap.gmail.com
PING imap.gmail.com(wr-in-x6d.1e100.net (2a00:1450:400c:c0c::6d)) 56 octets de données
^C

$ mtr -r -c3 -TP993 imap.gmail.com
Start: 2020-10-23T10:59:38+0200
HOST: leto                        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2a01:cb19:85e4:f800:769d:  0.0%     3    0.4   0.4   0.3   0.5   0.1
  2.|-- ???                       100.0     3    0.0   0.0   0.0   0.0   0.0

En IPv4 toujours aucun problème évidemment.

Je suis dans le flou :\

Effectivement, c'est le minimum.

Bon par contre ça ne change rien, hélas : toujours pas de connexion en IPv4 sur remonterletemps.ign.fr :

$ mtr -4 -r -c3 -T -P443 remonterletemps.ign.fr
Start: 2020-10-22T11:47:07+0200
HOST: leto                        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- _gateway                   0.0%     3    0.4   0.4   0.4   0.5   0.0
  2.|-- ???                       100.0     3    0.0   0.0   0.0   0.0   0.0
  3.|-- lag-111.nctou101.Toulouse  0.0%     3    1.4   1.6   1.1   2.3   0.6
  4.|-- 193.252.160.9             33.3%     3  3210. 2109. 1008. 3210. 1556.9
  5.|-- ae43-0.nipoi201.Poitiers.  0.0%     3    6.9   9.8   6.9  14.7   4.3
  6.|-- 193.252.137.18             0.0%     3   11.6  14.8  11.6  20.9   5.2
  7.|-- hundredgige0-5-0-22.pastr  0.0%     3  3171. 1066.  13.5 3171. 1823.4
        hundredgige0-2-0-14.pastr4.-.opentransit.net
        hundredgige0-4-0-13.pastr4.-.opentransit.net
  8.|-- zayo-8.gw.opentransit.net  0.0%     3   24.9  28.3  24.9  30.3   3.0
        zayo-9.gw.opentransit.net        
  9.|-- ae4.mpr2.cdg12.fr.zip.zay  0.0%     3   93.8  97.2  93.8 101.8   4.1
 10.|-- ???                       100.0     3    0.0   0.0   0.0   0.0   0.0

$ curl -v https://remonterletemps.ign.fr
*   Trying 185.113.40.99:443...
^C

Et la connexion en IPv4 vers le SMTP de Gmail fonctionne toujours - comme attendu - mais toujours pas en IPv6 puisque… ben je l'ai désactivé.

Oui j'avais pensé à désactiver l'IPv6 puis mes tests semblaient démontrer que le problème n'était - au moins uniquement - limité à cet aspect, donc j'ai préféré le laisser car pour certains cas d'usage c'est pratique.

Le test Gmail en IPv6 fonctionne parfaitement depuis une autre connexion que celle de chez moi, donc non a priori le service est ouvert et opérationnel (le contraire serait étonnant de la part de Google).

Effectivement le test de ping est un simple complément au reste. Ça permet surtout de valider la partie IP sans la partie TCP.

Hello,
Très intéressé pour remplacer mon vieux (mais néanmoins vaillant) portable de 2008.
Une adresse mail ou autre pour te contacter ?

C'est effectivement une très bonne remarque. Cette idée m'avait traversé l'esprit mais j'ai pensé que c'était plutôt réservé à des HDD de plus grosses capacités, en oubliant que justement les constructeurs s'étaient fait pincer récemment à omettre ces informations sciemment sur certains modèles…

Merci pour les docs, effectivement c'est une erreur de ma part en choisissant les disques. J'ai un peu trop joué sur le côté Inexpensive du RAID en prenant des disques d'entrée de gamme. Je note de remplacer le Barracuda qui n'est pas adapté à l'usage.

Oui pardon, j'avais bien compris le principe du NCQ pour les disques et de sa pertinence pour améliorer les perfs, mais presque tous les articles que j'ai vus qui parlaient de solutions concernant la lenteur d'un reshape de RAID5 disaient de le désactiver (càd de passer à 1).

Or chez moi ça a exactement l'effet inverse et baisse considérablement les débits. Alors que le laisser à 32 permet de revenir à des performances acceptables.

Ah, et passer /sys/block/$dev/device/queue_depth de 8 à 16 permet de gagner encore 5 Mo/s (soit environ 23 Mo/s).

Je l'avais abaissé à 8 en supposant qu'il s'agissait d'un bon compromis entre 1 (les conseils lus à droite et à gauche) et 32, la valeur par défaut.

Le repasser à 32 m'a encore permis de remonter à 27 Mo/s. Je comprends vraiment pas ces conseils.

Et le truc qui sauve vraiment, c'est le write cache des disques. C'est souvent désactivé par défaut parce qu'en cas de coupure brusque, ça fait de gros dégats dans le FS. Mais ça accélère vraiment sur des I/O un peu intenses.

Ah oué c'est radical oO

Je passe instantanément (ok non en quelques minutes) à 18 Mo/s.

Le serveur étant sur un onduleur avec 30mn d'autonomie et une extinction automatique propre on va dire que c'est plutôt safe. Dans tous les cas, c'est principalement des backups donc pas de question de vie ou de mort en cas de perte des données.

Merci !

Bon, après 5mn pas de changement notable malgré les "optimisations" apportées :(

Je déconseille par contre fortement dans une situation similaire de suivre les conseils indiquant qu'il faut désactiver le NCQ sur les disques : en faisant ça le débit a chuté chez moi en 1mn à ~500 ko/s ! (j'avais déjà testé ça en début de semaine avec le même résultat)

Ouais je crois que c'est ce qui fait toute la différence ici. Il faudrait (aurait fallu) que j'augmente la taille des chunks en passant du RAID1 à RAID5.

A priori c'est possible de le faire a posteriori, mais encore faut-il que le reshape se termine d'abord…

(et j'imagine que cette action va aussi prendre des plombes pour les mêmes raisons)

Très juste, j'avais oublié de mettre la sortie de mdadm --detail /dev/md0, j'ai corrigé ça.

Normalement ça permet de dire que j'utilise déjà un internal bitmap. C'est bien le but de ta première commande ?

Pour les commandes suivantes voici l'état actuel :

# cat /proc/sys/dev/raid/speed_limit_max
200000

# cat /sys/block/sd[a-d]/queue/read_ahead_kb
128
128
128
128

# cat /sys/block/sd[a-d]/queue/nr_requests
64
64
64
64

# for dev in $(echo /dev/sd[a-d]); do echo -n "$dev: "; blockdev --getra $dev; done
/dev/sda: 256
/dev/sdb: 256
/dev/sdc: 256
/dev/sdd: 256

# blockdev --getra /dev/md0
65536

# cat /sys/block/md0/md/stripe_cache_size
8192

# cat /sys/block/md0/md/stripe_cache_active
12041

Bon clairement y'a des choses à ajuster. Je m'en vais tenter ça de suite. Merci !

Autres sources trouvées à ce sujet en passant, avec des valeurs égales ou similaires :
- https://wtf.roflcopter.fr/links/pogo/?nICtQw
- http://wiki.alessandro.delgallo.net/wiki/index.php/RAID

Quand j'ai vu ces perfs j'ai cherché une explication dans les logs, et notamment des erreurs SATA (par expérience…). Mais là rien du tout, les logs systèmes sont cleans, rien à redire.

Si le problème était lié au débit es interfaces, je pense que les tests hdparm l'auraient révélé.

Quelle est la taille des chunks sur ta grappe ?

J'y ai pensé aussi, mais quand je regarde le load je vois surtout beaucoup d'iowait et pas beaucoup de temps kernel ou user (80% d'iowait contre 10% max de kernel+user). À mon sens ça devrait pourtant se traduire par une occupation forte de ces états.

La sortie de mon dmesg :

[    4.470732] raid6: sse2x1   gen()  2107 MB/s
[    4.538717] raid6: sse2x1   xor()  2003 MB/s
[    4.606728] raid6: sse2x2   gen()  3375 MB/s
[    4.674719] raid6: sse2x2   xor()  3409 MB/s
[    4.742733] raid6: sse2x4   gen()  4054 MB/s
[    4.810714] raid6: sse2x4   xor()  2175 MB/s
[    4.810717] raid6: using algorithm sse2x4 gen() 4054 MB/s
[    4.810718] raid6: .... xor() 2175 MB/s, rmw enabled
[    4.810720] raid6: using intx1 recovery algorithm

Pas top certes, mais pas trop dégueu non plus je pense, non ?