Derrière ce titre, rien de bien technique se cache, quoique.
En 1868, l'ITU (International Telegraph Union) se réunit en conférence, la deuxième après sa création à Paris une année auparavant, et créa un bureau permanent à Berne, en Suisse. Ce bureau restera jusqu'en 1948 puis fût déplacé à Genève, toujours en Suisse.
L'ITU est notamment connue pour la de standard X.500 qui définit "l'Annuaire" (dans le texte des documents X.500 "the Directory"). C'est ces documents qui donnent naissance au DAP (Directory Access Protocol) qui fût ensuite dérivé vers LDAP (Ligthweight Directory Access Protcol).
Voilà pour la trame de fond ( http://www.itu.int/ITU-T/50/docs/ITU-T_50.pdf ).
Aujourd'hui je téléphone à Swisscom, opérateur historique de téléphonie en Suisse, né de la privatisation (ou quasi-privatisation) de Telecom-PTT. Un problème avec mon "Swisscom login" : la "pièce d'identité" pour accéder à ses informations personnelles depuis le Web. Le problème est que j'ai deux lignes téléphoniques avec chacune un abonnement ADSL à mon nom. Rien de bien magique.
Une des lignes est à mon nom car j'ai fait les démarches, mais plusieurs personnes utilisent cet accès et doivent pouvoir gérer ce compte. L'autre ligne, je l'ai obtenue quand j'ai déménagé et repris la ligne téléphonique et l'abonnement ADSL des précédents habitants. Nous avons donc fait les démarches pour mettre à mon nom cette nouvelle ligne (ce qui a été fait, je reçois les factures).
Pour ma part j'aurais voulu avoir un nouveau "Swisscom login" sur cette nouvelle ligne. C'est donc pour cette raison que je téléphone au service client. Le service administratif (c'est là qu'il faut suivre), me dit : "pas de problème c'est du ressort du service technique".
Je suis dirigé vers le service technique.
Le service technique me dit : "mais la ligne X est au nom de M. Y (l'ancien détenteur de la ligne)". Là je dis "Non, j'ai reçu la lettre de confirmation, cette ligne est à mon nom". Le service technique se renseigne et me dit ceci : "Alors oui, la ligne est à votre nom, mais il y'a un service (???) qui n'a pas encore fait le changement. Nous, au service technique, on ne peut rien faire sans que se changement ait été fait. Par contre au service administratif, le changement a été fait correctement".
Voilà. Je vis dans le pays où l'on trouve l'ISO (X.500 est une norme ISO), où se trouve l'ITU (qui a défini X.500, donc DAP), qui a certainement pris part dès le début à l'ITU (connue avant sous le nom de CCITT), et l'entreprise de télécommunication historique (qui a certainement pris part à la création de X.500) n'est pas foutu de mettre en place un simple serveur OpenLDAP pour que tous les services aient la même information !
Incroyable, vraiment incroyable (et moi je suis parti pour des heures aux téléphones avec ces guignoles (là j'en suis déjà à 45 minutes pour le résultat suivant : je dois téléphoner demain (et recommencer le même cirque, parce que j'ai quand même été redirigé entre les bureaux 5 fois aujourd'hui)))
Après faut pas s'étonner que Swisscom soit pas capable de fournir une connexion décente durant quelques jours à une conférence http://www.google.com/search?&q=leweb+swisscom
Une petite note pour Swisscom (si vous passez par là) : http://www.openldap.org/doc/admin24/ (si c'est trop dur à comprendre, prenez un tuto sous Ubuntu : https://help.ubuntu.com/community/OpenLDAPServer )
Journal X.500 et LDAP
16
nov.
2010
# La Suisse...
Posté par zebra3 . Évalué à 5.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: La Suisse...
Posté par bubar🦥 (site web personnel) . Évalué à 4.
(quoi ? ça se rejoint ?? ha oui...)
Amitiés à la Suisse (mode évidence) qui applique la balance entre bénéfices et problèmes...
# Demander le nom
Posté par Ecran Plat (site web personnel, Mastodon) . Évalué à 3.
demande toujours le nom de la personne avec qui tu parles et quand tu rappel et qu'on te demande de tout recommencer à zéro ben tu sors le nom de la personne et ça va plus vite.
Chez moi à la maison j'ai toujours de bon souvenir de la hotline ils sont sympa et réactif (j'en suis à ma troisième box swisscom tv et à mon deuxième routeur vdsl) ça toujours été traité rapidement.
# X.500 et LDAP
Posté par Obsidian . Évalué à 7.
Et encore, les services techniques ont une existence connue et une légitimité dans ton pays. Imagine que tu aies eu le même problème en France avec Orange…
# Toi au moins tu a de la chance
Posté par maxix . Évalué à 6.
Moi j'ai appelle Orange pour faire sensiblement la même chose, cad un changement de propriétaire, et j'ai reçu 15 jours plus tard des papiers me présentant leurs condoléances suite au décès de ma mère.
N'ayant pas de certificat de décès sous la main je me retrouve un peu embêté et dois attendre l'expiration de cette procédure, avant de tout recommencer (sans cadavre, cette fois).
# simplification
Posté par Sebastien (site web personnel) . Évalué à 5.
Alors, de là à croire que le SI d'un opérateur télécom, c'est une paire de serveurs dans un garage sur lesquels il suffit d'installer OpenLDAP, faut arrêter de rêver. En particulier lorsqu'il s'agit d'un opérateur dit "historique", il se trouve que celui-ci au passage hérite, pour son SI, de beaucoup d'éléments historique plus ou moins indépendants à faire causer les uns avec les autres, et cela, que ce soit volontaire ou juste (sic) historique.
Et puis, on a beau être un membre fondateur de X500, DAP, LDAP, DTC, etc, étant donné que le dicton dit que les cordonniers sont les plus mals chaussés, on en connait d'autres, des opérateurs, qui finissent avec un Exchange et des noms d'utilisateurs ou des adresses emails préfixés en "zz" pour les séparer du reste.
(après, on peut aussi éventuellement se moquer de OpenLDAP à proprement parler, mais c'est une autre histoire)
[^] # Re: simplification
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Sinon ce n'est pas deux serveurs dans un garage et c'est bien dommage. Ça marcherai peut-être. Faut arrêter avec cet argument "on est trop gros", et peut-être commencer à donner des raisons plus réels : les données informatiques ne demandent qu'un peut de temps pour être migrées ... sauf si l'on s'est enfermé dans un format propriétaire. Et durant les 10h de panne de l'autre jour, vous aviez le temps.
Mais sinon un truc me fait terriblement souci, vous êtes une autorité de certification. Les certificats sont gérés comme les clients ? Et bien SSL est
définitivement mort.
Enfin, au final c'est moi qui vais devoir faire le travail de Swisscom bénévolement et continuer à payer un abonnement Internet avec le port 25 bloqué en sortie.
(Et se moquer d'un projet quand on a système d'information défectueux ça ne se fait pas)
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: simplification
Posté par claudex . Évalué à 4.
C'est-à-dire que Swisscom va racheter une société belge de téléphonie, lui pomper tout son fric et la foutre en faillite?
--->[]
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: simplification
Posté par Etienne Bagnoud (site web personnel) . Évalué à 9.
Bel exemple de socialisation du déficit et de privatisation du bénéfice.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: simplification
Posté par leoboy . Évalué à 1.
les données informatiques ne demandent qu'un peut de temps pour être migrées
Oui, ca c'est en théorie; dans la pratique, dans des grosses entreprises, ca ne se passe pas comme ça (ou rarement). Le SI ressemble souvent à un grand mikado, où quand tu enlèves une baguette, beaucoup de choses bougent. That's life.
Tu peux penser que j'ai tort et que je vois mal les choses; moi je te donne juste mon expérience 'terrain'.
Ah, et quand tu migres la base clients, t'as vachement intérêt à que tout marche le lendemain matin.... sans aucun effet de bord... ca peut prendre des mois à valider.
[^] # Re: simplification
Posté par William Steve Applegate (site web personnel) . Évalué à 1.
Bah s'ils finissent avec un Exchange, ils finissent automatiquement avec AD, donc avec du LDAP (quelque peu bâtardisé peut-être). Après s'ils ne savent pas comment s'en servir, évidemment c'est mal barré.
Envoyé depuis mon PDP 11/70
[^] # Re: simplification
Posté par Juke (site web personnel) . Évalué à 2.
ha je me suis toujours demandé pourquoi ils prefixaient leurs mails par zzz , je pensais que c'était juste pour etre dernier dans l'annuaire;
# c'est parce que LDAP est mal fichu
Posté par reno . Évalué à 0.
Quand on regarde LDAP, on se dit que finalement le XML c'est lisible (quoi que coté schema, les developpeurs d'XML ils ont pas fait fort non plus).
[^] # Re: c'est parce que LDAP est mal fichu
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: c'est parce que LDAP est mal fichu
Posté par llaxe . Évalué à 2.
[^] # Re: c'est parce que LDAP est mal fichu
Posté par Alex . Évalué à 2.
exemple à la con
C = fr (pays)
O = MultideskOs Corp (organisation)
OU = département qui poutre (organisational unit - en gros le service)
CN = Roger (nom commun de l'utilisateur)
plus tard tu as besoin de faire l'authentification unix sur ton ldap, tu rajoutes à ta feuille utilisateur les attributs Posix à ton utilisateur (uid, gid...). Le truc chiant, c'est de savoir à quoi correspond chaque acronyme, et lesquels sont nécessaires ou facultatifs
[^] # Re: c'est parce que LDAP est mal fichu
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Tout ça c'est écrit dans les RFC ou dans les schémas qui se trouvent (pour openldap) dans /etc/ldap/schema/*.schema ... Le format est aisé à lire.
En suite il faut aussi bien se rendre compte que chacun te des objets n'ont qu'une seule (1,1) classe structurelle (STRUCTURAL) et autant de classes auxiliaires (AUXILIARY) que tu souhaites (0,n). Les classes abstraites il faut juste savoir que la classe top et toutes les classes en descende.
Ensuite il y a un héritage entre les classes, dans les schémas tu vas voir "SUP top AUXILIARY", tu sais que c'est une classe auxiliaire qui descend de top, mais tu peux voir "SUP person STRUCTURAL" donc ta classe hérite des attributs de person et est structurelle.
Les attributs c'est presque la même chose, ils ont une syntaxe et tu dois t'en tenir, l'héritage existe ...
Chaque objet à un nom unique, le DN, c'est à dire "tout le chemin que tu vas parcourir depuis la racine de l'arbre jusqu'à l'objet" et c'est "l'identifiant unique" de ton objet. Il est composé d'un attribut que tu choisi (et qui va devenir ainsi le RDN).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: c'est parce que LDAP est mal fichu
Posté par Raoul Volfoni (site web personnel) . Évalué à 2.
On peut également avoir un RDN multivalué (plusieurs attributs)
Je chipote un peu mais le grand lurker que je suis est usé par les captchas de linuxfr...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.