Votre dedibox freeze : LA Solution

Written by Red, Sunday, 27 September 2009 15:55
Ca fait un bout de temps que j'ai rien posté mais la comme c'est dimanche et que je viens de résoudre un problème récurant (qui en amènera d'autres mais bon...)..
Comme le sujet du post l'indique, je vais essayer de répondre ici à un problème souvent évoqué mais jamais résolu, le freez des dediboxes.
Pour commencer, même si le titre est clinquant, cette solution a marché pour moi, et j'espère qu'elle vous permettra d'avancer un peu plus dans votre quête ultime de la stabilité de vos serveurs et que vous pourrez ainsi prendre quelques week-end bien mérités.

Les symptomes :

La box freeze sans raison, d'une maniére aléatoire, souvent quand la charge augmente. Le serveur ping mais impossible de se loguer en ssh. Le reboot obligatoire...
Ben en fait le problème vient du swap.
Globalement un système unix à cour de mémoire freeze en quelques secondes....
Et quand je dis freeze c'est définitivement freeze : mêm le watchdog se ramasse.

Voici le scénario classique :

- vous configurez votre architecture LAMP Linux Apache Mysql PHP.
Puis un jour votre client vous appelle, vous expliquant que son serveur est down : en fait c'est juste apache qui ne veux plus accepter de connections.
Vous éditez la config apache et augmentez le nombre de connections et hop, ça c'est fait...
C'est à ce moment que vos ennuis commencent, régulièrement quand le serveur monte en charge, il plante.

Les chiffres :

Personnellement je tourne en fcgi, donc les processus impliqués sont : apache2, php5-cgi et mysql.

Pour moi ça donnerai :
- Apache : 20M par process
- php5-cgi : 5M minimum, variable en fonction de ce qu'on lui demande
- mysql  : 60M

Le serveur a 3 Go de RAM soit
- 100 x Apache : 2Go
- 100 x php5-cgi : 500Mo
- 1 x mysql : 200M
A ce stade on a donc 2.7Go utilisés  plus le systéme et quelques services, il ne reste plus grand chose ...

Afin d'être tranquille avec le client évoqué plus haut, lors de la reconfiguration d'apache vous avez mis 'à la louche' MaxClients = 200...
Du coup avec notre petit calcul du jour on arrive à
- 200 x apache : 4Go
- 200 x php5-cgi : 1Go
- 1 x mysql : 200M
soit plus de 5Go.....

La Constatation des Faits

Par défaut, il me semble que l'installeur des dediboxes met 500Mo par disque de swap soit 1Go en RAID1.
Donc avec la configuration par défaut, il vous manque 1 bon Giga de mémoire.
Fort de cette constatation (c'est nettement plus sympa de connaitre la nature d'un problème qui vous pourri la vie), arrive maintenant l'angoisse :
- Faut réinstaller la box ?
- Virer apache et mettre lighty (lighttpd pour les puriste),
- Dire au client qu'il lui faut un autre serveur
- Mettre en place un cluster pour faire du load balancing,
- Coder un robot qui redémmarre apache lorsque la mémoire est en dessous d'un seuil.

La Solution :

La solution toute bête : rajouter du swap.
J'entends déjà ceux qui disent :
- Oui donc faut réinstaller !
- Jamais de la vie je fait un repartitionnage à chaud sur un serveur en production
.. a ceux la je répond : ayez la foi, Linux est votre ami...

Les autres Solutions :

Avant de continuer, et donner l'ultime solution, bien que à ce stade les plus vifs auront déjà soit sauté en bas de page ou alors tapoté sur Google pour trouver la commande magique qui fait ça....
Donc avant de continuer, étudions un peu plus les solutions évoquées plus haut :
- Reinstaller la box : en théorie c'est le mieux, toutefois si la charge monte, c'est que le serveur est utilisé donc la réinstallation me semble délicate sans couper le serveur.
- Virer apache et mettre lighty : moui..... Lighty est Beau, il est Fort, il est Sexy mais pas compatible avec apache , donc se retaper tout les htaccess, remettre les vhosts.... De suite la je dirais : mauvaise idée. En même temps ça peut être le début de quelque chose en installant lighty sur une IP/port à part pour tester et avec quelques htaccess rediriger images, CSS, javascript vers lighty. Bah, ça se tente à 4h00 du mat pour voir... Et c'est assez impressionnant : il est 10 fois plus rapide, prend moins de RAM... Mais apache reste Apache et il propose des centaines de modules tès utiles.
- Dire au client qu'il lui faut un autre serveur : avant d'en arriver la il faut déja comprendre d'ou vienne les connections sur le serveur web : spiders/robots, flood, probléme de code, taches cron via wget. De toutes facons, lui proposer un autre serveur n'est viable que si le serveur actuel ne plante pas.
Mettre en place un cluster pour faire du load balancing : Ca c'est top, en plus ça fait cool dans une discussion de geeks : "J'ai deployé une solution HA/LB avec un IP FailOver, ça pète......Quoi!!?? Tu connais pas HA/LB ?? Pfff, High Availability, Load Balancing, et en français ça donne, Haute Disponibilté avec Repartission de charge...". Moui, ce que le gars dit pas c'est qu'il a galéré pendant des mois pour que son truc soit stable et exploitable en production. Donc c'est un bonne solution, complexe et qui ne correspond pas à la situation ou vous avez un client au téléphone qui râle (à juste titre) parce que son serveur est planté.
- Coder un robot qui redémmarre apache lorsque la mémoire est en dessous d'un seuil : Alors ça c'est pas mal, je dirais même que c'est la base, je l'ai fait, le seul reproche est que actuellement c'est lancé par un cron chaque minute (ou 2 ca dépend). Du coup quand la machine est chargée, cron met du temps a se lancer et le moniteur aussi du coup, ce qui, en plus, prend encore un peu de mémoire à une machine qui en avait déja plus..... La solution serait un démon qui resterai en mémoire et qui d'ailleurs pourait scruter le constantes vitales de la machine plus frequement... Work in progress.

La solution Ultime (ou pas...) :

Bon, revenons à nos moutons (qui freezent Content), créer un swap sans toucher aux partitions :
Ici on créé un swap de 2Go (2 millions de blocks de 1024 octets chacun)
mkdir /var/swap
chown root.root /var/swap
chmod 700 /var/swap
dd if=/dev/zero of=/var/swap/01.swp bs=1024 count=2M
chown root.root /var/swap/01.swp
chmod 600 /var/swap/*
mkswap /var/swap/01.swp

Ensuite on ajoute ce swap au /etc/fstab
/var/swap/01.swp       none    swap    sw              0 0
Puis on l'active
swapon -av
Pour vérifier :
swapon -s

Elle est pas belle la vie ?
Bon, j'en entends encore raler:
- mettre un swap sur une partiton ext3 ca va ramer : oui
- le ficher swap va être fragmenté : oui
En même temps à la base, votre serveur plantait. Toutefois même si en théorie c'est géré il est possible de définir une priorité a ce fichier swap afin que le serveur utilise ce swap qu'en dernier recours en mettant ceci dans /etc/fstab
/var/swap/01.swp none swap sw,pri=2 0 0
Pour finir, il est evident que si vous faites un bête copier-coller de ce que j'ai ecris ici, vous allez au devant de problèmes et que je vous prédit prochainement un 'mode rescue'. Toutefois, en comprenant un minimum de quoi on parle, cette astuce vous permettra de faire un peu plus la bringue le week-end Complice.


 

Combien de temps faut il pour transférer un nom de domaine ?

Written by Red, Thursday, 12 February 2009 12:08
Dans le cadre de notre activité d'hébergement les questions autour des noms de domaines sont récurrentes.
Du point de vue de nos clients il est souvent angoissant de savoir quand un nom de domaine sera disponible suite à un transfert ou autres manipulations administratives.

Commençons par le plus simple : les .COM, .NET .ORG...

  • Pour déposer le nom et le rendre actif dernier record chrono en main : 7 minutes Cool
  • Pour transférer le nom de domaine d'un registrar à l'autre  : 5 jours
  • Pour mettre à jour le whois et les serveurs de noms : 24 à 48h
  • Pour mettre à jour un enregistrement DNS :  ça dépend de la configuration des serveurs de noms, dans notre cas le TTL est très court (15minutes) toutefois il faut aussi prendre en compte les caches de votre Fournisseur d'Accés Internet (FAI) le cache de votre systéme d'exploitation et le cache de votre navigateur. Dans les grandes lignes, et via nos serveurs de noms, en 4 heures l'enregistrement DNS est propagé. A titre d'exemple et de mon expérience, dans de cas des serveurs de noms de OVH il faut compter 10 heures.

C'est la que ça ce gate : les .FR  et .EU 

Dans les grands axes les délais sont les même avec quelques petites nuances :
  • Pour déposer le nom et le rendre actif  : 5 jours
La difference majeure se situe au niveau de la validation, l'AFNIC (Association Française pour le Nommage Internet en Coopération), contrôle toute les modifications faites sur le registre FR et RE (Réunion) et ne rends le transfert effectif que si toutes les données sont cohérentes, en clair si ça passe l'outil (très utile d'ailleurs) Zonecheck (http://www.afnic.fr/outils/zonecheck).
En conclusion, la manipulation des noms de domaine, tout en étant assez simple( une fois qu'on a compris le truc), demande de l'expérience, une parfaite compréhension du processus, et de la patience. Si on sait pas ce qu'on fait on risque d'avoir son domaine injoignable, et ça c'est définitivement très anxiogène.
Chez RedJuice, comme on aime bien que vous soyez zen, on gère tout pour vous : du dépot à la configuration des serveurs de noms en passant par le transfert de registrar.
  • Voici le lien vers notre plate forme d'enregistrement de nom de domaine publique avec possibilité de rendre le nom de domaine totalement anonyme (en anglais) : 
  • Si vous avez un manque d'inspiration pour trouver un nom  : 
 

Génération de mot de passe en PHP

Written by Red, Tuesday, 27 January 2009 11:43
Cette fonction permet de générer un mot de passe en PHP. Elle prend 2 paramètres :
  • La longueur du mot de passe
  • La force du mot de passe

Voici un exemple avec les source pour vos faire une idée.


<?php
function generatePassword($length=9, $strength=0) {
    $vowels = 'aeuy';
    $consonants = 'bdghjmnpqrstvz';
    if ($strength & 1) {
        $consonants .= 'BDGHJLMNPQRSTVWXZ';
    }
    if ($strength & 2) {
        $vowels .= "AEUY";
    }
    if ($strength & 4) {
        $consonants .= '23456789';
    }
    if ($strength & 8) {
        $consonants .= '@#$%';
    }

    $password = '';
    $alt = time() % 2;
    for ($i = 0; $i < $length; $i++) {
        if ($alt == 1) {
            $password .= $consonants[(rand() % strlen($consonants))];
            $alt = 0;
        } else {
            $password .= $vowels[(rand() % strlen($vowels))];
            $alt = 1;
        }
    }
    return $password;
}

?>

Ce code n'est pas de moi, je l'ai récupéré ici : http://www.webtoolkit.info/php-random-password-generator.html

 

Générateur pour adresses IP failover

Written by Red, Monday, 26 January 2009 14:37
Le script du dimanche : Générateur pour adresses IP failover

Cet outil en ligne (spartiate) permet de générer les informations nécessaires à la configuration d'adresses IP failover sur une debian.
Il marche au moins chez dedibox et OVH mais devrait marcher chez tout le monde.

Comment ça marche : 
A partir de votre liste d'adresses ip Failover ce script est capable de générer :
les interfaces, les blocs pour chaque IP virtuelle à coller dans /etc/network/interfaces, 
les quelques lignes à poser en ssh pour démarrer les interfaces,
les instructions SQL pour rajouter les adresses IP failover à ISPCP,
et les liens pour tester l'ip dans le cas ou elle est redirigée sur un serveur web.


 

Votre serveur dédié OVH ne boote pas

Written by Red, Thursday, 22 January 2009 06:36
Dans la série des coups de stress de l'administrateur système & réseau (ce qui est en définitive assez fréquent), une source de stress récurrente est OVH.
Sans faire de mauvaise pub, depuis le mois d'août, ils ont décidé de 'purifier' leur architecture. Grand bien leur fasse car il est vrai que pas mal de Spammeurs, Hackeurs et "Gars-qui-feraient-mieux-de-rester-en-mutualisé" se sont empressés de se jeter sur l'offre Kimsufi, qui selon moi et pas mal de monde, venait concurrencer Dedibox sur le marché jusqu'ici monolithique des serveurs dédiés.

Avant de revenir au sujet qui est 'Votre Serveur OVH boote pas' décrivons la problématique des fournisseurs de serveurs Low-cost. En même temps, le marché ayant évolué je trouve que finalement ce sont les autres fournisseurs qui sont High-cost mais bon passons....
Donc le problème est assez simple : les Spammeurs adorent ce type d'offres car ça leur permet d'avoir des IPs pas cher pour spammer. Conséquence : en fonction de votre chance du moment, vous pouvez tomber sur une plage d'IP chez Dedibox ou OVH qui est blacklistée... par Hotmail (Gmail est plûtot efficace contre le spam, Yahoo! : euh SpamAssassin fait définitivement mieux !!).

Dans le cas des hackeurs, disont globalement que ce sont des "utilisateurs" qui paient pas, il hackent une machine et l'utilise pour spammer, scanner les machines voisines, ou tout simplement héberger des contenus illicites à votre insue..... Brrrrr...
Et puis ben ils reste les "Gars-qui-feraient-mieux-de-rester-en-mutualisé", ben comme leur nom l'indique, ce sont les victimes des hackeurs. Pour la simple raison qu'il font un calcul assez simple : 
"Mon mutualisé me coute x € par mois par site, et comme je veux monter 120 sites/blogs (ou alors un gros forum sur War Of Warcraft dont aucun mutualisé ne veut), je me dit que je me prend un serveur à20 ou30€ par mois et c'est tout benef !!"
Le calcul est bon, mais uniquement dans le Monde merveilleux des bisounours ! Parce que un mutualisé il y 1 ou plusieurs admins qui s'occupent des machines et les chouchoute,  un dédié faut se le chouchouter soit même, et il faut lui faire ce qu'il aime sinon il boude (ou boote pas !).

Euh, tu devais pas parler de serveur OVH qui boote pas ??
On y arrive !!
Donc chez OVH on prend tout ça au sérieux, et ils ont raison !! Du coup ils ont mis en place des régles de filtrage au niveaux de leur routeurs. La dernière qui m'a causé un accroissement de stress inutile c'est la protection contre les Scans SSH.
Je développe : Redjuice gère une vingtaine de serveurs répartis sur plusieurs fournisseurs(Dedibox, OVH, RackSpace, Staminus, IPT,....) et continents (Europe et USA), pour gérer tout ce petit monde capricieux je me suis codé quelques scripts qui me permettent d'avoir une vision globale de notre infrastructure. Ces scripts utilisent des Clefs SSH pour s'authentifier auprès des serveurs qu'ils manipulent. Et donc ces scripts lancent en parralèle des commandes SSH sur ces 20 serveurs. Et c'est la que le bas blesse, OVH on décidés il y a quelques jours de limiter le nombre de connections par serveur, visiblement ça serait 1 toutes les 30 secondes, ce qui me semble être ridicule ! Et donc mon serveur vient de se faire arrêter accompagné d'un mail m'expliquant qu'ils me laissait un accès FTP en lecture seule pour récupérer mes données !! 

Après les avoir appelés plusieurs fois leur avoir fait un topo complet sur ma vie, mon oeuvre, mes scripts shell, j'arrive à récupérer mon serveur. Je leur explique que ce sont mes IPs, que ma machine est pas hackée, que j'ai dessus portsentry (détection de scan de ports), mod_security(firewall applicatif HTTP), chkrootkit (un peu d'imagination ?), rkhunter (pour Rootkit Hunter), et que en plus les sites hébergés dessus ne sont pas super sensibles au intrusions.

Me voila donc avec un accès SSH en mode rescue (un genre de mode sans échec windows....un genre). Consciencieux je regarde mes logs, passe 2-3 outils pour vérifier que des fichiers "malveillants" ne sont pas apparus... brrrrr..... Enfin tout bien quoi !

Je reboote la machine et ...ta-tan !! Pas de ping ! A ce stade il est vendredi soir, et j'ai pas envie de passer la nuit avec la machine....Par contre je sens bien que ça ne lui déplairait pas la bougresse !! Mais non ma cocotte je suis pas motivé ! Va falloir que je trouve un moyen rapide de te regler ton compte en 15 minutes chrono et pis partir loin de toi..... boire quelques bières. C'est vendredi soir....

A cet instant une illumination me traverse la tête : chroot la un grand coup et elle va te lacher !!!

Sans rentrer dans les considérations profondes de chroot, disons que c'est le truc magique qui se décrit en une phrase simple 'Change Root'. L'idée c'est que sous linux on peut changer la racine du système de fichier. Donc en gros en mode rescue le disque original est pas monté, on peut le monter la ou on veut par exemple, soyons fous, dans /mnt : 

mount /dev/sda1 /mnt

en faisant un ls /mnt le dique est là et intacte.

ensuite on chroot la machine : 

chroot / /mnt

En clair : la racine maintenant c'est /mnt. Ensuite reste plus qu'a démarrer apache, mysql, bind et ce qui est vital. Faut aussi monter /proc et puis on est bien. Chrootée en 15 minutes elle est calmée et je peux enfin m'évader....

Je laisse le week-end passer et je me motive pour résoudre le problème avec OVH. 1 fois sur 6 je tombe sur un gars, je pense que c'est le même d'ailleurs, un gars qui aime ça. On sentait bien qu'il était assez offusqué de voir que cette machine de voulait pas démarrer, on à exploré de multitude de pistes pendant 2 bonnes heures. Après les avoir toutes explorées on en arrive à la conclusion qu'il va falloir que quelqu'un du datacenter aille voir physiquement la machine démarrer afin de voir ce qu'affiche l'ecran. Mais pour ça il y a un genre de procédure qui implique que je coupe la machine, et que entre 2 et 4 heures plus tard quelqu'un allait aller voir.

C'est exactement ce que j'ai fait et au bout de 1h45 elle a fini par booter sans encombre et en mode normal et ce, bien que le RAID ai été reconstruit et que les disques avaient été vérifiés.

Pour l'info c'est un quadri duo core, 12Go de RAM, avec 2 disques de 750Go RAID1 en reiserfs.




 

PHP_AUTH_USER et FastCGI

Written by Red, Wednesday, 21 January 2009 20:04
Lorsque vous voulez utiliser les fonctions d'authentification HTTP de PHP en mode CGI (ou FastCGI)  les variables PHP_AUTH_USER, PHP_AUTH_PWD et AUTH_TYPE ne sont pas rensignée.
Pour contourner le problème il faut :
Créer ou ajouter ces lignes dans un fichier .htaccess

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
</IfModule> 

En clair cette règle assigne l'entête HTTP d'authentification à une variable d'environnement HTTP_AUTHORIZATION.

Ensuite, voici la source PHP qui permet d'utiliser  PHP_AUTH_USER et PHP_AUTH_PW : 

<?php
// sur mon serveur, bien que dans le .htaccess la variable d'environnement qui 
// reçoit les infos d'authentification s'appelle HTTP_AUTHORIZATION, la variable 
// affichée est REDIRECT_HTTP_AUTHORIZATION, un grand mystère... mais bon....
if(isset($_SERVER['REDIRECT_HTTP_AUTHORIZATION']))
$_SERVER['HTTP_AUTHORIZATION'] = $_SERVER['REDIRECT_HTTP_AUTHORIZATION'];

// les donnèes d'authentification sont dans HTTP_AUTHORIZATION encodées en base64 
// donc il faut les décoder et les extraire
if(isset($_SERVER['HTTP_AUTHORIZATION']))
list($_SERVER['PHP_AUTH_USER'], $_SERVER['PHP_AUTH_PW']) = explode(':', base64_decode(substr($_SERVER['REDIRECT_HTTP_AUTHORIZATION'], 6)));

// a ce stade on se retrouve dans la même configuration que PHP en module
if (!isset($_SERVER['PHP_AUTH_USER'])) {
header('WWW-Authenticate: Basic realm="My Realm"');
header('HTTP/1.0 401 Unauthorized');
echo "L'utilisateur a annulé l'authentification";
exit;
} else {
echo "<p>Bonjour, </p>".$_SERVER['PHP_AUTH_USER'];
echo "<p>Le mot de passe entré: </p>".$_SERVER['PHP_AUTH_PW'];
}
?>
 

Mise à jour de sécurité : Joomla 1.5.9

Written by Red, Sunday, 11 January 2009 02:06
Une mise à jour de Joomla est disponible, il passe donc en version 1.5.9.
Cette mise à jour corrige 81 bugs et 1 faille de sécurité.

Pour information la dernière version, 1.5.8, datait du 10 novembre il y a 2 mois.
Bien sur nos sites ont été mis à jour dés la réception de l'annonce.

Et pour la petite histoire, j'ai corrigé un des bugs et ma modification a été prise en compte dans cette version :).
 

Blog par email : MMS Blog

Written by Red, Friday, 09 January 2009 09:20
Ce composant est un petit bijou : il permet de blogger par mail, c'est à dire que on écrit à une adresse donnée et le mail est publié sur le site.
Ma version est en plus déboguée et traduite en français.
J'ai pour projet de l'intégrer à Joom!Fish afin que les billets soient aussi traduits

http://extensions.joomla.org/extensions/content-&-news/microblogging/38/details

 

Facebook like pour Joomla : GroupJive

Written by Red, Friday, 09 January 2009 09:15
Ce composant permet la mise en place de Groupes Communautaires comme Facebook.

http://www.groupjive.org/index.php?option=com_docman&task=cat_view&gid=23&Itemid=59

 

Etude de cas : mise en place d'un site de réseau social

Written by Red, Friday, 09 January 2009 09:13
Ce PDF est une etude de as sur la mise en plcae d'un site de réseau social uniquement à partir de Joomla et Communauty Builder.

http://www.joomladay.fr/index.php?option=com_jdownloads&Itemid=99999999&task=finish&cid=13&catid=10
 
 
<< Start < Prev 1 2 3 Next > End >>
Page 1 of 3