Espace logiciel libre à l'Ecole

4. Utiliser tequila dans un cgi

elle — 2003-10-15T16:49:12Z

Tequila permet aussi l'authentification dans les cgi-bin.

Le rpm de tequila-clients contient un module perl qui va permettre de gérer des sessions pour des applications. Par défaut, ce module est placé dans /var/www/cgi-bin/Tequila/Clients.pm [1].

Le module perl contient un ensemble de méthodes accessibles depuis un script perl. Quelques exemples permettront de d'utilser ces méthodes, de façon simple mais parfois aussi complexe.

Préliminaire important En cas d'échec d'authentification, le serveur ne rendra pas la main à l'application.

Exemple 1 : authentification simple

Ce cgi-bin tout simple requiert simplement une authentification par Tequila et imprime quelques attributs renvoyés par le serveur :


 use strict;
 use Tequila::Client;
 
 my $tequila = new Tequila::Client ();
 $tequila->setservice ('Tequila example 1');
 $tequila->setlang ('french');
 
 $tequila->authenticate ();

new Tequila ::Client : instancie l'objet tequila
$tequila->setservice : nomme le service pour lequel l'utilisatrice va s'authentifier [2]
$tequila->setlang : choisit la langue de l'interface d'authentification [anglais par défaut] [3].
$tequila->authenticate : active le processus d'authentification par Tequila
- si une session valide existe déjà pour l'utilisatrice, Tequila va remplir les attributs avec ceux de cette utilisatrice
- sinon, Tequila va proposer l'authentification [4]

Une fois l'authentification validée, Tequila rend la main à la variable urlaccess [Par défaut, l'url appelante, càd l'adresse de cet exemple].

Exemple 2 : authentification avec informations détaillées

Il est possible de récupérer les différents attributs concernant une personne qui s'authentifie. Certain seront requis (request) et certains souhaités (wish). Lors de son authentification, l'utilisatrice ne pourra pas ignorer ce qui se passe et pourra décider si, oui ou non, les attributs souhaités seront communiqués à l'application.


 use strict;
 use Tequila::Client;
 
 my $tequila = new Tequila::Client ();
 
 
 $tequila->authenticate ();

Exemple 3 : authentification en fonction des droits et rôles EPFL

L'annuaire de l'EPFL comprend aussi une interface avec l'Accreditation de l'EPFL. Ceci peut se visualiser en cliquant sur le lien Voir les accréditations de cette personne qui se trouve au bas du résultat d'une requête dans l'annuaire ldap .

Par Tequila, il est alors possible d'utiliser ces informations au sein du cgi.


 use strict;
 use Tequila::Client;
 
 my $tequila = new Tequila::Client ();
 $tequila->authenticate ();

[1] Si les cgis sont ailleurs, il suffit de déplacer le répertoire Tequila/.

[2] Bien que non obligatoire, cette option est conviviale.

[3] A ce jours 3 langues sont possibles : english, français et deutsch

[4] Par défaut, la session est créée par un appel de Tequila au fichier cgi-bin/tequilalogin (variable urlauth)

5. Remarque pour les managers

elle — 2003-07-10T14:46:55Z

Effacer les anciennes clés de session Tequila

Les clés de sessions déposées par Tequila dans le répertoire identifié par TequilaSessionDir ne peuvent être effacées par le serveur. En conséquence, il faudra penser à nettoyer le répertoire correspondant. Par un cron, par exemple.

3. Utiliser l'authentification par Tequila

elle — 2003-07-10T13:50:06Z

Lors de l'accès à une page web protégée par authentification de type Tequila, voici ce qui se passe.

Le serveur web redirige automatiquement la requête vers le serveur sécurisé de tequila.
S'authentifier par son username [1] et mot de passe. A noter que le mot de passe sera donc transmis sous forme encryptée sur le réseau.
Cocher la case du bas Voulez-vous utiliser un cookie si vous souhaitez ne pas devoir à nouveau vous authentifier lors d'un accès à un autre serveur protégé par Tequila.
Login
A ce stade, il faut que votre butineur accepte les cookies sinon vous devrez vous réauthentifier à chaque utilisation de l'arborescence considéré.

Il y a donc deux types de cookies :

Le cookie du serveur Tequila proprement dit. Celui-ci informe votre butineur que vous êtes déjà authentifié.e auprès de Tequila.
Le cookie du serveur web en cours de consultation. Celui-ci informe votre butineur que vous êtes authentifié.e pour le serveur considéré [2].

[1] En cas de doute sur son username, il est mentionné explicitement dans notre annuaire

[2] A noter qu'un même serveur web peut avoir plusieurs arborescences protégées de façons distinctes par Tequila (voir les exemples de configurations )

1. Installer Tequila-clients

elle — 2003-06-20T15:14:20Z

La version actuelle de Tequila-clients n'est disponible que pour apache 1.3. La version pour apache 2 devrait être bientôt disponible.

Pour installer Tequila-clients sur sa machine il suffit de télécharger le rpm disponible dans. Pour des raisons de simplicité, le rpm est nommé sous forme générique. [1] :


 wget http://slpc1.epfl.ch/public/software/tequila/tequila-clients-current.i386.rpm

et de l'installer [2]


 rpm -Uvh tequila-clients-current.i386.rpm

[1] Pour connaître la version courante, une fois le logiciel téléchargé, il suffit d'utiliser rpm :


 rpm -q --queryformat "%{name}-%{version}-%{release}\n" -p tequila-clients-current.i386.rpm

On peut maintenant aussi accéder au répertoire


 http://slpc1.epfl.ch/public/software/tequila/

[2] Pour savoir le numéro de la version :


 rpm -qi -p tequila-clients-current.i386.rpm

2. Configurer apache pour utiliser Tequila

elle — 2003-06-20T15:14:10Z

Quelques exemples de configuration de apache pour inclure une arborescence protégée par authentification par Tequila (EPFL) [1].

Exemple 1 : Une arborescence du serveur principal

Soit le serveur servtest.epfl.ch et le répertoire /var/www/html/subdir/monExemple pour lequel nous voulons restreindre l'accès uniquement aux personnes de l'EPFL ou à toute personne qui accède à cette arborescence depuis le site de l'EPFL.

Dans le fichier /etc/httpd/conf/httpd.conf nous allons inclure tout ce qu'il faut mettre en oeuvre l'authentification par Tequila [2] .

Charger le module Tequila :
LoadModule tequila_module modules/mod_tequila.so

Activer le module Tequila :
AddModule mod_tequila.c

Configurer les paramètres de session Tequila et les authentifications requises :
<IfModule mod_tequila.c> TequilaLog /var/log/Tequila/monExemple.log TequilaLogLevel 2 TequilaServer tequila.epfl.ch TequilaSessionDir /var/log/Tequila/Sessions TequilaSessionMax 7200 <Location /subdir/monExemple/> TequilaRewrite /var/www/restricted/monExemple/ TequilaAllowIf org=EPFL TequilaAllowNet 128.178. #TequilaHasSSL </Location> </IfModule>

TequilaLog : le fichier des logs de Tequila (créer le répertoire si nécessaire)
TequilaLogLevel : le niveau de debug pour les logs de Tequila (9 étant très bavard)
TequilaServer : le nom du serveur Tequila (EPFL : tequila.epfl.ch)
TequilaSessionDir : le répertoire qui contient les clés de session pour une arborescence donnée (créer le répertoire si nécessaire)
TequilaSessionMax : le temps maximum de la session en secondes
TequilaRewrite : le répertoire du serveur web qui contient l'arborescence sécurisée [3]
TequilaAllowIf : les conditions de droit à l'authentification [4]
TequilaAllowNet : le subnet pour lequel l'authentification ne sera pas demandée
TequilaHasSSL : option utile si il s'agit d'une accès sécurisé (https) [5]

Redémarrer le serveur apache avec cette nouvelle configuration :
service httpd restart

Tester en se connectant à http://servtest.epfl.ch/subdir/
La redirection vers le serveur tequila devrait se faire si on accède à cette page depuis la maison par exemple
En cas de problème, lire les logs dans /var/log/httpd/tequila.monExemple.log

A noter qu'il est possible de la même manière de protéger uniquement un fichier.

Exemple 2 : Restreindre l'accès d'une arboresence d'un virtual host à quelques personnes identifiées par leur numéro sciper

Soit servtest2.epfl.ch un virtual host sur le serveur servtest.epfl.ch et subdir/monExemple le répertoire à protéger.

La partie du fichier htppd.conf concernant ce virtual host sera de cette mouture :


 <VirtualHost servtest2.epfl.ch>
 ServerAdmin toto.rochat@epfl.ch
 DocumentRoot /virtdir
 ServerName servtest2.epfl.ch
 ServerAlias servtest2 servtest2.epfl.ch
 <Directory "/virtdir">
 Options FollowSymLinks
 AllowOverride none
 <Limit GET POST OPTIONS PROPFIND>
 Order allow,deny
 Allow from all
 </Limit>
 </Directory>
 <IfModule mod_tequila.c>
 TequilaLogLevel 2
 TequilaLog /var/log/Tequila/monExemple.log
 TequilaServer tequila.epfl.ch
 TequilaSessionDir /var/log/Tequila/Sessions
 TequilaSessionMax 7200
 <Location /subdir/monExemple/>
 TequilaRewrite /virtdir/subdir/monExemple/
 TequilaAllowIf uniqueid=104359&org=EPFL
 TequilaAllowIf uniqueid=104360&org=EPFL
 TequilaAllowIf uniqueid=104361&org=EPFL
 TequilaAllowIf uniqueid=104362&org=EPFL
 </Location>
 </IfModule>
 </VirtualHost>

[6]

TequilaAllowIf : les authentifications sont cette fois basées sur le numéro sciper de l'EPFL (identificateur unique)
nous avons ici choisi le TequilaRewrite dans l'arborescense normale

Exemple 3 : Restreindre l'accès d'une arboresence par htaccess

Pour qu'une arborescence puisse être sous authentification Tequila, il faudra :

que le fichier de configuration de apache httpd.conf contienne les informations générales de Tequila : chargement du module, activation du module, définition des paramètres globaux (au minimum TequilaServer)
que les droits au niveau du serveurs soient au minimum AuthConfig (sinon le fichier .htaccess ne sera pas lu) :
<Directory xxx> AllowOverride AuthConfig </Directory>

qu'un fichier .htaccess se trouve à la racine de l'arborescence à protéger, par exemple :
TequilaAllowIf uniqueid=123456&org=EPFL TequilaAllowIf uniqueid=123457&org=EPFL

La notion de TequilaRewrite n'a pas d'application dans ce cas.

[1] Apache 1.3 seulement à ce jour

[2] On suppose que la balise <Directory> est


 <Directory "/var/www/html">

[3] A noter que ce répertoire peut être identique à l'arborescence correspondante. Toutefois, choisir un répertoire en dehors de l'arborescence web assurance sans doute encore une plus grande sécurité.

[4] La liste des options d'identification possible est résumée ici :


 #
 # Configuration du connecteur LDAP Data pour Gaspar.
 #
 Server: ldap.epfl.ch
 Base: o=epfl,c=ch
 UseSSL: off
 #
 Supports: name firstname status classe email title unit where office phone \
 username uniqueid unixid groupid
 #
 Mapping: name sn
 Mapping: firstname givenname
 Mapping: status organizationalStatus
 Mapping: classe userClass
 Mapping: email mail
 Mapping: title title
 Mapping: unit ou
 Mapping: where dn
 Mapping: office roomNumber
 Mapping: phone phone
 Mapping: username uid
 Mapping: uniqueid uniqueIdentifier
 Mapping: unixid uidnumber
 Mapping: groupid gidnumber

[5] A noter que l'accès au serveur tequila, qui demandera de s'authentifier, sera elle toujours sécurisée.

[6] Les paramètres globaux de Tequila peuvent être configurer au niveau global, par exemple :


 <IfModule mod_tequila.c>
 TequilaLogLevel 2
 TequilaLog /var/log/Tequila/monExemple.log
 TequilaServer tequila.epfl.ch
 TequilaSessionDir /var/log/Tequila/Sessions
 TequilaSessionMax 7200
 </IfModule>
 #
 <VirtualHost servtest2.epfl.ch>
 ServerAdmin toto.rochat@epfl.ch
 DocumentRoot /virtdir
 ServerName servtest2.epfl.ch
 ServerAlias servtest2 servtest2.epfl.ch
 <Directory "/virtdir">
 Options FollowSymLinks
 AllowOverride none
 <Limit GET POST OPTIONS PROPFIND>
 Order allow,deny
 Allow from all
 </Limit>
 </Directory>
 <Location /subdir/monExemple/>
 TequilaRewrite /virtdir/subdir/monExemple/
 TequilaAllowIf uniqueid=104301&org=EPFL
 TequilaAllowIf uniqueid=104302&org=EPFL
 TequilaAllowIf uniqueid=104303&org=EPFL
 TequilaAllowIf uniqueid=104304&org=EPFL
 </Location>
 </VirtualHost>

NetBackup : Installation

elle — 2003-06-11T14:11:55Z

L'installation de NetBackup sur son serveur Linux RedHat se fait tout simplement à partir du cdrom à disposition auprès de Aristide Boisseau , responsable de Veritas à l'EPFL.

Les fichiers sont installés dans le répertoire /usr/openv/. Le fichier /etc/services est aussi modifié pour ajouter le service bpjobd.

Enfin, les fichiers /etc/xinetd.d/bpcd et /etc/xinetd.d/bpjava-msvc pour la sécurité.

NetBackup accède au serveur local par le port 13782 (bpcd) qui doit donc être accessible, tant au niveau du firewall que du tcp wrapper (/etc/hosts.allow).

NetBackup : Sélection de sauvegarde

elle — 2003-06-11T13:54:54Z

La liste des répertoires à backuper est gérée par l'administrateur du serveur Veritas.

Si le client le souhaite, il peut exclure dans fichiers et des répertoires de ce qui sera backupé (répertoires de cache, fichiers de log qui bougent sans cesse, etc.) en les incluant dans le fichier /usr/openv/netbackup/exclude_list [1]

Parmi les répertoires exclus, on peut encore décider de ne prendre que certains fichiers ou sous-répertoires. Ceci se fait en les mentionnant dans le fichier /usr/openv/netbackup/include_list.

Exemple

Supposons que le serveur Veritas va vouloir backuper le répertoire /disc1.

Il est possible d'exclure de ce répertoire toute l'arborescence test en l'incluant dans le fichier /usr/openv/netbackup/exclude_list :


 /disc1/test

Mais si dans l'arborescence test nous avons une sous-arborescence agarder que nous souhaitons sauvegarder, nous ajouterons dans le fichier /usr/openv/netbackup/include_list :


 /disc1/test/agarder

Documentation

Pour une documentation complète de la syntaxe de ces fichiers, voir les pages 86 à 115 du gros document de NetBackup .

[1] Par exemple, pour exclure les fichiers cache de java (j2re), on ajoutera la ligne suivante :


 /home/*/.java/*/cache/

NetBackup : Stratégie de backup

elle — 2003-03-04T19:03:44Z

Les premières utilisations de Veritas NetBackup d'un serveur sous Linux donnent quelques résultats qu'il est utile de comprendre.

Backup incrémental avec les options par défaut

Surprise : Après avoir ajouter plus de 1 GB de données sur le serveur, le backup incrémental n'a backupé que 20 MB de données. Pourquoi ?

Compréhension : L'algorithme utilisé par NetBackup pour décider si un fichier doit faire partie d'un backup incrémental est de comparer la date de modification (mtime) du fichier par rapport à la date du dernier backup. Comme les GB ajoutés proviennent principalement de fichiers installés depuis des fichiers d'archives, la majorité de leurs dates sont antérieures à la date du dernier backup et ne sont donc pas sauvegardées.

Les dates des fichiers : Sous GNU/Linux (et Unix en général), les fichiers ont 3 données d'information sur le temps :

ctime : la date de dernière modification de l'inode du fichier
mtime : la date de dernière modification du fichier
atime : la date de dernier accès au fichier (lecture)

Avec les paramètres par défaut du client NetBackup, seul le mtime est pris en compte pour décider si un fichier doit être backupé.

Etat des dates des fichiers après backup par NetBackup : Lorsqu'un fichier est backupé par NetBackup, sa date atime n'est pas modifiée mais sa date ctime correspond au moment du backup. Ceci correspond à un choix. Netbackup ne souhaite pas que atime soit modifié. Ceci se fait un utilisant la fonction utime qui restaure atime à sa valeur juste avant le backup mais avec pour effet secondaire de modifer ctime.

Option possible du client NetBackup

Il est possible d'ajouter dans le fichier /usr/openv/netbackup/bp.conf deux lignes qui vont changer le comportement de NetBackup [1] :

Cette fois, NetBackup va utiliser, non pas mtime mais ctime pour comparer cette date à sa date de référence (dernier backup).

En outre, en ne recouvrant pas le atime d'avant le backup, le ctime ne sera pas modifié [2].

Ces deux options sont celles choisies pour nos serveurs car des fichiers dont la date est antérieure sont souvent déroulés sur ces serveurs.

Remarque

La documentation dit aussi ceci concernant ces deux options : DO NOT use these options if you are running Storage Migrator on the system. Setting these options causes the atime for files to be updated every time they are backed up. This makes it appear as if the files are frequently used and stops Storage Migrator from selecting them for migration.

[1] Les pages 781 à 786 de ce gros document de NetBackup parlent de façon peu explicite de ces aspects. Quelques pistes supplémentaires existent

[2] C'est ce qui se passe lors de backups avec NetWorker, de Legato.

4. VPN et les firewalls

elle — 2002-12-06T16:27:12Z

ipchains

Si on utilise ipchains comme firewall, pour utiliser vpn il faudra ouvrir le port 500.

Pour cela, ajouter dans le fichier /etc/sysconfig/ipchains les 2 lignes suivantes (à mettre avant les REJECTS car l'ordre dans ipchains a de l'importance) :

Puis il faut arrêter et redémarrer le serveur ipchains :


 service ipchains restart

iptables

Si on utilise iptables comme firewall, pour utilise vpn il faudra aussi ouvrir le port 500.

Pour cela, ajouter dans le fichier /etc/sysconfig/ipchains les 2 lignes suivantes (à tester) :

Puis il faut arrêter et redémarrer le serveur iptables :


 service iptables restart

2. VPN sous redhat 8.0 à l'EPFL

elle — 2002-11-28T16:50:43Z

Installer vpn

Pour installer vpn sous linux, suivre les instructions.

Il faut toutefois être attentif car souvent il faut télécharger la version de base et la version de mise à jour.

Dans un répertoire, detarer le tar de base, puis le tar de mise à jour avant de lancer le script d'installation.

Initialiser le client

Si vous avez choisi de lancer automatiquement le client vpn, rien à faire. Sinon, en tant que root, lancer interativement la commande


 /etc/init.d/vpn_client_init start

Se connecter

Comme simple utilisateur, lancer la commande


 vpnclient connect EPFL_LAN

Il faut s'identifier par son numéro sciper et son mot de passe gaspar.

Après le lancement du client, pour récupérer le prompt, mettre la tâche en background (^Z, puis bg).

Si lors du démarrage de vpnclient, un message parle d'incompatibilité de version de gcc, c'est que la version de vpn que vous utilisez n'est pas asser récente.

Se déconnecter

Utiliser la commande


 vpnclient disconnect

Obtenir des informations sur la connexion

La commande


 vpnclient stat

permet d'avoir des détails sur la connexion. Une documentation complète est disponible chez cisco.