Infomaniak propose une alternative à Wix qui simplifie radicalement la création d'un site et d'une boutique en ligne. Il n'a jamais été aussi facile et rapide de lancer son activité en ligne.
Quel page builder pour WordPress ? Cet article résume tout ce que vous devez savoir pour choisir le meilleur constructeur de pages pour votre site WordPress, en privilégiant la fiabilité sur le long terme.
Aujourd’hui, et pour recommencer en douceur, nous allons découvrir le paquet unattended-upgrades qui permet comme son nom l’indique de de pouvoir obtenir les mises à jour de sécurité/mises à jour classiques de manière automatique.
Idéal si vous désirez automatiser un tant soit peu les mises à jour de vos différents serveurs persos donc.
I) Installation du package
Disponible de base dans les dépôts, un simple apt install suffit :
Et le tour est joué ! A noter que ce package est naturellement disponible pour Ubuntu, Mint, et autres dérivés.
II) Configuration
Rien de très sorcier, le fichier de configuration se situe ici : /etc/apt/apt.conf.d/50unattended-upgrades.
La première section concerne les différents dépôts qui vont être utilisés. Par défaut, sur une Debian 10 classique, il n’y aura que les dépôts Debian et Debian-Security d’activés. Libre à vous bien-entendu d’ajouter d’autres dépôts personnels si vous le désirez.
La seconde section concernant les paquets que l’on ne souhaite pas mettre à jour automatiquement via cet outil, c’est-à-dire les paquets à blacklister :
Comme on peut le voir, il suffit d’écrire le nom du package, en rajoutant bien le « $ » pour signifier la fin de son nom.
Enfin, les autres sections restantes sont orientées bidouillage :
On peut par exemple faire en sorte d’installer les mises à jour seulement lorsque la machine s’éteint, on peut activer les notifications par mail (en cas de réussite ou non), on peut supprimer automatiquement les anciens kernels non-utilisés… la liste est longue.
Une fois votre configuration aux petits oignons terminée, on peut passer à son activation. Pour cela on copie le template et on l’édite :
Concernant la modification de ce fichier, rien d’insurmontable ici :
Rajoutez simplement la première ligne, permettant d’activer l’outil, et concernant les deux autres lignes elles indiquent simplement la fréquence à la quelle mettre à jour la liste des paquets dans les dépôts, et à quelle fréquence upgrade les paquets présents sur le système (0 pour désactiver, et X pour tout les X jours, ici j’ai mis chaque semaine).
III) Exécution de l’outil
Pour tester sa bonne mise en place, on peut démarrer l’outil manuellement. Comme on peut le voir sur la capture d’écran ci-dessous, aucun paquets n’est à blacklister, et aucune whitelist n’a été fournie.
sudo unattended-upgrade -d
Et c’est tout ! Désormais vos systèmes se mettront à jour de manière automatique.
C’est tout pour ce rapide article, d’autres plus conséquents arriveront très vite !
Il m’est arrivé de me rendre compte sur l’un de mes serveurs Windows, que ce dernier affichait « Batterie en charge »… sauf qu’il s’agit d’un serveur au format rackable. Un peu étrange non ? Vérifiez par vous-même, vous risquez d’être surpris !
Bon pour ceux connaissant la réponse (mais au vu des nombreux posts dans les forums, ça ne semblait pas forcément tomber sous le sens), pas de magie noire ou de bug ici, simplement le fait que WS détecte l’UPS branché comme étant une batterie, et vous affiche donc sa charge et le pourcentage correspondant…
D’ailleurs, il existe une petite commande Powershell permettant de voir quelle(s) batterie(s) Windows détecte au juste :
wmic path Win32_Battery get Caption,Description,DeviceID,Name
Bref, rien d’incroyable mais j’avoue que cela avait piqué ma curiosité !
Sur ce, à bientôt pour des articles (je vous rassure) plus fournis que celui-ci !
Installation du logiciel de gestion de parc informatique Open Source.
GLPI, pour Gestionnaire Libre de Parc Informatique, est… et bien son nom l’indique ! Un logiciel qui va nous permettre d’inventoriser notre parc informatique, le tout de manière gratuite et libre.
Je ne vais pas le détailler de fond en comble tant celui-ci est connu dans le monde Open Source, mais ce dernier va nous permettre de :
Gérer un inventaire de nos différentes machines et équipements, des laptops aux écrans, en passant par les serveurs, les dockings… ;
Obtenir une vue de nos différents racks informatiques, avec la possibilité de voir le nombre de baies encore disponibles ;
Encoder les différentes factures d’achats, et les relier aux différents équipements ;
Gérer l’aspect Helpdesk via un système de ticketing, même si personnellement je préfère la solution Hesk à cet égard ;
. . .
La liste est encore longue, d’autant plus avec les nombreux plugins mis à disposition !
Courant avril la version 10.0 est sortie, et pour ceux connaissant déjà GLPI, voilà à quoi l’interface ressemblait il y a plusieurs années…
Tiré de https://forum.glpi-project.org
Pas forcément très séduisant n’est-ce pas ? Et bien désormais, c’est une véritable refonte graphique qui a eut lieu ! Regardez ce changement ! (En plus de plusieurs optimisations et fonctionnalités majeures rajoutées!)
Tiré de https://glpi10.fr
Quand même un sacré changement non ? Je comptais depuis plusieurs mois voir années faire un article sur son installation, et avec cette mise à jour majeure récemment sortie, je m’y suis donc enfin mis.
Sans plus attendre, allons-y !
I) Installation de GLPI
Nous partirons sur une classique debian 10, et une fois celle-ci installée et configurée de manière basique, nous allons pouvoir commencer à nous atteler à l’installation de notre soft.
Tout d’abord, les prérequis :
Un serveur web, dans notre cas ce sera un classique apache ;
Une base données, ici ce sera mariadb ;
PHP 7.4 à 8.1, concernant la version 10.0 que nous allons installer. Au passage, en voulant installer la version 8.0 j’ai obtenu un joli « PHP 7.4.0 – 8.2.0 (exclusive) required« , donc nous allons installer la version 7.4 spécifiquement… ;
Sous Debian 10, en installant simplement le package « php« , la version 7.1 sera installée, nous allons donc installer manuellement la version 7.4.
# Serveur web et SGBD
apt update && apt install apache2 mariadb-server -y
Passons ensuite à la configuration de notre base de données !
# Pour définir un mot de passe root, et faire les réglages de base
mysql_secure_installation
# On se connecte en CLI
mysql -u root -p
# On créé notre base de données et son utilisateur
create database glpi ;
create user 'glpi-user'@'localhost' identified by 'Pa$$W0Rd' ;
grant all privileges on glpi.* to 'glpi-user'@'localhost' ;
flush privileges ;
Bien-entendu, libre à vous de choisir un nom spécifique pour votre base de données, votre utilisateur, ainsi qu’un mot de passe.
On peut ensuite télécharge l’archive contenant la dernière version stable de GLPI (à l’heure où j’écris ces lignes) :
On décompresse le tout, et on set les droits pour le serveur web :
gunzip glpi-10.0.1.tgz
rm glpi-10.0.1.tgz
rm -r /var/www/html/
cp glpi-10.0.1.tar /var/www/ && cd /var/www/
tar xvf glpi-10.0.1.tar
mv glpi html
chown -R www-data:www-data html/
Une fois le tout installé, on peut passer directement à l’interface web pour la finalisation !
Je vous conseille cependant d’aller lire la documentation, qui stipule de ne pas directement se ruer sur l’interface web, mais d’effectuer diverses configurations supplémentaires au niveau sécurité. Ici cela reste un lab/une présentation, mais toujours bon de le mentionner !Surtout que leur doc’ est plutôt bien fournie.
II) Configuration de l’instance GLPI via la WebUI
Une fois notre langue choisie, on peut choisir l’option Install ou Update, ici ce sera donc Install :
Nous avons ensuite droit à un récapitulatif des extensions éventuelles manquantes, soit obligatoires, soit facultatives :
On renseigne ensuite les informations concernant notre base de données, ici elle est installée en local donc nous utiliserons 127.0.0.1 bien-entendu :
On choisi notre base de données sur laquelle notre utilisateur a les droits :
Et le tour est joué !
On peut ensuite éventuellement envoyer les statistiques d’usage, s’inscrire, expliquer comment nous avons connu GLPI… classique.
Puis un petit récap’ sur les identifiants et mots de passe par défaut, à changer une fois connecté bien-sûr :
III) Connexion à l’interface web
Le login par défaut pour le compte admin étant donc glpi/glpi, nous pouvons nous connecter et tadaaaa :
On notera les deux petits warnings, un concernant le changement de mot de passe par défaut (logique), et l’autre concernant la suppression du fichier d’installation.
IV) Conclusion
Vous avez donc terminé d’installer votre instance GLPI ! Bien-entendu, diverses optimisations sont possibles, et je n’ai pas parlé des plugins, cet article était avant tout une découverte et un tuto sur son installation.
Comme d’habitude, j’espère vous avoir appris quelques bricoles, et essayez de toujours privilégiez l’Open Source, ça en vaut la peine
Aujourd’hui nous allons voir comment migrer une machine virtuelle Windows Server 2012 R2 depuis un Hyper-V (version 2019) vers un Proxmox en version 6.4.4.
I) Le lab et rapides explications~
Rien de très sorcier ici :
PVE 6.4.4 : 192.168.0.100/24 ;
Hyper-V 2019 : 192.168.0.110/24 ;
VM ActiveDirectorysous WS2012 R2: 192.168.0.150/24 ;
Côté AD, je n’ai créé qu’un ou deux utilisateurs, ainsi que deux OUs. L’important est vraiment de s’assurer qu’après la migration les users soient toujours là, mais en pratique aucun soucis. D’ailleurs, nous verrons une commande pour vérifier si le disque virtuel ne présente pas de corruptions (toujours utile à savoir, surtout qu’en production ce ne sera pas de simples disques de 30Go que vous allez migrer, mais des disques faisant plusieurs Téraoctets…).
II) Copie du disque VM vers le nœud Proxmox
Bien, une fois votre VM installée et votre AD un peu peuplé, on peut stopper la machine virtuelle, puis copier son disque.
Deux OUs, et deux users, classique.
Pour copier le disque il n’y a pas de manipulations particulières, simplement copier le .vhdx, car même si la documentation de Proxmox ne parle que de .vhd, ce dernier supporte tout à fait les .vhdx. Aucun soucis donc.
Sachez cependant qu’une applet Powershell existe pour convertir un .vhdx en .vhd, si vraiment le besoin s’en fait sentir.
Si vous devez copier un disque de gros volume, le plus simple est encore de le copier sur un volume partagé, avec une liaison Gigabit voir 10-Gigabit. Sinon, dans le cadre de ce lab, un simple scp suffit :
Ici je copie directement le disque depuis mon hôte Hyper-V, à destination de mon nœud Proxmox, dans le dossier root.
Si vous vous posez la question « quid si la VM possède plusieurs disques ?« , et bien en théorie pas de soucis, la marche à suivre sera sensiblement la même, mais ne l’ayant pas encore pleinement testé à l’heure où j’écris ces lignes, je ne peux vous le garantir. Sûrement un prochain article !
III) Re-création de la VM côté Proxmox
La première étape est donc de re-créer une VM, en essayant dans la mesure du possible de reprendre les mêmes configurations hardware (si votre VM avait 4Go de ram, ne pas lui en mettre 2, ou même 8, en tout cas au départ, etc.)
On créer donc notre VM, de sorte que :
L’OS Invité choisi soit de type Windows (ou Linux si votre VM était une Linux, cela tombe sous le sens) ;
Pas encore d’image ISO à attacher ;
Au niveau de la carte graphique, j’ai lu que SPICE était assez souvent utilisé, mais ici je garderai le standard sous peine d’avoir un curseur qui n’en fait qu’a sa tête… ;
Concernant le Contrôleur SCSI, bien choisir VirtIO SCSI ;
Concernant le BIOS, opter plutôt pour l’OVMF/UEFI ;
Concernant le disque, ce n’est pas important car une fois notre VM créée celui-ci sera supprimée pour être remplacée par notre .vhdx fraîchement copié ;
Concernant le driver réseau, privilégiez Virtio(paravirtualisé) ;
Terminer, sans démarrer d’ores et déjà la VM ;
Je ne l’ai pas dit plus haut pour ne pas vous embrouiller, mais dans l’état, si l’on démarre notre VM, Windows ne détectera pas le disque ni la carte réseau. La raison est que nativement, les drivers VirtIO ne sont pas inclus dans Windows. Nous avons donc deux choix :
Installer les drivers VirtIO sur la VM avant de copier son disque ;
Démarrer tout de même la VM, puis installer les drivers par la suite ;
Je n’ai pas encore testé la première option, nous partirons donc sur la seconde. Mais avant de vouloir démarrer le tout et installer tel ou tel driver, nous devons rattacher notre ancien disque !
Bien, la première étape est de supprimer le disque de notre VM actuelle :
On le détache, puis on le supprime.
Une fois fait, on se connecte en CLI sur notre nœud Proxmox pour rattacher notre disque « Hyper-V » sur notre nouvelle VM :
qm importdisk 100 /root/srv-ad-01.vhdx local-lvm
On utilise donc l’utilitaire qemu pour importer notre disque sur la VM ayant l’ID 100, à adapter selon votre VM donc. Ensuite, on renseigne le chemin vers ce disque, et en dernier lieu on indique le datastore sur lequel il va être stocké. Ici il s’agit du datastore de base, local-lvm. Mais si vous utilisiez Ceph par exemple, cela aurait pu être rbd-datastore-24, ou que sais-je.
On patiente pendant l’import (qui peut parfois durer très longtemps !), et une fois fait, nous pourrons le rattacher à notre VM.
Au passage, voici la commande pour vérifier l’intégrité d’un disque, toujours pratique à effectuer avant de l’importer sur notre datastore :
qemu-img check srv-ad-01.vhdx
Extrêmement simple à réaliser, mais toujours important !
Bien, retournons donc sur les paramètres de notre machine virtuelle :
On clique donc sur Éditer, puis on choisi bien le contrôleur VirtIO SCSI. On peut éventuellement activer l’émulation SSD, le caching, ou autre.
On touche désormais presque à la fin !
IV) Démarrage de la VM et installation des drivers OpenSource VirtIO
Comme dit précédemment, il vous faudra des drivers à installer, tout dû moins pour le disque, et éventuellement pour la carte réseau si vous avez aussi choisi VirtIO. Rien de compliqué je vous rassure !
On télécharge l’ISO contenant les différents drivers VirtIO ici : https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/
*Pour ma part, j’ai choisi la version 215-2, car la dernière en date ne fonctionnait pas.
Une fois l’ISO téléchargé, on l’upload sur notre Proxmox, et on le rattache à notre machine virtuelle. On peut enfin modifier l’ordre de boot, et nous pourrons démarrer !
Ici j’ai désactivé le boot via PXE mais pas via CD, car nous voulons que notre VM boot sur notre disque, mais si on ne sélectionne pas notre lecteur CD, l’ISO ne montera pas au boot…
Au démarrage, votre Windows plantera. Puis encore une fois, et même éventuellement une troisième fois.
C’est normal ! Rappelez-vous, il n’a pas encore les drivers adéquats… cela nous permettra d’afficher le mode Rescue de Windows, et d’accéder à une invite de commandes :
Au passage, il se peut que votre curseur n’en fasse qu’à sa tête… cela peut venir du fameux pilote SPICE choisi pour la carte graphique, si vous n’avez pas choisi le standard.
Bien, on va donc maintenant installer le driver concernant notre disque SCSI VirtIO :
drvload D:\vioscsi\2k12R2\amd64\vioscsi.inf
A noter que la commande sera identique peut importe la version de Windows utilisée :
Et le tour est joué ! Ni plus, ni moins. On peut clôturer ce terminal et poursuivre le boot de manière normale :
Et voilà, votre VM Windows Server 2012 R2 migrée depuis votre Hyper-V s’allume sous vos yeux !
Cependant, comme pour le disque, il n’y a pas encore le driver correspondant à la carte réseau. Mais étant donné que notre ISO VirtIO est toujours rattaché à notre machine, rien de plus simple :
Il nous suffit d’exécuter le binaire virtio-win-gt-x64, et de choisir les drivers souhaités ! Selon plusieurs forums, il vaut mieux éviter d’installer le driver concernant le Ballooning, et de mémoire lorsque j’avais installé Proxmox sur un serveur dédié avec pfSense et autre (il y a de ça presque trois ans), j’avais aussi des soucis avec, donc autant prendre des précautions et ne pas l’installer, beaucoup se plaignant de dégradations de performances.
Comme on peut le voir, la carte réseau est désormais bien reconnue est fonctionnelle :
Et concernant notre AD lui-même, nos OU et users sont toujours bien là :
V) Conclusion
Et bien voilà, vous avez réussi à migrer un DC depuis Hyper-V vers Proxmox. Félicitations ! Comme vous le voyez, il n’y a rien de très sorcier, et plus encore si les drivers VirtIO sont installés avant la copie du disque de la VM (je n’avais pas testé avant de conclure cet article, mais je confirme que cela fonctionne).
Bref, au moins vous aurez les deux façons de faire !
Bien-entendu, c’était une première pour moi, et cela a été fait dans le cadre d’un lab. Impossible de dire si les performances seront équivalentes à Hyper-V, si certaines options peuvent être poussées plus loin en terme d’optimisation… libre à vous de donner votre grain de sel en commentaire ! J’y répondrais avec plaisir comme d’habitude.
Sur ce, je vous souhaite une bonne journée/soirée, et n’arrêtez pas d’expérimenter~
Connexion
Infomaniak propose une alternative à Wix qui simplifie radicalement la création d'un site et d'une boutique en ligne. Il n'a jamais été aussi facile et rapide de lancer son activité en ligne.