Nanawel a écrit 285 commentaires

Pour la gestion des assos, il y a aussi Garradin : https://garradin.eu/

Apparemment c'est simple mais pratique et efficace. Je te conseille d'y jeter un oeil.

Non c'est simple également, même si un poil plus délicat que la RAM.

Grosso-modo les étapes sont les suivantes :

1. Déclipser le ventirad (tu peux en profiter pour le nettoyer à fond, ça fait toujours plaisir ^^). Selon le montage il faut juste des doigts ou un tournevis plat.
2. Désarmer le CPU du socket. Sur ce modèle normalement ça consiste à simplement relever un petit bras métallique sur le côté.
3. Retirer le CPU. Là avec 2 doigts ça se fait tout seul.
4. Déposer le nouveau CPU (inutile de forcer, attention au détrompeur pour cela).
5. Abaisser le petit bras pour réarmer le CPU.
6. Ajouter une petite dose de pâte thermique au centre du CPU
7. Replacer le ventirad (dont on aura enlevé la pâte thermique restante du précédent CPU avant) et le refixer avec son système dédié (idem étape initiale : doigts et/ou tournevis).

Et c'est tout !
Reste juste à voir si le BIOS de la carte mère accepte bien ce CPU, mais généralement c'est le cas, ou au pire il faut bien mettre le BIOS à jour vers la dernière version.

Je rejoins l'avis général et pour cause, j'avais également un PC basé sur un CPU Athlon X2 3800+ et 2 Go de RAM : c'est très lent, même sous GNU/Linux (avec environnement XFCE pour ma part).

Pour une utilisation "plus confortable" même si c'est loin d'être idéal, je peux te proposer les pistes suivantes :
- installer un SSD pour le système (ça, ça peut faire une grosse différence)
- passer à 4 Go de RAM (d'occasion, ça ne coûte pas grand chose)
- upgrader le CPU (idem, d'occasion ça se trouve pour assez peu maintenant)

J'ai fait le remplacement de la RAM et du CPU (6000+) et ça fait un bon ordi d'appoint. J'envisage aussi d'installer un SSD mais mon faible usage ne le justifiait pas jusqu'ici.

Autre origine possible : la partition NTFS/FAT est marquée "dirty" (suite par exemple à un retrait sans éjection préalable) et par défaut je crois que dans ce cas le driver NTFS/FAT la monte en lecture seule.

Il suffit de faire un fsck sur la partition (une fois celle-ci démontée au préalable) pour réinitialiser le dirty bit.

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)