3
Oct

Nagios : Vautour Style

Vautour Style est un skin pour Nagios Core. Les feuilles de styles et les icônes ont été modifiés pour offrir une présentation différente de l’interface Web de Nagios. Vautour Style utilise le framework javascript jQuery et les icônes Silk icon set de Mark James.

vautour_style1

vautour_style2

vautour_style3

L’installation consiste à extraire le fichier ZIP dans le répertoire contenant les pages Web de Nagios (habituellement, /usr/local/nagios/share/).

Télécharger Vautour Style [116 Ko]

Mise à jour :

  • 26/06/2009 : Ajout du fichier index.php pour les versions 3.1.x de Nagios.
  • 12/10/2009 : Ajout d’une barre de recherche.
  • 04/06/2012 : Prise en compte de la numérotation des pages pour la version 3.4.x de Nagios.
  • 28/10/2012 : Correction d’affichage pour la numérotation des pages.
  • 03/10/2016 :
    • Prise en compte des nouvelles fonctionnalités introduites dans Nagios Core 4.x (map, trends et alert histogram).
    • Réorganisation des items du menu.
    • Utilisation du framework javascript jQuery à la place de MooTools.
    • Corrections mineures des CSS.
24
Mar

DHCP Failover Auto Config Sync sous Windows Server 2012

Dans Windows Server 2012, le service DHCP peut être configuré pour fournir une haute disponibilité. Les baux d’adresses IP d’une étendue sont ainsi synchronisés entre deux serveurs DHCP en relation de basculement. Cependant, lorsque l’administrateur effectue des modifications dans la configuration d’une étendue, celle-ci n’est pas répliquée sur l’autre serveur DHCP.

L’outil DHCP Failover Auto Config Sync écrit en Windows PowerShell, permet de réaliser cette réplication automatiquement.

La documentation que je vous propose, présente cette problématique et met en œuvre l’outil DHCP Failover Auto Config Sync (DFACS) à travers un atelier pratique.

Télécharger la documentation sur DHCP Failover Auto Config Sync [1.33 Mo]

3
Fév

Installation d’OpenNebula sous Archlinux (partie 2)

Dans cet article nous allons poursuivre l’installation de notre plateforme cloud utilisant OpenNebula sur une distribution Archlinux.
Nous avons vu que, par défaut, sunstone écoute sur le port 9869/tcp. Pour faciliter l’utilisation, nous allons mettre un reverse-proxy nginx en place. Ce dernier écoutera sur le port 80/tcp et enverra les requêtes à sunstone.

Mise en place de Nginx

L’installation se fait de manière classique sous Archlinux :

pacman -S nginx

La configuration se fait en éditant le fichier /etc/nginx/nginx.conf et en inserant un bloc server dans la section http :

http {
 	…

  server {
         listen       80 default_server;
         server_name  _;
         # A regler en fonction des images qcow2 que l'on souhaite uploader dans sunstone
         client_max_body_size 29G;

         location / {
                   proxy_pass http://127.0.0.1:9869;
          }
    }
 
	…
}

Le démarrage de nginx se fait à l’aide des commandes :

systemctl enable nginx
systemctl start nginx

Nous pouvons maintenant dire à sunstone de n’autoriser des requêtes que depuis le localhost.
Il nous faut éditer le fichier /etc/one/sunstone-server.conf et modifier la ligne :

:host: 0.0.0.0

en

:host: 127.0.0.1

et relancer le service :

systemctl stop opennebula-sunstone.service
systemctl start opennebula-sunstone.service

A présent si nous effectuons une requête depuis un navigateur web sur http://192.168.0.136 sans spécifier de port (a modifier bien sur en fonction de l’adresse de votre serveur opennebula),
nous obtenons la page d’accueil de sunstone :
sunstone

Installation d’OpenVPN

Vu que les VMs deployées par OpenNebula seront reliées à un switch virtuel n’ayant aucune connexion avec un quelconque réseau physique, nous devons installer un service VPN sur notre serveur OpenNebula qui nous permettra accéder aux machines.
Pour simplifier les choses, openvpn sera configuré pour authentifier les utilisateurs via leur compte système via les PAM. Nous allons d’abord créer un groupe « vpn » :

groupadd vpn

Nous allons donc créer le compte d’un utilisateur (ici beroot qui pourra se connecter au vpn :

useradd -s /usr/bin/nologin -M -g vpn beroot
passwd beroot

Installons OpenVPN :

pacman -S openvpn iptables easy-rsa

Créons le fichier de configuration d’OpenVPN /etc/openvpn/server.conf :

port 1194
proto udp
dev tun0

ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh2048.pem


server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

client-to-client

keepalive 10 120

comp-lzo
max-clients 100

user nobody
group nobody

persist-key
persist-tun

status /var/log/openvpn-status.log
log-append  /var/log/openvpn.log

verb  4

client-cert-not-required
plugin /usr/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn
push "route 192.168.1.0 255.255.255.0"

Créons le fichier /etc/pam.d/openvpn :

auth    required         pam_listfile.so        onerr=fail item=group sense=allow file=/etc/pam.d/openvpn.allowed
auth    sufficient       pam_unix.so            try_first_pass likeauth nullok
auth    required         pam_deny.so
account required         pam_unix.so
session required         pam_unix.so

et le fichier /etc/pam.d/openvpn.allowed qui contient juste le nom du groupe unix autorisé à se connecter au vpn :

vpn

Il nous faut maintenant préparer l’environnement qui va nous permettre de créer les clés de cryptage :

mkdir -p /etc/openvpn/keys
cp -r /usr/share/easy-rsa /etc/openvpn/

Nous éditons ensuite le fichier vars et le modifions en fonction de notre localisation.

cd /etc/openvpn/easy-rsa
vim vars

Nous générons ensuite les clés :

 . ./vars
 ./clean-all
 ./build-ca
 ./build-key-server server
 ./build-dh

Puis nous les copions à l’endroit approprié :

 cp keys/ca.crt /etc/openvpn/keys/
 cp keys/ca.key /etc/openvpn/keys/
 cp keys/server.crt /etc/openvpn/keys/
 cp keys/server.key /etc/openvpn/keys/
 cp keys/dh2048.pem /etc/openvpn/keys/

Vous pouvez déjà exporter le fichier /etc/openvpn/keys/ca.crt car il sera à installer sur les clients vpn par la suite.

Nous pouvons alors démarrer le service openvpn :

systemctl enable openvpn@server.service
systemctl start openvpn@server.service

Le serveur vpn est en service mais il faut que nous paramétrions quelques règles iptables pour rendre le système utilisable.

Mise en place de règles iptables

Créons le fichier /etc/iptables/iptables.rules (remplacez eno1 par le nom de votre interface réseau) :

*nat
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE
COMMIT
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT  -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A INPUT  -i br0 -j ACCEPT
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp  --match multiport --dports 5900:6000 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 29876 -j ACCEPT
-A INPUT -i eno1 -p udp --dport 1194 -j ACCEPT
COMMIT

Créons un fichier /etc/sysctl.d/iptables.conf :

net.ipv4.ip_forward = 1

Démarrons l’ensemble :

systemctl enable iptables.service
systemctl start iptables.service
sysctl -p

Ce deuxième article sur la configuration de notre plateforme OpenNebula s’achève ici. Le système est utilisable dans l’état mais nous irons encore plus loin dans un prochain article …

Le thème Celadon pour WordPress a été créé par Themes Boutique