Archive pour la catégorie ‘Linux Debian’

Configurer un certificat Let’s Encrypt sur Debian

vendredi 11 novembre 2016

Sources :

Cette installation a été effectuée sur une Debian Wheezy avec Apache 2.2.x mais cette doc fonctionne également sur une Jessie. Les commandes ci dessous sont lancées en root (pensez à rajouter les sudo si besoin).

Nous allons ici utiliser Certbot qui est le client officiel Let’s Encrypt pour gérer les certificats sur votre serveur. Il existe cependant d’autres alternatives.

Première chose à faire, vérifier que le module SSL d’Apache est bien activé (dans /etc/apache2/mods-enabled). Si ce n’est pas le cas :

> a2enmod ssl
> service apache2 restart

Installer ensuite le client Let’s Encrypt  dans le répertoire /usr/local/sbin

> cd /usr/local/sbin
> wget https://dl.eff.org/certbot-auto
> chmod a+x certbot-auto

Lire le reste de cet article »

cp et « liste d’arguments trop longue »

mercredi 12 mars 2014

Si lors de la copie d’un grand nombre de fichiers vous avez le message d’erreur :

Liste d'arguments trop longue

C’est que le nombre de fichiers est trop important. Que ce soit pour cp, rm ou mv, les fichiers sont passés en paramètres de la commande.

Dans ce cas on peut passer par find pour résoudre le problème :

> find /dossier/source/ -type f -name '*' -exec cp {} /dossier/destination/. \;

 

Installation de Composer sous Linux et Windows

mardi 25 septembre 2012

Informations tirées des blogs :

Installation sous Linux

Utiliser la commande

> curl -s https://getcomposer.org/installer | php

Ou alors si curl n’est pas installé :

> php -r "eval('?>'.file_get_contents('https://getcomposer.org/installer'));"

Idéalement, on va déplacer ensuite le fichier composer.phar dans /user/local/bin pour pouvoir y accéder de façon globale sur le système:

> mv composer.phar /usr/local/bin/composer

Désormais si l’on fait un :

> composer --version

On doit avoir un résultat du type:

Composer version 6bd7ca0

Si on veut installer directement composer dans le répertoire /usr/local/bin :

> curl -s https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin

Installation sous Windows

Nous n’avons pas de commande curl, donc nous allons utiliser la deuxième méthode. Je pars du principe que nous utilisons WAMP sous Windows 7, que nous avons une installation avec les répertoires par défaut, que la version de PHP est la 5.3.13 et que vous savez utiliser la console de commandes Windows.

Tout d’abord, ouvre le fichier php.ini qui se trouve dans le répertoire c:\wamp\bin\php\php5.3.13 et assurez-vous que la ligne

extension=php_openssl.dll

est décommentée (supprimez le point virgule au début de la ligne). Assurez vous également d’ajouter le chemin c:\wamp\bin\php\php5.3.13 à la variable Path de votre système, cela permettra d’utiliser la commande php n’importe où.

Pour cela, Menu Démarrer / Panneau de configuration / Système et Sécurité / Système / Paramètres système avancés. Cliquez sur le bouton « Variables d’environnement », cherchez la variable Path dans la première fenêtre et double cliquez dessus. A la fin de la ligne rajoutez :

;c:\wamp\bin\php\php5.3.13

N’oubliez pas le point-virgule ! Validez et fermez tout.

Ouvrez maintenant une console et lancez la commande :

php -r "eval('?>'.file_get_contents('https://getcomposer.org/installer'));"

Un message devrait vous indiquer que l’installation s’est bien passée. La problématique sous Windows est que contrairement à Linux, on ne va pas pouvoir utiliser directement la commande composer et qu’il faudra installer une copie de composer.phar dans chaque répertoire de projet. Il est possible d’améliorer cela en bidouillant un peu 🙂

Commencez par déplacer composer.phar dans le répertoire c:\wamp\bin\php\php5.3.13

Toujours dans ce répertoire, créez le fichier composer.bat que vous allez ouvrir avec un éditeur de texte (le bloc notes fera l’affaire). Saisissez les commandes suivantes :

@echo off
php c:\wamp\bin\php\php5.3.13\composer.phar %*

Et sauvegardez (évidemment personnalisez si vos répertoires ne sont pas les mêmes).

Ouvrez à nouveau une console et tapez

composer --version

Normalement, tout devrait fonctionner. Désormais vous pouvez utiliser composer comme sous Linux ! Une simple mise à jour de composer.phar dans le répertoire /usr/local/bin ou c:\wamp\bin\php\php5.3.13\ vous permettra de profiter de cette nouvelle version partout

Installation de vlogger sur squeeze

lundi 13 février 2012

vlogger est un petit script qui va s’occuper de gérer l’écriture des logs à la place d’Apache. Pourquoi ? Car il est bien mieux optimisé qu’Apache pour faire cette tâche et que du coup nous allons soulager notre serveur et économiser des ressources qui seront plutôt utilisées ailleurs. De plus sa façon de créer les logs est plutôt sympathique: vlogger va créer dans le répertoire de logs d’Apache un répertoire pour chaque VirtualHost du serveur (ce nom sera basé sur le ServerName). A l’intérieur, vlogger va créer un fichier de log différent pour chaque jour, et va créer un lien symbolique access.log vers le fichier de log du jour.

Lire le reste de cet article »

Migration d’un serveur mysql 5.0 à 5.1 : ERROR 1577 (HY000)

lundi 13 février 2012

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

Installation de APC sous Debian

lundi 7 juin 2010

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.

Transfert de fichiers via SSH

mardi 18 août 2009

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.

Lire le reste de cet article »

Rediriger le traffic HTTP d’un serveur à un autre avec Apache

mardi 4 août 2009

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.

Lire le reste de cet article »

Configuration d’un serveur dédié chez OVH

mercredi 15 juillet 2009

Ça faisait un moment que je n’avais pas eu à configurer un serveur dédié pour de la production. L’occasion d’en faire un petit article, le but étant de faire un serveur très basique, sans gestion de boîte mails, sans LDAP, sans chroot, etc. Juste une base LAMP.

Ce serveur dédié a été choisi chez OVH. J’ai bien sûr demandé une Debian nue mais ça n’a pas vraiment été le cas. En fait, OVH livre une distribution Debian avec un noyau personnalisé et plusieurs outils installés par défaut. Suite à une mésaventure lors du passage de Etch à Lenny sur un de mes dédiés, j’ai décidé de ne plus laisser le noyau d’OVH mais d’installer un noyau standard. Si cette manipulation vous intéresse, voyez ce billet. Sinon ce qui suit fonctionne quand même parfaitement. Ces infos sont désormais obsolètes, GRUB2 semble parfaitement gérer les noyaux OVH automatiquement.

Lire le reste de cet article »

Changer le noyau d’une Debian OVH

vendredi 3 juillet 2009

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.

Lire le reste de cet article »