Tech de Gamuza

Compiler imagemagick pour ajouter les delegated

Christophe — 2023-09-14T08:33:18Z

# tranformer une image (jpg) en pdf
Si la commande convert toto.jpg toto.pdf
vous renvoie l'erreur :
>ImageMagick : No decode delegate for this image format

cela veut dire que imagemagick n'est pas compilé avec les bons delegates
la commande convert -list configure | grep DELEGATES ne doit pas vous retourner jpeg

Pour résoudre ce problème, il faut compiler le paquet à la main :

sudo apt update sudo apt install build-essential sudo apt install -y libjpeg-dev wget https://www.imagemagick.org/download/ImageMagick.tar.gz tar xvzf ImageMagick.tar.gz cd ImageMagick-[version_number] ./configure --disable-shared sudo make sudo make install sudo make check

Configurer awstats pour utilisation avec tous les vhost d'un serveur apache

clem — 2015-11-12T01:32:09Z

Sur une installation "standard" d'awstats (version 7.1) réalisée selon l'indispensable tutoriel proposé par http://technique.arscenic.org/monitoring/awstats/article/installation-et-configuration-de, on souhaite que tous les virtuals hosts aient accès à leurs statistiques awstats avec une url de la forme : http://mon-domaine.tld/awstats/

Configuration générale : fichier /etc/apache2/apache2.conf

Le ScriptAlias et la directive Directory pour envoyer l'URL /awstats/ du vhost vers le script awstats.pl et protéger son accès par mot de passe

ScriptAliasMatch ^/awstats(.*) /usr/lib/cgi-bin/awstats.pl  AllowOverride None Order allow,deny Allow from all AuthUserFile /etc/awstats/users.pwd AuthName "Acces reserve" AuthType Basic Require valid-user

L'alias et la directive "Directory" pour que les images soient servies par le bon répertoire

Alias /icon/ /usr/share/awstats/icon/  Options None AllowOverride None Order allow,deny Allow from all

Configuration d'un vhost : le fichier /etc/awstats/mon-domaine.tld.conf minimum

On suppose que :

ce vhost mon-domaine.tld a la configuration suivante dans son fichier vhost :

 DocumentRoot /chemin/repertoire/vhosts/mon-domaine.tld/html CustomLog /chemin/repertoire/vhosts/mon-domaine.tld/logs/access.log combined LogFormat "%h %l %u %t \"%r\" %>s %b" common

qu'il existe un dossier /chemin/repertoire/vhosts/mon-domaine.tld/awstats qui stockera les fichiers générés par awstats.

Dans ces conditions le fichier /etc/awstats/mon-domaine.tld.conf aura comme configuration minimum :

# AWSTATS CONFIGURE FILE 7.1 LogFile="/chemin/repertoire/vhosts/mon-domaine.tld/logs/access.log" SiteDomain="mon-domaine.tld" HostAliases="www.mon-domaine.tld" DirData="/chemin/repertoire/vhosts/mon-domaine.tld/awstats"

La création d'un accès pour un utilisateur se fera par ajout d'un compte dans /etc/awstats/users.pwd avec la commande htpasswd, par ex pour un utilisateur toto avec le mot de passe LeSecret :

htpasswd -b /etc/awstats/users.pwd toto LeSecret

Créer et configurer une paire de clés SSH pour la synchronisation entre 2 serveurs

Christophe — 2015-10-01T12:12:40Z

Création d'un user spécifique sur les 2 serveurs
useradd --home /home/toto --password mon_super_motdepasse toto
Du serveur de production (PROD) vers le serveur de backup (SAUVE)

Remarque : dans toutes les commandes ssh, l'option -p permet de préciser le port de connexion ssh si différent de 22.
1. Sur le serveur PROD :
  - Générer une paire de clés publique/privée sans mot de passe avec le compte utilisé pour la synchro (toto par ex)
    ssh-keygen -t rsa
    
    nom du fichier de clé =/home/toto/.ssh/ id_rsa_rsync
    pass = vide pour connexion auto de rsync
  - Envoyer sa cle privé sur le serveur SAUVE ssh-copy-id -i ~/.ssh/id_rsa_rync.pub '-p 1234 toto@serveur-sauve.tld'
2. Sur le serveur SAUVE :
  - Ajouter les options de limitation de connexion en début de la ligne de la clé dans le fichier authorized_keys : from="1.2.3.4,...liste des IP autorisées séparées par une virgule"
3. Sur le serveur PROD :
  - Tester la connexion vers SAUVE avec la clé : ssh -i /home/toto/id_rsa_rsync -p 1234 toto@serveur-sauve.tld
  - Tester le rsync via ssh + fichier de la clé privée : (dans /home/toto on crée un rép /test avec 1 ou 2 fichiers dedans) mkdir test cd test touch fichier1 fichier2 rsync -e "ssh -i /home/toto/.ssh/id_rsa_rsync -p 1234" ./* toto@serveur-sauve.tld:/home/toto
    On doit retrouver tous les fichiers de /test de la source dans le dossier /toto du serveur de SAUVE
  - Créer un fichier cron_synchro.sh dans /home/toto et le rendre exécutable #!/bin/bash rsync -e "ssh -i /home/toto/.ssh/id_rsa_rync -p 1234" -az /home/toto/test/ toto@serveur-sauve.tld:/home/toto
  - Générer le crontab de toto pour lancer cron.sh (par ex ici à 1h12 toutes les nuits) crontab -e 12 1 * * * cd ~/ && ./cron_synchro.sh > /dev/null

Générer un fichier de commandes SVN et GIT pour l'installation d'un ensemble de plugins à partir de ceux d'un SPIP existant

clem — 2015-09-28T22:54:26Z

Pour le détail de la construction de la commande sed (qui est le truc compliqué de l'affaire...) voir :
http://www.commentcamarche.net/faq/...

#!/bin/bash # # Génère un sh avec les "git clone" de tous les plugins d'un SPIP # # chaque ligne du fichier générée est de la forme: # git clone https://github.com/nom_repo/nom_plugin.git nom_plugin # # ce fichier sera lancé dans le rep plugins/ d'un SPIP # # chemin du répertoire des plugins du SPIP REP_PLUGINS=./ # chemin du fichier sh à créer FICHIER_SH=./dupliquer_plugins.sh # initialiser le fichier echo "# commandes des plugins a installer" > $FICHIER_SH for i in <code class='spip_code spip_code_inline' dir='ltr'>ls $REP_PLUGINS</code>; do if [ -d $REP_PLUGINS/$i/.git ]; then grep "url" $REP_PLUGINS/$i/.git/config |sed 's/.*url = /git clone /;s/.*\/\([^\/]*\).git$/\0 \1/' >>> fi done # passer le fichier sh en executable chmod +x $FICHIER_SH

Une fois ce script lancé en étant dans le sous dossier plugins, on récupère le fichier dupliquer_plugins.sh généré dont le contenu ressemblera à :

svn co svn://zone.spip.org/spip-zone/_plugins_/acces_restreint/trunk acces_restreint svn co svn://zone.spip.org/spip-zone/_plugins_/adaptive_images/trunk adaptive_images git clone https://github.com/nursit/home.git home svn co svn://zone.spip.org/spip-zone/_plugins_/agenda/trunk agenda svn co svn://zone.spip.org/spip-zone/_plugins_/alias alias git clone https://github.com/nursit/bank.git bank ...

Il ne reste plus qu'a transférer ce fichier dans le répertoire plugins/ du nouveau SPIP, et le lancer en ligne de commande pour avoir les mêmes plugins installés.
On peut également décider de supprimer un certain nombre de lignes correspondantes aux plugins que l'on ne souhaite pas installer.

TODO :

ajouter la récupération de la branch git en cours : cf https://stackoverflow.com/a/11868440 git rev-parse --abbrev-ref HEAD ou git status | head -1
et intégrer l'appel de branche dans le git clone :
git clone --branche xxxx url

Alternative si vos plugins ne sont pas installés en ligne de commande :
voir l'astuce d'Eliaz blog : Migrer facilement ses plugins d'un SPIP à un autre

Sortir un fichier texte avec la liste de toutes les URLs des dépots SVN des plugins d'un SPIP

clem — 2015-09-26T17:08:34Z

#!/bin/bash
#
# récupérer un txt avec les URL SVN de tous les plugins du répertoire plugins/ d'un SPIP
# # chemin du répertoire des plugins du SPIP
REP_PLUGINS=/var/www/ma-mutu.tld/plugins # chemin du fichier txt à créer
FICHIER_TXT=/home/clem/liste_urls_svn_plugins.txt svn info $REP_PLUGINS/* |grep "^URL" > $FICHIER_TXT

On peut aller plus loin dans l'automatisation du transfert d'un ensemble de plugins installés avec SVN en générant directement le fichier sh de checkout à partir de ce svn info : voir Générer un fichier de commandes SVN et GIT pour l'installation d'un ensemble de plugins à partir de ceux d'un SPIP existant