Lors de la migration d’un serveur mysql de la version 5.0 à la version 5.1 j’ai eu un message d’erreur lors du lancement du serveur :
ERROR 1577 (HY000) at line 1: Cannot proceed because system tables used by Event Scheduler were found damaged at server start
J’ai résolu le problème en lançant cette commande :
> mysql_upgrade -u root -p --force
APC est un cache d’OPCodes pour PHP (version inférieure à 5.5). Il permet de mettre en cache au niveau serveur le code de PHP précompilé afin de ne pas refaire ce traitement.
Vous trouverez plus d’informations dans l’article de Julien Pauli sur developpez.com.
Ici il s’agit de voir comment l’installer sous Debian. Très facile finalement, il existe un paquet pour ça:
> apt-get install php-apc
Il faudra bien sûr redémarrer Apache.
Par défaut, le fichier permettant le monitoring du cache est situé dans /usr/share/doc/php-apc et s’appelle apc.php.gz. Il faudra donc le décompresser:
> gzip -d apc-php.gz
Il vous suffit de déplacer ce fichier où bon vous semble.
Si vous installez le package à partir de dotdeb, le fichier de monitoring ne sera pas présent. Dans ce cas, grâce à un phpinfo(), récupérez la version d’apc installée puis rendez vous sur http://pecl.php.net/package/apc
Choisissez votre version d’APC, localisez apc.php et téléchargez le.
A noter que le fichier de config d’APC se situe dans:
/etc/php5/conf.d/apc.ini
Vous pourrez trouver toutes les directives de configuration dans la documentation sur php.net, notamment le paramètre apc.shm_size qui permet d’ajuster la ram utilisée.
Dernièrement j’ai eu à migrer le site d’un client d’un serveur dédié à un autre.
Au lieu de faire un backup des données sur ma machine puis les renvoyer sur le nouveau serveur, j’ai décidé de faire directement un transfert de serveur à serveur via SSH. C’est nettement plus rapide car on bénéficie de la bande passante du serveur.
Un site est sur un serveur dédié A. Vous voulez le migrer sur un serveur dédié B. La migration des fichiers et de la base de données éventuelle ne pose pas spécialement de problème. Ce qui est plus délicat, c’est lorsque vous allez modifier les pointages DNS du nom de domaine : en effet, le temps de la propagation, certains visiteurs vont rapidement arriver sur le serveur dédié B alors que d’autres vont rester bloqués sur le serveur A pendant 24 à 48h. Si dans le cadre d’un site statique cela ne pose aucun souci, c’est plus problématique dans le cas d’un site dynamique car cela peut engendrer une désynchronisation de la base de données entre les deux serveurs et conduire à des pertes de données.
L’idéal serait que le serveur A puisse rediriger les visiteurs sur le serveur B le temps de la propagation des DNS. Apache va nous y aider.
Malgré le fait de demander une Debian nue à l’installation de mon serveur dédié, OVH m’a mis une distrib qui semble un peu modifiée par eux, notamment au niveau du noyau. Le noyau que j’ai au départ a un nom tout bizarre genre bzImage-2.6.27.10-xxxx-grs-ipv4-64.
En fait c’est un noyau préparé par OVH qui contient les derniers patchs de sécurité et qui permet de se passer de modules externes car ils sont embarqués. Problème: quand j’ai voulu upgrader ma distrib de Etch à Lenny, j’ai eu énormément d’ennuis et j’ai dû faire appel à un ami spécialiste pour me dépatouiller.
Le premier problème a été Lilo: il a commencé à me mettre des warnings pendant la mise à jour. Comme je n’étais pas sûr des conséquences que cela aurait au reboot et vu que Lilo commence sérieusement à dater, on a décidé de mettre Grub, et là tout est parti en vrille, ce qui n’aurait pas été le cas si j’avais eu un noyau standard… En effet d’une part Grub se base sur le nom d’un noyau standard pour s’installer, ce qui n’était pas le cas. La config de grub ne n’est donc pas faite correctement. On s’est donc dit que dans ce cas, on allait donner à Grub ce qu’il voulait, c’est à dire un noyau standard. Sauf que la il va aussi falloir gérer les modules à la main. En plus de cela le serveur était en raid1 logiciel, ce qui nécessite une maipulation supplémentaire avec Grub.
On va donc essayer à travers cet article de remettre la distribution droite dès le départ étant donné que le serveur dédié sur lequel je refais cette expérience est neuf.
Ce pense-bête a été fait à partir des deux articles suivants:
http://blog.fabroce.info/post/2006/11/19/Installer-un-depot-subversion-sur-une-Debian
http://blog.utopiaz.org/2008/04/mise-en-place-svn-et-virtual-hosts-apache/
Son but est de mettre en place un serveur subversion sur une Debian permettant la gestion de plusieurs dépôts avec une gestion des droits différente selon les dépôts. Lire le reste de cet article »
Suite à un bug présent sur le PHP installé sur ma distribution stable, j’ai dû faire une mise à jour afin de pouvoir installer la version testing, sans pour autant basculer complètement sur cette dernière. Le but du jeu est d’installer uniquement le paquet voulu (et ses dependances bien sûr).
J’ai eu droit à cette erreur en faisant un apt-get update. J’ai trouvé la solution ici:
http://e.rycks.com/index.php/post/2005/08/17/22-dynamic-mmap-ran-out-of-room
pour résumer il faut aller dans /etc/apt/apt.conf.d/ et créer un fichier 10cachelimit (le nom du fichier peut-être modifié à votre guise). Y placer l’instruction suivante:
APT::Cache-Limit "10000000";
Cela permet à APT d’utiliser plus de RAM. La valeur entre guillemets est à modifier selon les besoins. Personnellement j’ai dû passer à 20000000 pour que cela fonctionne.
Les screens sont vraiment indispensables pour tous ceux qui travaillent en mode console sous ssh. Ils permettent de créer une ou des consoles virtuelles sous la même session qui ne se détruisent pas lorsque l’utilisateur se déconnecte. Concrêtement, lorsqu’on lance une compilation dans un screen, si vous avez un plantage réseau, connexion ou autre, la compilation continue. On peut se relogguer et récupérer la session screen qui était en cours. En plus de la protection apportées, les screens sont efficaces pour lancer un travail qui peut durer longtemps. On peut ainsi lancer un travail sur un serveur le soir, s’en déconnecter et aller se coucher, puis le lendemain reprendre le screen et obtenir le résultat.
Cet article était présent sur l’ancienne version de coolcoyote.net. Comme je le trouve utile, je le remet, même si je ne l’ai pas retesté depuis.
Pour commencer nous allons définir que:
©2008 CoolCoyote.net - propulsé par WordPress
Articles (RSS) et Commentaires (RSS).
