Installation de mise à jour ESXi 5.0

Laisser un commentaire

La mise à jour d’un hôte ESXi 5.0 est très similaire à celle d’un hôte 4.1 (voir mon article pour ESXi 4.1). Cependant, les commandes à exécuter ont légèrement changé : il faut désormais utilier la commande 

esxcli software vib update -d fichier_bundle.zip

au lieu d’esxupdate.

Voici un exemple complet :

~ # cd /vmfs/volumes/datastore1/
/vmfs/volumes/4e5be3fd-b70bca00-7964-bc305bdf94b9 # wget http://hostupdate.vmware.com/software/VUM/OFFLINE/release-313-20110906-767411/ESXi500-201109001.zip
Connecting to hostupdate.vmware.com (2.18.131.51:80)
ESXi500-201109001.zi 100% |*************************************************************************************************|   281M 00:00:00 ETA
/vmfs/volumes/4e5be3fd-b70bca00-7964-bc305bdf94b9 # esxcli software vib update -d /vmfs/volumes/datastore1/ESXi500-201109001.zip
Installation Result
   Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
   Reboot Required: true
   VIBs Installed: VMware_bootbank_esx-base_5.0.0-0.3.474610, VMware_locker_tools-light_5.0.0-0.3.474610
   VIBs Removed: VMware_bootbank_esx-base_5.0.0-0.0.469512, VMware_locker_tools-light_5.0.0-0.0.469512
   VIBs Skipped: VMware_bootbank_ata-pata-amd_0.3.10-3vmw.500.0.0.469512, VMware_bootbank_ata-pata-atiixp_0.4.6-3vmw.500.0.0.469512, VMware_bootbank_ata-pata-cmd64x_0.2.5-3vmw.500.0.0.469512, VMware_bootbank_ata-pata-hpt3x2n_0.3.4-3vmw.500.0.0.469512, VMware_bootbank_ata-pata-pdc2027x_1.0-3vmw.500.0.0.469512, VMware_bootbank_ata-pata-serverworks_0.4.3-3vmw.500.0.0.469512, VMware_bootbank_ata-pata-sil680_0.4.8-3vmw.500.0.0.469512, VMware_bootbank_ata-pata-via_0.3.3-2vmw.500.0.0.469512, VMware_bootbank_block-cciss_3.6.14-10vmw.500.0.0.469512, VMware_bootbank_ehci-ehci-hcd_1.0-3vmw.500.0.0.469512, VMware_bootbank_esx-tboot_5.0.0-0.0.469512, VMware_bootbank_ima-qla4xxx_2.01.07-1vmw.500.0.0.469512, VMware_bootbank_ipmi-ipmi-devintf_39.1-4vmw.500.0.0.469512, VMware_bootbank_ipmi-ipmi-msghandler_39.1-4vmw.500.0.0.469512, VMware_bootbank_ipmi-ipmi-si-drv_39.1-4vmw.500.0.0.469512, VMware_bootbank_misc-cnic-register_1.1-1vmw.500.0.0.469512, VMware_bootbank_misc-drivers_5.0.0-0.0.469512, VMware_bootbank_net-be2net_4.0.88.0-1vmw.500.0.0.469512, VMware_bootbank_net-bnx2_2.0.15g.v50.11-5vmw.500.0.0.469512, VMware_bootbank_net-bnx2x_1.61.15.v50.1-1vmw.500.0.0.469512, VMware_bootbank_net-cnic_1.10.2j.v50.7-2vmw.500.0.0.469512, VMware_bootbank_net-e1000_8.0.3.1-2vmw.500.0.0.469512, VMware_bootbank_net-e1000e_1.1.2-3vmw.500.0.0.469512, VMware_bootbank_net-enic_1.4.2.15a-1vmw.500.0.0.469512, VMware_bootbank_net-forcedeth_0.61-2vmw.500.0.0.469512, VMware_bootbank_net-igb_2.1.11.1-3vmw.500.0.0.469512, VMware_bootbank_net-ixgbe_2.0.84.8.2-10vmw.500.0.0.469512, VMware_bootbank_net-nx-nic_4.0.557-3vmw.500.0.0.469512, VMware_bootbank_net-r8168_8.013.00-3vmw.500.0.0.469512, VMware_bootbank_net-r8169_6.011.00-2vmw.500.0.0.469512, VMware_bootbank_net-s2io_2.1.4.13427-3vmw.500.0.0.469512, VMware_bootbank_net-sky2_1.20-2vmw.500.0.0.469512, VMware_bootbank_net-tg3_3.110h.v50.4-4vmw.500.0.0.469512, VMware_bootbank_ohci-usb-ohci_1.0-3vmw.500.0.0.469512, VMware_bootbank_sata-ahci_3.0-6vmw.500.0.0.469512, VMware_bootbank_sata-ata-piix_2.12-4vmw.500.0.0.469512, VMware_bootbank_sata-sata-nv_3.5-3vmw.500.0.0.469512, VMware_bootbank_sata-sata-promise_2.12-3vmw.500.0.0.469512, VMware_bootbank_sata-sata-sil_2.3-3vmw.500.0.0.469512, VMware_bootbank_sata-sata-svw_2.3-3vmw.500.0.0.469512, VMware_bootbank_scsi-aacraid_1.1.5.1-9vmw.500.0.0.469512, VMware_bootbank_scsi-adp94xx_1.0.8.12-6vmw.500.0.0.469512, VMware_bootbank_scsi-aic79xx_3.1-5vmw.500.0.0.469512, VMware_bootbank_scsi-bnx2i_1.9.1d.v50.1-3vmw.500.0.0.469512, VMware_bootbank_scsi-fnic_1.5.0.3-1vmw.500.0.0.469512, VMware_bootbank_scsi-hpsa_5.0.0-17vmw.500.0.0.469512, VMware_bootbank_scsi-ips_7.12.05-4vmw.500.0.0.469512, VMware_bootbank_scsi-lpfc820_8.2.2.1-18vmw.500.0.0.469512, VMware_bootbank_scsi-megaraid-mbox_2.20.5.1-6vmw.500.0.0.469512, VMware_bootbank_scsi-megaraid-sas_4.32-1vmw.500.0.0.469512, VMware_bootbank_scsi-megaraid2_2.00.4-9vmw.500.0.0.469512, VMware_bootbank_scsi-mpt2sas_06.00.00.00-5vmw.500.0.0.469512, VMware_bootbank_scsi-mptsas_4.23.01.00-5vmw.500.0.0.469512, VMware_bootbank_scsi-mptspi_4.23.01.00-5vmw.500.0.0.469512, VMware_bootbank_scsi-qla2xxx_901.k1.1-14vmw.500.0.0.469512, VMware_bootbank_scsi-qla4xxx_5.01.03.2-3vmw.500.0.0.469512, VMware_bootbank_uhci-usb-uhci_1.0-3vmw.500.0.0.469512

Il est possible d’utiliser l’option ‘–dry-run’ pour simuler l’installation.

Fail2ban : utilisation du module recent d’iptables

Laisser un commentaire

J’utilise habituellement les bans dynamiques de shorewall en association avec fail2ban.
Cependant, il devient rapidement pénible de recevoir les mails d’avertissement associés à répétition lorsque l’attaquant ne se décourage pas.

C’est pourquoi je me suis inspiré de cet article afin d’utiliser le module recent d’iptables.

Le module recent

Ce module d’iptables permet de conserver un historique des derniers paquets d’une IP correspondants à certains critères. Il est ainsi possible de bloquer une IP avec une fenêtre glissante, qui se réinitialise à chaque tentative (elle-même bloquée).
Cela permet par exemple de bloquer une attaque brute force SSH tant que l’attaquant persiste.

On utilise généralement une association de deux règles pour profiter du module recent :

iptables -N to-ban
iptables -A to-ban -m recent --name recent-list --update --seconds 3600 -j DROP
iptables -A to-ban -m recent --name recent-list --set -j DROP

La première va rejeter (silencieusement) le paquet si l’IP source fait partie de la liste « recent-list » et qu’elle a émis un paquet il y a moins de 3600 secondes (1 heure donc). Si le paquet vérifie ces conditions, le module recent va en plus mettre à jour sa table avec le timestamp courant, réinitialisant alors le timer.

La seconde règle permet d’ajouter une IP dans la liste « recent-list » (afin qu’elle rentre en correspondance avec la première règle lors du prochain paquet).

Création de l’action fail2ban

Il est alors simple de créer un nouveau type d’action fail2ban, basé sur iptables-allports.conf :

# cat /etc/fail2ban/action.d/iptables-recent.conf
# Fail2Ban configuration file
#
# Author: Cyril Jaquier
# Modified: Yaroslav O. Halchenko 
#                       made active on all ports from original iptables.conf
#
# $Revision: 658 $
#

[Definition]

# Option:  actionstart
# Notes.:  command executed once at the start of Fail2Ban.
# Values:  CMD
#
actionstart = iptables -N fail2ban-
              iptables -A fail2ban- -m recent --name recent- --update --seconds 3600 -j DROP
              iptables -A fail2ban- -m recent --name recent- --remove -j RETURN
              iptables -A fail2ban- -j RETURN
              iptables -I INPUT -p  -j fail2ban-

# Option:  actionstop
# Notes.:  command executed once at the end of Fail2Ban
# Values:  CMD
#
actionstop = iptables -D INPUT -p  -j fail2ban-
             iptables -F fail2ban-
             iptables -X fail2ban-

# Option:  actioncheck
# Notes.:  command executed once before each actionban command
# Values:  CMD
#
actioncheck = iptables -n -L INPUT | grep -q fail2ban-

# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:      IP address
#            number of failures
#

L’action start crée une chaîne fail2ban-, dans laquelle sont routés tous les paquets entrants.
Cette chaîne ne fait par défaut que rejeter les paquets faisant partie de la liste recent-, c’est à dire aucun.

L’action ban ajoute une règle spécifique à l’IP à bannir, afin de l’ajouter à la liste du module recent. Elle entrera alors automatiquement dans la fenêtre de ban glissante.
L’action stop supprime cette dernière règle. L’IP pourra voir son trafic reprendre dès que le module recent l’aura « oubliée », c’est à dire dès qu’elle aura eu un délais d’inactivité de plus d’une heure.
Elle correspondra alors à la règle « remove », qui la supprimera de la liste recent-. Ceci n’est pas vraiment nécessaire, mais permet de faire un peu de ménage.

Nettoyage des listes du module recent

On peut voir le contenu des listes du module recent à partir des fichiers contenus dans /proc/net/xt_recent/ :

vilo _TV_ # cat /proc/net/xt_recent/recent-shorewall
src=82.234.245.47 ttl: 45 last_seen: 4304285107 oldest_pkt: 2 4304284706, 4304285107
src=89.72.204.102 ttl: 115 last_seen: 4300884873 oldest_pkt: 3 4300883971, 4300884269, 4300884873
src=87.244.66.115 ttl: 48 last_seen: 4303585869 oldest_pkt: 2 4303585477, 4303585869
src=77.205.31.17 ttl: 117 last_seen: 4311366646 oldest_pkt: 8 4311343362, 4311343998, 4311356076, 4311356271, 4311356904, 4311365737, 4311366043, 4311366646, 4311301283, 4311301646, 4311309439, 4311309741, 4311310339, 4311317676, 4311318269, 4311327004, 4311327387, 4311327945, 4311335224, 4311343121
src=87.244.104.236 ttl: 48 last_seen: 4296186058 oldest_pkt: 2 4296185657, 4296186058

La taille de ces listes étant limitées, je me suis intéressé à leur nettoyage. Leur taille est en effet limitée (100 IP par défaut), et le module ne retire pas automatiquement les IPs expirées.
Cependant, il est capable de faire automatiquement de la place en supprimant les entrées les plus anciennes lorsqu’il doit ajouter une nouvelle entrée dans une table déjà pleine.

Une alternative pourrait être l’option « reap », mais celle-ci ne semble pas encore officiellement supportée par l’utilitaire iptables (bien que certaines distributions appliquent le patch nécessaire).

Configurer Apache et PHP-FPM sous Gentoo

Laisser un commentaire

Après avoir utilisé suEXEC et PHP en fast-CGI; je suis passé a PHP-FPM, maintenant supporté par les dernières versions de PHP. Il s’agit d’un gestionnaire de processus PHP similaire au fast-CGI, mais offrant plus de possibilités de configurations que suEXEC/fastCGI.

Avantages

Lancement de processus PHP avec des utilisateurs différents. Cette fonction est similaire à celle de suEXEC, mais d’une configuration beaucoup plus aisée (évitant notamment les problèmes de droits sur les wrappers CGI).
Définition de plusieurs pools de processus, avec des paramètres différents.
Le processus maître étant une instance de PHP lui-même, les caches d’op-code peuvent être partagés par les différents processus fils.

Installation de PHP-FPM

Il faut tout d’abord ajouter le use flag ‘fpm’ à PHP avant de le recompiler. Il est aussi nécessaire de réinsaller les modules PHP éventuellement utilisés :

# Update /etc/portage/packages.use to add fpm use flag
emerge php
emerge pecl-geoip xcache pecl-memcache suhosin -av

Afin qu’Apache puisse communiquer avec PHP-FPM, il lui faut un module fast CGI. Si mod_fastcgi ou mod_fcgid peuvent faire l’affaire, ils disposent de plus de fonctionnalités que nécessaire et sont donc plus compliqués à configurer. J’ai donc choisi mod_fastcgi_handler :

emerge www-apache/mod_fastcgi_handler -av

Il faut alors modifier le fichier ‘/etc/conf.d/apache2’ pour lui activer ce nouveau module en l’ajoutant à la liste des options APACHE2_OPTS : ‘-D FASTCGI_HANDLER’.

Configuration PHP-FPM

La configuration de la gestion des pools de processus de PHP-FPM est centralisée dans le fichier ‘/etc/php/fpm-php-5.3/php-fpm.conf’. On peut définir plusieurs pools, exécutant PHP avec des utilisateurs différents :

[poirsouille]
listen=/var/run/php-fpm/poirsouille.socket
user=poirsouille
group=poirsouille
pm = dynamic
pm.max_children = 50
pm.min_spare_servers = 5
pm.max_spare_servers = 35

Le mode ‘dynamic’ permet à PHP-FPM d’ajuster automatiquement le nombre d’instances du pool à la demande.
On choisira un socket différent pour chaque pool.

Configuration Apache

Il reste à indiquer à Apache quel script fast CGI utiliser pour traiter les fichiers PHP. J’ai pu remplacer ma configuration suEXEC/mod_fcgid par celle-ci :


        Use VH tech

        # Ancienne configuration
        #SuexecUserGroup poirsouille poirsouille
        #FCGIWrapper /home/poirsouille/public_html/cgi-bin/php-fcgi .php
    
        # PHP-FPM
        AddHandler fcgi:/var/run/php-fpm/poirsouille.socket .php

On peut ainsi utiliser des pools différents selon les répertoires/virtualhosts/etc.

Démarrage

PHP-FPM est un ervice à part, qu’il faut donc ajouter au démarrage du serveur :

rc-update add php-fpm default

On peut ensuite (re)lancer PHP-FPM et Apache :

/etc/init.d/php-fpm restart
/etc/init.d/apache2 restart

Après quelques visites sur les différents sites, on constate l’apparition des processus dans les différents pools :

web ~ # ps aux |grep php-fpm
1002      9224  0.0  2.5 254380 52212 ?        S    00:16   0:02 php-fpm: pool poirsouille
1002      9275  0.0  2.1 246340 43540 ?        S    00:16   0:02 php-fpm: pool poirsouille
1002      9276  0.0  2.2 245420 45980 ?        S    00:16   0:01 php-fpm: pool poirsouille
1002      9331  0.1  2.2 244392 45816 ?        S    00:16   0:04 php-fpm: pool poirsouille
1002      9332  0.0  4.8 286808 100444 ?       S    00:16   0:02 php-fpm: pool poirsouille
root     19808  0.0  0.2 235232  5168 ?        Ss   May27   0:02 php-fpm: master process (/etc/php/fpm-php5.3/php-fpm.conf)
apache   19809  0.0  0.5 238400 11112 ?        S    May27   0:00 php-fpm: pool apache
apache   19810  0.0  0.7 240260 16372 ?        S    May27   0:00 php-fpm: pool apache
apache   19811  0.0  0.5 240184 12172 ?        S    May27   0:00 php-fpm: pool apache
apache   19812  0.0  1.2 248308 26444 ?        S    May27   0:00 php-fpm: pool apache
apache   19813  0.0  0.5 239864 12068 ?        S    May27   0:00 php-fpm: pool apache
apache   19814  0.0  0.7 241912 14476 ?        S    May27   0:00 php-fpm: pool apache
apache   19815  0.0  0.8 241416 16864 ?        S    May27   0:00 php-fpm: pool apache
tibou    19819  0.0  1.2 243724 26372 ?        S    May27   0:00 php-fpm: pool tibou
tibou    19820  0.0  2.7 268464 56912 ?        S    May27   0:01 php-fpm: pool tibou

Nettoyage

Une fois le fonctionnement validé, il est possible de désinstaller les packages devenus inutiles :

emerge --depclean mod_fcgid
#Remove suexec flag and recompile apache.

Références

http://mattmcadoo.com/node/42
http://blog.myprod.net/2010/08/14/apache2-suexec-fastcgi-php-5-3-3-fpm-cache-opcode-apc/

Installation de mise à jour ESXi 4.1

Laisser un commentaire

La version gratuite d’ESXi ne propose malheureusement pas de mise à jour automatique (ce qui est assez regrettable lorsque toutes les distributions linux le proposent…). Il est donc nécessaire de les récupérer et installer à la main.
L’offre dedibox sur laquelle je viens de passer propose ESXi 4.1 U1 en installation automatique. Cependant des mises à jours sont déjà disponibles.

Récupération des mises à jour

La liste des patchs disponibles peut être consultée (par produit) sur le site de VMWare : http://www.vmware.com/patch/download/

Une fois l’URL récupérée, il faut utiliser la console de maintenance pour l’installer. Vu la bande passante disponible sur le serveur, il est plus rapide de la télécharger directement depuis celui-ci plutôt que de l’uploader via le vSphere client.

cd /vmfs/volumes/datastore1/
wget http://hostupdate.vmware.com/software/VUM/OFFLINE/release-276-20110420-682352/ESXi410-201104001.zip

Une fois le téléchargement terminé, il est possible de contrôler le contenu du patch :

/vmfs/volumes/4dd56b07-e972f1d9-f727-bc305bd712f3 # esxupdate info --bundle=ESXi410-201104001.zip
   ID           - ESXi410-201104401-SG
   Release Date - 2011-04-28T08:00:00
   Vendor       - VMware, Inc.
   Summary      - Updates Firmware
   Severity     - security
   Urgency      - critical
   Category     - securityfix
   Install Date -
   Description  - For more information, see http://kb.vmware.com/kb/1035108.
   KB URL       - http://kb.vmware.com/kb/1035108
   Contact      - http://www.vmware.com/support/contacts/
   Compliant    - False
   RebootRequired          - True
   HostdRestart            - False
   RequiresMaintenanceMode - True
   List of constituent VIBs:
      deb_vmware-esx-firmware_4.1.0-1.6.381591

   ID           - ESXi410-201104402-BG
   Release Date - 2011-04-28T08:00:00
   Vendor       - VMware, Inc.
   Summary      - Updates VMware Tools
   Severity     - critical
   Urgency      - important
   Category     - bugfix
   Install Date -
   Description  - For more information, see http://kb.vmware.com/kb/1035109.
   KB URL       - http://kb.vmware.com/kb/1035109
   Contact      - http://www.vmware.com/support/contacts/
   Compliant    - False
   RebootRequired          - False
   HostdRestart            - False
   RequiresMaintenanceMode - False
   List of constituent VIBs:
      deb_vmware-esx-tools-light_4.1.0-1.6.381591

Répertoires manquants

J’ai rencontré des erreurs lors de l’exécution de certaines commandes. Il semblerait que certains répertoires ne soient pas créés correctement :

/vmfs/volumes/4dd56b07-e972f1d9-f727-bc305bd712f3 # esxupdate info -m ESXi410-201104001.zip
Encountered error FileIOError:
The error data is:
   Filename    - /var/tmp/cache/metadata1592750352
   Message     - Cannot create dir /var/tmp/cache/metadata1592750352: [Errno 17]
                 File exists: '/var/tmp'
   Errno       - 10
   Description - Unable to create, write or read a file as expected.

Certains liens symboliques sont invalides. Ceci se corrige simplement :

mkdir -p  /tmp/scratch/var/tmp/cache

Mise à jour

Pour installer le patch, il est nécessaire de passer l’hôte en mode maintenance :

/vmfs/volumes/4dd2fb9a-6501f76c-4f41-000c29e4a056 # esxupdate update --bundle=ESXi410-201104001.zip
Encountered error MaintenanceModeError:
The error data is:
   Message     - The following VIBs require this host to be in maintenance mode:
                 deb_vmware-esx-firmware_4.1.0-1.6.381591. Please put the host
                 in maintenance mode to proceed.
   Errno       - 18
   Description - Maintenance mode is not enabled or could not be determined.

Ceci nécessite l’arrêt ou la suspension des machines virtuelles. Lors de mon premier essai, je les ai suspendues. Cependant, j’ai eu des problèmes de connectivité réseau au réveil. Je recommanderais donc des les stopper.
Le passage en mode maintenance s’effectue aisément avec le client vSphere, en choisissant l’option « entrer en mode maintenance » dans le menu contextuel de l’hôte.

On peut alors lancer la mise à jour dans la console de maintenance :

/vmfs/volumes/4dd2fb9a-6501f76c-4f41-000c29e4a056 # esxupdate update --bundle=ESXi410-201104001.zip
Unpacking deb_vmware-esx-tools-light_4.1.0-1.6.381591 ######################################################################### [100%]

Unpacking deb_vmware-esx-firmware_4.1.0-1.6.381591    ######################################################################### [100%]

Removing packages :vmware-esx-tools-light             ######################################################################### [100%]

Installing packages :deb_vmware-esx-firmware_4.1.0-.. ######################################################################### [100%]

Installing packages :deb_vmware-esx-tools-light_4.1.. ######################################################################### [100%]

The update completed successfully, but the system needs to be rebooted for the
changes to be effective.

Il ne reste alors plus qu’à redémarrer l’hôte, désactiver le mode maintenance et relancer les machines virtuelles.

Abonnement à la mailing list

Afin d’être prévenu de la sortie de nouvelles mises à jour, il est possible de s’inscrire à la mailing list de VMWare :
https://www.vmware.com/mysupport/subscription.portal

Références

http://blog.stephane-grillot.fr/?p=5

Simplifier vos fichiers de configuration avec mod_macro

Laisser un commentaire

Si comme moi vous êtes allergiques au copier/coller, voici comment simplifier les fichiers de configuration Apache à l'aide d'un simple module : mod_macro.

Ce module permet la définition de macros, similaires à celles du pré-processeur C. Bien que basiques, elles permettent de factoriser une grande part de la configuration, tout particulièrement avec plusieurs virtualhosts.

Voici un exemple :

/etc/apache2/vhosts.d/01_poirsouille.org.conf
# Définition de la macro VH

        DocumentRoot "/home/poirsouille/public_html/$subdomain"
        ServerName $subdomain.poirsouille.org
        CustomLog /var/log/apache2/$subdomain_access_log combined
        ErrorLog /var/log/apache2/$subdomain_error_log

        
                Options Indexes FollowSymLinks
                Options +ExecCGI

                Order allow,deny
                Allow from all
        


# Autre macro pour la configuration SSL

        SSLEngine on
        SSLProtocol all -SSLv2

        SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
        SSLCertificateFile /etc/ssl/apache2/$subdomain.poirsouille.crt
        SSLCertificateKeyFile /etc/ssl/apache2/poirsouille.key
        SSLCertificateChainFile /etc/ssl/apache2/sub.class1.server.ca.pem
        SSLCACertificateFile /etc/ssl/apache2/ca.pem
        
                SSLOptions +StdEnvVars
        

        
                SSLOptions +StdEnvVars
        
        
                CustomLog /var/log/apache2/ssl_request_log \
                        "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
        





        Use VH photos



        Use VH tech

        SuexecUserGroup poirsouille poirsouille
        FCGIWrapper /home/poirsouille/public_html/cgi-bin/php-fcgi .php


        Use VH tech
        Use SSL tech
        SuexecUserGroup poirsouille poirsouille
        FCGIWrapper /home/poirsouille/public_html/cgi-bin/php-fcgi .php

 

Gentoo : monter un volume DM-crypt/LUKS au boot

2 réponses

DM-crypt et LUKS permettent de créer très simplement un volume totalement crypté. Si l'utilisation de cryptsetup sur Gentoo ne diffère pas de la procédure standard, le montage au boot n'utilise pas le fichier /etc/crypttab mais /etc/conf.d/dmcrypt.

Création du volume crypté

Voici les étapes à suivre pour créer un volume crypté /dev/mapper/data_secured à partir de la partition /dev/xvda2. Pour plus de détails, voir cet article.

# Formatage avec LUKS de la partition
cryptsetup --verbose --verify-passphrase luksFormat /dev/xvda2
# Ouverture de la partition LUKS
cryptsetup luksOpen /dev/xvda2 data_secured
# Création du système de fichiers Ext4
mkfs.ext4 /dev/mapper/data_secured

Le volume /dev/mapper/data_secured peut alors être monté et utilisé comme une partition normale (ne pas oublier le crypsetup luksOpen avant l'appel à mount cependant).

Monter le volume DM-crypt/LUKS au boot

Comme précisé dans le wiki Gentoo, on utilise le fichier /etc/conf.d/dmcrypt plutot que /etc/crypttab :

/etc/conf.d/dmcrypt
target=data_secured
source="/dev/xvda2"

Cela va indiquer aux scripts de boot Gentoo d'ouvrir le volume LUKS avant de monter les systèmes de fichiers (hors root, qui nécessite un initramfs spécifique pour être crypté). Si une passphrase est utilisée pour le volume, elle sera alors demandée au boot sur la console. A éviter donc sur un serveur distant sans accès à la console…

Il suffit ensuite d'ajouter une ligne dans /etc/fstab comme d'ordinaire :

/etc/fstab
/dev/mapper/data_secured        /var/torrent    ext4    errors=remount-ro,noatime,acl   0       2

A chaque reboot, la passphrase est demandée :

 * Setting up dm-crypt mappings ...
 * dm-crypt map data_secured ...
 * cryptsetup will be called with :   luksOpen /dev/xvda2 data_secured
Entrez la phrase de passe pour /dev/xvda2 :
                                                                          [ ok ]
                                                                          [ ok ]
 * Checking all filesystems .../dev/mapper/data_secured : propre, 473/3932160 fichiers, 10663788/15728383 blocs
                                           [ ok ]
 * Mounting local filesystems ...                                         [ ok ]
 * Mounting misc binary format filesystem ...                             [ ok ]

 

MyBB : Support HTTPS avec le plugin Google SEO

Laisser un commentaire

Je suis plutôt satisfait de MyBB pour la gestion du forum, mais il lui manque le support du HTTPS en parallèle avec le HTTP. En effet, il n'est possible de spévifier qu'une unique adresse de forum dans l'interface d'administration, et celle-ci inclut le protocole. Tous les liens internes du forum pointent alors vers celui spécifié…

J'ai trouvé ce plug-in pour MyBB 1.2, mais qui fonctionne parfaitement avec MyBB 1.6. Seul inconvénient, son incompatibilité avec le célèbre plugin Google SEO, et plus particulièrement le module redirect. En effet, le module redirect a part défaut une priorité supérieure à celle de dynbburl, et s'exécute donc avant que le protocol ne soit patché, forçant la redirection…

Il suffit de modifier légèrement dynbburl pour lui mettre une priorité plus forte :

inc/plugins/dynbburl.php
add_hook('global_start', 'dynbburl_run', 1);

function dynbburl_info()
{
        return array(
                'name'                  => 'Dynamic Board URL',
                'description'   => 'Changes the board URL dynamically based on requested page (only switches to HTTPS if applicable)',
                'website'               => 'http://mybbhacks.zingaburga.com/',
                'author'                => 'ZiNgA BuRgA',
                'authorsite'    => 'http://zingaburga.com/',
                'version'               => '1.0',
                'compatibility' => '1*',
                'guid'                  => ''
        );
}

function dynbburl_run()
{
        global $mybb;
        if(!empty($_SERVER['HTTPS']))
        {
                $mybb->settings['bburl'] = str_replace('http://', 'https://', $mybb->settings['bburl']);
        }
}
?>

OpenVPN : permettre la communication entre clients

Laisser un commentaire

Après avoi installé OpenVPN (je ne détaillerai pas l'installation, il suffit de suivre les très bon tutos ici et là), je me suis retrouvé avec deux soucis :

  • l'IP allouée au client est dynamique
  • impossible aux clients de communiquer entre eux

IP statique pour client OpenVPN

La solution est très simple. Dans la configuration du serveur, il suffit d'ajouter :

/etc/openvpn/openvon.conf
...
client-config-dir /etc/openvpn/ccd

Le dossier ccd va alors contenir les fichiers de configuration spécifiques par client. Chaque fichier doit porter le nom du Common Name du certificat du client correspondant.
Il suffit alors de rajouter dans le fichier client :

/etc/openvpn/ccd/client1
ifconfig-push 10.8.0.3 255.255.255.0

Permettre la communication entre clients

Par défaut les clients ne peuvent pas communiquer entre eux : client1 et client2 ont tous les deux accès au réseau VPN, mais il est impossible d'accéder à client1 depuis client2 (et inversement).
Pour autoriser cette communication, il suffit d'ajouter la ligne suivante dans la configuration du serveur OpenVPN :

/etc/openvpn/openvpn.conf
...
client-to-client

Sécuriser PHP avec Suhosin sur Gentoo

Laisser un commentaire

Je viens de découvrir Suhosin, un patch et une extension PHP permettant de combler d'éventuelles vulnérabilités (type buffer overflow, etc.).

Son installation sur Gentoo est enfantine :

 
echo "dev-lang/php suhosin" >> /etc/portage/package.use
emerge php
/etc/init.d/apache restart

Et voilà ! Ce n'est certainement pas une solution miracle, mais ça ne peut pas faire de mal.

Incompatibilité avec WordPress 3

Après l'activation de Suhosin, j'ai vu fleurir de jolies alertes dans mes logs :

 

Ceci est un problème connu de WP, qui demande 256Mo de mémoire pour certaines pages (dont l'admin)… Ceci est très bien détaillé ici, et un bug WP a été ouvert.

Unworkaround est de changer la taille mémoire max autorisée par Suhosin à 256 Mo.

Configurer PHP avec suEXEC sous Apache

Laisser un commentaire

Après l'installation de ce premier site WordPress, j'ai fait face à quelques soucis lors de l'installation automatique des thèmes et extensions : WP exige en effet que les fichiers appartiennent à l'utilisateur exécutant les scripts PHP. Ce qui n'était pas mon cas…

J'aurais simplement pu faire un "chown -R apache" , mais j'ai préféré en profiter pour me lancer dans la mise en place de suEXEC.

Installation

J'utilisais à l'origine l'association Apache + mod_php disponible par défaut sur ma Gentoo. Cependant, celle-ci ne permet pas d'exécuter les scripts PHP avec un utilisateur différent de celui du serveur web (ou alors peut-être avec le MPM "peruser", à vérifier).

Pour compiler Apache avec le support suEXEC, il suffit d'ajouter le use-flag suivant suexec. La configuration par défaut de suEXEC exige que tous les documents soientt dans /var/www. Dans mon cas, je préfère /home. Il est donc nécessaire d'ajouter la variable SUEXEC_DOCROOT dans /etc/make.conf :

 
echo 'www-servers/apache suexec' >> /etc/portage/package.use
echo 'SUEXEC_DOCROOT="/home"' >> /etc/make.conf
emerge apache

Afin de pouvoir utiliser les modes CGI ou FastCGI, il faut aussi désactiver le mod_php. Cela peut se faire en supprimant la directive "-D PHP5" du fichier /etc/conf.d/apache2. Mais pour faire des tests sans impacter tout le serveur (sur un VirtualHost ou un répertoire par exemple), il est aussi possible de le désactivé depuis les fichiers de configuration apache :

 
<VirtualHost *:80>
  ...
  php_admin_flag engine off
  ...
</VirtualHost>

Mode CGI

Première étape : le mode CGI basique.

 
<VirtualHost *:80>
  ServerName tech.poirsouille.org
  DocumentRoot "/home/poirsouille/public_html/tech"
  CustomLog /var/log/apache2/tech_access_log combined
  ErrorLog /var/log/apache2/tech_error_log

  SuexecUserGroup poirsouille poirsouille
  ScriptAlias /cgi-bin/ "/home/poirsouille/public_html/cgi-bin/"
  php_admin_flag engine off
  AddHandler php-script .php
  Action php-script /cgi-bin/php-cgi

  <Directory "/home/poirsouille/public_html/cgi-bin">
         AllowOverride None
         Options None
         Order allow,deny
         Allow from all
  </Directory>

  <Directory "/home/poirsouille/public_html/tech">
    Options Indexes FollowSymLinks
    AllowOverride All
    Order allow,deny
    Allow from all
  </Directory>
</VirtualHost>

La commande SuexecUserGroup active suEXEC pour les appels CGI. Le ScriptAlias définit un répertoire contenant des cgi exécutables. Celui-ci doit impérativement être contenu dans la DOC_ROOT de suEXEC. AddHandler et AddScript permettent d'associer les fichiers .php au binaire php-cgi.

suEXEC exige que le programme appelé appartienne à l'utilisateur, et qu'il ne soit modifiable que par lui. Les liens symboliques hors de DOC_ROOT ne sont pas supportés. Afin d'éviter de copier le binaire pour chaque utilisateur, le plus simple est d'utiliser un simple wrapper, en veillant à ce qu'il ait des droits corrects :

/home/poirsouille/public_html/cgi-bin/php-cgi
#!/bin/sh
/usr/bin/php-cgi $@

Après un redémarrage d'Apache, les scripts PHP devraient fonctionner correctement.

Cependant, côté serveur, un nouveau processus /usr/bin/php-cgi est créé pour chaque requête, ce qui cause une importante dégradation des performances face à mod_php.

Mode FastCGI

C'est alors qu'intervient FastCGI. Au lieu de créer un processus par requête, il ré-utilise toujours le(s) même(s). La maintenance de ces processus est assurée par Apache (un peu comme pour Apache lui-même avec le MPM prefork).

Voici donc comment utiliser PHP en mode FastCGI. Il existe deux modules Apache pour cela : mod_fstcgi et mod_fcgid. J'ai choisi le second :

 
emerge mod_fcgid

Voici ma configuration FastCGI :

/etc/apache2/modules.d/20_mod_fcgid.conf
<IfDefine FCGID>
  LoadModule fcgid_module modules/mod_fcgid.so
  SocketPath /var/run/fcgidsock
  SharememPath /var/run/fcgid_shm

  FcgidIdleTimeout 120
  FcgidProcessLifeTime 240
  FcgidMaxProcessesPerClass 100
  FcgidConnectTimeout 60
  FcgidIOTimeout 120

  # Ces deux lignes ne sont nécessaire que si mod_php est désactivé totalement
  AddHandler fcgid-script .php
  FCGIWrapper /usr/bin/php-cgi .php
</IfDefine>

Et on modifie le VirtualHost précédent :

 
<VirtualHost *:80>
  ServerName tech.poirsouille.org
  DocumentRoot "/home/poirsouille/public_html/tech"
  CustomLog /var/log/apache2/tech_access_log combined
  ErrorLog /var/log/apache2/tech_error_log

  SuexecUserGroup poirsouille poirsouille
  php_admin_flag engine off
  FCGIWrapper /home/poirsouille/public_html/cgi-bin/php-fcgi .php

  <Directory "/home/poirsouille/public_html/tech">
    Options Indexes FollowSymLinks
    AllowOverride All
    Order allow,deny
    Allow from all

    Options +ExecCGI

  </Directory>
</VirtualHost>

Les directives FCGIWrapper et +ExecCGI font leur apparition. Voici le simple wrapper PHP :

/home/poirsouille/public_html/cgi-bin/php-fcgi
#!/bin/sh

#export PHPRC="/etc/php.ini"
#export PHP_FCGI_CHILDREN=4
exec /usr/bin/php-cgi

On noter l'utilisation de la fonction exec de bash, qui permet de remplacer le processus de bash par celui appelé. Cela évite la création d'un processus fils, qui ne serait pas correctement tué par Apache. Une nouvelle fois, on s'assure que ce script a les droits corrects pour suEXEC :

 
web ~ # chown poirsouille:poirsouille /home/poirsouille/public_html/cgi-bin/php-fcgi
web ~ # chmod 755 /home/poirsouille/public_html/cgi-bin/php-fcgi
web ~ # ll /home/poirsouille/public_html/cgi-bin/php-fcgi
-rwxr-xr-x+ 1 poirsouille poirsouille 91 Oct 10 15:31 /home/poirsouille/public_html/cgi-bin/php-fcgi

Après redémarrage d'Apache on constate que les processus php-cgi survivent aux requêtes. Cela apporte de bien meilleures performances que le mode CGI, au détriment de l'utilisation mémoire (puisque l'interpréteur PHP reste en mémoire en attendant la prochaine requête).

Afin de minimiser la mémoire utilisée, j'ai désactivé mod_php globalement une fois mes tests terminés. Ainsi les processus Apache n'incluent plus mod_php et consomment moins de mémoire.

Performances

Les résultats suivants ont été obtenus en utilisant Apache bench avec les paramètres suivants :

ab -n100 -c10 http://tech.poirsouille.org/

La page d'accueil de ma nouvelle installation de WP m'a servi de référence.

mod_php

Concurrency Level:      10
Time taken for tests:   25.674 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      589000 bytes
HTML transferred:       565100 bytes
Requests per second:    3.89 [#/sec] (mean)
Time per request:       2567.396 [ms] (mean)
Time per request:       256.740 [ms] (mean, across all concurrent requests)
Transfer rate:          22.40 [Kbytes/sec] received

Ma configuration initiale comme référence.

CGI

Concurrency Level:      10
Time taken for tests:   72.616 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      586800 bytes
HTML transferred:       565100 bytes
Requests per second:    1.38 [#/sec] (mean)
Time per request:       7261.626 [ms] (mean)
Time per request:       726.163 [ms] (mean, across all concurrent requests)
Transfer rate:          7.89 [Kbytes/sec] received

En passant PHP en CGI on note une nette dégradation des performances, comme prévu.

CGI + suEXEC

Concurrency Level:      10
Time taken for tests:   72.299 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      586800 bytes
HTML transferred:       565100 bytes
Requests per second:    1.38 [#/sec] (mean)
Time per request:       7229.882 [ms] (mean)
Time per request:       722.988 [ms] (mean, across all concurrent requests)
Transfer rate:          7.93 [Kbytes/sec] received

L'activation de suEXEC en plus de CGI n'influe pratiquement pas sur les performances.

mod_fcgid + suEXEC

Concurrency Level:      10
Time taken for tests:   27.193 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      948188 bytes
HTML transferred:       926054 bytes
Requests per second:    3.68 [#/sec] (mean)
Time per request:       2719.334 [ms] (mean)
Time per request:       271.933 [ms] (mean, across all concurrent requests)
Transfer rate:          34.05 [Kbytes/sec] received

Le passage en mode FastCGI permet de retrouver des performances presque équivalentes à mod_php.

Remarques

L'authentification HTTP de PHP ne fonctionne qu'avec mod_php. Il existe toutefois des workarounds en utilisant mod_rewrite.

Il faudra que je jette un œil a PHP-FPM, qui devrait permettre de se passer de suEXEC.

Références