Articles plus anciens

Par défaut une fois les téléchargements terminés Transmission partage indéfiniment le fichier.

Pour changer ce comportement il faut utiliser les paramètres ratio-limit (= valeur numérique) et ratio-limit-enabled (= true). Dés lors Transmission partagera jusqu’à ce que le ratio téléchargement / partage défini dans ratio-limit soit atteint. Ensuite le fichier sera mis en état arrêté mais restera dans Transmission.

Le script ci-dessous (remove_completed_torrents.sh qui n’est pas de moi voir les sources) à exécuter à intervalle régulier via une tache Cron vérifie l’état des fichiers/torrents et pour ceux qui sont stoppés (dont le ratio de partage est atteint) les déplace dans un autre répertoire (complete dans mon cas, voir mon arborescence de fichier) et les supprime de Transmission

#!/bin/sh
# script to check for complete torrents in transmission folder, then stop and move them
 
AUTH="--netrc=$HOME/.netrc"
 
# either hard-code the MOVEDIR variable here
MOVEDIR=/data/downloads/torrents/complete # the folder to move completed downloads to
# or set MOVEDIR using the first command-line argument
# MOVEDIR=%1
 
# use transmission-remote to get torrent list from transmission-remote list
# use sed to delete first / last line of output, and remove leading spaces
# use cut to get first field from each line
TORRENTLIST=`transmission-remote --list | sed -e '1d;$d;s/^ *//' | cut --only-delimited --delimiter=" " --fields=1`
 
# for each torrent in the list
for TORRENTID in $TORRENTLIST
    do
    echo "* * * * * Operations on torrent ID $TORRENTID starting. * * * * *"
 
    # check if torrent download is completed
    DL_COMPLETED=`transmission-remote $AUTH --torrent $TORRENTID --info | grep "Percent Done: 100%"`
 
    # check torrent’s current state is Stopped, Finished, or Idle
    STATE_STOPPED=`transmission-remote --torrent $TORRENTID --info | grep "State: Finished"`
 
    # if the torrent is Stopped, Finished, or Idle after downloading 100%
    if [ "$DL_COMPLETED" != "" ] && [ "$STATE_STOPPED" != "" ]; then
        # move the files and remove the torrent from Transmission
        echo "Torrent #$TORRENTID is completed."
        echo "Moving downloaded file(s) to $MOVEDIR."
        transmission-remote --torrent $TORRENTID --move $MOVEDIR
        echo "Removing torrent from list."
        transmission-remote --torrent $TORRENTID --remove
    else
        echo "Torrent #$TORRENTID is not completed. Ignoring."
    fi
    echo "* * * * * Operations on torrent ID $TORRENTID completed. * * * * *"
done

Ce script utilise la commande transmission-remote du paquet transmission-cli à installer si ce n’est déjà fait.

Pour certaines opérations transmission-remote à besoin d’informations de connexion (login / mot de passe), plutôt que d’utiliser l’option –auth j’ai préféré utiliser l’option –netrc, il faut donc créer un fichier .netrc dans le home de votre utilisateur (ou si vous souhaitez le mettre ailleurs il faudra modifier la variable AUTH) et y mettre les informations suivantes :

machine localhost login [votre login] password [votre mot de passe]

Du Fait des information sensible de ce fichier on le protégera en faisant un :

chmod 600 ~/.netrc

 

Lorsque l’on exécute le script on aura ce genre de sortie :

./bin/remove_complet_torrent.sh
 * * * * * Operations on torrent ID 1 starting. * * * * *
 Torrent #1 is completed.
 Moving downloaded file(s) to /data/downloads/torrents/complete.
 localhost:9091 responded: "success"
 Removing torrent from list.
 localhost:9091 responded: "success"
 * * * * * Operations on torrent ID 1 completed. * * * * *

 

Rque : dans le script d’origine les fichiers étaient déplacés dès lors que leur statut était stopped ou idle ou finished. J’ai supprimé les 2 premiers statuts sinon les fichiers étaient enlevés alors que le ratio de partage n’était pas atteint…

 

Sources :

Dans le but de mettre une connexion https sur certains de mes sites NGINX je me suis intéressé à la génération du certificat et de la clé nécessaire pour cette opération.

Au fil de mes lectures j’ai pu constater la puissance de la commande openssl permettant de générer ces fichiers mais aussi la difficulté à en appréhender le fonctionnement.

En effet pour réaliser une même tache il est possible de lancer x commandes différentes avec y options différentes.

De même pour passer un site en https, certains décrivent la création d’une clé et d’un certificat auto-signé directement utilisé par le serveur web et d’autres créent d’abord une autorité de certification (sous la forme d’une clé et d’un certificat auto-signé) qu’ils utilisent ensuite pour signer un autre certificat qui lui sera paramétré dans le serveur Web.

Ci-dessous les 3 types d’opérations trouvés :

  • Génération d’un certificat serveur auto-signé (et de sa clé) pour utilisation directe par le serveur web.
  • Création d’une autorité de certification
  • Génération d’un certificat serveur et signature de ce dernier pour une autorité de certification

Pour chacune des ces opérations j’ai listés (non exhaustif) les différentes syntaxes trouvées (j’ai arrangé l’ordre des paramètres pour faciliter la comparaison)

L’objectif de cet article n’est pas de donner un mode opération pour créer un certificat et sa clé (je le ferais dans un autre article) mais il s’agit de mettre en avant la richesse et la difficulté à comprendre ce qui est fait avec la commande openssl…

(il s’agit d’un travail de débroussaillage pour choisir mon mode opératoire)

 

Premier point un peu en dehors du sujet, les extensions des fichiers, on trouve de tout :

  • clé :  key,  pem
  • demande de certificat : csr, pem
  • certificat : crt, pem

Cela montre sans même rentrer dans le détail des commandes la difficulté à s’y retrouver….

 

Création d’un certificat serveur auto-signé

Solution 1 : Génération de la clé et du certificat auto-signé en 1 seule fois

openssl req -x509 -nodes -days 365 -newkey rsa:1024 -out /etc/nginx/conf.d/default.pem -keyout /etc/nginx/conf.d/default.key
chmod 440 /etc/nginx/conf.d/default.pem /etc/nginx/conf.d/default.key

Nginx , SSL et plus encore ..

mkdir /etc/nginx/certificats
cd /etc/nginx/certificats
openssl req -new -x509 -nodes -out mon-site.fr.crt -keyout mon-site.fr.key

 

Solution 2 : en plusieurs commandes

(8)

Génération de la clé, génération de la demande de certificat, suppression de la passphrase et auto-signature du certificat

# cd /usr/local/nginx/conf
# openssl genrsa -des3 -out server.key 1024
# openssl req -new -key server.key -out server.csr
# cp server.key server.key.org
# openssl rsa -in server.key.org -out server.key
# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

 

Création d’une autorité de certification

La création de l’autorité de certification peut se faire en plus ou moins d’étapes, avec divers options voici celles trouvées de ci de là.

Solution 1 : Génération de la clé et du certificat en 1 seule fois

(3)

openssl req -x509 -newkey rsa:2048 -days 1825 -keyout private/cacertkey.pem -out cacert.pem

(4)

openssl req -x509 -newkey rsa:2048 -new -days 3650 -keyout private/cacert.key -out cacert.pem

(6)

openssl req -x509 -new -days 1825 -config openssl.my.cnf -extensions v3_ca -keyout private/myca.key -out certs/myca.crt

Quelques remarque sur ces syntaxes :

-new est optionnel lorsque -newkey rsa:xxx est spécifié (syntaxe 4) , en en effet ce dernier crée une clé et une demande de certificat tandis que -new ne crée que la demande de certificat.

Dans la syntaxe 6 la clé est générée malgré la seul présence de l’option -new qui n’est sensée ne générer que le certificat. Mais en l’absence du mot-clé -key spécifiant une clé à utiliser pour créer le certificat, une nouvelle clé est générée en utilisant les données du fichier de configuration openssl.conf (ici l’auteur précise un autre fichier de configuration à utiliser plutôt que celui standard avec l’option -config)

Enfin il ne s’agit pas d’une demande de certificat qui est généré comme indiqué ci-dessus mais directement un certificat grâce à l’adjonction de l’option -x509

 

Solution 2 : Création de la clé privé puis création du certificat auto-signé

(1)

openssl genrsa -des3 2048 -out /etc/ssl/CA/private/my-ca.key
openssl -req x509 -key /etc/ssl/CA/private/my-ca.key -days 3650 > my-ca.crt

(7)

openssl genrsa -des3 2048 -out elao-ca.key
openssl req -x509 -new -key elao-ca.key -days 3650 -out elao-ca.crt

La différence entre ces 2 sources réside dans l’utilisation de 2 commandes différentes.

  • req qui permet de générer un nouveau (-new) certificat auto-signé (-x509)
  • x509 utilitaire de gestion des certificats (affichage, conversion) utilisé ici pour créer un nouveau certificat (-req)

Et de la méthode sortie (option out contre redirection)

Solution 3 : Création de la clé privé, demande de certificat et signature du certificat

(2)

openssl genrsa -des3 -out ca.key 2048
openssl req -new -key ca.key -out ca.csr
openssl x509 -req -days 3650 -in ca.csr -signkey ca.key -out ca.crt

 

Création d’un certificat serveur et signature par l’autorité de certification

Solution 1 : Création de la clé, suppression du mot de passe, demande de certificat, signature du certificat avec notre autorité

(2)

openssl genrsa -des3 -out server.key 1024
openssl rsa -in server.key -out server.key
openssl req -new -key server.key -out server.csr
openssl x509 -req -in server.csr -out server.crt -CA ca.crt -CAkey ca.key -CAcreateserial

(7)

openssl genrsa -des3 -out elao-server.key 1024
openssl rsa -in elao-server.key -out elao-server.key.insecure
openssl req -new -key elao-server.key -out elao-server.csr
openssl x509 -req -in elao-server.csr -out elao-server.crt -sha1 -CA elao-ca.crt -CAkey elao-ca.key -CAcreateserial -days 3650

L’option -CAcreateserial n’est nécessaire que lors de la signature du premier certificat par notre autorité de certification, elle peut même ne pas être nécessaire du tout si on a créé préalablement le fichier paramétré sous le nome database dans le fichier openssl.conf.

 

Solution 2 : Création de la clé sans mot de passe,  demande de certificat, signature du certificat avec notre autorité

(1)

openssl genrsa 1024 -out www.test.net.key
openssl req -new -key www.test.net.key -out www.test.net.csr
openssl ca -in www.test.net.csr -out www.test.net.crt

Le fait de ne pas mettre l’option -des3 génère une clé directement sans mot de passe

La signature se fait avec la commande ca au lieu de x509, mais je ne comprends pas pas où l’on spécifie que l’on doit utiliser notre autorité de certification, son certificat et sa clé (my-ca.crt et my-ca.key, voir ci-dessus solution 2)

Pour moi avec cette méthode le certificat généré est auto-signé ce qui n’est pas le but recherché.

 

Solution 3 : Création de la clé et de la demande de certificat, signature du certificat avec notre autorité

(3)

openssl req -newkey rsa:2048 -keyout private/server.key -out server-req.pem
openssl ca -in serveur-req.pem -out signedcerts/serveur-cert.pem -cert cacert.pem -keyfile private/cacertkey.pem -days 365

(6)

openssl req -new -keyout private/server.key -out server.csr -config openssl.my.cnf -nodes -days 365
openssl ca -infiles server.csr -out certs/server.crtc -config openssl.my.cnf -policy policy_anything

Concernant les commande de génération de al clé et de la demande de certificat :

  • -new ne crée que la clé sauf si on n’utilise pas l’option -key auquel cas la clé est aussi générée
  • -newkey rsa:xxx crée une clé et un certificat
  • Ce sont des demandes de certificat qui sont générés (contrairement aux commandes que l’on a utilisé pour la création de l’autorité de certification solution 1) car nous n’avons pas l’option -x509
  • L’option -nodes permet d’indiquer que la clé qui doit être générée ne doit pas être protégée par un mot de passe (passphrase)

Enfin les commande de signature des certificats doivent pouvoir être simplifiées comme dans la solution 2 (juste -in et -out)

 

Sources :

  1. et Openssl – générer et signer une demande de signature(CSR) | 404Blog
  2. Autorité de certification openssl et Autorité de certification, le retour
  3. OpenSSL : création et mise en place d’une PKI – K-Tux
  4. Openssl pratique
  5. Nginx , SSL et plus encore ..
  6. Be your own Certificate Authority (CA)
  7. Créer une autorité de certification et des certificats SSL auto-signés
  8. Top 20 Nginx WebServer Best Security Practices

A voir pour les extensions de  fichier :

Source d’info sur les commandes les pages MAN (par contre il faut s’y retrouver avec toutes les options !!)

Image par Erik Pitti (photo de la machine Enigma utilisé par les Allemands lors de la 2de guerre mondial pour crypter leur communication)

Avec Transmission il est possible de gérer 2 modes de vitesse (normal et alternatif : alt)  en téléchargement et en upload et de planifier selon les heures et jour la bascule entre ces 2 modes (voir le paragraphe Vitesse de mon article Installer et configurer Transmission en tant que démon) La bascule entre ces 2 modes est aussi paramétrable selon les jours et les heures.

Bien que très pratique ce mécanisme n’est pas optimal en effet Transmission passe d’un mode à un autre pour une plage horaire et certains jours données or mon besoin est que Transmission passe du mode normal (sans limitation) au mode alternatif (vitesses limités, mode turtle/tortue) uniquement si un des mes PC est allumé, préservant ainsi ma bande passante pour pouvoir avoir un usage normal d’Internet.

Et dès que tous les PCs sont éteint on re-bascule en mode normal.

Voici le script que j’ai fait :

#!/bin/bash
 
cd $(dirname "${0}")
 
while read HOST_IP;
do
    ping -c 5 -w 15 $HOST_IP > /dev/null
    RESULT=$?
 
        if [ $RESULT -eq 0 ]; then
            break
        fi
 done < alt_speed_IP
 
if [ $RESULT -eq 0 ]; then
    echo "At least 1 computer on, set alt speed"
    transmission-remote -as
else  
    echo "no computer on, max speed"
    transmission-remote -AS
fi

Ce script attend un fichier alt_speed_IP contenant un liste d’adresse IP à surveiller (1 par ligne)

Pour chacun des adresses IP il essai de les pinguer, si au moins une adresse répond c’est qu’au moins un ordinateur de « bureau » est allumé et qu’il faut mettre Transmission en mode tortue pour préserver la bande passante.

Si au terme du ping de toutes les adresse du fichier alt_speed_IP aucun ordinateur n’a répondu Transmission peut repasser en mode normal.

Le changement de mode se fait avec la commande tranmission-remote du paquet transmission-cli…

 

Source :

Image par Stephen D’Agostino – its time to organize a show sous CC BY-NC-ND

J’ai déjà parlé de NGINX, ce formidable serveur web rapide et surtout léger installé sur mon Dockstar.

J’ai aussi installé logrotate sur mon serveur, outil qui permet de faire tourner et d’archiver les fichiers de logs

Pour que les 2 fonctionnent ensemble il faut ajouter une configuration dans logrotate pour qu’il prennent en compte NGINX, ce dernier n’étant pas reconnu par logrotate lors de son installation.

Il faut donc créer un fichier nginx sous /etc/logrotate.d/ et y coller ceci (à adapter) :

/var/log/nginx/*.log {
	#rotate the logfile(s) daily
	daily
	# adds extension like YYYYMMDD instead of simply adding a number
	dateext
	# If log file is missing, go on to next one without issuing an error msg
	missingok
	# Save logfiles for the last 10 days
	rotate 10
	# Old versions of log files are compressed with gzip
	compress
	# Postpone compression of the previous log file to the next rotation cycle
	delaycompress
	# Do not rotate the log if it is empty
	notifempty
	#after logfile is rotated and nginx.pid exists, send the USR1 signal
	postrotate
		[ ! -f /var/run/nginx.pid  ] || kill -USR1 `cat /var/run/nginx.pid`
	endscript
}

C’est la directive postrotate qui est spécifique à NGINX et qui est importante : une fois les log tournées / archivées on lance un signal d’arrêt à NGINX pour qu’il recrée les fichiers de logs.

On testera la configuration avec la commande :

sudo logrotate -d /etc/logrotate.d/nginx

Voila pour le paramétrage de base.

 

J’y ai personnellement ajouté l’appel à un script de mon crû avant que logrotate ne fasse tourner les logs.

Ce script analyse les logs d’accès de NGINX et effectue une petite analyse des IPs et des utilisateurs qui se connectent :

#!/bin/bash
cd $(dirname "${0}")
log=[nom et chemin du fichier log]
 
date > $log
echo -e "\n"  >> $log
 
for file in /var/log/nginx/*access.log
do
     echo ${file} >> $log
 
     echo -e "\nNb accès par IP" >> $log
     cat ${file} | awk '{print $1}' | sort | uniq -c  >> $log
     sed -i 's/\(81..125.231.15$\)/\1 : Travail/' $log
     sed -i 's/\(89.5.45.52$\)/\1 : Maison/'  $log
 
     echo -e "\nNb accès par utilisateur" >> $log
     cat ${file} | awk '{print $3}' | sort | uniq -c >> $log
 
     echo -e "\n-------------------------\n" >> $log
done

 

qui produit ce genre de rapport :

jeudi 14 avril 2011, 13:35:21 (UTC+0200)
 
/var/log/nginx/access.log
 
Nb accès par IP
1 121.162.199.215
6 192.168.1.100 : Maison
1 208.80.194.29
1 222.187.222.26
 
Nb accès par utilisateur
4 -
5 mon_utilisateur
 
-------------------------
/var/log/nginx/xxxx.access.log
 
Nb accès par IP
250 125.54.42.12
 
Nb accès par utilisateur
250 utilisateur2
-------------------------
/var/log/nginx/yyyy.access.log
Nb accès par IP
Nb accès par utilisateur
-------------------------

Pour prendre en compte ce script et le faire exécuter j’ai ajouté les directives suivantes au fichier nginx de logrotate  :

# scripts are runned only once
sharedscripts
 
# before rotation log are analyzed
prerotate
    /chemin/statistiques_nginx.sh
endscript

Ainsi avant de faire tourner les logs NGINX logrotate exécute une seule fois le script que j’ai nommé statistiques_nginx.sh. Ce dernier produit un rapport que je m’envoie par email (via un autre script)

 

A noter qu’il existe des solutions clé en main et beaucoup plus évoluées, complètes d’analyse et de statistiques pour les logs des serveurs Web (voir dans les sources), mais cela me semble un peu trop pour mon usage.

 

Sources :

Logrotate :

Autres solutions de rotation des logs :

Script analyse des logs :

Analyse des logs plus évoluées :

Les études (déclinaison des 3 lettres V A A stylisées)

Le nouvel avatar :

Un peu plus beau (les goûts les couleurs…) et moderne que le précédent :