PROJET AUTOBLOG


Planet-Libre

source: Planet-Libre

⇐ retour index

Thuban : Mise à jour de swx en version 0.6

dimanche 27 mai 2018 à 13:43

Mise à jour de swx en version 0.6

Afin de gérer mon site web, j'avais écrit swx. Je me suis penché à nouveau sur son code afin d'accorder plus d'importance au site plutôt qu'au blog. En effet, je délaissais son contenu. Dans cet article, je vais parler des changements apportés à swx.

Principe de fonctionnement

Pour rappel, swx est un ensemble de petits scripts shell permettant de fabriquer un site statique. Il ne doit pas dépendre d'outils ou de bibliothèques tierces, mis à part un éventuel convertisseur de langage markup (markdown, txt2tags, pandoc…).

Il va prendre pour argument un dossier contenant un site web et toute sa structure. Ce dossier et copié dans un répertoire avec l'extension “.static”, après avoir convertit les pages et inséré un menu de navigation.

D'autres scripts peuvent être lancés pour fabriquer un sitemap, un flux atom ou une page de type “blog”.

Le dossier final n'a plus qu'à être envoyé sur un serveur pour être accessible (ftp, sftp…)

Le tout s'utilise avec un fichier Makefile pour simplifier le processus.

Les modifications récentes

Dans cette nouvelle version, j'ai revu la logique de certains scripts, notamment pour la liste des nouvelles pages.

Ces changements n'ont pas été détaillés sur le dépôt. Je dois m'occuper de rédiger les pages de documentation auparavant… Par ailleurs, certains éléments sont propres à OpenBSD, il faut les tester sous GNU avant (commandes find, date et stat avec des options différentes).

Détection des changements

Au lieu d'utiliser rsync ou de copier tout le contenu du “dossier modèle”, swx va désormais comparer la date de modification des fichiers avec un fichier-repère créé automatiquement à la fin de chaque génération. Ce fichier est .swx.last et se trouve dans le dossier du site généré.

Pour refabriquer l'ensemble d'un site, il suffit de le supprimer.

Utilisation d'un template

Afin de personnaliser l'apparence des pages, l'utilisateur peut désormais utiliser un fichier modèle (template). Ce fichier ressemble à ceci :




${_PAGETITLE_}
<link rel="icon" href="./media/fe2a0650.favicon.png" data-original-source="https://yeuxdelibad.net/favicon.png" type="image/png">

<link rel="stylesheet" type="text/css" href="/style.min.css">
<link href="/atom.xml" type="application/atom+xml" rel="alternate" title="Atom feed of yeuxdelibad.net" />



${_HEADER_}
${_MAIN_}
Le ${_GENDATE_} avec swx

On remarque dans ce fichier des éléments comme ${_PAGETITLE_}. Il s'agit de variables qui seront remplacées par la fonction générant les pages. On remarquera notamment :

Ainsi, l'utilisateur peut plus facilement gérer l'apparence de ses pages.

Une nouvelle option fait son apparition si on souhaite changer la syntaxe désignant une variable. Il s'agit d'une expression régulière :

TOREPLACE='^\\${_.*_}$'

Par défaut, ce sont les lignes commençant par $, suivies d'une accolade et d'un underscore, terminant par un underscore, accolade en bout de ligne.

Séparation du code

Les fonctions et variables communes à tous les petits scripts sont rassemblés dans un fichier swx.functions.

Création d'un flux atom

Au lieu d'un flux RSS, c'est le format ATOM plus rigoureux que je privilégie. Le script swx_atom va rechercher les fichiers les plus récents puis ajouter son contenu dans un fichier atom.xml.

Afin de trouver les fichiers plus récents, c'est find qui est utilisé :

Sous GNU :

RECENTS=$(find "${1}" -type f -name "*${EXT}" -print0 | xargs -0 stat --format '%Y :%y %n' | sort -nr | cut -d: -f2- | head -n "${MAX}")

Avec OpenBSD, c'est un poil plus court :

RECENTS=$(find "${1}" -type f -name "*${EXT}" -exec stat -f "%m %N" {} \\; | sort -nr | head -n "${MAX}" | cut -d' ' -f2-)

Le nombre maximum d'entrées est définit avec la variable MAX présente dans le fichier de configuration.

Afin de savoir à quelle date la page a été créée pour la mettre dans le flux atom, on se sert de stat :

Sous GNU :

    UPDATED="$(date -ud @`stat -t ${i}|cut -f13 -d\\ ` +%Y-%m-%dT%TZ)"

Avec OpenBSD :

    UPDATED=$(date -ur $(stat -f %m "${i}") +%Y-%m-%dT%TZ)

Gestion d'une page de nouveauté

Afin d'utiliser swx comme moteur de blog, j'ai voulu améliorer cet aspect. Un script swx_blog est capable de détecter les fichiers les plus récents avec find.

Ces fichiers sont analysés pour en retirer le titre (première ligne) et le lien.

Deux nouvelles options font leur apparition pour la suite :

NEWSSTR="%%%BLOOOOG%%%"
NEWSPAGE="/index.md"

La première correspond à un bout de texte que l'on met dans une page et qui sera remplacé par la liste des nouveautés. La seconde correspond à la page du site qui servira d'entrée dans le blog, et qui contient justement le bout de texte précédent.

swx_blog va convertir cette page et remplacer $NEWSSTR par une liste de lien vers les nouvelles pages.

J'ai hésité à inclure directement le contenu des pages en utilisant les balises

et
, mais pour l'instant ça me convient ainsi.

Autres changements

Ci et là des corrections de bugs et amélioration de syntaxe. Les variables sont protégées, et normalement le tout doit tourner sur les systèmes de type UNIX.

Démonstration ?

Ce site 😁

Sinon, j'utilise ce fichier Makefile pour générer l'ensemble de mon site écrit en markdown :

SOURCEDIR=/home/xavier/Documents/site/epicededune/Rendez-vous_sur_Arrakis/
DESTDIR=/home/xavier/Documents/site/epicededune/Rendez-vous_sur_Arrakis.static/

all:
    @echo "Generate website"
    @./swx $(SOURCEDIR)
    @echo "Remove .swp"
    @find $(DESTDIR) -name '*.swp' -exec rm '{}' \\;
    @echo "Generate sitemap and gzip it"
    @./swx_sitemap  $(DESTDIR) > $(DESTDIR)/sitemap.xml
    @gzip --best -c $(DESTDIR)/sitemap.xml > $(DESTDIR)/sitemap.gz
    @echo "Generate website plan"
    @./swx_plan $(DESTDIR) > $(DESTDIR)/Divers/Plan_du_site.html
    @echo "Generate atom feed"
    @./swx_atom $(SOURCEDIR) > $(DESTDIR)/atom.xml
    @echo "Generate blog news entry"
    @./swx_blog $(SOURCEDIR) 
clean:
    rm -rf *.static
force:
    rm $(DESTDIR)/.swx.last
    make all
regen:
    find Rendez-vous_sur_Arrakis -name *.md -exec touch {} \\;
    make all
serve:
    sleep 1 && surf http://localhost:8000 &
    cd $(DESTDIR) && python3 -m http.server 

Un make serve me permet de voir mon site dans un navigateur après avoir généré le tout avec make. Un rsync avec un tunnel SSH envoie le tout sur mon serveur sous OpenBSD bien sûr ☺️.

Et ça ressemble à ça :

$ make
Generate website
> Load configuration
> Prepare output directory
> Generating html pages and copying files
[##################################################] 4/4

> Done! :)
Remove .swp
Generate sitemap and gzip it
Generate website plan
Generate atom feed
Generate blog news entry

Gravatar de Thuban
Original post of Thuban.Votez pour ce billet sur Planet Libre.

Yannic Arnoux : Proxmox, NAT et DHCP

dimanche 27 mai 2018 à 02:00

J’ai eu beaucoup de retours à mon dernier article qui ont alimenté ma réflexion et m’ont permis de clarifier mon objectif avec mon serveur Proxmox. J’ai décidé de pousser plus loin avec les containers LXC, de ne pas utiliser Docker sur le serveur mais d’améliorer certains aspects de mon installation : containeriser ce que j’ai installé directement sur l’hyperviseur (que ce soit par flemme, pour aller vite ou par manque de connaissances) et automatiser le déploiement de certains containers pour faciliter une éventuelle migration et me permettre d’installer un environnement de test local.

Voici un diagramme à gros grain de l’architecture actuelle :

Architecture Proxmox

Au niveau de l’hyperviseur, on a un pare-feu et une interface Bridge et j’ai installé un serveur NginX au niveau de l’hyperviseur qui joue le rôle de proxy Web vers les containers. Cela implique de modifier la configuration de NginX à chaque ajout d’un service Web et donc de se connecter en SSH à l’hyperviseur. C’est le premier point que je compte améliorer en migrant ce serveur Web vers un container. Or les containers sont configurés en IP fixe. Pour simplifier les configurations, je veux attribuer les adresses IP par DHCP et d’utiliser des noms DNS plutôt que des adresses.

Au préalable, approfondissons la configuration réseau de mon Proxmox déjà en place… rien de révolutionnaire car la plupart de ces choix ont été documentés par d’autres (et j’ai seulement assemblé pour arriver à mes fins) mais ça permettra de mieux comprendre la partie DHCP qui arrive ensuite. Mon serveur est une Dedibox hébergée chez Online et Proxmox est une distribution officiellement supportée, donc l’installation initiale est réalisée via l’interface Web d’administration du serveur. De base, une interface physique est configurée avec l’adresse IP fixe du serveur et l’adresse IP de la passerelle. Online attribue une adresse IP fixe à chaque dédibox et on peut acheter des adresses IP supplémentaires. C’est idéal pour associer une adresse IP à chaque container, mais on ne va pas faire ça du tout car :

  1. c’est coûteux (2 euros HT par IP / mois) pour le l’auto-hébergement,
  2. chaque container est directement exposé sur Internet donc il doit être capable d’assurer sa sécurité.

On va plutôt créer un réseau privée (non routable sur Internet), caché derrière l’IP publique du serveur. Les containers peuvent envoyer du trafic sortant sans restriction et le trafic entrant passe par le tamis du pare-feu avant d’être redirigé vers le bon container. C’est similaire à ce qu’on a tous à la maison avec un réseau en 192.168.x.x. derrière une box ADSL (ou fibre pour les chanceux). Pour cela on crée une interface bridge nommée vmbr0 qui sert de passerelle aux containers et on ajoute une règle de translation d’adresse (NAT) pour faire passer le trafic sortant de vmbr0 vers l’interface physique enp1s0.

Configuration dans /etc/network/interfaces :

auto lo
iface lo inet loopback

auto enp1s0
iface enp1s0 inet static
        address  xx.xx.xx.xx
        netmask  255.255.255.0
        gateway  xx.xx.xx.1

auto vmbr0
iface vmbr0 inet static
        address  10.10.10.1
        netmask  255.255.255.0
        bridge_ports none
        bridge_stp off
        bridge_fd 0
        post-up echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o enp1s0 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o enp1s0 -j MASQUERADE

Sans surprise, le pare-feu de Proxmox est basé sur iptables et l’interface Web facilite vraiment sa configuration en présentant trois niveaux de pare-feu : un niveau datacenter (qui peut contenir plusieurs Proxmox si on gère un cluster), un niveau noeud et un niveau container. On peut activer le pare-feu à chaque niveau.

Ma configuration de base est la suivante :

Pour finaliser l’aspect sécurisé, on peut installer fail2ban pour scruter les logs des services critiques et bannir les fâcheux.

A ce niveau là, on a un Promox opérationnel : les containers en IP fixe dans le réseau 10.10.10.0/24 peuvent communiquer avec l’extérieur. On va modifier le système pour fournir du DHCP. La première action consiste à remplacer le serveur DNS Bind fourni avec Proxmox par Dnsmasq qui combine les fonctions DNS et DHCP.

systemctl disable bind9
apt-get install dnsmasq

Et on crée un fichier de configuration dans /etc/dnsmasq.d/containers :

    domain-needed
    bogus-priv

    no-poll
    no-hosts

    no-dhcp-interface=enp1s0
    interface=vmbr0

    expand-hosts
    domain=madyanne.lan

    dhcp-authoritative
    dhcp-leasefile=/tmp/dhcp.leases

    dhcp-range=10.10.10.100,10.10.10.200,255.255.255.0,12h
    dhcp-option=3,10.10.10.1
    dhcp-option=19,1
    dhcp-option=6,10.10.10.1

    cache-size=256

    log-facility=/var/log/dnsmasq.log
    #log-queries

Quelques points clés de la configuration :

Pour tester, je configure un container en DHCP, démarre le container et… ça ne marche pas :-) Le container n’arrive pas à récupérer une adresse IP. En fait, le pare-feu bloque les requêtes DHCP. Je débloque la solution en autorisant les ports UDP/67 et UDP/68 en entrée de l’interface vmbr0.

La configuration du pare-feu au niveau Proxmox est la suivante :

Configuration pare-feu

Ainsi configuré, cela fonctionne ! Dnsmasq ajoute automatiquement les noms obtenus par DHCP à son service DNS. Ainsi depuis n’importe quel container je peux adresser un autre container par nom court :

# ping dev
PING dev (10.10.10.100) 56(84) bytes of data.
64 bytes from dev.madyanne.lan (10.10.10.100): icmp_seq=1 ttl=64 time=0.137 ms
64 bytes from dev.madyanne.lan (10.10.10.100): icmp_seq=2 ttl=64 time=0.076 ms

Il reste un problème en suspens : les containers de type Alpine ont le mauvais goût de ne pas propager leur nom au serveur DHCP ; c’est peut-être paramétrable dans leur service Udhcpc, il faut que je regarde…

Ma prochaine évolution consiste à migrer le serveur NginX installé par mes soins au niveau de le Proxmox vers un container dédié avec la gestion des certificats SSL Let’s Encrypt.

Gravatar de Yannic Arnoux
Original post of Yannic Arnoux.Votez pour ce billet sur Planet Libre.

Miamondo : Automatiser la mise en page d’un roman grâce à un petit script Python, en utilisant les outils pandoc et pdftk

samedi 26 mai 2018 à 20:07

Bonjour, Aujourd'hui, je vais vous prouver que la paresse a des vertus insoupçonnées car c'est elle qui nous pousse à nous creuser les méninges pour en faire le moins possible. Je suis actuellement en train de corriger les derniers chapitres d'un roman intitulé  On ira tou·te·s au Paradis. Si vous cliquez sur ce lien, vous accédez... Lire la suite →

Gravatar de Miamondo
Original post of Miamondo.Votez pour ce billet sur Planet Libre.

Thuban : Bienvenue sur mon blog

samedi 26 mai 2018 à 12:59

Bienvenue sur mon blog

Cette section du site fait office de blog. Si vous ne voulez pas manquer une information, abonnez-vous au flux atom.

Gravatar de Thuban
Original post of Thuban.Votez pour ce billet sur Planet Libre.

Thuban :  Blog statique, bye bye Blogotext

samedi 26 mai 2018 à 08:39

 Blog statique, bye bye Blogotext

Après 8 ans d'existence, mon blog sera désormais “statique” et disponible à l'adresse https://yeuxdelibad.net/Journal. Vous pouvez en suivre les nouveautés avec n'importe quel lecteur de flux grâce au flux atom.

Ce “déménagement” a lieu pour plusieurs raisons :

J'aime toujours autant Blogotext et continue de l'utiliser sur d'autres blogs. Mais avoir un site statique présente des avantages certains :

Ça m'a permis de remettre le nez dans le code de swx, le générateur de site statique, mais j'en reparlerai dans un autre billet.

Grâce à Blogotext, j'ai pu exporter tous mes articles et commentaires au format json. Après un peu de bidouille en python, j'ai pu recréer tout le contenu afin de faciliter les redirections de l'ancien blog vers le nouveau.

Ensuite, un peu de CSS pour l'apparence, du javascript pour rigoler et ça suffira bien.

Pour ceux qui veulent continuer à lire mes bafouilles, n'oubliez pas de vous abonner au nouveau flux atom.

Gravatar de Thuban
Original post of Thuban.Votez pour ce billet sur Planet Libre.