PROJET AUTOBLOG


Planet-Libre

source: Planet-Libre

⇐ retour index

genma : Devenir SysAdmin d'une PME, retour d'expérience - Billet n°0

vendredi 18 mai 2018 à 09:00

Introduction

Depuis mes débuts sous Linux, j'ai toujours su taper des commandes. Très tôt, j'ai appris à installer différents services et des serveurs (essentiellement dans des machines virtuelles et pour faire du LAMP : Linux, Apache, MySQL, PHP), mais c'est toujours resté de la bidouille. Avec le début de mon autohébergement fin décembre 2015, j'ai commencé à m'intéresser aux problématiques d'administration système. A l'été 2016, pendant les vacances, j'ai mes débuts véritable en sysadmin - administration système en cherchant à comprendre comment fonctionnait Yunohost dans ses entrailles, les différents services, en cassant et restaurant sans soucis à plusieurs reprises mon instance de production... J'ai donc appris et pas mal progressé à titre personnel, en gérant mon instance Yunohost, soit un seul serveur.

Pourtant, à côté, j'ai continué à m'intéresser à une gestion plus professionnelle et industrielle et en début de cette année 2018, je me suis vu affecter la reprise de la gestion de toute l'infrastructure de la société dans laquelle je travaille. Cette prise de fonction et de responsabilité a été décidé dans le cadre d'une restructuration des services : gérer les services de production, de support et d'infrastructure interne et liée à nos clients permet d'avoir une meilleur vision d'ensemble, plus de réactivité...

Comme toute nouvelle prise de fonction, les précédentes personnes ayant eu à gérer le service sont parties faire d'autres horizons bien qu'une passation de connaissances s'est faite, elle s'est faite rapidement.

Et avec les semaines, on découvre que même si une documentation existe (répartie dans plusieurs wikis), elle n'a pas été maintenue à jour, n'est pas assez détaillée ou obsolète... Et avec le temps il y a des choses qui marchent mais on ne sait pas comment, il y a des serveurs qu'on ne touche pas, des services qui tournent alors on ne touche à rien. Tout cet héritage et empilage de choix technique mis en place avec les années par les différents administrateurs systèmes qui se sont succèdés, c'est ce que j'appellerai le legacy, soit l'héritage.

Contexte de l'infrastructure Je pense qu'il est important, pour la suite des billets que j'aurai à rédiger, de préciser, que l'infrastructure actuelle se compose de trois grandes catégories de machines et ces catégories ont leurs importances :
- Les machines physiques : 99% des serveurs sont sous Debian, dans différentes versions
- Les machines virtuelles sur un hyperviseur : Xen et Proxmox
- Les machines cloud (sur l'hyperviseur d'un autre)

Un travail de modernisation avec le passage à des technologies plus évolutives et flexibles (virtualisation, Docker / K8S Kubernetes...) a été débuté mais il reste encore beaucoup de "une machine physique ou virtuelle pour un service dédié" avec autant de système d'exploitations et d'applications à maintenir et à découvrir...

Je pense que je ferai là encore, une série de billets au fur et à mesure de ma progression et sur comment j'ai commencer à dresser une cartographie détaillé de l'existant, documenter de novo en reprenant TOUTE la documentation existante pour la remettre d'aplomb... Et dans le futur, je parlerai de mon expérience dans la mise en place de nouveau service, dans la refonte et modernisation de l'infrastructure...

L'objectif de ma série de billets ces prochains mois sera le partage de mon expérience acquise avec le temps, le partage de bonnes pratiques mises en places, d'astuces etc. En complément de ma série de billets plus spécifiques sur le projet Chatonkademy/

Les commandes que j'utilise le plus

Pour finir ce premier billet un peu fourre-tout, je voudrais parler des commandes que j'utilise le plus au quotidien. A l'heure actuelle, quand l'outil de supervision (sous Zabbix) remonte des alertes, je me connecte en SSH sur les machines et voici les commandes que j'utilise le plus :
- ncdu
- ls -lrtu
- tail -f /var/log/le_fichier_de_log_qui_va_bien

ncdu Habitué de la commande du dont je ne me rappelle jamais les options pour avoir uniquement le niveau 1 (réponse du -h —max-depth=1 .), j'ai découvert et depuis je ne m'en passe plus et l'installe sur tous les serveurs la commande ncdu, soit NCurses Disk Usage. Simple, rapide et efficace, on a de suite l'espace disque occupé par un répertoire. Pratique pour de suite savoir quel dossier prend plein de place, et c'est très complémentaire à du, en ajoutant en plus un système de navigation au clavier dans l'arborescence scannée. Indispensable.

ls -lrtu on liste les fichiers et on les trie par date pour de suite avoir en base de liste les derniers fichiers modifiés. Pratique pour savoir quel est le dernier fichier de logs qui vient d'être modifié (c'est le dernier de la liste), voir quel est le propriétaire et la date et heure de dernière écriture.

Pour ensuite faire dessus le classique

tail -f /var/log/le_fichier_de_log_qui_va_bien J'ai dans les projets pour les mois à venir la mise en place d'un système de gestion des logs centralisés mais en attendant, à l'ancienne, je consulte les logs avec un tail -f et éventuellement du |grep motif_qui_va_bien pour filtrer affiner un peu.

Et pour le reste, il y a les commandes que j'évoquais dans mes billets :
-Yunohost - Supervision en ligne de commande
-Yunohost - Supervision du trafic réseau

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

Thuban : Syspatch : Patch 8 IPSec over IPv6 pour OpenBSD

vendredi 18 mai 2018 à 08:43

Cette nuit, l'équipe d'OpenBSD a livré un nouveau correctif pour OpenBSD.

Un paquet malicieux peut causer un crash du noyau lors de l'usage d'IPsec sur IPv6 !

 

Architectures concernées : amd64, arm64 et i386.

OS concernés :

Un redémarrage est nécessaire !

 


 

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

Cyprien Pouzenc : Restaurer GRUB avec une partition chiffrée séparée

vendredi 18 mai 2018 à 08:24

Logos de GRUB (© Karol Krenski)

Lorsque l'ordinateur ne peut plus démarrer à cause d'un chargeur d'amorçage cassé, il suffit de réparer le-dit chargeur d'amorçage — en l'occurence GRUB, dans le cas qui nous intéresse ici. Classiquement, cela implique de démarrer l'ordinateur sur le Live CD de sa distribution GNU/Linux favorite, de taper quelques commandes dans le terminal, puis de redémarrer. Cela se complique un poil lorsque le système est installé sur plusieurs partitions, potentiellement chiffrées. Voici un petit article bloc-note, pour savoir quoi faire quand la situation se présentera à nouveau sous les orteils de mes mains.

Logos de GRUB (© Karol Krenski)
Logos de GRUB (© Karol Krenski)

Démêlons les fils, LVM2 et LUKS

Je démarre donc l'ordinateur sur un Live CD de Debian GNU/Linux. Une fois passées les quelques étapes cosmétiques — à savoir la sélection d'une disposition de clavier française et l'installation des pilotes non-libres de la carte wifi pour avoir une connexion Internet — je peux m'attaquer au vif du sujet.

Dans ce cas précis, le disque dur contient trois partitions : /dev/sda1 pour /boot/efi, /dev/sda2 pour /boot et /dev/sda3 comme groupe de volumes logiques LVM2, chiffré avec LUKS — et qui contient, notamment, la partition racine. Afin de gérer LVM2 et LUKS, il faut commencer par installer les paquets nécessaires sur le système autonome du Live CD. Les étapes à suivre sont énoncées ci-dessous.

Se connecter en tant que super-utilisateur :

su -

Mettre à jour la liste des paquets :

apt update

Installer les paquets lvm2 et cryptsetup :

apt install lvm2 cryptsetup

Charger le module noyau dm-crypt utile au chiffrement des volumes :

modprobe dm-crypt

Déverrouiller et charger la partition chiffrée :

cryptsetup luksOpen /dev/sda3 luks_sda3

Il est maintenant possible de trouver les groupes de volumes LVM2 présents :

vgscan

Lequel nous répond :

Found volume group "portable-vg" using metadata type lvm2

J'active donc le groupe indiqué, afin de pouvoir accéder aux volumes qu'il contient :

vgchange -a y portable-vg

Pour trouver les-dits volumes :

lvscan

Qui nous répond à son tour :

ACTIVE            '/dev/portable-vg/root' [107,12 GiB] inherit
ACTIVE            '/dev/portable-vg/swap_1' [3,93 GiB] inherit

Le groupe contient donc deux volumes, à savoir la racine du système et une partition d'échange — qui est passablement inutile dans le cadre de cet article. Information intéressante s'il en est, le volume de la racine est accessible sur /dev/portable-vg/root.

Sus au chroot !

Il est maintenant possible de procéder à la restauration — désormais classique — de GRUB. Cela commence par la création d'un point de montage :

mkdir /mnt/chroot

Sur lequel monter le volume de la racine :

mount /dev/portable-vg/root /mnt/chroot/

Ainsi que quelques partitions spéciales du disque autonome :

mount --bind /dev /mnt/chroot/dev
mount -t proc /proc /mnt/chroot/proc
mount -t sysfs /sys /mnt/chroot/sys

Enfin, plongeons la tête dans le chroot :

chroot /mnt/chroot

Désormais, attention les doigts, toute opération prendra effet sur le disque à récupérer, non-plus sur le système autonome du Live CD. Finie la rigolade. À noter que les partitions /dev/sda1 et /dev/sda2 n'ont pas été montées précédemment. Si cela avait été le cas, le système chrooté aurait eu l'impression qu'il s'agissait d'une seule et unique partition, ce qui n'est évidemment ici pas l'ombre du reflet de la réalité. Et cela aurait posé problème lors de la configuration de GRUB. Ce n'est que maintenant, une fois entré dans le chroot, qu'il faut monter ces partitions :

mount /dev/sda2 /boot
mount /dev/sda1 /boot/efi

Pour enfin, objectif ultime, réparer ce foutu GRUB :

update-grub
grub-install /dev/sda

Pour terminer proprement le travail avant de quitter l'usine, on sort du chroot et on démonte toutes les partitions :

exit
umount /mnt/chroot/boot/efi
umount /mnt/chroot/boot
umount /mnt/chroot/dev
umount /mnt/chroot/proc
umount /mnt/chroot/sys
umount /mnt/chroot

Puis on redémarre l'ordinateur en croisant les narines :

reboot

Article sous licence Creative Commons BY-SA 3.0 France.

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

Okki : Hackathon GNOME pour l’amélioration des performances

jeudi 17 mai 2018 à 22:46
GNOME Performance Hackfest 2018 (© Alberto Ruiz)

Les fondations GNOME et Raspberry Pi ont récemment organisé un hackathon ayant pour objectif l’optimisation des ressources (RAM, CPU, GPU, consommation énergétique) utilisées par une session GNOME typique, ainsi que l’amélioration des performances.

L’événement s’est déroulé du 14 au 16 mai 2018 à Cambridge et a réuni plus d’une quinzaine de développeurs issus de diverses entreprises telles que Broadcom, Canonical, Collabora, Endless et bien évidemment Red Hat, dont les développeurs étaient présents en nombre.

Parmi les différents problèmes d’utilisation de la mémoire sur lesquels les développeurs ont travaillé, nous pouvons citer le gestionnaire de session GDM, qui maintient sa propre instance de GNOME Shell. De régler ce problème fait chuter la consommation de RAM de 280 Mio. Rien que ça. Autre cible importante, Logiciels, la logithèque GNOME, qui tourne en tâche de fond pour pouvoir fournir des résultats lors d’une recherche d’applications dans la vue d’ensemble des activités. Ce dernier consomme plus de 90 Mio de RAM. Sans oublier tous ces petits démons qui pourraient être appelés à la demande, plutôt que de tourner en permanence.

Le travail est loin d’être terminé, mais GNOME 3.30, dont la sortie est prévue pour le mois de septembre prochain, devrait, à n’en pas douter, être bien plus léger et réactif qu’il ne l’est actuellement.

Ceux qui souhaitent en apprendre plus peuvent consulter les billets de blog (en anglais) d’Alberto Ruiz et de Carlos Garnacho.

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

genma : Chatonkademy - Billet N°3 - FreshRSS, Yunohost et plusieurs utilisateurs

mercredi 16 mai 2018 à 09:00

Série de billets sur le projet Chatonkademy

Dans ce billet je voudrais parler du cas de FreshRSS sur Yunohost avec plusieurs utilisateurs. Pour rappel, FreshRSS est une application de type agrégateur RSS, fort pratique (on peut se connecter dessus via son API pour avoir une application mobile avec EasyRSS (voir Yunohost, FreshRSS et EasyRSS pour Android).

A la suite de la création et de l'installation de l'instance Yunohost, j'ai créer un utilisateur pour moi (Genma), qui est l'utilisateur par défaur puis installer différentes applications dont FreshRSS. J'ai ensuite fait la création des utilisateurs en masse (une quarantaine) sur cette instance.

L'application n'est pas une application publique et partagée, chaque utilisateur a donc l'application disponible pour lui et aura la gestion de son propre contenu.

Le soucis est que les différents utilisateurs au moment du premier usage de FreshRSS (et des fois suivantes), rencontraient différents soucis : pas de possibilité d'importer un fil RSS, pas de possibilité de changement de langue...

La solution est de reprendre le répertoire FreshRSS de l'utilisateur qui était là à l'installation de FreshRSS et de dupliquer ce répertoire nécessaire au bon fonctionnement de FreshRSS.

Cela se fait via

cd /var/www/freshrss/data/users
# On prend comme liste d'utilisateurs ceux qui ont un dossier dans /home (créer automatiquement par Yunohost, à l'exception des dossiers Yuno*
for user in `ls /home -I yuno*` do
# On copie le dossier existant de l'utilisateur qui était initialement présent avant l'installation de FreshRSS
cp -R genma/ $user
# on change les droits car il faut que ce soit www-data le propriétaire du dossier
chown -R www-data: ./$user
done

On remarque donc que les données pour l'application FreshRSS dans Yunohost se trouvent dans le dossier /var/www/freshrss/data/users/
Ces données sont un fichier config.php qui contient des préférences / paramétrage de l'application et un fichier de log, log.txt qui contient des logs spécifiques à l'application (différents des logs liés à nginx qui se trouvent dans /var/log/nginx/).

Les données (fils RSS auxquels on est abonné, catégorie, lu ou non lu...) sont dans la base de données et sont bien sauvegardées par le script de l'application. Seul le paramétrage de l'interface n'est donc pas sauvegardé par défaut. A prendre en compte dans le processus de sauvegarde.

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

Articles similaires