Minimalteck.fr

Détection de rookits simple avec /proc

Minimalteck — 2009-08-17T15:57:05Z

Un de vos serveur rame grave…
Gros loadaverage et vous ne comprenez pas pourquoi…
Pas de process anormaux via ps pourtant…

Comparez donc les résultats respectifs de ces 2 commandes :

ps ax | wc -l

ls -d /proc/* | grep [0-9]| wc -l

Elles doivent en théorie retourner une même valeur…
Il y a une différence ? Aïe, il va falloir se mettre à travailler un peu… l'installation d'un outil de détection de rootkits est peut être utile…

Accélérer les copies distantes avec tar sur ssh

Minimalteck — 2009-05-25T11:19:20Z

Contexte : vous devez copier depuis une machine distante un important volume de données… la première idée qui vient est sans doute scp…
Mais on peut optimiser le transfert en utilisant tar sur ssh :

Récupération depuis une machine distante du répertoire "local_directory_to_backup" situé dans le chemin "local_path_parent_directory" :

ssh root@machinelointaine “cd path_of_parent_directory; tar czf - local_directory_to_backup" | tar xzf - -C local_path_for_backup

Téléchargement du répertoire "local_directory_to_backup" vers la machine distante dans le répertoire "remote_path_for_backup"

tar czf - local_directory_to_backup | ssh root@machinelointaine "tar xzf - -C remote_path_for_backup"

Il apparaît même qu'en substituant la compression via tar avec gzip/gunzip on obtient un résultat encore meilleur… la commande devient alors :

ssh root@machinelointaine “cd path_of_parent_directory; tar cf - local_directory_to_backup | gzip" | gunzip -q | tar xf - -C local_path_for_backup

Ceci est surtout utile pour une copie/sauvegarde ponctuelle ; si le contexte est celui de sauvegardes récurrentes, creusez plutôt du côté de RSync.

Références :
OpenSSH (fr)
Man tar (fr)
FAQ GZIP

Ez-Publish : sauvegarde

Minimalteck — 2009-04-22T11:36:18Z

Sommaire

Étape 1 : Vider les caches :

Pour vider les caches d'Ez-Publish, rien de plus simple :

se placer dans répertoire d'installation de l'instance d'Ez-Publish
exécuter en ligne de commande (nécessite php cli)
server:/var/www/ez/# php bin/php/ezcache.php --clear-all Clearing : Cache d'affichage de contenu, Cache Global INI, Cache INI, Cache codepage, Expiry cache, Cache des identifiants de classes, Cache des clés de classement, Cache des alias d'URL, Cacher de transformation des caractères, Alias d'image, Cache des templates, Cache des template block, Cache des templates override, Cache RSS, Cache de informations personnelles des utilisateurs

alternativement vous pouvez utiliser un script shell disponible pour les versions antérieures à la 3.10 [1]
server:/var/www/ez/# sh bin/shell/clearcache.sh --clear-all Removing cache files in var/cache/content Removing ini cache files in var/cache/ini Removing codepage cache files in var/cache/codepages Removing template cache files in var/cache/template Removing template override cache files in var/cache/override Removing template-block cache files in var/cache/template-block Removing translation cache files in var/cache/translation Removing translation cache files in var/cache/wildcard Removing sortkey cache files in var/cache/sortkey_ Removing user-info cache files in var/cache/user-info Removing class identifier cache files in var/cache/classidentifiers_ Removing class attribute identifier cache files in var/cache/classattributeidentifiers_

Étape 2 : Sauvegarder la base

Si vous êtes étourdi, sachez que vous pouvez rapidement retrouver les informations « DatabaseSettings » dans le fichier « settings/override/site.ini.append.php » [2].
Faire un dump de la base :

mysqldump -u userez -p --opt ezbase | gzip -9 > ezbase.`date +%d-%m-%Y`.sql.gz

Étape 3 : Sauvegarder le tout

Il ne reste plus qu'à archiver l'arborescence de notre instance d'Ez-Publish

server:/var/www/# tar cfz backup_ez.tar.gz ez

et hop… l'affaire est dans le sac

[1] Quelle version est installée ? La réponse est là : server:/var/www/ez/# more kernel/ezinfo/about.php

[2] Pour mémoire le fichier « settings/override/site.ini.append.php » contient également d'autres paramètres de configurations intéressants comme les « MailSettings », le nom et l'URL du site « SiteSettings », mais aussi ceux concernant les caches via les blocks de configuration « FileSettings », « ContentSettings », « OverrideSettings », « TemplateSettings ».

Plugin Pages uniques et squelette par défaut

Minimalteck — 2009-04-07T15:04:55Z

La structure d'un site sous SPIP est construite sur une hiérarchie de rubriques. Le Plugin Pages uniques permet de créer des articles hors de cette hierarchie, des pages uniques ou orphelines.

Les articles générés par ce très utile plugin ont "id_rubrique" affecté à "-1".
Partant de ce postulat, il est aisé de fournir un squelette par défaut à ce type de page, simplement en créant un fichier article--1.html dans le répertoire des squelettes.
Pour les explications, je vous renvoie à la doc SPIP : Les variantes de squelette

Mysql : nettoyage des logs binaires

Minimalteck — 2009-04-01T16:06:21Z

Les beaux jours sont là et Mysql remplis gentiment la partition qui lui est dédiée avec ces beaux logs binaires…
Allons faire un petit nettoyage de printemps…

Un log binaire contient toutes les requêtes qui modifient les données et se voit utilisé par le(s) esclave(s) lors d'une réplication.
Dans la documentation on peut lire que l'on peut "effacer tous les fichiers de log avec la commande RESET MASTER, ou seulement certains d'entre eux avec PURGE MASTER LOGS".

mysql > PURGE BINARY LOGS TO 'mysql-bin.0020'; mysql > PURGE BINARY LOGS BEFORE DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY);

Ces commandes effacent tous les logs binaires listés dans l'index de logs, qui sont antérieurs au log (dans l'exemple antérieurs au log 'mysql-bin.0020') ou à la date indiqué (dans l'exemple antérieurs de 10 jours à la date courante).
Ceux-ci sont alors supprimés de l'indexation - le log éventuel donné en paramètre devient alors le premier de la liste.

En théorie, au prochain redémarrage du serveur MySQL ou à la prochaine commande "FLUSH LOGS", MySQL doit faire tourner les logs, crée un nouveau fichier de log binaires et supprimer les anciens logs binaires selon la variable système " expire_logs_days " présente dans le fichier de configuration "my.cnf" [1].

Seulement en pratique, ce n'est pas toujours le cas [2].

Au moins une alternative se présente et fonctionne (pour moi en tout cas ) :

Arrêter MySQL
effacer les vieux log binaires à la main : find /var/log/mysql/hostname-bin.* -mtime +10 -exec rm {}\;
reconstruire l'index des binaires ls /var/lib/mysql/ > mysql-bin.index
redémarrer MySQL

Et hop, ça c'est fait… le mieux serait de faire un script et de croner tout ça non ? Hum, demain…

[1] dans cette configuration, on doit avoir quelque chose comme :

log_bin = /var/lib/mysql/hostname-bin.log
 expire_logs_days = 10
 max_binlog_size = 100M

[2] Dans le cas de réplication apparemment un bug subsiste du au fait que le fichier d'indexation du "master" contient encore les anciens fichiers…
Mais voyez plutôt ces exemples de "Quand ça veut pas…" :

Mysql + root + perte + mot de passe = bévue

Minimalteck — 2009-04-01T14:25:00Z

"Un doute m'assaille… Qu'avais-je donc pu assigner comme mot de passe à notre bien-aimé utilisateur root MySQL sur vieux-bazard-poussiéreux ?"
Après avoir testé une bonne vingtaine de vos mots de passe fétiches [1], la réalité prend le pas sur votre optimisme habituel, vous poussant à exprimer haut et fort votre total désapointement face à cette situation ubuesque :
"Peste soit de ce fâcheux contre-temps !"

Heureusement, une solution toute simple s'offre à vous…

Étape 1 [2] : arrêter le serveur Mysql /etc/init.d/mysql stop

Étape 2 : redémarrer le serveur Mysql
Oui ! mais pas n'importe comment mysqld --skip-grant-tables --skip-networking & Ces options forcent le serveur à ne pas utiliser le système de privilège du tout… mais à ne pas accepter de connexions TCP/IP du tout non plus !

Étape 3 : on change tout
Ensuite on se connecte au serveur et on sélectionne la base mysql : $ mysql -u root mysql On change le mot de passe root

mysql> UPDATE user SET Password=PASSWORD('newpassroot') WHERE User='root';

On recharge les privilèges puis on quitte

mysql> FLUSH PRIVILEGES;
 mysql>exit

Étape 3bis ou 4, au choix
On redémarre Mysql /etc/init.d/mysql restart

[1] si la machine n'a pas été installé par vos soins… le premier test à effectuer est l'abscence abhérente mais possible du mot de passe root,
Ne riez pas, cela m'est arrivé pas plus tard qu'hier sur la machine d'un client

[2] Étape avant l'étape 1 : Vérifiez dans le répertoire du super-utilisateur s'il n'y a pas un fichier d'options utilisateur qui traîne… ls -a /root | grep '.my.cnf' ou encore sortez le canon tue-mouches pour faire croire que votre tâche est difficile test -e '/root/.my.cnf' && more /root/.my.cnf || echo 'Le système se voit au regret de vous informer que le fichier demandé est inexistant !'
En effet, ce type de fichier peut stocker les paramètres de connexions sous la forme

 
 [client]
 host=localhost
 user=root
 password=mot_de_passe_root

"Ah, c'est pour ça que j'arrive pas à me connceter moi… j'en n'ai pas"…"
"Euh, non toi c'est à cause de tes mouffles"…
"des mouffles ??? ben, j'en ai pas non plus…"

Si cette recette n'a pas marché chez vous… essayez sans vos mouffles

Création d'un fichier .htaccess sous Windows

Minimalteck — 2009-03-12T15:21:27Z

Suivant les versions, Windows refusent de créer ou de renommer un fichier avec le nom .htaccess (ou plus généralement de fichier dont le nom commence par un '.').

Et ce qui devait arrivé, arrive… on vous demande de créer un tel fichier sur un… Windows… ne paniquer pas !

Pour contourner le problème de la création du fichier .htacces , il faut utiliser un editeur de texte comme PsPad pour sauvegarder le fichier, ou bien - plus simplement pour les amis de la ligne de commande - renommer dans une session DOS le fichier, via la commande ren : ren htaccess .htaccess

EzPublish : Reset du "password_hash" admin

Minimalteck — 2008-11-27T10:17:24Z

Vous avez oubliez le mot de passe de l'admin sous votre site Ez ?
Ne pleurez plus amis poissons rouges, voici la recette adéquate…

Sous mysql (en console ou sous PhpMyAdmin), requêtez comme suit :

SET @key = 'VotreNouveauMotDePasse';
 SET @username = 'admin';
 SET @del = '\n';
 SET @hash = MD5(CONCAT(@username,@del,@key));
 UPDATE ezuser SET password_hash=@hash WHERE login=@username;

Sous Linux, et si vous aimez vous compliquer la vie, une autre alternative s'offre à vous :
Générez votre nouvelle clé "password_hash" en mode console :

$ echo -n -e "admin\nVotreNouveauMotDePasse" | md5sum

Il ne reste plus qu'à insérer dans mysql la nouvelle clé…

UPDATE `ezuser` SET `password_hash`='2cfe50db7795f6a52f0f03322ba51a1a' WHERE login='admin';

Vous noterez que cela n'a aucun intérêt… ça prend un peu plus de temps, c'est tout