Administration d’un service de listes de diffusion avec

Administration d’un service de listes de diffusion avec
Novembre 2004 Administration d’un service de listes de diffusion avec Serge Aumont & Olivier Salaün September 2004

Pourquoi Sympa par le CRU ?
Les listes de diffusions sont un service de base des universités et établissements d’enseignement supérieur. Première génération de serveur de listes de diffusion pour accompagner la migration de EARN. (Serveur de listes du CRU = 8 millions de messages diffusés en Octobre 2004) Toujours un déficit de l’offre par rapport aux besoins La logique du libre n’est pas seulement d’utiliser les réalisations des autres Notre tutelle est maintenant convaincue des retombées favorables de cet effort en particulier en terme d’image Sympa est notre matériel d’expérimentation favori (pages dynamiques, cgi/MySQL, LDAP, S/MIME, antivirus, SSO, SOAP, XML …)

Les inscrits 300 inscrits dont : Majorité : universités
30 Recherche (CNRS, INRA, INRIA) 26 Rectorats 16 IUFM 14 xx.gouv.fr Collectivités locales Entreprises privées

Les utilisateurs 4 000 sites connus Education :
90% des universités françaises +IUFM + Rectorats Universités étrangères (Europe, USA, Amérique du sud, Asie du sud est) Ministères et agences gouvernementales Fournisseurs de service & SSII Associations Entreprises privées

Le support (http://www.sympa.org)
Manuel de référence FAQ Archives des listes Google site:sympa.org « mon problème » Articles et présentations Listes de discussion (sympa-fr, sympa-dev) Support commercial

Disponibilité, versions
Architecture générale et organisation de Sympa Interaction avec le système, structure de la base robots virtuels Authentification Autorisation Shibboleth Protection des données individuelles Listes dynamiques Familles de listes Les templates Le serveur soap En cas de problème Perspectives

Ce qui ne sera PAS abordé aujourd’hui...
Présentation exhaustive des fonctionnalités utilisateur Installation « pas à pas » de Sympa Fonctionnalités S/MIME

Evolution des versions
Mars 2004 SOAP Auth. CAS, Shibboleth Gestion auto. Bounces HTML Area Juillet 2000 WWSympa inclus S/MIME 3.4.4 4.1 2.7.3 3.4 HEAD Fin 2004/début 2005 TT2 Familles de listes Include owners Modération documents Canal RSS Upload zip Octobre 2002 Include 2 AuthN LDAP Virtual robots Task manager Documents partagés Antivirus 4.1.2

Distribution de Sympa sympa-xx.tar.gz Paquets :
Préserve les personnalisations Gestion automatique des dépendances CPAN Maj automatique des structures de données Paquets : Debian : sympa dans unstable Mandrake : maintenu par le rectorat de Nantes RedHat : pas maintenu !! CVS : ne pas installer une version « anonyme » !!

Mise à jour de votre installation
Incompatibilités : indiquées dans le fichier NEWS (lignes *****) affiché au début du make install Installation/Maj des modules CPAN : Géré automatiquement au make install Modification de la structure de la base : Pour MySQL mise à jour auto, au démarrage de sympa.pl Préservation de vos personnalisations : Seul le répertoire /home/sympa/bin/ est écrasé

Architecture générale et organisation de Sympa Interaction avec le système, structure de la base Les robots virtuels Authentification Autorisation Shibboleth Protection des données individuelles Listes dynamiques Familles de listes Les templates Le serveur soap En cas de problème Perspectives

Organisation d’un serveur Sympa
super listmaster listes.cru.fr Serveur Robots virtuels recherche.gouv.fr jres.org cru.fr listmaster Familles owner Listes editor

Une organisation hiérarchique
Mecanisme d’héritage s’applicant aux : Fichiers de configuration et aux paramètres Fichiers d’authorisation (scenarios) Templates web Messages de service (templates) Il est souhaitable de définir les défauts au niveau le plus haut Le niveau le plus haut est la distribution de Sympa (/home/sympa/bin/etc/)

Un robot par défaut ou pas…
Le robot par défaut peut : Contenir les listes du service principal Servir uniquement pour définir des défauts communs à tous les robots virtuel (dans ce cas il faut définir un paramètre host jamais utilisé) La solution (2) offre plus de souplesse

Les rôles dans Sympa au niveau global
Listmaster du site : défini dans sympa.conf Gère le service au niveau système (personnalisation, création de robots virtuel, familles,…) Listmaster d’un robot virtuel : Défini dans robot.conf Valide les créations de listes, assure le support auprès des propriétaires de listes

Les rôles dans Sympa au niveau d’une liste
Propriétaire : Gère la population des abonnés (ajout, suppression, bounces) Configure la liste (paramètres, templates, scenarios) Propriétaire privilégié : Gère les propriétaires Accès à des paramètres de configuration sensibles (send,…) Modérateur : Gère les contenus de la liste (messages, documents partagés)

Organisation des données
Des fichiers pour : La configuration (globale, des listes) Les templates Les « spools » Les archives Une base de données pour : Les préférences utilisateurs Les membres des listes (nombreux attributs) Les « gérants » des listes (cache uniquement ; référence = fichier de configuration de la liste)

Organisation / les répertoires
/home/sympa/bin/ # Exécutables /home/sympa/bin/etc/ # Configurations par défaut /home/sympa/etc/ # Configurations du site /home/sympa/etc/scenari/ # Scenarios d’autorisation /home/sympa/etc/mail_tt2/ # Messages de service /home/sympa/etc/web_tt2/ # Templates web /home/sympa/etc/family/ # Répertoire des modèles de familles /home/sympa/etc/mon-robot/ # Configurations robot virtuel /home/sympa/expl/ # Répertoire des listes /home/sympa/expl/maliste/ # Répretoire d’une liste /home/sympa/expl/X509r-certs/ # Certificats utilisateurs /home/sympa/spool/ # Les “spools” /home/sympa/src/ # Pour stoquer vos tar.gz… /var/bounce/ # Stockage des bounces /home/httpd/html/arc/ # Les archives web

Organisation / les fichiers de configuration
/etc/sympa.conf # Configuration du site /etc/wwsympa.conf # Configuration relative à l’interf. web /home/sympa/etc/topics.conf # Les catégories de listes /home/sympa/etc/edit_list.conf # Qui peut éditer quel paramètre /home/sympa/etc/auth.conf # Configuration de l’authentification /home/sympa/etc/mon-robot/robot.conf # Configuration d’un robot virtuel /home/sympa/etc/family/ma-famille/edit_list.conf /home/sympa/etc/family/ma-famille/param_constraint.conf # Contraintes param. listes /home/sympa/expl/maliste/config # Fichier de configuration d’une liste

Les démons sympa.pl wwsympa.fcgi Internal database spool
task_manager.pl archived.pl config bounced.pl templates sympasoap.fcgi

Circuit d’un complexe mail
valid confirm message List config message Sendmail root.bin sympa.pl uid sympa mysql msg auth mod outgoing message confirm valid message message message

Interactions avec la messagerie
exim, postfix, qmail, sendmail sendmail  sympa.pl via spool msg ma-liste: “| /etc/smrsh/queue ma-liste” -rwsr-xr-x 1 sympa sympa Oct 13 14:55 /etc/smrsh/queue* sendmail  bounced.pl : idem, bouncequeue

Interactions avec la messagerie
sympa.pl et wwsympa.pl  /usr/bin/sendmail wwsympa.pl et sympa.pl  newaliases -rwxr-xr-x 1 sympa sympa 5933 Oct 15 12:24 alias_manager.pl* -rwsr-x--- 1 root sympa Oct 13 14:55 aliaswrapper* sendmail.mc : define(`ALIAS_FILE', `/etc/mail/aliases,/etc/mail/sympa_aliases')dnl maxsmtp pour contrôler la charge du serveur nrcpt pour optimser le groupage. Attention à ne pas passer pour un spammeur

Interactions avec Syslogd
serveur de log unix Voir : syslog.conf log_socket_type dans sympa.conf log_level dans sympa.conf et wwsympa.conf option –d pour chaque démon (sauf fastcgi) Attention à la charge induite

Interaction avec le systeme
MySQL ou autre SGBD pour le backend : Le backend de type fichier (user_data_source file) est abandonné : perfs déplorables, manque fonctionnel, plus de support. Le SGBD de référence est MySQL : versions beta testées uniquement avec MySQL Création et mise à jour automatique de la structure des tables (au lancement de sympa.pl)

Apache Un uid/gid unique pour wwsympa.fcgi, archived.pl, bounced.pl and sympa.pl. wwsympa.fcgi : sympa.sympa + bit s Serveur apache dédié avec uid sympa Virtual host + directive User dans httpd.conf attention borne sup pour uid/gid) attention directive User et Goup avant FastCgiServer wrapper en C

Apache fastcgi Fastcgi est requis
FastCgiServer /home/sympa/bin/wwsympa.fcgi -processes 2 <Location /wws> SetHandler fastcgi-script </Location> ScriptAlias /wws /home/sympa/bin/wwsympa.fcgi

OpenSSL openssl : binaire de OpenSSL,
cafile capath : bundle des certificats d’AC (fichier et répertoire). Partage avec la config https recommandée

OpenSSL key_password :mot de passe pour protéger les clés privées de chaque liste quand celle-ci dispose de certificat pour le chiffrement Installation d’un certificat de liste : p12topem.pl --pkcs12 cert.p12 –listname foo --robot cru.fr

Antivirus Pour ne pas traiter les bounces
mailhost et listhost différents Produit supportés : uvscan, avp, fsav, sophos, clamav Sympa.conf antivirus_path /usr/local/bin/uvscan antivirus_args --summary --secure antivirus_notify nobody

MhOnarc Le moteur de conversion utilisé par archived et le module de modération par le web Archives stokées dans un répertoire séparé (partition recommandée), voir arc_path Config de liste web_archive Access private quota 10000

…/list@dom/arctxt/xx
MhOnarc …/spool/outgoing sympa.pl archived.pl mhonarc_ressources remove rebuild wwsympa.fcgi tt2

htmlarea Compatible IE 5.5 et + et Mozilla 1.4 et + (Gecko)
Installer htmlarea quelque part sur le même host Renseigner htmlarea_url (wwsympa.conf)

Structure de la base Tables : user_table, subscriber_table, admin_table user_table _user gecos_user password_user chiffrement réversible cookie_delay_user permanence de session lang_user attributes_user cache des attributs hérités

Structure de la base subscriber_table list_subscriber Ex: sympa-fr
user_subscriber Ex: date_subscriber # jour depuis 1970 update_subscriber Ex: visibility_subscriber Ex: conceal reception_subscriber Ex: digest

Structure de la base / subscriber
bounce_subscriber date de premier bounce, date de dernier bounce, nombre de bounce, type du dernier bounce, ex : comment_subscriber gecos par liste subscribed_subscriber 1 si add or sub included_subscriber 1 si inclusion dynamique include_sources_subscriber id de la source d’inclusion bounce_score_subscriber euristique de désabonnement automatique, task_manager.pl

Structure de la base admin_table user_admin Ex: dupont@cru.fr
list_admin Ex: sympa-fr role_admin owner|editor profile_admin Ex: privileged reception_admin Ex: nomail comment_admin gecos info_admin Info privée

Structure de la base date_admin date création update_admin date update
subscribed_admin 1 si definition statique included_admin 1 si definition par include include_sources_admin Id de la source d’incl

MySQL : les droits Créer un usager avec les droits suivants :
En fonctionnement normal select_priv insert_priv update_priv delete_priv Initialisation ou mis à jour create_priv drop_priv index_priv alter_priv

Robots virtuels Equivalent Sympa des domaines virtuels de sendmail et des hosts virtuels d’Apache Une seule installation de Sympa Les démons servent indistinctement tout les robots Pas de création en ligne du robot

Installation messagerie
Créer le domaine dans le DNS Installer un domaine virtuel sendmail virtual-domains:virtual.org virtual.org-%1%3 Créer les alias virtual.org-sympa: "| ../bin/queue virtual.org-listmaster: "| ../bin/queue template list_alias.tt2 a perrsonnaliser selon la forme de vos alias

Installation apache FastCgiServer /home/sympa/bin/wwsympa.fcgi -processes 3 <VirtualHost > ServerAdmin DocumentRoot /var/www/virtual.org ServerName listes.virtual.org <Location /wws> SetHandler fastcgi-script </Location> ScriptAlias /wws /home/sympa/bin/wwsympa.fcgi </VirtualHost>

Installation robot virtuel
/home/sympa/etc/virtual.org/robot.conf http_host : comparé à $ENV{‘SERVER_NAME’} pour déterminer quel robot solliciter. Exemple : http_host listes.virtual.org wwsympa_url base URL Exemple wwsympa_url

Installation robot virtuel
Les variables suivantes peuvent être positionnée pour un virtual robot , elles remplacent les valeures par défaut spécifiées dans sympa.conf : lang log_smtp listmaster max_size dark_color, light_color, text_color, bg_color, error_color, selected_color, shaded_color soap_url cookie_domain title default_home create_list

Exemple de robot.conf http_host demo.sympa.org
wwsympa_url title A demo mailing list service listmaster create_list public_listmaster default_home lists lang us default_shared_quota 5000 soap_url

Personnaliser les robots
/home/sympa/etc/virtual.org/web_tt2/, /home/sympa/etc/virtual.org/wws_templates/, /home/sympa/etc/virtual.org/mail_tt2/, /home/sympa/etc/virtual.org/templates/, /home/sympa/etc/virtual.org/scenari/ /home/sympa/etc/virtual.org/edit_list.conf /home/sympa/etc/virtual.org/topics.conf

Authentification Sympa doit être compatible avec la politique d’authentification de l’établisssement (LDAP, SSO, Certificats X509) Toujours des usagers exterieurs. Comment traiter les exceptions ?

Authentification Obligation de panacher les méthodes d’authentification Choix du système d’authentification en fonction de l’usager concerné. Préserver la cohérence de l’authentification à travers les différentes interfaces.

Méthodes d’authentication
Interface Challenge de confirmation mail Password (allocation par ) web LDAP AuthN backend SSO: CAS SSO: Shibboleth Web & SOAP Web certificat utilisateur Mail: S/MIME Web: HTTPS

Authentification classique, backend LDAP ou Sympa
Login X509 Authentification classique, backend LDAP ou Sympa WAYF

Auth.conf Décrit les services d’authentification
Décrit comment on choisit un service d’authentification lors du login. Pour chaque service, décrit comment obtenir l’ de la personne quand celle-ci est authentifiée avec un UID.

authentification LDAP
Si un service d’authentification LDAP est sélectionné : Bind anonymous, recherche LDAP pour collecter le user_id à partir du (si fourniture d’un ) Bind user_id+ password pour vérifier le passwd Bind anonymous pour collecter le avec le user_id (si non fourni par l’utilisateur)

Authentification LDAP
host ldap1.cru.fr:392,ldap2.cru.fr:392 timeout suffix dc=cru,dc=fr get_dn_by_uid_filter (uid=[sender]) get_dn_by_ (|(mail=[sender])(aliasmail=[sender])) alternative_ _attribute maildrop _attribute mail scope sub

Central Authentication Service
Yale university web Single Sign On Usage universitaire croissant Basé sur des redirections et un ticket qui doit être validé par le serveur CAS canal Uportal pour Sympa CAS est trop centralisé, cohabitation avec d’autres systèmes d’authentification difficile.

Sympa interaction with one CAS server
LDAP Welcome Search for ID=smith Client Sympa Who is he ? ticket=17429 Redirection ticket=17429 redirection. Is that user authenticated? CAS ID=smith

Interaction with a chosen CAS server
Welcome Client Sympa WAYF ? redirection. Is that user authenticated? User : ? Password ? yes ticket=17429 ID=smith CAS 2 Who is he ? ticket=17429

Interaction with multiple CAS servers
non blocking redirection. Is that user authenticated ? no Client Sympa Welcome yes ticket=17429 Non blocking redirection. Is that user authenticated? Who is he ? ticket=17429 CAS 2 ID=smith

Un serveur CAS est en panne ?
Novembre 2004 Un serveur CAS est en panne ? Toute redirection est sans issue La configuration de Sympa permet de choisir pour chaque serveur CAS si on essaye une redirection non bloquante. Surveiller disponibilité des serveurs CAS ? Direction non blocante

“CAS logout” ? Sympa mémorise la méthode d’authentification utilisée pour adapter le bouton logout Sympa efface son cookie de session et redirige l’utilisateur sur l’URL de logout CAS Insuffisant car CAS ne propose pas de service de logout centralisé

Generic SSO Pour tout SSO si
un module apache en frontal d’une partie des applications pour l’authentification délivre à cette application une authentification dans une variable d’environnement. Que cette authentification soit sous forme d’un ou d’un id permettant de trouver l’ dans un annuaire LDAP Exemple « authentification basic Apache », Shibboleth, PAPI Sympa reste utilisable en mode anonyme

Generic SSO / auth.conf Paragraphe generic_sso
service_name (nom du service d’authentification pour l’utilisateur) service_id ( pour contruire l’URL avec authentification _http_header variable d’environnement contenant le http_header_prefix prefix des variables d’environnement à concerver comme attribut de la personne (mise en cache dans la base) Si _http_header n’est pas défini : tous les paramètres pour get_ _by_uid idem CAS

cas base_url on_blocking_redirection off login_path /login service_validate_path /validate logout_path /logout auth_service_name CRU ldap_host ldap.cru.fr:392 ldap_get_ _by_uid_filter(&(uid=[uid])(objectClass=eduPerson)) ldap_timeout ldap_suffix dc=cru,dc=fr ldap_scope sub ldap_ _attribute mail ldap host ldap1.univ-nancy2.fr:392,ldap2.univ-nancy2.fr:392 timeout suffix dc=univ-nancy2,dc=fr get_dn_by_uid_filter (uid=[sender]) get_dn_by_ (|(mail=[sender])(aliasmail=[sender])) alternative_ _attribute maildrop _attribute mail scope user_table negative_regexp (univ\-nancy2)\.fr

TODO authentification
Novembre 2004 TODO authentification Supprimer le chiffrement réversible des mots de passe, ne stocker que l’empreinte des mots de passe. Plus de rappel de mot de passe, seulement une réinitialisation Formulaire de login en HTTPS (chiffrement du flux contenant le mot de passe) Bouton d’identification par certificat client par config dans les templates

Le contrôle d’accès En général les applications implémentent 2 notions, public / privé : Droit de s’abonner, de diffuser des messages,… Sympa permet d’exprimer des notions plus fines en testant le contexte : L’appartenance de l’utilisateur à un groupe Les attributs d’un message L’origine de la requête Le niveau d’authentification …

Gérer le contrôle d’accès
Séparation authentification/autorisation Définition de règles pour le contrôle d’accès : aux listes (subscribe, send, review, visibility,…) au service (création de liste, catégories de listes) Configurable pour chaque liste (+ défauts) Equivalence entre les 3 interfaces (mail, web, soap) Personnalisable grâce aux scénarios d’autorisation (100 scénarios distribués avec Sympa)

Les scénarios d’autorisation
Un scénario est évalué pour accorder/refuser l’accès à un service de Sympa : ainsi l’interface web est adapté au profil de l’utilisateur (seules les fonctions accessibles sont proposées) Un scénario est constitué d’un ensemble de règles ordonnées Une règle est composée de : la condition les méthodes d ’authentification l’action (décision) Le scénario comporte un titre décrivant son fonctionnement (utilisé lors du paramétrage de la liste)

Exemples de scénarios... Contexte : Fonctionnalité :
Diffusion des messages Fonctionnalité : Liste de discussion privée is_editor([list->name],[sender]) smtp,smime > do_it is_subscriber([list->name],[sender]) smtp,smime > do_it true() smtp,smime > reject

Diffusion des messages Fonctionnalité : Liste de discussion privée Confirmation pour les non abonnés is_editor([list->name],[sender]) smtp,smime > do_it is_subscriber([list->name],[sender]) smtp,smime > do_it true() smtp > request_auth true() md5,smime > do_it

Diffusion des messages Fonctionnalité : Liste de discussion privée Confirmation pour les non abonnés Modération des messages multipart is_editor([list->name],[sender]) smtp,md5,smime > do_it match([msg_header->Content-type],/multipart/) smtp,md5,smime -> editorkey is_subscriber([list->name],[sender]) smtp,smime > do_it true() smtp > request_auth true() md5,smime > do_it

Exemples de scénarios... Fonctionnalité : Contexte :
Accès aux archives web Fonctionnalité : Autoriser l’accès depuis l’intranet Autoriser l’accès pour les utilisateurs authentifiés ayant une adresse locale Autoriser l’accès pour les abonnés, depuis n’importe où is_editor([list->name],[sender]) smtp,md5,smime > do_it is_subscriber([list->name],[sender]) smtp,md5,smime > do_it match ([remote_host],/unicaen\.fr$/) md5,smime -> do_it match([sender],/unicaen\.fr$/) md5,smime -> do_it true() md5,smime > reject

Syntaxe des scénarios (1)
Les conditions : is_subscriber(),is_owner(),is_editor(),is_listmaster() equal(), match(), search() true() Les variables : [sender], [user->attr], [subscriber->attr], [user_attributes->attr] [list->param], [conf->param] [remote_host], [remote_addr], [env->var] [msg_header->field], [msg_body],[msg_part->type], [msg_part->body], [msg_encrypted], [is_bcc] |

Syntaxe des scénarios (2)
Les méthodes d’authentification : smtp md5 smime pgp (bientot) Les actions : do_it [,notify | quiet], reject(<tpl_name>) request_auth, owner, editor, editorkey, listmaster

Services utilisant les scénarios
Diffusion des messages Abonnement Désabonnement Ajout d’abonnés Suppression d’abonnés Accès à un document Edition d’un document Lister les abonnés Accès aux archives Visibilité d’une liste Accès aux information sur la liste Création d’une liste Visibilité d’une catégorie …

Exemple de scénario exploitant l’annuaire LDAP
Contexte : Droit de s’abonner à la liste étudiante feministe-l Fonctionnalité : Limité l’abonnement en fonction d’un attribut LDAP de l’utilisateur filter (‘female_students.ldap’,,[sender]) smtp,md5,smime > do_it true() smtp,md5,smime > owner # female_students.ldap host ldap.utexas.edu:389, ldap2..utexas.edu:389 suffix dc=utexas,dc=edu filter &((EduPersonAffiliation = student)(mail = [sender]) (EduPersonGender = female)) scope sub

Les scénarios Exemple d’organisation
Montrer l’organisation des fichiers /home/sympa/bin/etc/scenari/ access_web_archive.closed access_web_archive.intranet … /home/sympa/etc/scenari/ include.send.header send.intranet:ignore topics_visibility.cru /home/sympa/etc/demo.sympa.org/scenari/ include.subscribe.header /home/sympa/etc/family/mafamille/scenari/ /home/sympa/expl/cru.fr/sympa-users/scenari send.private_nofrench

Scénarios / Personnalisation
Se baser sur les scénarios existants (/home/sympa/bin/scenari/) Installer le nouveau scénario au niveau du site, du robot ou de la liste Prise en compte d’une modification sur un scénario : touch /home/sympa/expl/maliste/config Inclusion include.action.header Pour ignorer un scénario de la distribution : touch /home/sympa/etc/scenari/send.public:ignore

Intégration avec LDAP 3 niveaux d’intégration en fonction des besoins : Filtres LDAP : permettent de personnaliser un scénario Définition dynamiques des membres et/ou des propriétaires d’une liste Définition d’une famille de liste à partir de l’annuaire LDAP Authentification basée sur LDAP

L’architecture Shibboleth
Développé par Internet2 « Colle » entre des services de Single Sign-On locaux pour permettre de partager des ressources entre Universités Les 3 composants de l’architecture Shibboleth : Identity Provider : installé dans l’organisation d’origine de l’utilisateur ; en frontal devant le service d’authentification et la base utilisateurs Service Provider : installé devant la ressource web à protéger ; communique avec l’Identity Provider WAYF (Where Are You From) : le composant central de l’architecture, partagé par plusieurs institutions ; il guide l’utilisateur jusqu’à son Identity Provider

Shibboleth et Sympa Besoins / Prérequis
Construire des listes de diffusion inter-universitaires Donner accès à une liste en fonction d’attributs utilisateurs (gérés par son établissement) Pas de gestion de comptes utilisateurs sur le serveur de listes Prérequis pour chaque organisme : Avoir un service d’authentification Installer la partie Identity Provider de Shibboleth Partager une nomenclature commune des attributs utilisateurs (formations, catégorie de personnels,…)

Interaction entre Sympa et Shibboleth
WWSympa délègue l’authentification à Shibboleth Sympa est une ressource protégée par la brique Service Provider de Shibboleth Shibboleth fournit des attributs utilisateurs à Sympa (adresse requise) Sympa exploite les attributs Shibboleth pour : Personnaliser l’interface web Adapter les privilèges utilisateur

Sympa Shibboleth Attribute Authority Handle Service Identity Provider
Zone publique identité attributs Ressource Manager login Attributs utilisateur WAYF Zone à Accès restreint SHAR SHIRE Service Provider

Configuration # Sympa configuration (auth.conf) generic_sso
service_name InQueue Federation service_id inqueue http_header_prefix HTTP_SHIB _http_header HTTP_SHIB_EP_AFFILIATION # Apache configuration <Location /wws/sso_login/inqueue> AuthType shibboleth require affiliation ~ </Location>

Contrôle d’accès basé sur des attributs Shibboleth
Attributs utilisateur Shibboleth : Hérités via des variables d’environnement Stoqués comme des données de session dans la base de Sympa (champ user_attribute) Accessible depuis les scenarios Scenario sample rule: # check if the user is a geology or archeology student equal([user_attributes->SHIB_STUDY_BRANCH],’geology’) md5 -> do_it equal([user_attributes->SHIB_STUDY_BRANCH],’archeology’) md5 -> do_it true() smtp,md5,smime -> reject

Données personelles/archives
Spammers use spam harvester Googling (googliation) is a peril Sympa solution : Sympa hides s using javascript (google indexation is possible) or by a form (all automatic process blocked in archives) X-No-Archive header feld Users can delete there own posts from archives

Protection des données personelles
Mise en œuvre de la tracabilité des abonnements (demande de l’afnic S.Bortzmeyer) Objectif prouver l’OPT IN ou expliquer le OPT OUT Conserver les messages et les éléments d’authentification pour chaque abonnement

Listes de diffusion classiques
Novembre 2004 Listes de diffusion classiques ADD, DEL, SUB, UNSUBSCRIBE Taches administratives dupliquées pour maintenir la cohérence avec un référentiel Utilisation des listes comme un outil de gestion de groupes Abonnement de listes dans des listes (sous-listes) (

Listes dynamiques Définition des listes d’abonnés directement via des sources de données quelconques du système d‘information : fichiers locaux autres listes locales requêtes sql filtres LDAP autres listes d’un autre serveur diffusion (remote_lists en désuétude) URL (cgi !)

Dynamic mailing list LDAP TTL task_manager.pl SGBD Internal database
fichiers bounced.pl sympa.pl wwsympa.fcgi

Include LDAP include_ldap_query host ldap.cru.fr,replica.cru.fr:387
suffix dc=cru, dc=fr timeout 10 filter (&(student=math) (dc=fr)) attrs mail select first

Include LDAP (contrib from Dalbec ysu.edu)
include_ldap_2level_query host ldap.univ.fr suffix1 ou=Groups,dc=univ,dc=fr scope1 one filter1 (&(objectClass=groupOfUniqueNames) (| (cn=cri)) attrs1 uniquemember select1 all First LDAP query to select a group suffix2 [attrs1] scope2 base filter2 (objectClass=n2pers) attrs2 mail select2 first For each group member fetch his adress

Listes dynamiques / perf
Importance de l’objectif de performances Aucune page délivrée par wwsympa.fcgi sans évaluer toutes les listes (même lists ou help) Ldap_2_level_query impose une requête LDAP par abonné (des milliers) Cache en base de donnée Gestion de la vie du cache : TTL Mise à jour asynchrone task_manager.pl

Uniquement avec include2
Listes panachées ADD,DEL + include Include2 mode gestion par défaut Gestion des bounces Options d’abonnement (nomail très utile) Gestionnaire de groupes ? En lecture seulement Interrogation en SOAP (is_subscribers, review)

demo Overview of list admin page
List configuration overview (data_source) review

Listes dynamiques Définition des owners et editor de listes selon la même méthode. Idée : abonnés = étudiants de maths editor = enseignants de math owner = responsable de la formation math Destiné à la gestion de listes par paquets Disponible dans la version 5.0

Pourquoi le concept de famille?
On observe l’usage de script maison pour la création des listes Exemple tamu.edu : listes Comment gérer les très grands nombres de listes de diffusion correspondants à des catégories de personnes ?

Pourquoi le concept de famille
Dans le schéma initial, la création d’une liste on choisi un type de liste Le type de liste fait référence à un gabarit de config. (create_list_template/config.tt2) Cette info n’est pas conservée. Rien ne permet de s’assurer que la liste créée restera conforme au type de liste choisi.

Pourquoi le concept des familles
Dans le cas de création de liste avec des scripts, il est impossible de gérer les ensembles de listes après leur création. Le changement d’un détail dans la config du paquet de liste oblige à régénérer toutes les listes et écrase les personnalisations éventuelles de chaque liste. On identifie pas les listes qui doivent disparaître Il faut un outil de gestion de familles de listes.

List families (Version 5)
Les familles permettent la création et la gestion d’un très grand nombre de listes conformément à une politique La configuration d’une liste est complexe (une 50taine de paramètres) Les familles de listes simplifient la création en permettant de choisir un mode de fonctionnement sans entrer dans le détail du paramétrage

Lists families in Sympa
Family definition List template param_constraint edit_list Family instantiation List a List A <family> <list>….</list> </family> skeleton of configuration file Use var that are defined in XML file required constraint for each parameter (example review is private or owner) For each parameter, defines who can edit it :(listmaster,privilegied owner or owner) Data coming from information system. XML format

Family definition List template param_constraint edit_list Family instantiation <form> <input type=..>… </form> List A Sympa.pl –instantiate_family=ftest –input_file=data.xml Data coming from web form

XML data and list template
Jeu de données <?xml version="1.0" ?> <family> <list> <listname>networking.ipv6</listname> <family>my_profile</family> <section>computer_science<section> <option>networking</option> </list> <listname>…</listname> <section>…</section> … </family> config.tt2 subject students of [section]/[option] title all students from department [section], course [option] web_archive private include_ldap_query Host ldap.foo.edu:389,backup.foo.edu suffix dc=foo, dc=edu filter(&(section=[section])(option=[option])) attrs mail owner_include Include_ldap_query …..

Qui modifie quoi dans la config ?
Roles : owner, privileged owner, listmaster Le owner de la liste a besoin de contrôler de nombreux paramètres de sa liste Le listmaster a besoin d’un contrôle sur le fonctionnement de chaque famille de liste de chaque robot : Ex :taille max d’un message d’une newsletter Ex :Le créateur initial de la liste ne peut en abandonner la responsabilité ….

edit_list.conf user_data_source owner,privileged_owner hidden
ttl owner,privileged_owner hidden shared_doc owner,privileged_owner write review owner read review privileged_owner write footer_type owner,privileged_owner hidden owner owner read owner.profile owner,privileged_owner read owner privileged_owner write default listmaster write

param_constraint.conf Enumération des valeures autorisées pour une famille donnée # very simple example # parameter edition control send private_smime, editor_key web_archive private,owner shared_doc.d_read private,owner Shared_doc.d_edit owner

Edition en ligne de la config
Formulaire d’édition auto-adaptatif : les rôles de la personne identifiée edit_list.conf param_constraint.conf (ordonné et coupé en plusieurs pages par paramètres interne au code)

Evolution d’une famille
Le changement du jeu de données, du template ou de param_constraint entraîne la régénération des listes de la famille Certaines listes peuvent disparaître Sympa conserve les personnalisations faites via le web si elles sont compatibles avec param_constraint.conf

Dispo en version 5.0 Redéfinition des familles à chaque niveau robot site distribution. Familles de listes = expression technique d’une politique de listes + création de listes par paquet

Les templates Dans Sympa, les templates permettent de séparer l’interface utilisateur du code Les templates sont utilisés pour définir : l’interface web les messages de service les modèles de listes les alias de messagerie Tous les templates sont personnalisables à différents niveaux : site / robot / famille / liste

Les templates / format Jusqu’à la version 4.1.2, les templates utilisaient un format « propriétaire » (fichiers .tpl) Les versions à venir utilisent le format TT2 ( format proche des .tpl migration automatique des .tpl en .tt2 Separation du HTML et des traductions plus de divergence du nombre de templates (auparavant un jeu par langue)

Les templates / organisation
Les messages de service (mail_tt2/) : 34 templates (message de bienvenue, fichier d’aide, compilation des messages,…) Les templates web (web_tt2/) : 67 templates : main.tt2 + bandeaux + templates d’action Multi-linguisme : [%|loc%]Chaine à traduire[%END%] web_tt2/fr_FR/info.tt2

Le format TT2 (voir http://www.tt2.org)
Substitution de variables : [% var %] ou [% struct.var %] Inclusions : [% INSERT fichier %] ou [% PROCESS fic.tt2 %] Conditions : [% IF var1 %]…[% ELSIF var2 %]…[%END%] Boucles : [% FOREACH var IN liste %] …[% END %] Des filtres : [% FILTER qencode %] Entête à encoder[%END%]

Exemple de message de service global_remind.tt2
Summary of your subscription (using the [% user. %]). If you want to unsubscribe from some list, please save this mail. Foreach list here is a mailto to use if you want to unsubscribe. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= [% FOREACH l = lists %] [% l %] mailto:[% conf.sympa %]?subject=sig%20[% l %]%20[% user. %] [% END %] [% IF user.password %] In order to authenticate on the web interface([% conf.wwsympa %]) use your [% user. %] and your password [% user.password %]

Exemple de template web list_menu.tt2
………. [% IF is_editor %] [% IF mod_total == '0' %] No message to moderate [% ELSE %] Messages to moderate :<B> [% mod_total %]</B> [% END %] [% IF shared == 'exist' %] <BR><BR> [% IF mod_total_shared == '0' %] No document to moderate <B>Documents to moderate :<B> [% mod_total_shared %]</B>

Les templates / variables disponibles
Pas (encore) de documentation exhaustive Se baser sur les templates distribués par défaut

SOAP en bref… « Web services » = SOAP SOAP = XML sur HTTP
Appel procédural distant (alternative à XML-RPC, RMI) Indépendant du language de programmation Librairies disponibles : SOAP::Lite (Perl), Axis (Java), NuSOAP (PHP),…

Interface SOAP pour Sympa
Permet d’utiliser les services de Sympa depuis une autre application Alternative à l’accès direct aux données de Sympa, préférable car : Le format des données peut évoluer L’authentification et le contrôle d’accès sont préservés L’interface est principalement utilisée pour inclure un canal Sympa dans Uportal

SOAP dans Sympa Un nouveau FastCGI : sympa_soap_server.fcgi
Accédé via Apache (versus standalone) Utilise la bibliothèque SOAP::Lite Description des services au format WSDL Utilisation des cookies HTTP pour maintenir la session (pb avec PHP)

Configuration du service SOAP
## extrait de httpd.conf FastCgiServer /home/sympa/bin/sympa_soap_server.fcgi -processes 1 ScriptAlias /sympasoap /home/sympa/bin/sympa_soap_server.fcgi <Location /sympasoap> SetHandler fastcgi-script </Location> ## sympa.conf / robot.conf soap_url

Les services proposés Pour l’instant les fonctionnalités sont limitées :login, which, lists, subscribe, signoff, review Extensions envisagées (si utiles) : archives, création de liste, add, del,… Authentification par mot de passe ou par “ticket” (fonctionnalité “proxy” de CAS) Evolution possible vers SAML…

Exemple de client PHP (http://demo.sympa.org/sampleClient.php)
include('/home/sympa/bin/nusoap.php'); require_once('nusoap.php'); $soapclient->debug_flag=true; global $soapServer; $soapServer = " $soapclient = new soapclient($soapServer,'wsdl'); … $res = $soapclient->call('authenticateAndRun',array($user ,$md5, 'subscribe', array($_GET['list']))); if (gettype($res) == 'array') { echo "<P ALIGN=\"center\"><FONT COLOR=\"#ff0000\">Subscription failed<BR>".$res['faultstring']." : ".$res['detail']."</FONT></P>\n"; }else { echo "<P ALIGN=\"center\"><FONT COLOR=\"#99ccff\">Successfully subscribed</FONT></P>\n"; }

Un canal Sympa dans Uportal
Utilisation de AXIS Génération automatique d’un squelette (stub) à partir du WSDL : java org.apache.axis.wsdl.WSDL2Java -av Exemple de code client : SympaSOAP loc = new SympaSOAPLocator(); ((SympaSOAPLocator)loc).setMaintainSession(true); SympaPort tmp = loc.getSympaPort(); String _value = tmp.casLogin(_ticket); String _cookie = tmp.checkCookie(); String[] _abonnements = tmp.which();

Résolution de problèmes Généralités
Analyser les logs de Sympa, de Apache, de Sendmail, de mysql, de OpenLDAP,… Tous les processus sont-ils lancés ? /etc/rc.d/init.d/sympa status Démarrer sympa.pl en mode debug (-d) ou augmenter le ‘log_level’ (sympa.conf) Vérifier les droits d’accès sur les fichiers, les répertoires

Problème de réception des messages
Les alias sont-ils correctement installés Utilisez-vous smrsh ? Les messages sont-ils déposés dans le spool de Sympa (spool/msg/) ? Sympa.pl est-il lancé ? Option --keepcopy

Pas de gestion automatique des alias
Si vous n’utilisez pas sendmail, il faudra faire du « tuning » (voir FAQ)… Vérifiez le bit ‘SetUID’ sur aliaswrapper Le fichier sympa_aliases a-t-il les bons accès ? Le fichier sympa_aliases est-il connu de sendmail ? Les options de configure : --with-sendmail_aliases --with-newaliases --with-newaliases_arg

Je n’ai pas de logs… Avez-vous paramétré /etc/syslog.conf ?
Redémarrer syslogd. Modifiez le paramètre log_socket_type. "_PATH_LOG not found in syslog.ph“ Sous Solaris ‘.*' n’est pas reconnu dans syslog.conf

Robot virtuel non reconnu
Vérifiez les paramètres ‘host’ et ‘http_host’ dans robot.conf Vérifiez que le paramètre passé à queue depuis les alias de messagerie est qualifié avec le bon nom de domaine

Problèmes LDAP Avez-vous installé le module perl-ldap ?
Par défaut OpenLDAP limite la réponse à une requête à 500 enregistrements

Problème d’accès aux archives
Vous accédez à l’interface web via un Proxy ? WWSympa doit s’exécuter sous l’identité ‘sympa’. Si le HTML est incorrect, essayez de reconstruire les archives (depuis « Admin Sympa ») Vous pouvez personnaliser le fichier mhonarc-ressources

TODO Ce chapitre est conçu pour votre information et pour tester vos réactions de plus en plus copieux préparation de la 5.0 Alpha (Décembre) Objectif 5.0 stable 1er trimestre 2005

La 5.0 tt2 Shared : Définition par include de owner et editor
modération des documents upload .zip vision admin / vision sans privilège Définition par include de owner et editor Include source distante via URL Familles Canaux RSS

Vers la version 6 Relooker les pages web Abonnement thématique
Prise en compte complète des alt_ Composeur de messages MIME Aide à la modération Gestionnaire d’enquête Visibilité des journaux de chaque liste Editeur de topics Abonnement multiple

Vers la version 6 Le « bulk mailer » : multithread
casser le groupage : verp / parsing du message distribution spécifique pour les abonnés en erreur (en fin de queue, verp et spool direct) nrcpt.conf points de reprise multithread mailsig (technique de signatuer anti-spam) PGP et PGP / S/MIME

Vers la version 6 Une couche attribut formalisée
Homonymie des listes et robot virtuel Extention des services soap Portail multi-serveur (client soap dans wwsympa.fcgi) Remonté des résultats d’un scenario Red hat Terminer le merge sympa et wwsympa

Administration d’un service de listes de diffusion avec

Présentations similaires

Présentation au sujet: "Administration d’un service de listes de diffusion avec"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Administration d’un service de listes de diffusion avec

Présentations similaires

Présentation au sujet: "Administration d’un service de listes de diffusion avec"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back