Utilité

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.

Lire la suite de Script de réservation de serveur kimsufi

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.

Lire la suite de Horodatage des sauvegardes de dump de base de donnée

Le but est de sauvegarder toutes les bases d'un SGBD MySQL dans des fichiers séparés horodatés dans un répertoire portant comme nom l'horodatage des sauvegardes. Ce script est un mixte dérivé de ceux trouvés à ces deux URLs : Le site de Maciej Mensfeld et cette astuce de Tim Kuijsten sur GitHub.

Lire la suite de Script de backup MySQL

Cet article contient diverses petites commandes que l'on n'utilise pas forcément tous les jours et que l'on oublie. C'est un pense-bête dans ma catégorie pense-bête !

Lire la suite de Commandes utiles