Repository EPEL & REMI

Les packages de certaines applications ne sont pas disponibles sur les repositories configurés par défaut avec la distribution. Il faut alors aller les cherche sur d'autres repositories qu'il faut configurer soit même.

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

mod_perl startup

Une fois que l'on a un couple {Apache2 + mod_perl2} adapté il faut faire une peu de configuration. Voici comment mettre en place mod_perl2  et verifier que tout marche.

Rappel: il faut au minimum mod_perl 2.0.9 pour Apache 2.4.x

1) Configurer Apache normalement pour qu'il affiche le fichier index.html de votre répertoire htdocs. Ceci est toujours utile de pouvoir servir des pages statiques sans faire appel à Perl.
NB: Inutile de configurer la partie cgi-bin, ou php ;-)


2) Quand l’étape #1 fonctionne ajouter cette simple ligne à la fin du fichier de configuration principale de apache (httpd.conf)

    Include conf/mod_perl2.conf

Ainsi on ne touchera plus au fichier de configuration principal, on travaillera sur mod_perl2.conf, dont voici le contenu de départ :

LoadModule perl_module modules/mod_perl.so

# la ligne suivante n'est utile que si on a installé le module
# Apache2::Request qui utilise APR::Request qui utilise libapreq2
#   yum install libapreq2
#   cpanm       APR::Request
#   cpanm       Apache2::Request
# (le but étant de ne plus utiliser CGI.pm)
LoadModule apreq_module modules/mod_apreq2.so

PerlPostConfigRequire /path/to/myCode/startup.pl
PerlOptions -SetupEnv
 
<Location /hello>
   SetHandler perl-script
   PerlResponseHandler Hello
   PerlOptions +ParseHeaders
</Location>

a) On charge le module mod_perl (c'est lui qui importe Perl dans Apache)
b) On désigne un script Perl à exécuter au démarrage de Perl (voir plus bas)
c) On désactive l'importation de l'environnement dans le contexte de chaque requête (plus sûr et plus rapide)
d) On annonce que l'url /hello sera traitée par le module Perl Hello.pm
Ce module gèrera lui-même les headers et il sera exécuté en tant que "perl-script" (bien que ce soit forcement un module)


3) Le module Hello.pm est très simple à écrire et à comprendre :

package Hello;
use strict;
use warnings;

sub handler {  # Le nom de la fonction est imposé
    print "Content-type: text/plain\n\n";
    print "Hello at : ". localtime . "\n";
    return Apache2::Const::OK;
}
1;

On le stocke dans /path/to/myCode/Hello.pm



4) Le script startup.pl ressemble à ceci

use lib qw(/path/to/myCode);   # voir "Attention #2" plus bas

use ModPerl::Util ();
use ModPerl::Registry ();
 
use Apache2::RequestRec ();
use Apache2::RequestIO ();
use Apache2::RequestUtil ();
use Apache2::ServerRec ();
use Apache2::ServerUtil ();
use Apache2::Connection ();
use Apache2::Log ();
use Apache2::Const -compile => ':common';

use APR::Table ();
use APR::Const -compile => ':common';

1;

Le plus important dans ce fichier est la première ligne car elle indique où seront vos modules Perl chargés de réponde aux requêtes. Les autres "use" préchargent des modules d'usage courant ce qui evitera de répéter ces "use" dans chaque module Perl.


Si vous devez ouvrir un accès à une base de donnée ce sera aussi dans ce script en utilisant Apache::DBI Exemple pour Postgresql

use Apache::DBI;
Apache::DBI->connect_on_init("dbi:Pg:dbname=myDB", 
  "myUSR", 
  "myPASS",
  {AutoCommit => 1, RaiseError => 1, PrintError => 1} 
);
Apache::DBI->setPingTimeOut("dbi:Pg:dbname=myDB", 30);

ATTENTION #1: Pour accéder à la base de donnée dans un module (handler) il faudra utiliser le classique $dbh = DBI->connect(...) Mais il faudra que tous les paramètres de connect() soit exactement les mêmes que ceux passé à connect_on_init();


ATTENTION #2: Dans le contexte de mod_perl2 "use FindBin;" ne marche pas comme espéré.

En effet $FindBin::Bin donne le point de démarrage du serveur Apache, pas celui de startup.pl.

A la place il faudra faire ce genre de gymnastique:

use File::Basename;
our $PERLBASE;
BEGIN {
  $PERLBASE = dirname( __FILE__ );
}
use lib $PERLBASE;


Dans tous les modules (handlers) vous pourrez accéder simplement à $::PERLBASE

proxy ssh

Il arrive souvent que les machines d’un réseau de développement  ne soit pas accessibles depuis l’extérieur à l’exception d’une machine jouant le rôle de porte d’entrée (frontdoor.mydomain.com).

Pour accéder depuis l’extérieur aux machines internes on établit depuis son poste externe une première connexion ssh avec  frontdoor.mydomain.com puis, de là, on établit une seconde connexion ssh vers la machine interne sur laquelle on veut travailler. Donc une opération en deux temps.

On peut simplifier ceci en établissant des ‘tunnels’ entre le frontdoor et les machines internes qui vont faire en sorte qu’une connexion sur le port 8001 du frontdoor donne directement accès à dev1, qu’une connexion sur le port 8002 du frontdoor donne directement accès à dev2 etc…

On établit donc un tunnel entre le port 8001 du frontdoor et le port 22 de dev,
puis un tunnel entre le port 8002 du frontdoor et le port 22 de dev2 etc…

Pour cela on se connecte sur le frontdoor et on exécute par exemple ces 2  commandes pour établir deux tunnels :

ssh -N -f -L 8001:localhost:22 devusr1@dev1.mydomain.com

ssh -N -f -L 8002:localhost:22 devusr2@dev2.mydomain.com

Chaque commande va  demander le mot passe pour se connecter  avec le user voulu à la machine interne qui sera l’extrémité ‘22’ du tunnel. Si la clé publique du user de frontdoor  est acceptée par le devusr coté machine de développement aucun mot de passe n’est demandé.  (Cette possibilité est très utilise si on veut automatiser l’établissement et la supervision de ces tunnels)

Ceci fait on peut fermer la session avec le frontdoor, les tunnels resteront actifs.

Maintenant, pour se connecter sur dev1 depuis l’extérieur on tape

    ssh –p 8001 usr@frontdoor.mydomaine.com

et bien sur la commande suivante vous loguera sur dev2

    ssh –p 8002 usr@frontdoor.mydomaine.com

La demande de mot de passe sera pour l'utilisateur 'usr' sur frontdoor. Là aussi on peut aussi utiliser un système de clés.

NOTE

Du point de vue de la machine interne (dev1 ou dev2) vous êtes un utilisateur connecté depuis 127.0.0.1 pas depuis frontdoor. Facile à vérifier avec la commande ‘who ‘

Il y a plein d'autre utilisations de cette technique du 'Local Port Forwarding'. Mais attention au firewall qui peut se trouver devant le frontdoor et qui pourrait bloquer l’accès aux ports d'entré du tunnel (8001, 8002 dans notre exemple)

Il y aussi des variantes de cette technique :

- Remote port forwarding (on établit le tunnel dans l'autre sens en utilisant ssh -R à la place de ssh -L)

- Dynamic port forwarding (plus complexe et nécessite la configuration SOCKS)

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, user, 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