Que nous réserve la LDAPCon 2017 ?

La LDAPCon est une conférence internationale autour de la technologie LDAP et des enjeux de gestion des identités, d’authentification et d’habilitation.

L’événement qui se déroulera cette année à Bruxelles du 19 au 20 octobre, se tient tous les deux ans dans un pays différent :

Savoir-faire Linux, déjà commanditaire en 2015 (consultez notre retour sur cette édition) renouvelle avec plaisir son soutien à cette communauté en étant une nouvelle fois partenaire de l’édition 2017.

2 jours et 19 conférences, un programme riche et rythmé

Le programme de cette édition promet des interventions intéressantes, parmi lesquelles :

  • ReOpenLDAP : Modification d’OpenLDAP pour une utilisation intensive chez un opérateur de télécommunications
  • OpenLDAP pour Samba 4 : Point sur l’intégration d’OpenLDAP dans Samba 4 en lieu et place de l’annuaire natif codé par l’équipe Samba
  • PHP-LDAP : Des nouvelles de l’évolution de l’API LDAP dans PHP, délaissée depuis plusieurs années et que les développements reprennent
  • OpenLDAP : Des nouvelles du projet OpenLDAP par Howard Chu, le développeur principal

Les sujets afférents à LDAP comme la gestion des identités dans le Cloud, les habilitations/autorisations, l’authentification unique ou encore la supervision seront abordés dans les différentes présentations.

Savoir-faire Linux fera le point sur les différents protocoles de SSO (CAS, SAML et OpenID Connect) dans une intervention donnée vendredi après-midi, juste avant la présentation du logiciel FusionDirectory, le logiciel d’administration des données d’un annuaire LDAP, utilisé dans notre infrastructure interne et chez certains de nos clients.

Si cette conférence vous intéresse, vous pouvez réserver vos billets en ligne sur le site de la conférence.

Définir des rôles avec Ansible pour Nexus Repository Manager v3.x


Savez-vous comment automatiser l’installation ainsi que la configuration de Nexus Repository Manager version 3.x avec Ansible ? Pas encore ? On vous donne un coup de pouce ici !

Pour rappel, Ansible est un outil de déploiement qui permet à des playbooks d’automatiser les déploiements d’applications et d’infrastructure. L’avantage clé d’Ansible est sa flexibilité puisqu’il permet de modifier les applications avec souplesse et de les appréhender en tant que service. Toutefois, Ansible possède également quelques faiblesses. Avec une conception volontairement simple, il fonctionne uniquement comme une application de paramètres sans tenir compte de la disponibilité de l’information et des problèmes de sécurité, qui doivent alors être gérés par d’autres systèmes. C’est pourquoi un grand nombre de développeurs préfèrent utiliser Ansible en complémentarité avec un système d’agent actif comme Puppet ou avec un outil de gestion centralisé comme Ansible Tower.

Automatisation avec Ansible

Ansible se concentre sur la configuration au niveau de l’application, les scripts d’approvisionnement pouvant être exécutés sur tout outil de support d’infrastructure (PaaS, conteneurs, bare-metal, Vagrant, etc.). Ansible ne nécessite qu’une connexion SSH et un compte sudo sur le système distant.

Les scripts d’approvisionnement Ansible sont écrits dans un style déclaratif à l’aide de fichiers YAML regroupés en rôles. Les instructions atomiques des rôles sont déclarées à l’aide d’un certain nombre de modules de base fournis par Ansible. Consultez la documentation Ansible pour une introduction en profondeur.

Réapprovisionnement et mise à jour de la configuration

L’un des modèles DevOps pour gérer les mises à jour de configuration consiste à fournir un nouvel environnement à partir de zéro et à éliminer complètement l’ancien (pensez à des images de conteneur). Cela implique une gestion fiable de votre cycle de vie des données. Dans notre cas particulier du Nexus Repository Manager, cela consiste à plusieurs gigaoctets d’artefacts téléchargés / mandatés, de certains journaux d’audit et d’objets OrientDB contenant la configuration. Par conséquent, en fonction des contraintes de l’environnement, il peut être logique de mettre à jour la configuration d’une instance Nexus préalablement approvisionnée. La nature déclarative des instructions de base d’Ansible est répond bien à cette contrainte, mais toute logique personnalisée écrite dans un rôle devrait être idempotente et prendre en compte la logique « créer ou éventuellement mettre à jour ».

Il faut également noter que certaines parties de la configuration Nexus ne peuvent pas être mises à jour. Voici quelques exemples :

  • Les paramètres relatifs aux BlobStores
  • Le mot de passe administrateur si vous le perdez (mise à jour: peut-être par cette voie)

Comment bien intégrer l’API Groovy de Nexus avec Ansible

Les étapes de base de l’installation sont très simples et peuvent toutes être écrites en utilisant des modules simples de base Ansible :

  • Télécharger et décompresser l’archive
  • Créer un utilisateur / groupe système
  • Créer un service systemd

(Ces étapes sont dans les tâches / nexus_install.yml)

Et puis vient la surprise : la configuration Nexus n’est pas disponible dans un fichier texte simple qui peut être édité à l’aide d’instructions simples Ansible. Elle est stockée dans une base de données OrientDB intégrée qui ne doit pas être modifiée directement. La manière documentée de configurer Nexus est soit par son interface utilisateur Web, soit par son API d’intégration.

La façon dont l’API d’intégration fonctionne est la suivante :

  1. Écrire un script Groovy qui gère vos changements de configuration;
  2. Charger le script sur Nexus à l’aide d’un requête HTTP PUT, créant une ressource REST pour ce script;
  3. Appeler le script via sa ressource HTTP GET / POST

Module URI à la rescousse !

Le module uri d’Ansible envoie des requêtes HTTP, fournissant une automatisation de ces étapes.

La première étape consiste à téléverser le script Groovy sur Nexus. Notez que le script peut déjà être présent. Par conséquent, lors des ré-exécutions du playbook, nous essayons de le supprimer avant d’entreprendre d’autres actions, par le biais de tasks/declare_script_each.yml, comme suit :

  ---
  - name: Removing (potential) previously declared Groovy script {{ item }}
    uri:
      url: "http://localhost:8081/service/siesta/rest/v1/script/{{ item }}"
      user: 'admin'
      password: "{{ current_nexus_admin_password }}"
      method: DELETE
      force_basic_auth: yes
      status_code: 204,404

  - name: Declaring Groovy script {{ item }}
    uri:
      url: "http://localhost:8081/service/siesta/rest/v1/script"
      user: 'admin'
      password: "{{ current_nexus_admin_password }}"
      body_format: json
      method: POST
      force_basic_auth: yes
      status_code: 204
      body:
        name: "{{ item }}"
        type: 'groovy'
        content: "{{ lookup('template', 'groovy/' + item + '.groovy') }}"

Les requêtes HTTP sont exécutées à partir de l’hôte cible, c’est pourquoi localhost est utilisé ici. force_basic_auth: yes s’assure que le client HTTP n’attende pas une réponse 401 avant de fournir des informations d’identification. Autrement, Nexus répondra immédiatement avec une réponse 403 lorsque aucune authentification n’est passée. status_code est l’état HTTP attendu de la réponse fournie par Nexus. Étant donné que le script Groovy peut ne pas nécessairement exister à ce moment-là, nous devons également accepter le code d’état 404.

L’étape suivante consiste à appeler le script Groovy créé via l’appel HTTP précédent. La plupart des scripts prendront certains paramètres d’entrée (par exemple, créer un utilisateur <x>), et c’est là que Ansible et Groovy aideront. Tous deux issus de l’âge des principes REST, ils peuvent parler et comprendre le format JSON de manière relativement transparente.

Du côté du script Groovy :

import groovy.json.JsonSlurper
parsed_args = new JsonSlurper().parseText(args)
security.setAnonymousAccess(Boolean.valueOf(parsed_args.anonymous_access))

Et pour appeler ce script à partir des arguments passés via Ansible  :

  - include: call_script.yml
    vars:
      script_name: setup_anonymous_access
      args: # this structure will be parsed by the groovy JsonSlurper above
        anonymous_access: true

Avec call_script.yml :

  ---
  - name: Calling Groovy script {{ script_name }}
    uri:
      url: "http://localhost:8081/service/siesta/rest/v1/script/{{ script_name }}/run"
      user: 'admin'
      password: "{{ current_nexus_admin_password }}"
      headers:
        Content-Type: "text/plain"
      method: POST
      status_code: 200,204
      force_basic_auth: yes
      body: "{{ args | to_json }}"

Cela nous permet de passer de manière transparente les paramètres structurés de Ansible aux scripts Groovy, en gardant la structure, les tableaux et les types de base des objets.

Scripts Groovy pour Nexus : conseils et astuces pour le développement

Voici quelques conseils qui peuvent aider les développeurs travaillant sur les scripts Groovy.

Configurer le Classpath dans votre IDE

Comme décrit dans la documentation Nexus, avoir les scripts Nexus dans le classpath de votre IDE peut vraiment vous aider à travailler. Si vous automatisez la configuration de Nexus autant que possible, vous allez inévitablement tomber sur certaines API internes sans documentation. De plus, certaines parties de l’API n’ont aucune source disponible (par exemple, l’API LDAP). Dans de tels cas, un décompilateur peut être utile.

Puisque notre rôle sur Github utilise Maven avec toutes les dépendances nécessaires, vous pouvez simplement l’ouvrir avec IntelliJ et éditer les scripts situés dans « files/groovy ».

Points d’entrée de l’API de Scripting

Comme documenté, il y a quatre points d’entrée implicites pour accéder aux entrailles de Nexus à partir de votre script:

  • core
  • repository
  • blobStore
  • security

Ceux-ci sont utiles pour des opérations simples, mais pour tout ce qui est plus compliqué, vous devrez résoudre plus en profondeur les services par:

  • Indirection à partir des points d’entrée principaux: blobStore.getBlobStoreManager ()
  • Résolution d’un @Singleton interne du contexte du conteneur : container.lookup (DefaultCapabilityRegistry.class.getName())

Prenez des exemples du code source de Nexus

Certaines parties de Nexus (7,4%, selon Github) sont également écrites à l’aide de Groovy, contenant de nombreux bons exemples de code: CoreApiImpl.groovy.

Créer des requêtes HTTP à partir de l’interface Web de configuration (requêtes AJAX) fournit également des indications sur les structures de données attendues, les paramètres ou les valeurs de certains paramètres.

Enfin, mettre en place un débogueur distant depuis votre IDE vers une instance Nexus peut aider, car il existe de nombreux endroits où une structure de données très générique est utilisée (comme Map <String, Object>) et seule l’inspection au moment de l’exécution peut rapidement indiquer les types réels nécessaires.

Exemples détaillés

Voici quelques exemples commentés de scripts Groovy tirés du rôle Ansible

Configuration d’une Capability

Les Capabilities de Nexus  peuvent être configurées à l’aide d’une interface utilisateur unifiée. Dans notre cas, cela couvre:

  1. L’accès anonyme
  2. L’URL publique de base
  3. La marque (en-tête et pied de page HTML personnalisés).

Instructions :


    import groovy.json.JsonSlurper
    import org.sonatype.nexus.capability.CapabilityReference
    import org.sonatype.nexus.capability.CapabilityType
    import org.sonatype.nexus.internal.capability.DefaultCapabilityReference
    import org.sonatype.nexus.internal.capability.DefaultCapabilityRegistry

    // unmarshall the parameters as JSON
    parsed_args = new JsonSlurper().parseText(args)

    // Type casts, JSON serialization insists on keeping those as 'boolean'
    parsed_args.capability_properties['headerEnabled'] = parsed_args.capability_properties['headerEnabled'].toString()
    parsed_args.capability_properties['footerEnabled'] = parsed_args.capability_properties['footerEnabled'].toString()

    // Resolve a @Singleton from the container context
    def capabilityRegistry = container.lookup(DefaultCapabilityRegistry.class.getName())
    def capabilityType = CapabilityType.capabilityType(parsed_args.capability_typeId)

    // Try to find an existing capability to update it
    DefaultCapabilityReference existing = capabilityRegistry.all.find {
        CapabilityReference capabilityReference -&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
            capabilityReference.context().descriptor().type() == capabilityType
    }

    // update
    if (existing) {
        log.info(parsed_args.typeId + ' capability updated to: {}',
                capabilityRegistry.update(existing.id(), existing.active, existing.notes(), parsed_args.capability_properties).toString()
        )
    } else { // or create
        log.info(parsed_args.typeId + ' capability created as: {}', capabilityRegistry.
                add(capabilityType, true, 'configured through api', parsed_args.capability_properties).toString()
        )
    }

Configuration d’un mandataire de dépôt Maven

    import groovy.json.JsonSlurper
    import org.sonatype.nexus.repository.config.Configuration

    // unmarshall the parameters as JSON
    parsed_args = new JsonSlurper().parseText(args)

    // The two following data structures are good examples of things to look for via runtime inspection
    // either in client Ajax calls or breakpoints in a live server

    authentication = parsed_args.remote_username == null ? null : [
            type: 'username',
            username: parsed_args.remote_username,
            password: parsed_args.remote_password
    ]

    configuration = new Configuration(
            repositoryName: parsed_args.name,
            recipeName: 'maven2-proxy',
            online: true,
            attributes: [
                    maven  : [
                            versionPolicy: parsed_args.version_policy.toUpperCase(),
                            layoutPolicy : parsed_args.layout_policy.toUpperCase()
                    ],
                    proxy  : [
                            remoteUrl: parsed_args.remote_url,
                            contentMaxAge: 1440.0,
                            metadataMaxAge: 1440.0
                    ],
                    httpclient: [
                            blocked: false,
                            autoBlock: true,
                            authentication: authentication,
                            connection: [
                                    useTrustStore: false
                            ]
                    ],
                    storage: [
                            blobStoreName: parsed_args.blob_store,
                            strictContentTypeValidation: Boolean.valueOf(parsed_args.strict_content_validation)
                    ],
                    negativeCache: [
                            enabled: true,
                            timeToLive: 1440.0
                    ]
            ]
    )

    // try to find an existing repository to update
    def existingRepository = repository.getRepositoryManager().get(parsed_args.name)

    if (existingRepository != null) {
        // repositories need to be stopped before any configuration change
        existingRepository.stop()

        // the blobStore part cannot be updated, so we keep the existing value
        configuration.attributes['storage']['blobStoreName'] = existingRepository.configuration.attributes['storage']['blobStoreName']
        existingRepository.update(configuration)

        // re-enable the repo
        existingRepository.start()
    } else {
        repository.getRepositoryManager().create(configuration)
    }

Créer un rôle

    import groovy.json.JsonSlurper
    import org.sonatype.nexus.security.user.UserManager
    import org.sonatype.nexus.security.role.NoSuchRoleException

    // unmarshall the parameters as JSON
    parsed_args = new JsonSlurper().parseText(args)

    // some indirect way to retrieve the service we need
    authManager = security.getSecuritySystem().getAuthorizationManager(UserManager.DEFAULT_SOURCE)

    // Try to locate an existing role to update
    def existingRole = null

    try {
        existingRole = authManager.getRole(parsed_args.id)
    } catch (NoSuchRoleException ignored) {
        // could not find role
    }

    // Collection-type cast in groovy, here from String[] to Set&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;String&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
    privileges = (parsed_args.privileges == null ? new HashSet() : parsed_args.privileges.toSet())
    roles = (parsed_args.roles == null ? new HashSet() : parsed_args.roles.toSet())

    if (existingRole != null) {
        existingRole.setName(parsed_args.name)
        existingRole.setDescription(parsed_args.description)
        existingRole.setPrivileges(privileges)
        existingRole.setRoles(roles)
        authManager.updateRole(existingRole)
    } else {
        // Another collection-type cast, from Set&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;String&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt; to List&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;String&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
        security.addRole(parsed_args.id, parsed_args.name, parsed_args.description, privileges.toList(), roles.toList())
    }

Le rôle est disponible sur Ansible Galaxy et Github. Il comporte:

  • Le téléchargement et l’extraction de Nexus
  • La création de l’unité de service systemd
  • (Facultatif) La configuration d’un reverse-proxy Apache supportant SSL
  • La configuration du mot de passe administrateur
  • La configuration LDAP
  • La configuration des privilèges et des rôles
  • La création des utilisateurs locaux
  • La configuration des Blobstores
  • La configuration de tous les types de dépôts
  • La spécification de l’URL de base
  • La mise en place de la marque (en-tête HTML et pied de page personnalisés)
  • La mise en place des tâches automatiques

 

Notre expertise et la puissance des technologies open source dans Azure

Logos Microsoft + Savoir-faire Linux  

 

 

 

Nous sommes heureux de vous annoncer la sortie d’une vidéo promotionnelle produite par Microsoft eux-même ! Fruit d’une collaboration autour de la plateforme Azure, cette vidéo souligne la pertinence et l’essor des technologies open source dans l’environnement infonuagique Azure de Microsoft ainsi que notre capacité d’innovation en combinant technologies open source et solutions infonuagiques hybrides.

Premier  «partenaire Microsoft Open Source» au Canada

Savoir-faire Linux est, depuis 2015, le premier  «partenaire Microsoft Open Source» au Canada. Ce partenariat rappelle notre force : la conception et l’intégration de technologies libres et open source dans des écosystèmes complexes ou hybrides, comme la plateforme Azure. Nous aidons nos clients grâce à l’innovation des technologies ouvertes et à des alliances stratégiques pour maximiser la puissance des systèmes d’information complexes ou hétérogènes et créer des environnements spécifiques pour nos clients.

Pour Microsoft, l’open source fait désormais partie intégrante de l’approche quotidienne de l’innovation cloud. En tant qu’expert et chef de file de l’industrie du logiciel libre et  des technologies open source au Canada, Savoir-faire Linux se devait d’offrir des moyens d’améliorer l’expérience des utilisateurs et des développeurs en ajoutant à son éventail de solutions, la plateforme Azure, désormais compatible avec de nombreuses technologies open source.

Un nouveau standard de SSO pour les gouverner tous

L’authentification unique (en anglais Single Sign On ou SSO) est aujourd’hui bien implantée dans les systèmes d’information, grâce à une large offre de produits et surtout de nombreux standards comme CAS, SAML ou OpenID Connect, pour ne citer que les plus importants.

Cependant, ce domaine reste difficile d’accès car chaque nouvelle norme demande un temps d’apprentissage non négligeable et l’adaptation des applications. Afin d’éviter que ces technologies finissent dans un cul-de-sac, un nouveau standard unifiant les protocoles actuels a vu le jour : le standard des anneaux !

La fraternité de l’anneau

Ce standard part du principe que tous les protocoles de SSO fonctionnent sur le même modèle : une requête non authentifiée à un fournisseur de servicesls (application) est renvoyée à un fournisseur d’identité (portail) qui authentifie l’utilisateur puis transmet son identité au fournisseur de service dans un jeton.

Le fournisseur de service et le fournisseur d’identité font partie d’un anneau de confiance (ou cercle de confiance) grâce à l’échange préalable de données de configuration (métadonnées).

Le standard des anneaux conserve donc tout simplement ce fonctionnement en simplifiant les échanges (uniquement des requêtes HTTP GET) mais en exigeant une validation des signatures des messages au bit près.

Les deux tours

Le processus d’authentification se joue en deux tours :

  1. Redirection de l’utilisateur via son navigateur entre fournisseur de services et fournisseur d’identité pour récupérer un jeton opaque (canal frontal)
  2. Validation du jeton directement entre les fournisseurs (canal dorsal)

Concrètement, le standard des anneaux va comme OpenID Connect reposer sur OAuth 2.0, à la différence que les jetons d’accès sont rebaptisés « access tolkien » pour les distinguer justement des jetons OAuth 2.0 classiques.

La redirection initiale est inspirée du protocole CAS (notion de service dans l’URL) et la gestion des signatures du protocole SAML (clé publique publiée dans les metadonnées).

Ainsi, ce nouveau standard tire parti du meilleur des protocoles existants en masquant la complexité de leurs implémentations.

Le retour du R.O.I.

Pour les applications devant intégrer le standard des anneaux, le retour sur investissement est immédiat : le nouveau protocole est simple, basé sur des composants existants, robuste et sûr.

En résumé, la gestion de l’identité de l’utilisateur peut se traduire du point de vue des applications vis-à-vis de utilisateurs par « Vous le savez ? Nous le saurons ! ».

Le standard des anneaux, un nouveau protocole sur lequel il faudra compter !

LemonLDAP::NG, le choix de Villeurbanne pour son système d’authentification

La Ville de Villeurbanne mise sur l’Open Source et choisit LemonLDAP::NG pour contrôler les droits d’accès de ses utilisateurs.

La Ville de Villeurbanne possédait plusieurs applications Web dont l’authentification était déjà déléguée à un serveur central CAS (Central Authentification Services), modifié pour les besoins de Villeurbanne pour donner accès à la fois aux utilisateurs internes présents dans Active Directory et à des utilisateurs externes stockés dans une base de données.

L’arrivée de nouvelles applications dans le système d’information nécessitait de pouvoir contrôler les droits d’accès afin d’éviter que certains utilisateurs accèdent à des données confidentielles.

Une solution éprouvée pour répondre aux enjeux « d’authentification unique» de la Ville de Villeurbanne

Après une veille poussée et une consultation des principaux acteurs du marché, leur choix s’est porté sur le système d’authentification unique LemonLDAP::NG.
Solution de gestion des identités distribuée sous licence GPL, LemonLDAP::NG est un logiciel d’authentification unique adaptée au monde des entreprises (gestion centralisée des autorisations, interopérabilité avec tous les protocoles d’échange d’identité tels CAS, OpenID Connect, SAML,…). Très simple d’installation, la configuration peut se faire en mode texte ou graphique. LemonLDAP::NG est également compatible avec des nombreuses applications web.

« Dans le cadre d’un projet d’intranet composé de briques Open Source, nous recherchions un outil d’authentification unique permettant d’affecter des droits d’accès en fonction de caractéristiques de comptes de l’active directory. Après analyse de diverses solutions, nous avons retenu LemonLDAP::NG qui répondait parfaitement à nos besoins », explique Jean-Patrick Trauet, responsable technique et sécurité de la ville de Villeurbanne.
« C’est également devenu une opportunité pour créer un portail d’authentification pour nos applications web. Nous envisageons désormais de faire évoluer LemonLDAP::NG vers de l’authentification forte. »

« Après analyse de diverses solutions, nous avons retenu LemonLDAP::NG qui répondait parfaitement à nos besoins. C’est également devenu une opportunité pour créer un portail d’authentification pour nos applications web. »
Jean-Patrick Trauet, responsable technique et sécurité


Un projet mené par Savoir-faire Linux

La ville de Villeurbanne a fait appel à nous pour les accompagner dans la mise en place de LemonLDAP::NG. Le projet a été découpé en plusieurs phases :

  • Mise en place d’un annuaire OpenLDAP pour remplacer la base
    de données en tant que référentiel des identités externes.
  • Création de connecteurs pour synchroniser automatiquement les
    comptes et les groupes Active Directory dans l’annuaire OpenLDAP.
  • Gestion de groupes de droits dans OpenLDAP associant utilisateurs internes et externes. .
  • Mise en place de LemonLDAP::NG en tant que serveur CAS pour remplacer l’ancien et personnalisation de la mire d’authentification.
  • Migration des applications sur le nouveau serveur CAS.

Le nouveau portail d’authentification

Les principaux bénéfices pour la ville de Villeurbanne

La ville de Villeurbanne dispose désormais d’un annuaire central des identités (internes et externes) et d’un outil de WebSSO et contrôle d’accès. La possibilité d’utiliser LemonLDAP::NG comme serveur CAS, mais également comme fournisseur d’en-têtes ou fournisseur SAML ou OpenID Connect, permet de connecter un large périmètre d’applications.

Données clés

  • Nombre d’utilisateurs touchés : environ 1000 utilisateurs
  • Nombre de jours de charge du projet : 10 jours
  • Nombre d’applications concernées : entre 5 et 10
  • Technologies utilisées : OpenLDAP, LSC et LemonLDAP::NG , EZPublish, Alfresco, iTop, Piwik, Orchestra, développements internes en PHP