Journal X.500 et LDAP

Posté par  (site web personnel) .
Étiquettes :
6
16
nov.
2010
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 )

  • # La Suisse...

    Posté par  . Évalué à 5.

    ... tu l'aimes ou tu la quittes !

    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  (Mastodon) . Évalué à 4.

      Purée, en Suisse il est plus simple d'être opaque sur ses comptes que d'être transparent sur ses accès.


      (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  (site web personnel) . Évalué à 3.

    Salut,
    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  . Évalué à 7.

    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". […] 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)))

    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  . Évalué à 6.

    Toi au moins tu a de la chance, tu a pu changer la ligne de titulaire!

    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  (site web personnel) . Évalué à 5.

    n'est pas foutu de mettre en place un simple serveur OpenLDAP

    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  (site web personnel) . Évalué à 3.

      Et pourtant ! S'il y'avait une vraie concurrence je me demande si Swisscom serait encore de ce monde. Ça va faire comme Swissair.

      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  . Évalué à 4.

        Ça va faire comme Swissair.

        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  (site web personnel) . Évalué à 9.

          Pour finir en faillite elle même, être sauvée par l'argent du contribuable, donnée aux allemands et redevenir rentable. Oui.
          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  . Évalué à 1.

        Sans être méchant, je te conseille d'aller travailler dans la DSI d'un opérateur avec plus de 100.000 abonnés pour te rendre compte. Tu vas vite voir que les choses sont un peu plus compliquées en pratique. Des services et serveurs, il y en a partout, les bases ne sont pas toujours partagées, tout n'est pas "beau".

        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  (site web personnel) . Évalué à 1.

      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

      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  (site web personnel) . Évalué à 2.

      >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.

      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  . Évalué à 0.

    Je n'ai jamais rien compris avec les dn, on, etc.

    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  (site web personnel) . Évalué à 2.

      C'est parce que tu n'as pas compris les annuaires. Finalement c'est plutôt simple et logique.

      "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  . Évalué à 2.

      Peut-être pour la syntaxe ou l'orthographe, mais il me semble que les annuaires sur basent pour leur implémentation sur la théorie des graphes en maths de manière assez directe. Ça doit tenir un minimum debout quand même.

    • [^] # Re: c'est parce que LDAP est mal fichu

      Posté par  . Évalué à 2.

      suffit de se dire que c'est un simple arbre, chaque noeud de ton arbre peut être enrichi des informations dont tu as besoin, chacune d'elle utilisant un acronyme de préférence peu compréhensible. (o = organisation, dn = nom absolu, etc...)

      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  (site web personnel) . Évalué à 3.

        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

        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  (site web personnel) . Évalué à 2.

          Il est composé d'un attribut que tu choisi (et qui va devenir ainsi le RDN).

          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.