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 ?
Pour le moment mon PC principal est toujours en LUKS+Ext4, j’attends de recevoir mon nouveau PC pour faire le changement. En attendant je l’utilise intensivement sur d’autres machines :)
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 ?
Pour le moment mon PC principal est toujours en LUKS+Ext4, j’attends de recevoir mon nouveau PC pour faire le changement. En attendant je l’utilise intensivement sur d’autres machines :)
Merci pour ce long article intéressant, qui m’a permis de mieux comprendre BtrFS, et surtout la logique des instantanés, et CoW. :D
Personnellement, j’aime bien ce FS, que je trouve stable, rapide, et l’installe de préférence à Ext4.