À partir d’un certain nombre de serveurs c’est totalement contre-productif d’utiliser des noms de dieux/héros/pays/others, qui va se souvenir que les dieux sont les serveurs PostgreSQL, les héros les serveurs web, etc.
On cherche tous à nommer les serveurs en précisant leur(s) fonction(s), il ne faut donc pas hésiter à faire simple : postgresql7, dns1, vpn2, dhcp1, ntp1… Le souci c’est qu’on peut avoir plusieurs applications/services sur un serveur, on perd le côté propre/logique dans le nommage. Bah ouais rien n’est parfait, il faut juste chercher à être le plus propre/logique pour le nommage et puis on fera avec.
Un S-L-T-BDD-PG01 serait chez moi TEST-PG01 parce que a/ On sait que c’est un serveur (implicite) donc je garde pas le S b/ Serveurs Linux la norme chez moi donc je garde pas le L c/ T (pour test) je garde, je garde pas PROD car c’est la norme d/ BDD je garde pas car PG01 donne l’info implicitement.
Vouloir préciser trop de choses dans le nom est une mauvaise idée d’après mon expérience, trop de changements possibles lors du cycle de vie d’un serveur. Par exemple foutre le nom de l’application ou du service genre GLPI, CIEL part du principe que ça ne changera pas. Je préfère COMPTA, RH…
Pour plus de lisibilité, je commence par les abréviations.
J’ai horreur d’une seule lettre comme abréviation, je n’ai pas souvenir avoir vu des serveurs avec des abréviations sur une seule lettre. J’ai aussi une mauvaise mémoire et mon cerveau est pas très rapide, quand je vois S-L-T-WEB01 je dois faire un effort intellectuel car je n’arrive pas à “lire” directement.
Les abréviations que je préfère : PST pour poste, PRT pour portable, SRV pour serveur, LN pour Linux, NT pour Windows, VM pour machine virtuelle, SB pour sandbox (machine de tests en général pour les devs), HY pour hypervisor, BDD pour bases de données, WEB pour serveurs web, PROD, TEST.
La plupart du temps utiliser SRV est inutile car souvent on le sait, c’est implicite, SRV-DC01 serait DC01 chez moi. Souvent il y a une majorité de serveurs Windows ou Linux pourquoi leur mettre une abréviation ? Je ne mets une abréviation qu’à ceux qui ne sont pas de la majorité de serveurs ainsi si la majorité est du Windows je ne préfixe que les serveurs Linux. Pareil pour PROD je ne le mets pas car c’est la norme chez moi, je ne mets que TEST.
Pour info dernière release du 31/03/2021 et “PROJECT ON BREAK I’m looking forward to continue development some time in the future, but there will not be updates for the next few months” (https://github.com/jliljebl/flowblade).
Tiens. Perso, je fais différement et ça fonctionne aussi :
Dans le menu “Sécurité” de mon compte GMail, du fait d’avoir activé la 2FA, créer un pass par application et dans TB (ou autres clients mails), je remplis les infos SMTP, IMAP de Gmail, et dans le champ password lié à mon compte utilisateur, je mets celui relatif au “pass par application”, créé précédemment.
Le seul truc “casse-pied” est de devoir valider quasiment tous les jours le certificat TLS de Gmail.
Je peux me tromper, mais la dernière fois que j’ai regardé il n’était justement pas possible d’auto-héberger l’équivalent de dwservice.net, si?
D’ailleurs, la première fois que j’ai entendu parler de RustDesk, il me semble bien que le relais auto-hébergeable n’était PAS opensource, me trompé-je? ou bien ça a changé?
Autre solution alternative est DWagent, fourni par dwservice.net, gratuit, open source, multi-OS.
solution méconnue mais pratique et surtout très légère, ne reste pas en mémoire, une fois le client fermé, etc.
(je ne suis en rien affilé à… j’ai simplement découvert ce logiciel libre, bien pratique)
J ai utilisé quelque chose de similaire longtemps.
Mais au final, il failait aussi retenir l’url, bah oui ca fini par changer pour de petit site et puis le compteur par site, bah oui, il y a toujours un moment ou il faut changer le pwd.
Je ne recommande pas du tout. De nos jour on a de chouette gestionnaire comme http://passwordstore.org/ qui peuvent etre sur ses propres serveurs.
Oui et dans le cas où on utilise ce système parce que les applis qui tournent dessus ne sont pas encore migrées et qu’on a besoin d’outils à installer, ça peut toujours être utile.
Après dans le monde entreprise il y a plein de cas où des systèmes obsolètes tournent encore, le cloisonnement réseau via VLAN, parefeu, ou WAF dans le cas d’un applicatif rendent moins vulnérables des systèmes qui peut être complexes à migrer (soit techniquement, soit logiciellement, soit au niveau des moyens humains)
Je vois qu’il y a bien des h2 dans le code et tout mais visuellement il n’y a pas trop de formattage.
Les titres ne ressortent pas du texte, il n’y a d’espace entre les paragraphes. Là c’est plus niveau CSS qu’il faudrait trifouiller ;-)
Merci pour ton retour. Effectivement c’est pas super niveau visuel. Je ne suis pas très à l’aise avec le markdown, solution que nous avons choisi pour poster nos articles. J’ai essayé de remettre un peu en forme mais je reste très limité.
J’ai juste une petite remarque concernant la forme : ça fait vraiment gros mur de texte un poil indigeste.
Ça serait pas mal de juste rajouter différentes section avec un titre.
Avec le même texte et la même disposition, ça permettrait déjà de scinder en plusieurs sous-parties logiques plus agréable à lire.
Ça aide aussi à reprendre la lecture quand on est interrompu ;-)
Merci pour ce retour ,en effet je n’ai pas pensé à passer par ssh pour la connexion c est une très bonne remarque. Je vais également indiquer comment valider le routage côté noyau après un reboot. Votre message a été tronqué il me semble je ne vois pas la fin ?
J’ai tendance à “crisser des pneus” quand je vois comme recommandation de faire un alias pour se connecter en ssh à son routeur, alors qu’il serait préférable de recommander la configuration du fichier de config personnel dans le sous-répertoire de SSH, et encore plus de le faire par root.
Configuration minimaliste du fichier personnel SSH : $HOME/.ssh/config
Host routeurx
Hostname 192.168.X.X
User xyz
(etc.)
C’est simple et facile à faire, et la commande en terminal, l’est tout autant : $ ssh routeurx.
Concernant la détection de matériel, afin d’avoir moins d’infos en retour : $ lsusb | grep -i net ;)
Pour finir, à-propos de net.ipv4.ip_forward, dans l’état de votre article, au redémarrage suivant, c’est terminé le routage. Il faudrait peut-être ne pas faire l’impasse sur le fait de recommander la configuration du fichier relatif à la commande sysctl. Non assurément, il ne faudrait pas faire l’impasse sur…
Comme l’article était déjà assez long, j’ai décidé de garder la mise en pratique pour un second article.
Pour répondre à ta question, dans le cas de Ubuntu, il crée automatiquement des volumes @ et @home. Et s’ils sont déjà présents dans la partition, il va les remplacer (et donc en effacer le contenu). Il faudra donc renommer le sous-volume @home (avec la commande mv ou via un navigateur de fichier) avant de procéder à la réinstallation.
Dans le cas de Fedora, l’installateur à une meilleur intégration de Btrfs et on peut créer et sélectionner des sous volumes pour le système, les données, etc. Donc à priori pas de problème (note : j’ai juste testé l’installation de Fedora avec Btrfs, pas sa réinstallation contrairement à Ubuntu)
Pour ce qui est du cas du home partagé entre 2 distributions Linux. À part faire attention à ne pas écraser le sous volume @home, je ne pense pas que ça pose de problème. Il suffira de crée un volume @distrib1 et un autre @distrib2 pour chacun des 2 systèmes. Ça sera plus ou moins simple à faire suivant comment Btrfs est pris en charges par les installateurs des deux distribs.
Et … quand tu veux réinstaller ton système en gardant ton home, (qui serait situé sur un sous-volume @home) tu procède comment ?
Idem dans le cas d’un dual-boot avec un home commun ?
Le nommage.
À partir d’un certain nombre de serveurs c’est totalement contre-productif d’utiliser des noms de dieux/héros/pays/others, qui va se souvenir que les dieux sont les serveurs PostgreSQL, les héros les serveurs web, etc.
On cherche tous à nommer les serveurs en précisant leur(s) fonction(s), il ne faut donc pas hésiter à faire simple : postgresql7, dns1, vpn2, dhcp1, ntp1… Le souci c’est qu’on peut avoir plusieurs applications/services sur un serveur, on perd le côté propre/logique dans le nommage. Bah ouais rien n’est parfait, il faut juste chercher à être le plus propre/logique pour le nommage et puis on fera avec.
Un S-L-T-BDD-PG01 serait chez moi TEST-PG01 parce que a/ On sait que c’est un serveur (implicite) donc je garde pas le S b/ Serveurs Linux la norme chez moi donc je garde pas le L c/ T (pour test) je garde, je garde pas PROD car c’est la norme d/ BDD je garde pas car PG01 donne l’info implicitement.
Vouloir préciser trop de choses dans le nom est une mauvaise idée d’après mon expérience, trop de changements possibles lors du cycle de vie d’un serveur. Par exemple foutre le nom de l’application ou du service genre GLPI, CIEL part du principe que ça ne changera pas. Je préfère COMPTA, RH…
Pour résumer : PST123, PRT456, TEST-WEB1, WEB1, DNS1, HY3, MYSQL8, POSTGRESQL4, SB-LTORVALDS (sandbox Linus Torvalds)…
Tcho !
Salute,
Pour plus de lisibilité, je commence par les abréviations.
J’ai horreur d’une seule lettre comme abréviation, je n’ai pas souvenir avoir vu des serveurs avec des abréviations sur une seule lettre. J’ai aussi une mauvaise mémoire et mon cerveau est pas très rapide, quand je vois S-L-T-WEB01 je dois faire un effort intellectuel car je n’arrive pas à “lire” directement.
Les abréviations que je préfère : PST pour poste, PRT pour portable, SRV pour serveur, LN pour Linux, NT pour Windows, VM pour machine virtuelle, SB pour sandbox (machine de tests en général pour les devs), HY pour hypervisor, BDD pour bases de données, WEB pour serveurs web, PROD, TEST.
La plupart du temps utiliser SRV est inutile car souvent on le sait, c’est implicite, SRV-DC01 serait DC01 chez moi. Souvent il y a une majorité de serveurs Windows ou Linux pourquoi leur mettre une abréviation ? Je ne mets une abréviation qu’à ceux qui ne sont pas de la majorité de serveurs ainsi si la majorité est du Windows je ne préfixe que les serveurs Linux. Pareil pour PROD je ne le mets pas car c’est la norme chez moi, je ne mets que TEST.
Tcho !
Pour info dernière release du 31/03/2021 et “PROJECT ON BREAK I’m looking forward to continue development some time in the future, but there will not be updates for the next few months” (https://github.com/jliljebl/flowblade).
Tcho !
Tiens. Perso, je fais différement et ça fonctionne aussi :
Dans le menu “Sécurité” de mon compte GMail, du fait d’avoir activé la 2FA, créer un pass par application et dans TB (ou autres clients mails), je remplis les infos SMTP, IMAP de Gmail, et dans le champ password lié à mon compte utilisateur, je mets celui relatif au “pass par application”, créé précédemment.
Le seul truc “casse-pied” est de devoir valider quasiment tous les jours le certificat TLS de Gmail.
Et, je n’ai pas configuré OAuth2.
Je peux me tromper, mais la dernière fois que j’ai regardé il n’était justement pas possible d’auto-héberger l’équivalent de dwservice.net, si?
D’ailleurs, la première fois que j’ai entendu parler de RustDesk, il me semble bien que le relais auto-hébergeable n’était PAS opensource, me trompé-je? ou bien ça a changé?
Autre solution alternative est DWagent, fourni par dwservice.net, gratuit, open source, multi-OS. solution méconnue mais pratique et surtout très légère, ne reste pas en mémoire, une fois le client fermé, etc.
(je ne suis en rien affilé à… j’ai simplement découvert ce logiciel libre, bien pratique)
Encore mieux. On va sur la page de release du dépôt voulu. On rajoute “.atom” à la fin de l’URL, et on a un flux RSS :) –> https://github.com/prometheus/prometheus/releases.atom
Un flux RSS VS des emails quand il s’agit d’infos du genre, je trouve ça beaucoup plus simple à gérer !
Merci, corrigé.
Tcho !
Mauvais lien ! Le bon: https://www.youtube.com/watch?v=yr0QkMXW1ZE
J ai utilisé quelque chose de similaire longtemps.
Mais au final, il failait aussi retenir l’url, bah oui ca fini par changer pour de petit site et puis le compteur par site, bah oui, il y a toujours un moment ou il faut changer le pwd.
Je ne recommande pas du tout. De nos jour on a de chouette gestionnaire comme http://passwordstore.org/ qui peuvent etre sur ses propres serveurs.
Oui et dans le cas où on utilise ce système parce que les applis qui tournent dessus ne sont pas encore migrées et qu’on a besoin d’outils à installer, ça peut toujours être utile. Après dans le monde entreprise il y a plein de cas où des systèmes obsolètes tournent encore, le cloisonnement réseau via VLAN, parefeu, ou WAF dans le cas d’un applicatif rendent moins vulnérables des systèmes qui peut être complexes à migrer (soit techniquement, soit logiciellement, soit au niveau des moyens humains)
Je vois qu’il y a bien des h2 dans le code et tout mais visuellement il n’y a pas trop de formattage. Les titres ne ressortent pas du texte, il n’y a d’espace entre les paragraphes. Là c’est plus niveau CSS qu’il faudrait trifouiller ;-)
Merci pour ton retour. Effectivement c’est pas super niveau visuel. Je ne suis pas très à l’aise avec le markdown, solution que nous avons choisi pour poster nos articles. J’ai essayé de remettre un peu en forme mais je reste très limité.
J’ai juste une petite remarque concernant la forme : ça fait vraiment gros mur de texte un poil indigeste.
Ça serait pas mal de juste rajouter différentes section avec un titre. Avec le même texte et la même disposition, ça permettrait déjà de scinder en plusieurs sous-parties logiques plus agréable à lire. Ça aide aussi à reprendre la lecture quand on est interrompu ;-)
Merci pour ce retour ,en effet je n’ai pas pensé à passer par ssh pour la connexion c est une très bonne remarque. Je vais également indiquer comment valider le routage côté noyau après un reboot. Votre message a été tronqué il me semble je ne vois pas la fin ?
CentOS 6 est officiellement EOL depuis novembre 2020.
Bonsoir.
J’ai tendance à “crisser des pneus” quand je vois comme recommandation de faire un alias pour se connecter en ssh à son routeur, alors qu’il serait préférable de recommander la configuration du fichier de config personnel dans le sous-répertoire de SSH, et encore plus de le faire par root.
Configuration minimaliste du fichier personnel SSH : $HOME/.ssh/config
(etc.)
C’est simple et facile à faire, et la commande en terminal, l’est tout autant :
$ ssh routeurx.Concernant la détection de matériel, afin d’avoir moins d’infos en retour :
$ lsusb | grep -i net;)Pour finir, à-propos de net.ipv4.ip_forward, dans l’état de votre article, au redémarrage suivant, c’est terminé le routage. Il faudrait peut-être ne pas faire l’impasse sur le fait de recommander la configuration du fichier relatif à la commande sysctl. Non assurément, il ne faudrait pas faire l’impasse sur…
Comme l’article était déjà assez long, j’ai décidé de garder la mise en pratique pour un second article.
Pour répondre à ta question, dans le cas de Ubuntu, il crée automatiquement des volumes @ et @home. Et s’ils sont déjà présents dans la partition, il va les remplacer (et donc en effacer le contenu). Il faudra donc renommer le sous-volume @home (avec la commande mv ou via un navigateur de fichier) avant de procéder à la réinstallation.
Dans le cas de Fedora, l’installateur à une meilleur intégration de Btrfs et on peut créer et sélectionner des sous volumes pour le système, les données, etc. Donc à priori pas de problème (note : j’ai juste testé l’installation de Fedora avec Btrfs, pas sa réinstallation contrairement à Ubuntu)
Pour ce qui est du cas du home partagé entre 2 distributions Linux. À part faire attention à ne pas écraser le sous volume @home, je ne pense pas que ça pose de problème. Il suffira de crée un volume @distrib1 et un autre @distrib2 pour chacun des 2 systèmes. Ça sera plus ou moins simple à faire suivant comment Btrfs est pris en charges par les installateurs des deux distribs.
Ahhh, bonne question. J’ai toujours le réflexe de créer une partition dédiée, quelque soit le FS ! ;)
Et … quand tu veux réinstaller ton système en gardant ton home, (qui serait situé sur un sous-volume @home) tu procède comment ? Idem dans le cas d’un dual-boot avec un home commun ?