Shell : créer une liste de mot de passe facilement photo

Shell : créer une liste de mots de passe facilement

Créer une liste de mots de passe simples

Voici un moyen très simple de créer une liste de mots de passe en utilisant le terminal sous Linux ou MacOS par exemple :

for i in `seq 1 8`; do mktemp -u XXXXXXXXXXXXXXXXXXXXXXXX; doneCode language: JavaScript (javascript)

Explications sur le fonctionnement de la commande:

  • seq 1 8 va nous créer 8 mots de passe différents,
  • mktemp -u XXXXXXXXXXXXXXXXXXXXXXXX va nous créer des mots de passe alphanumériques dont le nombre de caractères dépend du nombre de X. Ici, j’ai mis 24 X donc les mots de passe feront 24 caractères.

Créer une liste de mots de passe sécurisés

La méthode précédente n’est pas vraiment sécurisée car le degré d’entropie est trop faible. Pour augmenter le niveau de sécurité, j’utilise cette commande:

for i in $(seq 1 8); do LC_CTYPE=C tr -dc '[:graph:]' < /dev/urandom | tr -d "'" | tr -d '"' | head -c 64 && echo; doneCode language: JavaScript (javascript)

Voici une explication de la commande :

  • for i in $(seq 1 8); do : Cela commence une boucle for qui se répète 8 fois (de 1 à 8).
  • LC_CTYPE=C : Cela définit la variable d’environnement LC_CTYPE à la valeur C, ce qui assure que le générateur de mots de passe utilise le jeu de caractères ASCII.
  • tr -dc '[:graph:]' < /dev/urandom : Cela utilise la commande tr pour supprimer les caractères non imprimables et générer des caractères graphiques aléatoires à partir de /dev/urandom, qui est une source d’entropie aléatoire sur les systèmes Unix.
  • tr -d "'" | tr -d '"' : Cela utilise deux commandes tr supplémentaires pour supprimer les caractères de guillemets simples (') et les guillemets doubles (") des mots de passe générés. Cela garantit que les guillemets simples et doubles sont supprimés des mots de passe générés.
  • head -c 32 : Cela utilise la commande head pour limiter la longueur des mots de passe générés à 32 caractères.
  • && echo; done : Cela termine la boucle for et ajoute un retour à la ligne (echo) pour afficher chaque mot de passe généré sur une ligne séparée.

Simple et efficace, j’utilise souvent cette commande lors de la création ou l’import d’utilisateurs en masse, lors de la création d’un fichier CSV par exemple.

Cela permet d’avoir des mots de passe un minimum sécurisés dès le départ de la création des comptes utilisateurs.

CSS : supprimer subtilement le placeholder d'un champ input ou textarea photo

CSS : supprimer subtilement le placeholder d’un champ input ou textarea

Je viens de finir un projet sur Codeable qui utilisait WordPress et Gravity Forms et lors de la réalisation d’un formulaire de réservation complexe, je me suis heurté à Chrome qui ne supprime pas toujours (suivant les versions utilisées) le texte du placeholder d’un champ de type input ou textarea lorsque le curseur est placé à l’intérieur (action focus).

Normalement, la valeur du placeholder disparaît et permet à l’utilisateur de compléter sa saisie mais sous certaines versions de Chrome, cela ne passe pas bien.

J’ai considéré l’utilisation de JavaScript, évidemment, avant de me rendre compte que l’on pouvait résoudre le problème avec quelques règles CSS natives. Toutes les déclarations sont à ajouter – ne cherchez pas à les compiler, cela ne fonctionnera pas !

On joue donc avec l’opacité et un léger effet de transition pour le côté subtil et smooth :

/* Placeholders */
::-webkit-input-placeholder { opacity: 1; transition: opacity .5s; }  /* Chrome 56, Safari 9 */
:-moz-placeholder { opacity: 1; transition: opacity .5s; } /* FF 4-18 */
::-moz-placeholder { opacity: 1; transition: opacity .5s; } /* FF 19-51 */
:-ms-input-placeholder { opacity: 1; -ms-transition: opacity .5s; transition: opacity .5s; } /* IE 10+ */
::placeholder { opacity: 1; transition: opacity .5s; } /* Modern Browsers */

/* Focus */
*:focus::-webkit-input-placeholder { opacity: 0; } /* Chrome 56, Safari 9 */
*:focus:-moz-placeholder { opacity: 0; } /* FF 4-18 */
*:focus::-moz-placeholder { opacity: 0; } /* FF 19-50 */
*:focus:-ms-input-placeholder { opacity: 0; } /* IE 10+ */
*:focus::placeholder { opacity: 0; } /* Modern Browsers */Code language: CSS (css)

Ps : Chrome souffre également d’un bug qui concerne la fonction autofill qui aide les utilisateurs à pré-remplir les formulaires.

Pensez donc à supprimer les valeurs enregistrées pendant vos tests (Chrome > Paramètres > Paramètres avancés > Confidentialité et sécurité > Effacer les données de navigation > Paramètres avancés > cocher Données de saisie automatique).

Enjoy !

Linux : récupérer des vidéos depuis votre terminal avec MovGrab photo

Linux : récupérer des vidéos depuis votre terminal avec MovGrab

Movgrab est un outil en ligne de commande écrit en C (sans dépendances) qui permet de récupérer facilement des vidéos sur des sites comme YouTube, DailyMotion, Vimeo, Blip.tv, Liveleak, Guardian…

Il permet de choisir les flux disponibles sur les pages vidéo, supporte les proxies, peut reprendre des téléchargements… c’est une application très utile.

Liste des sites supportés par movgrab

Movgrab fonctionne avec:

  • YouTube
  • Metacafe
  • Dailymotion
  • Vimeo
  • Break.com
  • eHow
  • 5min.com
  • vbox7
  • blip.tv
  • Ted
  • MyVideo
  • ClipShack
  • MyTopClip
  • RedBalcony
  • Mobando
  • Yale University
  • Princeton University
  • Reuters
  • LiveLeak
  • Academic Earth
  • Photobucket
  • VideoEmo
  • VideosFacebook
  • Aljazeera
  • Mefeedia
  • IViewTube
  • Washington Post
  • CBS News
  • Euro News
  • MetaTube
  • MotionFeeds
  • Escapist
  • Guardian
  • RedOrbit
  • Sciive
  • Izlese
  • uctv.tv
  • royalsociety.tv
  • British Academy
  • Kitp
  • Dotsub
  • Astronomy.com
  • Teachertube.com
  • Discovery
  • Bloomberg.com

Lire la suite

Calculer le Time To First Byte (TTFB) d'un serveur photo

Calculer le Time To First Byte (TTFB) d’un serveur

Le Time to First Byte (TTFB) est le temps de chargement du premier octet, c’est la mesure qui nous permet d’évaluer la vitesse d’accès à un serveur.

Plus la mesure est basse et plus le serveur commencera à servir les ressources rapidement.

Calculer le Time To First Byte (TTFB) d'un serveur photo

Le ping comme moyen de contrôle

A l’origine le “ping” vient du bruit effectué par l’écho d’un sonar, le temps entre deux ping indiquant la distance parcourue par le signal pour détecter les fonds marins et revenir vers un navire.

Les sons courts n’étaient pas de bons signaux pour un capitaine, puisqu’ils indiquaient que le danger se rapprochait de la coque du navire.

Le ping correspond pour nous au TTFB car il nous permet de mesurer la réactivité d’un serveur ou d’une ressource réseau.

Le ping comme mesure du Time To First Byte

Le TTFB mesure le temps écoulé entre la requête d’un client qui effectue une requête HTTP et le premier octet de la page reçu dans le navigateur du client.

Ce temps se compose du temps de connexion au socket, du temps pris pour envoyer la requête HTTP, et du temps pris pour recevoir le premier octet de la page.

Le calcul du TTFB inclut toujours la latence du réseau lorsqu’il calcule le temps que prend une ressource avant de se charger.

Ce temps varie en fonction de plusieurs critères: l’éloignement entre le serveur et le client, la qualité de la connexion, ou les questions de connexion directe (réseau filaire) ou indirecte (WI-FI, 3G, etc) sont des facteurs modifiant le ping.

Un TTFB faible est perçu comme une indication d’un serveur bien configuré. Cela signifie que moins de calculs dynamiques sont effectués par le serveur ou alors que le cache (DNS, serveur, ou applicatif) est en place.

Calcul to TTFB avec curl

Il existe pas mal de services en ligne qui permettent de calculer le TTFB mais il est aussi très simple de le calculer soi-même, avec un simple terminal avec curl :

curl -o /dev/null -w "Connect: %{time_connect} TTFB: %{time_starttransfer} Total time: %{time_total} \n" https://www.skyminds.netCode language: JavaScript (javascript)

Ce qui nous donne le résultat suivant depuis chez moi:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 54616    0 54616    0     0   153k      0 --:--:-- --:--:-- --:--:--  153k

Connect: 0,039729 TTFB: 0,269024 Total time: 0,347745Code language: CSS (css)

A titre indicatif, si on lance la requête depuis le serveur:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 54616    0 54616    0     0   797k      0 --:--:-- --:--:-- --:--:--  808k

Connect: 0.001645 TTFB: 0.066232 Total time: 0.066848Code language: CSS (css)

On peut voir une sacrée différence, dû au temps de latence et à l’éloignement géographique.

Une autre raison pour laquelle il faut travailler sur la baisse du TTFB : si le TTFB met 270ms en France, à combien sera-t-il pour un visiteur Américain ou Australien ?

Concrètement, plus la connexion au serveur est rapide et plus le site se chargera tôt, ce qui a un fort impact sur le ranking du site. A surveiller donc !

Ajouter un nouveau site WordPress dans un répertoire, sans conflit avec le site principal photo

Nginx : créer un nouveau site WordPress dans un sous-répertoire, sans conflit avec le site principal

Dernièrement, j’ai développé un nouveau site WordPress pour une cliente dont l’hébergement ne prévoit pas de staging site, ce qui est un peu ballot.

Plutôt que d’utiliser son hébergeur, je me suis dit que j’allais travailler sur la nouvelle version depuis un répertoire sous SkyMinds.

Le problème s’est assez rapidement posé : les diverses règles de configuration de SkyMinds (à la racine du domaine) entrent en conflit avec le nouveau site qui se trouve dans un répertoire. Il est donc nécessaire d’ajuster la configuration du bloc serveur NginX.

J’ai bien sûr effectué quelques recherches sur le net et après moults tests, il s’avère que la plupart des configurations nginx que l’on y trouve sont erronées. En relisant les docs, j’ai fini par trouver une solution satisfaisante.

Des erreurs 404, 403 ou 500

Je mentionnais à l’instant les configurations erronées – elles ne permettent pas au nouveau site d’afficher les pages correctement : erreur 404 pour les pages, erreur 404 pour la partie administration ou alors erreur 403 ou même 500…

Le plus surprenant est que l’on retrouve quasiment ces mêmes configurations dans tous les tutoriels. Cela fonctionnait peut-être à une époque mais plus maintenant avec les dernières versions de WordPress et NginX.

La configuration qui fonctionne

Voici donc la configuration que j’ai concoctée et qui permet d’avoir un autre site WordPress (comme par exemple https://example.com/nouveau-site/) lorsqu’un site WordPress (de type https://example.com) existe déjà à la racine du domaine. Le but est donc d’avoir deux sites fonctionnels qui n’entrent pas en conflit au niveau de la gestion des règles.

On édite le server block de notre domaine :

nano /etc/nginx/sites-available/example.com

Dans la partie server de la configuration, on ajoute :


# Script name : Add new WP site in subfolder
# Author : Matt Biscay
# Author URI : https://www.skyminds.net/?p=29604

# Add new location point with rewrite rule
location @nouveausite{
rewrite . /nouveau-site/index.php last;
}

# Add subfolder config
location  /nouveau-site {
         root /home/example/public_html/nouveau-site;
         index index.php;
         try_files $uri $uri/ @nouveausite;
}Code language: PHP (php)

Sauvegardez le fichier. On teste la nouvelle configuration:

nginx -t

et on relance nginx et PHP:

service nginx restart 
service php7.2-fpm restartCode language: CSS (css)

Et voilà, le nouveau site dans son répertoire devrait maintenant être fonctionnel, sans conflit avec le site principal.

Subliminal : résoudre l'erreur "AttributeError: list object has no attribute lower" photo

Subliminal : résoudre l’erreur “AttributeError: list object has no attribute lower”

Dernièrement, le script python que j’ai écrit pour télécharger les sous-titres automatiquement avec Subliminal a renvoyé le message d’erreur suivant :

AttributeError: 'list' object has no attribute 'lower'Code language: JavaScript (javascript)

Il se trouve que l’attribut lower ne peut-être appliqué qu’à des variables (type string) et non pour des objets (type array).

Nous allons donc éditer le code source de subliminal pour corriger le problème.

Ajout de nouvelles directives à subtitle.py

1. On se connecte au Synology en SSH:

ssh admin@SYNOLOGYCode language: CSS (css)

2. On passe root:

sudo -i

3. On recherche le fichier subtitle.py :

find / -type f -name "subtitle.py"Code language: JavaScript (javascript)

Résultat, 3 fichiers trouvés sur le NAS:

/usr/lib/python2.7/site-packages/subliminal/subtitle.py
/volume1/@appstore/VideoStation/subtitle_plugins/syno_subscene/subtitle.py
/volume1/@appstore/subliminal/env/lib/python2.7/site-packages/subliminal/subtitle.py

4. Le fichier qui nous intéresse se trouve sous /usr/lib donc nous l’éditons:

nano /usr/lib/python2.7/site-packages/subliminal/subtitle.py

5. Faites une recherche avec le terme lower (avec Ctrl+W sous nano). Vous trouver cette ligne:

    # format
    if video.format and 'format' in guess and guess['format'].lower() == video.format.lower():
       matches.add('format')Code language: PHP (php)

Nous allons commenter ces lignes et ajouter des conditions pour que lower ne soit appliqué qu’aux chaînes (type string):

    # format
    #if video.format and 'format' in guess and guess['format'].lower() == video.format.lower():
       #matches.add('format')
    if video.format and 'format' in guess:
       guess_format = guess['format'] if isinstance(guess['format'], list) else [guess['format']]
       if any(gf.lower() == video.format.lower() for gf in guess_format):
            matches.add('format')Code language: PHP (php)
Attention à bien respecter le nombre d’espaces pour l’indentation : il s’agit d’un script python donc très tatillon à ce sujet !

6. Sauvegardez le fichier.

7. Relancez la recherche automatique des sous-titres : plus d’erreurs relatives à l’attribut lower :)

Enjoy!

WorddPress : éviter d'avoir à mettre le même plugin à jour sur chaque site hébergé sur le serveur photo

WordPress: mettre un plugin à jour sur plusieurs sites sur le serveur en une seule opération

Sur un serveur qui héberge plusieurs sites WordPress différents, il est fort probable qu’il y ait quelques plugins en commun sur chaque installation.

WordPress permet de mettre à jour les thèmes et plugins en quelques clics mais cela suppose de s’identifier sur chaque site ou alors de donner permission à une application tierce comme JetPack pour vous faciliter la tâche.

Cela suppose toutefois de bien vouloir rassembler toutes les autorisations sur un seul compte, ce qui n’est pas optimal puisqu’il n’y a plus cloisonnement entre les sites hébergés.

Nous allons donc mettre en place un système de liens symboliques (symlink ou symbolic link en anglais) pour gagner pas mal de temps lors des mises à jour.

Principe d’optimisation de la mise à jour des plugins récurrents

Sur le serveur, j’utilise une petite astuce tout simple : j’utilise mon site comme master officiel du serveur. C’est lui que je mets à jour en premier et tous les autres sites “hériteront” des nouvelles mises à jour, automatiquement et sans manipulation de ma part.

Mise en place de liens symboliques

Comme le serveur tourne sous Linux, il nous suffit de faire un lien symbolique sur le site slave vers le dossier d’un plugin qui se trouve sur le site master.

Lorsque je mettrai certains plugins de SkyMinds à jour par exemple, ces plugins qui sont également installés sur le site du Centre de Kriya Yoga France seront également à jour. En fait, aucun fichier de ce plugin ne sera présent chez eux, seul un lien symbolique.

Concrètement, voici la marche à suivre :

  1. On se place dans le répertoire /wp-content/plugins du site slave (kriyayoga.fr dans cet exemple):
    cd /kriyayoga/wp-content/plugins
  2. On crée un lien symbolique qui va pointer vers le répertoire qui se trouve dans le répertoire de SkyMinds :
    ln -s /skyminds/wp-content/plugins/my-plugin my-plugin
  3. Et voilà !

Lire la suite

NAS Synology : mapper un répertoire du NAS sur un répertoire local sous Ubuntu photo 2

NAS Synology : mapper un répertoire du NAS sur un répertoire local sous Ubuntu

A la maison, je galère un peu avec les taux de transfert des fichiers entre ma machine fixe (The Reaper) et le NAS Synology.

Lors des transferts via le navigateur, la vitesse arrive à peu près à 2MB/s, ce qui, excusez-moi du peu, sonne comme une douce plaisanterie.

Pour pallier ce problème, nous allons donc “mapper” un des répertoires du NAS directement dans un répertoire local de ma machine.

Comme cette dernière tourne sous Ubuntu, il suffira dans Nautilus de copier des fichiers ou dossiers dans ce répertoire pour que tout soit uploadé directement dans le NAS. Un gain de temps en perspective !

Activation de NFS sur le NAS

Sur le NAS, nous allons avoir besoin du protocole NFS (Network File System).

Rendez vous dans Control Panel > File Sharing > File Services > cochez la case pour activer le service NFS et appliquez les changements:

NAS Synology : mapper un répertoire du NAS sur un répertoire local sous Ubuntu photo

Ensuite, cliquez sur l’icône qui se trouve juste au dessus, Shared folders :

  1. créez un nouveau dossier partagé. Je vais prendre NetBackup comme exemple pour ce tutoriel.
  2. sélectionnez le dossier > cliquez sur Edit > sélectionnez l’onglet NFS permissions.
  3. cliquez sur Create pour ajouter une nouvelle politique de droits NFS sur ce dossier.

Voici les droits à accorder:

NAS Synology : mapper un répertoire du NAS sur un répertoire local sous Ubuntu photo 1

Configuration :

Hostname/IP : on indique l’IP de la machine locale. Sur mon réseau local, 192.168.0.10 est l’adresse de ma machine fixe.

Privileges: Read/Write pour lecture et écriture.

Squash : Map root to admin. Cela permet de monter automatiquement le répertoire au démarrage de la machine.

Je laisse coché toutes les autres options, les transferts asynchrones ne me dérangent pas.

Lire la suite

WordPress : afficher des média oEmbed avec HTTPS photo

WordPress : forcer le chargement des média oEmbed en HTTPS

Lorsque le site est servi via HTTPS, toutes les ressources – même les ressources oEmbed automatiquement générée par WordPress – qui composent une page doivent également être servies via une connexion chiffrée aussi.

Il se trouve que je mets des vidéos Youtube et consorts de temps en temps : elles ne s’affichaient plus en https, étant servies par défaut en http.

Le changement vers HTTPS est en marche mais tous les services oEmbed n’ont pas encore adopté le chiffrement des connexions.

Servir les vidéos Youtube en HTTPS

Au lieu d’utiliser Youtube.com, nous allons utiliser la version cookie-less de Youtube, à savoir youtube-nocookie.com : cela permet d’éviter les cookies pisteurs de Google et donc offre plus de sécurité et de respect de la vie privée.

J’utilise ce système depuis des années sur SkyMinds donc je me suis dit qu’il était bien temps de le partager dans ces colonnes.

Le code permet donc de remplacer youtube.com par youtube-nocookie.com dans le code généré par l’oEmbed WordPress.

Ce code est à ajouter dans votre utility plugin (ou à défaut le fichier functions.php de votre thème WordPress).

Le premier code remplace toutes les occurences des médias HTTP pour HTTPS :

<?php
/* Force HTTPS rewrite for oEmbeds
* Source : https://wordpress.stackexchange.com/questions/40747/how-do-i-embed-youtube-videos-with-https-instead-of-http-in-the-url
*/
add_filter( 'embed_oembed_html', 'sky_embed_oembed_html' );
function sky_embed_oembed_html( $html ) { 
  return preg_replace( '@src="https?:@', 'src="', $html );
}Code language: HTML, XML (xml)

Le second code modifie tous les appels à youtube.com et les remplace par youtube-nocookie.com, ce qui empêche la création de cookies pisteurs :

<?php
//BEGIN Embed Video Fix - HTTPS and privacy mode
//https://wordpress.org/support/topic/forcing-ssl-return-for-youtube-oembed

add_filter('the_content', 'sky_add_secure_video_options', 10);
function sky_add_secure_video_options($html) {
   if (strpos($html, "<iframe" ) !== false) {
    	$search = array('src="http://www.youtube.com','src="http://youtube.com');
	$replace = array('src="https://www.youtube-nocookie.com','src="https://www.youtube-nocookie.com');
	$html = str_replace($search, $replace, $html);
   	return $html;
   } else {
        return $html;
   }
}Code language: HTML, XML (xml)

Cela a l’air tout bête mais cela permet de faire respecter un peu plus notre droit au refus de se faire pister à tout bout de champs sur le net.

Le petit plus : on charge également moins de cookies, qui ne sont pas des ressources cachables par essence donc on améliore un peu aussi le temps de chargement de la page.

Serveur dédié : transférer et héberger un nouveau domaine sur votre serveur photo

Serveur dédié : transférer et héberger un nouveau domaine sur votre serveur

Aujourd’hui, nous allons voir comment héberger un nouveau domaine sur le serveur, en simplifiant au maximum les procédures.

Serveur dédié : transférer et héberger un nouveau domaine sur votre serveur photo

Le nom de domaine sera réservé chez OVH et le site hébergé sur notre serveur Debian. Nous allons servir le site avec NginX en HTTPS grâce à un certificat SSL fourni gratuitement par Let’s Encrypt.

Enfin, on utilisera le serveur email existant et on ajoutera la configuration OpenDKIM pour signer et authentifier tous les emails sortants du domaine.

Nom de domaine

J’achète mes noms de domaine chez OVH parce que le prix est relativement raisonnable (comparé à mon ancien registrar).

Au moment de la commande, faites pointer le nouveau domaine vers les DNS du serveur.

Si votre serveur n’est pas chez OVH, il suffit d’aller dans Domaines > Serveurs DNS et de renseigner le DNS primaire et secondaire de votre serveur.

Configuration DNS dans BIND

Une fois le domaine commandé, si vous vous rendez dans le Manager OVH, vous vous rendrez compte que le bouton DNS est en rouge : c’est normal puisqu’il nous faut paramétrer notre nouveau domaine dans BIND, notre serveur de noms.

On édite la configuration de BIND :

nano /etc/bind/named.conf.local

et on lui indique que nous créons une nouvelle zone :

zone "example.com" {
        type master;
        file "/etc/bind/example.com.hosts";
        allow-query { any; };
};Code language: JavaScript (javascript)

On crée maintenant notre fichier de zone:

nano /etc/bind/example.com.hosts
$ttl 84600
$ORIGIN example.com.

@       IN      SOA     XXXXXX.kimsufi.com. root.example.net. (
                        2018012801
                        14400
                        3600
                        604800
                        84600 )

; NAMESERVERS
 IN     NS      XXXXXX.kimsufi.com.
 IN     NS      ns.kimsufi.com.

example.com.   IN      A       XXX.XXX.XXX.XXX
example.com.   IN      AAAA    4001:41d0:1:4462::1
example.com.   IN      MX      10 mail.example.net.

www.example.com.       IN      A        XXX.XXX.XXX.XXX
www.example.com.       IN    AAAA    4001:41d0:1:4462::1
www       IN A          XXX.XXX.XXX.XXXCode language: PHP (php)

Ps: example.net est le domaine principal du serveur.

Pous vérifions la configuration BIND:

named-checkconf -z

et nous redémarrons BIND pour prendre en compte nos changements et activer notre nouveau fichier de zone:

service bind9 restart

Vous pouvez vérifier votre configuration DNS à l’aide de l’outil ZoneMaster.

Configuration du bloc serveur sous NginX

On commence par créer le répertoire qui va accueillir les fichiers du site et on lui attribue les bons droits:

mkdir -p /home/example/public_html
chown -R www-data:www-data /home/example/public_html
chmod 755 /home/example/public_html

On crée également un fichier index.php à la racine du site pour éviter une erreur 403 plus tard lors de la génération du certificat SSL :

echo "<!--?php echo 'hello world. Domain activated.'; ?-->" >> /home/example/public_html/index.phpCode language: HTML, XML (xml)

On crée maintenant le répertoire de cache du site, toujours avec les bons droits:

mkdir -p /home/nginx-cache/example
chown -R www-data:www-data /home/nginx-cache/example
chmod 755 /home/nginx-cache/example

Voici le server block de départ, en HTTP simple :

server {
       listen         80;
       listen    [::]:80;
       server_name    example.com www.example.com;
       #return         301 https://$server_name$request_uri;
        root /home/example/public_html;
        index index.php index.html;
}Code language: PHP (php)

On active le site :

ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

On teste la configuration de NginX et on redémarre le service:

nginx -t
service nginx restart

On crée maintenant le certificat SSL avec Let’s Encrypt :

certbot certonly --webroot -w /home/example/public_html -d example.com -d www.example.com

Lire la suite

Télécharger vos fichiers torrents automatiquement avec Flexget photo

Télécharger vos fichiers torrent automatiquement avec FlexGet et Transmission

Aujourd’hui, nouvelle étape dans l’automatisation de nos téléchargements : au lieu d’uploader un fichier .torrent ou magnet sous Transmission, nous allons installer FlexgGet qui va nous permettre de surveiller un flux RSS pour télécharger automatiquement les fichiers bittorrent.

Une fois le fichier graine téléchargé, Transmission se chargera de télécharger les fichiers immédiatement. Tout sera donc automatisé !

En prérequis, je vous conseille d’avoir Transmission installé et configuré sur votre serveur ou machine, cela vous fera gagner pas mal de temps.

Étape 1 : configuration de Transmission

Vous avez déjà Transmission qui tourne ? Parfait, on commence par arrêter le service :

service transmission-daemon stop

On crée un nouveau répertoire qui sera surveillé par Transmission – dès qu’un fichier .torrent sera ajouté dans ce répertoire, Transmission lancera le téléchargement :

mkdir /home/transmission/torrentwatch

On lui donne les bons droits et le bon utilisateur :

chown debian-transmission:debian-transmission /home/transmission/torrentwatch
chmod 777 /home/transmission/torrentwatch

Et on édite le fichier de configuration :

nano /etc/transmission-daemon/settings.json

Je me suis aperçu qu’il me manquait deux directives importantes dans ce fichier pour surveiller un répertoire donc on les ajoute à la suite des autres directives :

   "watch-dir": "/home/transmission/torrentwatch",
    "watch-dir-enabled": true,Code language: JavaScript (javascript)

On sauvegarde le fichier et on redémarre Transmission :

service transmission-daemon start

Lire la suite

Serveur dédié : réinitialiser le mot de passe root d'un serveur MySQL ou MariaDB photo

Serveur dédié : réinitialiser le mot de passe root d’un serveur MySQL ou MariaDB

Pour les besoins d’un de mes clients préférés, j’ai eu la grande joie de paramétrer un VPS aux petits oignons avec réplication des données à la volée.

C’est un projet fascinant que j’ai déjà abordé dans la série réplication de données.

Serveur dédié : réinitialiser le mot de passe root d'un serveur MySQL ou MariaDB photo

Au moment de la réalisation des bases de données, je demande à mon client le mot de passe root du serveur de base de données pour y créer de nouveaux utilisateurs. La réponse ne se fait pas attendre : “je n’ai pas ce mot de passe mais j’ai confiance en toi Matt, tu pourras aisément contourner le problème!”.

Challenge accepted.

Voici donc un mini-tutoriel pour réinitialiser le mot de passe root quand vous ne l’avez jamais eu vous en souvenez plus.

Vous aurez besoin de deux fenêtres de terminal, que je nomme ici terminal1 et terminal2.

Etape 1 : lancer mysqld_safe

Voici le principe de la manipulation : nous allons “occuper” le serveur MySQL ou MariaDB en lançant le daemon mysqld_safe dans un terminal et nous allons lancer un second terminal qui nous permettre de réinitialiser le mot de passe root.

C’est parti : dans le terminal1, nous commençons par arrêter le serveur SQL:

service mysql stop

puis lançons mysqld_safe :

mysqld_safe --skip-grant-tables --skip-syslog --skip-networking

Le terminal semble arrêté ou attendre quelque chose : c’est bon signe, laissez-le comme ça pour le moment.

Lire la suite