Executer des scripts php sous différentes identités.

28/05/201029/05/2010 CyrilLeave a comment

Il peut parfois être utile que des scripts php s’exécutent sous différents UID/GID.

Dans notre exemple,nous allons faire en sorte que les scripts s’exécutent sous l’uid/gid du propriétaire du script. Nous allons également permettre d’executer des scripts sous l’identité du root (ATTENTION : CECI EST UNIQUEMENT FAIT A DES FINS PÉDAGOGIQUES ET NE DOIT PAS ÊTRE MIS EN PRODUCTION POUR DES RAISONS ÉVIDENTES DE SÉCURITÉ).

La plateforme utilisée est une Centos 5.5.

Tout d’abord, il convient d’installer apache ainsi que la version « cgi » de php.

yum install httpd httpd-devel php-common php-cli

Attention à ce que le module apache php ne soit pas installé sinon le désinstaller :

rpm -e php

Nous installons ensuite quelques outils de compilation

yum install autoconf gcc-c++ gcc libtool-ltdl-devel

Il nous faut ensuite installer apr depuis les sources :

wget http://mir2.ovh.net/ftp.apache.org/dist/apr/apr-1.4.2.tar.gz
tar zxf apr-1.4.2.tar.gz
cd apr-1.4.2
./configure --prefix=/usr/ && make && make install

Nous allons ensuite compiler et installer le module Apache suPHP :

wget http://www.suphp.org/download/suphp-0.7.1.tar.gz
tar zxf suphp-0.7.1.tar.gz
./configure --prefix=/usr --disable-checkpath --disable-checkuid --disable-checkgid --with-min-uid=0 --with-min-gid=0 --with-apache-user=apache --with-apr=/usr/bin/apr-1-config --sysconfdir=/etc --with-setid-mode=owner
make
make install

Si nous avions voulu interdire l’exécution de scripts possédant des uid/gid <100, il aurait fallu modifier les parametres –with-min-uid et –with-min-gid en conséquence.

Editons ensuite un fichier /etc/suphp.conf :

Modifions ensuite le fichier /etc/httpd/conf/httpd.conf.

Dans les options générales du fichier de configuration, ajoutons :

LoadModule suphp_module modules/mod_suphp.so
suPHP_Engine on

puis sous la section <Directory /var/www/html> :

  AddType application/x-httpd-php .php
  suPHP_AddHandler application/x-httpd-php

Il faut ensuite relancer le service avec :

service httpd restart

Pour tester, créons un fichier /var/www/html/test.php

<?
 echo("<html><body>");
 system("/usr/bin/id");
 echo("</body></html>");
?>

Positionnons les droits sur ce fichier sur root:root :

chown root:root /var/www/html/test.php

Si nous lancons un navigateur sur http://xxx.xxx.xxx.xxx/test.php
nous obtenons :

Et si nous changeons les droits sur le fichier :

chown nobody:nobody /var/www/html/test.php

Nous obtenons :

Le script est donc bien exécuté en fonction du propriétaire du script et non pas sous l’identité « apache:apache ».

suPhP propose de nombreuses options permettant d’affiner les permissions accordées aux scripts. Pour cela, consultez la documentation officielle ici.

Installation de Dell OpenManage Server Administrator sur CentOS 5.3

07/09/200917/02/2010 YoannLeave a comment

Cet article décrit tous les étapes pour installer Dell OpenManage Server Administrator sur un serveur Dell doté d’un système CentOS 5.3.

– Placez-vous dans le répertoire suivant : cd /usr/local/src/
– Téléchargez la dernière version de Dell Open Manage : wget http://ftp.us.dell.com/sysman/OM_6.1.0_ManNode_A00.tar.gz
– Créez le répertoire suivant : mkdir OM_6.1.0_ManNode_A00
– Décompressez l’archive : tar -xzvf OM_6.1.0_ManNode_A00.tar.gz -C OM_6.1.0_ManNode_A00
– Placez-vous dans le répertoire suivant : cd OM_6.1.0_ManNode_A00
– Éditez le fichier de configuration suivant : vi setup.sh

GBL_OS_TYPE=${GBL_OS_TYPE_RHEL5}
GBL_OS_TYPE_STRING="RHEL5"

– Installez la dépendance suivante avec l’utilitaire YUM : yum install compat-libstdc++-33
– Créez le répertoire suivant : mkdir /usr/local/omsa/
– Lancez le script d’installation : sh linux/supportscripts/srvadmin-install.sh –prefix /usr/local/omsa/ -d -s -r -w

Installing the selected packages.

Préparation...              ########################################### [100%]
1:srvadmin-omilcore      ########################################### [  6%]
To start all installed services without a reboot,
enter the following command:  srvadmin-services.sh  start
2:srvadmin-omcommon      ########################################### [ 12%]
3:srvadmin-hapi          ########################################### [ 18%]
4:srvadmin-syscheck      ########################################### [ 24%]
5:srvadmin-deng          ########################################### [ 29%]
6:srvadmin-omacore       ########################################### [ 35%]
7:srvadmin-isvc          ########################################### [ 41%]
8:srvadmin-omauth        ########################################### [ 47%]
9:srvadmin-wsmanclient   ########################################### [ 53%]
10:srvadmin-idrac-componen########################################### [ 59%]
11:srvadmin-jre           ########################################### [ 65%]
12:srvadmin-cm            ########################################### [ 71%]
13:srvadmin-idracadm      ########################################### [ 76%]
14:srvadmin-idracdrsc     ########################################### [ 82%]
15:srvadmin-iws           ########################################### [ 88%]
16:srvadmin-omhip         ########################################### [ 94%]
17:srvadmin-storage       ########################################### [100%]

Le répertoire d’installation par défaut de Dell OpenManage se situe à l’emplacement /opt/dell/srvadmin/omsa/.

– Lancez les différents services de Dell OpenManage Server Administrator : srvadmin-services.sh start

Starting Systems Management Device Drivers:
Starting dell_rbu:                                         [  OK  ]
Starting ipmi driver: Already started                      [  OK  ]
Démarrage de snmpd :                                       [  OK  ]
Starting Systems Management Data Engine:
Starting dsm_sa_datamgr32d:                                [  OK  ]
Starting dsm_sa_eventmgr32d:                               [  OK  ]
Starting dsm_sa_snmp32d:                                   [  OK  ]
Starting DSM SA Shared Services:                           [  OK  ]
Starting DSM SA Connection Service:                        [  OK  ]

Dell OpenManage sera lancé automatiquement au démarrage du serveur.

– Éditez le fichier contenant les règles du pare-feu : vi /etc/sysconfig/iptables

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 1311 -j ACCEPT

– Redémarrez le pare-feu : service iptables restart
– A l’aide d’un navigateur Web, vous pouvez vous rendre sur l’interface Web de Dell OpenManage Server Administrator en entrant l’URL suivante : https://xxx.xxx.xxx.xxx:1311/.

dell_openmanage

Pour arrêter OMSA, il suffit de lancer la commande suivante : /usr/bin/srvadmin-services.sh stop.

Pour activer OMSA avec l’agent SNMPD : /etc/init.d/dataeng enablesnmp.

Pour procéder à la désinstallation d’OMSA, il suffit de lancer le script suivant : /usr/bin/srvadmin-uninstall.sh.

P2V : De Compaq Proliant ML370 vers Vmware Server

23/07/200917/02/2010 CyrilLeave a comment

L’abréviation P2V signifie Physical To Virtual, c’est à dire que c’est le procédé qui permet de virtualiser un serveur physique.

Dans notre étude, nous allons virtualiser un serveur Compaq Proliant ML370 G2 équipé d’une carte Raid SmartArray 5i fonctionnant sous CentOS 4.7.

Cependant, cette méthode est utilisable pour tout type de matériel, moyennant quelques légères adaptations.

Pré-requis :

Un serveur VMware en état de fonctionnement (VMware 1.0.9 sous Linux dans notre cas)
Un disque dur USB d’une capacité suffisante pour contenir des fichiers images de l’ensemble des partitions du serveur physique
Un CD bootable de SystemRescueCD
Du temps 🙂

1 . Backup du serveur physique

Tout d’abord nous allons créer des fichiers images des partitions du serveur physique sur le disque dur USB.

Le serveur étant en fonctionnement, relever la hiérarchie des points de montage à l’aide d’un cat /etc/mtab

Nous faisons booter le serveur sur le CD SystemRescueCD.
Au prompt du bootloader du CD, il est possible de booter le noyau par défaut (appui sur la touche entrée) ou de taper altkern32 pour avoir accès à un noyau alternatif au cas où celui par défaut ne détecterait pas certains périphériques.

Après le choix du keymap (fr=16), nous nous retrouvons sous le shell de SystemRescueCD.Il est alors temps de connecter le disque dur USB

Grâce à la commande sfdisk -l, il est alors facile de repérer le disque dur USB sur le système (dans mon cas, c’est la seule partition en W95 Fat32).

Ici, le disque USB est en /dev/sda1 et les partitions de mon serveur sont /dev/c0d0p1, /dev/c0d0p2 (swap), /dev/c0d0p3, /dev/c0d0p5, /dev/c0d0p6, /dev/c0d0p7, /dev/c0d0p8.

Nous en profitions également pour relever la taille des partitions (#blocks)

Nous allons donc monter le disque usb :

– mkdir /mnt/usbdisk
– mount /dev/sda1 /mnt/usbdisk

Nous lançons ensuite l’utilitaire partimage.

Nous choisissons la partition à sauvegarder (/dev/c0d0p1), le nom du fichier image (/mnt/usbdisk/c0d0p1) et nous validons en appuyant sur F5. Le nom des fichiers est volontairement le même que le nom de la partition afin de faciliter la restauration par la suite.

Dans l’écran suivant, nous laissons toutes les options par défaut et nous poursuivons en appuyant sur F5.

Après validation, le backup commence.

Il faut ensuite recommencer l’opération pour chaque partition présente sur le serveur (exceptée la swap).

2. Restauration sur la machine virtuelle

Nous sommes connecté à la console VMware Server, le disque dur USB étant connecté

Tout d’abord il faut créer la machine virtuelle en prêtant attention à ce que la taille du disque soit au moins très légèrement supérieure à la somme de la taille des partitions sauvegardées.

Ensuite dans les settings de la VM, il faut ajouter un controleur USB en cliquant sur le bouton ADD

Il faut aussi mapper le lecteur CD sur l’image ISO de SystemRescue CD

Nous pouvons alors connecter le disque USB via le menu VM->Removables Devices->USB Devices une fois que la VM est démarrée.

Nous bootons sur le CD de la machine virtuelle. Nous arrivons alors au prompt de SystemRescueCD.

De nouveau, un sfdisk -l permet de repérer les périphériques de stockage.

Ici /dev/sdb1 est le disque USB externe et /dev/sda est le disque dur virtuel.

Grâce à l’utilitaire Fdisk, nous allons recréer des partitions /dev/sda1, /dev/sda2, /dev/sda3, /dev/sda5, /dev/sda6, /dev/sda7, /dev/sda8 de taille légèrement supérieure à celles que l’on a relevées pour /dev/c0d0p1, /dev/c0d0p2 (swap), /dev/c0d0p3, /dev/c0d0p5, /dev/c0d0p6, /dev/c0d0p7, /dev/c0d0p8.

Par exemple si /dev/c0d0p1 faisait 9Go, alors /dev/sda1 fera 9.1Go afin d’éviter d’avoir un message « partition too small » lors de la restauration du fait de la différence de géométrie des disques si l’on utilisait le même nombre exact de blocs.

Ne pas oublier le type de la partition de swap en 82 (Linux Swap).

Formater la partition de swap à l’aide de mkswap /dev/sda2

Nous allons donc monter le disque usb :

– mkdir /mnt/usbdisk
– mount /dev/sda1 /mnt/usbdisk

Nous lançons ensuite l’utilitaire partimage.

Choisir la partition à restaurer (/dev/sda1), l’image à utiliser (/mnt/usbdisk/c0d0p1.000). Positionner l’Action à effectuer sur Restore partition from an image file et valider avec F5. Recommencer l’opération pour chaque partition à restaurer.

3. Opérations post-restauration

Une fois les partitions restaurées, toujours sur le CD SystemRescue CD, il convient de les monter afin de pouvoir chrooter dans l’environnement restauré.

Voici le schéma de points de montage utilisé dans le serveur original :

/dev/c0d0p1 -> /boot
/dev/c0d0p3 -> /
/dev/c0d0p5 -> /var
/dev/c0d0p6 -> /usr
/dev/c0d0p7 -> /tmp
/dev/c0d0p8 -> /data

Nous allons donc les monter comme suit :

– mkdir /mnt/guest
– mount /dev/sda3 /mnt/guest
– mount /dev/sda1 /mnt/guest/boot
– mount /dev/sda5 /mnt/guest/var
– mount /dev/sda6 /mnt/guest/usr
– mount /dev/sda7 /mnt/guest/tmp
– mount –bind /dev /mnt/guest/dev

Cette dernière ligne nous permet d’avoir accès aux périphériques lorsque nous serons chrooté dans l’environnement et que nous devrons réinstaller le bootloader.

Nous chrootons dans l’environnement crée :

chroot /mnt/guest /bin/bash

Il suffit ensuite d’éditer le fichier /etc/fstab et de modifier les anciennes références des partitions vers les nouvelles partitions (ex: /dev/c0d0p1 (ou LABEL=/boot) devient /dev/sda1).

L’initrd présent est généré d’après le fichier /etc/modprobe.conf pour fonctionner avec le matériel du proliant ML380G2. Il faut donc le régénérer pour le matériel de la machine virtuelle.

Le fichier /etc/modprobe.conf contient :

alias eth0 tg3
alias scsi_hostadapter cciss

Il faut le modifier ainsi :

alias eth0 pcnet32
alias scsi_hostadapter mptbase
alias scsi_hostadapter1 mptspi
alias scsi_hostadapter2 mptscsih

Un petit less /boot/grub/menu.lst permet de connaitre le noyau (mais surtout l’initrd) utilisé par défaut.

Dans notre cas, il s’agit de initrd-2.6.9-78.0.22.EL.img. Nous allons donc le sauvegarder et en générer un nouveau :

– mv /boot/initrd-2.6.9-78.0.22.EL.img /boot/initrd-2.6.9-78.0.22.EL.img.old
– mkinitrd /boot/initrd-2.6.9-78.0.22.EL.img 2.6.9-78.0.22.EL

Il nous reste donc à réinstaller le bootloader grub.

Tout d’abord, il faut modifier dans le fichier /boot/grub/menu.lst les références aux anciennes partitions (ex: root=LABEL=/ devient root=/dev/sda3).

Ensuite, exécutons sous l’utilitaire en ligne de commande grub :

– root (hd0,0)setup (hd0)

Ceci a pour effet de réinstaller le bootloader.

Il suffit ensuite de sortir du chroot, de rebooter la VM en n’oubliant pas démapper l’ISO du lecteur CD et de déconnecter le disque externe et de booter sur le disque virtuel normalement.

Au premier boot, il se peut que kudzu détecte de nouveau périphériques et notamment la carte réseau. Il suffit alors
de lui remettre les paramètres IP du serveur physique.