PROJET AUTOBLOG


Planet-Libre

source: Planet-Libre

⇐ retour index

nIQnutn : Masquer des utilisateurs dans GDM

dimanche 10 juin 2018 à 17:41

Il est parfois utile de masquer des utilisateurs dans le gestionnaire de connexion, ça évite d'avoir une liste d'utilisateur à n'en plus finir ou inutile.

Pour GDM (le gestionnaire de connexion par défaut de Gnome), il faut modifier un fichier de configuration.

On commence donc par lister les fichiers utilisateurs présents dans le dossier /var/lib/AccountsService/users/

[codeUser]ls /var/lib/AccountsService/users/[/codeUser]

Pour l'utilisateur que l'on souhaite masquer sur GDM, il suffit d'éditer son fichier de configuration. S'il n'existe pas, il faudra le créer:

[codeRoot]touch /var/lib/AccountsService/users/[/codeRoot]

Avec l'éditeur de texte, on peut effectuer les modifications

[codeRoot]nano -B /var/lib/AccountsService/users/[/codeRoot] [codeFile fichier="/var/lib/AccountsService/users/"][User] SystemAccount=true[/codeFile]

Il peut être nécessaire de redémarrer l'ordinateur pour que les modifications soient prises en compte.


By nIQnutn

Gravatar de nIQnutn
Original post of nIQnutn.Votez pour ce billet sur Planet Libre.

blog-libre : Quelques réflexions autour de l’externalisation des sauvegardes

samedi 9 juin 2018 à 09:00

Sebsauvage a publié sur son wiki sa recherche d’un petit cloud perso pour y stocker des données personnelles (2 To).

Une majorité d’entre nous fait ses sauvegardes sur un disque dur interne/externe ou sur un NAS. Données et sauvegardes sont situées au même endroit physique, il peut arriver un événement rare (mais pas impossible) comme un incendie ou un cambriolage => gros fail. On en conclue qu’on a besoin d’externaliser nos sauvegardes.

Identifier et formaliser

Il faut vraiment prendre le temps d’identifier et formaliser. Prenons le cas de Sebsauvage.

Public visé : Informaticien
Ressources et moyens : Connaissances en informatique et Lignux, usage de BorgBackup, prêt à payer pour son besoin
Contexte : Personnel pas professionnel (environnement), pas urgent (délai), assez important (priorité), actuellement chez hubiC (analyse de l’existant)
Besoin : Avoir un système de sauvegarde efficace (et pas simplement “faire des sauvegardes”) pour 2 To de données
Corollaires : Identifier les outils pour effectuer des sauvegardes, restaurer les données, tester la restauration des sauvegardes, externaliser les sauvegardes
Contraintes : Coût limité (typiquement pas plus de 10 euros par mois), accès par protocole ouvert (ssh/sftp/ftp/webdav/rsync…)
Tolérance : Se moque des performances et de la disponibilité
Idéal : Le moins coûteux possible (argent et temps), principe KISS
Inconnus : Pas d’information sur la volumétrie de données à envoyer ni sur le planning (récurrence/fréquence) des sauvegardes ni sur leurs utilisations

Ce que je viens d’écrire est relativement simple mais on a grandement précisé les choses via 4 axes :

On fournit une solution par rapport à un public, des ressources et des moyens à disposition, un contexte et un besoin. Sauvegarder 50 Go ou 2 To, ce n’est pas le même besoin donc le même problème à résoudre. De même un débutant n’aura pas les mêmes connaissances en informatique qu’un informaticien, une entreprise n’aura pas les mêmes moyens qu’un particulier. Il est nécessaire d’adapter la solution à chaque cas.

On cherche à faire des sauvegardes (niveau 1) puis ensuite à avoir un système de sauvegarde efficace (niveau 2). Il y a une logique de progression mais aussi de priorités. Avant de penser à externaliser, il faut que votre processus “faire des sauvegardes” soit rodé et satisfaisant. Je vous renvoie à la règle des 3-2-1.

Considérer les solutions

Je ne vais me concentrer que sur les principaux inconvénients d’externaliser ses données personnelles dans le cloud en me basant sur le cas de Sebsauvage (je vous invite fortement à lire son article avant les lignes ci-dessous) :

A présent je vais proposer une autre solution que je vais nommer “solution locale” :

Inconnus, données actives et inactives

Il y a potentiellement un gros fail dans cette solution, ça correspond aux inconnus, on ne connaît pas l’utilisation de ses données. Sebsauvage a-t-il besoin de restaurer/récupérer régulièrement les données de ses sauvegardes ?

On va différencier 3 types de données :

Ce que l’on vient de faire là, c’est analyser plus finement le cas d’utilisation et les besoins de Sebsauvage. On les a passé sous une loupe et on a augmenté notre champ lexical : fréquence (régulièrement, tout le temps, une fois de l’an ?), accès (rapide, lent, de partout ?), utilisation (lecture, écriture, partagée ?).

Mon besoin

J’ai sensiblement le même besoin que Sebsauvage à la différence notable que j’ai besoin d’inclure une synchronisation des données.

J’ai un pc portable (pour mes déplacements/interventions), un pc fixe perso à mon domicile, un pc fixe pro au bureau. Lorsque je travaille quelque part, j’ai besoin de récupérer les données sur les autres postes. ATTENTION UNE SYNCHRONISATION N’EST PAS UNE SAUVEGARDE. J’écris un texte dans un document, il se synchronise sur les autres postes, je supprime ce texte, il se synchronise sur les autres postes, je perds donc mon texte. Dans le monde proprio l’outil de synchronisation par excellence s’appelle Dropbox, dans le monde libre c’est Syncthing dont le fonctionnement est distribué. Syncthing a mauvaise presse pour deux raisons : 1/ Sa relative complexité (que je confirme) liée au fait que c’est un outil pointu, puissant, souple 2/ Les ressources qu’il consomme, ça tombe bien c’est réglé depuis quelques semaines.

A présent ma solution nommée sobrement “solution maison” :

Votre besoin

Je ne viens pas de vous donner une solution générique, chaque cas est particulier. En revanche je vous ai fourni les informations, les termes, les pistes, le cheminement si vous voulez apprendre, comprendre…

A noter que pour aller au fond des choses, on devrait utiliser des outils de sauvegarde différents. Borg d’un côté, restic de l’autre prévenant ainsi une erreur humaine ou un bug sur l’un des deux outils. On peut évidemment mixer les solutions présentées dans ce billet, c’est même recommandé pour appréhender les différentes possibilités.

J’ai pris des libertés sur certains concepts car j’essaie de vulgariser, merci de ne pas m’injurier dans les commentaires ;)

Gravatar de blog-libre
Original post of blog-libre.Votez pour ce billet sur Planet Libre.

Articles similaires

Renault : Élections pour le FESCo cette semaine

jeudi 7 juin 2018 à 08:00

Après les élections du Mindshare et du Council qui se sont conclues cette nuit, voici le tour du FESCo d’ouvrir sa période de vote aujourd’hui pour une semaine aussi.

Chaque candidat a bien sûr un programme et un passif qu'ils souhaitent mettre en avant durant leur mandat pour orienter le projet Fedora dans certaines directions. Je vous invite à étudier les propositions des différents candidats pour cela.

J'ai voté

Pour voter, il est nécessaire d'avoir un compte FAS actif et de faire son choix sur le site du scrutin. Vous avez jusqu'au jeudi 13 juin à 2h heure française pour le faire. Donc n'attendez pas trop.

FESCo

Le FESCo (Fedora Engineering Steering Committee) est un conseil entièrement composé de membres élus et totalement dévoués à l'aspect technique du projet Fedora.

Ils vont donc traiter en particulier les points suivants :

Le responsable de ce groupe est tournant. Les 9 membres sont élus pour un an, sachant que chaque élection renouvelle la moitié du collège.

Gravatar de Renault
Original post of Renault.Votez pour ce billet sur Planet Libre.

genma : Devenir SysAdmin d'une PME - Les sauvegardes- Billet n°4

mercredi 6 juin 2018 à 09:00

Ce billet fait partie de la série :
-Devenir SysAdmin d'une PME, retour d'expérience - Billet n°0
-Devenir SysAdmin d'une PME - Gestion du legacy- Billet n°1
-Devenir SysAdmin d'une PME - Mineur de bitcoin- Billet n°2
-Devenir SysAdmin d'une PME - Accepter de ne pas avoir le contrôle sur tout- Billet n°3

Introduction

Les sauvegardes... Ah les sauvegardes... Depuis que j'ai eu mon premier ordinateur et que j'ai perdu des données, j'ai appris très rapidement à faire des sauvegardes. Car il y a deux types d'administrateurs systèmes "celui qui a déjà fait un rm -rf /* et celui qui le fera".

J'ai écrit quelques billets au cours des années sur ce sujet, pour aider à savoir quoi sauvegarder etc. je vous mets la liste des principaux billets ici :
-A.I.2 - Qu'est ce que je dois sauvegarder ?
-Sauvegarde la règle des 3-2-1
-L'importance des sauvegardes...
-Sauvegarde et restauration

Dans ce billet, je voudrais parler de quelques trucs sympa sur les sauvegardes.

Borg pour la sauvegarde des fichiers

Nombreux sont les outils pour les sauvegardes de fichers, des scripts maisons à base de rsync en passant par des outils plus évolués comme Duplicty, Rdiffbackup... Dans un précédent billet, j'évoquais Borg comme outil de sauvegarde. Avec les semaines, je reste persuader et convaincu que Borg est l'outil idéal et permet de faire, d'une façon simple, des sauvegardes des fichiers (on exclue le cas des bases de données qui sera traiter dans un billet ultérieur). Et je ne suis pas le seul à le dire. Cet article Sauvegarder ses machines avec Borg et Backupninja présente par exemple les avantages de Borg Contrairement à rdiff-backup qui a un algorithme basé sur rsync et fonctionne par incrémentation de version en version (ce qui interdit notamment de supprimer une version intermédiaire), BorgBackup utilise une technique de déduplication de morceaux (chunks). Au lieu de travailler par fichiers, il concatène (et compresse) tout ce qu'il y a à sauvegarder, pour le stocker par morceaux de 50Mo. Sans rentrer dans les détails, les intérêts sont multiples...

Le but de cette partie n'est pas de faire un tutoriel sur Borg, mais de parler de mon retour d'expérience sur le sujet en quelques mots. Je l'utilise au quotidien pour mes sauvegardes de mon poste professionnel mais également pour différents serveurs. C'est rapide, simple et efficace, pour gérer des sauvegardes de plusieurs gigas en sauvegarde chaque jour (avec peu de fichiers modifiés), ça prends quelques dizaines de secondes. Pour le cas des serveurs, j'ai mis en place un script shell on ne peut plus basique, qui fait appel à Borg. Un script du type de celui-ci est placé en tâche cron lancé chaque nuit. Si besoin, l'avantage de Borg est que l'on peut même faire une tâche cron qui se lance toutes les heures pour avoir une sauvegarde des fichiers toutes les heures. Ca ne prendra pas beaucoup de place et on aura toutes les sauvegardes dont on pourrait avoir besoin...

# on se place dans le répertoire ou l'on veut sauvegarder, qui est un montage d'un espace de stockage dédié partagé par SSH, monté en SSHFS
cd /Backup
# on lance la sauvegarde par borg qui s'effectue par un incrémental
borg create -v --stats ./::`date +%Y-%m-%d-%H:%m:%S` /le_dossier_a_sauvegarder --show-rc -v >> /tmp/mailreport.txt 2>&1

# Purge des anciennes sauvegardes, on garde sur 7 jours, 1 par semaine pendant 4 semaine, 1 par an
borg prune -v --list --keep-daily=7 --keep-weekly=4 --keep-monthly=-12 .

# Pur avoir la liste des sauvegardes dans le mail de rapport de la sauvegarde
echo -e "Liste des Sauvegardes\\n" >> /tmp/mailreport.txt
borg list . >> /tmp/mailreport.txt

# envoie du rapport par courriel
sendemail -f expediteur@domaine.com -u "Sauvegarde du serveur XXXX - Daily Report" -t destinataire@domaine.com -s smtp.domaine.com -o message-file=/tmp/mailreport.txt

Pour répondre à la règle des 3, 2, 1, il faut donc avoir une copie externalisée qui est une copie / réplication de l'espace de stockage qui reçoit toutes les sauvegardes. A voir ce que l'on met en place : disque répliqué à l'identique, service de stockage haute-disponibilité...

Sauvegarde de la configuration

Pour l'instant, ce que je fais, c'est un export via Scp de tout /etc des différents serveurs avec la remontée des fichiers de configuration dans un dossier nommé selon le serveur dans un projet dédié dans un Gitlab. Ca se scripte assez bien pour avoir le scp, un git commit... Je fais au plus facile pour l'instant mais je pense. Pourquoi pas Borg ? Car git permet d'avoir l'historique et de comparer facilement les fichiers là où Borg permet de conserver l'ensemble d'une arborescence à un instant t, une sorte de snapshot, mais il faudrait montrer plusieurs sauvegardes pour faire les comparaisons fichier à fichier..

Je réfléchis à la mise en place d'un outil comme Etckeeper pour avoir une autre automatisation, il faut encore que j'étudie ça.
etckeeper est un système conçu pour suivre la configuration d'une machine (répertoire /etc, d'où le nom) à l'aide d'un gestionnaire de versions(par exemple Git).
Deux tutoriaux sur le sujet :
-Etckeeper sur le site de l'association Grenode
-Etckeeper sur le blog Syloe.com

Sauvegarde des bases de données

Du classique, un script, une tâche cron pour faire un export Dump sur un espace de stockage... Je pense que je développerai ce sujet dans un billet une prochaine fois.

Une sauvegarde complète (un snapshot par exemple pour une VM) et des sauvegardes régulières des éléments changeants

Snapshots

Dans mon billet Devenir SysAdmin d'une PME - Gestion du legacy- Billet n°1, je parlais de machines virtuelles sur des hyperviseurs. Je gère ces machines virtuelles comme des serveurs et j'applique donc au fur et à mesure l'homogénéisation de la sauvegarde en mettant Borg en place partout.
Il est important de pouvoir remonter rapidement un service et avec une V.M., c'est assez simple. Un snapshot régulier (je travaille à scripter l'automatisation et la rotation de ces snapshots sur Xen, je ferai un billet sur le sujet), le delta de la VM correspondant à ce qui est sauvegarder de façon journalière. Je n'ai donc qu'à restaurer la VM, à réappliquer les mises à jours de l'OS, éventuellement restaurer les données et les fichiers de configuration et tout est bon.

A noter que je ne considère pas le snapshot comme une sauvegarde mais comme un complément de sauvegarde. Le snapshot ne suffit pas comme la sauvegarde ne suffit pas. Si il faut réinstaller tout une machine avec tous les services... Quoiqu'avec le tournant qu'apporte le Devops et la gestion en mode PAAS, la création de VM à la demande et l'industrialisation à venir... Bref, encore plein d'autres sujets à aborder dans les prochaines semaines et prochains mois... A suivre.

Gravatar de genma
Original post of genma.Votez pour ce billet sur Planet Libre.

Goffi : Vers une forge décentralisée basée sur XMPP

mercredi 6 juin 2018 à 07:43

Avec la récente annonce concernant le changement de propriétaire de la plus grosse forge centralisée connue, on a vu resurgir ici et là des questionnements sur la création d'un outil similaire mais décentralisé.

J'ai profité de l'occasion pour rappeler le travail effectué pour implémenter tickets et requêtes de fusion (« merge requests ») dans Salut à Toi (SàT), travail qui était passé relativement inaperçu quand j'ai écrit à ce sujet, il y a 6 mois.

Désormais je souhaite apporter quelques précisions sur le pourquoi de ces outils.

Tout d'abord pourquoi pas la grosse forge ? Après tout une importante partie des logiciels libres actuels l'utilise déjà !
D'une part parce que ce n'est pas libre, et nous nous sommes engagés dans notre contrat social à utiliser tant que possible des logiciels libres, y compris pour l'infrastructure. D'autre part parce que c'est centralisé, et là encore notre contrat social est clair à ce sujet, même si c'est moins essentiel pour l'infrastructure que pour SàT lui-même. Enfin parce que nous utilisons à l'heure actuelle Mercurial, et que la forge la plus connue est construite autour de Git.
Ne cachons pas toutefois que nous nous sommes déjà posés la question notamment en assemblée générale (cf. les comptes rendus), nous étions intéressés en particulier par la visibilité.

« C'est centralisé ? Mais « Git » est décentralisé ! » est une réflexion que l'on entend souvent et elle est vraie, Git (et Mercurial, et d'autres) est décentralisé. Mais une forge n'est pas le gestionnaire de version, c'est tous les outils autour : hébergement, tickets, gestion des modifications (merge/pull requests), commentaires, wikis, etc. Et ces outils là ne sont pas décentralisés à l'heure actuelle, et même s'ils sont souvent accessibles par des API spécifiques aux services, ils restent soumis aux lois de la centralisation, c'est-à-dire du service qui héberge (et des aléas techniques de ce service). Cela veut également dire que si le service ne veut pas d'un projet, il peut le refuser, l'effacer, le bloquer.

La centralisation, c'est aussi la facilité pour cataloguer et rechercher… pour les projets qui sont sur ce service. Rendant de facto toute tentative extérieure moins visible et donc augmentant ses difficultés. C'est une situation que nous connaissons bien avec Salut à Toi (nous sommes également absents des « réseaux sociaux » propriétaires et centralisés pour les mêmes raisons), et que nous jugeons inacceptable. Il va sans dire que se concentrer sur une plateforme ne fait qu'encourager et prolonger cet état de fait. Notons tout de même qu'il n'est pas question ici de dénigrer ceux qui ont fait des choix différents, ces réflexions étant liées à notre implication politique forte et les contraintes changent d'un cas à l'autre.

Pourquoi, alors, ne pas utiliser des projets libres existants, avancés et fonctionnels comme Gitlab ? D'une part parce que nous travaillons avec Mercurial et non Git, et d'autre part parce que nous serions là aussi dans la centralisation. Il y a une autre raison : c'est qu'il n'existe pas ou peu (Fossil peut être ?) de forges décentralisées, et nous avons déjà tout ce qu'il nous faut avec SàT et XMPP. Et puis il y a un certain plaisir à créer les outils qui nous manquent.

SàT se veut un écosystème complet, offrant la majeure partie si ce n'est tous les outils nécessaires pour s'organiser et communiquer. Mais il est aussi générique et réutilisable. C'est pourquoi le système de « merge requests » n'est pas lié à un outil particulier (Git ou Mercurial), il peut être utilisé avec d'autre logiciels, et n'est d'ailleurs par réservé au développement de code. C'est une autre brique qui sera utilisée là où ça sera utile.

Pour conclure, je rappelle que si vous voulez voir une alternative décentralisée, éthique et engagée pour construire nos logiciels, nous organiser et communiquer, on peut la rendre possible en coopérant et contribuant, que ce soit avec du code, de la conception graphique (design), des traductions de la documentation des tests, etc.
Nous avons récemment eu de l'aide pour l'empaquetage sur Arch (merci à jnanar et aux mainteneurs précédents), et il y a des efforts continus pour l'empaquetage sur Debian (merci à Robotux, Naha, Debacle et les autre empaqueteur XMPP sur Debian). Si vous pouvez participer, merci de regarder comment nous contacter sur le site officiel), ensemble on peut faire la différence.
Si vous manquez de temps, vous pouvez aussi nous soutenir sur Liberapay: https://liberapay.com/salut_a_toi. Merci d'avance !

Gravatar de Goffi
Original post of Goffi.Votez pour ce billet sur Planet Libre.