L'adress Matérielle ou adresse MAC identifie une carte réseau. Chaque carte réseau de chaque équipement possède une telle adresse qui est censée être unique au monde. Or les systèmes DHCP utilisent cette adresse pour allouer une adresse IP à toute machine du réseau qui les contactent. Cette adresse MAC n'est accessible que dans votre réseau ou sous réseau ou au travers de sauts via des switchs. Si vous passez par un routeur par contre vous ne pourrez pas la connaître (elle n'a pas à être routée sur Internet ou un autre réseau privé). Pour que ma box alloue toujours la même IP à mon imprimante réseau, il fallait que je puisse lui fournir cette adresse MAC. Le principe consiste à découvrir l'IP de l'imprimante, de lancer un PING sur cette machine pour que ma table de routage la connaîsse et ensuite utiliser la commande arp -a. Voici la marche à suivre, en utilisant nmap pour détecter l'IP.
Script pour rechercher automatiquement les serveurs kimsufi disponibles. Surtout intéressant pour les serveurs premier prix (KS1) qui sont pris dès que créés et n'apparaissent jamais ou peu de temps sur la page web de commande.
Il utilise la bibliothèque cURL (l'installer si elle n'est pas dispo sur le système) et l'extension php-cli. Il ne permet pas de choisir le datacenter OVH (Gravelines, Roubaix etc.), il serait facile de le modifier pour cela, mais du coup il sera plus difficile d'avoir un KS1. Pour la recherche efficace d'un serveur KS1, le mieux est de ne laisser que ce serveur et commenter tous les autres.
OVH change régulièrement ses références serveur, donc il est bon de jeter un oeil sur la page web (en survolant les liens et regardant les références envoyées dans l'url) pour voir si les désignations de serveur saisies en dur dans le script sont encore valables, ou mieux encore en regardant le fichier json qui figure en début de script. Les serveurs kimsufi ont en général un nom du genre 1801ks et des chiffres, aujourd'hui (septembre 2018) les noms sont 1801ks12 pour le KS1 et 1801ks13 pour le KS2. La réservation des serveurs d'entrée de gamme est seule problématique, les autres ne posent pas de problèmes de réservation.
Utilisation
On lance le script en console avec la commande php ./kimsufi.php, en supposant qu'on a sauvegardé le script sous le nom kimsufi.php dans le répertoire courant et qu'on lui a bien entendu donné les droits d'exécution, par exemple avec la commande chmod u+x kimsufi.php.
Les résutats s'affichent sur la sortie standard. Si l'on veut en garder un log on peut rediriger la sortie vers un fichier php ./kimsufi.php > kimsufi.log, ou avec la redirection >> si l'on veut rajouter au fichier sans le vider à chaque fois.
On peut bien entendu utiliser la commande tee pour à la fois afficher sur la sortie standard et logger dans un fichier : php ./kimsufi.php | tee -a kimsufi.log, avec l'option -a pour ajouter au fichier (équivalent de >>) ou sans elle pour vider le fichier de log à chaque lancement. Il est en effet probable que vous devrez lancer ce script plusieurs jours de suite les mises à disposition des ks1 se produisant visiblement seulement une ou deux fois par semaine.
Un champ booléen dans SQLite ou MySQL (contenant une valeur vrai/faux) est représenté par les valeurs 0 ou 1. Pour modifier sa valeur on peut lancer un SELECT sur la table et en fonction de la valeur renvoyée mettre la table à jour. Mais ce n'est pas la façon la plus efficace et élégante.
Tout comme les clés SSH, les clés SSL peuvent être chiffrées ou non avec une « pass phrase ». Les clés SSL sont généralement utilisées par des services de façon automatique, comme un serveur Apache ou Nginx par exemple, ou des logiciels de courrier comme Postfix. Du coup à chaque redémarrage du service il faudrait entrer la « pass phrase » pour déchiffrer la clé. Ce n'est pas pratique. Une solution est de mettre la clé en clair dans un fichier que peut lire le service. Mais des logiciels comme Postfix ne savent tout bonnement pas utiliser une clé chiffrée. Du coup Il faut savoir comment à partir de la clé chiffrée par la « pass phrase » générer un fichier de clé non chiffré.
Avec MySQL comme avec les autres SGBDr, la façon la plus portable de sauvegarder ses données est d'en extraire des fichiers sql susceptibles de servir à reconstruire la base et y replacer ses données ce qui s'appelle en anglais un « dump ».
MySQL propose un script du nom de mysqldump qui fait ça très bien. Il produit des fichiers texte qui contiennent des instructions sql. Ces fichiers se compressent très bien, et comme les bases sont souvent grandes, les utilitaires comme gzip sont très utiles pour gagner de l'espace disque.
Le problème commence lorsqu'on envisage des sauvegardes incrémentales. Avec les utilitaires comme rsnapshot qui utilise rsync et les liens en dur, seuls les fichiers modifiés depuis la dernière sauvegarde sont sauvegardés. On économise ainsi de l'espace disque et de la bande passante. Mais les fichiers de dump sont à chaque fois nouveaux, car même si leur contenu n'a pas changé, le fichier lui est nouveau. Du coup rsync le télécharge. Et si vous faites un dump des bases de votres serveur MySQL toutes les quatre heures vous allez télécharger six fois par jour la même chose si vos bases reçoivent rarement des modifications.
Depuis Debian 6.0 Squeeze, le Shell générique par défaut n'est plus bash mais dash qui est beaucoup plus rapide à charger. Dash est un shell plus limité que Bash (voir ce comparatif en anglais). Pour une utilisation sur un serveur que l'on ne passe pas son temps à démarrer, l'argument du temps de démarrage n'a pas beaucoup de sens et si comme moi vous avez certains scripts qui ne fonctionnent pas sous dash, pouvoir revenir à bash par défaut n'est pas sans intérêt.
