jeudi 13 mars 2014

Comment contrôler si un port est ouvert/accessible sur un serveur Linux.

0°) Introduction.

En mission chez un client, j'ai rencontré une problématique intéressante.
Sur le serveur linux de développement, nous devons faire tourner plusieurs instances de notre serveur d'application (dans notre cas Tomcat) sur des ports différents. Malheureusement, les contraintes de sécurités internes, ne nous permettent pas d'utiliser les ports comme nous l'aurions souhaités. Du coup, il fallait faire une demande auprès du service concernée et attendre que celle-ci soit traitée.

Malheureusement, certaines ouvertures de ports n'étaient pas correctement traitées, et nous avions besoin de contrôler si le port était bien accessible.

1°) Dans le vif du sujet.

Mon premier réflexe a été de penser à faire une configuration spécifique avec un serveur apache/nginx et tester si je pouvais interroger le service depuis un navigateur... Mais j'avais plus  d'une vingtaine de port à tester. La solution devenait beaucoup trop lourde à mettre en oeuvre.

Après une rapide recherche sur internet, j'ai trouver un petit script python (voir ici), que j'ai donc adapter pour mes besoins. Voici le script modifié :

  #!/usr/bin/python
import datetime,BaseHTTPServer,sys
#
# Contruction de la réponse : On renvoi la date et l'heure
#
class MyHandler(BaseHTTPServer.BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.send_header('Content-type','text/plain')
        self.end_headers()
        self.wfile.write(str(datetime.datetime.now()))
        return
#
# On regarde si le port a été passé en paramétre.
# - Si oui on le récupere
# - Si non, on mets le port 18443 par défaut.
#
if len(sys.argv) > 1:
        port =  sys.argv[1]
else:
        port = "18443"
print "En écoute sur le port " + port  +  " ..."
#
# Lancement du service
#
server = BaseHTTPServer.HTTPServer(('',  int(port)), MyHandler)
server.serve_forever()


Bien sur il faut que python soit installé sur votre serveur :-)
Le fonctionnement est assez simple. Il suffit de lancer le script en indiquant le port sur lequel on veut écouter :

user# ./dummyService.py 18443
En écoute sur le port 18443 ...

On peut commencer à faire une requête en local avec wget :

users#  wget localhost:18443
--2014-03-13 15:46:45--  http://localhost:18443/
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:18443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: `index.html.24'

    [ <=>                                                                           ] 26          --.-K/s   in 0s

2014-03-13 15:46:45 (3.54 MB/s) - `index.html.24' saved [26]

Et ensuite essayer d'accéder au serveur depuis un navigateur :


Si le service n'est pas accessible, la réponse du navigateur sera :


Lors du lancement du script, si le port est occupé, le script nous réponds :

En ecoute sur le port 18080 ...
Traceback (most recent call last):
  File "./dummyService.py", line 26, in ?
    server = BaseHTTPServer.HTTPServer(('',  int(port)), MyHandler)
  File "/usr/lib64/python2.4/SocketServer.py", line 330, in __init__
    self.server_bind()
  File "/usr/lib64/python2.4/BaseHTTPServer.py", line 101, in server_bind
    SocketServer.TCPServer.server_bind(self)
  File "/usr/lib64/python2.4/SocketServer.py", line 341, in server_bind
    self.socket.bind(self.server_address)
  File "<string>", line 1, in bind
socket.error: (98, 'Address already in use')

2°) Conclusion.

Voilà, du coup tester si un port est accessible sur un serveur devient très simple et très rapide.
Lors de la mise en place d'un firewall, ce type d'outil peut-être très utile pour tester les règles que l'on mets en place....

mardi 29 janvier 2013

NAGIOS : Vérifier l'état du pare-feu iptables

L'environnent technique des serveurs est le suivant :
  • OS : OpenSuse 12.2
  • Supervision : NAGIOS 3.4
  • Pare-feu : iptables

0°) Introduction

L'objectif de cette article est de vous faire partager un petit outil que j'ai développé pour nos besoins propres, concernant la supervision de la prise en compte des règles d'accès à notre réseau via iptables avec NAGIOS.
Avec la politique de sécurité que nous avions choisis de mettre en place, il était nécessaire de s'assurer que nos règles étaient bien appliquées lors du démarrage de nos serveurs.
Le script est assez basique et contrôle juste le nombre de règles appliquées, déclenchant une alerte lorsque ce nombre est inférieur à un seuil prédéfini.

1°) Les motivations.

Depuis quelques années maintenant, j'ai choisi de configurer sur chacun des nos serveurs des règles de sécurité basées sur iptables. Le mise en place n'a pas été évident et la compréhension des règles a pris pas mal de temps, même en ayant une bonne connaissance du réseau et des trames IP. Mais bon, à l'arrivé nous avons un résultat qui tient la route (du moins c'est l'impression que ça donne !!!).

Seul petit bémol: une fois les règles mises au point, j'avais eu la mauvaise idée de démarrer le pare-feu au moment du boot. Et bien sur, un jour (un très mauvais jour), une erreur dans mon fichier contenant mes règles a bloqué l'ensemble des accès réseaux sur un serveur de production....
De coup, impossible d’accéder à la machine, m'obligeant à me déplacer directement en salle machine pour corriger ce problème en redémarrant le système en mode single et en désactivant le script appliquant les règles de notre pare-feu.

Pas vraiment pratique... du coup j'ai décidé d'appliquer les règles à la main après chaque démarrage. Pas très satisfaisant, mais beaucoup plus sur. Il est souvent nécessaire de faire des compromis en informatique.

2°) Dans le vif du sujet.

Malheureusement, il arrive (pas souvent, mais ça arrive) que les serveurs redémarrent (panne électrique, bug du kernel, mauvaise manipulation des techniciens,...). Du coup Il devenait nécessaire que nous soyons prévenu lorsque ces règles n'étaient pas appliquées.
Comme tous bon informaticien qui se respect, avant de ré-inventer la roue, je me suis mis à chercher un plugin plus ou moins officiel de NAGIOS. A ma grande surprise, je n'ai pas trouvé grand chose. Du moins, en restant diplomate et en modérant mes propos, je dirais que je n'ai pas trouvé de plugin qui pouvait répondre à mes attentes ou alors je n'ai pas été assez malin pour arriver à faire marcher le plugin que j'avais trouvé (check_iptables_status.sh).

Du coup, il ne me restait plus qu'à en développer un... m'inspirant malgré tout du plugin de rhoml, je suis partie sur le même principe : tester le nombre de règles appliquées et déclencher une alerte si on est en dessous d'un certain seuil.

Voici le détail des étapes pour la mise en place de ce script.
cd /usr/lib/nagios/plugins
vi check_firewall.sh
Copier le contenu

#!/bin/sh
#
# Author: Alain TOMASIAN
# Date: 25 Dec. 2012
# Description: Check if the firewall based on iptables is running
#
. /usr/lib/nagios/plugins/utils.sh
print_usage() {
echo "Usage: check_firewall.sh "
}
# Make sure the correct number of command line
IPTABLES_CMD=/usr/sbin/iptables
RESULT=`sudo $IPTABLES_CMD -L -n | wc -l`
if [ $RESULT -lt 10 ] ; then
   echo "FW CRITICAL : The firewall hasn't been started : number of  rules lines = $RESULT"
   exit $STATE_CRITICAL
elif [ $RESULT -lt 100 ] ; then
   echo "FW WARNING : May be the firewall hasn't been started : number of rules lines = $RESULT"
   exit $STATE_WARNING
else
   echo "FW OK : The firewall has been started : number of rules lines = $RESULT"
   exit $STATE_OK
fi
Le point délicat est qu'il faut autoriser l'utilisateur "nagios" à exécuter la commande "iptables". Pour cela, il est nécessaire de passer par sudo :
# sudoedit /etc/sudoers

Ajouter la ligne suivante dans la partie :
    ##
    ## User privilege specification
    ##
    nagios  ALL = (root) NOPASSWD:/usr/sbin/iptables -L -n    
et sauvegarder le fichier.

A cette phase du projet, il n'est pas vraiment facile de tester la commande avec l'utilisateur nagios, car normalement cette utilisateur n'a pas de shell valide....
Pour valider notre travail, il faut continuer la phase configuration, car le problème viendra uniquement lorsqu'on essaiera d'utiliser la commande via nrpe (dans notre cas de figure).

A présent il faut installer la commande au niveau de nrpe et au niveau de nagios.
Sur le serveur à superviser, il faut aujouter dans le fichier de configuration /etc/nagios/nrpe.cfg la ligne suivante dans la description des commandes :
    vi /etc/nagios/nrpe.cfg
    command[check_firewall]=/usr/lib/nagios/plugins/check_firewall.sh

Puis redémarrer nrpe :
    /etc/init.d/nrpe restart

Sur le serveur de supervision, il faut aujouter dans le fichier /etc/nagios/objects/commands.cfg les lignes suivantes :

    vi /etc/nagios/objects/commands.cfg
    # 'check_remote_firewall' command definition
define command { command_name check_remote_firewall command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c check_firewall } # 'check_firewall' command definition define command { command_name check_firewall command_line $USER1$/check_firewall.sh }
Faire un check de la config nagios avant de relancer le serveur :
    /etc/init.d/nagios check
Starting configuration check - passed configuration check done
    /etc/init.d/nagios restart
Shutting down Nagios           done
Starting Nagios                done


A présent, nous pouvons effectuer un test de connexion avec un check_nrpe pour valider le mode de fonctionnement :
# /usr/lib/nagios/plugins/check_nrpe -H xx.xx.xx.xx -c check_firewall
FW OK : The firewall has been started : number of rules lines = 671


Le reste n'est plus qu'une simple formalité car il faut juste configurer sur le serveur de supervision les services pour mettre un check sur les machine à superviser.
Le résultat en image :




3°) Conclusions.


Ce plugin est assez basique et nécessiterait certaines améliorations que j'apporterai peut-être si mon emploi du temp me le permet.... Mais pour l'instant il me rend un grand service en vérifiant que mes règles de sécurités soient bien appliquées.

mercredi 23 janvier 2013

Configuration SSL pour MySQL sous OpenSuse

L'environnent technique des serveurs est le suivant :
  • OS : OpenSuse 12.1
  • Base de données : MySQL Community Server 5.5.28
  • Librairie SSL : OpenSSL 1.0 

0°) Introduction.

Comme je l'ai expliqué dans mon précédent post (Serveurs physiques Versus Serveurs virtuels), nous avons migrer nos serveurs physiques vers des serveurs virtuels. Un des premiers dommages collatéral a été que l'ensemble de nos serveurs ne soient plus sur la même plage de réseau IP et que nous ne puissions plus installer une réseau privé (192.168.0.0/16) entre nos serveurs.

Bien sur, j'aurais pu mettre en place un réseau privé virtuel (VPN) pour faire transiter l'ensemble du trafic interne. Mais j'ai eu la flemme car la plus part des échanges sont fait à travers du ssh et le seul trafic en clair qui était concerné était la réplication de mes bases de données sous MySQL. Donc, je me suis lancé dans la mise en place de connexions sécurisé via SSL pour MySQL.
A priori (d'après ce que j'aivais pu lire) MySQL crypte par défaut l'échange des mots de passe lors de l'établissement d'une connexion. Par contre, une fois la connexion établie, les données transitaient en clair. Même si ces données ne revêtent pas un caractère hyper-sensible, certaines informations doivent demeurer confidentielles. Il devient alors nécessaire de crypter l'ensemble des échanges afin de pouvoir garantir la confidentialité des données échangées.

 

 1°) Dans le vif du sujet.

Pour réaliser cette mise en place, je me suis fortement inspiré de l'article "Sécurisez votre serveur MySQL sous Unix".

Même si on trouve pléthore d'articles sur le net, je vais quand même détailler les différentes étapes que effectuer car j'ai rencontré quelques difficultés qui n'ont pas été toujours simple à résoudre.

 

 1.1°) Création des certificats SSL.

Le premier travail consiste à créer les certificats qui vont être utilisés par MySQL pour le cryptage des communications entre les serveurs.
Il faut commencer par créer un premier certificat qui va nous servir à signer les 2 autres certificats (un certifcat serveur et un certificat client). C'est notre autorité de certification.  Le premier piège est qu'il est indispensable que le CN (Common Name) du certifcat de notre autorité de certification soit différent des autres certificats. Cela semble évident, mais lorsque on autosigne un certificat, on a tendance à donner le même CN. Du moins c'est ce que j'ai fait et j'ai eu énormément de mal ensuite à faire fonctionner la connexion SSL avec MySQL. Voici les lignes de commande pour la création des différents certificats :
diplodocus# cd /etc/ssl/certs
diplodocus# mkdir mysql
diplodocus# cd mysql
diplodocus# openssl req -new -x509 -keyout ca-key.pem -out ca-cert.pem -days 3600

Generating a 1024 bit RSA private key
.......................++++++
...++++++
writing new private key to 'ca-key.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Ile de France
Locality Name (eg, city) []:PARIS
Organization Name (eg, company) [Internet Widgits Pty Ltd]:NAOS Technologies
Organizational Unit Name (eg, section) []:MySQL
Common Name (eg, YOUR name) []:www.naos.com
 
<--- ATTENTION : il est très important que le common name du CA soit différent de ceux des certificats (Voir erreur sinon en bas de page).

Email Address []:alain.tomasian@naos.com

diplodocus# openssl req -new -keyout server-key.pem -out server-req.pem -days 3600
Generating a 1024 bit RSA private key
.....++++++
..........++++++
writing new private key to 'server-key.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Ile de France
Locality Name (eg, city) []:PARIS
Organization Name (eg, company) [Internet Widgits Pty Ltd]:NAOS Technologies
Organizational Unit Name (eg, section) []:MySQL
Common Name (eg, YOUR name) []:*.naos.com
Email Address []:alain.tomasian@naos.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:NAOS Technologies


- On signe le certificat serveur avec la clé de l'autorité de certification que l'on vient de créer :
diplodocus# openssl x509 -req -in server-req.pem -days 3600 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem
Signature ok
subject=/C=FR/ST=Ile de France/L=PARIS/O=NAOS Technologies/OU=MySQL/CN=*.naos.com/emailAddress=alain.tomasian@naos.com
Getting CA Private Key
Enter pass phrase for ca-key.pem:
Generating a 1024 bit RSA private key
...............++++++
..............................++++++
writing new private key to 'client-key.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Ile de France
Locality Name (eg, city) []:PARIS
Organization Name (eg, company) [Internet Widgits Pty Ltd]:NAOS Technologies
Organizational Unit Name (eg, section) []:MySQL
Common Name (eg, YOUR name) []:*.naos.com
Email Address []:alain.tomasian@naos.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:NAOS Technologies


- On signe le certificat client avec la clé de l'autorité de certification que l'on vient de créer :
diplodocus# openssl x509 -req -in client-req.pem -days 3600 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem
Signature ok
subject=/C=FR/ST=Ile de France/L=PARIS/O=NAOS Technologies/OU=MySQL/CN=*.naos.com/emailAddress=alain.tomasian@naos.com
Getting CA Private Key
Enter pass phrase for ca-key.pem:


- On supprime la pass phrase sur les deux certificats :
diplodocus# openssl rsa -in server-key.pem -out server-key.pem
Enter pass phrase for server-key.pem:
writing RSA key
diplodocus# openssl rsa -in client-key.pem -out client-key.pem 
Enter pass phrase for client-key.pem:
writing RSA key

Avant de continuer, on vérifie que les certificats sont ok en passant la commande :
diplodocus# openssl verify -CAfile ca-cert.pem server-cert.pem
server-cert.pem: C = FR, ST = Ile de France, L = PARIS, O = NAOS Technologies, OU = MySQL, CN = *.naos.com, emailAddress = alain.tomasian@naos.com
error 18 at 0 depth lookup:self signed certificate
OK

Si vous avez le résultat ci-dessus, c'est que vous avez un souci. Sinon vous devriez avoir :
diplodocus# openssl verify -CAfile ca-cert.pem server-cert.pem

server-cert.pem: OK
diplodocus# openssl verify -CAfile ca-cert.pem client-cert.pem

client-cert.pem: OK

 

1.2°) Configuration du serveur MySQL.

Voilà, les certificats sont créés, il nous reste maintenant à configurer MySQL pour qu'il puisse gérer les transactions cryptées.
Dans le fichier /etc/my.cf, ajoutons dans le bloc [mysqld] les lignes suivantes :
ssl
ssl-cipher=DHE-RSA-AES256-SHA
ssl-ca=/etc/ssl/certs/mysql/ca-cert.pem
ssl-cert=/etc/ssl/certs/mysql/server-cert.pem
ssl-key=/etc/ssl/certs/mysql/server-key.pem

et dans le bloc [client], ajoutons les lignes suivantes :
ssl-ca = /etc/ssl/certs/mysql/ca-cert.pem
On redémarre le serveur MySQL :
diplodocus# /etc/init.d/mysql restart
Restarting service MySQL
Shutting down service MySQL done
Starting service MySQL done

Si tous se passe bien, on devrait avoir le résultat suivant sous la console MySQL:
diplodocus# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.5.28-log Source distribution
Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
 

mysql> SHOW VARIABLES LIKE '%ssl%';
+-----------------+-----------------------------------------+
| Variable_name   | Value                                   |
+-----------------+-----------------------------------------+
| have_openssl    | YES
                                     |
| have_ssl        | YES
                                     |
| ssl_ca          | /etc/ssl/certs/mysql/ca-cert.pem        |
| ssl_capath      | /etc/ssl/certs/mysql                    |
| ssl_cert        | /etc/ssl/certs/mysql/server-cert.pem    |
| ssl_cipher      | DHE-RSA-AES256-SHA                      |
| ssl_key         | /etc/ssl/certs/mysql/server-key.pem     |
+-----------------+-----------------------------------------+
7 rows in set (0.01 sec)

 

1.3°) Tester la connexion SSL en local.

A présent, il faut tester la connexion ssl. D'abord, nous allons tester le fonctionnement en local. Pour cela nous avons besoin de créer un utilisateur qui ne peut se connecter qu'en utilisant une connexion sécurisée.
mysql> GRANT ALL PRIVILEGES ON *.* TO 'bidon'@'localhost' IDENTIFIED BY "xxxxxxxx" REQUIRE SSL;
Query OK, 0 rows affected (0.00 sec)
mysql> flush privileges ;
Query OK, 0 rows affected (0.00 sec)

Pour tester la connexion il suffit de passer la commande suivante, pour une connexion simple :
# mysql -u bidon -p
Enter password:
ERROR 1045 (28000): Access denied for user 'test'@'localhost' (using password: YES)

On peut remarquer que la connexion échoue. Maintenant en utilisant une connexion sécurisée :
# mysql -u bidon -p --ssl-ca=/etc/ssl/certs/mysql/ca-cert.pem
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 24
Server version: 5.5.25-log Source distribution
Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> quit

Et ô miracle ça fonctionne. Maintenant, tentons la connexion sécurisée depuis un serveur distant.

 

 1.4°) Tester la connexion SSL depuis un serveur distant. 

Notre serveur local est nommé "diplodocus" et le serveur distant "triceratops". Sur diplodocus il faut autoriser un utilisateur à se connecter en SSL depuis triceratops :
mysql> GRANT ALL PRIVILEGES ON bidon.* TO 'bidon'@'triceratops' IDENTIFIED BY "xxxxxxxxx" REQUIRE SSL;
Query OK, 0 rows affected (0.00 sec)
mysql> flush privileges ;
Query OK, 0 rows affected (0.00 sec)

Il faut à présent copier l'ensemble des certificats situé dans le répertoire /etc/certs/mysql/ sur le même répertoire sur triceratops :
triceratops# cd /etc/ssl/certs/mysql
triceratops# scp root@diplodocus.naos.com:/etc/ssl/certs/mysql/client-key.pem .
triceratops# scp root@diplodocus.naos.com:/etc/ssl/certs/mysql/server-cert.pem .
triceratops# scp root@diplodocus.naos.com:/etc/ssl/certs/mysql/client-cert.pem .

Un fois ce travail effecuté, il suffit de tester la connexion distante :
triceratops# mysql -u bidon -p --ssl-ca=/etc/ssl/certs/mysql/ca-cert.pem -h diplodocus
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 25
Server version: 5.5.25-log Source distribution
Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> quit
Bye


Et voilà, le tour est joué...

 

2°) Analyse du trafic réseau pour valider la connexion SSL.

Mais bon comment être sur maintenant que les échanges entre le client et le serveur sont bien crypté ?
Ben, il suffit de regarder ce qui se passe sur le réseau entre les deux machine. Pour cela, j'ai trouvé sur le net un outil permettant d'analyser les paquets liés au trafic réseau MySQL sur une interface : mysqlsniffer.
Voici les étapes pour installer, compiler et utiliser mysqlsniffer (inspiré de : Utilisation de mysqlsniffer) :
diplodocus# mkdir -p /usr/local/src/mysqlsniffer
diplodocus# cd /usr/local/src/mysqlsniffer
diplodocus# wget hackmysql.com/code/mysqlsniffer.tgz
diplodocus# tar xfvz mysqlsniffer.tgz
diplodocus# gcc -O2 -lpcap -o mysqlsniffer mysqlsniffer.c packet_handlers.c misc.c

mysqlsniffer.c:26:18: fatal error: pcap.h: No such file or directory

Là, on se rend compte qu'il manque une librairie :
# zypper install libpcap-devel
# gcc -O2 -lpcap -o mysqlsniffer mysqlsniffer.c packet_handlers.c misc.c
# ls -lt

total 136
-rwxr-xr-x 1 root root 35223 Jan 22 15:50 mysqlsniffer

..............

Ensuite il faut lancer la commande et se connecter à la base distante depuis un autre console:# ./mysqlsniffer -p 3306 eth0
mysqlsniffer listening for MySQL on interface eth0 port 3306
.....................
::FRAGMENT START::
::FRAGMENT END::

......................

Les
::FRAGMENT START:: et ::FRAGMENT END:: montre que la connexion est cryptée, sinon on aurait :# ./mysqlsniffer -p 3306 eth0
mysqlsniffer listening for MySQL on interface eth0 port 3306
server > xx.xx.xx.xx.57842: ID 0 len 78 Handshake <proto 10 ver 5.5.28-log thd 18>
xx.xx.xx.xx.57842 > server: ID 1 len 80 Handshake (new auth) <user bidon db (null) max pkt 16777216>
server > xx.xx.xx.xx.57842: ID 2 len 7 OK <fields 0 affected rows 0 insert id 0 warnings 0>
xx.xx.xx.xx.57842 > server: ID 0 len 33 COM_QUERY: select @@version_comment limit 1
server > xx.xx.xx.xx.57842: ID 1 len 1 1 Fields
ID 2 len 39 Field: ..@@version_comment <type var string (253) size 19>
ID 3 len 5 End <warnings 0>
ID 4 len 20 || Source distribution ||
ID 5 len 5 End <warnings 0>
xx.xx.xx.xx.57842 > server: ID 0 len 18 COM_QUERY: SELECT DATABASE()
server > xx.xx.xx.xx.57842: ID 1 len 1 1 Fields
ID 2 len 32 Field: ..DATABASE() <type var string (253) size 34>
ID 3 len 5 End <warnings 0>
ID 4 len 1 || NULL ||
ID 5 len 5 End <warnings 0>
xx.xx.xx.xx.57842 > server: ID 0 len 5 COM_INIT_DB: bidon
server > xx.xx.xx.xx.57842: ID 1 len 7 OK <fields 0 affected rows 0 insert id 0 warnings 0>
server > xx.xx.xx.xx.44498: ID 0 len 72 Handshake <proto 10 ver 5.5.8 thd 72804>
xx.xx.xx.xx.44498 > server: ID 1 len 85 Handshake (new auth) <user bidon db bidon max pkt 1073741824>
server > xx.xx.xx.xx.44498: ID 2 len 7 OK <fields 0 affected rows 0 insert id 0 warnings 0>
xx.xx.xx.xx.44498 > server: ID 0 len 1 COM_STATISTICS
server > xx.xx.xx.xx.44498: ID 1 len 143 Uptime: 4611470 Threads: 1 Questions: 16883155 Slow queries: 1 Opens: 183 Flush tables: 1 Open tables: 152 Queries per second avg: 3.661
xx.xx.xx.xx.44498 > server: ID 0 len 1 COM_QUIT
xx.xx.xx.xx.57842 > server: ID 0 len 12 COM_QUERY: show tables
server > xx.xx.xx.xx.57842: ID 1 len 1 1 Fields
ID 2 len 86 Field: information_schema.TABLE_NAMES.Tables_in_bidon <type var string (509) size 64>
ID 3 len 5 End <warnings 0>
ID 4 len 5 End <warnings 0>
xx.xx.xx.xx.57842 > server: ID 0 len 1 COM_QUIT


Voilà, l'affaire est dans le sac.

 

3°) Conclusions

Nous voilà maintenant paré, pour mettre en place la réplication entre serveurs MySQL situés sur  réseaux différents. Il reste quand même évident que ce travail vous assure la confidentialité des données échangées, mais n'assure en aucun cas la sécurisation du serveur de base de données qu'est MySQL : c'est un autre sujet.... qui est lui lié à la mise en place d'un pare-feu et d'une vrai politique de sécurité réseau.

Quelques liens intéressant :
- Connexion sécurisée à MySQL (chicoree.fr).
- Sécurisez votre serveur MySQL sous Unix ( developpez.com).

mardi 15 janvier 2013

Serveurs physiques Versus Serveurs virtuels

0°) Introduction

L'objectif de cet article est de vous faire partager mon retour d'expérience sur la migration de l'hébergement de nos serveurs physiques vers un hébergement virtualisé.
Je me suis rendu compte à travers mes recherches que même si on parlait énormément de technologie "Cloud" et "IAAS", il n'était pas vraiment évident de si retrouver dans la jungle des offres disponibles, même pour un professionnel.
Il est possible que la problématique exposée dans cet article soit particulière et ne réponde pas à l'ensemble de vos interrogations. Mais globalement si vous gérez aujourd'hui des serveurs physiques et que vous louez une ou plusieurs baies dans une salle machine, cet article vous donnera un aperçu et surtout un exemple réussi de migration de serveurs physiques vers des serveurs virtuels.

1°) L'état des lieux

Depuis 1998, les serveurs de la société NAOS sont hébergés chez INTERNET-FR. Dans une de leurs salles machines ultra sécurisées, nous avons bénéficié pendant plus de 14 ans d'une qualité de services exceptionnelle. Que ce soit au niveau des caractéristiques techniques mises à notre disposition pour notre hébergement que de la qualité relationnelle avec les équipes techniques. A tel point qu'il ne nous était jamais venu à l'esprit de chercher une autre solution pour l'hébergement de nos serveurs.

Le seul point d'ombre à cela, c'est que nous n'avions pas accès à nos serveurs 24H/24 et 7J/7. Mais, nous avions fait avec. Les pannes étant assez rares, nous avons compensé ce léger souci d'accès par la mise en place de serveurs de secours (1 serveur de secours pour 2 serveurs en production) avec des procédures de bascule en cas de plantage, pour assurer à nos clients un taux de disponibilité le plus élevé possible. Concrétement, comme nous avions à notre disposition une plage de 32 adresses IP, nous avons attribués une adresse IP pour chaque service et une adresse IP pour chaque serveur. Ainsi, il suffisait de reconfigurer les cartes réseaux des serveurs de secours pour que les services soient relancés.

Cette stratégie avait quand même ses limites. En effet, il fallait être sûr que le serveur en panne ne soit pas redémarré, sinon des collisions et des pertes de paquets réseaux risquer de créer de gros souci si sur le même réseaux nous avions configuré la même adresse IP sur 2 cartes différentes.
Mais cela ne c'est jamais présenté.

Malheureusement, toute bonne chose a une fin. Fin Mai 2011, INTERNET-FR est racheté par la société PROSODIE. Jusque-là, pas d'affolement, même si nous nous posons pas mal de questions... L'inquiétude vient d'une annonce deux mois plus tard, mi-juin 2011 sur le rachat de PROSODIE par CAP GEMINI.  Là, nous comprenons que notre aventure avec notre hébergeur est sur sa fin....

Bon, c'est la vie....

Fataliste, même si à ce moment là, nos interlocuteurs privilégiers chez INTERNET-FR se veulent rassurants, nous entamons quand même à notre grand regret notre quête du Saint Graal : 

2°) A la recherche d'un nouvel hébergeur !

Avant d'entamer mes recherches, je fais un état des lieux des prestations que nous disposions afin d'essayer de trouver quelque chose d'approchant. Bien sur, nous avions conscience qu'il serait très difficile de retrouver l'équivalent rapport qualité/prix.
L'état des lieux fût assez rapide :
  • 6 serveurs (double alimentation 500Wx2, et oui les serveurs ne sont pas tous jeunes...)
  • 32 adresses IP
  • 2 routeurs (un réseau local + un réseau public)
  • 1 baie 42U
  • très bonne bande passante
Tant qu'à changer, autant aussi gommer les lacunes de notre précédent hébergement, donc en plus nous voulions :
  • accès à nos serveurs 24h/24 et 7j/7
  • reboot physique à distance
Voilà, YaPluKa

Je commence mes recherches en mars 2012 et elles s'avèrent très difficiles :
  1. Trouver des sociétés qui gèrent des salles machines d'hébergement sur Paris, Ile de France.
  2. Qui sont intéressées par louer 1 seule baie ou 1/2 baie.
  3. Dont le prix de la location n'est pas fonction de la consommation des ressources mais forfaitisé.
  4. Trouver des sociétés qui veulent faire un devis
  5. ...
Je me rends compte que c'est la jungle.... et j'ai énormément de mal a avoir un début de réponse, même en appelant directement les personnes. C'est assez exaspérant et surprenant. Malgré tous j'obtiens 2 devis, de la part de Céleste et de Téléhouse : un grand merci
Mais malheureusement leurs propositions ne correspondent pas à nos attentes.

Devant ce constat d'échec, nous devions changer de stratégie et commencer à penser à abandonner nos machines au profit de machines de locations chez un hébergeur. Là, du coup c'est beaucoup plus facile à trouver car les offres sur ce sujet sont pléthoriques...

3°) Dans le vif du sujet

Depuis quelques années maintenant, j'avais une position assez tranchée sur la mise en place de serveurs virtuels. Mes arguments (pour les environnement Linux) étaient les suivants :
  • Ajout d'un surcouche à l'OS : ce qui ne peut que pénaliser les performances.
  • Ajout d'un SPOF (Single Point Of Failure) : Mettre plusieurs serveurs virtuels sur une seule machine physique.
  • Démultiplication des serveurs : ce qui se traduit par l'accroissement du travail d'administration, de déploiement, de supervision, etc...
  • L'optimisation et la gestion des ressources physiques devient de plus en plus difficile et ce fait uniquement par accroissement des dites ressources...
Donc j'étais plutôt adepte d'optimiser les ressources d'une machine avec un bon OS plutôt que de multiplier l'installation de plusieurs serveurs.

Fin Septembre 2012 un événement va remettre à plat toutes mes convictions : un plantage hardware d'un serveur de production...
  • Impossible de rebooter, 
  • les délais d'intervention de mon hébergeur ont frôlé les 24h
  • la carte réseau du serveur continuait de répondre donc impossible de passer sur le serveur de secours. 
Bilan, chez NAOS on commence à se poser des questions sur l'hébergement de machines physiques. Pourquoi pas s'intéresser au marché de l'hébergement des serveurs virtuels ?
Là aussi, les offres sont pléthorique et nous avions du mal à nous y retrouver, et pourtant l'informatique c'est notre métier, je n'osais même pas imaginer si nous n'avions pas eu les compétences requises pour effectuer ce type de démarches....
Nous avions quand même une assez bonne idée de ce que nous cherchions et nous avions du mal à trouver chaussure à notre pied. Jusqu'à ce que je me rende compte en lisant mes emails, que la société GANDI (le registrar de l'ensemble de mes domaines) était un acteur assez actif dans le marché du Cloud et plus particulièrement dans le domaine du IAAS. Et, ô miracle, fin septembre 2012, GANDI annonce la mise à disposition de la distribution OpenSuse 12.1. Tous les signes étaient au vert pour faire notre choix...

Un tour d'horizon rapide du service proposé par GANDI me permet de constater dans un premier temps que cela peut répondre à nos attentes. Donc, il ne nous restait plus qu'à tester.

Et là, je commence à être assez bluffé par la simplicité et l'accessibilité du service. Comme à son habitude, GANDI travaille essentiellement sur le net. Donc, l'ensemble des opérations s'effectuent via une interface web, qui est assez simple et suffisamment ergonomique. Ce qui m'allait très bien :
  • Pas besoin d'attendre des semaines un hypothétique devis.
  • Aucun engagement dans le temps.
  • Une offre technique très claire et sans surprise.
  • Une offre financière claire et surtout très abordable.
  • ...
Le principe choisi est assez déroutant au début, mais on s'y habitue rapidement. En mode serveur, vous achetez des parts de ressources. A ce jour, une part correspond à :
  • 1 coeur
  • 512 Mo de mémoire
  • 12Go d'espace disque (SAS en Raid 10)
  • 10Mbps de bande passante

Bon, je ne vais pas décrire ici l'ensemble des avantages et des possibilités de la solution GANDI. Le mieux est de se rendre sur leur site pour le découvrir ...

De notre côté, après une quinzaine de jours de tests, nous avons complètement adopté la solution et pris la décision de migrer l'ensemble de nos services.
Avec cette expérience, j'ai remis mes convictions au goûs du jour et aujourd'hui, je commence (enfin! diront certains) à appréhender les bénéfices du cloud pour notre entreprise.

Plusieurs avantages pour nous, que je vais essayer d'énoncer et de commenter (peut-être pas de manière exhaustive) ci-dessous par degré d'importance  :

4°) Zéro serveurs physiques

Le fait de ne plus avoir de serveurs physiques, corrige deux freins majeurs dans notre mode de fonctionnement et dans nos offres de services.
Notre premier frein était lié au coût d'acquisition et de maintenance d'un serveur physiques. Lors de la mise en place de nouveaux services et/ou de propositions de nouvelles prestations, nous étions obligés :
  • d'intégrer dans nos coûts et/ou propositions, l'amortissement de l'achat des serveurs. Pour une proposition, il fallait demander à notre client, un engagement minimum de 36 mois (comptablement, c'est le délai nécessaire pour l'amortissement d'une machine). 
  • de contracter un crédit pour financer cet achat. 
  • de proposer des délais de mise en service pouvant s'étaler sur plusieurs mois (acceptation du crédit, délais de livraison des serveurs, mise en production des services, etc...).
  • de prévoir l'espace nécessaire dans notre baie d'hébergement et le cas échéant d'intégrer un coût supplémentaire de location d'une nouvelle baie.
Le second frein venait de la gestion des ressources de nos serveur et de la gestion de l'obsolescence de notre parc. Concernant l'optimisation des ressources, nous avions des serveurs qui étaient toujours surdimensionnés afin d'éviter de se retrouver sous-dimensionné après quelques mois d'exploitation. Il était très difficile après la mise en production de modifier les caractéristiques physiques d'un serveur :
  • difficulté d'accéder à la salle machine,
  • dans la majorité des cas, l'intervention nécessitait un arrêt des services,
  • risque non négligeable de générer des problèmes collatéraux suite à l'intervention.
Donc comme vous l'aurez compris, aujourd'hui, avec nos serveurs virtualisés, nous avons déporté l'ensemble des problèmes énoncés ci-dessus auprès de notre nouveau prestataire. Plusieurs gains financiers notables très rapidement:
  • réduction de notre TCO (notre coût de possession).
  • suppression de l'ensemble des contrats de maintenance hardware de nos serveurs.
  • réduction de notre facture d'hébergement.

Maintenance et  sauvegarde des données améliorés

5°) Agilité de l'entreprise.

La première conséquence évidente et mesurable induite par le choix de passer à des serveurs virtuels est d'avoir introduit une forme d'agilité dans les "futur services" que nous pourrons proposer.
En effet, la mise en production d'un serveur peut s'effectuer en quelques jours (uniquement liée à la complexité des services à installer).  Le choix de fonctionnement de notre prestataire va nous permettre de proposer à  nos clients de pouvoir s'engager sur des périodes inférieures ou égales à 12 mois.

A titre d'exemple, vous trouverez ci-dessus les délais qui ont été nécessaire pour la migration de notre serveur de supervision basé sur NAGIOS :
  • Délai d'acquisition des ressources auprès de GANDI : 1h
  • Installation d'OpenSuse 12.1 (image GANDI) : 1h
  • Configuration spécifique du serveur : 2h
  • Installation de NAGIOS et configuration des machines et services à superviser : 6h
  • Tests de validation et correction des problèmes : 5h
  • Mise en production : 1h
Soit un total d'environ 16h (deux grosses journées) de travail pour migrer un serveur NAGIOS. Honorable non ?

La deuxième conséquence concerne la gestion et l'évolution des ressources des serveurs. Bon, je n'ai pas une grosse expérience des serveurs virtualisés, mais je trouve que le concept mis en place par GANDI est assez séduisant. Concernant les ressources attribuées, vous avez les ressources propres au serveur (CPU, mémoire) et les ressources externes (carte réseau, espace disque).
Les cartes réseaux et les espaces disques sont attachés à un serveur.
Dans l'exemple ci-dessous, j'ai un serveur 3 cœurs avec 4Go de mémoire auquel est attaché une interface réseau.



Sur ce serveur, j'ai attaché 2 disques :
Un disque qui contient le système d'exploitation et un autre qui contient les données des services qui tournent sur ce serveur.
Premier avantage, en supposant que je dispose de l'espace disque nécessaire, je peux à tout moment faire un spnashot des mes disques très simplement.
Je peux aussi agrandir la taille du disque, à priori sans avoir à redémarrer le serveur. Mais je me suis rendu compte que même en effectuant un resize2fs, j'avais besoin de faire un reboot (qui ne dure que quelques secondes).
Ce qui est séduisant, c'est que je peux détacher les ressources associées à un serveur et les rattacher à un autre serveur (mais je n'ai pas encore testé). Idem pour l'interface réseau (mais je n'ai pas encore testé aussi). Ce qui ouvre des perspectives de garanties de services assez intéressantes.
Avec un peu d'organisation et de rigueur, nous allons améliorer considérablement le taux de disponibilité de nos services (même si celui si était quand même assez bon), offrir aussi des garanties plus importante sur la pérennité des données qui nous sont confiées.

Donc vous l'aurez compris, nos limites en terme de ressources seront étroitement liées à celles de notre prestataire...

6°) Conclusions.

Pour conclure, même si je suis énormément séduit pas les nouvelles perspectives qui me sont aujourd'hui offertes les services virtualisés, je suis quand même conscient que cela soulève certains nouveaux problèmes :
  • une très forte dépendance vis-à-vis de mon prestataire.
  • mes serveurs ne sont plus sur le même réseau.
  • impossible d'installer un réseau privé entre l'ensemble de mes serveurs, donc le trafic même intra-serveur passe par le réseau public.
  • accroissement nécessaire des règles de sécurité et de cryptage des données échangées entre les serveurs.
  • quid des garanties des données en cas de pertes suite à un problème grave sur l'infrastructure du prestataire ?
  • ...
Il faut malgré tous rester réaliste, aujourd'hui il est impossible d'avancer et de proposer des services innovant sans dépendre d'un prestataire... Donc le tous c'est de prévoir des plans de sorties en cas de problèmes.
Nous nous sommes déjà affranchi (du moins nous le pensons ???) des problèmes de sécurités en durcissant et en affinant les règles de nos pares-feux, et des problèmes de confidentialités d'échanges de données intra-serveurs en cryptant ces échanges via OpenSSL (cela fera l'objet d'un autre post concernant la mise en place de crytpage avec MySQL).

Pour les autres nouvelles contraintes, nous allons pour l'instant, déjà profiter des plus apporter par ces nouvelles technologies et nous essayerons dans le futur de palier aux nouveaux problèmes induits par les choix qui ont été fait.

lundi 26 novembre 2012

NRPE : Problème avec la commande check_procs.

NRPE : Problème avec la commande check_procs.

Dernièrement, j'ai eu la malchance d'avoir un problème hard (carte RAID H.S.) sur un de mes serveurs de production.
Bon, ça arrive, le serveur n'était pas tous jeune... Le problème c'est que ce genre de désagrément se produit toujours le week-end :-) Sans être fataliste, d'un autre côté le week-end, l'utilisation des services est moindre, donc l'un d'en l'autre : on va pas se plaindre !!!
La priorité était de remettre les services en route le plus rapidement possible. Une fois le problème hardware mis en évidence (impossible de redémarrer le serveur), il était plus couteux d'essayer de réparer plutôt que de migrer sur un serveur de secours. Donc la solution choisie, voire imposée par les circonstance et le bon sens, consistait à migrer les services.
Après migration et remise en production des services, tous était redevenu à la normale. Ouf, j'ai eu chaud... C'est dans de telle situation que l'on est content d'avoir mis en place des sauvegardes régulières :-)

Touche finale: il ne restait plus qu'à remettre en place mes scripts de supervision sur le nouveau serveur de production.
Une partie du serveur étant déjà supervisé, je n'avais que les scripts spécifiques à mes services à remettre en place. Et là, grosse surprise, la supervision de la présence  de certain processus me renvoyer :
 - PROCS CRITICAL: 0 processes with args 'com.naos.enews.privateInterfaces.utilities.SendingSchedulingEmailings'
- PROCS CRITICAL: 0 processes with args 'com.naos.enews.privateInterfaces.utilities.NewNpaiManager'

Bizarre, car après vérification sur le serveur de production, les processus étaient bien présent et en cours d'exécution.
J'ai exécuté les commandes en direct sur le serveur sans passer par NRPE et là, le résultat était bien celui attendu :
# ./check_procs -c 1:1 -a com.naos.enews.privateInterfaces.utilities.NewNpaiManager
PROCS OK: 1 process with args 'com.naos.enews.privateInterfaces.utilities.NewNpaiManager'

Déduction logique : le problème venait du check_nrpe...
Hop, un petit coup de google and co... Dur dur de trouver la bonne informations...
Après pas mal d'heures de tests, de compilation des sources et pas mal d'heure de recherche sur le net (voire quelques jours...), j'ai enfin trouver "THE SOLUTION".
A priori, le problème proviennait d'une variable d'environnement permettant de limiter le nombre de caractères en sortie de la commande "ps". Lorsque je passais mes tests en local, j'utilisais le compte root. Donc il était normal que j'obtienne le résultat attendu. Par contre en passant pas NRPE, le compte utilisateur était celui de nagios. Le résultat de la commande "ps" était tronqué et la pattern recherchée était absente.

Finalement, la solution la plus élégante pour corriger le problème, a été trouvé via le lien suivant.
J'ai mis en application en modifiant mon fichier de configuration NRPE sur la machine à superviser :

command[check_sending_enews_procs]=COLUMNS=512 /usr/lib/nagios/plugins/check_procs -c 1:1 -a com.naos.enews.privateInterfaces.utilities.SendingSchedulingEmailings
command[check_smtp_log_enews_procs]=COLUMNS=512 /usr/lib/nagios/plugins/check_procs -c 1:1 -a com.naos.enews.privateInterfaces.utilities.NewNpaiManager


Après avoir sauvegardé et relancer le daemon nrpe, j'obtiens afin sur le serveur de supervision le  résultat attendu :

# /usr/local/nagios/libexec/check_nrpe -H 192.168.0.146 -c check_smtp_log_enews_procs
PROCS OK: 1 process with args 'com.naos.enews.privateInterfaces.utilities.NewNpaiManager'

# /usr/local/nagios/libexec/check_nrpe -H 192.168.0.146 -c check_sending_enews_procs
PROCS OK: 1 process with args 'com.naos.enews.privateInterfaces.utilities.SendingSchedulingEmailings'


En conclusion :
Il devient de plus en plus dur de trouver de l'information pertinente sur les moteurs de recherche. Pourtant les problèmes à résoudre sont de plus en plus pointus et demandent quand même une bonne dose de réflexion... D'un autre côté, si c'était facile, ça ne serait pas aussi marrant :-) pour se remuer les méninges non ???

lundi 8 octobre 2012

Optimiser les images de sa lettre

Gérer et optimiser vos images dans vos lettres d'informations.

Le choix du format HTML comme format de diffusion de vos lettres d'informations, vous permet de mettre en valeur votre message par l'insertion d'images et d'illustrations graphiques ce qui va améliorer la lecture de votre message en la rendant plus animée.
Généralement, ces images proviennent soit de votre bibliothèque d'entreprise, soit d'une bibliothèque d'images que vous aurez préalablement sélectionné sur le web. Dans la majorité des cas, les images choisis ne sont pas à la bonne dimension, au bon poids ou parfois vous souhaitez ne récupérer qu'une partie de l'image. Sans les bons outils, nous sommes souvent désemparées lorsqu'il faut optimiser, retailler ou modifier le format d'une image.
Notre article a pour objectif de vous donner quelques pistes afin de réaliser ce type d'opération sans engloutir votre budget communication.

Vous trouverez sur le net, de nombreux logiciels qui sont capables de vous permettre de retailler, d'extraire ou d'optimiser vos images. Loin d'être exhaustif, nous avons sélectionné et testé trois applications sur les environnements Mac et PC. L'investissement des deux premières applications restent raisonnables, un peu moins pour la troisième, mais on ne pouvait pas passer à côté de la référence actuelle du traitement d'image qu'est Photoshop.

Même si aujourd'hui la bande passantes des réseaux est de plus en plus performante, l'optimisation de vos images va vous permettre d'alléger le poids global de votre lettre et favoriser un affichage plus rapide dans les gestionnaires de courriers de vos destinataires.
1BleuPHOTOFILTRE 2BleuPIXELMATOR 3BleuPHOTOSHOP
PhtofiltreLogoCompatible PC
Version gratuite (selon usage) et version Pro . Budget inférieur à 50€.
LogoPixelMatorCompatible MAC
Budget inférieur à 50€
LogoPhotoshopCompatible MAC et PC
Budget supérieur à 400€
PROCEDURE
Commencer par effectuer une copie de sauvegarde de votre image origine.
♦ Pour recadrer/rogner votre image :
Ouvrir votre copie d'image avec Photofiltre phfiltre1
Votre écran se présente avec votre image au centre, une barre horizontale de menus et d'outils dans le haut, une barre verticale d'outils à droite.
Sélectionner dans la barre d'outils, l'outil "Sélection"phfiltre2 .
Sélectionner avec la souris la partie de l'image que vous souhaitez conserver. La partie sélectionnée est encadrée par un pointillé.
Sélectionner
dans le menu "Image", le sous-menu "Recadrer" (ou utiliser le raccourci Maj+ctrl+H).
Il ne vous reste plus à l'écran que la partie souhaitée.

♦ Pour redimensionner votre image :
Sélectionner
dans le menu "Image", le sous-menu "Taille de l'image". Une fenêtre apparaît vous permettant de saisir vos paramètres.
phfiltre4
Cocher l'option 'Conserver les proportions" pour effectuer un redimensionnement homothétique.
Saisir la longueur ou la hauteur en pixels.
Saisir la résolution (généralement 72 pour le web) puis valider.
phfiltre5
♦ Pour sauvegarder l'image modifiée :
Sélectionner dans le menu "Fichier", le sous-menu "Enregistrer sous".
phfiltre6
Choisir le format de l'image (gif ou jpeg). Eviter "png" pour l'emailing.
Sélectionner le répertoire d'enregistrement et valider.
PROCEDURE
Commencer par effectuer une copie de sauvegarde de votre image origine.
♦ Pour recadrer/rogner votre image :
Ouvrir votre copie d'image avec Pixelmator Pixelm1
Votre écran se présente avec votre image au centre, une barre horizontale de menus dans le haut, une barre verticale d'outils à gauche, deux autres fenêtres sur la droite.
Sélectionner dans la barre d'outils, l'outil "Rogner"Pixelm2 .
Sélectionner avec la souris la partie de l'image que vous souhaitez conserver. Pixelm3La partie non sélectionnée est opacifiée.
Valider
votre opération en cliquant en haut à droite sur le bouton "Rogner" Pixelm4.
Il ne vous reste plus à l'écran que la partie souhaitée. Pixelm5♦ Pour redimensionner votre image :
Sélectionner
dans le menu "Image", le sous-menu "Taille de l'image". Une fenêtre apparaît vous permettant de saisir vos paramètres.
Pixelm6
Cocher l'option 'Echelle proportionnelle" pour effectuer un redimensionnement homothétique.
Saisir la longueur ou la hauteur en pixels.
Saisir la résolution (généralement 72 pixels/pouce pour le web) puis valider.
Pixelm7
♦ Pour sauvegarder l'image modifiée :
Sélectionner dans le menu "Partage", le sous-menu "Exporter pour le web".
Choisir les options en haut de l'image telles que
• le format de l'image (gif ou jpeg). Eviter "png" pour l'emailing;
• la qualité de 0 à 100%. Le poids de l'image s'affiche à gauche, en jouant avec ce paramètre, il est possible de le baisser. Il faut alors trouver le bon compromis entre poids et qualité d'image.
Cliquer sur suivant pour finaliser l'enregistrement de votre image et sélectionner le répertoire d'enregistrement.
PROCEDURE
Commencer par effectuer une copie de sauvegarde de votre image origine.
♦ Pour recadrer/rogner votre image :
Ouvrir votre copie d'image avec Photoshopphotoshop1
Votre écran se présente avec votre image au centre, une barre horizontale de menus dans le haut, une barre verticale d'outils à droite ou à gauche, d' autres fenêtres sur la droite.
Sélectionner dans la barre d'outils, l'outil "Rogner"photoshop2 .
Sélectionner avec la souris la partie de l'image que vous souhaitez conserver. photoshop8La partie non sélectionnée est opacifiée.
Valider
votre opération en cliquant en haut à droite sur le bouton "Valider" photoshop4.
Il ne vous reste plus à l'écran que la partie souhaitée. photoshop5
♦ Pour redimensionner votre image :
Sélectionner
dans le menu "Image", le sous-menu "Taille de l'image". Une fenêtre apparaît vous permettant de saisir vos paramètres.
photoshop6
Cocher l'option 'Echelle proportionnelle" pour effectuer un redimensionnement homothétique.
Saisir la longueur ou la hauteur en pixels.
Saisir la résolution (généralement 72 pixels/pouce pour le web) puis valider.
photoshop7
♦ Pour sauvegarder l'image modifiée :
Sélectionner dans le menu "Fichier", le sous-menu "Enregistrer pour le web".
Choisir les options à droite de l'image telles que
• le format de l'image (gif ou jpeg). Eviter "png" pour l'emailing;
• la qualité. Le poids de l'image s'affiche sous l'image, en jouant avec ce paramètre, il est possible de le baisser. Il faut alors trouver le bon compromis entre poids et qualité d'image.
Valider pour finaliser l'enregistrement de votre image et sélectionner le répertoire d'enregistrement.
Voilà, avec ces informations, vous devriez être capable à présent de retailler ou d'optimiser vos images pour vos lettres d'informations.

Chantal KERMAIDIC
Responsable de la communication

Images bloquées, quelles parades ?

Impact de l'attribut "alt" dans les images de votre lettre.

Les images d'une newsletter sont parfois bloquées à l'arrivée sur les postes destinataires en fonction de  l'outil de messagerie utilisé ou de son paramétrage. Votre objectif est d'arriver à rendre votre lettre suffisament attractive  pour que votre destinataire s'y intéresse même si les images sont bloquées.
Dans cette situation, qui ne dépend malheureusement pas de vous, les questions suivantes se posent :
  • comment réussir à intéresser votre destinataire ?
  • comment éviter qu’il ignore ou efface votre email immédiatement?
  • comment lui suggérer d’aller vers votre site ?
  • comment éviter qu’il ne se désabonne ?
  • comment l’inciter à débloquer les images ?
Dans le code HTML de votre lettre, l'insertion d'une image nécessite au minimum l'ajout du code : <img src="nom du fichier"  />
Pour faciliter la mise en page,  les valeurs de longueur et largeur sont généralement renseignés ainsi qu'un texte alternatif :  <img src="nom du fichier" height="hauteur" width="largeur" alt="mon image" />
Dans la réalisation d'une lettre d'information il est fortement conseillé de renseigner les attribut de taille de l'image.
D'autres attributs existent permettant de gérer la position de l'image (droite, gauche, ...) ainsi que sa distance par rapport au texte environant (horizontalement, verticalement,).
Dans cet article, nous allons nous intéresser de plus près à l'attribut "alt".
Comme énoncé plus haut, l'attribut "alt" (pour "alternatif") permet de définir le texte à afficher en lieu et place de l'image si celle-ci ne s'affiche pas suite à un problème de connexion, un problème d'indisponibilité du serveur qui héberge l'image, etc....
Renseigner ce champ évite dans certain cas, de trouver sur sa page (lorsque les images sont bloquées) des images de remplacement du style :

exemple1 ou exemple2
Il devient donc logique de se poser les bonnes questions lors de la réalisation de son message :
  • Dans quels cas faut-il renseigner ce champ ?
  • Quel type de texte faut-il insérer ?
  • Comment mettre en valeur ce texte ?
Si le texte de subsitution s'affiche en lieu et place de l'image, il faut avoir en tête que ce contenu va disposer de l'espace initialement prévu pour l'image.Cette contrainte doit être prise en compte au moment de la rédaction du texte.
Bien sur tous les images n'ont pas besoin de disposer d'un texte alternatif. En effet, certaines images qui composent votre lettre sont purement décoratives (angles arrondis, des séparations graphiques, ...) et ne nécéssitent aucun texte de subsitution.Malgrè tout, si nous voulons éviter "l'affreuse image bloquée", nous allons renseigner notre attribut "alt" avec un seul caractère discret (du style "." ou "-" par exemple). Dans la suite de cet article, nous vous montrerons comment nous pouvons jouer sur son style CSS pour le rendre encore plus discret si nécessaire.
Pour des images du type puce imagée, nous mettrons comme attribut un caractère symbolisant une puce (point, flèche, ...).
Pour des images du type bouton à cliquer, l'attribut "alt" sera renseigné selon le cas par un texte du type "cliquez ici pour vous inscrire". Le destinataire saura ainsi où cliquer et pour quelle raison sans voir l'image.
Pour substutuer un logo, le nom de la société, de la marque ou du produit qu'il symbolise peut-être utilisé.
Pour une "grosse" image contenant un texte (avec une police particulière ou un fond spécifique), utilisez l'attribut pour réécrire le texte ou l'accroche. Attention, si pour des raisons d'intégration votre image a été découpée en plusieurs images, évitez de renseigner l'attribut de chaque morceau avec un texte. Faites-le sur le ou les plus grosses images, ou l'image la mieux placée et pour les autres mettez juste un seul caractère discret comme texte de subsitution.

A ce stade, si les images sont bloquées, votre lettre devrait déjà être plus lisible et le code HTML de la déclaration de votre image devrait ressembler à ceci :<img src="nom du fichier" height="hauteur" width="largeur" border="0" alt="mon texte de substitution" /> (hormis les autres attributs d'image qui auraient pu être renseignés).

Nous allons à présent, nous intéresser à l'enrichissement du texte de substitution afin de le "styler" pour redonner un peu plus de peps à notre lettre. Effectivement, il est tout à fait possible d'appliquer un style de texte à notre image qui ne va en aucun cas influer sur le rendu de l'image, mais qui s'appliquera au texte alternatif si celui-ci était présenté. Il est quand même à signaler que cet artifice technique, n'est pas reconnue par tous les outils de messagerie mais par la plupart.
Pour vous donner une exemple, nous allons travailler sur le texte de substitution de votre logo.
  • La taille de police pour être assez visible pourra être augmenter à 24px ou plus.
  • La couleur de la police pourra être choisie en fonction de la couleur dominante de votre charte graphique.
  • Si vous avez une couleur de fond foncée, la couleur de votre texte de substitution devra être d'une couleur clair, pour qu'il soit visible (voir l'exemple ci-dessous, le texte de substitution apparaît en blanc).
Votre code devrait ressembler à : <img src="nom du fichier" height="hauteur" width="largeur" Alt="mon texte de substitution" style="font-family: Arial, Helvetica, Verdana, Tahoma, sans-serif; font-size: 12px; color: #fff;"/>
Pour les textes de subsitutions contenant les caractères "discrets" cités plus hauts, vous pouvez minimiser leur présence choisissant une taille de police très petite.
Voici ci-dessous un exemple de mise en valeur de newsletter avec l'utilisation de l'attribut Alt
AvecouSansImages
Voilà, à vous de jouer avec le "alt" à présent !
Votre message pourra désormais avoir un impact plus percutant même si les images sont bloquées...
Chantal KERMAIDIC
Reponsable de la communication

vendredi 4 mai 2012

NUMERICABLE: Sécurité et port ouvert

Depuis que j'ai subi l'installation d'un cheval de Troie sur un de mes serveurs il y a maintenant presque deux ans de cela, je suis devenu de plus en plus prudent et surtout de plus en plus restrictif (voire paranoïaque) sur l'accès des services au niveau de mes serveurs. A l'époque, j'avais eu l'outrecuidance de croire que les applications OpenSource que j'installais et que j'utilisais, étaient plus ou moins sécurisées. Je n'avais pas pris la peine de vérifier et de mettre à jours régulièrement phpMyAdmin. Ayant laissé les scripts de setup ouverts, il n'a pas fallu longtemps à mes assaillants pour installer un cheval de Troie. Alerté par le trafic réseau anormal et après quelques heures de recherche, je suis arrivé à nettoyer le serveur infecté et à combler le trou de sécurité.

Depuis cette époque, j'ai installé sur chacun de mes serveurs un firewall système (iptable) et je n'ouvre les services qu'avec parcimonie et à bon escient.

Dernièrement j'installe une nouvelle version d'eGroupWare que j'envisage de faire fonctionner sur le port 445 (microsoft-ds). je vérifie, avant bien sur, dans le fichier /etc/services à quoi correspond l'utilisation de ce port. Pas de souci, c'est un port qui est réservé par le protocole Samba, que je n'utilise pas.

En déplacement lors de mon installation, mes tests de validations sont donc effectués depuis une connexion ADSL chez SFR. Je configure l'accès de port 445 depuis l'adresse IP que j'utilise à ce moment là :

root# iptables -t filter -A INPUT -p tcp --dport 445 -s xxx.xxx.xxx.0/24 -j ACCEPT
root# iptables -t filter -A OUTPUT -p tcp --dport 445 -s xxx.xxx.xxx.0/24 -j ACCEPT

et pas de souci, tous fonctionne correctement. De retour chez moi avec une connexion ADSL Free et après avoir mis les bonnes autorisations, pas de souci aussi, ça fonctionne.
Par contre, de retour au bureau avec une connexion numéricable, là même après avoir configuré convenable mon firewall, impossible d'accès à mon site avec un joli message super bien explicite :


Après avoir passé quelques heures à faire des tests dans tous les sens au niveau de la configuration de mon firewall, je me rends compte qu'avec ou sans firewall, impossible d'accéder à ce service quoi que je fasse. Alors qu'un autre service sur un port différent, passe sans problème. Du coup, je me mets à suspecter le port en question. Effectivement, après une recherche sur le net, j'apprends que le port 445 qui est utilisé par le port Samba est potentiellement un trou de sécurité et peut permettre la récupération des mots de passes d'un PC, donc bloqué chez numéricable.... Mais je suis sur Mac moaaaaa !!!!
Pour résoudre mon problème, j'ai modifié le port d'accès et à présent cela fonctionne...

Beaucoup de temps perdu pour une information qui n'est pas diffusé par numéricable, mais bon c'est toujours satisfaisant de trouver la solution à un problème.


jeudi 26 avril 2012

OpenSuse 12.1: Installer eGroupWare

J'utilise eGroupWare depuis pas mal de temps, pour le module "Base de connaissance". Bon, je sais, installer un outil aussi complet pour n'utiliser qu'un seul module, c'est un peu du luxe. Mais (pour l'instant, car je continu de chercher) je n'ai pas trouvé d'outils OpenSource me permettant de gérer convenablement les informations techniques que j'amasse quotidiennement. Donc comme j'ai les serveurs, comme j'ai les ressources et comme j'ai les compétences, pourquoi ne pas s'offrir le luxe d'installer eGroupWare sur un de nos serveurs ?

Ma dernière installation d'eGroupWare (en version 1.4), remontait à plus de 3ans... mon premier réflexe a donc été d'essayer de mettre à jours, la version existante. Bien mal m'en a pris... Heureusement que dans ma grande sagesse (et surtout avec déjà beaucoup d'upgrade manqués aux compteurs), j'avais sauvegardé à la fois la base et le répertoire d'eGroupWare. Ce qui m'a permis de revenir en arrière sans avoir perdu la moindre information.... Ouf ...
Donc après cette petite mésaventure, je me décide à installer une nouvelle instance d'eGroupWare sur un serveur à part, histoire d'être tranquille.
Le souvenir que j'en avais, c'était qu'eGroupWare avait beaucoup de dépendances au niveau des modules php et que lors de mes premières installations, j'avais pas mal galéré pour toutes les ajouter à la main.
Utilisant depuis quelques temps maintenant le super outil de gestion des packages d'OpenSuse 'zypper', je me dis pourquoi ne pas en profiter pour l'installation d'eGroupWare ? Effectivement, sur le site d'eGroupWare, on trouve justement un repository pour pouvoir utiliser zypper.

Et voilà que l'installation commence.

Etape 1 : ajouter les référence du repository
piaf:~ # zypper addrepo http://download.opensuse.org/repositories/server:/eGroupWare/openSUSE_12.1/ 'openSUSE-12.1 eGroupWare'
Adding repository 'openSUSE-12.1 eGroupWare' [done]
Repository 'openSUSE-12.1 eGroupWare' successfully added
Enabled: Yes
Autorefresh: No
GPG check: Yes
URI: http://download.opensuse.org/repositories/server:/eGroupWare/openSUSE_12.1/


Etape 2 : mettre à jours les informations du nouveau repository
piaf:~ # zypper lr -u
# | Alias                    | Name                     | Enabled | Refresh | URI                                                                       
--+--------------------------+--------------------------+---------+---------+----------------------------------------------------------------------------
1 | openSUSE-12.1 eGroupWare | openSUSE-12.1 eGroupWare | Yes     | No      | http://download.opensuse.org/repositories/server:/eGroupWare/openSUSE_12.1/
2 | repo-12.1-non-oss        | openSUSE-12.1 Non-OSS    | Yes     | No      | http://download.opensuse.org/distribution/12.1/repo/non-oss/              
3 | repo-12.1-oss            | openSUSE-12.1 OSS        | Yes     | No      | http://download.opensuse.org/distribution/12.1/repo/oss/                  
4 | repo-12.1-update         | openSUSE-12.1 Updates    | Yes     | No      | http://download.opensuse.org/update/12.1/       
                          

piaf:~ # zypper refresh
Retrieving repository 'openSUSE-12.1 eGroupWare' metadata [\]

New repository or package signing key received:
Key ID: DC0A179E47E7FC8D
Key Name: server:eGroupWare OBS Project <server:eGroupWare@build.opensuse.org>
Key Fingerprint: A8533F680C15B1B9DC69036BDC0A179E47E7FC8D
Key Created: Sat Apr  3 09:02:42 2010
Key Expires: Mon Jun 11 09:02:42 2012 (expires in 45 days)
Repository: openSUSE-12.1 eGroupWare

Do you want to reject the key, trust temporarily, or trust always? [r/t/a/?] (r): a
Retrieving repository 'openSUSE-12.1 eGroupWare' metadata [done]
Building repository 'openSUSE-12.1 eGroupWare' cache [done]
Repository 'openSUSE-12.1 Non-OSS' is up to date.
Repository 'openSUSE-12.1 OSS' is up to date.
Retrieving repository 'openSUSE-12.1 Updates' metadata [done]
Building repository 'openSUSE-12.1 Updates' cache [done]
All repositories have been refreshed.
 


Etape 3 : installation d'eGroupWare
piaf:~ # zypper search egroupware
Loading repository data...
Reading installed packages...

S | Name                       | Summary                                                   | Type     
--+----------------------------+-----------------------------------------------------------+-----------
  | eGroupware                 | EGroupware is a web-based groupware suite written in php. | package  
  | eGroupware                 | EGroupware is a web-based groupware suite written in php. | srcpackage
  | eGroupware-bookmarks       | The EGroupware bookmarks application                      | package  
  | eGroupware-calendar        | The EGroupware calendar application                       | package  
  | eGroupware-core            | The EGroupware core                                       | package  
  | eGroupware-developer_tools | The EGroupware developer_tools application                | package  
  | eGroupware-egw-pear        | The EGroupware egw-pear application                       | package  
  | eGroupware-emailadmin      | The EGroupware emailadmin application                     | package  
  | eGroupware-felamimail      | The EGroupware Webmail application                        | package  
  | eGroupware-filemanager     | The EGroupware filemanager application                    | package  
  | eGroupware-gallery         | The EGroupware gallery application                        | package  
  | eGroupware-importexport    | The EGroupware importexport application                   | package  
  | eGroupware-infolog         | The EGroupware infolog application                        | package  
  | eGroupware-manual          | The EGroupware manual application                         | package  
  | eGroupware-news_admin      | The EGroupware news_admin application                     | package  
  | eGroupware-notifications   | The EGroupware notifications application                  | package  
  | eGroupware-phpbrain        | The EGroupware phpbrain application                       | package  
  | eGroupware-phpfreechat     | The EGroupware chat application                           | package  
  | eGroupware-phpsysinfo      | The EGroupware phpsysinfo application                     | package  
  | eGroupware-polls           | The EGroupware polls application                          | package  
  | eGroupware-projectmanager  | The EGroupware projectmanager application                 | package  
  | eGroupware-registration    | The EGroupware registration application                   | package  
  | eGroupware-resources       | The EGroupware resources application                      | package  
  | eGroupware-sambaadmin      | The EGroupware sambaadmin application                     | package  
  | eGroupware-sitemgr         | The EGroupware Sitemanager CMS application                | package  
  | eGroupware-syncml          | The EGroupware syncml application                         | package  
  | eGroupware-timesheet       | The EGroupware timesheet application                      | package  
  | eGroupware-tracker         | The EGroupware trouble ticket system application          | package  
  | eGroupware-wiki            | The EGroupware wiki application                           | package  

piaf:~ # zypper install eGroupware
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following NEW packages are going to be installed:
  eGroupware eGroupware-bookmarks eGroupware-calendar eGroupware-core eGroupware-developer_tools eGroupware-egw-pear eGroupware-emailadmin
  eGroupware-felamimail eGroupware-filemanager eGroupware-importexport eGroupware-infolog eGroupware-manual eGroupware-news_admin eGroupware-notifications
  eGroupware-phpbrain eGroupware-phpfreechat eGroupware-phpsysinfo eGroupware-polls eGroupware-projectmanager eGroupware-registration eGroupware-resources
  eGroupware-sambaadmin eGroupware-sitemgr eGroupware-syncml eGroupware-timesheet eGroupware-tracker eGroupware-wiki jpgraph libc-client2007e_suse php5-bz2
  php5-gd php5-imap php5-posix php5-zip t1lib tnef

36 new packages to install.
Overall download size: 21.7 MiB. After the operation, additional 69.0 MiB will be used.
Continue? [y/n/?] (y):
Retrieving package tnef-1.4.9-1.1.x86_64 (1/36), 45.0 KiB (131.0 KiB unpacked)
Retrieving: tnef-1.4.9-1.1.x86_64.rpm [done]
Retrieving package libc-client2007e_suse-2007e_suse-9.1.2.x86_64 (2/36), 405.0 KiB (1.1 MiB unpacked)
Retrieving: libc-client2007e_suse-2007e_suse-9.1.2.x86_64.rpm [done]
Retrieving package php5-bz2-5.3.8-4.12.2.x86_64 (3/36), 27.0 KiB (28.0 KiB unpacked)
Retrieving: php5-bz2-5.3.8-4.12.2.x86_64.rpm [done (0 B/s)]
Retrieving package php5-posix-5.3.8-4.12.2.x86_64 (4/36), 27.0 KiB (32.0 KiB unpacked)
Retrieving: php5-posix-5.3.8-4.12.2.x86_64.rpm [done]
Retrieving package php5-zip-5.3.8-4.12.2.x86_64 (5/36), 49.0 KiB (88.0 KiB unpacked)
Retrieving: php5-zip-5.3.8-4.12.2.x86_64.rpm [done]
Retrieving package t1lib-5.1.2-15.7.1.x86_64 (6/36), 152.0 KiB (405.0 KiB unpacked)
Retrieving: t1lib-5.1.2-15.7.1.x86_64.rpm [done]
Retrieving package php5-imap-5.3.8-4.12.2.x86_64 (7/36), 46.0 KiB (100.0 KiB unpacked)
Retrieving: php5-imap-5.3.8-4.12.2.x86_64.rpm [done]
Retrieving package php5-gd-5.3.8-4.12.2.x86_64 (8/36), 99.0 KiB (333.0 KiB unpacked)
Retrieving: php5-gd-5.3.8-4.12.2.x86_64.rpm [done]
Retrieving package jpgraph-3.0.7-2.1.noarch (9/36), 9.8 MiB (21.8 MiB unpacked)
Retrieving: jpgraph-3.0.7-2.1.noarch.rpm [done (4.4 MiB/s)]
Retrieving package eGroupware-core-1.8.004.20120423-1.1.noarch (10/36), 5.6 MiB (23.8 MiB unpacked)
Retrieving: eGroupware-core-1.8.004.20120423-1.1.noarch.rpm [done (4.2 MiB/s)]
Retrieving package eGroupware-wiki-1.8.004.20120423-1.1.noarch (11/36), 152.0 KiB (487.0 KiB unpacked)
Retrieving: eGroupware-wiki-1.8.004.20120423-1.1.noarch.rpm [done]
Retrieving package eGroupware-tracker-1.8.004.20120423-1.1.noarch (12/36), 136.0 KiB (555.0 KiB unpacked)
Retrieving: eGroupware-tracker-1.8.004.20120423-1.1.noarch.rpm [done]
Retrieving package eGroupware-timesheet-1.8.004.20120423-1.1.noarch (13/36), 91.0 KiB (265.0 KiB unpacked)
Retrieving: eGroupware-timesheet-1.8.004.20120423-1.1.noarch.rpm [done]
Retrieving package eGroupware-sitemgr-1.8.004.20120423-1.1.noarch (14/36), 825.0 KiB (2.8 MiB unpacked)
Retrieving: eGroupware-sitemgr-1.8.004.20120423-1.1.noarch.rpm [done]
Retrieving package eGroupware-sambaadmin-1.8.004.20120423-1.1.noarch (15/36), 49.0 KiB (79.0 KiB unpacked)
Retrieving: eGroupware-sambaadmin-1.8.004.20120423-1.1.noarch.rpm [done]
Retrieving package eGroupware-resources-1.8.004.20120423-1.1.noarch (16/36), 106.0 KiB (338.0 KiB unpacked)
Retrieving: eGroupware-resources-1.8.004.20120423-1.1.noarch.rpm [done]
Retrieving package eGroupware-registration-1.8.004.20120423-1.1.noarch (17/36), 161.0 KiB (434.0 KiB unpacked)
Retrieving: eGroupware-registration-1.8.004.20120423-1.1.noarch.rpm [done]
Retrieving package eGroupware-projectmanager-1.8.004.20120423-1.1.noarch (18/36), 397.0 KiB (1.6 MiB unpacked)
Retrieving: eGroupware-projectmanager-1.8.004.20120423-1.1.noarch.rpm [done]
Retrieving package eGroupware-polls-1.8.004.20120423-1.1.noarch (19/36), 68.0 KiB (142.0 KiB unpacked)
Retrieving: eGroupware-polls-1.8.004.20120423-1.1.noarch.rpm [done]
Retrieving package eGroupware-phpsysinfo-1.8.004.20120423-1.1.noarch (20/36), 267.0 KiB (1.0 MiB unpacked)
Retrieving: eGroupware-phpsysinfo-1.8.004.20120423-1.1.noarch.rpm [done (843.8 KiB/s)]
Retrieving package eGroupware-phpfreechat-1.8.004.20120423-1.1.noarch (21/36), 971.0 KiB (4.7 MiB unpacked)
Retrieving: eGroupware-phpfreechat-1.8.004.20120423-1.1.noarch.rpm [done]
Retrieving package eGroupware-phpbrain-1.8.004.20120423-1.1.noarch (22/36), 155.0 KiB (639.0 KiB unpacked)
Retrieving: eGroupware-phpbrain-1.8.004.20120423-1.1.noarch.rpm [done]
Retrieving package eGroupware-notifications-1.8.004.20120423-1.1.noarch (23/36), 58.0 KiB (115.0 KiB unpacked)
Retrieving: eGroupware-notifications-1.8.004.20120423-1.1.noarch.rpm [done]
Retrieving package eGroupware-news_admin-1.8.004.20120423-1.1.noarch (24/36), 105.0 KiB (361.0 KiB unpacked)
Retrieving: eGroupware-news_admin-1.8.004.20120423-1.1.noarch.rpm [done]
Retrieving package eGroupware-infolog-1.8.004.20120423-1.1.noarch (25/36), 294.0 KiB (1.3 MiB unpacked)
Retrieving: eGroupware-infolog-1.8.004.20120423-1.1.noarch.rpm [done (0 B/s)]
Retrieving package eGroupware-importexport-1.8.004.20120423-1.1.noarch (26/36), 206.0 KiB (432.0 KiB unpacked)
Retrieving: eGroupware-importexport-1.8.004.20120423-1.1.noarch.rpm [done]
Retrieving package eGroupware-egw-pear-1.8.004.20120423-1.1.noarch (27/36), 105.0 KiB (503.0 KiB unpacked)
Retrieving: eGroupware-egw-pear-1.8.004.20120423-1.1.noarch.rpm [done]
Retrieving package eGroupware-developer_tools-1.8.004.20120423-1.1.noarch (28/36), 82.0 KiB (220.0 KiB unpacked)
Retrieving: eGroupware-developer_tools-1.8.004.20120423-1.1.noarch.rpm [done]
Retrieving package eGroupware-calendar-1.8.004.20120423-1.1.noarch (29/36), 467.0 KiB (2.4 MiB unpacked)
Retrieving: eGroupware-calendar-1.8.004.20120423-1.1.noarch.rpm [done]
Retrieving package eGroupware-bookmarks-1.8.004.20120423-1.1.noarch (30/36), 121.0 KiB (280.0 KiB unpacked)
Retrieving: eGroupware-bookmarks-1.8.004.20120423-1.1.noarch.rpm [done]
Retrieving package eGroupware-manual-1.8.004.20120423-1.1.noarch (31/36), 56.0 KiB (61.0 KiB unpacked)
Retrieving: eGroupware-manual-1.8.004.20120423-1.1.noarch.rpm [done]
Retrieving package eGroupware-syncml-1.8.004.20120423-1.1.noarch (32/36), 65.0 KiB (235.0 KiB unpacked)
Retrieving: eGroupware-syncml-1.8.004.20120423-1.1.noarch.rpm [done]
Retrieving package eGroupware-filemanager-1.8.004.20120423-1.1.noarch (33/36), 171.0 KiB (476.0 KiB unpacked)
Retrieving: eGroupware-filemanager-1.8.004.20120423-1.1.noarch.rpm [done (0 B/s)]
Retrieving package eGroupware-emailadmin-1.8.004.20120423-1.1.noarch (34/36), 121.0 KiB (497.0 KiB unpacked)
Retrieving: eGroupware-emailadmin-1.8.004.20120423-1.1.noarch.rpm [done]
Retrieving package eGroupware-felamimail-1.8.004.20120423-1.1.noarch (35/36), 361.0 KiB (1.6 MiB unpacked)
Retrieving: eGroupware-felamimail-1.8.004.20120423-1.1.noarch.rpm [done]
Retrieving package eGroupware-1.8.004.20120423-1.1.noarch (36/36), 30.0 KiB (0 B unpacked)
Retrieving: eGroupware-1.8.004.20120423-1.1.noarch.rpm [done]
Installing: tnef-1.4.9-1.1 [done]
Installing: libc-client2007e_suse-2007e_suse-9.1.2 [done]
Installing: php5-bz2-5.3.8-4.12.2 [done]
Installing: php5-posix-5.3.8-4.12.2 [done]
Installing: php5-zip-5.3.8-4.12.2 [done]
Installing: t1lib-5.1.2-15.7.1 [done]
Installing: php5-imap-5.3.8-4.12.2 [done]
Installing: php5-gd-5.3.8-4.12.2 [done]
Installing: jpgraph-3.0.7-2.1 [done]
Installing: eGroupware-core-1.8.004.20120423-1.1 [done]
Installing: eGroupware-wiki-1.8.004.20120423-1.1 [done]
Installing: eGroupware-tracker-1.8.004.20120423-1.1 [done]
Installing: eGroupware-timesheet-1.8.004.20120423-1.1 [done]
Installing: eGroupware-sitemgr-1.8.004.20120423-1.1 [done]
Installing: eGroupware-sambaadmin-1.8.004.20120423-1.1 [done]
Installing: eGroupware-resources-1.8.004.20120423-1.1 [done]
Installing: eGroupware-registration-1.8.004.20120423-1.1 [done]
Installing: eGroupware-projectmanager-1.8.004.20120423-1.1 [done]
Installing: eGroupware-polls-1.8.004.20120423-1.1 [done]
Installing: eGroupware-phpsysinfo-1.8.004.20120423-1.1 [done]
Installing: eGroupware-phpfreechat-1.8.004.20120423-1.1 [done]
Installing: eGroupware-phpbrain-1.8.004.20120423-1.1 [done]
Installing: eGroupware-notifications-1.8.004.20120423-1.1 [done]
Installing: eGroupware-news_admin-1.8.004.20120423-1.1 [done]
Installing: eGroupware-infolog-1.8.004.20120423-1.1 [done]
Installing: eGroupware-importexport-1.8.004.20120423-1.1 [done]
Installing: eGroupware-egw-pear-1.8.004.20120423-1.1 [done]
Installing: eGroupware-developer_tools-1.8.004.20120423-1.1 [done]
Installing: eGroupware-calendar-1.8.004.20120423-1.1 [done]
Installing: eGroupware-bookmarks-1.8.004.20120423-1.1 [done]
Installing: eGroupware-manual-1.8.004.20120423-1.1 [done]
Installing: eGroupware-syncml-1.8.004.20120423-1.1 [done]
Installing: eGroupware-filemanager-1.8.004.20120423-1.1 [done]
Installing: eGroupware-emailadmin-1.8.004.20120423-1.1 [done]
Installing: eGroupware-felamimail-1.8.004.20120423-1.1 [done]
Installing: eGroupware-1.8.004.20120423-1.1 [done]
Additional rpm output:
/var/tmp/rpm-tmp.tlGGWE: line 2: /usr/bin/php5: No such file or directory
EGroupware install log saved to /root/eGroupware-install.log


Et voilà, le tour est joué... facile non?
Juste un petit souci, car il manque l'exécutable /usr/bin/php5. Pour cela il suffit d'installer le package php5 (j'ai quand même mis un bout de temp à trouver le bon package, car un package php5 était déjà installé, mais ce n'était pas le bon) :

piaf:~ # zypper install php5
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following package is going to be upgraded:
  php5

1 package to upgrade.
Overall download size: 1.1 MiB. No additional space will be used or freed after the operation.
Continue? [y/n/?] (y):
Retrieving package php5-5.3.8-4.12.2.x86_64 (1/1), 1.1 MiB (4.6 MiB unpacked)
Retrieving: php5-5.3.8-4.12.2.x86_64.rpm [done (0 B/s)]
Installing: php5-5.3.8-4.12.2 [done]


Beaucoup plus simple à installer car je n'ai plus à m'occuper des dépendances. Par défaut, les fichiers d'eGroupWare sont situé dans /usr/share/egroupware. Il suffit donc maintenant de configurer apaache et de suivre les instructions d'installation d'eGroupWare. Je n'ai rencontré aucun problème pour la suite, mais si vous avez un souci, n'hésitez pas à me laisser une question.