* prilb * session à part pour chaque wapp * rewrite cookie path * recenser adresses apotest (et apoprod) * mettre à jour les adresses apotest * faire TODO pour la rentrée * migrer dans oratools les outils appropriés de oracletools (otprepare-java-alternatives, rdbms-admin, etc...) * migrer dans apotools les outils appropriés de oracletools (update-uiprint4cups)

url, branch et destdir sont des variables after_cmds est un ensemble de commandes à lancer après update (genre synchro de proj.../sqlmig/ vers mariadb/) options --nu/--no-update pour ne pas faire la maj avant build pour fast2, prilb, faire composer install dans un container, avec montage du répertoire local de cache -- si docker-machine est activé vers une machine distante, alors le répertoire local de cache est dans /var/tmp

éventuellement: faire un hash des données source. si différent, alors il y a eu des modifications concurrentes et il faut afficher un avertissement

par exemple, la clé data.apps.my.key pourrait si elle n'est pas définie lue dans la variable d'environnement CONFIG_DATA_APPS_my_key

- sqlmig pour ur/mariadb: - le répertoire est le nom de la base de données sur laquelle appliquer la mise à jour [OK] - support des fichiers CSV: le fichier est traduit au vol, sauf s'il existe un fichier sql avec le même nom de base [OK] - générer le fichier .sql au vol à partir du fichier .csv et de certains paramètres - maj version java pour ur/java [OK] - strucol-app pour modification table en ligne [OK] - support nulib dans d9min [OK] --> création d9lite - remplacer gogs par gitea, pour le support git-lfs [OK] - gogs vers base locale [OK] --> migrer les données - nexus sur le chemin /nexus [NON] --> repos ne sert que pour nexus - service pgit.univ-reunion.fr via repos.univ-reunion.fr/pgit et git.univ-reunion.fr via repos.univ-reunion.fr/git [NON] --> l'accès en https ne se fait plus que par gogs. on garde l'accès via ssh et en http anonyme - renommer d9base en d9dev et d9lite en d9base [NON]

[-+]5.23 --> chrono qui commence à 5:23 5.23 --> minuteur qui va de 5:23 à zéro

ou alors un service mariadb avec les containers db et utils dans le container utils: - backup - restore - copie prod --> test - sqlmig pour mettre à jour la configuration automatiquement (non, géré par l'application) - scripts de maintenance (non, géré par l'application) - connect peut-être en faire un container à part, pour permettre de gérer plusieurs instances? -- non chaque base de données est self-contained

support aussi de APP_DOMAIN

ajouter un log des connexions

ajouter l'opérateur "in" $array (il faut tester d'abord si on peut binder sur les éléments d'un tableau e.g. col in (:a, :b, :c) ajouter les opérateurs "[is ]null", "[is ]not null" ça évite de devoir accéder à des variables globales $NULL et $NOT_NULL si on sait que la valeur doit être nulle ou non nulle

si pfs constate que le profil demandé n'existe pas, il demande à partir de quel profil le nouveau profil doit être créé (Common ou Base par défaut) pour un autre profil que Common|Base, cela consiste à copier les fichiers du profil spécifié pour faire le nouveau profil.

- demande de relevé de notes: pas visible (?) - type de diplôme pour DU? - calculer le domaine lors de la création de la demande

vérifier si le bug existe aussi pour transdep!

possibilité de "protéger" un dossier local qui n'est jamais supprimé en cas de mise à jour actuellement, avec PROTECTS, ces fichiers ne sont pas supprimés en mode full, mais ils sont écrasés s'ils sont livrés par l'upstream vérifier que PROTECTS peut concerner un répertoire...

les comptes peuvent être créés pour des organisations: UR, LMDE, Vittavi ils peuvent être nominatifs ou génériques (genre vacataire) on les localise aussi, et on leur donne des droits en terme de localisation, gère-t-on aussi les centres de gestion, les composantes, etc? cette application permet ensuite de récupérer des informations d'ACLs à mettre en session pour PHP par exemple. les informations peuvent être aussi fournies en pickle python. l'accès est protégé par token, qui est géré par cette application aussi les infos d'acls sont placés en session lors de la connexion. un décorateur permet de vérifier ces informations on prend des informations supplémentaires d'APOGEE pour compléter les informations sur un compte

- peut-on aussi gérer keepalived? - possibilité de forcer le flux vers un backend en particulier, afin de faire de la maintenance sur un autre backend

on définit: profils (prod, test, devel), groupes, utilisateurs ensuite on définit: * domaines (APOGEE, HARPEGE, etc.) --> section|action * sections (applications regroupées par thème) --> application|action * applications --> action * actions à chacune de ces entités est associée une permission implicite on attribue les permissions à * profil * groupe * utilisateur * (utilisateur, profil) (éventuellement supporter d'enlever des permissions) ces informations sont utilisées pour générer, pour un utilisateur, une arborescence qui est utilisée pour afficher un menu. c'est à sa connexion qu'un utilisateur récupère l'arborescence des actions auxquels il a droit (cette information est mise en cache dans une base de données locale). les domaines, sections, applications correspondent à des éléments de l'UI: ils ont un titre, une description, une URL associée les actions sont simplement des droits accordés, mais il est de la responsabilité de l'application qui la reçoit d'exploiter cette information. pour l'UI, on peut peut-être récupérer une version statique du menu, qui est inclue dans chaque page, étant donné que c'est une description des applications auxquelles a droit l'utilisateur. le menu local est géré/affiché à gauche de l'écran, ou éventuellement inclu dans le menu général: genre pour la page d'accueil on a un menu [MON APP][AUTRES MENUS] et si on est dans des sous-pages alors le contenu de [MON APP] est déployé

faire pareil pour un template de page cela simplifiera la customization faire aussi classes Row et RowCtl class BatchCtl(RowCtl): CLASS = Batch def list(self): return self.query("select * ...") généraliser Row en LazyObject, qui génère l'objet final à la demande class LazyObject(object): _object = None # objet final def __init__(self): pass def _resolve(self): pass # à dériver si _object est construit dynamiquement def __resolve(self): if self._object is None: self._object = self._resolve() return self._object def __getattr__(self, name): return getattr(self.__resolve(), name) ...

* autorisation d'accès par utilisateur et par groupe * requête SQL + paramètres * description des paramètres * description des champs à afficher

- augmenter la durée du timeout à 15 minutes (sur apoprod2017, ça prend pas mal de temps à démarrer) - poser un verrou pour interdire plusieurs invocations simultanées. afficher un message du genre "une opération est déjà en cours: démarrage de ..." - possibilité de voir les logs de l'arrêt et du démarrage? est-il possible de configurer systemd dans ce sens? - faire un support natif de local-services pour systemd

en profiter pour faire les pages d'accueil de la DSI, DSVE, etc. pour qu'on puisse les mettre en raccourcis

* possibilité de faire uniquement déploiement de resource web * si on spécifie -h ou -w, ne pas interroger la configuration locale de déploiement * quand on spécifie -h et -w, il semble que l'archive temporaire a disparu, ce qui provoque une erreur avec -w

ces définitions locales sont en plus de la définition globale dans ~/etc/deploy/deploy.conf de plus, si on interroge la base pour un module, et que ce module contient des définitions locales, il faudrait les charger... bien sûr ça n'a de sens que si la base contient le chemin vers le module en question [est-ce que ça a du sens?) on peut aussi considérer que c'est dans l'autre sens: uinst par exemple veut déployer un module, et fournit à deploydb le chemin local en plus de la définition globale

l'application met à jour un fichier au format connu, puis appelle un script tierce qui génère les fichiers destination et relance apache le cas échéant le script doit être sudoer et se relance automatiquement avec sudo -n

- maj doc LdapGear: les profils sont stackables. par exemple on aurait des profils de base correspondant à des serveurs (genre ldap, ldapm) puis des profils (avec le flag overlay) qui se rajoutent pas dessus et qui permettent de mettre à jour certaines données, ie people, groups, etc. avec certains paramétrages ie default, bijective, delete, etc. [à déterminer] on peut ensuite spécifier le profil effectif comme une combinaisons de ces profils individuels e.g ldap+people+update-only - maj rdv17: faire un paramétrage "DYNAMIC"=TRUE|FALSE qui fait afficher la page depuis la base de données ou affiche le résultat statique qui a été pré-généré. en production, forcer l'affichage statique - faire une configuration "générale" pour les services numériques: sn17-config.php au lieu de rdv17-config.php ? (ou en plus de ...) - sur apofrontal, ajouter les profils dsve, correspondant et utilisateurs à ces 3 groupes [FAIT]

- bases qui tournent - batches activé/désactivé - listener activé/désactivé - batches en cours d'exécution

à merger avec le support du dépôt central

bug dans awkcsv? ==> awkcsv n'affiche rien s'il n'y a pas de données... il faudrait corriger ça, mais ça risque de poser des problèmes de compatibilité ==> le plus sûr pour la compatibilité, c'est de rajouter print_headers() dans END{} si -a n'est pas spécifié. de plus, ajouter une option pour ajouter print_headers dans END{}

- mpm_event + phpfm + proxy_fcgi - créer le dépôt ssi-webfrontal - configurer gitolite-contrib pour supporter le match inverse: les machines "baseN" peuvent accéder aux dépôts "base" - keepalived

group webapp default tomcat -p test,dev host=aposndev4 group webapp auto webapp primoweb=iaprimo-web tomcat host=primo tomcat -p dev host=- dans cet exemple, il n'y a pas de profil dev pour primoweb. voici une alternative: group webapp auto webapp primoweb=iaprimo-web tomcat host=primo tomcat -x dev -x comme "--exclude" OU ALORS, il faudrait que les profils soient définis par deploiement dans l'exemple suivant: group webapp default tomcat -p test host=aposndev4 group webapp auto webapp primoweb=iaprimo-web tomcat host=primo tomcat -p dev host=aposndev4 le profil test est définit pour tous les déploiement, alors que les profils prod et dev ne sont définis que pour primoweb

soit les mettre systématiquement, soit vérifier que l'on utilise la bonne méthode!

ce dépôt est agnostique, c'est une base de données de la destination de certains artifacts suggestion de l'emplacement du dépôt => pgit@vcs.univ.run:deploy le fichier de conf pourrait être un DSL pour faciliter l'écriture des règles support de ruinst, rwoinst, tomcat (pour les service numériques apogee), maven etc. par exemple, 'ruinst module' consultera cette base de données pour savoir où il faut le déployer par défaut ce dépôt fourni un script permettant d'interroger la base de données. par exemple, la commande précédente interroge deployq -q hosts -F lines|shell|path|comma -t uinst -d path/to/module -n module et le résultat serait: -F lines: un hôte par ligne h1 h2 -F shell: hosts=(h1 h2) -F path: h1:h2 -F comma: h1,h2 -F space: h1 h2 le format est shell par défaut. le nom de la variable est celui de l'information qui est demandée les chemins -d sont absolus ou exprimés relativement à un ensemble de chemins ARTIFACTPATH réfléchir à ce qu'on peut avoir comme organisation pour supporter les services numériques apogee, les woinst (bundles et resources web) exemple: $ deployq -q bundle_hosts,webres_hosts -F shell -t woinst -n MonCompte.woa handles=(wh) bundle_hosts=(woapp1.univ.run) webres_hosts=(wh) wh_vars=(host dest) wh_host=ssi-webfrontal1.univ.run wh_dest=HTDOCSBASE/dmzworedir on voit ici la nécessité(?) d'offrir la possibilité d'utiliser des handles. wh est identifié comme étant un handle avec le tableau handles ici, wh a plusieurs valeurs associées: host et dest

on pourrait l'appeler stlb-script par défaut, il lance son argument avec le chemin vers un répertoire temporaire dans lequel le script doit placer les fichiers à sauvegarder stlb-script -b /path/to /path/to/myscript --> lance /path/to/myscript /path/to/tmpdir --> enregistre le résultat dans script-timestamp-myscript.tar.gz sans l'option -b, le fichier serait nommé script-timestamp-path--to--myscript.tar.gz des options permettent de spécifier un fichier destination, ou même d'enregistrer la sortie standard du script

dans un premier temps, faire un script mensuel qui liste les départs des personnels de l'établissement

~~~ Laurent Le script gérant les mises à jour de Sifac (récupération des OT et des annexes) semble ne pas récupérer la bonne note de livraison (fichier xls). Il serait souhaitable de corriger ce script pour les prochains OT. ~~~ ~~~ Jephté le problème est que le nom du fichier généré par l'amue change de temps en temps sans explication : - par ex, maintenant le nom du fichier est "annexe" et avant c'était "Annexe" - il y a aussi l'heure qui change de temps en temps. on ne pourra jamais traiter tous les cas, donc à mon avis, ça sert à rien de changer le script. en cas de pb, il suffit juste de récupérer le fichier annexe et de changer son nom et c'est ok. ~~~

ceci peut-être implémentée en notant la date de validité des données actuelles si on demande un export incrémental des données situées après cette date, alors appliquer une heuristique pour ne rien renvoyer ce n'est peut-être pas suffisant. faut-il aussi dater chaque enregistrement?

exemples - problème MDB_ENV_FULL --> redémarrer a permis de résoudre le problème

exemple: maj du niveau des logs, certificats installés, etc. possibilité éventuelle de faire des modifications offline: export de cn=config avec slapcat, modif, import avec slapadd

vérifier pourquoi en mode complet les personne qui n'ont plus d'affectation sont synchronisées même si elles n'existent pas dans LDAP

rajouter aussi l'info sur le relevé de compte, etc. rajouter aussi les noms des frères qui font la vérification

exemple: si on a .../%h/... et qu'on demande host=mysql1 alors prendre .../mysql1/... et .../mysql/...

si ATTR==. alors c'est le premier attribut mentionné qui match cela permet de faire des choses comme: k userpassword // av . newPASS // r l'avantage est que le nom de l'attribut affiché est celui qui est dans le flux, puisqu'on doit garder le nom de l'attribut qui est matché. eg pour le flux dn: uid=x,dc=fr ATTR: value et la directive av attr newvalue le résultat sera dn: uid=x,dc=fr ATTR: value ATTR: newvalue et non dn: uid=x,dc=fr ATTR: value attr: newvalue le désavantage, à documenter, c'est que ça ne marche pas si l'attribut n'est pas mentionné dans le flux donc pour la directive av ça cause des problèmes: on ne peut ajouter que si des valeurs existent déjà indiquer clairement les directives pour lesquelles c'est utile et pour lesquelles c'est dangereux

... faire un DSL .pydeps qui permet d'exprimer les dépendances en python pub=addr("pub.univ-reunion.fr", "194.195.123.74") priv=addr("priv.univ.run", "10.82.70.123") nat(pub, priv, 80, 443) etudiant=actor() uses(actor, priv) ou orienté objet actor().uses(priv) les méthodes mysql(), ... sont créées dynamiquement require(), uses(), ...

* runsmod a un concept de "repodir" (ou clonedir) qui permet de spécifier où il faut faire le pull/push, et un lien est fait dans ~/runs * support de %n * si un serveur n'est pas accessible, ne pas écraser le fichier .lst * ajouter une option qui calcule les chemins RUNS{SCRIPTS,MODULES,HOSTS}PATH

c'est requis pour un poste de développement

ajouter le tag %n qui correspond à n'importe quel numéro qu'on peut enlever. cela permet de faire des configuration génériques pour des groupes d'hôtes. exemple: on veut avoir la configuration pour les hôtes de la forme gdrsilbN où N est un nombre. on définit l'url de la forme generic/%h%n/%m ainsi, sur les hôtes gdrsilb1 et gdrsilb2, on récupèrerai les modules generic/gdrsilb/modules comme on le voit, %n a une sémantique particulière: c'est un pattern que l'on *enlève* au nom d'hôte pour faire la correspondance. comme %n ne marche à priori qu'avec un nom d'hôte, faut-il considérer que %n tout seul est équivalent à %h%n ? --> je pense que oui.

ajouter l'option -m pour charger un module, qui implémente des fonctions supplémentaires

pour l'installation de gdrsilb* et des hôtes destination, il faudrait un dépôt avec dans runs/ le script pour installer keepalived+ipvsadm, et le script pour configurer le réseau ensuite il faut un répertoire hosts/ qui contient pour chaque hôte la recette pour installer ce qu'il faut

initscript qui utilise start-stop-daemon pour le lancer initdefault qui contient la configuration par défaut, lire d'abord slapd_trigger.rules dans le répertoire du script puis dans /etc/ldap faire un script setup.py qui installe slapd_trigger dans /usr/local/bin et slapd_trigger.rules dans /etc/ldap

exemple: $ ldapctl new -b ou=people uid=toto dn: uid=toto,ou=people,dc=univ-reunion,dc=fr uid: toto la branche par défaut est prise du paramètre searchbase une configuration permettrait de définir pour certaines branches les objectClass par défaut se base sur ldapctl schema pour savoir quels sont les attributs requis et les inclue dans la sortie Par exemple, si la configuration spécifie que l'on doit créer des objets de type runUnivAccount dans ou=cas,dc=univ-reunion,dc=fr et que searchbase="ou=cas", alors on a: $ ldapctl new uid=toto dn: uid=toto,ou=cas,dc=univ-reunion,dc=fr objectClass: runUnivAccount uid: toto userPassword: voici un autre exemple: $ ldapctl new uid=toto // sv userPassword pass dn: uid=toto,ou=cas,dc=univ-reunion,dc=fr objectClass: runUnivAccount uid: toto userPassword: pass

- par sujet - saisie des activités du jour cela permettrait de suivre la lecture de la bible et le culte dans un premier temps, prendre une feuille partagée sur google

- pour les fichiers qui contiennent des paramètres, afficher la différence en cas de mise à jour - faire une doc pour utiliser cette librairie

- quel est cet hôte? - la configuration a-t-elle été sauvegardée dans runs

cela permet, pour slapd2.4conf, d'intégrer les modifications dans les scripts, mais de pouvoir les afficher à la demande exemple: LDAPCTL_DUMP=- slapd2.4conf -f update150621 avec update150621 qui aurait quelque chose du genre: slapctl ai <<EOF ... EOF slapctl aa <<EOF ... EOF

HEAD semble alors pointer sur un blob, pas un commit, et le fichier résultat est complètement mélangé (il semble que c'est une version précédente du fichier)

Scope: local, remote, etc.

values=(first second third) qvals values -p -a # ou qvals_prefix values -a --> -a first -a second -a third qvals values -s -a # ou qvals_suffix values -a --> first -a second -a third -a values=(first second third) array_before values -a # values vaut maintenant (-a first -a second -a third) values=(first second third) array_after values -a # values vaut maintenant (first -a second -a third -a)

la fonction permet de sélectionner les colonnes affichées, et de faire un filtre éventuel

par exemple streamlower permet de mettre en minuscule les caractères d'un flux

cf https://wiki.debian.org/HowToSetupADebianRepository

HA: http://jasig.github.io/cas/4.0.0/planning/High-Availability-Guide.html throttling: http://jasig.github.io/cas/4.0.0/installation/Configuring-Authentication-Components.html#login_throttling

quels comptes & infos faut-il (re)faire dans ces bases de données?

une première passe examine les données pour déterminer le type (chaine, entier, date) et la taille une deuxième passe crée la table puis charge les données

il semble que j'utilise le "vieux" client de yale, et pas celui de jasig... faut-il néanmoins voir à mettre à jour le client utilisé?

pour les applications WebObjects: on host (?) name [prot://][host/]Application.woa[/suffix] (options) pour les autres url, il faudra y réfléchir

en effet, dans le cas contraire, le CR de fin fait partie des données et cela pose problème pour l'analyse des valeurs

à cause de VEEAM, les serveurs ne sont plus accessibles chaque nuit. Le problème est que LSC ne réussit pas à refaire la connexion devenue invalide. installer un réplica local pour corriger le problème

== sur hnpx-pub1 == services web apogee: 6 vms: 1 frontal, 4 de prod, 1 de test serveurs CAS: 5 vms: 1 de prod, 4 autres pour divers besoins, il faudra faire le ménage et supprimer ce qui n'est plus utilisé. je pense que seul casedu1 est encore utilisé redirecteurs web: 3, public, privé (personnels), dmz (personnels + étudiants) divers services web: 11 vms: frontal recup fichiers, t, woappconf, support, sifacdocs, monsifac, wpad, dlvpn, dl, autoconfig, phpora redirecteurs wo: 3, public, privé (personnels), dmz (personnels + étudiants) backends wo: 3 vms: legacy, googlemig, synecure serveur vcs: 1 vm (git + svn) ldap supann 2009: 3 vms: master r/w, replica r/o, frontend ldap supann v1: 2 vms: replica, replica public serveur mysql: 1 vm synchros: 3 vm: gads, mailctl1, mailctl2 vms pas encore installée, mais "réservées": 3 vms, mq, maven, idp (mq et maven sont sans doute à supprimer) divers: 7 vms: DAIL, SAM (DT par mail), openreports, graal, univca, silegacy1, silegacy2, total: 51 vms (tient... je pensais qu'il y en avait plus :-) ... je sais, certaines anciennes machines ont été supprimées, mais les numéros se suivent, on en est à 162, d'où la confusion) le services web peuvent être mutualisés les redirecteurs web pourraient être mutualisés sur un loadbalancer logiciel type haproxy les backends webobjects *pourraient* être mutualisés, pareil pour les services web apogee on peut supprimer le frontend LDAP si on met en place un loadbalancer mutualisé pour les services en HA si toutes les mutualisations sont effectuées, et si on supprime les machines inutilisées, on pourrait descendre à: services web apogee: 2 vms: 1 prod, 1 test serveur cas: 2 vms: 1 prod, 1 pour edu loadbalancer/redirecteur haproxy: 1 vm redirecteur wo: 3 vm services web: 1 vm serveur vcs: 1 vm ldap supann 2009: 2 vms ldap supann v1: 2 vms serveur mysql: 1 vm synchros: 3 vms divers: 7 vms soit un total de 25 vms en ce qui concerne les redirecteurs wo, il peut être possible de les mutualiser, mais à cause d'une limitation du module webobjects, il faudrait avoir 3 apaches qui tournent sur la même machine avec des configuration différentes. on pourrait alors l'installer sur le loadbalancer/redirecteur haproxy. mais le plus simple et de garder chaque service sur une machine différente.

ne pas basculer sur le master tant qu'il n'est pas à jour

l'idée est de voir si les étudiants de ces formations peuvent être saisis comme hébergés dans APOGEE

quelque chose comme lo:x.x.x.x/32 avec x.x.x.x qui n'est pas 127/8 on en déduit qu'il faut activer le mode noarp auto lo iface lo inet loopback up ip addr add x.x.x.x/32 dev lo label lo:0; ip link set lo arp off down ip addr del x.x.x.x/32 dev lo le numéro après le label (0 dans l'exemple ci-dessus) est assigné de façon incrémentale

faire comme ugenpass: ordonner au hasard le résultat du tirage pour faire le mot de passe final

1) Action put 2) - test si données ont été regénérées après un fichier dépendant: if inputctl testdep dest src; then generate dest inputctl put dest fi inputctl get dest | process-it... 3) pourquoi ne pas ajouter des arguments à put, avec les noms des données dépendantes? ainsi, on peut tester si un fichier doit être regénéré puisqu'on a liste des données sources

est-ce le même problème que pour Synecure, où les requêtes retournent toujours la même chose, pendant longtemps... ? faire un environnement de déploiement WebObjects pour tester les applications en conditions réelles

- arrêt/démarrage de oracle, openoffice, tomcat

par exemple, un outil pour (re)configurer les sources d'installation par défaut, pour debian et redhat faire aussi des outils pour gérer les utilisateurs, les clés ssh, etc. éventuellement, mettre ces outils dans nutools? les scripts runs/base ensuite peuvent utiliser ces outils autonomes

du genre, config avec un compte cn=config et un mot de passe connu, et on {replace} tout cn=config

07/05/2013: fait pour ldap-srv1; ajout de member et eduPersonNickname

15/04/2013: c'est déjà le cas et ça semble ne pas marcher???

http://www.modsecurity.org/ http://www.fail2ban.org/wiki/index.php/Main_Page

- data sur SDS - archivelogs en local

Le 08/06/2012 18:17, Carpier Vincent a écrit : > On 06/08/2012 04:54 PM, Jephte CLAIN wrote: >> bonjour, >> >> il semble que MacOS X Lion n'intègre plus l'autorité de certification >> TERENA par défaut. >> >> il faudra faire des recherches plus poussées pour savoir exactement la >> raison de ce changement, mais on peut peut-être déjà avertir au moins >> les AOCmen pour qu'ils puissent répondre aux utilisateurs affolés par >> les messages d'erreur >> > > Les autorités racines émettrices de ce certificat sont apparemment > encore présent. > Il faudrait donc que nos serveurs envoie la bonne chaîne de > certification, et ça devrait rouler. > salut, l'autorité racine a toujours été présente. ce sont les deux autorité intermédiaires qui ne sont plus là. c'est le même problème avec java, je suppose donc que c'est politique puisque c'est corrigé dans, e.g. windows et firefox depuis belle lurette. il me semble que les serveurs web sont configurés pour offrir toute la chaine, mais peut-être pas dans le bon ordre. en effet, il y a un bug avec certains clients qui s'attendent à recevoir la chaine dans un ordre précis, sinon les autorités ne sont pas reconnues... le problème c'est que le "bon ordre" diffère suivant les clients.... c'est une idée intéressante. je vais vérifier l'ordre dans les certificats sont présentés dans apache. si c'est juste ça... il me semblait déjà avoir fait la correction...

- tous les 3 ou 4 mois, envoyer un mail à tous pour leur proposer de cliquer sur un lien pour "mettre à jour leur compte" - éduquer les utilisateurs qui cliquent sur ce lien