Les iso sont là: http://mirror.centos.org/altarch/7/isos/i386/
Ceci est le résultat d'un SIG (Special Interest Group) dont la home page est ici:
https://wiki.centos.org/SpecialInterestGroup/AltArch/i386
Affichage des articles dont le libellé est centos7. Afficher tous les articles
Affichage des articles dont le libellé est centos7. Afficher tous les articles
12 janvier 2016
CentOS 7 32 bits
Les iso sont là: http://mirror.centos.org/altarch/7/isos/i386/
Ceci est le résultat d'un SIG (Special Interest Group) dont la home page est ici:
https://wiki.centos.org/SpecialInterestGroup/AltArch/i386
12 mars 2015
mod_perl 2.0.9
[ UPDATE: La version officielle de mod_perl 2.0.9 est disponible depuis le 18/juin/2015 ]
[ Mais en attendant les packages officiels la procédure ci-dessous reste valide ]
Steve Hay, le principal développer de mod_perl2, affirme que l'on est en phase de test ...
En attendant un package voici pour les impatients comment tester sous Linux (dans mon cas Centos 7) cette version bêta de mod_perl 2.0.9 (il y a encore quelques problèmes sous Windows, et Perl 5.22 n'est pas supporté).
# Il faut avoir de quoi compiler et bien-sur apache et ses fichiers de développement
yum group install "Development Tools"
yum install httpd httpd-devel
# Depuis le 19/juin/2015 on peut récupérer les sources ici
http://apache.org/dist/perl/
# Sinon on peut récupérer les source via SVN
svn checkout https://svn.apache.org/repos/asf/perl/modperl/trunk/ mod_perl-2.0.9
# Il ne faut pas etre root sinon le 'make test' echoue
# On prepare un Makefile, on compile, on teste
# Vérifier que /usr/bin/apxs existe (il vient du package httpd-devel)
# MP_TRACE=1 permet ensuite d'utiliser dans httpd.conf la directive PerlTrace
cd mod_perl-2.0.9
perl Makefile.PL MP_APXS=/usr/bin/apxs MP_TRACE=1
make
make test
# Si tout se passe bien on doit avoir une fin qui ressemble à
All tests successful.
Result: PASS
# Pour cette dernière commande il faut être root
su
make install
La commande suivante indique où sont les modules (mod_xxxxx.so) que Apache charge
/usr/bin/apxs -q LIBEXECDIR
C’est là que doit se trouver le nouveau module mod_perl.so qui est chargé dans la config du serveur web avec
LoadModule perl_module modules/mod_perl.so
Voir ce précédent ce post pour la configuration,
24 octobre 2014
Repository EPEL & REMI
Par exemple, avec Centos / EL, le repository "EPEL" (Extra Packages for Enterprise Linux) ou les repositories de Remi Collet ne sont pas connus. Pour les installer il y a deux méthodes : la facile et la moins facile !
Version facile (que pour EPEL)
On va essayer de voir si dans les repositories déjà configurés il y en a un qui contient la définition du repository EPEL.
On tape la commande : yum search epel
On regarde dans ce qui s'affiche si le package existe et si oui, son nom exact.
Si le package existe on l'installe en général avec : yum install epel-release
Si rien n’est trouvé passer à la version moins facile.
Version moins facile
Si la définition de EPEL n'est pas dans un package disponible il faut la télécharger puis l'installer à la main.
On va sur http://dl.fedoraproject.org/pub/epel
On choisit la version centos/el : 4, 5, 6, 7
On choisit l'architecture : i386, x86_64, ppc64
Si une liste de répertoires (a, b, c…) se présente on va dans le répertoire "e"
On cherche un package avec un nom du type epel-release-X-Y.noarch.rpm (le X et le Y étant variables)
On le télécharge sur la machine à configurer avec une commande du type (ici pour centos 7, 64 bits)
wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-2.noarch.rpmEnfin on l'installe avec la commande : yum install epel-release-X-Y.rpm
Pour les repositories de Remy Collet il n'y a que la version moins facile qui marche, sachant qu'avec centos il faut déjà avoir installer EPEL. Le processus reste le même :
- trouver le rpm d'auto configuration (détails pour centos, fedora ici: http://rpms.famillecollet.com/)
- le télécharger (wget http://rpms.famillecollet.com/enterprise/remi-release-7.rpm)
- l'installer (yum install remi-release-7.rpm)
ATTENTION: Quand on a beaucoup de repositories configurés il peut y avoir des conflits. Quand on fait un yum update ou un yum install il faut bien vérifier le repository source.
Par défaut les repositories de Remi sont désactivés. Deux méthodes pour les activer :
- Editer le fichier /etc/yum.repos.d/remi.repo et y mettre le/les "enable=0" à "enable=1".
- Activer le bon repository au cas par cas. Par exemple :
yum --enablerepo=remi install nom-du-package
yum --enablerepo=remi update nom-du-package
Pour voir les repositories actifs : yum repolist
Pour voir les repositories desactivés : yum repolist disabled
18 septembre 2014
pg_hba.conf (part2)
(Dans la première partie on a vu comment configurer l'accès local à un serveur Postgresql)
Sachant que pour se connecter à distance (via le réseaux) à un serveur Postgresql il faut utiliser la commande
psql -h host database username
On va essayer d’accéder à notre nouvelle installation de Postgresql se situant sur le serveur avec l'ip 192.168.0.3
> psql -h 192.168.0.3 postgres postgres
psql: n'a pas pu se connecter au serveur : Connection refused
Le serveur est-il actif sur l'hôte « 192.168.0.3 »
et accepte-t-il les connexions TCP/IP sur le port 5432 ?
Effectivement la première chose à faire est d’autoriser les connections venant du réseau.
Pour cela il faut éditer le fichier /var/lib/pgsql/data/postgresql.conf et y ajouter la ligne
listen_addresses = '*'
puis redémarrer le serveur Postgresql
systemctl restart postgresql
On ré-essaye :
psql -h 192.168.0.3 postgres postgres
psql: FATAL: no pg_hba.conf entry for host "192.168.0.59",
user "postgres", database "postgres", SSL off
Maintenant il faut autoriser les connections sur la base du triplet : (data-base, ip-client)
Pour faire simple on va ajouter cette ligne à pg_hba.conf
host all all all md5
Ce qui signifie que s'il connait le password n'importe quel utilisateur de Postgresql peut se connecter à n'importe quelle base de données depuis n'importe où sur internet. C'est un peut trop ouvert !
En utilisant cette ligne
host all all samenet md5
les clients devront être sur des machines du même réseau local que le serveur Postgresql.
En utilisant cette ligne
host sameuser all samenet md5
Un user ne pourra se connecter qu'a la base de données qui porte son nom et seulement depuis une machine du réseau local. (config typique d'un environnement de développement dédié. Ne pas utilisé si le réseau local est trop ouvert, ni dans un environnement cloud)
En utilisant ces deux lignes en même temps
host webapp webapp w.x.y.z/32 md5
host sameuser all a.b.c.0/24 md5
Le serveur web situé à l'adresse w.x.y.z pourra se connecter à la base webapp avec le user webapp
et les développeurs du sous réseau a.b.c.0/24 pourront utiliser la base qui à le même nom que d'utilisateur.
Par exemple : postgres/postgres, webapp/webapp, webbackup/webbackup jean/jean
Si vous avez pigez cela vous pigerez la petite doc qui se trouve au début du fichier pg_hba.conf
RAPPEL: Pour que les changements dans le fichier pg_hba.conf prennent effet il faut redémarrer le serveur Postgresl.
Info sur le codage md5 des mots de passe dans la table pg_shadow de Postgresql;
http://code18.blogspot.fr/2010/01/cracker-un-md5-de-postgresql.html
Sachant que pour se connecter à distance (via le réseaux) à un serveur Postgresql il faut utiliser la commande
psql -h host database username
On va essayer d’accéder à notre nouvelle installation de Postgresql se situant sur le serveur avec l'ip 192.168.0.3
> psql -h 192.168.0.3 postgres postgres
psql: n'a pas pu se connecter au serveur : Connection refused
Le serveur est-il actif sur l'hôte « 192.168.0.3 »
et accepte-t-il les connexions TCP/IP sur le port 5432 ?
Effectivement la première chose à faire est d’autoriser les connections venant du réseau.
Pour cela il faut éditer le fichier /var/lib/pgsql/data/postgresql.conf et y ajouter la ligne
listen_addresses = '*'
puis redémarrer le serveur Postgresql
systemctl restart postgresql
On ré-essaye :
psql -h 192.168.0.3 postgres postgres
psql: FATAL: no pg_hba.conf entry for host "192.168.0.59",
user "postgres", database "postgres", SSL off
Maintenant il faut autoriser les connections sur la base du triplet : (data-base
Pour faire simple on va ajouter cette ligne à pg_hba.conf
host all all all md5
Ce qui signifie que s'il connait le password n'importe quel utilisateur de Postgresql peut se connecter à n'importe quelle base de données depuis n'importe où sur internet. C'est un peut trop ouvert !
En utilisant cette ligne
host all all samenet md5
les clients devront être sur des machines du même réseau local que le serveur Postgresql.
En utilisant cette ligne
host sameuser all samenet md5
Un user ne pourra se connecter qu'a la base de données qui porte son nom et seulement depuis une machine du réseau local. (config typique d'un environnement de développement dédié. Ne pas utilisé si le réseau local est trop ouvert, ni dans un environnement cloud)
En utilisant ces deux lignes en même temps
host webapp webapp w.x.y.z/32 md5
host sameuser all a.b.c.0/24 md5
Le serveur web situé à l'adresse w.x.y.z pourra se connecter à la base webapp avec le user webapp
et les développeurs du sous réseau a.b.c.0/24 pourront utiliser la base qui à le même nom que d'utilisateur.
Par exemple : postgres/postgres, webapp/webapp, webbackup/webbackup jean/jean
Si vous avez pigez cela vous pigerez la petite doc qui se trouve au début du fichier pg_hba.conf
RAPPEL: Pour que les changements dans le fichier pg_hba.conf prennent effet il faut redémarrer le serveur Postgresl.
Info sur le codage md5 des mots de passe dans la table pg_shadow de Postgresql;
http://code18.blogspot.fr/2010/01/cracker-un-md5-de-postgresql.html
17 septembre 2014
pg_hba.conf (part1)
Dans cette première partie on va voir comment sécuriser Postgresql juste après son installation.
1) Vous venez donc d'installer Posgresql 9.x et voulez vous connectez en tapant psql.
> psql
psql: FATAL: role "bidule" does not exist
En fait, en absence d'information, psql utilise le nom de l'utilisateur coté Unix et essaye de s'en servir pour se connecter à la base de données du même nom.
En fait, pour l'utilisateur 'bidule'
> psql
est équivalant de
> psql bidule bidule
Le premier 'bidule' est le nom de la base de données et le second le nom de l'utilisateur coté postgresql.
2) Dans toute installation par défaut de Postgresql il y a une base de données nommée postgres et un utilisateur nommé postgres. Donc ceci doit marcher :
> psql postgres postgres
psql (9.2.7)
Type "help" for help.
postgres=# _
Effectivement, on a bien le prompt du serveur Posgresql.
3) QUOI ?! Pas besoin de mot de passe !!!
Incroyable : Sur la machine où s’exécute le serveur Postgresql aucun utilisateur local n'a besoin de mot de passe pour y accéder. Ceci est dû à cette ligne dans le fichier pg_hba.conf
local all all trust
Elle signifie qu'en 'local', toutes les bases de données (premier 'all') sont accessibles par tous les utilisateurs (deuxième 'all') à qui l'OS a déjà fait confiance ('trust') en acceptant qu'ils se connectent sur la machine.
Bien sur ceci est un véritable problème sur une machine multi-utilisateurs.
Notez que cette méthode très libérale pose exactement les mêmes problèmes que le mot de passe par défaut connu de tout le monde ou que l'utilisateur par défaut sans mot de passe.
4) Les trois premières choses à faire sont, dans cet ordre :
- attribuer un password au user 'postgres' (coté Postgresql, pas coté Unix)
- changer la ligne de pg_hba en: "local all all md5"
- mettre en commentaire toute les autres lignes utilisant la méthode 'trust'
En remplaçant la méthode 'trust' par la méthode 'md5' on force tout utilisateur local à donner le mot de passe de l'utilisateur coté base de données. Encore faut-il qu'il en ait un...
4.1) Donc on se connecte à Posgresql avec:
> psql postgres postgres
puis on tape ces deux commandes pour attribuer un mot de passe à l'utilisateur postgres :
ALTER USER postgres WITH PASSWORD 'Secr3tPassW0rd';
\q
4.2) Dans le fichier pg_hba on remplace sur la ligne local la methode 'trust' par 'md5'
et on met en commentaire les deux lignes host utilisant aussi trust
# host all all 127.0.0.1/32 trust
# host all all ::1/128 trust
On sauve, puis on redémarre le serveur Postgresql :
systemctl restart postgresql
4.3) Maintenant si on utilise la commande psql on doit taper le mot de passe
> psql postgres postgres
Password for user postgres: xxxxxxxxxxxx
psql (9.2.7)
Type "help" for help.
postgres=# _
Ouf !
Notez qu'en remettant la méthode d'authentification pour 'local' à 'trust' pour pourrez vous connecter à nouveau (en local) sans mot de passe, ce qui est bien pratique si vous l'avez oublié.
Ce qui signifie que le 'root' Unix a tous pouvoirs sur le serveur Postgresql puisque il peut outre passer l’authentification en modifiant le fichier pg_hba.conf
Passons à l’accès via le réseaux ...
1) Vous venez donc d'installer Posgresql 9.x et voulez vous connectez en tapant psql.
> psql
psql: FATAL: role "bidule" does not exist
En fait, en absence d'information, psql utilise le nom de l'utilisateur coté Unix et essaye de s'en servir pour se connecter à la base de données du même nom.
En fait, pour l'utilisateur 'bidule'
> psql
est équivalant de
> psql bidule bidule
Le premier 'bidule' est le nom de la base de données et le second le nom de l'utilisateur coté postgresql.
2) Dans toute installation par défaut de Postgresql il y a une base de données nommée postgres et un utilisateur nommé postgres. Donc ceci doit marcher :
> psql postgres postgres
psql (9.2.7)
Type "help" for help.
postgres=# _
Effectivement, on a bien le prompt du serveur Posgresql.
3) QUOI ?! Pas besoin de mot de passe !!!
Incroyable : Sur la machine où s’exécute le serveur Postgresql aucun utilisateur local n'a besoin de mot de passe pour y accéder. Ceci est dû à cette ligne dans le fichier pg_hba.conf
local all all trust
Elle signifie qu'en 'local', toutes les bases de données (premier 'all') sont accessibles par tous les utilisateurs (deuxième 'all') à qui l'OS a déjà fait confiance ('trust') en acceptant qu'ils se connectent sur la machine.
Bien sur ceci est un véritable problème sur une machine multi-utilisateurs.
Notez que cette méthode très libérale pose exactement les mêmes problèmes que le mot de passe par défaut connu de tout le monde ou que l'utilisateur par défaut sans mot de passe.
4) Les trois premières choses à faire sont, dans cet ordre :
- attribuer un password au user 'postgres' (coté Postgresql, pas coté Unix)
- changer la ligne de pg_hba en: "local all all md5"
- mettre en commentaire toute les autres lignes utilisant la méthode 'trust'
En remplaçant la méthode 'trust' par la méthode 'md5' on force tout utilisateur local à donner le mot de passe de l'utilisateur coté base de données. Encore faut-il qu'il en ait un...
4.1) Donc on se connecte à Posgresql avec:
> psql postgres postgres
puis on tape ces deux commandes pour attribuer un mot de passe à l'utilisateur postgres :
ALTER USER postgres WITH PASSWORD 'Secr3tPassW0rd';
\q
4.2) Dans le fichier pg_hba on remplace sur la ligne local la methode 'trust' par 'md5'
et on met en commentaire les deux lignes host utilisant aussi trust
# host all all 127.0.0.1/32 trust
# host all all ::1/128 trust
On sauve, puis on redémarre le serveur Postgresql :
systemctl restart postgresql
4.3) Maintenant si on utilise la commande psql on doit taper le mot de passe
> psql postgres postgres
Password for user postgres: xxxxxxxxxxxx
psql (9.2.7)
Type "help" for help.
postgres=# _
Ouf !
Notez qu'en remettant la méthode d'authentification pour 'local' à 'trust' pour pourrez vous connecter à nouveau (en local) sans mot de passe, ce qui est bien pratique si vous l'avez oublié.
Ce qui signifie que le 'root' Unix a tous pouvoirs sur le serveur Postgresql puisque il peut outre passer l’authentification en modifiant le fichier pg_hba.conf
Passons à l’accès via le réseaux ...
15 septembre 2014
Postgresql 9 + Centos 7
1: Installer postgresql
yum install
postgresql postgresql-server
2: Créer le home directory de postgresql
mkdir /home/postgres
chown postgres:postgres /home/postgres
chown postgres:postgres /home/postgres
3: Initialiser le repertoire où postgresql va stocker ses bases de données et autres meta-data
su postgres
cd
initdb /home/postgres/data
exit
cd
initdb /home/postgres/data
exit
4: Configuration systemd
Ce qui suit a pour but de ne pas modifier la version d'origine de /usr/lib/systemd/system/postgresql.service
La solution proposé par postgresql est d'utiliser .include mais il faut savoir que cette méthode est obsolète (https://lists.fedoraproject.org/pipermail/devel/2014-July/200804.html)
Créer le fichier /etc/systemd/system/postgresql.service
avec ces 3 lignes (respectez la case)
.include
/usr/lib/systemd/system/postgresql.service
[Service]
Environment=PGDATA=/home/postgres/data
[Service]
Environment=PGDATA=/home/postgres/data
Si nécessaire ajouter la ligne suivante pour aussi changer
le port
Environment=PGPORT=2345
5: Démarrer le serveur postgresql à la main
systemctl daemon-reload (important)
systemctl start postgresql
verifier les log
systemctl status postgresql
6: Si tout va bien activer le démarrage automatique
systemctl enable postgresql
Reste à configurer /home/postgres/pg_hba.conf
Voir ces 3 posts:
- pg_hba (part1) accès local avec/sans mot de passe
- pg_hba (part2) accès via le réseau
- pg_hba + SSL cryptage
7: Installer les extensions
yum install postgresql-contrib
Toutes les extensions vont dans /usr/share/pgsql/extension
Pour installer une extension (par exemple adminpack) dans une base il faut se se connecter à cette base avec le user postgres et taper
CREATE EXTENSION adminpack;8: Installer les .h
Necessaire si on veut compiler un driver pour perl php ruby etc...
Par exemple quand un programme d’installation a besoin de libpq-fe.h
12 septembre 2014
APACHE 2.2 et Centos 7
Il y a de nombreuses raisons pour vouloir encore utiliser Apache 2.2 et de ne pas migrer vers Apache 2.4. L'une d'entre elles est l'utilisation de mod_perl2 qui ne fonctionne toujours pas correctement avec Apache 2.4.
Malheureusement l’installation d’Apache 2.2 sur centos 7 ne peut pas se faire avec yum car seule la version 2.4 est disponible. Voici comment procéder pour compiler Apache 2.2 et mod_perl2 sur centos 7 et mettre en place les fichiers nécessaires au démarrage de httpd 2.2 avec systemctl (aka systemd).
1) Il faut avoir les outils de développements
yum group install "Development Tools"
2) Puis on va sur http://www.us.apache.org/dist/httpd/ et on repère la version la plus récente de httpd-2.2
puis on la télécharge et on la décompresse :
wget http://www.us.apache.org/dist/httpd/httpd-2.2.29.tar.gz
tar xvf httpd-2.2.29.tar.gz
On compile et installe apache 2.2.x
On utilise --prefix pour ne pas installer apache par dessus l’éventuelle version 'officielle'.
cd httpd-2.2.29
./configure --prefix=/path/to/apache22
make
make install
On démarre apache (risque de conflit si une autre version utilise le port 80)
/path/to/apache22/bin/apachectl -k start
Et avec le browser ont doit avoir le classique « It works »
3) Pour compiler mod_perl et tester il y a plus de préparatifs ET une correction de bug:
(peut être certains des packages ci-dessous sont déjà sur votre machine)
yum install perl-ExtUtils-Embed
yum install perl-libwww-perl
yum install perl-CGI
yum install perl-Test-Simple
yum install perl-Linux-Pid
yum install expat
cd /usr/lib64
ln -s libexpat.so.1.x.0 libexpat.so.0
(Adaptez le version de libexpat à votre cas. Pour moi c'est 1.6.0)
4) On va sur http://apache.org/dist/perl/ repérer la dernière version de mod_perl2
puis on la télécharge et on la décompresse :
wget http://apache.org/dist/perl/mod_perl-2.0.8.tar.gz
tar xvf mod_perl-2.0.8.tar.gz
cd mod_perl-2.0.8
ATTENTION #1: Dans le fichier t/api/err_headers_out.t il faut remplacer à deux endroits:
if defined HTTP::Headers->VERSION and HTTP::Headers->VERSION==6.00;
par
if defined HTTP::Headers->VERSION and HTTP::Headers->VERSION>=6.00;
Enfin on peut exécuter la séquence standard :
perl Makefile.PL MP_APXS=/path/to/apache22/bin/apxs
make
make test
make install
NB: Le fait d'avoir installé apache 2.2.x dans un répertoire spécifique n'implique pas que toute la partie mod_perl aille aussi dans ce répertoire. Une partie ira dans apache/include et apache/module mais les modules perl iront dans /usr/local/lib64/perl5
5) Quand on compile soit même Apache on ne bénéficie pas des petits plus apportés par un package comme par exemple la mise en place du script de démarrage. Voici donc comment installer cela avec un Linux, comme centos os 7, qui utilise systemd (sytemctrl) à la place les scripts init.d. On va créer deux fichiers :
a) Le premier est /etc/sysconfig/httpd22
Il sert à configurer l’environnement et les paramètres à passer au daemon httpd.
OPTIONS="-f /path/to/conf/httpd22.conf"
LANG=C
b) Le second /etc/systemd/system/httpd22.service
Il est utilisé par systemd pour exécuter les commandes start/reload/stop et il fait référence au fichier créé ci-dessus.
[Unit]
Description=The Apache HTTP Server 2.2.x
After=network.target remote-fs.target nss-lookup.target
[Service]
Type=simple
KillMode=none
PIDFile=/path/to/apache22/logs/httpd.pid
EnvironmentFile=/etc/sysconfig/httpd22
ExecStart=/path/to/apache22/bin/httpd -DFOREGROUND $OPTIONS
ExecStop=/path/to/apache22/bin/httpd -k stop $OPTIONS
ExecReload=/path/to/apache22/bin/httpd -k restart $OPTIONS
[Install]
WantedBy=multi-user.target
NB: C'est apache qui gère le fichier .pid. Par défaut il est avec les logs de apache, mais on peut changer sa position avec la directive PidFile. Dans ce cas il faut adapter le PIDFile=... dans notre fichier httpd22.service
Après avoir créé ces deux fichiers (et avoir un fichier httpd.conf correct) faire
systemctl daemon-reload
systemctl start httpd22
systemctl status httpd22
Si tout est ok rendre le démarrage automatique
systemctl enable httpd22
Ces 2 fichiers cohabitent très bien avec ceux de httpd 2.4. Si les eux doivent s’exécuter en même temps il faut faire en sorte qu'ils n'utilisent pas le même port en changeant le paramètre "listen 80" dans la config de l'un ou de l'autre.
/path/to/apache22/lib
Après quoi on exécute ldconfig pour que ce nouveau chemin soit pris en compte.
Enjoy 2.2 ;-)
Malheureusement l’installation d’Apache 2.2 sur centos 7 ne peut pas se faire avec yum car seule la version 2.4 est disponible. Voici comment procéder pour compiler Apache 2.2 et mod_perl2 sur centos 7 et mettre en place les fichiers nécessaires au démarrage de httpd 2.2 avec systemctl (aka systemd).
1) Il faut avoir les outils de développements
yum group install "Development Tools"
2) Puis on va sur http://www.us.apache.org/dist/httpd/ et on repère la version la plus récente de httpd-2.2
puis on la télécharge et on la décompresse :
wget http://www.us.apache.org/dist/httpd/httpd-2.2.29.tar.gz
tar xvf httpd-2.2.29.tar.gz
On compile et installe apache 2.2.x
On utilise --prefix pour ne pas installer apache par dessus l’éventuelle version 'officielle'.
cd httpd-2.2.29
./configure --prefix=/path/to/apache22
make
make install
On démarre apache (risque de conflit si une autre version utilise le port 80)
/path/to/apache22/bin/apachectl -k start
Et avec le browser ont doit avoir le classique « It works »
3) Pour compiler mod_perl et tester il y a plus de préparatifs ET une correction de bug:
(peut être certains des packages ci-dessous sont déjà sur votre machine)
yum install perl-ExtUtils-Embed
yum install perl-libwww-perl
yum install perl-CGI
yum install perl-Test-Simple
yum install perl-Linux-Pid
yum install expat
cd /usr/lib64
ln -s libexpat.so.1.x.0 libexpat.so.0
(Adaptez le version de libexpat à votre cas. Pour moi c'est 1.6.0)
4) On va sur http://apache.org/dist/perl/ repérer la dernière version de mod_perl2
puis on la télécharge et on la décompresse :
wget http://apache.org/dist/perl/mod_perl-2.0.8.tar.gz
tar xvf mod_perl-2.0.8.tar.gz
cd mod_perl-2.0.8
ATTENTION #1: Dans le fichier t/api/err_headers_out.t il faut remplacer à deux endroits:
if defined HTTP::Headers->VERSION and HTTP::Headers->VERSION==6.00;
par
if defined HTTP::Headers->VERSION and HTTP::Headers->VERSION>=6.00;
Enfin on peut exécuter la séquence standard :
perl Makefile.PL MP_APXS=/path/to/apache22/bin/apxs
make
make test
make install
NB: Le fait d'avoir installé apache 2.2.x dans un répertoire spécifique n'implique pas que toute la partie mod_perl aille aussi dans ce répertoire. Une partie ira dans apache/include et apache/module mais les modules perl iront dans /usr/local/lib64/perl5
5) Quand on compile soit même Apache on ne bénéficie pas des petits plus apportés par un package comme par exemple la mise en place du script de démarrage. Voici donc comment installer cela avec un Linux, comme centos os 7, qui utilise systemd (sytemctrl) à la place les scripts init.d. On va créer deux fichiers :
a) Le premier est /etc/sysconfig/httpd22
Il sert à configurer l’environnement et les paramètres à passer au daemon httpd.
OPTIONS="-f /path/to/conf/httpd22.conf"
LANG=C
b) Le second /etc/systemd/system/httpd22.service
Il est utilisé par systemd pour exécuter les commandes start/reload/stop et il fait référence au fichier créé ci-dessus.
[Unit]
Description=The Apache HTTP Server 2.2.x
After=network.target remote-fs.target nss-lookup.target
[Service]
Type=simple
KillMode=none
PIDFile=/path/to/apache22/logs/httpd.pid
EnvironmentFile=/etc/sysconfig/httpd22
ExecStart=/path/to/apache22/bin/httpd -DFOREGROUND $OPTIONS
ExecStop=/path/to/apache22/bin/httpd -k stop $OPTIONS
ExecReload=/path/to/apache22/bin/httpd -k restart $OPTIONS
[Install]
WantedBy=multi-user.target
NB: C'est apache qui gère le fichier .pid. Par défaut il est avec les logs de apache, mais on peut changer sa position avec la directive PidFile. Dans ce cas il faut adapter le PIDFile=... dans notre fichier httpd22.service
Après avoir créé ces deux fichiers (et avoir un fichier httpd.conf correct) faire
systemctl daemon-reload
systemctl start httpd22
systemctl status httpd22
Si tout est ok rendre le démarrage automatique
systemctl enable httpd22
Ces 2 fichiers cohabitent très bien avec ceux de httpd 2.4. Si les eux doivent s’exécuter en même temps il faut faire en sorte qu'ils n'utilisent pas le même port en changeant le paramètre "listen 80" dans la config de l'un ou de l'autre.
ATTENTION #2: Quand on se compile un programme (comme ici Apache 2.2) avec ses propres répertoires d'installation on se retrouve avec des fichiers .h ou des librairies à des endroits non standards. Ceci peut poser problèmes par la suite.
Par exemple, si pour utiliser mod_perl on veut installer la librairies Apache2::Request, qui utilise APR::Request, qui est une interface avec la librairie C libapreq2.so, il faudra que le programme d'installation de APR::Request trouve libapreq2.so dans le répertoire ou on a installé notre version d'Apache.
La solution la plus élégante est d'ajouter un fichier apache22.conf dans le répertoire /etc/ld.so.conf.d/ . Ce fichier contiendra juste une ligne du type:
/path/to/apache22/lib
Après quoi on exécute ldconfig pour que ce nouveau chemin soit pris en compte.
Enjoy 2.2 ;-)