Téléchargement :

http://www.plop.at/en/bootmanagerdl.html

Et au démarrage, vous devriez obtenir le résultat suivant :

Voici une petite astuce fort sympathique, et qui est très utile pour les administrateurs qui se connectent souvent sur des serveurs de développement.
Qui dit des serveurs de développement, dit des serveurs qui se créaient et se suppriment à la volée.
Du coup vous vous retrouvez sans cesse en train de modifier votre fichier /$user/.ssh/known_hosts, car vos serveurs évoluent (suppression, création) mais vos IP utilisées restent les mêmes.
Pour éviter cette manip, voici un paramètre à changer dans le fichier de configuration du client ssh (/etc/ssh/ssh_config).

# vi /etc/ssh/ssh_config
-
StrictHostKeyChecking no

Désormais fini, le message de confirmation lors des premières connexions SSH sur un serveur.

$ ssh $server1
Are you sure you want to continue connecting (yes/no)? yes

mstsc /v 00.00.00.00 /f -console

Il faut remplacer 00.00.00.00 par l’adresse IP du serveur distant sur lequel nous souhaitons nous connecter.

Il s’agit d’un petit tuto abordable pour tous.
Je ne manquerais pas de compléter ce tuto avec la gestion des quotas par utilisateur.

Installation du service

# apt-get install proftpd openssl

- Lors de l’installation, vous avez le choix du démarrage du service soit par Inet, soit en démon autonome. Par habitude, je préfére que chaque service ait son propre processus.

Configuration

Tous les fichiers de configuration se situent au même endroit « /etc/proftpd ».

# cd /etc/proftpd

Tout d’abord, nous allons effectuer une copie du fichier de configuration par défaut, pour qu’en cas d’erreur, nous puissions revenir à la configuration d’origine.

# cp proftpd.conf proftpd.conf.orig

# vi proftpd.conf
UseIPV6  off
DefaultRoot ~
IdentLookups off

UseIPV6 : Active/Désactive le protocol IPV6
DefaultRoot : Utilisé pour chrooter les utilisateurs dans leur HomeDirectory

# /etc/init.d/proftpd restart

Et voilà, vous vous retrouvez déjà avec un serveur FTP fonctionnel.

Activation de TLS

Pour ce faire, nous allons commencer par générer un certificat autosigné.

# mkdir /etc/proftpd/ssl
# openssl req -new -x509 -days 365 -nodes -out /etc/proftpd/ssl/proftpd.cert.pem -keyout /etc/proftpd/ssl/proftpd.key.pem

!! Attention !! à bien spécifier le hostname de la machine au niveau du champ
Common Name (eg, YOUR name) [] : srv-ftp

Une fois le certificat créée, nous allons maintenant activer le TLS dans les fichiers de configuration

# vi /etc/proftpd/proftpd.conf
Include /etc/proftpd/tls.conf

puis

# cd /etc/proftpd/
# cp tls.conf tls.conf.orig

# vi tls.conf
<IfModule mod_tls.c>
TLSEngine                  on
TLSLog                     /var/log/proftpd/tls.log
TLSProtocol                SSLv23
TLSOptions                 NoCertRequest
TLSRSACertificateFile      /etc/proftpd/ssl/proftpd.cert.pem
TLSRSACertificateKeyFile   /etc/proftpd/ssl/proftpd.key.pem
TLSVerifyClient            off
TLSRequired                on
</IfModule>

# /etc/init.d/proftpd restart

Connexion

Pour chaque utilisateur devant se connecter au serveur, un compte doit être créée en local sur la machine, sauf authentification centralisée.

# apt-get install filezilla

 » Gestionnaire de Sites |  Nouveau Site |   »
Hôte : srv-ftp
Type de serveur : FTPES
Type d’authentification : normale
Identifiant : userx
Mot de passe : passwx

puis « Valider » et enfin « Connexion »

Ni une, ni deux, je me suis lancé dans la compilation de ceux-ci afin d’entamer mon premier dessin ( j’ai l’impression de retourner quelques années en arrière en disant cela).

Pré-requis

Dans un premier temps, nous allons installer les sources de notre noyau afin de générer le module qui sera utilisé par la suite.

apt-get install linux-headers-`uname -r`

Puis nous installons les paquets suivants :

apt-get install build-essential libx11-dev libxi-dev x11proto-input-dev xserver-xorg-dev tk8.4-dev tcl8.4-dev libncurses5-dev

Après avoir installé tous les paquets nécessaires à la compilation, nous allons récupérer les sources du module. Pour ce faire allez sur le site afin de récupérer l’URL en fonction de la version en cour.

wget http://prdownloads.sourceforge.net/linuxwacom/linuxwacom-0.8.6-2.tar.bz2

Phase de compilation

Nous allons maintenant passer à la phase de compilation :

tar -xvjf linuxwacom-0.8.6-2.tar.bz2
cd linuxwacom-0.8.6-2
./configure --enable-wacom

# A adapter selon la version du noyau
cd src/2.6.30/
make
cp wacom.ko /lib/modules/`uname -r`/kernel/drivers/input/tablet/
rmmod wacom
modprobe wacom

Je tiens à préciser que je suis actuellement sur un noyau version 2.32, et le module pour le 2.6.30 fonctionne.
Et voilà le tour est joué. Vous pouvez désormais lancer « GIMP » et profiter comme moi de cette tablette graphique.

Vous devez vérifier que la tablette est bien activée dans « GIMP », pour ce faire allez dans l’onglet « Edition/Préférences/Périphériques d’entrée/Configurer les périphériques d’entrées étendus/« .

Sélectionnez item par item correspondant à la tablette et paramétrez le en mode « écran« .

Comme vous avez pu le constater, j’utilise énormément MUNIN pour le monitoring de mes systèmes.
Ayant de plus en plus de système virtualisé, je me suis donc empressé de faire un petit plugin munin permettant de superviser le CPU et RAM de mes ESXi. En effet, VirtualCenter Server fait cela très bien, mais je trouve l’interface un peu lourde, alors qu’une page sur un navigateur comprenant tous les graphs de vos hyperviseurs c’est plus simple d’accès.

Ce script sera implémenté dans une installation de MUNIN déjà existante. je ne vais pas revenir sur ces étapes qui sont détaillées dans un de mes précédents POST.

POST ACTIONS

Installation des Pré-requis

Nous allons commencer par installer les paquets pré-requis pour utiliser des scripts Perl couplés aux librairies Vmware (VmwarePerlToolKit).

# apt-get install libxml-libxml-common-perl libxml-libxml-perl libclass-methodmaker-perl libcrypt-ssleay-perl

Récupération des sources sur le site de vmware

Téléchargement des VIPerlToolKit

# tar xvzf VMware-vSphere-SDK-for-Perl-4.0.0-161974.i386.tar.gz
# cd vmware-vsphere-cli-distrib/
# ll
# ./vmware-install.pl

Plugins pour le monitoring CPU/RAM d’un ESXi ou ESX

Nous allons créer le plugin, pour ce faire vous allez créer le fichier suivant : /usr/share/munin/plugins/esxi_

et y insérer le code ci-dessous :

#!/usr/bin/perl -w
use strict;
use warnings;
use lib "/usr/lib/vmware-vcli/apps/";
use VMware::VIRuntime;
use VMware::VILib;
use AppUtil::VMUtil;
use AppUtil::HostUtil;

my $codeRetour = 0;
my $hostIP = $0;
$hostIP =~ s/esxi_//;
$hostIP =~ s/^\/etc\/munin\/plugins\///;

my $username = Opts::set_option ('username',"root");
my $password = Opts::set_option ('password'," ");

my $test= Opts::set_option ('url',"https://$hostIP/sdk/webService");
my $critical = 90;
my $warning = 70;

if ( exists $ARGV[0] and $ARGV[0] eq "config" ) {
  # Affichage de la configuration
  print "graph_title ESXi : ".$hostIP." \n";
  print "graph_args --base 1000 -l 0 \n";
  print "graph_vlabel % \n";
  print "graph_category ESXi \n";
  print "graph_scale no \n";
  print "mem.label MEM used \n";
  print "mem.draw AREA \n";
  print "mem.colour CC7700 \n";
  print "cpu.label CPU used \n";
  print "cpu.colour 000000 \n";
#  print "cpu.draw LINE2 \n";
#  print "cpu.draw AREA \n";
} else {
## Connexion au HOST
  Util::connect();
  get_host_cpu_info();
  get_host_mem_info();
## Deconnexion au HOST
  Util::disconnect();
}

exit $codeRetour;

sub get_host_mem_info {
  my %filter;
  $filter{'summary.config.vmotionEnabled'} = 'false';
  $filter{'runtime.inMaintenanceMode'} = 'false';
  $filter{'name'} = Opts::get_option ('host');
  my $host_views = HostUtils::get_hosts('HostSystem',
                                  );
  if ($host_views) {
    foreach (@$host_views) {
      my $host_view = $_;
      my $PercentMemoryUsed = $host_view->summary->quickStats->overallMemoryUsage * 1024 * 1024 * 100 / $host_view->hardware->memorySize;
      printf "mem.value %.0f\n",$PercentMemoryUsed;
    }
  }
}

sub get_host_cpu_info {
  my %filter;
  $filter{'summary.config.vmotionEnabled'} = 'false';
  $filter{'runtime.inMaintenanceMode'} = 'false';
  $filter{'name'} = Opts::get_option ('host');
  my $host_views = HostUtils::get_hosts('HostSystem'
                                  );
  if ($host_views) {
    foreach (@$host_views) {
      my $host_view = $_;
      my $percentCpuUsed = $host_view->summary->quickStats->overallCpuUsage * 100000000/ ($host_view->hardware->cpuInfo->hz * $host_view->hardware->cpuInfo->numCpuCores);
      printf "cpu.value %.0f\n",$percentCpuUsed;
      if ( $percentCpuUsed > $critical ) {
        $codeRetour = 2;
      } elsif ( $percentCpuUsed > $warning && $codeRetour eq '0' ) {
        $codeRetour = 1;
      }
    }
  }
}

Mise en place du plugin

# cd /etc/munin/plugins/
# ln -s /usr/share/munin/plugins/esxi_ /etc/munin/plugins/esxi_${IPHOST}

Ajout des autorisations nécessaires pour que munin puisse lancer le script

# vi /etc/munin/plugin-conf.d/munin-node
-
[esx*]
user root

Il ne reste plus qu’à redémarrer le service munin-node afin de prendre en compte le plugin.

# /etc/init.d/munin-node restart

Vous devriez obtenir un résultat comme ci-dessous.

Note : ce plugin est aussi bien compatible avec les ESXi qu’avec les ESX.

Depuis quelques temps j’essaye d’optimiser au mieux tous les services compris au sein d’une architecture n-tiers.
Cette tâche me direz-vous est très complexe….je vous le confirme, il faut beaucoup de patience, de tests, de bourrage de crâne de bouquin.

Dans ma quête de la perfection je suis tombé sur un poste alliant un système de cache « MEMCACHE » avec MYSQL…oui vous avez bien lu.
Au début je ne pensais pas trop obtenir de réels résultats en couplant les deux mais finalement, les résultats sont présents.
C’est d’ailleurs pour cela, que je vous en parle aujourd’hui.

Installation des pré-requis

Pour que tout ce petit monde fonctionne main dans la main, nous allons commencer par installer les pré-requis.

# apt-get install  lua5.1 liblua5.1-md5-0 liblua5.1-socket2 luarocks mysql-proxy

Le paquet « MYSQL-PROXY » fera la liaison entre Mysql et Memcache.

Puis nous allons récupérer la librairire lua

# wget http://luamemcached.googlecode.com/files/liblua5.1-memcached0.deb

Nous sommes contraint de la récupérer sur le site de googlecode car, le paquet n’est pas récupérable à travers « APTITUDE ».

Configuration de Mysql-Proxy

Récupération du fichier nécessaire pour que Mysql-proxy récupère les infos dans Memcache plutôt qu’au sein du serveur Mysql.

# cd /usr/share/mysql-proxy/
# wget http://github.com/clofresh/mysql-proxy-cache/raw/master/mysql-proxy-cache.lua

Je vous invite à éditer ce fichier, il vous permettra de voir qu’il ne s’agit n’y plus ni moins qu’une regex sur la requête pour savoir si elle commence par SELECT ou non, et l’envoyer au service adéquate.

# vi /etc/default/mysql-proxy
-
ENABLED="true"
OPTIONS="--proxy-lua-script=/usr/share/mysql-proxy/mysql-proxy-cache.lua"

Activation

Nous avons terminé avec la configuration, et il ne reste plus qu’à démarrer le service « MYSQL-PROXY ».

# /etc/init.d/mysql-proxy start

Vous verrez vous obtiendrez de net gain de performance.
Par défaut, les résultats sont présents durant 30 secondes dans le système de cache.
A vous de régler ce paramètre selon fréquence de modification des données.

Visualiser l’utilisation du cache

Vous avez la possibilité de visualiser l’utilisation du cache en effectuant un telnet sur le service MEMCACHE (port 11211), suivit de la commande stats.
Vous obtiendrez des informations quant aux valeurs enregistrées et utilisées dans le cache.

# telnet localhost 11211
-
stats

Source : http://blog.rodolphe.quiedeville.org/index.php?post/2009/10/Int%C3%A9grer-memcache-et-mysql

Après quelques recherches sur le web, on se rend vite compte que de nombreux administrateurs ont eu le même problème mais que peu d’entre eux ont trouvé la solution…
Heureusement le post très intéressant d’un blog attire votre attention « recovering-vmware-snapshot-after-parent-changed« , et une lueur dans le ciel apparaît, OUF..

C’est en lisant cet article que j’apprends notamment, que le fichier .vmdk de la machine virtuelle a un identifiant unique qui est repris dans le fichier vmdk du snapshot. Cet identifiant se retrouve sous forme de variable dans les fichiers précédemment évoqués, et ils doivent concorder pour que le snapshot sache quel est son vmdk parent ( d’où vient le message d’erreur ).

1 – Récupération du CID (identifiant) du vmdk de la machine virtuelle

head --lines=20 {base parent vmdk path}
-
...
CID=94..... <-- à récupérer pour comparer avec le parentCID du snapshot
...

2 – Vérification du parentCID (CID du vmdk principal) présent dans le vmdk du snapshot

vi ma-vm-00001.vmdk

CID=e397..
parentCID=92... <-- à modifier

Si les deux identifiants ne correpondent pas, vu l’erreur ce qui est tout à fait normal, il suffit de remplacer le paramètre parentCID par le CID du disque virtuel.
Ceci fait, il ne nous reste plus qu’à redémarrer la vm, et normalement, c’est reparti comme en l’an 40.

Source :

http://driveactivated.com/blog/archive/2007/11/06/recovering-vmware-snapshot-after-parent-changed.aspx

L’Etat vient aider l’éditeur EdenWall à développer un pare-feu performant dans le cadre du dispositif Rapid.

L’éditeur français de pare-feu EdenWall bénéficie d’un sérieux coup de pouce. Son dossier a été retenu dans le cadre du dispositif Rapid (Régime d’Appui aux PME pour l’innovation duale) qui lui garantit un financement de plusieurs centaines de milliers d’euros de la DGA (Direction Générale de l’Armement) et de la DGCIS (Direction Générale de la Compétitivité, de l’Industrie et des Services). Objectif : « Développer un pare-feu capable de supporter jusqu’à un million d’utilisateurs simultanés. Cette solution sera développée à partir de notre technologie NuFW qui équipe les solutions que nous commercialisons déjà », explique Jérôme Notin, le directeur des opérations d’EdenWall. D’après le calendrier défini par l’entreprise, ses développements devraient aboutir à un produit opérationnel d’ici 24 mois

Un produit performant et peu gourmand en ressources machines

A la différence des pare-feu classiques qui filtrent les ports et les adresses IP, les produits d’EdenWall effectuent leur filtrage en identifiant les utilisateurs. Ce qui permet par exemple de sécuriser les connexions des travailleurs nomades indépendamment des machines qu’ils utilisent et du lieu où ils se trouvent. De plus, dans le cadre de RAPID, EdenWall va redévelopper l’algorithme qu’il utilise actuellement pour rendre sa solution beaucoup moins consommatrice en ressources machines. On imagine aisément l’intérêt pour des forces militaires en opération à l’étranger de limiter la quantité de matériel informatique qu’elles ont à transporter.
L’éditeur / constructeur est aidé dans son entreprise par Dalibo, un spécialiste des bases de données. Ce partenaire doit solutionner les problèmes de goulets d’étranglement dans la journalisation des logs qu’engendre classiquement la montée en performance d’un pare-feu.

Les forces armées parmi les futurs clients

Bien que financée par des fonds publics, la solution qui va sortir des laboratoires d’EdenWall sera sa propriété. L’armée, et plus largement l’Etat, pourraient donc devenir ses clients. Une bonne affaire qui vient s’ajouter au fait qu’EdenWall compte bien faire fructifier ses travaux en commercialisant aussi son produit auprès des entreprises du secteur privé. « A l’heure actuelle, nous sommes déjà capables de sécuriser plusieurs centaines de milliers de connexions en répliquant des pare-feu. Demain, nous offrirons le même services, mais avec une seule machine à un coût beaucoup plus abordable », prévoit Jérôme Notin. Passé à l’indirect depuis quelques mois, l’entreprise prévoit logiquement de mettre son produit sur le marché notamment par le biais de partenaires intégrateurs.