Comme je l'avais expliqué lors de mon billet sur mon serveur privé virtuel de chez amen.fr, je n'ai pas eu le choix d'avoir un Plesk collé à ma CentOS ! Après quelques tentatives ratées, je donne ici la marche à suivre pour s'en débarrasser, et avoir une distribution proche de l'originale. Notez que cela me servira surtout d'aide mémoire, et que si vous suivez cette procédure, vous ne pourrez revenir en arrière (à moins d'une réinstallation), que vous n'aurez évidemment plus accès à Plesk (mais toujours au menu virtuozzo, donc aux statistiques, à la console de maintenance, etc ...) et qu'il vous faudra l'assumer (vous avez tout à fait le droit de le faire, il est cependant probable que si un jour vous posez une question au support, une réponse avec la "méthode Plesk" vous soit donnée). Il faut donc aussi que vous soyez surs de pouvoir administrer votre serveur sans Plesk (je ne le ferai pas pour vous ;) ). Le contexte étant fixé, on peut y aller.

Histoire de se rendre compte de ce qu'il y a à virer, on peut commencer par un

# yum list extras

Les paquets qui nous intéressent sont ceux commençant par "psa", mais pas seulement. Il y a énormément de chose à retirer. Ce n'est pas spécialement nécessaire, mais je commence par arrêter les services inutiles (certains seront automatiquement redémarrés ensuite) :

# service courier-imap stop
# service qmail stop
# service saslauthd stop
# service drwebd stop
# service mysqld stop
# service httpd stop
# service psa stop
# sh /etc/init.d/spamassassin stop

Il faut forcer la désinstallation des paquets psa-* sans se soucier des dépendances, car certains rpms semblent poser des soucis (les dépendances seront retirées ensuite). J'évite simplement le psa-appvault-gallery car sa désinstallation ne marche pas, fait monter la commande rpm à 100% CPU, et semble même corrompre la base RPM. Je le laisse donc et supprime ensuite le répertoire où étaient contenus les fichiers de tous ces paquets, car il en reste ....

# for i in $(rpm -qa psa*|sed '/appvault-gallery/d'); do echo "Removing "$i;rpm -e --nodeps $i;done
# rm -rf /usr/local/psa/

Une fois fait, on supprime tous les paquets qui étaient installés comme simple dépendance pour Plesk, ou qui ne proviennent pas des dépôts officiels :

# yum remove drweb\\* openssl097a
# yum remove perl-Apache-ASP.noarch perl-Apache-ASP.x86_64 perl-Font-AFM.x86_64 perl-Font-AFM.noarch perl-FreezeThaw.x86_64 perl-FreezeThaw.noarch perl-HTML-Format.x86_64 perl-HTML-Tree.x86_64 perl-MLDBM.x86_64 perl-MLDBM-Sync.x86_64 perl-Text-Iconv.x86_64 perl-TimeDate.x86_64
# yum remove PPWSE-1.1-cos5.build86080722.00.x86_64 sb-publish-3.0.1-200705230938.noarch php-sqlite2.x86_64 php5-ioncube-loader.x86_64 SSHTerm.noarch awstats.noarch courier-imap.x86_64 log4cpp-plesk.x86_64 miva-ssl-stub.i386 mod_bw.x86_64
# yum remove ruby-actionmailer.noarch ruby-actionpack.noarch ruby-actionwebservice.noarch ruby-activerecord.noarch ruby-activesupport.noarch ruby-fcgi.x86_64 # ruby-mysql.x86_64 ruby-rails.noarch ruby-rake.noarch
# yum remove sw-libxml2.x86_64 sw-libxml2-python.x86_64 sw-libxslt.x86_64 sw-xmlrpc-c.x86_64 plesk-skins.noarch
# yum remove vzdummy-apache.noarch vzdummy-glibc.noarch vzdummy-jre-el5.noarch vzdummy-kernel-el5.noarch

Pour terminer avec la désinstallation, je supprime les différents serveurs installés, pour obtenir un système minimal (quitte à en réinstaller ensuite). Les fichiers de configuration d'apache et les bases MySQL sont aussi supprimés au cas où il y aurait eu des choses particulières paramétrées pour Plesk. Certains scripts pour xinetd restant encore sont supprimés, ainsi que les fichiers de configuration conservés et les paquets i386 :

# yum groupremove "Base de données MySQL"
# rm -rf /var/lib/mysql/*
# yum groupremove "Serveur web"
# rm -rf /etc/httpd/conf.d/*
# yum groupremove "serveur de messagerie"
# yum groupremove "serveur de fichier windows"
# yum groupremove "ruby"
# yum remove samba-common php-*
# rm -f /etc/xinetd.d/*psa*
# find / -name *.rpmsave|xargs rm
# rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH} "|grep i386|xargs yum -y remove

La désinstallation de tous ces services fait qu'il n'y a plus de MTA sur le système. Pour remédier à cela :

# yum install sendmail
# alternatives --config mta

Indiquez sendmail comme MTA.

S'en ai fini pour le nettoyage du système. Un petit redémarrage histoire de s'assurer que tout va bien. Notez qu'un "yum list extras" renverra toujours deux paquets :

• psa-appvault-gallery : impossible à désinstaller, mais ses fichiers ont été supprimés
• vzdev : paquet indispensable fournissant le nécessaire pour les connexions (ne pas oublier que l'on est sur un serveur virtuel !)

# reboot

Après le premier reboot, on peut constater qu'on se retrouve avec un serveur minimal. On peut d'abord commencer par une mise à jour du système :

# yum update

La suite concerne mes besoins, vous n'aurez donc pas forcément à installer tout ça. Je commence par installer le dépôt EPEL :

# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm

Puis quelques logiciels nécessaires à mon sens. vnstat pour ne pas avoir à toujours me connecter sur l'interface virtuozzo pour contrôler ma consommation de bande passante, logwatch pour le rapport quotidien du système et system-config-securitylevel-tui pour la configuration du pare-feu :

# yum install vnstat logwatch system-config-securitylevel-tui nmap

Un autre logiciel dont je ne peux me passer est fail2ban. Au moment où j'écris ce billet, je dois prendre la version présente dans epel-testing, bien plus à jour :

# yum --enablerepo epel-testing install fail2ban
# chkconfig fail2ban on

Configuration pour ces différents logiciels :

# sed -i 's/Interface \\"eth0\\"/Interface \\"venet0\\"/' /etc/vnstat.conf
# sed -i 's/eth0/venet0/' /etc/sysconfig/vnstat
# sed -i '3s/^..//' /etc/cron.d/vnstat
# vnstat -u -i venet0
# echo "MailTo = monmail@mail.com" >> /etc/logwatch/conf/logwatch.conf

Je termine par l'installation des différents paquets dont j'ai besoins, pour mon blog et mon dépôt SVN :

# yum groupinstall "Base de données MySQL"
# yum groupinstall "Serveur Web"
# yum install php-xml subversion mod_dav_svn repoview createrepo perl-Text-Iconv

Voilà les différentes étapes nécessaires pour arriver à un serveur qui ne contient que ce dont j'ai besoins. Cela permet d'avoir un système propre, sans paquets superflus, ce qui est intéressant quand on sait le peu de ressources dont dispose le serveur.

Fabien (eponyme)

Il existe, dans de nombreuses langues, de nombreux tutoriels expliquant la façon de mettre en place un dépôt SVN. On peut notamment l'expliquer par le fait qu'il est possible de configurer un dépôt de nombreuses manières, dans la façon de gérer les droits, dans celle de gérer le type d'accès, l'organisation ... Afin de ne pas rajouter une couche de plus à tout ce qui existe, je propose ici directement un exemple d'installation et de configuration. Les étapes que je détaille sont celles que j'ai effectuées pour mettre en place le dépôt SVN de trustyRC, profitant ainsi de mon nouveau serveur privé pour lui ajouter un service supplémentaire. Mon serveur fonctionne sous CentOS 5.3, mais les commandes utilisées ici fonctionnent aussi sous Fedora.

L'objectif

Tout d'abord, voici les quelques contraintes que je me suis fixées :

• Ayant une petite configuration, et un serveur web (apache) tournant déjà, j'ai choisi d'utiliser subversion avec le module apache (mod_dav_svn). Cela m'évite d'avoir à utiliser svnserve, d'ouvrir un port, de gérer un service supplémentaire... Je préfère gérer les accès via apache, l'utilisant déjà pour mes sites
• Le dépôt SVN sera placé dans un vhost spécifique : svn (pour un accès avec une URL de type http://svn.nicoleau-fabien.net/projet...)
• Chaque projet hébergé sera géré séparément des autres, notamment pour les accès. Ainsi il me sera possible d'héberger sur le dépôt un projet auquel je ne participe pas, sans avoir de droits dessus. Si réellement deux projets ont la même liste d'utilisateurs, alors je pourrais faire pointer les fichiers des accès au même endroit
• Pour le moment, il n'y aura pas de gestion de droits avec les ACL. Les actions de lecture (comme le checkout) seront accessibles anonymement, alors que les actions d'écritures (comme le commit) seront soumises à une authentification. Ajouter les ACL ensuite n'est pas compliqué, si le besoins s'en fait sentir, il sera facile de le faire

Il est important de bien comprendre le principe et les atouts de subversion, et ensuite de se renseigner sur les différentes façons de le configurer, afin d'avoir un système proche de ses besoins, et de ses possibilités. Voici les quelques liens que j'ai consultés avant de me lancer dans l'installation et la configuration du dépôt :

• Documentation CentOS
• Documentation fedora-fr
• Documentation détaillant les différentes possibilités (et commandes associées) de subversion
• Documentation ubuntu-fr (assez complète, notamment sur les modes d'accès)

Installation

L'installation est assez simple, on prends le paquet subversion, et mod_dav_svn, qui permettra d'utiliser apache pour l'accès au dépôt :

# yum install subversion mod_dav_svn

Evidemment, il faut un serveur apache installé, configuré, et en marche.

Configuration

La configuration se limite à l'édition du fichier /etc/httpd/conf.d/subversion.conf. Il est bien documenté, et correspond quasiment à la configuration finale voulue. Une petite particularité dans mon cas : mes sous-domaines pointent actuellement tous sur le même serveur (ils me servent surtout  à bien dissocier mes services), donc afin que l'accès au dépôt ne se fasse bien que dans le sous-domaine svn, je déclare un VirtualHost dans ce fichier, et place la configuration de subversion à l'intérieur de ce vhost. Voici le contenu du fichier de configuration (commentaires retirés) :

LoadModule dav_svn_module     modules/mod_dav_svn.so
LoadModule authz_svn_module   modules/mod_authz_svn.so
<VirtualHost *:80>
        ServerName   svn.nicoleau-fabien.net
        # Dossier contenant les pages
        DocumentRoot /var/www/svn

        <Location /trustyrc>
               DAV svn
               SVNPath /var/www/svn/trustyrc
               # SSLRequireSSL
               AuthType Basic
               AuthName "trustyRC subversion repository"
               AuthUserFile /etc/subversion/svn-auth-trustyrc.conf
               <LimitExcept GET PROPFIND OPTIONS REPORT>
                      Require valid-user
               </LimitExcept>
       </Location>
</VirtualHost>

J'utilise ici une configuration spécifique pour le projet trustyRC, et non pas une configuration qui engloberait plusieurs projets. Cela m'obligera à modifier ce fichier à chaque nouveau projet hébergé sur le dépôt, mais me permet de bien les dissocier. Comme dis plus haut, "au pire", je pourrais faire pointer les directives AuthUserFile de plusieurs projets sur le même fichier, si les utilisateurs sont les mêmes. A part le fait que le dépôt soit placé dans un vhost, il n'y a rien de particulier ici. On remarque que le "Require valid-user" est placé dans un LimitExcept, permettant de ne demander une authentification que pour les opérations d'écriture. Un checkout par exemple pourra se faire anonymement.

Gestion des comptes utilisateurs

La gestion des utilisateurs se fait par l'intermédiaire d'un fichier des mot de passes, créé par la commande htpasswd :

$ htpasswd -cm /etc/subversion/svn-auth-trustyrc.conf eponyme

Le mot de passe pour l'utilisateur sera demandé deux fois. Le fichier sera ensuite créé (option -c, à n'utiliser que la première fois pour un même fichier) et le mot de passe chiffré avec un algorithme md5 (option -m, au peut utiliser -s pour du SHA). Pour un second utilisateur dans le même fichier, on utilisera donc cette syntaxe :

$ htpasswd -m /etc/subversion/svn-auth-trustyrc.conf second_user

Préparation du dépôt

Création du répertoire qui contiendra les projets, puis création du dépôt pour le projet trustyrc :

# mkdir /var/www/svn
# cd /var/www/svn
# svnadmin create trustyrc
# chown -R apache:apache trustyrc

Il faut ensuite préparer l'arborescence du projet. Je choisis le schéma classique trunk, branches, tags :

$ mkdir -p /tmp/trustyrc/{trunk,branches,tags}

Il n'y a plus qu'a initialiser ces répertoires, selon l'état du projet. J'ai pour ma part créé des tags avec les sources des anciennes releases, et copié les sources actuelles dans le trunk.

Importation

Le dépôt et l'arborescence sont prêts. Il n'y a plus qu'a importer le nouveau projet :

# svn import /tmp/trustyrc/ file:///var/www/svn/trustyrc -m "Initialisation du dépôt pour le projet trustyRC"

Checkout

Tout est prêt maintenant, ne reste plus qu'à récupérer une copie de travail du projet en cours pour travailler sur un autre poste :

$ svn co http://svn.nicoleau-fabien.net/trustyrc/trunk/

La première révision est alors téléchargée. Aucune authentification n'est demandée.

Commit

Après avoir effectuer des modification, on peut "commiter" les changements vers le dépôt :

$ svn ci -m "Première mise à jour des sources"

Pour cette opération "d'écriture", un login et un mot de passe sont alors demandés (ceux créés avec la commande htpasswd et stockés dans le ficher /etc/subversion/svn-auth-trustyrc.conf).

Conclusion

Les objectifs cités au départ sont remplis. Un dépôt svn offre une réelle souplesse pour la gestion des sources. Une étape supplémentaire pourrait d'être utiliser en plus du dépôt le logiciel trac, l'association semblant être intéressante. Je vous conseille vraiment de prendre le temps de lire les documentations cités, et même d'autres, afin de bien comprendre le principe, d'utiliser la bonne configuration, et de découvrir toutes les commandes/possibilités offertes. Pour ceux qui choisiraient d'utiliser svnserve, notez qu'il est possible de l'utiliser avec xinetd.

Fabien (eponyme)

Voilà longtemps qu'il était réservé, et pourtant toujours pas utilisé : j'ai enfin lancé mon domaine nicoleau-fabien.net.

J'ai en effet profité de la mise en place de mon nouveau serveur privé et de la migration de tous mes services web pour l'utiliser. J'ai de plus créé différents sous-domaines :

• blog.nicoleau-fabien.net: héberge mon blog. Attention, le flux des billet a donc changé :  http://blog.nicoleau-fabien.net/index.php?feed/rss2
• http://www.nicoleau-fabien.net/ : simple alias du domaine principal, qui à la racine redirige vers le blog. Peut-être ferais-je un petit portail un jour
• rpms.nicoleau-fabien.net : naviguation dans mes RPMs (merci repoview). Les RPMs peuvent paraitre obsolètes pour certains, mais je rappelle que je ne package que pour les dépôts officiels, et que je ne les propose en téléchargement qu'en attendant qu'ils soient approuvés. Je ne les mets donc plus à jour sur mon site ensuite.
• trustyrc.nicoleau-fabien.net: contient les fichiers relatifs à mon bot IRC, le guide d'utilisation, et la documentation du code

La gestion du domaine (et des sous-domaines) est vraiment simplissime chez gandi, hébergeur de mon nom de domaine. Pour les gérer avec apache, c'est la aussi un jeu d'enfant grâce à la documentation fedora, et notemment l'article de Remi.

La migration du blog vers le nouveau serveur a été simple (plugin import/export de dotclear), mais en revanche, la mise en place du nom de domaine a été plus complexe. J'ai dû, à grand coups de sed, modifier les URLs du fichier exporté pour mettre à jour les liens, en faisant attention aux anciens sous-dossiers qui sont pour certains devenus des sous-domaines, et pour d'autres sont restés des sous-dossiers ... mais d'un autre sous-domaine ... Les choses auraient été bien plus simple si mon dotclear avait été installé à la racine de mon dossier d'hébergement chez free. C'est maintenant corrigé, ca sera plus facile la prochaine fois ^^.

Pour les liens existants vers l'ancien hébergeur (free), pas de soucis normalement. J'ai certes vidé mon espace, mais j'ai laissé un fichier htaccess contenant quelques directives "Redirect permanent" permettant de rediriger l'intégralité des requêtes vers le nouvel emplacement. J'ai fait quelques tests en cherchant sur le net des liens pointant vers mon site, et la redirection s'est toujours bien faite. La migration est donc transparante, notemment pour les lecteurs RSS. Cependant, mettez à jour vos favoris ou flux RSS si vous en avez, car un jour l'hébergement free sera peut être fermé.

Bonne naviguation sur ce nouveau domaine !

Fabien (eponyme)

Depuis quelques temps, je pensais me prendre un serveur privé, pour différentes raisons :

• Mon BNC et mon robot IRC sont hébergés chez girafon, qui n'est plus ce qu'il était, et qui me coûte un peu plus de 5 euros par mois (location d'un shell + une IP dédiée)
• Mon blog, mes RPMs, et toute mon activité web était hébergée chez free.fr, ce qui n'est franchement pas le top
• J'avais envie de jouer un peu avec un vrai serveur en prod

Mes besoins étaient donc très faibles, et j'étais enbêté à l'idée de prendre un kimsufi, ou un RPS, qui bien qu'avec des coûts très faibles, me revenaient "cher", pour la faible utilisation que je souhaitais en faire. J'ai ensuite découvert l'offre VDS+5 de chez AMEN, qui pour 5 euros (HT), offre un serveur virtuel linux, allourdi d'un Plesk (mais qui se retire, ca sera l'objet d'un prochain billet), avec une config raisonnable, et des performances qui m'ont surprises (attention, tout est relatif, on parle d'un serveur virtuel à 5 euros ...).

5 distributions sont disponnibles :

• CentOS
• Debian
• Fedora 8 (ils ont laissé trainer le core ...)
• Suse
• Ubuntu

J'ai choisi une CentOS, qui m'a été livrée le lendemain matin ! Je teste donc ce serveur depuis presque trois semaines, en y ayant installé tous les services dont j'ai besoins ... et tout tourne à merveille ! J'ai eu pas mal de questions au départ à poser au support, et j'ai toujours obtenu des réponses claires, complètes, et rapides. De plus il y a quelques services fournis, comme la réinstallation complète et gratuite du serveur en moins de deux heures, dont j'ai eu besoins au départ pour mes tentatives ratées de suppression de Plesk, la visualisation de la bande passante utilisée, des logs, la possibilité d'ouvrir une console de maintenance, quand le serveur ne démarre plus par exemple (la aussi, bien utile pendant mes tests ...), et pas mal d'autres petites choses. En plus de tout cela, il y a Plesk, mais je ne pourrais rien vous en dire, car c'est la première chose que j'ai virée !

Bref, pour un prix identique à ce que j'avais avant, j'ai un produit d'une bien meilleure qualité ! Une offre plutôt complète que je conseille à tous ceux qui souhaitent "jouer" avec un serveur pour pas cher, et maintenir quelques services en production. Adieu donc les problèmes chez girafon, la lenteur et les erreurs de free ! Me voilà seul maître de toutes mes activités sur internet.

Je détaillerai dans un prochain billet les quelques manipulations à effectuer pour se débarrasser de Plesk (et seulement lui, pas des autres servces, comme la console de maintenance qui peut être elle bien utile !) et avoir un serveur au plus proche de la distribution de base choisie (avec de nouveau les possibiliés de faire les mises à jour notemment !).

Fabien (eponyme)