# uname -a

Switch

mardi 5 mars 2019

La délégation NS d'un sous-domaine, cet illustre inconnu

Un billet un peu technique aujourd'hui. Si vous travaillez dans le Web, vous n'êtes pas sans savoir que c'est le mécanisme des DNS qui fait en sorte que vos noms de domaine soient résolus en adresses vers votre hébergement.

Vous savez aussi peut-être ce qu'est une zone DNS. Une zone DNS est un bête fichier présent sur le serveur DNS, et qui contient l'ensemble des enregistrements du domaine1.

Vous savez aussi certainement ce qu'est un sous-domaine, par exemple pour le domaine example.com, des sous-domaines seraient :

  • www.example.com
  • test.example.com
  • sousdomaine.example.com

Parfois, pour séparer les services, on souhaite aller encore plus loin et dédier un sous-domaine entier à une tâche, par exemple on souhaite faire en sorte que compta.example.com soit totalement indépendant, c'est à dire :

  • Qu'on puisse recevoir sur l'email facturation@compta.example.com ,
  • Qu'on puisse avoir des mini-sites dédiés sous ce sous-domaine, comme urssaf.compta.example.com ou creances.compta.example.com
  • Que le sous-domaine puisse servir tout autre usage tel que permis par les DNS (enregistrements SRV, etc)

Bien sûr, ces usages sont possibles à partir de la zone DNS du domaine parent, mais à mesure que le sous-domaine grandit en indépendance (et donc en nombre d'enregistrements), il peut être nécessaire de poser les bases d'une délégation plus avancée, pour éviter de maintenir une zone avec tous les enregistrements. On peut aussi vouloir déléguer à un prestataire la gestion de ce sous-domaine.

Pour ce qui est des mini-sites, il est relativement simple de déclarer un wildcard pour rediriger tous les enregistrements d'un sous-domaine vers un même serveur. Mais lorsqu'on veut plus de souplesse, ou que l'on veut aussi déléguer tous les enregistrements de ce sous-domaine, un wildcard est trop "brutal" et pas toujours supporté par toutes les spécifications, il faut alors déléguer la zone via une délégation NS.

Lire la suite...

mardi 26 février 2019

Utiliser l'Object Storage d'OVH (Openstack Swift) avec Updraft Plus

J'ai expérimenté cette semaine l'Object Storage d'OVH avec le module de sauvegarde de Wordpress UpdraftPlus, et le moins que l'on puisse dire c'est qu'on n'est pas aidé : pas de documentation de A à Z, les noms de configuration qui souffrent à la traduction, bref.

Voilà comment faire, simplement et du premier coup.

Lire la suite...

vendredi 3 novembre 2017

Je suis hype, j'ai un Tipeee

Voilà, c'est fait.

Presque deux ans après avoir retiré Flattr et ses bénéfices mirobolants, profitant d'un rhume qui verrouille mon cerveau en mode "lecture seule" depuis deux jours, j'ai fini par me laisser convaincre à créer un Tipeee.

Vous trouverez donc sous chaque article un petit rappel que oui c'est possible de donner un euro pour remercier le type qui vous a fait gagner 20 minutes, qui vous a fait sourire, ou que vous trouvez simplement sympathique.

À très bientôt sur le blog :)

jeudi 19 octobre 2017

Setup Letsencrypt certificates on Gitlab and Mattermost

The new versions of Gitlab are embedding the Mattermost server. Here is how to setup the certificates for these instances.

1. Install certbot

Read the docs here (choose Nginx on the appropriate system) : certbot.eff.org

2. Make a webroot

mkdir -p /var/www/letsencrypt/.well-known

3. Configure Gitlab and Mattermost to answer /.well-known to this webroot

Edit /etc/gitlab/gitlab.rb and add :

nginx['custom_gitlab_server_config']="location ^~ /.well-known/ {\n alias /var/www/letsencrypt/.well-known/;\n}\n"
mattermost_nginx['custom_gitlab_mattermost_server_config']="location /.well-known/ {\n alias /var/www/letsencrypt/.well-known/;\n}\n"

And reconfigure Gitlab :

gitlab-ctl reconfigure

4. Create the certificates

Run the certbot command :

certbot certonly --staging --webroot --webroot-path=/var/www/letsencrypt/ -d gitlab.your-domain.com
certbot certonly --staging --webroot --webroot-path=/var/www/letsencrypt/ -d mattermost.your-domain.com

5. Tell Gitlab to use the certificates

Edit /etc/gitlab/gitlab.rb again, and add :

nginx['redirect_http_to_https'] = true
nginx['ssl_certificate']= "/etc/letsencrypt/live/gitlab.your-domain.com/fullchain.pem"
nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/gitlab.your-domain.com/privkey.pem"

mattermost_nginx['redirect_http_to_https'] = true
mattermost_nginx['ssl_certificate'] = "/etc/letsencrypt/live/mattermost.your-domain.com/fullchain.pem"
mattermost_nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/mattermost.your-domain.com/privkey.pem"

6. Done

Reconfigure Gitlab again :

gitlab-ctl reconfigure

mardi 10 octobre 2017

Elasticsearch, Kibana : mapper [hits] cannot be changed from type [long] to [integer]

Every time I upgrade my ELK stack, it breaks. This time, it was the Kibana index with this obscurous errors :

[DEBUG][o.e.a.a.i.m.p.TransportPutMappingAction] [logs] failed to put mappings on indices [[[.kibana]]], type [timelion-sheet]
java.lang.IllegalArgumentException: mapper [hits] cannot be changed from type [long] to [integer][DEBUG][o.e.a.a.i.m.p.TransportPutMappingAction]

[DEBUG][o.e.a.a.i.m.p.TransportPutMappingAction] [logs] failed to put mappings on indices [[[.kibana]]], type [timelion-sheet]
java.lang.IllegalArgumentException: mapper [version] cannot be changed from type [long] to [integer]

Here is how to fix it. You will have to re-create an index with the correct mapping, and then reindex it.

Lire la suite...

- page 1 de 32