PROJET AUTOBLOG


Planet-Libre

source: Planet-Libre

⇐ retour index

Renault : Participez à la journée de test de Fedora 25 sur les images Cloud et Atomic

lundi 24 octobre 2016 à 14:15

Aujourd'hui, ce lundi 24 octobre, est une journée dédiée à un test précis : sur les images Cloud et Atomic de Fedora. En effet, durant le cycle de développement, l'équipe d'assurance qualité dédie quelques journées autours de certains composants ou nouveautés afin de remonter un maximum de problèmes sur le sujet.

Elle fournit en plus une liste de tests précis à effectuer. Il vous suffit de les suivre, comparer votre résultat au résultat attendu et le notifier.

Qu'est-ce que c'est ?

Les images clouds sont en fait des images d'installation de Fedora dédiée au Cloud. À l'instar de Workstation qui est la version de base, et Server pour les serveurs, Cloud fait parti des produits de Fedora pour gérer des cas d'utilisations spécifiques et offrir une expérience utilisateur cohérente autour de ceux-ci.

La particularités des images clouds sont d'être légères pour être instanciées plusieurs fois dans une même machine via des machine virtuelles ou autre solution similaire.

Les tests du jour couvrent :

Comment y participer ?

Vous pouvez vous rendre sur la page des tests pour lister les tests disponibles et rapporter vos résultats. La page wiki récapitule les modalités de la journée.

En cas de bogue, il est nécessaire de le rapporter sur le BugZilla. Si vous ne savez pas faire, n'hésitez pas à consulter la documentation correspondante.

De plus, si une journée est dédiée à ces tests, il reste possible de les effectuer quelques jours plus tard sans problème ! Les résultats seront globalement d'actualité.

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

Angristan : Seedbox : installer le client torrent Flood sous Debian 8

lundi 24 octobre 2016 à 11:42

Seedbox : installer le client torrent Flood sous Debian 8

L'autre jour je vous présentait l'installation de Transmission, un client de torrent basique, mais stable, et très facile à installer. Pour ceux d'entre vous qui sont prêts à passer un peu plus de temps pour avoir un client plus performant et plus design, voici Flood ! C'est une interface web en nodejs ( :-? ) pour rTorrent, un client en lignes de commandes qui est stable et léger, et qui est souvent utilisé avec Rutorrent, une interface web qui elle est en PHP (mais moins jolie !). Pour ceux qui veulent voire à ça ressemble, j'ai mis une petite galerie à la fin de l'article. :)

Une Seedbox ?

Une seedbox est un serveur dédié au téléchargement et au partage de fichiers torrents. Flood est une interface web qui nous permet de télécharger ces fichiers. Pourquoi avoir une seedbox ? Le fait que ce soit un serveur signifie que : • vous avez beaucoup de stockage • vous avez beaucoup de bande passante, donc des téléchargements rapides • vous n’êtes pas surveillés par HADOPI • vous pouvez regarder vos films ou séries en streaming depuis votre serveur.

Installation de rTorrent et libTorrent

Flood n'étant qu'une interface web pour rTorrent, nous allons d'abord devoir l'installer.

Depuis les dépôts

rTorrent est disponible dans les dépôts de Debian en version 0.9.2 et libTorrent en version 0.13.2, sachant que les dernières versions disponibles, même si elles ont plus d'un an, sont respectivement la 0.9.6 et 0.13.6, qui elles sont disponibles sous Debian Sid et Stretch. Si vous avez la flemme de compiler vous pouvez tout de même les installer :
apt install rtorrent

Depuis les sources

Ainsi pour avoir les dernières versions, on peut compiler rTorrent et libTorrent directement depuis les sources. On installe les dépendances :
apt install build-essential subversion autoconf g++ gcc ntp curl comerr-dev pkg-config cfv libtool libssl-dev libncurses5-dev ncurses-term libsigc++-2.0-dev libcppunit-dev libcurl3 libcurl4-openssl-dev
XML-RPC permet rTorrent de communiquer avec Flood. On le télécharge :
svn co -q https://svn.code.sf.net/p/xmlrpc-c/code/stable /tmp/xmlrpc-c
On le compile :
cd /tmp/xmlrpc-c
./configure
make -j $(nproc)
On l'installe :
make install
On télécharge libTorrent :
cd /tmp
curl http://rtorrent.net/downloads/libtorrent-0.13.6.tar.gz | tar xz
On le compile :
cd libtorrent-0.13.6
./autogen.sh
./configure
make -j $(nproc)
Et on l'installe :
make install
On télécharge rTorrent :
cd /tmp
curl http://rtorrent.net/downloads/rtorrent-0.9.6.tar.gz | tar xz
On le compile :
cd rtorrent-0.9.6
./autogen.sh
./configure --with-xmlrpc-c
make -j $(nproc)
Et on l'installe :
make install
ldconfig
Vous êtes toujours là ?  :lol:

Configuration de rTorrent

On ajoute un utilisateur pour éviter de lancer rTorrent en root :
adduser --disable-password rtorrent
On édite la configuration de rTorrent :
nano /home/rtorrent/.rtorrent.rc
Et on ajoute ceci :
# Vitesse de téléchargement max up/down, en KiB. "0" équivaut à aucune limite. 
download_rate = 0
upload_rate = 10000

# Nombre maximal de téléchargements simultanés
max_downloads_global = 10

# Nombre maximal de peers par torrent
max_peers = 100

# Nombre maximal de peers à upload par torrent
max_uploads = 20

# Répertoire qui contient les fichiers téléchargés.
directory = /srv/seedbox/downloads

# Répertoire où rtorrent stocke l'état de téléchargement des torrents.
session = /srv/seedbox/.session

# Ports utilisables par rTorrent. 2x la même valeur = 1 port
port_range = 49999-49999
port_random = no

# Vérification des données à la fin du téléchargement
check_hash = yes

# Activation de DHT pour les torrents sans trackers.
# À désactiver si vous utilisez des trackers privés
dht = auto
dht_port = 6881
peer_exchange = yes

# On préfère les échanges avec chiffrement
encryption = allow_incoming,try_outgoing,enable_retry

# On autorise les trackers UDP
use_udp_trackers = yes

# Port SCGI, on en a besoin pour communiquer avec Flood
scgi_port = 127.0.0.1:5000
On n’oublie pas de créer les dossiers qui vont bien :
mkdir /srv/seedbox
mkdir /srv/seedbox/downloads
mkdir /srv/seedbox/.session
Et on applique les bonnes permissions à tout ça :
chmod 775 -R /srv/seedbox
chown rtorrent:rtorrent /srv/seedbox
Il faudra démarrer rTorrent à la main. J'aurai préféré le faire avec des services, mais ceux que j'ai trouvé ne marchent pas du tout, ou à moitié, et j'ai pas les connaissances nécessaires pour les débugger. De toute façon ils utilisaient screen ou dtach. Si quelqu'un passe par là et a un script d'init qui fonctionne, je suis preneur. :) On va utiliser screen :
apt install screen
screen nous permet de créer des terminaux virtuels, de les laisser tourner en arrière plan, et d'y revenir quand on veut. Personnellement je m'en sert très souvent pour des processus un peu longs. :) On crée le terminal du nom de "rtorrent" comme ceci :
screen -S rtorrent
On y entre automatiquement. Ensuite on change d'utilisateur :
su - rtorrent
Et on lance rTorrent :
rtorrent
Pour arrêter rTorrent, il faut faire ctrl + q. Pour quitter screen sans cloturer le terminal, il faut faire ctrl + a puis d. Pour clôturer le terminal, il faut fermer rTorrent puis écrire exit et le screen se fermera tout seul. Vous reviendrez ensuite dans votre "ancien terminal" qui n'a pas bougé non plus. Pour retourner dans le screen de rTorrent :
screen -r rtorrent
Et même manip' pour le quitter ou le fermer.

Installation de Flood

On passe au morceau qui nous intéresse : l'interface web. C'est du nodejs, donc il va falloir installer ce dernier :
curl -sL https://deb.nodesource.com/setup_4.x | sudo -E bash -
sudo apt-get install -y nodejs
Ensuite, on installe git :
apt install git
Puis on va récupérer le code source de flood :
mkdir /srv/seedbox
cd /srv/seedbox
git clone https://github.com/jfurrow/flood.git
On ajoute la conf de flood :
cd flood
cp config.template.js config.js
On l'installe :
npm install --production
Là non plus, pas de script d'init, j'ai essayé avec forever pour les connaisseurs mais ça ne marche pas. Je n'ai pas réussi à faire de script d'init, d'autant plus que le dev lui même conseille d'utiliser screen... donc maintenant que l'on connait, autant en profiter. J'ai quand même ouvert une issue à ce sujet. On ajoute un utilisateur pour éviter de lancer flood en root par la suite :
adduser --disable-password flood
On crée un screen :
screen -S flood
On change d'utilisateur :
su - flood
Puis on lance flood :
cd /srv/seedbox/flood
npm run start:production
(Vous pouvez sortir du screen avec ctrl + a puis d par la suite) Flood est désormais accessible via http://IP_DU_SERVEUR:3000 À votre première connexion il vous sera demandé de créer un compte, et puis après, vous êtes prêts à faire chauffer la connexion !  :-D

Mettre à jour Flood

Il suffit de récupérer le nouveau code et de relancer flood.
screen -r flood
ctrl + c pour l'arrêter puis ctrl + a et d pour sortir de flood
cd /srv/seedbox/flood
git pull
Vous devriez vérifier au cas où il y ait des changements dans config.sample.js. On met à jour flood :
npm install --production
Et on le relance :
screen -r flood
npm run start:production

Docker

Si vous êtes un adepte de Docker, une image "officielle" est en cours de discussion ici, et WonderFall en a fait une très bien ici. D'ailleurs, je me tâte à faire ma seedbox sous Docker moi. ^^

Reverse proxy Nginx avec HTTPS

Vous me connaissez, tant qu'on y est, autant faire les choses proprement : accéder à Flood via un domaine, le tout en HTTPS ! Pré-requis : avoir un domaine/sous domaine qui pointe l'IP du serveur. Ici je prends comme exemple seedbox.hadopi.fr.   8-)

Installation de Nginx

On suit mon petit guide :
wget -O - https://nginx.org/keys/nginx_signing.key | apt-key add -
echo "deb http://nginx.org/packages/debian/ $(lsb_release -sc) nginx" > /etc/apt/sources.list.d/nginx.list
apt update
apt install nginx

Génération d'un certificat avec Let's Encrypt

On suit aussi mon petit gui... Oups, j'en ai pas encore fait :lol: On installe l'outil depuis les backports de Debian :
echo "deb http://httpredir.debian.org/debian jessie-backports main" >> /etc/apt/sources.list
apt update
apt install -t jessie-backports letsencrypt
On arrête Nginx pour laisser le port 80 libre :
service nginx stop
On génère le certificat :
letsencrypt certonly -d seedbox.hadopi.fr --agree-tos -m contact@hadopi.fr --rsa-key-size 4096 --standalone
On configure nginx :
nano /etc/nginx/conf.d/seedbox.conf
Et hop (à adapter bien sûr) :
server {
 listen 80;
 server_name seedbox.hadopi.fr;
 return 301 https://seedbox.hadopi.fr$request_uri;

 access_log /dev/null;
 error_log /dev/null;
}

server {
 listen 443 ssl http2;
 server_name seedbox.hadopi.fr;

 access_log /var/log/nginx/seedbox-access.log;
 error_log /var/log/nginx/seedbox-error.log;

 location / {
  proxy_pass http://127.0.0.1:3000/;
  proxy_set_header Connection "";
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_pass_header X-Transmission-Session-Id;
 }

 ssl_certificate /etc/letsencrypt/live/seedbox.hadopi.fr/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/seedbox.hadopi.fr/privkey.pem;
 ssl_trusted_certificate /etc/letsencrypt/live/seedbox.hadopi.fr/chain.pem;

 ssl_protocols TLSv1.2;
 ssl_ecdh_curve secp384r1;
 ssl_ciphers EECDH+AESGCM:EECDH+AES;
 ssl_prefer_server_ciphers on;
 resolver 80.67.169.12 80.67.169.40 valid=300s;
 resolver_timeout 5s;
 ssl_stapling on;
 ssl_stapling_verify on;
 ssl_session_cache shared:SSL:10m;
 ssl_session_timeout 5m;
 ssl_session_tickets off;
}
Et peut démarrer Nginx :
service nginx start
Et voilà ! J'avoue, l'article est un peu long, mais ça vaut le coup non ? Pouvoir télécharger des ISO Linux avec style, c'est pas donné à tout le monde. 8-) Je vous laisse avec quelques captures d'écran (ce client tellement bien fini, y'a même des petites animations) : [gallery columns="4" link="file" ids="3657,3650,3652,3659,3651,3646,3654,3647,3653,3658,3648,3656,3655"] J'adore ! Dans un prochain article, on verra comment streamer tout ça depuis sa seedbox. À suivre ! Sources :

L'article Seedbox : installer le client torrent Flood sous Debian 8 a été publié sur Angristan

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

cm-t : Après 3 épisodes des Directs du Jeudi : Elle bondis la souris !

lundi 24 octobre 2016 à 10:00
Après 3 épisodes des Directs du Jeudi : Elle bondis la souris !

Les Chiffres

 

 

Les actualités

 

 

 

On se retrouve bientôt pour des épisodes à propos d’actualités autour d’Ubuntu et des logiciels libre !

 

Gravatar de cm-t
Original post of cm-t.Votez pour ce billet sur Planet Libre.

Tuxicoman : Définir la carte son de sortie d’une application spécifique avec Pulseaudio

lundi 24 octobre 2016 à 08:56

J’ai découvert une fonctionnalité sympa de Pulseaudio, on peut choisir la sortie de chaque application séparément ;-)
Ça me permet de lancer un jeu vidéo ou une conversation mumble dans mon casque tout en diffusant de la musique ou un film dans le salon via une autre carte son.
Si vous démarrez le « Control de volume Pulseaudio » (pavucontrol), vous pouvez choisir la carte son et le volume de sortie de chaque application indépendamment :

pulseaudio-multiple-outputJe ne crois pas que Windows puisse faire ça.

Related Posts:

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

Articles similaires

Marthym : Sauvegarde de données personelle

lundi 24 octobre 2016 à 02:00

Introduction

J’ai récemment déménagé et au passage changé de box, de configuration réseau et tant qu’à tout refaire, j’en ai profité pour revoir l’organisation de mes sauvegardes perso. Je n’ai pas écrit grand-chose depuis un moment, alors pourquoi pas en faire profiter pour faire un billet rapide sur les quelques trucs sympas que j’ai changé.

Les besoins

Voyons déjà ce qui est important en matière de préservation de nos données personnelles. Pour une sécurité minimale, les données doivent être dupliquées sur au moins deux supports physiques. On parle là de deux copies faciles d’accès, sur le PC de tous les jours et sur un disque secondaire. Les données doivent être facile à restaurer et à synchroniser.

Pour une sécurité optimale, une copie distante, situé physiquement dans un lieu différent est importante. Envoyé sur le cloud par exemple, cette copie n’a pas besoin d’être facile ou rapide d’accès. Par contre selon le lieu du stockage, il faudra sans doute crypter.

Enfin un accès distant aux données est uns fonctionnalité sympa qui permet d’accéder à ses photos ou vidéo même en voyage.

Le matériel

Un vieux PC fixe de 7 à 8 ans, avec quelques modifications se reconvertit en NAS.

Suppression du matériel inutile, lecteur DVD et carte graphique, ça gagne en consommation et en décibels. Ensuite, ajout de disque conséquent et adapté, j’ai opté pour 2x Western Digital Red 2 To, des disques fait pour rester allumé en permanence, taillés pour les NAS et j’en suis vraiment très content. Les deux seront monté en RAID 10.

J’ai aussi ajouté une ventilateur plus silencieux que l’original car le PC est dans le salon et le ventilo original soufflait un peu. J’ai pris conseil sur cette page (elle est moche mais bien pratique et pleine de bonnes infos), et j’ai choisi un Arctic Freezer 13 pour son rapport taille efficacité.

Le système

Pour la partie système, le NAS tourne sous FreeNAS. Certes il y a d’autres système pour NAS, comme OpenMediaVault par exemple, et de bonnes raisons de les choisir. Les avis divergents et je vais pas rentrer dans une justification. FreeNAS répond au besoin, et de ce que j’en ai vu ça ét là il est ultra robuste et éprouvé. Parmi les fonctionnalités particulièrement appréciables on trouve :

Le fonctionnement

Duplication et accès distant aux données

J’ai longtemps utilisé ownCloud pour répondre à ces besoins. Installé dans une jail de FreeNAS, ownCloud fournit une interface de visualisation des données, un accès WebDAV et des clients de synchronisation pour un peu tous les OS du marché. Cependant je n’ai jamais été pleinement satisfait par owncloud.

Son client Windows est une horreur, si la quantité de fichiers à synchroniser est trop grande, il met plus de temps à chercher les différences que la plage d’intervale de synchronisation. Ce qui a pour conséquence une suppression pure et simple des fichiers en retard lors de la plage de synchro suivante. Sous Linux c’est un peu différent car le client utilise inotify et la synchro est en temps réel.

Dernièrement sous Linux le client se déconfigure et à chaque redémarrage il faut resaisir l’URL du serveur et les login/password.

Enfin, des dissensions au sein du projet ont engendré un fork NextCloud. Ce genre de chose est rarement de bon augure pour un projet, les utilisateurs en sont divisés et la pérénnité des projets est douteuse. Pour des projets garant de vos données personnelles ce n’est pas engageant.

C’est pourquoi après quelques recherches d’alternative, je me suis tourné vers une solution un peu différente, en séparant la partie duplication de la partie accès distant.

Duplication des données

C’est la base de la sauvegarde, les données doivent a minima se trouver sur deux supports différents pour s’assurer qu’il n’y aura pas de perte si un disque ou un PC tombe en panne.

Donc les données sont biensur sur mon portable de tous les jours, c’est de là que je les utilise, et elles sont aussi dupliquées sur le NAS. Sur les deux disques en RAID 10 (stripper + mirroré).
Je voulais une synchro bidirectionnelle car quand je ne suis pas chez moi il m’arrive de mettre à jour les données directement sur le NAS. rsync n’est pas adapté à la synchronisation bidirectionnelle et les clients de synchro sont rares et souvent peu fiables (cf. ownCloud). Mais il y a Syncthing, un clone libre de BittorentSync. Ca fonctionne à partir du protocole … Torrent donc, c’est décentralisé et particulièrement efficace. Ca fonctionne sur un réseau local comme depuis internet et tous les échanges sont crytpés. A la base c’est plus pour le partage que la synchronisation de backup mais ça fait le taff à merveille.

J’ai donc Syncthing qui tourne sur mon portable et dans une jail du NAS (il existe une version pour FreeBSD) et les deux se synchronisent. Malgré la quantité de données il n’y a pas eu de cafouillage, ça va vite et c’est léger. L’installation ne présente pas de difficulté particulière mais la configuration entre les machines synchronisées est un peu moins intuitive, je m’y suis pris à deux fois.

J’ai choisi de splitter la synchro en plusieurs répertoires, ça permet de paralléliser la synchro, c’est un peu plus long à configurer mais ça fonctionne beaucoup mieux.

Le site du projet est clair sur le fait que c’est plus un outil de partage que de backup notamment parce qu’il n’historise pas (en fait si mais bon) mais pour l’utilisation que j’en fais c’est le jour et la nuit avec ownCloud. Et en bonus, sans la moindre configuration supplémentaire ça fonctionne aussi depuis l’extérieur du réseau.

Accès à distance aux données

Reste maintenant à pouvoir accéder aux données à distance. Techniquement c’est possible avec Syncthing mais ça implique une duplication complète des répertoires que l’on veut accéder ce qui s’avère plutôt lourd à l’utilisation. J’ai besoin de pouvoir mettre à jour rapidement quelques fichiers et d’en récupérer quelques autres, je ne tiens pas à dupliquer toutes mes données partout ! C’est là qu’intervient le WebDAV. C’est le protocole qui semble le plus adéquat pour ça, plus simple (et rapide ?) que le SFTP. FreeNAS possède cette fonctionnalité de base mais j’ai préféré installer un serveur Nginx à l’interieur d’une Jail, plus sûr en termes d’accès.

Et avec ça j’ai remplacé l’utilisation que je faisais d’ownCloud et c’est beaucoup plus efficace. Reste finalement qu’à placer un frontal pour accéder au différents services dans les jails et configurer la box pour accéder au frontal

Sauvegarde distante

Comme expliqué plus haut, il est rassurant d’avoir ses données dupliqué sur plusieurs supports, ça couvre 90% des risques de perte de données. Mais quand les deux supports sont situés physiquement au même endroit, il reste un risque de perte, un incendie, un cambriolage, … La solution c’est d’exporter les données dans un lieu différent.

Pour ça j’ai prix un compte chez Hubic, rapport espace de stockage / prix imbattable (10To/50€/an). La difficulté c’est que Hubic c’est des serveurs OpenStack ce qui veut dire que tout passe par des APIs REST, pas d’accès FTP ou autres. J’ai déjà fait un billet sur le sujet des backups distants sur HubiC, je vous invite à le lire pour plus d’info sur la façon d’envoyer des sauvegardes sur Hubic.

Sauvegarde de données personelle écrit à l'origine par Marthym pour J'ai acheté un PC neuf cassé ... le October 24, 2016.

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