Automatisation on Zwindler's Reflection

Une issue ouverte sur un projet, 7 ans après ?

Fri, 24 Nov 2023 14:00:00 +0200

Introduction

Il y a 7 ans, en août 2016 (!!), je créais ma première “vraie” image docker.

Il s’agissait d’une image custom pour un outil que j’utilisais énormément XWiki, un outil de Knowledge management open source (et français) que j’apprécie particulièrement et qui remplace avantageusement un Confluence (si vous voulez mon avis).

A l’époque, mon image fournissait un XWiki prêt à l’emploi avec Tomcat 8 et le driver JDBC pour postgresql.

github.com/zwindler/docker-xwiki

J’avais fait ce projet car les images officielles du projet étaient encore balbutiantes (ça date !) et ne proposaient pas cette alternative.

J’avais d’ailleurs écrit un article pour l’occasion (Installer XWiki 8.2.1 avec Docker (compose) en 2 lignes de commandes) et fourni au fil des mois suivants des manifests pour Kubernetes.

Et aujourd’hui ?

Ca fait bien longtemps que ce projet n’a plus aucun intérêt, même si mes images ont été téléchargées environ 30000 fois (quand même !), avec un dernier téléchargement l’an dernier, malgré une version vielle de plus de 6 ans (mais pourquoiiiiii ?).

hub.docker.com - zwindler/xwiki-tomcat8

Les images officielles proposent désormais (depuis bien longtemps) toutes les options les plus courantes pour toutes les versions supportées

Pourtant ?!?

Pourtant, début novembre, j’ai reçu une issue, d’un utilisateur qui m’informait qu’il ne pouvait pas rebuild mon image car l’URL permettant de télécharger les artefacts WAR ne répondait plus (effectivement, elle a changé).

Même si au début j’étais un peu interloqué, je me suis dis que ça pouvait être fun de remettre les mains dedans et de tenter de mettre à jour mon image sur toute la stack, pour voir si ça fonctionne encore.

Voyons voir ce qui a changé depuis 2016…

Évidemment, beaucoup de choses !

D’abord, les versions de XWiki (de 10 à 14), qui ont forcément évoluées, ainsi que cette fameuse URL de téléchargement des artefacts qui avait changé.

La version de postgres est passée de 9.5 à 16, les versions du driver JDBC ont évoluées de plusieurs mineures.

Plus impactant, tomcat est passé de la version 8 à la version 10, avec un gros breaking change entre la 9 et la 10, notamment à cause de JEE, renommé en JakartaEE !

Ca parlera aux Javaistes ;-)

Plus anecdotique, le MAINTAINER a disparu depuis bien longtemps des Dockerfile (remplacé par un LABEL opencontainers), le MaxPermSize n’existe plus en Java et le format des fichiers docker-compose est passé en version 3.

Les modifs

Pour le fun, j’ai donc réparé mon image pour qu’elle marche (et pas plus), puis j’ai passé le repo en readonly, pour la postérité, en prenant soin d’informer l’auteur de l’issue qu’il valait mieux regarder du côté des images officielles ;-).

Le code de fix est disponible ici, pour les curieux/curieuses.

Mais… ça fonctionne :-p

Votre première VM dans Azure… déployée avec Ansible bien sûr !

Tue, 07 Aug 2018 11:45:22 +0000

Mais tu n’as pas déjà fais un article sur Ansible et des VMs ?

Si vous me suivez depuis quelques temps, vous savez que j’apprécie particulièrement Ansible. J’ai déjà écris plusieurs articles sur le sujet, ainsi que de nombreux playbooks que j’ai mis à votre disposition sur mon compte github.

Un des articles qui intéresse le plus les lecteurs du blogs est un article en deux parties (part1 part2) qui détaille comment déployer des machines virtuelles sur une architecture VMware vSphere avec Ansible. J’en ai d’ailleurs fait une version en anglais également qui attire pas mal de monde aussi ;-).

Du coup, maintenant que je me suis attaqué aux principaux clouds providers (AWS, GCP et Azure), il était grand temps de faire un article sur cette partie également !

Comme d’autres outils d’automatisation, Ansible fait la part belle aux intégrations cloud. Je vous laisse jeter un oeil à la liste des modules Ansible disponibles pour le cloud :

docs.ansible.com/ansible/2.9/modules/list_of_cloud_modules.html

Et c’est particulièrement vrai pour Azure, dont l’équipe dédiée chez Microsoft est assez réactive et ajoute des features de manière très régulière (on aura l’occasion d’y revenir dans un prochain article, #teasing).

Les prérequis

Finalement, déployer un VM dans Azure, c’est presque pareil que comme déployer une VM dans VMware. On a des prérequis, une liste de paramètres à renseigner et pouf, on va poper une VM.

Bon, en vrai, ce n’est pas aussi trivial : si pour VMware, on se contentait d’une API python relativement simple à installer avec pip et d’un mot de passe, sur Azure, il va falloir trimer un poil plus.

Deux ressources nous donnent la marche à suivre pour configurer notre poste :

Installer

Sur une machine mint/debian/ubuntu, récupérer les modules python nécessaires :

apt install python-pip ansible
pip install setuptools wheel
pip install ansible[azure]

Configurer

Pour déployer des VMs sur Azure, il faut… un compte sur Azure !

Thanks, captain obvious.

Bon, si jamais vous voulez essayer, sachez que vous pouvez vous créer un compte gratuit avec 200$ de crédit offert, mais seulement valable 30 jours. C’est hyper radin de leur part, là où un GCP offre 300$ pendant 1 an, ce qui offre largement plus de temps pour tester.

Pour ouvrir le compte, il faut simplement aller à cette URL et renseigner une carte bancaire. Oui je sais, j’ai flippé moi aussi.

Normalement, ils ne vous prélèveront pas sans vous prévenir, c’est simplement pour éviter les bots. Personnellement je n’ai pas eu de problèmes mais je ne peux rien garantir (même si je pense que ça se saurait s’il y avait eu des soucis de ce côté là).

Une fois le compte créé, on va générer les fichiers de configuration pour Azure. Le plus simple pour le faire, c’est d’utiliser la commande « az login » (mais du coup il faut installer az cli en plus).

az login
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code CCHMTROLL to authenticate.

Vous devriez avoir un dossier .azure dans votre homedir

ll .azure
total 8
drwxrwxrwx 1 zwindler zwindler 512 Aug 4 17:00 ./
drwxr-xr-x 1 zwindler zwindler 512 Aug 4 16:56 ../
-rw------- 1 zwindler zwindler 7124 Aug 4 17:00 accessTokens.json
-rw-rw-rw- 1 zwindler zwindler 5 Aug 4 16:56 az.json
-rw-rw-rw- 1 zwindler zwindler 5 Aug 4 16:56 az.sess
-rw-rw-rw- 1 zwindler zwindler 333 Aug 4 17:00 azureProfile.json
-rw-rw-rw- 1 zwindler zwindler 66 Aug 4 17:00 clouds.config
-rw------- 1 zwindler zwindler 27 Aug 4 16:56 config

Et donc, on la déploie sur Azure, cette VM ?

Maintenant que notre poste est configuré, ça redeviens simple. Ouf !

Le module à invoquer dans notre playbook est azure_rm_virtualmachine, dont la documentation est disponible à l’adresse suivante :

https://docs.ansible.com/ansible/latest/modules/azure_rm_virtualmachine_module.html#azure-rm-virtualmachine-module

Voici un des exemples donnés dans la documentation du module :

- name: Create a VM with managed disk
azure_rm_virtualmachine:
resource_group: Testing
name: testvm001
vm_size: Standard_D4
managed_disk_type: Standard_LRS
admin_username: adminUser
ssh_public_keys:
- path: /home/adminUser/.ssh/authorized_keys
key_data: < insert your ssh public key here... >
image:
offer: CoreOS
publisher: CoreOS
sku: Stable
version: latest

La plupart des options que je vous met plus haut sont obligatoires. Il y en a beaucoup d’autre, mais celles ci sont un minimum. Pour expliquer un peu de quoi il s’agit, voici une petite traduction :

resource_group
Sur Azure, il existe plusieurs entités logiques permettant de segmenter les ressources entre elles. La souscription (plus haut niveau de segmentation, utile au niveau billing) et les resources groups. On peut donc avoir plusieurs resource groups dans une souscription.

name
Le nom de la ressource, telle qu’elle apparaîtra dans votre portail Azure. Pas plus important que ça.

vm_size
Là on rentre dans le vif du sujet ; il s’agit de la taille de la VM (en terme de nombre de CPU et de Go de RAM) que va avoir votre VM. Un guide des tailles (sans le billing) est disponible à l’adresse suivante

managed_disk_type

Pour faire simple, est ce que votre disque sera sur des baies SSD ou sur des baies mixant SSD et HDD classiques. On a assez peu d’information sur la façon dont sont stockées les données, au delà d’un nombre d’IOPS qui sera d’autant plus important que vous aurez réservé d’espace disque. Par exemple, un disque Premium de 128 Go, on aura droit à 500 IOPS et 100Mo/s max. Si vous passez au delà (de 129 à 256), vous aurez droit à 1100 IOPS et 125 Mo/s.

Quelques infos quand même :

Je vois vos petits yeux pétiller de malice.

Vous vous dites « ahah, je vais les feinter, me payer un disque de 129 Go pour avoir les perfs d’un disque de 256 pour à peine plus qu’un disque de 128 Go ».

Et bien non, ils ne sont pas fous, vous payerez pour un disque de 256 même si vous ne demandez que 129 (et même si vous n’utilisez 1 Go dedans).

admin_username & ssh_public_keys

Je ne vais pas vous faire l’affront de détailler ça. Il faut rentrer un utilisateur, un path pour la clé SSH et le contenu de votre clé publique.

image

Sur azure, vous avez accès à un magasin pré configuré d’images de VMs.

Si on veut un Ubuntu 16.04, on mettra :

image:
offer: UbuntuServer
publisher: Canonical
sku: '16.04.0-LTS'
version: latest

Pour un CentOS 7.4 :

image:
offer: CentOS
publisher: OpenLogic
sku: '7.4'
version: latest

Toujours plus

Alors OK, avoir un bout de doc qui explique comment déployer une VM sur Azure, c’est chouette. Mais est ce qu’on pourrait pas faire mieux ?

Et oui, bien sûr ! Car en fait, dans Azure, on ne va pas simplement pouvoir déployer notre VM comme ça et espérer que ça marche.

Je l’ai déjà dis, il existe des ressources groups, dans lequel toutes vos ressources doivent être. On va devoir le créer. Mais il va aussi nous falloir une carte réseau, qui aura une adresse IP qui elle même proviendra d’un réseau virtuel, qui auront leur propres règles de sécurité (genre de firewalling basique). Et bien sûr, tout ça, c’est des objets à créer (à la main :-( … ou pas) !

Mais comme je suis sympa, je vais vous donner un playbook clé en main qui fait tout ça pour vous ;)

---
- name: "Create Azure resources"
connection: local
hosts: all
vars_prompt:
- name: "location"
prompt: "Choose region to deploy VMs"
private: no
default: "westeurope"
- name: "project_prefix"
prompt: "Choose a prefix for all the resources"
private: no
default: "test"
- name: "instances_number"
prompt: "Choose a number of virtual machines to create"
private: no
default: 1
- name: "vm_size"
prompt: "Choose a size for azure virtual machines"
private: no
default: "Standard_B2s"
- name: "managed_disk_type"
prompt: "Choose a type for azure virtual disks"
private: no
default: "Standard_LRS"
- name: "admin_username"
prompt: "Choose an admin username"
private: no
default: "zwindler"
- name: "admin_pub_path"
prompt: "Where can I find the admin public key ?"
private: no
default: "~/.ssh/id_rsa.pub"
- name: "local_ip"
prompt: "your local IP address (skip if you don't want to add 22 port to NSG)"
private: no
default: "skip"
- name: "virtualnetwork_cidr"
prompt: "Give a network CIDR for virtual network (large)"
private: no
default: "172.16.0.0/18"
- name: "subnet_cidr"
prompt: "Give a subnet of that network"
private: no
default: "172.16.1.0/24"
vars:
- resourcegroup_name: "{{project_prefix}}-rg"
- availabilityset_name: "{{project_prefix}}-avset"
- virtualnetwork_name: "{{project_prefix}}-vnet"
- subnet_name: "{{project_prefix}}-subnet"
- securitygroup_name: "{{project_prefix}}-nsg"
- vm_root_name: "{{project_prefix}}-vm"
- public_ip_name: "{{project_prefix}}-ip"
- nic_root_name: "{{project_prefix}}-nic"
tasks:
- name: "Create {{project_prefix}}-rg Resource Group"
azure_rm_resourcegroup:
name: "{{resourcegroup_name}}"
location: "{{location}}"
- name: "Create {{availabilityset_name}} Availability Set"
azure_rm_availabilityset:
name: "{{availabilityset_name}}"
location: "{{location}}"
resource_group: "{{resourcegroup_name}}"
sku: Aligned
- name: "Create {{virtualnetwork_name}} Virtual Network"
azure_rm_virtualnetwork:
name: "{{virtualnetwork_name}}"
resource_group: "{{resourcegroup_name}}"
address_prefixes_cidr:
- "{{virtualnetwork_cidr}}"
- name: "create {{subnet_name}} Subnet in {{virtualnetwork_name}} for VMs"
azure_rm_subnet:
name: "{{subnet_name}}"
virtual_network_name: "{{virtualnetwork_name}}"
resource_group: "{{resourcegroup_name}}"
address_prefix_cidr: "{{subnet_cidr}}"
register: subnet
- name: "Create {{securitygroup_name}} security rules (if local IP address was given)"
azure_rm_securitygroup:
name: "{{securitygroup_name}}"
resource_group: "{{resourcegroup_name}}"
purge_rules: yes
rules:
- name: 'AllowSSHFromYourOwnInternetIP'
protocol: 'Tcp'
source_address_prefix: "{{local_ip}}"
destination_port_range: 22
access: Allow
priority: 1000
direction: Inbound
when: local_ip | ipaddr
- name: "Create a {{nic_root_name}}X network interface for each VM"
azure_rm_networkinterface:
name: "{{nic_root_name}}{{item}}"
resource_group: "{{resourcegroup_name}}"
virtual_network: "{{virtualnetwork_name}}"
subnet_name: "{{subnet_name}}"
security_group: "{{securitygroup_name}}"
ip_configurations:
- name: "ipconfig"
public_ip_address_name: "{{public_ip_name}}"
primary: True
with_sequence: count="{{instances_number}}"
- name: "Create {{vm_root_name}}X VM with existing NIC"
azure_rm_virtualmachine:
resource_group: "{{resourcegroup_name}}"
name: "{{vm_root_name}}{{item}}"
vm_size: "{{vm_size}}"
managed_disk_type: "{{managed_disk_type}}"
admin_username: "{{admin_username}}"
availability_set: "{{availabilityset_name}}"
ssh_password_enabled: false
ssh_public_keys:
- path: "/home/{{admin_username}}/.ssh/authorized_keys"
key_data: "{{lookup('file', '{{admin_pub_path}}') }}"
network_interface_names: "{{nic_root_name}}{{item}}"
image:
offer: UbuntuServer
publisher: Canonical
sku: '16.04.0-LTS'
version: latest
with_sequence: count="{{instances_number}}"

Pour ceux qui veulent d’économiser un copier coller, j’ai mis à disposition ce playbook à l’adresse suivante :

github.com/zwindler/ansible-deploy-azure

Et il ne reste plus qu’à l’exécuter :

pip install --user netaddr
echo localhost > hosts
ansible-playbook -i hosts azure-deploy.yml
[...]
TASK [Create test-vmX VM with existing NIC] *****************************************
changed: [localhost] => (item=1)
PLAY RECAP **************************************************************************
localhost : ok=1 changed=7 unreachable=0 failed=0

Le mot de la fin

Bon, on en est où maintenant ?

Et bien maintenant, vous avez un playbook qui vous permet de déployer des VMs à tour de bras dans Azure certes, mais aussi de les préconfigurer avec votre clé SSH et votre utilisateur administrateur, et seul votre IP (ou celle que vous aurez donné ou un subnet) pourra y accéder en SSH.
Vous avez toutes vos VMs dans un même sous réseau, lui même dans un réseau virtuel.
Vous avez également un AVSET qui vous permet de ne pas avoir toutes vos VMs sur les mêmes hyperviseurs et augmenter la disponibilité de votre application.
Et tout ça, sans rien avoir eu à faire à la main.

Badass non ?

Et encore! J’en ai gardé un peu sous le coude, pour d’autres articles ;-)

Installer XWiki 8.2.1 avec Docker (compose) en 2 lignes de commandes

Thu, 15 Sep 2016 11:00:28 +0000

Automatiser l’installation du XWiki avec Docker compose

Pour ceux qui ne le savent, XWiki est une plateforme collaborative de gestion de la connaissance (généralement appelé wiki, KMDB en ITIL). L’exemple le plus connu de wiki est bien entendu Wikipedia qui tourne par contre lui sous Mediawiki (un autre wiki, moins convivial mais très répandu). J’ai déjà écris pas mal au sujet du XWiki donc si vous voulez un petit tour d’horizon de ce qu’on peut faire avec, vous pouvez cliquer ici.

Je commence à en avoir installé un certain nombre :

que ce soit pour tester les nouvelles version
en recette ou en production pour de nouvelles équipes
faire des tests sur Docker

Si l’installation d’un XWiki est simplissime si vous utilisez les outils préconfigurés par défaut dans l’installeur JAR, l’installation d’une instance XWiki avec Tomcat et PostgreSQL est un peu plus complexe. Du coup, j’ai eu besoin à plusieurs reprise d’ouvrir mon propre tutoriel qui guide pas à pas l’installation de la version 7 de XWiki sur un Redhat Entreprise Linux 7 (ou CentOS).

Vous avez dit Docker ?

Et c’est notamment grâce au besoin que j’ai eu de faire des tests sur Docker que j’en suis venu à réaliser une image Docker XWiki.

XWiki était le parfait exemple pour s’initier à :

la création d’un service multi-conteneurs séparés par Tiers (Tomcat, PostgreSQL)
la rédaction d’un DockerFile qui automatise entièrement l’installation et la configuration de l’application java XWiki à partir de l’image standard Tomcat 8
l’ajout d’une orchestration de base avec Docker Compose
la mise en ligne d’une image publique avec Docker Hub

Un des avantages de Docker, c’est que grâce à l’aspect « portable » des conteneurs :

Avec ce conteneur, je peux garantir que les fichiers de configuration que j’embarque avec l’image seront compatibles.
Sans conteneur, avec un serveur Tomcat déjà existant et en fonction des fichiers de configurations embarqués selon telle ou telle distribution, les instructions que je donne dans mon article « pas à pas » pourraient ne pas toujours fonctionner.

Pour les plus pressés

Quelque soit la méthode que vous choisirez, le XWiki sera opérationnel et accessible sur le port 8080 à l’issue de ces commandes. Il faudra juste passer le « First Installation Wizard » et commencer à configurer le XWiki.

Avec Docker Compose

Docker compose se charge pour vous, à partir du fichier docker-compose.yml, de :

télécharger/builder l’image des conteneurs Postgresql et XWiki
configurer ces conteneurs
démarrer les conteneurs.

C’est donc forcément plus simple de le faire marcher en 2 lignes de commandes ;-).

[Edit]
A priori il n’est plus nécessaire de faire un « chmod +x xwiki-tomcat/xwiki-tomcat-entrypoint.sh » sinon ça ne fonctionne pas, j’ai corrigé les permissions sur le github
[/Edit]

git clone https://github.com/zwindler/docker-xwiki.git && cd docker-xwiki
docker-compose -f compose/docker-compose.yml up -d

Avec Docker depuis les sources

Avec Docker uniquement, il faudra forcément tout faire à la main. Donc il faudra créer le network, démarrer successivement l’image PostgreSQL puis l’image Tomcat modifiée par mes soins.

docker network create -d bridge xwiki-nw
docker run --net=xwiki-nw -itd --name xwiki-postgres -e POSTGRES_DB=xwiki -e POSTGRES_USER=xwiki -e POSTGRES_PASSWORD=xwiki postgres

git clone https://github.com/zwindler/docker-xwiki.git && cd docker-xwiki
chmod +x xwiki-tomcat/xwiki-tomcat-entrypoint.sh
docker build -t zwindler/xwiki-tomcat8:latest .
docker run --net=xwiki-nw -itd --name xwiki-tomcat -p 8080:8080 -e POSTGRES_INSTANCE=xwiki-postgres zwindler/xwiki-tomcat8

Avec Docker et Docker Hub

Un cran plus simple que la version précédente car je viens d’uploader l’image zwindler/xwiki-tomcat sur Docker Hub. Elle est donc automatiquement téléchargée depuis Docker hub lors de la commande docker run. Pas besoin de « chmod » ni de builder l’image.

docker network create -d bridge xwiki-nw
docker run --net=xwiki-nw -itd --name xwiki-postgres -e POSTGRES_DB=xwiki -e POSTGRES_USER=xwiki -e POSTGRES_PASSWORD=xwiki postgres
docker run --net=xwiki-nw -itd --name xwiki-tomcat -p 8080:8080 -e POSTGRES_INSTANCE=xwiki-postgres zwindler/xwiki-tomcat8

L’image en question

L’ensemble des sources sont disponibles sur Github dans mon repository docker-xwiki.

Voici le contenu du DockerFile :

FROM tomcat:8-jre8
MAINTAINER Denis GERMAIN <denis@example.com>
ENV POSTGRES_INSTANCE=xwiki-pgsql
ENV POSTGRES_PORT=5432
ENV POSTGRES_DB=xwiki
ENV POSTGRES_USER=xwiki
ENV POSTGRES_PASSWORD=xwiki
RUN rm -rf webapps/* && \
curl -L \
'http://download.forge.ow2.org/xwiki/xwiki-enterprise-web-8.2.1.war' \
-o xwiki.war && \
unzip -d webapps/xwiki xwiki.war && \
rm -f xwiki.war
RUN curl -L \
'https://jdbc.postgresql.org/download/postgresql-9.4.1208.jar' \
-o 'webapps/xwiki/WEB-INF/lib/postgresql-9.4-1208.jdbc42.jar'
COPY hibernate.cfg.xml webapps/xwiki/WEB-INF/
COPY xwiki.cfg webapps/xwiki/WEB-INF/
COPY setenv.sh bin/setenv.sh
RUN sed -i "s/redirectPort=\"8443\" /redirectPort=\"8443\" URIEncoding=\"UTF-8\" /" conf/server.xml
COPY xwiki-tomcat-entrypoint.sh /
ENTRYPOINT ["/xwiki-tomcat-entrypoint.sh"]

Des variables d’environnement ENV sont à votre disposition pour adapter à votre contexte (on en parlera un peu plus loin). La première étape consiste à télécharger la dernière version en date du XWiki, puis le pilote JDBC PostgreSQL correspondant.

Les fichiers de Tomcat sont adaptés pour un fonctionnement avec XWiki (Xmx java, autorisation des « / » dans les URLs, …) et les fichiers de configuration de XWiki sont paramétrés pour accepter l’instance PostgreSQL.

Personnalisation

Pour permettre un peu plus de souplesse dans l’utilisation de la base de données, j’ai volontairement ajouté des variables d’environnement et un script « ENTRYPOINT ». Ce script sert à paramétrer à la première exécution les valeurs définies en début de DockerFile (ENV).

Ceci permet à la fois de mettre à disposition une image Docker clé en main si l’utilisateur ne souhaite rien modifier et tout laisser par défaut, ou à l’inverse, de fournir des variables qui lui sont propres et personnaliser automatiquement son instance.

Vous pourrez ainsi par exemple changer le mot de passe et/ou le nom de l’instance PostgreSQL (soit via modification du docker-compose.yml, soit directement en modifiant le DockerFile).

Problème ALLOW_ENCODED_SLASH=true

Malgré l’ajout de ALLOW_ENCODED_SLASH=true dans catalina.properties, j’avais des problèmes pour ouvrir les pages avec des / dans les noms de pages.

J’en ai profité pour essayer de déplacer l’application du paramètres et l’intégrer au niveau du setenv.sh avec la variable d’environnement CATALINA_OPTS. Ca n’a pas corrigé le problème (situé à un autre niveau) mais a permis de simplifier le Dockerfile, ce qui est toujours bon à prendre.

En réalité, la variable était bien prise en compte dans les deux cas. Je l’avais vérifié et cela marchait depuis le début. En réalité, j’ai un reverse proxy Apache (ProxyPass) qui lui aussi fout le boxon avec les « / » dans mes titres de pages de XWiki.

La réponse suivante sur StackOverflow explique très bien ce qu’il se passe. Pour autant dans mon cas, impossible d’accéder à ces pages, quelque soit le paramètre essayé, dans le cas où le XWiki est derrière mon proxy Apache. Je peux y accéder sans, je vais donc devoir les renommer pour contourner le problème. De toute façon, ça ne me plait pas que ces pages aient un « / » dans leur URL ;-).