Matt Biscay: développeur WordPress et WooCommerce pour SkyMinds
linux apt packages

Apt : the following packages have been kept back

Après la mise à jour d’Ubuntu Server sur le serveur, j’ai eu cette erreur récurrente après chaque mise à jour apt :

The following packages have been kept back:
  mysql-client mysql-server

Il m’était donc impossible de mettre le serveur et client mysql à jour, ce qui n’est évidemment pas idéal.

Et si l’on essaie de les installer directement avec:

apt install mysql-client mysql-server

On obtient alors ce message:

Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 mysql-common : Conflicts: mysql-client-8.0 but 8.0.29-0ubuntu0.22.04.2 is to be installed
                Conflicts: mysql-client-core-8.0 but 8.0.29-0ubuntu0.22.04.2 is to be installed
 mysql-server : Depends: mysql-server-8.0 but it is not installable
E: Unable to correct problems, you have held broken packages.

Réinstaller mysql-apt-config

On commence donc par réinstaller le package mysql-apt-config :

wget https://dev.mysql.com/get/mysql-apt-config_0.8.22-1_all.deb

Et on installe le paquet:

dpkg -i mysql-apt-config_0.8.22-1_all.deb

On relance donc la mise à jour:

apt update && apt upgrade

Les nouvelles versions des paquets sont désormais installables:

9 packages can be upgraded. Run 'apt list --upgradable' to see them.
W: http://repo.mysql.com/apt/ubuntu/dists/bionic/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.
Listing... Done
libmysqlclient21/unknown 8.0.29-1ubuntu18.04 amd64 [upgradable from: 8.0.29-0ubuntu0.22.04.2]
mysql-client/unknown 8.0.29-1ubuntu18.04 amd64 [upgradable from: 8.0.28-1ubuntu18.04]
mysql-common/unknown 8.0.29-1ubuntu18.04 amd64 [upgradable from: 8.0.28-1ubuntu18.04]
mysql-community-client-core/unknown 8.0.29-1ubuntu18.04 amd64 [upgradable from: 8.0.28-1ubuntu18.04]
mysql-community-client-plugins/unknown 8.0.29-1ubuntu18.04 amd64 [upgradable from: 8.0.28-1ubuntu18.04]
mysql-community-client/unknown 8.0.29-1ubuntu18.04 amd64 [upgradable from: 8.0.28-1ubuntu18.04]
mysql-community-server-core/unknown 8.0.29-1ubuntu18.04 amd64 [upgradable from: 8.0.28-1ubuntu18.04]
mysql-community-server/unknown 8.0.29-1ubuntu18.04 amd64 [upgradable from: 8.0.28-1ubuntu18.04]
mysql-server/unknown 8.0.29-1ubuntu18.04 amd64 [upgradable from: 8.0.28-1ubuntu18.04]
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  linux-headers-5.15.0-25 linux-headers-5.15.0-25-generic linux-image-5.15.0-25-generic linux-modules-5.15.0-25-generic
  linux-modules-extra-5.15.0-25-generic
Use 'apt autoremove' to remove them.
The following packages will be upgraded:
  libmysqlclient21 mysql-client mysql-common mysql-community-client mysql-community-client-core mysql-community-client-plugins
  mysql-community-server mysql-community-server-core mysql-server
9 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Résoudre le message “Key is stored in legacy trusted.gpg keyring”

Dans le message précédent, nous pouvons trouvez ce message d’avertissement:

W: http://repo.mysql.com/apt/ubuntu/dists/bionic/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.

Je l’ai résolu en déplaçant le fichier dans le répertoire trusted.gpg.d :

mv trusted.gpg trusted.gpg.d/

Et voilà, plus d’erreur avec apt et notre système met bien tous ses paquets à jour.

ubuntu 2204 jammy jellyfish

Serveur: migration d’Ubuntu 20.04 à 22.04 LTS

Aujourd’hui, nous mettons le serveur à jour et passons d’Ubuntu Server 20.04 (Focal Fossa) à la version 22.04 LTS (Jammy Jellyfish).

Chaque nouvelle mise à jour d’Ubuntu en version LTS (Long Time Support) permet de bénéficier des mises à jour de sécurité et de maintenance pendant 5 ans, c’est à dire jusqu’en 2027 pour la version Jammy Jellyfish.

Lecture des changements apportés

Je vous conseille fortement de lire le changelog de la version 22.04 pour avoir un aperçu des changements apportés au niveau du kernel, openSSL, certains services.

Sont maintenant disponibles:

  • Apache 2.4.52
  • BIND 9.18
  • Linux kernel v5.15.0-25
  • MySQL 8.0.28
  • NetworkManager 1.36
  • nftables est le backend par défaut pour le parefeu
  • Perl v5.34.0
  • PHP 8.1.2
  • PostgreSQL 14.2
  • Python 3.10.4
  • Ruby 3.0
  • ssh-rsa est maintenant désactivé par défaut dans OpenSSH.

Cela donne aussi une idée des potentielles complications qui pourraient subvenir à la suite de la mise à jour, ainsi que leur remédiation.

Sauvegarde des données du serveur

Je ne vous apprends rien : il va falloir sauvegarder les données importantes du serveur avant de commencer la mise à jour de l’OS.

Pensez-donc au dossier /home et /var/www mais aussi aux fichiers de configuration dans /etc et /root.

Vérification des pré-requis

Vérification de la version actuelle

On vérifie notre noyau actuel:

uname -mrs

> Linux 5.4.0-109-generic x86_64

On vérifie notre version actuelle:

lsb_release -a


No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.4 LTS
Release:	20.04
Codename:	focal

Mise à jour des paquets de la version actuelle

On met à jour la version actuelle avec les derniers paquets et les derniers noyaux:

apt update && apt upgrade

Redémarrage du serveur

On redémarre le serveur pour appliquer les changements et partir sur une base propre:

shutdown -r now

Lire la suite

Linux et MacOS : lister tous les répertoires de plus de 500 Mo photo

Linux et MacOS : lister tous les répertoires de plus de 500 Mo

De temps en temps, il faut un peu faire le ménage sur nos disques durs et il est assez utile de chercher à savoir quels sont les dossiers qui prennent le plus d’espace disque.

Lister tous les répertoires de plus de 500 Mo

Sous Linux et MacOS, voici la commande que je lance pour trouver tous les répertoires de plus de 500 Mo, classés par ordre d’importance:

du -m ~/Downloads/* | awk '$1 > 500' | sort -nr

Voici le détail de la commande:

  • du signifie disk usage
  • -m signifie que l’on souhaite la taille en Mo
  • ~/Downloads/* est le chemin dans lequel se trouvent nos gros dossiers, là où se trouvent nos données
  • awk '$1 > 500' capture le chemin du dossier lorsqu’il dépasse 500 Mo
  • sort -nr permet de classer la liste du plus gros dossier au plus petit

Une petite commande à garder sous le coude, cela permet d’éviter de perdre trop de temps à trouver le dossier le plus gourmand du disque!

Linux : obtenir la valeur numérique du chmod photo

Linux : obtenir la valeur numérique du chmod

chmod permissions compressor

Je vous ai déjà parlé du chmod et du chown de manière extensive mais aujourd’hui on va un tout petit peu plus loin.

La valeur du chmod telle qu’elle apparaît dans le terminal est un peu esotérique. Prenons par exemple le chmod d’un fichier standard de WordPress : -rw-r-----, cela demande une petite gymnastique intellectuelle pour réaliser quels sont les droits véritables.

Je vous propose donc une petite commande qui va vous simplifier la vie, de manière à vous donner la valeur numérique du chmod des fichiers et répertoires.

Il vous suffit d’utiliser la commande stat comme ceci, dans votre fenêtre de terminal:

stat -c '%a %U:%G %n' *

Notes:

  • -c permet de formater la sortie avec la template entre apostrophes
  • %a donne la valeur octale du chmod
  • %U donne le nom de l’utilisateur du chown
  • %G donne le groupe de l’utilisateur du chown
  • %n donne le nom du fichier

Et voilà simple et efficace!

Python : résoudre l'erreur

Python : résoudre l’erreur “ImportError: cannot import name main”

Pip écrasé par une nouvelle version

Suite à une mauvaise manipulation, j’ai malencontreusement écrasé ma version de pip installée par APT en faisant un pip install pip.

Après cela, toute commande lancée par pip donne cette erreur:

Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

Pas glop! Si cela vous arrive un jour, voici comment retrouver la version pip initiale, installée par votre gestionnaire de paquet APT.

Retrouver la version pip initiale (apt)

On marque python2.7 comme binaire Python par défault en le sélectionnant dans cette liste (si besoin):

update-alternatives --config python

On désinstalle pip, dans APT et dans PIP :

python -m pip uninstall pip
apt purge --autoremove python-pip

On réinstalle pip avec APT:

apt install python-pip

Et on vérifie la version de pip :

pip --version

qui nous donne:

pip 9.0.1 from /usr/lib/python2.7/dist-packages (python 2.7)

Et voilà, nous venons de retrouver une version de pip utilisable sur notre système.

Note : ne pas tenter de mettre à jour pip manuellement, il vaut mieux laisser le gestionnaire de paquet gérer les mises à jour de ce paquet lorsque cela est nécessaire, au fil des mises à jour.

Serveur dédié : installation de MariaDB 10.3 photo

Serveur dédié : installation de MariaDB 10.3

mariadb

Debian Stretch possède MariaDB 10.1 mais au vu des améliorations récentes de MariaDB, il est intéressant de passer à la version 10.3 pour des raisons de performance.

Ajout du nouveau dépôt

On installe les dépendances et on ajoute le dépôt de MariaDB 10.3 à notre fichier de configuration apt, ainsi que la clé du dépôt:

apt install software-properties-common dirmngr
apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xF1656F24C74CD1D8
add-apt-repository 'deb [arch=amd64,i386,ppc64el] http://mariadb.mirrors.ovh.net/MariaDB/repo/10.3/debian stretch main'

Mise à jour de MariaDB

Une fois que la clé du dépôt est ajoutée au trousseau, on installe la nouvelle mouture de MariaDB:

apt update
apt install mariadb-server

Notez que vous pouvez choisir la version de MariaDB à installer très facilement depuis le site officiel.

Et voilà, serveur de base de données mis à jour.

MariaDB : changer le répertoire des bases de données sous Debian photo

Serveur dédié : déplacer les bases de données MariaDB ou MySQL sur une autre partition

J’ai récemment installé un plugin qui met en cache les requêtes API Amazon mais dont la table SQL gonfle énormément – plus de 5 Go à l’heure où j’écris ces lignes.

Le problème, c’est que cela remplit la partition racine du serveur, qui est utilisée par défaut par MariaDB pour stocker les fichiers des bases de données.

Lorsque j’ai créé ce serveur, j’ai utilisé la configuration par défault d’OVH, ce qui est une erreur grossière : la partition racine (/) fait 10 Go alors que la partition /home fait 740 Go… même pour un desktop, on ne fait plus cela parce que cela laisse trop peu pour le système alors imaginez un peu pour un serveur !

Nous avons donc le choix entre re-partitionner le disque (autant vous dire que cela ne me tente que très moyennement) ou alors changer le dossier des bases SQL pour les mettre sous /home.

Ce tutoriel vous permet donc de délocaliser les bases de données MySQL/MariaDB sur une autre partition. Le serveur tourne sur la dernière version de Debian.

Vérification du chemin des bases MariaDB

Tout se passe via le terminal. Je vous conseille de faire une sauvegarde de vos bases avant de commencer.

Commençons par vérifier le dossier dans lequel se trouve nos bases de données:

mysql -u root -p

Entrez votre mot de passe root puis entrez la commande suivante:

select @@datadir;

Résultat:

+-----------------+
| @@datadir       |
+-----------------+
| /var/lib/mysql/ |
+-----------------+
1 row in set (0.00 sec)

Ajustement de systemd pour MariaDB

Ceci est une étape fondamentale du tutoriel. Si vous ne faites pas cela, MariaDB ne démarrera pas avec votre nouveau dossier car, par défaut, il n’a pas accès à /home.

Il faut donc que nous lui donnions explicitement l’accès :

systemctl edit mariadb

Dans le fichier qui s’ouvre, entrez le code suivant:

[Service]
ProtectHome = false

Enregistrez le fichier tel quel, sans changer le nom. Le fichier que vous venez de créer est /etc/systemd/system/mariadb.service.d/override.conf

Appliquez maintenant les changements :

systemctl daemon-reload

Un nouveau répertoire pour nos bases de données

Nous pouvons maintenant créer le nouveau répertoire qui accueillera les fichiers de nos bases de données. Par simplicité, je choisis de tout mettre sous /home/mysql :

Lire la suite

Linux : désactiver les emails de notification d'une tâche cron photo

Linux : désactiver les emails de notification d’une tâche cron

La plupart des tâches cron sont exécutées à un moment où elles n’empiètent pas sur les ressources du serveur (i.e. la nuit).

Or crontab envoie un email récapitulatif à chaque fois qu’une tâche est complétée, ce qui peut vite devenir pénible à gérer.

Heureusement, il existe plusieurs manières d’empêcher de recevoir ces emails de notification de tâches cron.

1. Méthode nucléaire : rendre la variable MAILTO nulle

Vous pouvez éditer le fichier /etc/crontab et rendre la variable MAILTO nulle, comme ceci:

MAILTO=""

Cela désactive effectivement tous les emails envoyés depuis crond. C’est par contre une méthode nucléaire : si vous voulez une notification, il faudra l’envoyer depuis le script et non cron.

Cela empêche également de recevoir toute notification en cas d’erreur de la tâche cron, ce qui est très gênant – ce n’est pas vraiment la méthode que je conseille.

2. Rediriger STDOUT et STDERR vers null pour supprimer toute sortie

Si vous supprimez la sortie du script, crond n’aura rien à envoyer.

Ajoutez ceci à l’entrée de votre crontab pour envoyer toute sortie (STDERR et STDOUT) vers /dev/null:

>/dev/null 2>&1

Voici un exemple qui lance un script toutes les 5 minutes, sans sortie:

*/5 * * * * /example/script >/dev/null 2>&1

Le principal inconvénient est que cela supprime également toutes les erreurs qui pourraient être utiles au débuggage du script.

3. Configurer crond pour envoyer la sortie du script vers les logs système et désactiver la notification de la sortie

Vous pouvez configurer crond en éditant le fichier /etc/sysconfig/crond pour y changer la ligne CRONDARGS.

L’argument -s envoie la sortie vers le log système et l’argument -m off désactive la notification email du résultat de la tâche.

Voici un exemple :

cat /etc/sysconfig/crond

Résultat:

# Settings for the CRON daemon.
# CRONDARGS= :  any extra command-line startup arguments for crond
CRONDARGS=-s -m off

Il faut ensuite relancer le service cron pour appliquer la nouvelle configuration avec les nouveaux arguments:

service cron restart

Conclusion

Toutes ces méthodes permettent de supprimer totalement les notifications emails du service cron lorsqu’une tâche est lancée.

Si vous souhaitez ne pas produire de sortie mais garder la possibilité de recevoir un email en cas d’erreur, pensez à rediriger STDOUT vers /dev/null:

*/5 * * * * /example/script > /dev/null
Installer Redis pour accélérer WordPress sous Debian photo

Installer Redis pour accélérer WordPress sous Debian

Aujourd’hui, nous installons le serveur Redis pour accélérer les temps de chargement de tous les sites présents sur le serveur.

Redis (de l’anglais REmote DIctionary Server qui peut être traduit par « serveur de dictionnaire distant » et jeu de mot avec Redistribute1) est un système de gestion de base de données clef-valeur scalable, très hautes performances, écrit en C ANSI.

Il fait partie de la mouvance NoSQL et vise à fournir les performances les plus élevées possibles.

Redis permet de manipuler des types de données simples : chaînes de caractères, tableaux associatifs, listes, ensembles et ensembles ordonnés.

Une des principales caractéristiques de Redis est de conserver l’intégralité des données en RAM. Cela permet d’obtenir d’excellentes performances en évitant les accès disques, particulièrement coûteux sur ce plan.

Lorsqu’une page WordPress est chargée par exemple, des requêtes sur la base de données sont lancées et cela prend un certain temps pour récupérer ces informations.

Lorsque Redis est activé, il garde ces requêtes SQL en mémoire, ce qui permet de gagner en temps de chargement des pages.

Voici donc le tutoriel pour mettre en place Redis sur votre serveur. Cela prend environ 15 minutes.

Installation du serveur Redis

Nous installons le serveur Redis et le paquet PHP associé:

apt install redis-server php-redis

Nous vérifions que Redis est bien actif, il nous suffit de lancer redis-cli:

redis-cli

On tape ping dans l’invite:

127.0.0.1:6379> ping

Réponse:

PONG

Parfait, le serveur Redis est bien installé et actif.

Configuration de Redis

Editons le fichier de configuration de Redis :

nano /etc/redis/redis.conf

Changez les valeurs suivantes :

maxmemory 256mb # max memory 
maxmemory-policy allkeys-lru # replace old keys with fresher ones
requirepass VOTRE-MOT-DE-PASSE

Enregistrez et relancez le serveur pour prendre en charge la nouvelle configuration:

service redis-server restart

Lire la suite

PHP : configurer un pool PHP pour chaque site photo

PHP : configurer un pool PHP pour chaque site

Au départ, ce serveur n’avait qu’un seul site – celui que vous lisez en ce moment ;) – mais au fil du temps, plusieurs sites sont venus s’installer dans son giron.

Au début, nous n’avions donc besoin d’une seule configuration PHP – www.conf par défaut – qui est un pool (ou conteneur) selon la terminologie PHP.

Ce fichier de configuration dicte le nombre de threads PHP à lancer, les permissions, etc.

Afin de monter en charge et fournir à chaque site les ressources qui lui sont nécessaires, adoptons la stratégie “un site, un pool”.

Mise en place du nouveau pool PHP

Pour être sûr de partir d’une base éprouvée, copions notre pool de départ dans un nouveau fichier :

cp /etc/php/7.2/fpm/pool.d/www.conf /etc/php/7.2/fpm/pool.d/skyminds.conf

Editons ensuite notre pool :

nano /etc/php/7.2/fpm/pool.d/skyminds.conf

1. Nom du pool : remplacez [www] par le nom de votre site, ici [skyminds] de manière à pouvoir l’identifier plus aisément.

2. Vérifiez l’utilisateur et le groupe dans les directives user et group.

3. On modifie le nom du site dans la directive listen en utilisant le nom du pool que vous avez choisi dans l’étape 1:

listen = /run/php/skyminds.sock

Mise à jour de la configuration NginX

Il nous reste maintenant à mettre à jour la configuration du site :

nano /etc/nginx/sites-available/skyminds.net

Mettez à jour cette ligne (même chemin que la directive listen dans la configuration PHP):

fastcgi_pass unix:/run/php/skyminds.sock;

Relancez les services PHP et NginX:

service php7.4-fpm restart && service nginx restart

Lire la suite

Sommaire de la série Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. Serveur dédié : création d’un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d’utilisateurs/domaines virtuels
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d’APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d’une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”
  28. Serveur dédié : mise en place de l’IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : installer la dernière version d’OpenSSL sous Debian
  43. Serveur dédié : activer l’IP canonique du serveur sous Apache
  44. Serveur dédié : mise à jour vers PHP 5.6
  45. MySQL : convertir les tables MyISAM au format InnoDB
  46. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  47. Serveur dédié : migration de MySQL vers MariaDB
  48. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  49. Serveur dédié : produire une meilleure réserve d’entropie avec haveged
  50. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  51. Serveur dédié : mise en place du protocole DANE
  52. 8 règles d’or pour bien déployer DNSSEC et DANE
  53. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  54. Serveur dédié : optimiser la couche TCP
  55. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  56. Serveur dédié : mettre à jour Apache pour HTTP/2
  57. Serveur dédié : ajouter le domaine à la liste HSTS preload
  58. Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
  59. Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”
  60. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian
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

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; done

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.

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.

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…

movgrab-download-videos-shell

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:

[one_half]

  • 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

[/one_half]

[one_half_last]

  • 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

[/one_half_last]

Lire la suite