Petite note pour définir avec PowerShell le nom convivial (friendlyname) d'un certificat.

Procédure

1) Identifier le certificat à configurer en utilisant la commande suivante (conserver la valeur Thumbprint pour la suite de la procédure) :

> Get-ChildItem Cert:\LocalMachine\My | fl

Subject : CN=*.adminmalin.fr
Issuer : CN=R3, O=Let's Encrypt, C=US
Thumbprint : C376287BB6EEF40E74FBF4D39EFA4BAC24031CB2
FriendlyName :
NotBefore : 12/04/2023 20:47:19
NotAfter : 11/07/2023 20:47:18
Extensions : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid...}

Subject : CN=WIN-M4BGKG2MRBA
Issuer : CN=WIN-M4BGKG2MRBA
Thumbprint : 04CEB668C3CED37E308983CF1B594DF01AFA7700
FriendlyName :
NotBefore : 30/01/2023 22:02:35
NotAfter : 29/01/2026 22:02:35
Extensions : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid}

Remplacer My par l'emplacement de votre choix. Pour connaitre les valeurs possibles, utiliser la commande suivante :

> Get-ChildItem Cert:\LocalMachine

2) Modifier le nom convivial du certificat (friendlyname) en utilisant la commande suivante :

> (Get-ChildItem -Path Cert:\LocalMachine\My\C376287BB6EEF40E74FBF4D39EFA4BAC24031CB2).FriendlyName = "OOS-Cert"

Remplacer l'empreinte par la valeur récupérée à l'étape 1) et la valeur FriendlyName par celle de votre choix.

3) Vérifier le changement de configuration en réutilisant la commande de l'étape 1) :

> Get-ChildItem Cert:\LocalMachine\My | fl

Subject : CN=*.adminmalin.fr
Issuer : CN=R3, O=Let's Encrypt, C=US
Thumbprint : C376287BB6EEF40E74FBF4D39EFA4BAC24031CB2
FriendlyName : OOS-Cert
NotBefore : 12/04/2023 20:47:19
NotAfter : 11/07/2023 20:47:18
Extensions : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid...}

Subject : CN=WIN-M4BGKG2MRBA
Issuer : CN=WIN-M4BGKG2MRBA
Thumbprint : 04CEB668C3CED37E308983CF1B594DF01AFA7700
FriendlyName :
NotBefore : 30/01/2023 22:02:35
NotAfter : 29/01/2026 22:02:35
Extensions : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid,

 

L’article PowerShell - Définir le nom convivial d'un certificat est apparu en premier sur Admin Malin.

Dans cet article, nous allons voir comment configurer le service DOCKER avec un proxy.

Procédure

Toute la procédure nécessite les droits root

1) Se connecter au serveur hébergeant le service Docker

2) Créer le répertoire suivant :

# mkdir /etc/systemd/system/docker.service.d

3) Créer le fichier de configuration suivant :

# vi /etc/systemd/system/docker.service.d/http-proxy.conf

4) Ajouter le contenu suivant (à adapter suivant votre environnement) :

[Service]
Environment="HTTP_PROXY=http://user01:password@10.10.10.10:3128/"
Environment="HTTPS_PROXY=https://user01:password@10.10.10.10:3128/"
Environment="NO_PROXY= repo.adminmalin.fr,10.20.40.45"

5) Recharger les nouvelles configurations :

# systemctl daemon-reload

6) Redémarrer le service Docker :

# systemctl restart docker

7) Finalement, pour vérifier le bon fonctionnement de la configuration :

# systemctl show docker --property Environment

 

L’article LINUX - Configurer un serveur proxy pour DOCKER est apparu en premier sur Admin Malin.

Occasionnellement, il peut être nécessaire de régénérer le certificat SSL d'un host ESXI en standalone. Heureusement, la procédure de renouvellement est très simple. Nous allons voir dans cet article comment procéder.

 

Procédure

1) Se connecter à l'host VMware ESXI en SSH

2) Sauvegarder l'ancien certificat (au cas ou) en utilisant les commandes suivantes :

# cd /etc/vmware/ssl
# mv rui.crt rui.crt.bkp
# mv rui.key rui.key.bkp

3) Renouveler le certificat

# /sbin/generate-certificates

4) Pour appliquer le nouveau certificat, redémarrer les services de gestion ou redémarrer l'host

Pour ne pas redémarrer l'ESXI, utiliser la commande suivante :

# services.sh restart

 

L’article VMware - Renouveler un certificat d'un host ESXI est apparu en premier sur Admin Malin.

Suite à plusieurs tests, le service gorgoned ne fonctionne plus correctement avec plusieurs de mes collecteurs. Le message d'erreur est le suivant : 2022-11-14 20:55:11 - ERROR - fingerprint changed for target... Nous allons voir comment corriger ça rapidement.

Les erreurs complètes sont disponibles dans le fichier de log suivant :
/var/log/centreon-gorgone/gorgoned.log

2022-11-14 20:55:11 - ERROR - fingerprint changed for target 'tcp://10.10.100.101:5556' [id: 1] [old fingerprint: tL55IsAkexyw2QwAFpUKxaXBcrvlnVL9Az775FAcZYw] [new fingerprint: tMUdBX-eQhlCAZq8TrSZ7fZqybFLTvV9J4HGXtY58c8]

2022-11-14 20:55:11 - ERROR - [proxy] Send message problem for '3': fingerprint changed for target 'tcp://10.10.100.101:5556' [id: 1] [old fingerprint: tL55IsAkexyw2QwAFpUKxaXBcrvlnVL9Az775FAcZYw] [new fingerprint: tMUdBX-eQhlCAZq8TrSZ7fZqybFLTvV9J4HGXtY58c8]

2022-11-14 20:55:11 - INFO - [proxy] PongReset received from '3'

Procédure

1) Se connecter sur le serveur ou l'erreur est présente

2) Installer l'utilitaire sqlite3.Sur un OS de type RH/Almalinux :

# dnf install sqlite

3) Se connecter à la base de données sqlite

# sqlite3 /var/lib/centreon-gorgone/history.sdb

4)  Mettre à jour la ou les empreintes

sqlite> UPDATE gorgone_target_fingerprint SET fingerprint = 'new_fingerprint' WHERE fingerprint = 'old_fingerprint';

5)  Vérifier la mise à jour avec la requête suivante :

sqlite> Show the fingerprints for each poller, and check that the new fingerprint as been applied correctly:
SELECT * FROM gorgone_target_fingerprint;

6)  Quitter l'utilitaire sqlite

sqlite> .quit

7) Pour finir, redémarrer le service gorgoned

# systemctl restart gorgoned

 

L’article CENTREON - Gorgoned fingerprint changed for target est apparu en premier sur Admin Malin.

Petit mémo rapide pour convertir un certificat au format PFX. Dans mon cas, un certificat Let's Encrypt à utiliser avec un serveur de messagerie Microsoft Exchange.

Procédure

Se connecter à la machine Linux en SSH

Utiliser la commande suivante en adaptant le chemin des fichiers cert.cert (certificat) et cert.key (clé associée au certificat) :

# openssl pkcs12 -export -out cert.pfx -inkey cert.key -in cert.cert

 

L’article LINUX - Convertir un certificat Let's Encrypt au format PFX est apparu en premier sur Admin Malin.

Suite à la montée de version de mon VPS sur Ubuntu 22.04, mon serveur Nextcloud retourne l'erreur suivante : Encryption pas prête : multikeyencryption failed error:0480006C:PEM routines::no start line et impossible de lire et d'ajouter de nouveaux fichiers.

Les erreurs visibles dans la journalisation :

Sabre\DAV\Exception\ServiceUnavailable: Encryption pas prête : multikeyencryption failed error:0480006C:PEM routines::no start line 
OCA\Encryption\Exceptions\MultiKeyEncryptException: multikeyencryption failed error:0480006C:PEM routines::no start line

Correction

Editer le fichier suivant : /etc/ssl/openssl.cnf

Ajouter ou décommenter les lignes suivantes :

[provider_sect]
default = default_sect
legacy = legacy_sect

[default_sect]
activate = 1

[legacy_sect]
activate = 1

Solution trouvé ICI

 

L’article Nextcloud - Encryption pas prête : multikeyencryption failed error:0480006C:PEM routines::no start line est apparu en premier sur Admin Malin.

Petit mémo pour sauvegarder et importer des images Docker.

Procédure

Sauvegarde

1) Se connecter à la machine possédant l'image Docker souhaitée

2) Lister toutes les images disponibles :

# docker images

3) Sauvegarder une image :

Dans mon exemple, sauvegarde de l'image adminmalin_talk

# docker save -o nc_talk.tar adminmalin_talk

Restauration

1) Transférer sur la nouvelle instance Docker le fichier tar de l'image

2) Se connecter sur la nouvelle instance Docker

3) Importer l'image :

# docker load -i nc_talk.tar

4) Pour vérifier si l'image est bien disponible :

# docker images

 

L’article LINUX - Sauvegarder et importer des images Docker est apparu en premier sur Admin Malin.

Petite note suite à l'installation d'une machine OPNsense. Lors de la détection d'un virus/malware avec le service Proxy Web, le message suivant apparaît sur les clients : Unable to find specified template: /tmp/c-icap/templates//virus_scan/en/VIRUS_FOUND. Nous allons voir dans cet article comment résoudre cet incident.

Cause

En regardant le message d'erreur, il est explicite que le service c-icap ne trouve pas le template à renvoyer aux clients du service Proxy Web. En faisant un ls /tmp/c-icap/templates//virus_scan/en le répertoire est vide.

Lorsque l'on regarde le fichier utiliser pour générer la configuration du service c-icap, on retrouve le répertoire vide :

# cat /usr/local/opnsense/service/templates/OPNsense/CICAP/c-icap.conf | grep TemplateDir
TemplateDir /tmp/c-icap/templates/

On peut résoudre le problème en modifiant la directive correctement mais cela va poser un nouveau problème. Lors d'une mise à jour, cette configuration sera de nouveau incorrecte (sauf si une correction est mise en place par l'éditeur).

Nous allons voir comment résoudre cette problématique proprement et sans être impacter par les mises à jours futures.

Prérequis

Pouvoir accéder en shell sur la machine OPNsense.

Procédure

Nous allons créer un script qui sera lancé au démarrage de OPNsense pour modifier les chemins des templates en utilisant les liens symboliques.

1) Se connecter au shell de OPNsense

2) Créer le fichier suivant et saisir le contenu ci-dessous :

Fichier: /usr/local/etc/rc.syshook.d/start/99-custom-icap

#!/bin/sh

sleep 60

rm -rf /tmp/c-icap/templates/virus_scan/en
ln -s /usr/local/share/c_icap/templates/virus_scan/en/ /tmp/c-icap/templates/virus_scan/en

date >> /tmp/custom.log

exit 0

3) Ajouter les autorisations d’exécution au nouveau script :

# chmod +x /usr/local/etc/rc.syshook.d/start/99-custom-icap

4) Redémarrer la machine OPNsense pour vérifier que tout fonctionne correctement

Pour vérifier la bonne exécution du script au démarrage, il est possible de regarder la présence du fichier de log :

# cat /tmp/custom.log
Tue Aug 23 21:56:06 CEST 2022

Pour tester le bon fonctionnement du service, il existe des URLs de tests, en voici un exemple :

 

L’article OPNsense - Unable to find specified template VIRUS_FOUND est apparu en premier sur Admin Malin.

Suite à une mise à jour pas concluante du firmware iDRAC & Lifecycle Controller, j'ai perdu l'accès à l'interface WEB iDRAC. Nous allons voir comment réaliser un rollback (retour arrière) de cette mise à jour en SSH.

Prérequis

Il est nécessaire de disposer des identifiants administrateur du contrôleur iDRAC.

Procédure

Attention, la réalisation de cette procédure touche directement les composants du serveur. Je ne pourrai être en aucun cas tenu responsable de vos opérations.

Dans mon cas, j'ai réaliser cette opération sur un serveur DELL T320 après avoir réaliser la dernière mise à jour de iDRAC & Lifecycle Controller.

1) Se connecter en SSH au contrôleur iDRAC

2) Il est nécessaire de récupérer le FQDD du composant à restaurer dans son ancienne version. Pour cela utiliser la commande suivante :

/admin1-> racadm swinventory

-------------------------SOFTWARE INVENTORY------------------------

ComponentType = FIRMWARE
ElementName = Power Supply.Slot.1
FQDD = PSU.Slot.1
InstallationDate = 2014-08-20T18:54:26Z
Current Version = 09.2B.80
-------------------------------------------------------------------

ComponentType = FIRMWARE
ElementName = Power Supply.Slot.2
FQDD = PSU.Slot.2
InstallationDate = 2014-08-20T18:54:26Z
Current Version = 09.2B.80
-------------------------------------------------------------------

ComponentType = FIRMWARE
ElementName = Integrated Dell Remote Access Controller
FQDD = iDRAC.Embedded.1-1
InstallationDate = NA
Rollback Version = 2.41.40.40
-------------------------------------------------------------------

.....

3) Pour réaliser le retour arrière d'un firmware, utiliser la commande suivante :

/admin1-> racadm rollback FQDD

Avec FQDD, le nom présent dans l'inventaire réalisé en étape 2)

Dans mon cas, je souhaite restaurer l'ancienne version du contrôleur iDRAC en version 2.41.40.40 :

/admin1-> racadm rollback iDRAC.Embedded.1-1
RAC1056: Rollback operation initiated successfully. To view the progress of the job, use the "racadm jobqueue view" command.
If the job is scheduled, the system will require a manual reboot.
To reboot the system manually, use the "racadm serveraction powercycle" command.

 

L’article DELL iDRAC - Réaliser le rollback d'un firmware en SSH est apparu en premier sur Admin Malin.

Dans cet article nous allons voir comment configurer manuellement la vitesse du ventilateur CPU afin de pouvoir limiter le bruit (et la consommation électrique) sur un serveur DELL T320.

Contexte

Suite à la monté de version du firmware de mon serveur DELL T320 (IDRAC et Lifecycle Controller en 2.41.40.40), il est devenu plus bruyant à cause d'une vitesse du ventilateur CPU plus importante.

Ayant plusieurs T320 dans des configurations différentes, c'est le seul ayant eu ce "problème". Cette augmentation sonore s'explique par le nombre plus important de périphériques (2x Perc H310 et 2x HP Quad Port Gigabite).

Prérequis

Disposer d'un accès à l'interface WEB iDRAC du serveur DELL T320 avec des droits administrateur.

Disposer du soft ipmitool, disponible ICI si besoin (version Windows). Il est possible de l'installer pour Linux.

Procédure

Attention, forcer manuellement la vitesse d'un ventilateur est à réaliser avec précaution.  Je ne pourrai pas être tenu responsable d'une surchauffe de votre matériel suite à l'application de cette procédure.

Activer IPMI

1) Se connecter sur l'interface WEB du contrôleur iDRAC du serveur

2) Activer IPMI en se rendant dans le menu Réseau

3) Cliquer sur Appliquer pour valider la nouvelle configuration

Configurer la vitesse du ventilateur via IPMI

Dans mon cas, les manipulation sont réalisées avec IPMITOOL pour Windows.

Adresse IP du contrôleur iDRAC: 10.20.200.21
Utilisateur: root
Mot de passe: calvin

1) Télécharger IPMITOOL

2) Ouvrir une invite de commande CMD et se placer dans le répertoire ou se trouve ipmitool.exe

3) Pour afficher l'état des capteurs :

ipmitool -I lanplus -H 10.20.200.21 -U root -P calvin sdr list full

Inlet Temp      | 10 degrees C  | ok
Sys Fan1        | 1800 RPM      | ok
Sys Fan2        | disabled      | ns
Current 1       | 0.10 Amps     | ok
Current 2       | 0.05 Amps     | ok
Voltage 1       | 236 Volts     | ok
Voltage 2       | 236 Volts     | ok
Pwr Consumption | 112 Watts     | ok
Temp            | 28 degrees C  | ok
Temp            | disabled      | ns

4) Activer la gestion manuelle du ventilateur :

ipmitool -I lanplus -H 10.20.200.21 -U root -P calvin raw 0x30 0x30 0x01 0x00

Pour désactiver cette configuration saisir la commande suivante :

ipmitool -I lanplus -H 10.20.200.21 -U root -P calvin raw 0x30 0x30 0x01 0x01

5) Configurer la vitesse du ventilateur souhaité. Voici quelques exemples :

Pour forcer la vitesse à 5% :

ipmitool -I lanplus -H 10.20.200.21 -U root -P calvin raw 0x30 0x30 0x02 0xff 0x05

Pour forcer la vitesse à 20% :

ipmitool -I lanplus -H 10.20.200.21 -U root -P calvin raw 0x30 0x30 0x02 0xff 0x14

Pour forcer la vitesse à 30% :

ipmitool -I lanplus -H 10.20.200.21 -U root -P calvin raw 0x30 0x30 0x02 0xff 0x1e

Pour forcer la vitesse à 100% :

ipmitool -I lanplus -H 10.20.200.21 -U root -P calvin raw 0x30 0x30 0x02 0xff 0x64

Dans mon cas, je l'ai configuré sur 5% :

La configuration est conservée en cas de reboot du serveur mais pas en cas de réinitialisation du contrôleur iDRAC / coupure de courant.

Pour allez plus loin, il est possible de créer un script qui configure la vitesse du ventilateur en fonction de la température CPU.

 

L’article DELL iDRAC - T320 Modifier la vitesse du ventilateur CPU est apparu en premier sur Admin Malin.

Dans cet article nous allons voir comment configurer le service SNMP de SQUID afin de pouvoir le superviser. Cette configuration pourra être utilisé avec la solution CENTREON par exemple.

Prérequis

Il est nécessaire d'avoir une installation de SQUID fonctionnelle et disposer des privilèges root.

Procédure

1) Se connecter en SSH sur la machine hébergeant le serveur SQUID

2) Editer le fichier de configuration SQUID. Généralement le fichier /etc/squid/squid.conf

3) Ajouter les directives suivantes

snmp_port 3401
acl snmpcentreon snmp_community centreon
acl supervision src 10.10.10.199
snmp_access allow supervision snmpcentreon

Dans cet exemple, le port SNMP configuré est 3401, la communauté SNMPv2c est centreon et le serveur pouvant réaliser des requêtes est 10.10.10.199.

Il est possible de configurer un fichier listant tous les hôtes autorisés :

snmp_port 3401
acl snmpcentreon snmp_community centreon
acl supervision src "/etc/squid/allow-supervision.conf"
snmp_access allow supervision snmpcentreon

Contenu du fichier /etc/squid/allow-supervision.conf

10.10.10.199
10.10.10.200
192.168.1.0/24

4) Pour finir, redemarrer le service SQUID :

systemctl restart squid

5) Voici un résultat obtenu avec la solution CENTREON :

 

Documentation officielle : https://wiki.squid-cache.org/Features/Snmp

 

L’article Configurer le service SNMP pour SQUID est apparu en premier sur Admin Malin.