Bonjour

Je rentre quelques soucis avec mon serveur VMWare Server 2.0 commençant à être de plus en plus rapprochés, je me suis dit pourquoi pas OpenVZ.

Pour poser les bases de l’installation, je dispose de :

  • Deux serveur physiques qui vont héberger les deux serveurs OpenVZ. Ces deux serveurs se trouvent en DMZ de mon réseau.
  • Un serveur dans mon LAN et non dans ma DMZ pour l’administration des deux serveurs avec l’interface OpenVZ Web Panel.

Ci dessous les différentes étapes de l’installation :

  • Installation d’un version d’Ubuntu Server 8.04 sur chaque serveur comme socle de base.
  • Installation d’OpenVZ :
apt-get install linux-openvz vzctl
  • Suppression des version des linux-image qui ne sont plus nécessaires :
apt-get remove --purge --auto-remove linux-image-.*server
  • Modification du fichier /etc/sysctl.conf pour le paramétrage réseaux des machines virtuelles, en rajoutant les lignes ci dessous :
vi /etc/sysctl.conf
# On Hardware Node we generally need
# packet forwarding enabled and proxy arp disabled
net.ipv4.conf.default.forwarding=1
net.ipv4.conf.default.proxy_arp=1
net.ipv4.conf.eth0.proxy_arp=1
net.ipv4.ip_forward=1
# Enables source route verification
net.ipv4.conf.all.rp_filter = 1
# Enables the magic-sysrq key
kernel.sysrq = 1
# TCP Explict Congestion Notification
#net.ipv4.tcp_ecn = 0
# we do not want all our interfaces to send redirects
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0
  • Prise en compte des nouveaux paramètres réseaux :
sysctl -p

Lire la suite de

fail2ban_logo

Bonjour à tous

Dans tous ce que je dois faire, et que je ne fais jamais le temps de faire, j’ai priorisé certains points comme les aspects sécurités dans un premier temps.

Fail2ban lit les logs de divers serveurs (SSH, Apache, FTP…) à la recherche d’erreurs d’authentification répétées et ajoute une règle iptables pour bannir l’adresse IP de la source.

Niveau installation rien de plus simple :

aptitude install fail2ban

Puis tout ce passe dans le dossier /etc/fail2ban, voyons maintenant la configuration :

  • Un fichier /etc/fail2ban/fail2ban.conf incluant les paramètres de log et de socket entre autre de fail2ban en lui même.
  • Un dossier /etc/fail2ban/action.d contenant les fichiers des actions en cas de bannissement.
  • Un dossier /etc/fail2ban/filter.d contenant les différents filtres pour les règles de filtrages.
  • Un fichier /etc/fail2ban/jail.conf contenant les paramètre principaux.

Ces deux derniers qui vont devoir être modifiés pour être adapté aux besoins de chacun.

Lire la suite de

Bonjour à tous

Possédant un NAS QNAP TS-439 Pro avec 4 disques de 1,5 To en Raid 5 je me suis dit que j’allais essayer d’utiliser le plus de fonctionnalités de celui ci.

Avec la dernière mise à jour en 3.5.0 build 0815T, un nouvelle fonctionnalité est apparue : il permet de faire serveur Syslog pour récolter les logs et les événements de différents machines

Mon parc de machine est assez hétérogènes et va l’être encore plus dans les mois à venir avec l’arrivé d’Apple dans mon réseau :

  • Serveur Ubuntu 10.04
  • Serveur Ubuntu 8.04
  • Station Ubuntu 10.04
  • Station Windows XP SP3
  • Netbook Windows 7 / Ubuntu

Et le but c’est que chaque machine renvoi ces informations sur mon NAS.

Sur le NAS, il faut activer le serveur syslog dans le sous menu Serveur Syslog du menu Serveurs d’Applications et renseigner les champs suivants :

  • Choisir le protocole : UDP
  • Choisir le port : 541
  • Choisir la taille maximum de journal : 100 Mo (taille maximum)
  • Choisir le dossier ou sauvegarder les logs : Public
  • Choisir le nom du fichier : syslog
  • Choisir le niveau d’alerte pour l’envoi d’un mail, pour l’instant je laisse par défaut : Emerg

Pour décrire rapidement l’emplacement de mes machines dans le réseau, elles sont réparties comme ci dessous :

  • une ou deux serveurs en hébergement donc dans le WAN
  • Des serveurs dans la DMZ
  • Des serveurs et station de travail dans le LAN

Lire la suite de

Bonjour à tous

Hier en fin d’après midi, un ami (informaticien) est passé prendre le café, moment d’échange et forcément on parle d’informatique.

Je lui dit qu’il faut absolument que je trouve un moyen de lancer des commandes en même temps sur une ferme de serveurs, dans un premier temps pour résoudre le problème récurrent des mises à jour à faire sur chaque machine.

Marre de me connecter sur toutes les machines dès qu’une mise à jour pointe le bout de son nez, et sur ce il me dit tout simplement « Ben utilise Fabric c’est la pour ça ».

En cette fin de samedi après midi je me penche donc ce jour sur la question, en relisant entre autre l’article de Emile « iMil » Heitor dans le numéro 135 de Linux Magazine / France de février de cette année.

Mon environnement de test est le suivant :

  • Une VM avec une ubuntu server 10.04 à jour sans aucun paquet spécifiques servant de serveur Fabric (et également de client)
  • Une seconde VM ubuntu server 10.04 servant de client à Fabric
  • Un échange de clé ssh pour l’accès de la VM serveur à la VM cliente

L’installation de Fabric est nécessaire uniquement sur une seule machine du parc, tous le reste ce fait via ssh vers les autres machines ce qui est en soit déjà une bonne chose.

Une installation tout ce qu’il y a de plus classique :

aptitude install fabric

L’installation via aptitude (et non apt-get) prend en compte les dépendances c’est à dire qu’au final trois paquets sont installés :

  • fabric
  • python-crypto
  • python-paramiko

Ensuite rien de plus n’est nécessaire pour notre première utilisation de Fabric passons donc à la configuration :

Lire la suite de