On va s’écarter un peu du sujet DevOps, pour traiter des environnements clos.
Imaginons que vous êtes dans un environnement clos sans connexion internet mais que vous voulez installer un rpm qui demande une foule de dépendances (genre glibc … ).
La solution utilisé par chroot est possible, et pour cela il vous faut : Continue reading
Après m’être étendu sur Docker et sa facilité de déploiement pour les stacks complexes, je vais vous parler d’Ansible pour rajouter une couche d’automatisation aux déploiements.
La première chose à faire est de vous mettre un lab à disposition, quelques VMs feront l’affaire, et comme d’habitude je me concentrerai sur des CentOs 7+.
Ansible est une solution en ligne de commande qui ne s’appuie pas sur l’installation d’agent sur le machines cibles, mais bosse uniquement par la voie (royale) de SSH. Pour cela Ansible est bien plus facile a appréhender que les concurrents (Puppet, Chef, CFEngine, …) et tout aussi puissant.
Avant de commencer, je suis obliger de vous mettre en garde sur le développement rapide (trop) d’Ansible et des versions associées de python. Une installation via les package risque de vous causer quelques désagréments.
Continue reading
Après une installation d’une Centos 7.2 sur une clé USB sur un HP EliteBook, ou après un yum upgrade qui touche au kernel (donc au grub) je me suis retrouvé avec un boot qui m’affichait :
Failed to open \EFI\BOOT\grubx64.efi - Not Found Failed to load image \EFI\BOOT\grubx64.efi: Not Found start_image() returned Not Found
La faute à EFI/UEFI et secureboot qui s’intercale entre BIOS et BootLoader (Grub dans mon cas). Je vous passe la littérature abondante qui traite des différents moyens de contourner cette brique, mais je traiterai directement du moyen de récupérer un boot fonctionnel.
On commence par récupérer une distribution linux live qui bootera proprement puis direction la console.
Après un passage en root on va récupérer les informations de la clé usb (ou du hdd).
[liveuser@localhost liveuser]# su [root@localhost liveuser]# fdisk -l /dev/sdb WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion. Disk /dev/sdb: 62.7 GB, 62746787840 bytes, 122552320 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: gpt # Start End Size Type Name 1 2048 411647 200M EFI System EFI System Partition 2 411648 1435647 500M Microsoft basic 3 1435648 122550271 57.8G Linux LVM
Ensuite on monte la partition qui contient l’EFI
On continu la série Docker avec un article entièrement consacré à l’outil docker-compose.
Comme pour les articles précédents, toutes les commandes seront faites sur un serveur CentOs 7.
Le seul prérequis sera d’avoir une installation fonctionnelle de Docker sur le serveur.
yum install epel-release yum upgrade python* yum install -y python-pip pip install docker-compose
Avec ces commandes vous devriez voir apparaitre la version de docker-compose.
cyklo@testmachina:~$ docker-compose -v docker-compose version 1.11.2, build dfed245
Une fois que OpenVAS a été installé et configuré et qu’on le reprend en main un peu de temps après, il y a de fortes chances que vous soyez confrontés à ça au moment de lancer un scan :
503 - Service temporarily down
Ce qui est visible dans les logs
==> /var/log/openvas/openvasmd.log <== lib serv:WARNING:2017-04-24 07h44.56 UTC:5176: openvas_server_verify: the certificate is not trusted lib serv:WARNING:2017-04-24 07h44.56 UTC:5176: openvas_server_verify: the certificate has expired
Apparemment il faut régénérer et re-allouer les certificats au scanner utilisé.