Dans le host de devilbox :

nano autostart/install-spip-cli.sh

puis dans le fichier

#!/usr/bin/env bash
#

SPIP_CLI_PATH='/opt/spip-cli/'

if [ -d "${SPIP_CLI_PATH}" ]; then
	>&2 echo "[Warning], ${SPIP_CLI_PATH} existe déjà, on sort"
	exit 0
fi

mkdir -p ${SPIP_CLI_PATH}
cd ${SPIP_CLI_PATH}
git clone https://git.spip.net/spip-contrib-outils/spip-cli.git .
composer install --no-dev
cd bin
ln -s $(pwd)/spip /usr/local/bin/
ln -s $(pwd)/spipmu /usr/local/bin/
ln -s $(pwd)/spip_console_autocomplete /etc/bash_completion.d/spip

Bonus :

nano autostart/install-spip-dump.sh

Puis :

#!/usr/bin/env bash
#

SPIP_DUMP_PATH='/opt/spip-dump/'

if [ -d "${SPIP_DUMP_PATH}" ]; then
	>&2 echo "[Warning], ${SPIP_DUMP_PATH} existe déjà, on sort"
	exit 0
fi

echo 'installation des scripts spip-dump'
mkdir -p ${SPIP_DUMP_PATH}
cd ${SPIP_DUMP_PATH}
curl -fsSL -o spip-import-dump-from-connect.sh https://git.spip.net/-/snippets/12/raw/main/import-dump-from-connect.sh?inline=false
curl -fsSL -o spip-export-dump-from-connect.sh https://git.spip.net/-/snippets/11/raw/main/export-dump-from-connect.sh?inline=false
chmod +x *.sh
ln -s $(pwd)/spip* /usr/local/bin/

Le fichier source est disponible ici.

A l’installation de phpmyadmin laisser le champ vide pour configurer automatiquement les identifiants de connexion à la base de données.

[x] Cocher redémarrer apache2 pour prendre en compte la configuration ;

Puis ajouter "root" en superadmin de phpmyadmin

Se connecter sur http://localhost/phpmyadmin

Pour certains, l’email est une donnée privée qui peut déjà révéler certaines informations sur son propriétaire.

Ainsi, nombreux sont les administrateurs de sites SPIP soucieux de pouvoir préserver la confidentialité des auteurs dans l’espace privé, en ne divulgant leur adresse email qu’aux seuls webmestres.

Pour passer outre une fastidiese surcharge des squelettes du privé, j’avais proposé une solution sur le forum, et je la retranscris ici, pour qu’elle gagne en visibilité :

Déclarer un traitement automatique sur le champ #EMAIL :

Déclarer les autorisations :

Pour passer outre ce traitement automatique, on pourra toujours utiliser la syntaxe #EMAIL* dans son squelette si besoin.

Récemment, j’ai eu besoin d’incorporer le contenu d’un fichier distant à l’intérieur d’un squelette de feuille de style. En l’occurence, il s’agissait de récupérer un fichier CSS dans sa dernière version (fréquemment mise à jour) et d’étendre certaines règles CSS via des directives @extend de SCSS à d’autres élémenst de mon choix.

Pour complexifier encore la chose, le document source question débute par un BOM [1] qui faisait planter le compilateur SCSSphp.

Mais à SPIP vaillant, rien d’impossible, sans quitter le squelette, en 2 lignes de code s’il vous plait :

Xz - Compresser un fichier

Xz est un outil de compression très performant. Pour compresser un gros fichier avec le taux de compression maximal on utilise simplement :

xz -9 gros_fichier

Le fichier de sortie sera nommé gros_fichier.xz

Split - Découper un fichier en plusieurs fichiers de taille définie

Découper le fichier en plusieurs fragments de 1GB (-b bytes) et ajouter un suffixe numérique aux fichiers de sortie (-d )

split -b 1024M  -d gros_fichier.xz  gros_fichier.xz_part
donnera :

gros_fichier.xz_part01
gros_fichier.xz_part02
gros_fichier.xz_part03
...

Combiner tar + xz-utils + split

A titre d’exemple, le même résultat que précédement, en utilisant conjointement tar et split :

tar -Jcvf - un_repertoire_ou_fichier | split -d -b 1024MB - gros_fichier.tar.xz.

Tmux - Envoyer les fichiers en tâche de fond

Pour envoyer les fichiers vers un serveur, j’utilise scp avec une clef ssh et comme je ne veux pas saturer la connexion j’utilise l’option -l (limit). Dans l’exemple ci-dessous, -l 512 correspond à environ 50ko/s.

scp -i ~/.ssh/ma_clef  -l 512 gros_fichier.xz_part* user@host:/home/bob/incoming

C’est bien joli, mais si je fais des transferts à distance, j’aimerais bien lancer la commande en tâche de fond, surtout si l’upload est très long.
Pour ce faire, j’utilise tmux qui permet d’utiliser plusieurs terminaux virtuel que l’on peu détacher ou rattacher au terminal facilement.

tmux new-session -d -s upload  'scp -i ~/.ssh/ma_clef  -l 512 gros_fichier.xz_part* user@host:/home/bob/incoming 2> errors.log'

Rattacher le terminal pour voir l’upload en cours : tmux attach
Détacher le terminal avec la combinaison de touches ctrl + b puis d
Grâce à tmux, je peux me déconnecter du shell distant et revenir plus tard...
Un simple tmux a me permettra de consulter l’état d’avancement de l’upload.

Cat - Réassembler les fichiers découpés

Une fois les fichiers transférés, je les réassemble avec un simple cat

cat gros_fichier.xz_part*   >  gros_fichier.xz

Décompression d’un xz ou d’un tar.xz

Avec tar (-x xtract) :
tar -Jxvf gros_fichier.tar.xz

Avec xz-utils (-d)
xz -d gros_fichier.xz

Voilà.

Installation de java-package

java-package est un script permettant de générer un paquet # !Debian afin de faciliter l’installation et la mise à jour de l’Environnement d’exécution Java (JRE).

Récupérer java-package et les outils nécessaires à la génération du paquet :

apt-get install java-package build-essential java-common

Récupérer l’archive sur le site d’Oracle ©

Rendez vous sur le site d’Oracle© afin de télécharger les archives.

On peux également récupérer les archives via WGET ou CURL (Et passer outre l’acceptation de la licence...)

Exemple de commande CURL pour récupérer java 8.77 32BIT via le terminal

curl -v -j -k -L -H "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/8u77-b03/jre-8u77-linux-i586.tar.gz > jre-8u77-linux-i586.tar.gz

Exemple de Commande WGET pour récupérer java 8.77 64BIT via le terminal

 wget --no-check-certificate --no-cookies --header "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/8u77-b03/jre-8u77-linux-x64.tar.gz

Générer le paquet java JRE 8 pour votre distribution Debian

une fois l’archive téléchargée il suffit d’exécuter le script make-jpkg sous l’identifiant utilisateur :

fakeroot make-jpkg jre-8u77-linux-i586.tar.gz

qui devrait démarrer ainsi :

Detected Debian build architecture: i386
Detected Debian GNU type: i586-linux-gnu

Detected product:
    Java(TM) Runtime Environment (JRE)
    Standard Edition, Version 8 Update 77
    Oracle(TM)
Is this correct [Y/n]: y <-

Checking free diskspace: done.

In the next step, the binary file will be extracted. Probably a
license agreement will be displayed. Please read this agreement
carefully. If you do not agree to the displayed license terms, the
package will not be built.

Press [Return] to continue: 
Testing extracted archive... okay.

.

Une fois le script terminé l’installation du nouveau paquet se fait via la commande dpkg :

dpkg -i oracle-java8-jre_8u77_i386.deb

Et voilà ! L’environnement d’exécution java et désormais opérationnel !

Allons directement dans le vif du sujet en créant un fichier Makefile [1] quelque part en amont de votre projet :

Passons rapidement le script en revue

Tout d’abord, on doit éditer le script pour renseigner 2 informations :

• FONT_DIR, qui est l’emplacement du dossier qui va recevoir les éléments issus de fontetto (.ttf, .woff. css, .css, ...), relativement au fichier Makefile. Personnellement j’ai choisi un dossier "icons" dédié à cela, et distinct des polices (webfonts) complètes qui elles sont dans un autre dossier "fonts".
• PROJECT_NAME qui désigne le nom du projet.

A présent, direction fontello.com où vous pouvez commencer à composer votre webfont personnalisée projet_foo. Enregistrez (bouton en haut à droite), téléchargez le .zip et récupérez le fichier config.json (qui est le seul qui nous intéresse) et copiez le dans le dossier FONT_DIR.

À l’usage

À partir de maintenant, l’ajout ou modification d’icônes va se faire en un clin d’oeil via 2 commandes successives, issues du fichier Makefile :

inspecte le fichier config.json et ouvre le navigateur avec les paramètres d’édition sauvegardés.

récupère la version mise à jour du projet_foo en écrasant les anciens fichiers.

Pour ma part, c’est surtout le fichier projet_foo-codes.css avec les codes qui m’importe (voir et modifier au besoin la ligne 32) ; c’est pourquoi je renomme en codes.scss pour l’appeler ultérieurement dans la compilation SASS.

Ajouter un nouveau compte

Une fois le client ftp démarré, on accède aux paramètres des sites en cliquant sur
fichier -> gestionnaire de sites

Une nouvelle fenêtre permettant de gérer les sites s’ouvre. Dans l’encart de gauche, un clic sur le bouton "nouveau" fait apparaître une nouvelle ligne qui permet de nommer la nouvelle connexion de façon arbitraire (NomSite dans l’exemple)

Configuration du nom d’hôte et du port

Une fois le nouveau site ajouté, on configure l’hôte (nomdedomaine.com) puis le port :

Configuration du protocole SFTP

Sélectionner SFTP - SSH File Tranfer Protocol dans la liste des protocoles disponibles

Type d’authentification

Afin d’enregistrer le nom d’utilisateur et le mot de passe de manière définitive on définit le type d’authentification à "normale" :

Couple nom d’utilisateur et mot de passe

Pour finir, on ajoute le nom d’utilisateur et son mot de passe dans les champs prévus à cet effet :

Cliquer sur connexion afin de se connecter au serveur. Lors de la première connexion le message suivant apparaît :

Lorsqu’on se connecte pour la première fois à un serveur ssh/sftp, il est nécessaire d’avoir un échange de clefs entre le client et le serveur. Ce message est normal lors de la première connexion. Ainsi, les fois suivantes, on est certain de se connecter toujours sur le même serveur.

Voilà, si vous n’arrivez pas à vous connecter, Pensez à bien vérifier le port, le nom d’hôte et les identifiants.

Pour changer le mot de passe sans avoir à se connecter au container LXC, Il faut “chrooter” son système de fichier (chroot est disponible dans les paquets coreutils de Debian) .

“Chrooter” le système de fichier du container LXC “NomContainer” :

Générer un nouveau mot de passe root pour le container LXC :

Quitter l’environement "chrooté" :

Attention, si vous utilisez un shell différent de bash tel que zsh, il se peut que vous vous trouviez confronté à cette erreur :
« chroot : impossible d’exécuter la commande « /bin/zsh » : Aucun fichier ou dossier de ce type ».

dans ce cas :

devrait permettre de chrooter le container lxc.

Installation de LXC

Création d’un container

– -n nom du container
– -t template de l’OS à utiliser

Bien noter le mot de passe root qui s’affichera à la fin de la création du container lxc.

Configuration du réseau sur l’hôte

Il y a plusieurs façons de configurer le réseau, pour ma part je préfère créer un (ou plusieurs) sous-réseaux pour mes containers qui seront "natter" par la machine hôte.
Pour illustrer, on pourrait dire que les sous-réseaux sont cloisonnés à l’intérieur de l’hôte qui fera office de pare-feu vers l’extérieur.

Autoriser "l’ip forwarding"

Recharger la configuration du système pour prendre en compte la modification.

Configurer l’interface qui servira de bridge

La paquet bridge-utils est nécessaire, il est normalement installé en dépendance de lxc, au cas ou :

Paramétrage de /etc/network/interfaces

Redémarrer le service réseau afin de prendre en compte la nouvelle interface br0

Vérifier que l’interface réseau est bien présente :
ifconfig devrait renvoyer quelque chose comme ça

Activer le partage de connexion internet pour les containers LXC :

On va donner l’accès internet aux containers LXC à travers wlan0 (On verra comment automatiser ça sur un hôte au profil itinérant qui se connecte sur des interfaces diverses et variées : wlan0 eth0 usb0... )

Configuration du réseau sur les containers LXC

Attention ! il ne s’agit pas de paramétrer le réseau à l’intérieur du container mais d’éditer un fichier de configuration qui se chargera de configurer le réseau au démarrage de celui-ci.

Par défaut, Debian installe les nouveaux containers dans /var/lib/lxc ; ce dossier contient tous les containers créés, qui eux-même contiennent des fichiers de logs, de configs et le dossier rootfs qui comme son nom l’indique, correspond à la racine du système virtualisé ( / ).

Afin de configurer le réseau sur notre container LXC, nous allons éditer son fichier de config /var/lib/lxc/NomContainer
Extrait de la configuration réseau d’un container /var/lib/lxc/NomContainer/config

Démarrage du container et test du réseau

– -n nom du container
– -d en mode daemon

La commande pour contrôler si notre container LXC est bien démarré :

Devrait retourner

Sur l’hôte un petit ping 192.168.100.1 devrait retourner :

On va se connecter directement au container LXC

Se connecter au container, j’espère que vous avez bien noté le mot de passe root lors de sa création sinon vous pouvez toujours consulter l’article dédié au changement de mot de passe root d’un container LXC.
Une fois connecté, on va tester l’accès internet en utilisant apt pour installer ping afin de "pinguer" la machine hôte :

Et voilà, Juste ça marche !

Au sein d’un plugin

Dans le cadre de la création d’un plugin, après avoir déclaré le pipeline dans paquet.xml

Dans le dossier de personnalisation

Dans le dossier squelette habituel, il faut ajouter au fichier mes_fonctions.php une fonction que l’on peut nommer par exemple "redirections_persos".

Puis dans config/mes_options.php on lie notre fonction au pipeline affichage_entetes_final