Installer HP Web JetAdmin 8.1 sur Ubuntu 10.04

Tout d’abord, téléchargez le programme HP Web JetAdmin 8.1 version Fedora depuis le site HP .

Positionner les droits d’execution :

chmod +x wja81-3872-fe.selfx

Créer un fichier /etc/redhat-release :

sudo echo "Red Hat Linux release 7.3 (Valhalla)" > /etc/redhat-release

Préparer l’environnement d’exécution :

sudo apt-get install libdb1-compat
sudo ln -s /usr/lib/libgdbm_compat.so.3 /usr/lib/libgdbm.so.2
sudo ln -s /usr/lib/libdb-4.7.so /usr/lib/libdb-4.0.so
sudo ln -s /lib/ln -s  libexpat.so.1  /lib/libexpat.so.0

Télécharger le paquet libstdc++5_3.3.6-17ubuntu1_i386.deb depuis le repository de Jaunty et l’installer.

Lancer l’installation :

sudo ./wja81-3872-fe.selfx

L’installation plantera vers la fin. Ceci n’est pas bloquant.

Modifier le script de lancement :

cd /opt/hpwebjet/
sudo vi ./hpwebjetd.sh

Remplacer sur la première ligne :

#!/bin/sh ->    #!/bin/bash

Et a la ligne 107 :

pidlist=`/sbin/pidof -o %PPID hpwebjetd`   ->    pidlist=`/bin/pidof -o %PPID hpwebjetd`

Lancer Hp Web jetadmin par la commande :

sudo ./hpwebjetd.sh -start

Lister les fichiers ouverts lors de l’exécution d’une commande

Il est parfois utile de connaitre quels sont les fichiers utilisés par un exécutable. Par exemple, pour connaitre quels sont les fichiers utilisés lorsque nous tapons la commande ‘ls -l’, il suffit de faire :

strace -o ./sortie.txt  /bin/ls -l

Puis ensuite, à l’aide d’un grep sur le fichier de sortie :

grep open sortie.txt

Ce qui donne :

Nous y voyons les bibliothèques utilisées par la commande ls mais aussi l’accès à l’ensemble des fichiers utilisés.

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

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.