Auteur/autrice : Enguerrand

Pas de commentaire

VMware et Powershell : détection de snapshots anciens et surveillance de l’espace libre

  de

PowerCli est un excellent outil pour faciliter l’administration et la maintenance d’une infrastructure VMware. Il m’arrive d’écrire des scripts pour un client ou pour moi-même en fonction de tâches que j’ai à réaliser. Dans ce billet, je vais partager aujourd’hui deux petits scripts tout simples.

Le premier permet de scanner les VM présentes sur l’ESX ou le vCenter et d’envoyer un courriel si un snapshot est plus ancien qu’un certain nombre de jours. Par défaut, si un snapshot existe sur une machine virtuelle, un mail est tout de même envoyé.

Add-PSSnapin VMware.VimAutomation.Core
$From = "admin-vmw@localhost"
$To = "supervision@localhost"
$Smtp = "smtp.localdomain"
$Delay = 7

Connect-VIServer $ESXserver -User $ESXUser -Password $ESXPwd

$VMNamesArray = Get-VM | select Name
foreach ($VMName in $VMNamesArray)
    {
    $VMSnaps = Get-Snapshot $VMName.name
    foreach ($Snap in $VMSnaps)
        {
        $now = Get-Date
        if ($Snap.Created.AddDays($Delay) -gt $now -eq $false)
            {
            $SnapVM = $Snap.VM
            $MailString = "Bonjour, le snapshot '$Snap' de la machine '$SnapVM' existe depuis plus de $Delay jours."
            Send-MailMessage -From $From -To $To -Subject "Alerte snapshot" -SmtpServer $Smtp -Body $MailString
            }
        else
            {
            $MailString = "Aucun snapshot datant de plus de $Delay jours existant."
            Send-MailMessage -From $From -To $To -Subject "Rapport snapshot" -SmtpServer $Smtp -Body $MailString
            }
        }
    }

Le second script analyse les datastore de l’ESX ou du vCenter et envoie un mail si jamais il y a dépassement du seuil prédéfini. Il me semble que les préconisations VMware font état d’un besoin minimal de 20% de libre sur un datastore pour assurer le fonctionnement optimal de celui-ci. Le script va envoyer un courriel si jamais un datastore tombe à moins de 25% d’espace libre. 

Add-PSSnapin VMware.VimAutomation.Core
$From = "admin-vmw@localhost"
$To = "supervision@localhost"
$Smtp = "smtp.localdomain"
$SeuilAlerte = 25

Connect-VIServer $ESXserver -User $ESXUser -Password $ESXPwd

$DatastoreArray = Get-Datastore
foreach ($Datastore in $DatastoreArray)
    {
    $MBAvail = $Datastore.FreeSpaceMB
    $MBTotal = $Datastore.CapacityMB
    $FreeProp = ($MBAvail/$MBTotal) * 100
    if ($FreeProp -lt $SeuilAlerte)
        {
        $FreeProp = [math]::Round($FreeProp,1)
        $MailString = "Bonjour, le datastore '$Datastore' n'a plus que $FreeProp % de libre."
        Send-MailMessage -From $From -To $To -Subject "Alerte occupation Datastore" -SmtpServer $Smtp -Body $MailString
        }
    }

Vous pouvez récupérer les scripts depuis mon miroir de téléchargement dans des versions commentées :
Script d’alerte snapshot
Script d’alerte datastore

Pas de commentaire

Plus de réseau sur Debian Jessie

  de

Alors que je souhaitais faire un petit tour de passe-passe sur mes machines GNU/Linux afin d’y faire les mises à jour des paquets, j’ai été surpris de ne pouvoir me connecter en SSH à l’une de mes machines.

Je tente alors de la joindre par un ping, et pas de réponse. Les requêtes ICMP atterrissant bien à la normale sur le serveur, j’ai pensé à un crash sévère de la machine ou de l’interface réseau. Je lance alors la console VMware et arrive sur le prompt du login sans soucis.

Une fois connecté, un petit ifconfig me renvoie les informations suivantes :

Je comprends pourquoi ma machine est injoignable : pas d’IP affectée, pas même une IPv6. Normalement, tout est géré par DHCP, les serveurs Linux ayant un bail permanent (les machines Windows en IP fixe afin de pouvoir avoir en DNS primaire le serveur ActiveDirectory et en secondaire l’appliance pfSense, bien qu’ils aient en secours un bail DHCP fixe aussi).

Naturellement, un ping de mon appliance pfSense ainsi que du DNS Windows ne renvoient rien. Par ailleurs, je voulais tenter un ifdown eth0 et un ifup eth0, sans succès vu que l’interface eth0 ne semble pas être configurée tout court.

Tout d’un coup, mon cerveau fait tilt, et je me souviens avoir déconnecté tous les lecteurs optiques des VM une fois les installations des OS terminées. Or, sur le client web ESXi, la case de déconnexion du lecteur optique est juste en dessous… de la case de déconnexion de la carte réseau.

Une fois la carte réseau connectée suite à cette fausse manipulation, un petit redémarrage du serveur (bien que je pense qu’un simple redémarrage du service networking aurait suffit) et la connectivité réseau est revenue !

Pas de commentaire

Mise en place d’OpenFire sur Debian Jessie

  de

Depuis quelques temps, je cherchais une solution de chat permettant de m’affranchir de Facebook et des autres plateformes comme WhatsApp ou Skype, afin de pouvoir satisfaire ma curiosité à ce sujet et essayer de convertir une partie de mes proches sur un outil de chat peut-être moins fringuant mais plus privé et personnel.

Après quelques recherches, je me suis donc orienté vers OpenFire qui est un serveur utilisant le protocole XMPP, qui fonctionne sous Windows, GNU/Linux et OS X. Dans mon cas précis, je vais réaliser l’installation de ce serveur sur un système d’exploitation Debian dans sa version Jessie (8.7).

1. Prérequis

 

Une fois l’OS de base installé, j’ajoute toujours par habitude fail2ban et proftpd, afin de pouvoir protéger le serveur par la suite et proftpd afin de faciliter le dépôt de fichiers sur la machine depuis mon filer. Ma machine étant hébergée sur un ESXi, j’installe les VMware tools.

apt-get install fail2ban
apt-get install proftpd
apt-get install open-vm-tools

A noter que par la suite, j’ajouterai certaines règles à fail2ban afin qu’il surveille les tentatives d’authentification sur le serveur OpenFire lui-même.

Dans un même souci de sécurité, je vais désactiver la connexion en root sur le serveur via SSH :

nano /etc/ssh/sshd_config

Je modifie de cette manière la ligne suivante (ancienne valeur en rouge, nouvelle valeur en vert) :

PermitRootLogin without-password
PermitRootLogin no

 Puis, un redémarrage du serveur SSH pour prendre en compte la modification :

/etc/init.d/ssh restart

Plus tard, lors de la configuration, je vais choisir l’authentification par ActiveDirectory. J’ai donc créé dans mon AD un groupe « OpenFire Users » avec le compte utilisateur dont je vais me servir afin de pouvoir me connecter à l’application. Pour des raisons de sécurité, je ne vais pas utiliser le même compte que mon compte usuel sur ma plateforme Windows mais un utilisateur tout simple. Je vais également créer un compte de service qui permettra à l’application d’avoir un accès en lecture seule uniquement à l’AD, afin de ne pas avoir à renseigner le compte d’administrateur du domaine ou mon compte d’administration personnel. Pour ce faire, je vais passer par une délégation de contrôle.

Clic droit sur le domaine « domaine.local » puis Délégation de contrôle

En choisissant le compte de service en question sur le domaine, je vais créer une tâche personnalisée à déléguer, sur ce dossier et les objets qui s’y trouvent. Enfin, je vais accorder les autorisations en lecture, en cochant Lire et Lire toutes les propriétés. Si tout s’est bien passé, le compte de service pourra lire le contenu du domaine.

2. Installation

 

Le paquet pour Debian fourni par l’éditeur d’OpenFire ne contient pas l’environnement Java nécessaire. Il faut donc l’installer préalablement. Etant donné que mon système est tout juste installé, je n’ai pas pris la peine de réaliser un apt-get update avant de lancer la commande suivante :

apt-get install default-jre

apt va installer la JRE présente dans les dépôts de Debian. La version requise par l’application est la version 1.7. Un simple java -version permet de renvoyer la version installée :

Une fois dans le répertoire dans lequel j’ai calé le paquet, un petit dpkg -i et l’installation se déroule. J’obtiens une notification comme quoi le répertoire créé pour l’utilisateur ne lui appartient pas : j’affecte un password à l’utilisateur et le rend propriétaire de son répertoire.

3. Configuration

 

L’installation étant terminée, j’ouvre donc un navigateur afin d’accéder à l’installateur web, qui va s’occuper de la création de la configuration de base ainsi que de la base de données. J’ai laissé les paramètres par défaut (encryption Blowfish, et les ports de la console d’administration, qui de toutes façons ne seront pas routés vers l’extérieur). 

Concernant la base de données, si je voulais utiliser mon serveur MySQL, vu le peu de criticité et de besoin pour l’instant, je me suis retourné vers une base de données embarquée. Si selon l’éditeur les performances sont en retrait, cela m’importe peu dans le cadre de mon utilisation personnelle. Je verrai éventuellement pour déporter la partie base vers mon serveur MySQL si l’envie m’en prend.

Vient ensuite la partie authentification. Je vais me baser sur mon domaine ActiveDirectory. La connexion se passe sans accrocs grâce aux autorisations que nous avons accordées durant les prérequis. Les DN (distinguishedName) se déduisent facilement ou peuvent être trouvées grâce à ADSI Edit.

Je laisse par défaut les configurations de mapping utilisateur et groupes, puis je spécifie temporairement mon compte comme administrateur de l’application. Je créerai un compte d’administration de l’application plus tard.

 

4. Administration

 

En me connectant avec le login déclaré comme administrateur de l’application, je peux parcourir les différents réglages de l’application. Les délégations permettent à l’application de bien parcourir le domaine, cependant l’application ne gère pas l’écriture dans un annuaire LDAP, par conséquent, la création d’utilisateurs, la modification de mot de passe ou autres opérations ne sont pas possibles ; il faudra se connecter sur une console ActiveDirectory pour procéder à une quelconque manipulations sur les comptes.

La première chose que je vais réaliser est un blocage des comptes d’utilisateurs qui ne sont pas dans le groupe « OpenFire Users » que j’ai créé au départ. Ainsi, des utilisateurs peuvent se connecter à l’application sans avoir forcément de comptes sur mes machines, ou un accès à une machine ne donne pas forcément d’accès à l’application.

L’option est des plus explicites. Dans la liste des utilisateurs visibles, on y retrouve un icône en plus d’avoir son nom barré pour signifier que cet utilisateur n’aura pas d’accès à l’application.

Ensuite, étant donné que je suis situé derrière un pare-feu et que j’utilise le NAT pour n’utiliser qu’une seule IP pour toutes mes machines virtuelles, je vais devoir faire quelques opérations de routage sur mon appliance pfSense (que j’aurai l’occasion d’aborder dans un futur billet). Dans l’interface d’administration, chaque port est plutôt bien détaillé.

Je vais changer les ports qui ont été inscrits par défaut, et en profiter pour forcer des connexions sécurisées afin que les données ne transitent pas en clair sur le réseau. En fonction de mes besoins au départ, il y a des connexions que je ne vais pas autoriser. Quelques paramètres de sécurité méritent également le détour (qui peut se connecter, plages IP autorisées, inscriptions en ligne…).

5. Tests de connectivité cliente

 

Maintenant que tout est configuré côté serveur – même si il y a sans doute de quoi peaufiner – il ne reste plus qu’à faire un essai en local, et un essai depuis le web.
Je réaliserai l’essai en local depuis une machine virtuelle Debian. Le client qui se connecte à OpenFire s’appelle Spark et il est édité par la même communauté. Tout comme le serveur, le client est disponible sur Windows, OS X et GNU/Linux. Et tout comme le serveur, le paquet pour Debian est livré sans Java, il faudra donc l’installer à part. Java étant déjà installé sur ma machine, je suis donc parti pour un dpkg -i du paquet spark, cependant, je me suis heurté à un mur :

 

J’ajoute dans ma liste de dépôts les dépôts jessie-backports sans oublier de les rafraîchir juste après :

deb http://ftp.fr.debian.net/debian jessie-backports main

Puis, je lance un aptitude install -s afin de simuler une installation du paquet et de voir exactement ce qui merde. En cause, des dépendances non satisfaites à cause de la différence de version entre les paquets dans la branche usuelle et la branche backports de Jessie.

aptitude install -s permet de simuler une installation des paquets pour diagnostiquer ce qui ne fonctionne pas correctement.
Je finis par accepter l’installation de ce paquet dans la version la plus récente, disponible dans le dépôt ajouté précédemment.
Le paquet s’installe bien.

Enfin, je peux conclure en installant le paquet Java final.

Je peux enfin réaliser mon dpkg -i spark_2_8_3.deb et exécuter l’application.

Vu que je ne possède pas de certificats, je vais cocher les deux options pour accepter tous les certificats et pour ne pas vérifier le nom du serveur afin de pouvoir me connecter. Je saisis ensuite mes identifiants… Et ça marche !

Il ne me reste plus qu’à réaliser un test de connexion depuis l’extérieur, ajouter les quelques règles fail2ban si nécessaires… et demander à mes proches d’installer cette petite appli pour discuter en tout temps. Le serveur étant plus orienté utilisation professionnelle que personnelle, il n’y a pas d’application tout du moins sur iOS.

Pas de commentaire

Installation de TrueCrypt 7.1 sur OS X 10.10 et suivants

  de

J’utilise TrueCrypt comme solution de cryptage de données depuis quelques années. Outil gratuit et indépendant de tout OS (fonctionne sur Windows, OS X et GNU/Linux), je le trouve léger, fonctionnel et fiable, malgré les rumeurs qui ont conduit les développeurs à abandonner le projet. VeraCrypt semble être le fork reprenant TrueCrypt cependant par habitude j’utilise toujours TrueCrypt.

Cependant, comme TrueCrypt est assez vieux et qu’il n’a pas été mis à jour depuis 2014, son installation sur un système OS X récent est problématique. En effet, le package refusera de s’installer car il considère que la version d’OS X est trop vieille. En cause, dans le code d’initialisation du paquet, un contrôle caduc de la version d’OS X, en se basant sur la chaîne elle-même de la version de l’OS et non la valeur décimale. Ce qui signifie qu’en s’exécutant sur un OS X 10.10, 10.11 ou 10.12, l’application jugera que votre version est plus vieille que 10.4, car par ordre alphabétique, 10.10 est avant 10.4.

Afin de pouvoir installer l’application, il va donc falloir modifier ce bout de code afin de supprimer le contrôle.

Tout d’abord, il faut monter l’image disque, puis copier le fichier d’installation .mpkg. Dans cet exemple, je le copierai sur le bureau.

 

En « affichant le contenu du paquet », on va dérouler le répertoire Contents et modifier le fichier distribution.dist grâce à TextEdit ou n’importe quel autre éditeur de texte. Au début de fichier, la fonction pm_install_check est celle qui pose problème.

 

En supprimant la partie du code écrite en rouge, l’installateur ne fera plus de vérification de la version d’OS X. Il suffit d’enregistrer le fichier (si vous avez bien copié le fichier .mpkg dans un répertoire pour lequel vous avez les autorisations d’écrire, cela ne devrait pas poser de problèmes, c’est pourquoi il faut le sortir du fichier .dmg monté) et de relancer le fichier .mpkg afin que l’installation s’exécute sans anicroche.

function pm_install_check() {
  if(!(system.version.ProductVersion >= '10.4.0')) {
    my.result.title = 'Error';
    my.result.message = 'TrueCrypt requires Mac OS X 10.4 or later.';
    my.result.type = 'Fatal';
    return false;
  }
  return true;
}

Si vous voulez télécharger TrueCrypt dans sa dernière révision avant la version modifiée par les développeurs afin qu’elle ne gère plus l’écriture, je vous renvoie vers ce lien. Si vous ne souhaitez pas réaliser la modification du code vous-même, je mets à disposition sur mon miroir à la fois le fichier .dist modifié (il ne reste plus qu’à le copier-coller dans le .mpkg) ou alors le fichier .mpkg qu’il ne vous restera plus qu’à exécuter pour installer l’application.