Mémo autohébergement

Attention ! Le contenu de cette page n’est plus mis à jour et reste uniquement en ligne à des fins d’archivage.

Dernières mises à jour :

  • 14 mai 2017, refonte du blog. Je laisse cette page pour les archives, mais elle est en grande partie obsolète maintenant :/
  • 31 juillet 2014, reprise en profondeur de la documentation. Refactor du début sur le partitionnement, ajout d’un sommaire, suppression de parties obsolètes (Firefox Sync / SVN), entrée de FreshRSS et de MinigalNano, ajout de parties sur Lutim et Node.JS.
  • 20 avril 2014, reprise de la partie sur le partitionnement et Owncloud / Firefox Sync / SNI.

Sommaire

Monter son propre serveur, s’autohéberger ?

Monter son propre serveur n’est pas très compliqué et est même largement accessible pour quiconque a un peu de temps à y consacrer et quelques connaissances sur Linux. Ce guide a été écrit dans l’optique de me servir d’aide-mémoire le jour où je devrai tout réinstaller. Il n’est donc pas forcément très détaillé ou très complet et ne vise pas à être un guide pas-à-pas pour installer son serveur. En revanche, il donne des liens vers tous les sites et toutes les ressources que j’ai utilisées, et liste les quelques points qui peuvent porter à confusion et sur lesquels on peut perdre pas mal de temps, afin de vous permettre de moins galérer que moi le jour où vous déciderez de passer à l’autohébergement. En particulier, il m’arrivera de décrire les grandes étapes, sans tout détailler, notamment sur l’installation des scripts webs, qui fonctionnent tous de la même façon. De même, je n’ai pas eu le courage de prendre des photos de toutes les étapes d’installation, et si vous cherchez des guides illustrés, il faudra visiter les liens à travers cette page (et puis de toutes façons, des photos de ligne de commande… :).

Pour toutes remarques, suggestions, commentaires, modifications à proposer, pour me dire que vous n’avez rien compris, que je dis n’importe quoi ou au contraire, parce que ça vous a servi, n’hésitez pas à m’envoyer un e-mail. Vous trouverez toutes les informations nécessaires sur ma page contact. De même, si certains liens sont morts, n’hésitez pas à me le signaler que je puisse fournir des liens alternatifs ou recopier les explications.

On va donc s’intéresser à l’installation d’un serveur personnel complet tournant sous Debian Stable permettant d’héberger un certain nombre de services afin de s’affranchir des services centralisés : Google, Twitter, DropBox… À noter que pour un serveur, il n’y a pas besoin d’installer d’interface graphique, qui alourdirait le serveur plus qu’autre chose. On va donc tout gérer à la ligne de commande (ceci dit, ce n’est pas très dur à appréhender) ! :)

Il est préférable de lire (ou au moins survoler :) ) l’intégralité de cette page pour avoir une vision d’ensemble de la procédure et de ce que cela implique (notamment les contraintes liées au FAI, discutées dans la partie “comment j’accède à mon serveur de l’extérieur”). Certaines informations sont disséminées à travers cette page, à l’étape logique où elles interviennent lors de la mise en place, mais elles peuvent également intervenir au moment de la prise de décision de s’auto-héberger. De plus, j’ai listé pas mal de liens dans mon Shaarli, ici ou là notamment. Je vous invite à faire une recherche rapide dans mon shaarli pour les scripts et les fonctions avancées (email, git, …) pour avoir les informations les plus à jour.

Encore une dernière remarque : il vaut mieux tout mettre en place jusqu’au serveur LAMP d’une traite, ce qui permet d’avoir une base fonctionnelle et sécurisée. On peut ensuite installer chaque service petit à petit.

Note : Dans les liens vers mon SnippetVamp, les deux premières lignes commençant par # sont des commentaires pour avoir le titre du script. Elles ne sont donc pas à prendre en considération.

Petit disclaimer et mise en garde

Car il faut bien en parler également… S’auto-héberger, ça veut dire être responsable d’une machine, qui doit tourner H24 et qui héberge un certain nombre de services plus ou moins critiques. En particulier, il s’agira sûrement d’une machine ouverte sur l’extérieur (si c’est pour accéder à ses fichiers depuis son réseau local, c’est bien, mais ça ne va pas remplacer Dropbox). Ça veut donc dire qu’il faut que la machine soit sécurisée et qu’elle risque de subir des attaques régulières. De plus, l’autohébergement a un coût, financier et humain. Financier, car il faut une machine qui tourne en permanence (électricité tout ça, ou serveur dédié / VPS chez un hébergeur) et humain car il faut y consacrer un peu de temps pour que cela fonctionne.

Enfin, quand vos mails sont chez GMail, s’il y a une panne quelconque, c’est à Google de s’en occuper et de rétablir le service dans les plus brefs délais. Si vous vous autohébergez, c’est à vous d’assurer la maintenance. Il faut donc réfléchir un peu avant de mettre des services critiques sur sa machine (mails notamment) : est-ce vital pour vous d’avoir un serveur de mails disponible en permanence et dans toutes les situations ? Si oui, il n’est pas impossible de s’autohéberger, mais il faut y avoir pensé avant :). De même, vous êtes le seul responsable de vos backups etc.

Ceci étant dit, je passe pas tant de temps que ça à bidouiller mon serveur, et ça fonctionne plutôt bien. Je n’ai pas (encore) eu de problèmes et je ne regrette absolument pas :)

S’auto-héberger ?

Depuis le début de cette page, je parle d’autohébergement, mais finalement, pourquoi s’autohéberger ? De nombreux articles traitent le sujet bien mieux que je ne pourrais le faire, inutile de les paraphraser ici. Parmi les articles qui m’ont réellement donné envie de m’autohéberger, on peut citer :

Enfin, il faut noter que vous devrez laisser votre serveur allumé 24h/24h (ou presque, selon vos besoins). Il faut donc prendre en compte le coût en électricité (300W pour un PC standard, quelques dizaines de Watts pour un mini-PC type Raspberry Pi ou à base d’Atom).

Pré-requis

Il vous suffit d’avoir un ordinateur que vous pouvez dédier à cet usage (un “vieil” ordinateur peu puissant peut largement suffire, il est également possible de partir sur un ordinateur peu puissant type Raspberry Pi ou à base d’Atom, qui en plus consomme très peu) et que vous pouvez donc laisser allumé et connecté à Internet 24h/24. Personnellement, j’ai commencé avec un vieux PC avec un Pentium IV et 768Mo de RAM que j’avais à la cave, puis suis passé sur un serveur dédié OVH (kimsufi, Celeron220 monocoeur, 500Go de disque et 2Go de RAM), qui me suffisait amplementi, avant de passer sur la dernière gamme de Kimsufi (C2D E7400, 4Go de RAM, 500Go en RAID1) principalement pour la sécurité apportée par le RAID1. Je suis passé sur un serveur dédié principalement pour des contraintes de gestion (il est plus facile de redémarrer un serveur dans un datacenter que dans sa cave si on n’est pas sur place) et de bande passante, ma connexion ADSL étant vraiment trop juste pour héberger mes fichiers.

Quelques pré-requis liés à votre FAI : voir la section “comment j’accède à mon serveur de l’extérieur”. Pour l’essentiel, il vous faut une connexion stable et en xDSL (pour avoir un débit suffisant). Le A de ADSL signifie Asymétrique, les FAI ayant jugé au moment du développement de cette technologie que les particuliers n’avaient pas besoin d’envoyer du contenu, mais seulement d’en recevoir. Ainsi, votre débit en download (depuis Internet, vers vous) est bien plus élevé que votre débit en Upload (de vous vers Internet). Si vous pouvez, l’idéal est d’avoir du SDSL (certains FAI le proposent, OVH notamment) ou une connexion par fibre. Ainsi, vous ne souffrirez pas de votre faible vitesse de connexion (chez moi, je plafonne à 100ko/s en upload, de mon serveur vers mon ordinateur local…)

Au niveau de la connexion de votre serveur à votre routeur, celle-ci doit être en ethernet (ou éventuellement en CPL). Une connexion en wifi est à proscrire, les débits pouvant fluctuer trop facilement et n’étant pas suffisants.

Enfin, je pars du principe que vous connaissez un minimum les systèmes linux et que vous connaissez un minimum les serveurs web (Apache, WAMP etc.) pour savoir comment cela fonctionne et comment fonctionne un site internet. Si ce n’est pas le cas, il existe un très bon tutoriel sur les bases de Linux sur le Site du Zéro (la partie “interface graphique” n’est pas intéressante dans notre cas car notre serveur sera piloté en ligne de commande) ainsi que des cours sur le HTML/CSS et le PHP sur ce même site. Ça me semble être de toutes façons un pré-requis obligatoire avant de considérer l’idée d’avoir son serveur.

À part le PC qui va servir à installer notre serveur, il n’y a rien de particulier à acheter. Il est bien sûr possible d’acheter un nom de domaine ou d’autres services comme on le verra plus bas, mais ce n’est pas obligatoire. Si vous ne souhaitez pas garder un ordinateur allumé chez vous 24h/24 ou que vous souhaitez profiter d’une meilleure bande passante que la vôtre, il est également possible de “louer” un serveur chez un hébergeur. Cela revient à un peu plus cher, mais cela marche mieux. Un VPS (serveur virtuel, suffisant pour ce qu’on va installer) chez OVH revient ainsi à 5€ par mois hors taxe, 10€ par mois chez Dedibox avec un plus gros espace de stockage, et est largement suffisant pour l’utilisation que vous en ferez. Un serveur dédié, plus puissant et sur lequel vous aurez un accès root revient à une dizaine d’euros par mois. Vous aurez également l’avantage de ne pas (trop) avoir à vous soucier du matériel. Enfin, divers accessoires peuvent être utiles, dont un onduleur si votre alimentation électrique a tendance à fluctuer ou si vous avez souvent des coupures électriques.

Enfin, comme déjà dit plus haut, votre serveur ne sera QU’une unité centrale, pas besoin d’écran ni de clavier et encore moins de souris une fois la phase d’installation passée (ie une fois l’accès SSH mis en place).

Installation du système

Note  : Il existe aussi YunoHost qui est une solution plus clé en main pour l’autohébergement, sous la forme d’une distribution à installer. Celle-ci peut facilement être installée sur Raspberry-Pi ou virtualisée, pour tester, et constitue une alternative à bon nombre d’étapes décrites dans ce guide. Ne l’ayant pas personnellement testée, je la signale ici, mais ne saurait donner plus de conseils.

On va installer une Debian stable. Cette distribution Linux est parfaite pour les serveurs, elle ne contient que des logiciels qui ont été longuement éprouvés et qui ont donc un minimum de failles de sécurité. Il ne s’agit pas toujours des dernières versions de ces logiciels, mais ce qui peut être génant sur un poste de travail pour lequel on n’a pas besoin d’une sécurité absolue mais plutôt des dernières fonctionnalités devient un avantage pour un serveur. C’est donc une distribution de choix pour un serveur.

On commence par récupérer l’image du CD d’installation (netinstall) sur le site de Debian. Une fois l’image iso gravée, il suffit de booter sur le CD. Puis :

  • On choisit la langue d’installation.
  • On parcourt les écrans en répondant aux différentes questions (nom du serveur, mot de passe…). Vous pouvez renseigner ce que vous voulez pour le nom du serveur, mais si vous prévoyez d’utiliser un nom de domaine, il faut mettre le nom de domaine utilisé comme nom du serveur (même si cela peut se changer ultérieurement).
  • On partitionne le/les disque(s) (cf. section plus bas).
  • Enfin, Debian demande quels logiciels supplémentaires installer. Ne cocher que “Utilitaires standards du système” (avec la touche espace) et valider (avec entrée).

Après reboot, on arrive sur une invite de connexion. On rentre le nom d’utilisateur et le mot de passe choisis précédemment pour se connecter.

Note  : Il faut que le PC dispose d’une connexion à Internet pendant l’installation car on a choisi un CD “netinstall”. L’idéal étant d’avoir une connexion ethernet.

Partitionnement

Finalement, sur un serveur personnel, il n’y a pas forcément besoin de beaucoup s’embêter avec tout le partitionnement, surtout qu’il n’y a bien souvent qu’un seul disque (ou deux, utilisés en RAID1 donc un seul volume en définitive). Un peu de swap (en fonction de la quantité de RAM dont vous disposez), et une seule grosse partition suffit pour le reste. On peut éventuellement séparer /home, pour le conserver en cas de réinstallation, ou /boot, obligatoire si les disques sont chiffrés, séparés. Si vous disposez de deux disques durs, un RAID1 est un gros plus pour être assez tranquille (voir notamment les liens sur mon shaarli pour ces configurations un peu plus avancées, si vous n’utilisez pas l’installation graphique). Les informations ci-dessous sont donc laissées à titre indicatif et historique :

Sur mon premier serveur, avec un disque de 60Go, j’avais adopté le schéma de partitionnement suivant (et j’avais déplacé tous les “gros” fichiers dans le dossier /home, dont la racine du serveur Apache).

Point de montage Taille Utilité
/ 512Mo Racine du système. C’est la base de l’arborescence du système. La création de partitions à côté permettent de ne pas lui attribuer une taille trop importante.
/boot 128Mo Contient les données relatives aux lanceurs de démarrage et aux en-têtes du noyau.
/usr 5Go Contiendra les données des applications (paramètres et certains binaires).
/tmp 1Go Contiendra les fichiers temporaires.
/var 7.5Go Contiendra des données variables, dont la racine du serveur Apache par défaut.
Swap 1Go Partition permettant de décharger un peu l’utilisation de la mémoire (équivalent au pagefile windows).
/home Le reste Contient les données personnelles des utilisateurs.

Sur mon serveur actuel, avec un disque de 500Go, je stocke également le plus possible dans le /home (dont la racine du serveur Apache, les backups etc.) et j’ai le schéma suivant :

Point de montage Taille Utilité
/boot 300Mo Contient les données relatives aux lanceurs de démarrage et aux en-têtes du noyau.
/ Tout le reste Racine du système.
Swap 2Go Partition permettant de décharger un peu l’utilisation de la mémoire (équivalent au pagefile windows).

Remarque : Personnellement, je stocke tout sur ma partition /home (y compris les données de site) pour réaliser plus facilement des sauvegardes.

Note : Chez OVH, si vous choisissez l’installation en un clic, vous aurez droit à une version custom de la dernière debian stable, modifiée par OVH. Je préfère personnellement garder la version de base et réaliser éventuellement des modifications moi-même. Il faut donc bien choisir la “distribution nue”. Même dans ce cas, il n’est pas possible de partitionner à sa guise. Pour cela, voir ce lien.

Note : Avec l’installation de base, votre serveur sera installé avec des partitions non-chiffrées. Personnellement, je préfère chiffrer mes partitions, au prix d’une légère baisse de performances, surtout sur un serveur qui ne m’appartient pas. Ainsi, pas de problèmes une fois le serveur rendu, je sais que toutes mes clés SSH / SSL etc. ne pourront pas être récupérées. Je ne détaillerai pas cette procédure ici, mais voici un certain nombre de liens utiles et de remarques.

  • http://blog.tincho.org/posts/Setting_up_my_server:_re-installing_on_an_encripted_LVM/
  • Chez OVH, j’ai eu des soucis avec les modules nécessaires pour le chiffrement qui n’étaient pas disponibles en mode “rescue”. J’ai donc dû éditer manuellement le fichier cryptroot de l’initrd pour le premier boot (mais après le premier boot, tout fonctionne normalement :). EDIT : Ça semble résolu avec les dernières images, je n’ai pas eu de problèmes sur un kimsufi édition 2013. Par contre, j’ai eu deux / trois autres problèmes, voir ici.
  • Les docs usuelles sur dm-crypt etc., notamment la doc d’Arch Linux sur la question (à adapter pour Debian, notamment au niveau du montage des partitions, mais elle est très bien faite).

Connexion à distance au serveur : SSH

Il faut pouvoir administrer le serveur à distance. Pour cela, on va installer de quoi se connecter à distance (SSH), et on n’utilisera plus le clavier physique du serveur qu’en cas d’urgence, lorsque la connexion SSH tombera (ce qui ne devrait pas arriver).

Pour installer SSH, on installe le paquet openssh-server. Comme toujours, il y a l’excellente doc de ubuntu-fr.org pour l’installation et les grandes lignes de la configuration.

Il va ensuite falloir configurer SSH en détails (pour protéger un minimum le serveur) et installer de quoi se connecter sur le serveur.

Configuration

Le fichier de configuration est /etc/ssh/sshd_config. On va modifier quelques valeurs.

Paramètre Valeur à fixer (exemple) Commentaire
Port N’importe lequel. Par exemple 3134. Changer le port par défaut pour plus de sécurité. Cela permet d’éviter de subir les tentatives répétées des scanners de port. Attention, si vous changez le port, il faut en prendre un qui ne sera pas utilisée par une autre application. De plus, si vous vous connectez souvent depuis des réseaux que vous ne contrôlez pas, il est très fréquent que de nombreux ports soient bloqués. Pensez-y avant de changer le port !
Protocol 2 Interdit l’utilisation du protocole SSH v1 pour plus de sécurité.
PermitRootLogin no Interdit le login via root (il faudra se connecter puis faire su root) par mesure de sécurité. Si quelqu’un venait à récupérer votre moyen d’authentification et que vous vous loggiez en root, il aurait directement un accès root sur votre serveur ! En faisant comme ça, il n’aura qu’un accès user (tant qu’il n’a pas le mot de passe root).
X11Forwarding no Pour faire de l’affichage graphique déporté, inutile pour nous puisqu’on gère notre serveur en console.
MaxStartups 10:30:60 Décommenter la ligne (enlever le #) Après 10 connexions échouées, il y a 30% de chances pour qu’une connexion suivante soit bloquée. Ce pourcentage augmente jusqu’à 100% linéairement (100% atteint pour 60 connexions).
Banner /etc/issue.net Décommenter (Optionnel) Afficher un message d’accueil (éditer /etc/issue.net pour le modifier).
AllowUsers (ligne à ajouter) Nom de votre compte (Alice) Nom des comptes autorisés à se connecter en ssh. Vous seuls serez autorisés à vous connecter.
ClientAliveInterval 300 Idle timeout en secondes (300s = 5min).
ClientAliveCountMax 0 Avec la ligne précédente, déconnecte après 5min d’inactivité.
IgnoreRhosts yes Désactive un accès peu sécurisé
HostbasedAuthentication no idem
PermitEmptyPasswords no idem, interdit les mots de passe vides.

Si vous ne suivez pas la partie suivante, vous pouvez vous connecter à votre serveur en lançant ssh -p le_port_choisi utilisateur@adresse_ip_de_votre_serveur sur Linux ou en utilisant Putty et en remplissant correctement les champs sur Windows. Pour obtenir l’adresse IP de votre serveur, s’il est sur votre réseau local, il suffit de taper ifconfig sur votre serveur. Si votre serveur a directement une adresse IP publique, vous pouvez lancer wget -q -O - dynip.phyks.me pour afficher votre adresse IP. Le mot de passe à fournir est celui de votre compte utilisateur sur le serveur.

Note : Pour la commande ssh, l’argument pour spécifier le port est -p tandis que pour scp, c’est -P (en majuscule).

(Optionnel) Connexion via clé publique / privée au lieu d’un mot de passe

Avec SSH, il est possible de se connecter avec un jeu de clé publique / clé privée, ce qui renforce la sécurité. Mais il y a quand même un inconvénient majeur : il vous faudra vos clés pour vous connecter sur votre serveur, ce qui peut empêcher de réparer rapidement un problème : on connait tout le temps son mot de passe mais la clé SSH est un fichier qu’il faut avoir sur soi. Utiliser l’authentification par clé évite en revanche de devoir taper un mot de passe à chaque connexion. Personnellement, j’utilise les deux modes d’authentification : par clé la plupart du temps, et par mot de passe quand je n’ai pas le choix.

Note : Ne pas désactiver l’authentification par mot de passe avant d’avoir généré votre clé SSH et avant de l’avoir testée, si vous n’avez pas d’accès physique à la machine. Vous n’auriez alors plus aucun accès possible sur la machine et devriez trouver un moyen de réaliser la maintenance.

Si vous souhaitez mettre en place l’authentification par clé publique/privée, modifiez le fichier /etc/ssh/sshd_config comme suit :

Paramètre Valeur à fixer (exemple) Commentaire
PubkeyAuthentication yes Activer l’authentification par clé.
PasswordAuthentication no Authentification par clé uniquement (désactive l’authentification par mot de passe, si vous le souhaitez).
UsePAM no Pour ne plus avoir à saisir de mot de passe. Laisser à yes si vous souhaitez conserver l’authentification par mot de passe.

Génération des clés et connexion

Pour cela, si vous n’avez pas encore de clés ssh, lancer sur votre machine la commande ssh-keygen -t rsa -b 2048 -C COMMENT qui va générer une clé chiffrée en RSA2048 avec un commentaire COMMENT permettant de l’identifier (-C COMMENT est optionnel et, s’il n’est pas spécifié, le commentaire inséré automatiquement sera user@machine). Une phrase de passe vous sera demandée, la choisir assez forte pour bien protéger la clé (vous devrez vous en souvenir, sinon la clé sera inutilisable, mais vous pourrez déverouiller automatiquement la clé à la connexion, avec le gestionnaire de trousseaux de Gnome, vous évitant de devoir la saisir à chaque connexion).

On obtient deux fichiers id_rsa et id_rsa.pub, stockés dans /home/utilisateur/.ssh. Le fichier id_rsa est votre clé *privée* à garder secrète, le fichier id_rsa.pub est la clé publique, à donner au serveur. Pour cela, vous pouvez utiliser la commande ssh-copy-id (si vous avez conservé la connexion par mot de passe). Sinon, vous pouvez également procéder manuellement en mettant le contenu du fichier id_rsa.pub sur une seule ligne dans le fichier ~/.ssh/authorized_keys de l’utilisateur avec lequel vous souhaitez vous connecter sur le serveur.

Remarque : Deux approches différentes sont envisageables vis-à-vis de la gestion des clés SSH. Pour certains utilisateurs, une clé == une personne, et dans ce cas, vous avez juste à transmettre les fichiers id_rsa *et* id_rsa.pub à chacune des machines avec lesquelles vous souhaitez vous connecter. Ceci dit, si vous avez un ordinateur portable, il présente des risques de se faire voler, et il peut donc être plus simple de ne révoquer l’accès qu’à sa clé ssh, en cas de vol (plutôt que de devoir redistribuer les clés SSH à toutes vos machines). À vous de voir.

Pour plus d’informations sur la connexion (en particulier sur les postes Windows en utilisant PuTTy qui a un fonctionnement un peu particulier), de bonnes explications peuvent-être trouvées dans le wiki de Fedora. Vous pouvez aussi lire la doc des tuteurs de l’Ens sur le sujet.

Configuration du pare-feu

À partir de maintenant, toute la configuration peut se faire via SSH. De nombreuses étapes de configuration étant à faire en root, il est plus simple de se connecter en SSH sur le serveur puis de faire “su” pour passer en root.

On va maintenant activer et configurer le pare-feu du noyau (iptables) pour protéger notre serveur. Pour vérifier qu’iptables est bien disponible, taper iptables -L qui va lister toutes les règles disponibles. Comme toujours, une bonne source de documentation est la doc d’ubuntu-fr.org.

On va créer un script qui se lancera à chaque démarrage et définira les règles du pare-feu (iptables étant remis à zéro à chaque démarrage du serveur) :

Note : nano est un éditeur de texte basique en ligne de commande. Il est simple à prendre en main et intuitif. Vous pouvez également utiliser vim, emacs ou autre, à votre convenance.

  • nano /etc/init.d/firewall
  • Un exemple de règles commentées, pour une utilisation basique est disponible ici. Libre à vous de réaliser un script à votre convenance.
  • On le rend exécutable : chmod +x /etc/init.d/firewall
  • On l’exécute à chaque démarrage : update-rc.d firewall defaults

Attention, si vous configurez mal ces règles, vous risquez de ne plus pouvoir vous connecter en SSH à la machine. Ce n’est pas très grave si vous avez un accès physique au serveur, mais si vous êtes à distance, vous risquez de devoir passer en mode maintenance pour débugger cela. Une précaution minimale est d’avoir une session root en SSH ouverte, et de ne *pas* la fermer avant d’avoir testé que les règles fonctionnent.

On a ainsi défini une politique assez restrictive pour le pare-feu. Par défaut, tout est bloqué en INPUT, OUTPUT et FORWARD. On autorise les connexions déjà existantes et on traite les nouvelles connexions au cas par cas. Quelques limitations et protection basiques sont également ajoutées. Il est bien que vous compreniez les règles que vous entrez. Lisez donc bien la documentation d’iptables et la doc qu’on trouve à droite à gauche pour voir ce que fait chaque règle, avant de l’insérer dans votre fichier de configuration. En règle générale, quand on administre un serveur, il vaut mieux éviter de recopier bêtement des bouts de configuration à droite à gauche (ce qui en général conduit à de mauvaises configurations et des trous de sécurité béants) et comprendre un peu ce qu’on fait.

À ce moment, c’est une bonne idée de redémarrer le serveur pour vérifier qu’il n’y a aucun problème avec la configuration précédente. En particulier pour vérifier que vous pouvez encore vous connecter en SSH au serveur. Si ce n’est pas le cas, rebrancher un écran et un clavier sur le serveur et éditer les règles jusqu’à ce que ça marche (ou le redémarrer en mode rescue) :)

Remarque : On peut aussi l’exécuter directement depuis la console via sh /etc/init.d/firewall en cas de besoin.

Note : Pour vider votre configuration iptables, il faut rentrer iptables -F; iptables -X puis remettre les politiques par défaut par protocoles comme vous le souhaitez (par exemple iptables -P INPUT ACCEPT).

Installation de logiciels de sécurisation supplémentaires

Installation de fail2ban

Fail2ban permet de bannir automatiquement de votre serveur des adresses IP qui échoueraient un trop grand nombre de fois à une authentification et de vous avertir par e-mail.

Installer le paquet fail2ban pour l’installer. Pour modifier la configuration, il faut modifier les fichiers /etc/default/fail2ban, /etc/fail2ban/fail2ban.conf, /etc/fail2ban/jail.conf et /etc/fail2ban/jail.local. Ce dernier fichier est celui qui va nous intéresser (c’est en fait le même que jail.conf mais il est prévu pour être modifié et donc pour conserver les réglages après une mise à jour du paquet).

Configuration (fichier jail.local) :

Paramètre Commentaire
ignoreip Laisser 127.0.0.1 pour que fail2ban ne bloque jamais votre propre serveur.
bantime Définit la durée du ban, 600 est une bonne valeur.
maxretry Nombre d’échecs avant bannissement, 3 est bien aussi.
destemail Mettre ici l’adresse e-mail à laquelle vous souhaitez recevoir des rapports de fail2ban.

Voila pour la configuration générale. Il faut ensuite modifier les ports (si on les a modifié manuellement pour SSH par exemple) pour les faire correspondre aux ports réels, dans la section jails. Par exemple, si votre connexion SSH se fait sur le port 3134 et non sur le port 22, il faut mettre 3134 à la place de 22 dans la section jails. N’oubliez pas de passer enabled à true pour les jails que vous souhaitez activer (sûrement ssh, ssh-ddos, apache, apache-noscript, apache-overflows pour commencer). Noter qu’il existe énormément de règles pré-définies, certaines pourront vous être utiles par la suite (postfix/sasl par exemple si vous installez un serveur de mails sur votre serveur).

On peut également rajouter des règles comme la règle apache-w00tw00t pour bloquer les requêtes w00tw00t. Voir ici.

On trouvera plus d’informations sur la configuration de fail2ban sur le wiki debian-fr

Vous pourrez alors tester fail2ban en entrant volontairement un mauvais mot de passe sur une page protégée par un fichier .htaccess (après avoir installé apache) ou sur une connexion SSH. Normalement, vous devriez être banni. Soit vous attendez la fin du bantime, soit vous avez un autre accès à la machine et dans ce cas, vous pouvez supprimer la règle iptables qui vous interdit l’accès au serveur (fail2ban bloque en utilisant iptables). Une solution est d’avoir une session SSH ouverte en arrière-plan pour pouvoir se débannir facilement.

Note (peut-être dépassée lorsque vous lirez ceci) : il semble qu’il y ait un problème dans une regex de fail2ban pour identifier les erreurs de connexion avec postfix. Voir ce sujet sur debian-fr.org pour plus de détails et pour corriger la regex.

Liens divers :

Installation de portsentry

Portsentry est un programme de détection et de blocage de “scans de ports”.

On commence par installer le paquet portsentry. La configuration se fait dans les fichiers /etc/portsentry/portsentry.conf et /etc/default/portsentry.

Dans le fichier /etc/default/portsentry, fixer les valeurs de TCP_MODE à atcp et de UDP_MODE à audp.

Dans le fichier /etc/portsentry/portsentry.conf, mettre BLOCK_UDP à 1, BLOCK_TCP à 1 également (pour activer la protection). Décommenter la ligne KILL_ROUTE pour les nouvelles versions de Linux (avec le flag reject : /sbin/route add -host $TARGET$ reject) ainsi que la ligne KILL_HOSTS_DENY=”ALL: $TARGET$ : DENY”. Inutile de spécifier un PORT_BANNER, ce n’est pas la peine de provoquer celui qui tente une intrusion. Décommenter également (ou rajouter) la ligne 

KILL_RUN_CMD="/sbin/iptables -I INPUT -s $TARGET$ -j DROP && /sbin/iptables -I INPUT -s $TARGET$ -m limit --limit 3/minute --limit-burst 5 -j LOG --log-level debug --log-prefix 'Portsentry: dropping: '"

Portsentry est maintenant configuré et fonctionnel. Vous pouvez le tester en lançant un scan nmap sur votre serveur depuis un autre poste. Attention, avant de le lancer, il faudra pouvoir vous débloquer en supprimant les entrées vous concernant dans le fichier /etc/hosts.deny, dans route et dans iptables, sinon vous n’aurez plus d’accès au serveur. Soit vous avez une autre adresse IP disponible pour récupérer l’accès au serveur, soit il faut encore une fois laisser tourner une session SSH en root en arrière-plan.

Pour plus d’informations sur la configuration (notamment comment exclure certaines adresses IP pour autoriser des scans légitimes, voir la doc de debian-fr (qui détaille également la procédure de test).

Installation de rkhunter

Rkhunter est utile pour détecter l’installation de rootkits, en comparant les checksums de binaires essentiels du système, notamment.

Il faut installer le paquet rkhunter puis éditer le fichier /etc/default/rkhunter pour la configuration. Il faut notamment éditer CRON_DAILY_RUN et le mettre à yes pour effectuer un scan quotidien et REPORT_EMAIL pour spécifier l’adresse email à laquelle on souhaite recevoir les avertissements. Il faut également appeler rkhunter après chaque installation de logiciels pour qu’il remette à jour sa base de données et éviter ainsi des faux positifs. Pour installer et configurer rkhunter, se référer à cette page du wiki debian-fr.org

Installation de logwatch

Un guide complet pour l’installation et la configuration est disponible sur le wiki debian-fr.

On trouvera des informations complémentaires sur toute cette partie (logwatch, rkhunter, fail2ban et portsentry) ici. Il est possible d’installer beaucoup plus de logiciels pour protéger son serveur (snort par exemple, pour détecter des intrusions) mais cela consommera autant de ressources en plus et n’apportera pas beaucoup plus pour notre serveur personnel.

Quelques astuces avant d’installer les services (linux, rien à voir en particulier avec l’autohébergement)

Utiliser des alias pour les commandes qu’on lancera souvent

On peut définir des alias dans le fichier ~/.bashrc (pour l’utilisateur courant seulement) ou /etc/bash.bashrc (pour tous les utilisateurs).

Un alias se définit par la ligne alias ALIAS=”commande” à rajouter dans ce fichier. Par exemple, on peut définir un alias pour mettre à jour le serveur : alias update=”aptitude update && aptitude upgrade” ou pour lister tous les fichiers d’un dossier facilement alias ll=”ls -alh.

Plus généralement, il est toujours bon d’avoir un shell bien configuré aux petits oignons (bashrc, zshrc etc.) pour être plus efficace.

Completion intelligente dans le shell

On peut activer facilement l’auto-completion intelligente dans la console qui, une fois qu’on l’a essayée, devient vite essentielle. Pour cela, rien de plus simple, il suffit d’éditer le fichier /etc/bash.bashrc et décommenter les lignes correspondant à l’auto-completion (cf. commentaires de ce fichier).

Il est également possible d’afficher les suggestions lorsqu’il y a plusieurs possibilités. Pour ce faire, il faut rajouter dans le fichier /etc/inputrc, set show-all-if-ambiguous on en-dehors des conditions (if).

Réglage automatique de l’heure avec NTP

Pour régler automatiquement l’heure de notre serveur, et le garder synchronisé avec un temps de référence, on peut utiliser NTP. Pour cela, rien de plus simple, il suffit d’installer NTP par un aptitude install ntp. La synchronisation se fera automatiquement par la suite (vérifiez juste que le service ntp est bien lancé).

(Putty) SSH en français

Si vous utilisez putty pour vous connecter en SSH, il ne transmet pas les variables de locales qui permettent d’avoir un environnement en français. Ainsi, si vous vous connectez en SSH et lancez nano, il sera en anglais.

Pour passer SSH en français, connectez-vous avec Putty puis passer en root (su root). Lancez locale qui va vous donner vos paramètres de locales. Notez le contenu des variables. Il ne reste plus qu’à ouvrir la configuration de Putty et à rentrer ces variables dans l’onglet Data.

Ok, mon serveur est installé, mais comment j’y accède ?

Le système de base est installé. Il faut maintenant pouvoir accéder aux services depuis l’extérieur. Je vais maintenant présenter la méthode générique pour accéder à son serveur depuis l’extérieur. Certaines parties seront à appliquer à chaque service.

Tout d’abord, si vous avez votre serveur chez vous, derrière une box, celle-ci bloque par défaut tout le trafic entrant. Il faut donc rediriger les ports que l’on va utiliser sur notre serveur (port pour SSH, port 80/443 pour Apache, …) vers notre serveur. Il faut donc donner une adresse ip locale fixe à notre serveur et rediriger correctement les ports. Une autre solution est de mettre le serveur en DMZ.

Mais ce n’est pas tout. Votre box a une adresse ip qui l’identifie sur Internet. Pour l’instant, vous pouvez vous connecter à votre serveur en utilisant cette adresse ip. Pas très pratique, surtout si vous avez une adresse IP dynamique, qui change de temps en temps.

L’idéal est d’avoir une adresse IP fixe (possible chez certains hébergeurs, dont Free). Sinon, il est possible d’utiliser un service tel que no-ip pour pouvoir vous connecter à votre serveur via une adresse du type cequevousvoulez.noip.com. Certaines box peuvent mettre à jour elles-mêmes l’adresse IP envoyée à no-ip, sinon il faudra que le serveur s’en charge. Vous pouvez désormais remplacer l’adresse IP du serveur par cequevousvoulez.noip.com dans les commandes précédentes.

Si votre serveur est chez un hébergeur pro (OVH, Gandi, 1&1, etc.), il aura directement une adresse IP fixe attribuée, que vous pourrez trouver dans l’interface d’administration.

Pour accéder à votre serveur avec une adresse textuelle plutôt qu’une adresse IP, il vous faut un nom de domaine. Certains sont gratuits (les .tk notamment, mais étant très utilisés par les spammeurs, vous ne pourrez pas avoir de certificats SSL signés par une autorité avec un tel nom de domaine par exemple). Une autre possibilité est d’acheter un nom de domaine (en .fr, .eu etc par exemple). Il vous en coûtera entre 5 et 10€ par an (et vous aurez en général des adresses e-mail en @votredomaine.tld associées etc.). OVH en propose avec gestion des dynhosts pour pouvoir les utiliser avec une adresse ip dynamique, ce qui vous permettra de vous affranchir de no-ip.

Maintenant que vous avez un nom de domaine (ou une adresse chez no-ip), vous ne pouvez pas vous connecter depuis votre réseau local vers votre serveur avec cette adresse. Ce n’est pas pratique… il faudrait utiliser deux adresses différentes, selon qu’on est chez soi ou à l’extérieur. Cela est dû au fait que, quand la box reçoit la requête vers le serveur, elle se connecte en quelque sorte chez elle-même (car c’est son adresse IP qui est indiquée par le nom de domaine) et ne sait pas à quel PC transférer la requête. Il faut alors lui dire que ce nom de domaine correspond à un ordinateur sur le réseau local. Certaines box permettent de modifier les DNS sur le réseau local pour pouvoir accéder depuis n’importe où à votre serveur avec une seule adresse.

Si vous avez un nom de domaine, les interfaces d’administration permettent de faire beaucoup de choses directement graphiquement. Pour s’y retrouver dans les différents types de champs, voici un petit guide.

À partir de maintenant, je suppose que votre serveur est accessible de l’extérieur, et que vous pouvez vous connectez (en SSH par exemple) dessus.

Installation des services souhaités

Installation d’un serveur LAMP

Installation des paquets

On va commencer par installer le serveur web Apache (qui fait tourner la majorité des sites webs que vous visitez !) et php. Pour ce faire, installer apache2 apache2-utils php5 php5-dev php5-gd et valider la résolution des dépendances. Vous pouvez également utiliser un serveur web plus léger si votre serveur n’est pas très puissant. On peut notamment citer Nginx et Lighttpd, mais je ne détaillerai pas leur utilisation ici.

On va installer ensuite MariaDB (fork open-source de MySQL depuis le rachat par Oracle, vous pouvez effectuer les mêmes actions en installant mysql si vous préférez). Ce site vous permet de générer les entrées à ajouter dans votre sources.list pour ajouter le dépôt contenant mariadb. Bien choisir sa version de Debian (on a installé une debian stable). Il contient également des instructions d’installation. Pour plus d’informations sur le fork MariaDB, je vous renvoie à cet article du framablog.

On installe ensuite le paquet mariadb-server. S’il le demande, définir un mot de passe root pour MariaDB assez fort, c’est sur lui que reposera la sécurité de la connexion à notre base de données. Puis on installe de quoi le faire communiquer avec PHP grâce au paquet php-mysql et PHPMyAdmin (grâce au paquet du même nom) pour avoir une interface web d’administration.

Note : en installant phpmyadmin depuis les dépôts, vous n’aurez sûrement pas la dernière version. Mais vous aurez une version stable, sûre, testée et éprouvée par les développeurs Debian, et surtout directement fonctionnelle ! L’ancienneté des paquets peut être gênante sur des scripts évoluant rapidement (owncloud par exemple), mais pour l’utilisation que nous ferons de phpmyadmin, cette version est largement suffisante. Vous êtes bien sûr toujours libre d’installer la dernière version, mais alors ça sera à vous de surveiller les évolutions du script et en particulier les éventuelles failles de sécurité détectées, et non à l’équipe sécurité de Debian.

Tous les éléments nécessaires à notre serveur sont ainsi installés. On va maintenant modifier quelque peu la configuration.

Configuration d’Apache et de PHP

Éditer le fichier /etc/apache2/conf.d/security et mettre ServerTokens à Prod, ServerSignature et TraceEnable à off pour empêcher votre serveur Apache de donner trop d’informations sur lui. Pour plus d’informations sur la sécurisation d’un serveur Apache2, on peut aller voir dans la doc Ubuntu-fr.org. Vous pouvez également cacher la version de PHP utilisée dans les headers renvoyés, voir ici pour plus d’infos.

On va ensuite mettre en place des vhosts. Chaque vhost correspond à un sous-domaine. Pour plus d’informations, voir cette page par exemple.

Pour plus d’informations sur Apache, voir la doc Ubuntu-fr.org. Une autre page très complète, même si personnellement je n’aime pas sa méthode de mise en place de la configuration.

Note : Apache sert d’abord le virtual host _default_:80, et sert les virtual host par ordre alphabétique pour les mêmes niveaux de priorité.

Quelques modifications à effectuer dans PHP pour le sécuriser un peu plus. Attention : certaines fonctions à désactiver en général car peu utilisées sont néanmoins nécessaires pour utiliser Owncloud, que nous verrons apparaître un peu plus bas (notamment les fonctions qui agissent sur le système de fichiers pour avoir l’espace libre etc. qui sert pour les quotas d’Owncloud). Il est également probable que vous ayez Suhosin d’installé avec PHP. On peut trouver ici un exemple d’utilisation de Suhosin pour gérer les fonctions PHP interdites par domaine.

Les logs d’Apache sont personnalisés pour chaque vhost avec la configuration précédente. Plus d’informations ici par exemple.

Toute la configuration d’Apache et de PHP se fait dans les dossiers /etc/apache2 et /etc/php5.

Configuration de MariaDB

Lancer mysql_secure_installation pour sécuriser un peu mieux MariaDB (il suffit de répondre aux questions). Les commandes s’appellent toujours MySQL pour des raisons de compatibilité, mais c’est bien MariaDB qui est utilisé.

Test du serveur web/mariadb

On va lancer apache et mariadb via les commandes

service apache2 start
service mysql start

Vous pouvez maintenant rentrer l’adresse http://serveur dans votre navigateur et une page blanche avec “It works !” écrit en gros devrait s’afficher dans votre navigateur. Si ce n’est pas le cas, vous avez un problème de configuration.

Vous devriez également pouvoir vous connecter à phpmyadmin via http://serveur/phpmyadmin et en utilisant le login root et le mot de passe associé pour mariadb. Si ça ne marche pas, tentez de reconfigurer le paquet avec dpkg-reconfigure phpmyadmin.

Quelques services webs utiles

Je présente ci-dessous quelques services utiles que j’utilise ainsi que des alternatives éventuelles. La majorité des scripts webs s’installent de la même façon : un copier/coller des fichiers et éventuellement la création d’une base de données, si nécessaire. Rien de très compliqué là-dedans.

Si le script nécessite un accès à une base de données, mieux vaut lui créer un utilisateur restreint, ayant tous les droits sur sa base de données, mais uniquement sur celles-ci. De mêmes, faites attention aux permissions sur les fichiers que vous servez. Idéalement, l’utilisateur de votre serveur web (www-data sur Debian) ne devrait pouvoir modifier que les fichiers dont il a besoin (tous les dossiers de data des divers scripts). En cas de faille dans un script, vous limiterez les risques.

Un agrégateur de flux RSS

Commençons doucement par les flux RSS. Ces flux vous permettent de suivre les news (ou n’importe quel contenu, à partir du moment que le site publie un flux RSS pour ce contenu) d’un site sans s’y rendre. Par exemple, sur le flux RSS de Sebsauvage, on retrouve les derniers articles publiés par Sebsauvage. On peut les lire directement depuis un logiciel (Thunderbird par exemple) ou utiliser une interface en ligne pour les lire (feu Google Reader est sûrement une des plus connues). De nombreux sites en proposent, même si ces flux ont tendance à être de plus en plus cachés au profit d’un bouton nous suivre sur Facebook ou sur Twitter.

Leed est une interface permettant de lire ces flux en ligne sur son propre serveur, et de les marquer comme lus / non-lus. Il n’y a plus de démonstration fonctionnelle en ligne, mais vous pouvez voir une démonstration avec le thème Greeder ici (thème qui est nettement plus attrayant que l’original, et je ne dis pas ça parce que j’y contribue :).

Pour l’installer, il suffit de télécharger l’archive de la dernière version depuis le site d’idleman. Il faut ensuite l’extraire dans le répertoire racine de son serveur web (via la commande unzip par exemple) puis donner les droits corrects sur le répertoire (droits en lecture et écriture à l’utilisateur www-data:www-data). On peut ensuite ouvrir la page install.php depuis son navigateur et procéder à l’installation. Ne pas oublier de supprimer l’archive zip (on n’en a plus besoin une fois décompressée) ainsi que le fichier install.php par mesure de sécurité. Une alternative est de cloner le dépôt Git, afin de pouvoir le mettre à jour très facilement.

Cependant, comme écrit dans un article récent, le développement de Leed est beaucoup moins actif récemment, et j’aurais tendance à lui préférer FreshRSS qui est nettement plus dynamique et performant actuellement (et qui devrait continuer sur cette voie).

Alternatives : Tiny Tiny RSS, plus proche de feu Google Reader et avec plus de fonctionnalités mais plus lourd également. On peut aussi citer KrISS Feed. Pour une liste plus complète, voir ici.

Shaarli de Sebsauvage : l’alternative à del.icio.us rapide et libre (agrégation de marques-pages et plus)

Peut-être connaissez-vous del.icio.us ? Un service centralisé pour stocker et partager ses marque-pages. Shaarli propose de réaliser exactement la même chose (et bien plus !) sur votre propre serveur. Pour une démonstration de ce que ça peut donner, rien de tel que les liens en vrac de sebsauvage (13538 liens au moment où j’écris ces lignes) :)

Pour l’installer, comme pour Leed, rien de plus simple. On télécharge l’archive du projet sur la page du projet. Et on la décompresse dans notre répertoire racine d’Apache. Pas besoin de base de données pour ce script super léger !

Plus d’informations sur la page du projet

Wordpress : le moteur de blog

Wordpress est un moteur de blog à installer sur votre serveur. L’installation, très classique, est largement commentée, en plusieurs langues, sur le net ; je ne la détaillerai donc pas ici.

Alternatives : Blogotext, qui mise sur la simplicité, la rapidité et la centralisation de quelques services (ne pas se fier au thème moins glamour que Wordpress, il est bien plus léger et tout aussi fonctionnel. Il faut juste bidouiller un peu pour se faire son thème, là où il y a d’innombrables thèmes pour Wordpress sur le web). On peut également citer Drupal qui permet également de faire un blog, mais qui est plus orienté CMS ou encore Dotclear.

À noter qu’il existe également des moteurs de blogs statiques, afin de servir des fichiers html statiques plutôt que de générer les pages à chaque fois. Il existe notamment ma solution maison, à base de dépôt Git (Blogit qui fait tourner mon blog mais qui doit être trop mal codée pour être réutilisée par quiconque… :/) mais surtout Jekyll qui a de bons retours (utilisé pour les pages Github notamment) ou encore Pelican en Python, ou Fugitive tout en bash.

Owncloud : l’alternative libre à dropbox (et bien plus)

Owncloud est une alternative libre à Dropbox. Ce script vous permettra de synchroniser des fichiers avec votre serveur, de faire des partages (publics/privés etc) et de gérer vos calendriers, vos contacts et bien plus encore (OwnCloud intègre nativement un serveur AmPache pour écouter de la musique directement depuis votre serveur par exemple). Il propose donc bien plus qu’une alternative à Dropbox (ce serait plutôt une alternative à un mix de Dropbox et des services Google). Owncloud est en développement intensif et de nombreuses fonctionnalités sont ajoutées à chaque nouvelle version. Une demonstration est disponible ici.

Installation

L’installation est bien documentée dans le wiki d’Owncloud. Il est possible de l’installer soit manuellement soit en ajoutant un dépôt de paquet dans le sources.list (suivre au choix les instructions “manual installation” ou “Ubuntu/Debian”).

Installation d’extensions

Il est possible d’ajouter de nombreuses fonctionnalités à Owncloud grâce à des extensions. Pour cela, il suffit de regarder dans le menu configuration/applications ou de visiter le site http://apps.owncloud.com/.

Une astuce en passant : il est possible d’installer le module php-apc (pour cela, rien de tel que l’excellente doc d’Ubuntu-fr.org) pour accélérer sensiblement le chargement despages d’Owncloud. Ce module s’occupe tout seul de repérer les pages php les plus demandées et de les mettre en cache pour les fournir plus rapidement. C’est particulièrement efficace sur un PC peu puissant (type Raspberry Pi).

Firefox Sync avec Owncloud

Cette partie est obsolète depuis la version 29 de Firefox qui est arrivée avec un nouveau serveur de synchronisation. L’application doit être mise à jour en conséquence, à suivre…

Il existe une extension pour Owncloud qui rajoute le support de Firefox Sync, pour synchroniser ses marque-pages, préférences, onglets ouverts et modules entre ses ordinateurs. Elle marche plutôt bien et est bien plus facile à installer que le serveur Mozilla Sync que j’utilisais avant. Seul regret, tout comme le serveur Mozilla Sync, elle ne fournit aucune interface pour voir les éléments synchronisés. Une intégration avec les marque-pages d’Owncloud aurait été cool par exemple.

Pour l’installer, il suffit d’activer l’extension, puis d’aller dans l’onglet “Personnel” pour trouver les réglages à insérer dans Firefox.

Par contre, comme documenté ici (et dans les liens liés), Android ne supporte pas le SNI, qui permet d’assigner un certificat SSL différent par vhost. Le plus simple est donc de mettre Firefox Sync sur un port différent, pour pouvoir l’utiliser avec SSL sur Android.

Monter directement Owncloud sur ses appareils
Sous Windows

Sous Windows, le plus simple est d’utiliser le client OwnCloud pour les fichiers. Pour les contacts et les calendriers, on peut utiliser Mozilla Thunderbird et suivre les instructions de la section Linux ci-dessous. Sous Outlook, il est possible de synchroniser ses calendriers et ses contacts moyennant l’utilisation de logiciels tiers pour rajouter ces fonctionnalités à Outlook. On peut également monter directement ses fichiers Owncloud dans Windows, moyennant quelques bidouilles.

Sous Linux

Sous Linux, il est très simple de monter son serveur Owncloud pour lire des fichiers. Celui-ci peut se monter directement dans Nautilus, ou en tant que système de fichiers moyennant l’installation de davfs2. Sinon, il est possible d’utiliser le client officiel pour Linux.

Pour les calendriers et les contacts, Evolution le gère en natif. Pour thunderbird, il faut installer l’extension agenda (Lightning), ainsi que l’extension Inverse SOGo Connector qui permet de synchroniser facilement des serveurs carddav (de contacts) en choisissant d’ajouter un nouvel agenda, sur le réseau, de type Caldav et idem avec les contacts. La synchronisation fonctionne très bien ensuite.

À noter que, sous Thunderbird, il est possible d’installer également “WebDAV for FileLink” qui propose d’envoyer les fichiers lourds en pièce jointe directement sur son serveur Owncloud et d’envoyer le lien par e-mail (tandis que par défaut, Thunderbird propose seulement d’utiliser une plateforme centralisée type Dropbox).

Petit bonus pour ceux qui tournent sous Linux (et Gnome ?) : il y a l’excellent logiciel Tomboy pour prendre des notes qui propose nativement une synchronisation des notes sur un serveur webdav. On garde ainsi ses notes à portée de main sur son instance Owncloud (les notes sont envoyées sous forme de fichiers xml stockés sur le serveur). Je n’ai personnellement pas réussi à faire fonctionner cette synchronisation sous tomboy mais son successeur (en fait, un clone de tomboy développé en C et non en Mono, et qui se paye le luxe d’être plus rapide) Gnote fonctionne à merveille.

Sous iOs

Sous iOs, les contacts et les calendriers peuvent se synchroniser nativement avec un serveur carddav ou caldav (après quelques batailles… si ça ne marche pas, essayez d’utiliser un mot de passe uniquement alphanumérique, sans caractères spéciaux).

Pour les fichiers, il y a l’application officielle Owncloud qui marche bien.

Sous Android

Sous Android, il est très facile de synchroniser ses calendriers, ses fichiers et ses contacts avec son serveur Owncloud.

Commençons par le plus simple : les fichiers. Il existe une application (officielle) Owncloud (qui à terme permettra de tout synchroniser) qui fonctionne très bien pour synchroniser des fichiers pour l’instant. Il suffit de l’installer depuis le Play Store (elle est aussi disponible sur F-Droid le store alternatif des applications libres). Elle permet de synchroniser des fichiers, de voir les fichiers sur son serveur Owncloud (et d’en télécharger) et d’envoyer automatiquement ses photos en ligne sur son Owncloud (comme le propose par ailleurs Facebook).

Pour les calendriers et les contacts, le plus simple est d’utiliser l’application DavDroid qui gère tout directement dans les applications d’origine et est libre.

Je cherche encore la meilleure solution pour synchroniser les “TODO” et les notes entre mon serveur et Android. Pour l’instant, j’utilise les applications d’aCal pour ça. Finalement, je gère mes TODO en les rentrant dans mon Shaarli avec le tag TODO et en privé (il est facile de customiser le bookmarklet pour gagner quelques secondes en mettant ces réglages par défaut :). Ainsi, je les ai partout, et avec les pull requests sur Github, qui seront peut-être intégrées prochainement (notamment l’API REST), on peut le faire communiquer avec un peu n’importe quoi.

Alternatives

Il existe un certain nombre d’alternatives à Owncloud, que ce soit des systèmes complets clé en main comme Owncloud ou des applications séparées.

  • Comme alternative globale, on peut citer CozyCloud
  • Pour ce qui est du stockage des fichiers, il existe DropCenter d’idleman (et bien d’autres, voir sur mon shaarli)
  • Pour ce qui est de la partie CalDAV/CardDAV, il existe Radicale

Single File PHP Gallery : Une galerie d’image qui tient en un seul fichier

Single File PHP Gallery vous propose de mettre en place une galerie d’image type Picasa grâce à un seul fichier. Pratique pour rapidement diffuser des photos à ses amis.

Note : je n’ai pas testé personnellement cette solution. Elle peut ne pas être particulièrement adaptée à un grand nombre de photos par exemple.

Une autre solution trouvée au détour du web est Bizou, une galerie en php qui respecte le principe KISS. Je l’ai utilisé à plusieurs reprises et elle est vraiment parfaite ! :) On peut aussi citer MiniGalNano très fonctionnelle et très jolie depuis son redesign par tmos.

Enfin, il faut signaler qu’Owncloud permet également de partager des albums photos, ce qui peut dépanner même si ce n’est pas forcément la solution la mieux adaptée pour faire du partage de photo rapidement et simplement (Owncloud ayant tendance à être un peu lourd).

Un wiki KISS avec WiKISS

“WiKISS est un wiki simple à utiliser et à déployer”, KISS-compliant. Son interface est quelque peu austère mais en s’amusant un peu avec, il est possible d’obtenir quelque chose de très sympa comme le montre la page “projet” d’Idleman (qui a d’ailleurs réalisé une version légèrement modifiée BlazeKiss)

Alternatives : DokuWiki, utilisé par Sebsauvage ou encore hackEns par exemple. DokuWiki est très complet et fonctionnel, si vous recherchez une solution fiable pour un gros wiki, je vous le recommande vivement.

Encore une fois, ces scripts sont classiques et il existe de la très bonne documentation sur Internet, à commencer par les README et les documentations officielles.

Roundcube / Squirrelmail : le webmail chez soi

Les meilleurs webmails que j’ai trouvés sont Roundcube et Squirrelmail. Squirrelmail est un peu austère mais très rapide et très puissant. Roundcube est un peu plus convivial. Des démos sont visibles sur les sites respectifs de ces projets. Une fois installés, vous pourrez centraliser tous vos comptes e-mails dans une seule interface.

Une fois installés, vous pourrez vous servir de ce webmail pour gérer les comptes hébergés sur votre serveur mais aussi d’autres comptes à divers endroits, notamment ceux liés à votre nom de domaine si vous en avez laissé la charge à votre hébergeur.

Un bon guide d’installation est disponible sur le blog d’idleman pour Roundcube. Pour squirrelmail, le processus est sensiblement identique. L’installation d’un webmail est également traitée sur cette page du wiki debian-fr (cf. installation d’un serveur mail plus bas, même si le webmail n’a pas besoin d’un serveur mail).

Une note pour Roundcube : Pour pouvoir se connecter à plusieurs comptes sur des serveurs différents, dans le fichier config/main.inc.php, modifier comme cela :

$rcmail_config['default_host'] = array(
    'Serveur 1'=>'Alias',
    'Serveur 2'=>'Alias'
    );

Quelques liens supplémentaires :

FluxBB, le moteur de forum libre

Pour héberger des forums sur son serveur, il est possible d’utiliser l’excellent FluxBB, léger et très personnalisable avec de nombreuses extensions. L’installation est très classique et très bien documentée et guidée (ici (lien en anglais) par exemple).

Se passer de Google Analytics grâce à Piwik

Piwik propose de réaliser des statistiques sur vos sites web, comme Google Analytics. La seule différence, mais non des moindres, étant qu’il tourne sur VOTRE serveur et que ce qui concerne vos sites peut donc rester chez vous.

Une démo est disponible ici.

L’installation est très simple, et très bien documentée sur le site officiel (disponible en français !). Une remarque quand même : lors du choix de la base de données, il faut remplacer 127.0.0.1 par localhost chez certaines personnes.

Pour utiliser un site avec Piwik, il suffit de rajouter un bout de code javascript sur chaque page. Il y a des plugins pour intégrer directement Piwik dans les principaux CMS (Wordpress, Joomla, Drupal etc) et il est possible de faire pleins de choses avec Piwik. Je vous laisse aller voir dans la doc pour plus d’infos.

Piwik est fourni avec un plugin pour vous aider à le sécuriser. Voir cette page pour plus d’infos. Pour les plus gros sites (plus de cent visites par jour), il est recommandé de désactiver l’analyse en temps réel pour générer des rapports toutes les heure ou toutes les 6 heures. Le chargement est alors plus rapide car Piwik ne fait que lire des données déjà traitées. Plus d’infos ici.

Alternatives : AWStats qui scrute les logs Apache et ne propose pas, comme Piwik, de temps réel et d’analyse des clics etc.

L’alternative aux réseaux sociaux, pour tout poster chez soi et diffuser après, Known

Known peut être un peu tout ce que vous voulez : un blog, un service de microblogging, un réseau social, etc. Il vous permet de tout poster chez vous, et de balancer ensuite automatiquement chez Facebook, Twitter etc. Pour plus de détails, voir ce billet

Services divers

Quelques services listés en vrac :

  • ZeroBin (stockage de notes avec chiffrement / déchiffrement dans le navigateur)
  • SnippetVamp (gestion de snippets)
  • BikeInParis (mon script pour remplacer les apps Vélib)
  • OranjeProxy (un webproxy, par lehollandaisvolant)
  • BouffeATUlm (mon script pour gérer les courses à plusieurs)
  • Pombo (pour retrouver un appareil volé)
  • shortURL (un raccourcissuer d’URLs maison, comme TinyURL)
  • Et bien d’autres que j’oublie (voir les liens en bas de page)

Utilisation de SSL avec son serveur Apache pour sécuriser les connexions

Pour l’instant, vous ne pouvez vous connecter à votre serveur web qu’à travers le port 80 (http) et non avec le port 443 (https). Si vous vous connectez à une interface web depuis un réseau wifi public (par exemple), vos identifiants étant transmis en clair, ils peuvent être récupérés. Il serait donc bien de pouvoir utiliser https.

Pour ce faire, il vous faut un certificat SSL. Ces machins-là coûtent les yeux de la tête chez la plupart des hébergeurs (plusieurs centaines d’euros) car ils doivent faire des vérifications manuelles de votre identité etc. Heureusement, certaines autorités de certification délivrent des certificats gratuitement, après une rapide vérification automatisée. L’inconvénient : ces certificats ne sont valables que sur un seul sous-domaine (il faudra en créer un par sous-domaine que vous voulez protéger) et ils ne sont pas reconnus par tous les navigateurs. Certains visiteurs auront des alertes de certificat SSL non vérifiable. Deux autorités proposent ces services : StartCom (qui est très bien reconnue) et CACert, une autorité de certification communautaire, qui commence à être reconnue par la plupart des navigateurs.

Note : Les noms de domaine en .tk étant gratuits, ils sont beaucoup utilisés pour du spam. Startcom ne propose donc pas de créer un certificat SSL pour un domaine en .tk.

Un bon guide pour l’installation d’un certificat SSL de StartCom (c’est la même chose pour CACert) est disponible ici (commencer directement à l’étape 6 - Création du compte chez StartSSL et s’arrêter avant l’étape 9 - Mise en place des certificats sur le DSM).

Une fois les fichiers récupérés (les fichiers .key décryptés et les fichiers .crt pour chaque sous-domaine), créez un dossier /etc/apache2/ssl et copiez dedans tous les fichiers (avec des noms explicites pour se rappeler qui correspond à quel vhost). Ces fichiers sont précieux, vous ne pourrez pas les refaire gratuitement tant qu’ils sont encore valables. Et vous devez gérer leurs droits d’accès (chmod) finement pour que n’importe qui ne puisse pas aller les consulter (chmod 400 pour root par exemple). Vous devrez ensuite allez éditer la configuration de votre vhost.

Les fichiers sub.class1.server.ca.pem et ca.pem sont mis à disposition par votre autorité de certification. Il faut donc les télécharger chez StartCom par exemple, si vous avez un certificat chez eux..

Note : Il peut éventuellement falloir modifier le fichier /etc/apache2/ports.conf si cela ne marche pas. Voir cette page au besoin. Pour pouvoir utiliser des certificats SSL différents pour chaque vhost, tous étant derrière la même adresse IP, il faut rajouter une ligne NameVirtualHost *:443 qui va activer le SNI (qui permet de sélectionner le certificat à envoyer en fonction d’un en-tête). Seul problème : cela ne marche pas avec Android (cf Firefox sync pour Android). Les utilisateurs du navigateur par défaut d’Android (pas de problèmes avec Firefox pour Android par contre) auront donc un message les avertissant que le certificat SSL ne correspond pas au nom de domaine, car ce sera le certificat du principal vhost qui sera distribué à chaque fois. Une solution pour contrer cela est de mettre une directive Listen sur un autre port et d’utiliser ce port.

Installation d’un serveur Jabber pour héberger sa propre messagerie instantanée

Jabber (XMPP), c’est une solution libre et décentralisée de messagerie instantanée (comme feu MSN…). Il existe de nombreux serveurs disponibles à faire tourner sur votre serveur, voir cette page pour une liste (non exhaustive). Je vous propose d’installer ejabberd, très puissant mais pas le plus simple à configurer. Pour ceux qui préfèrent, il existe Prosody qui peut s’installer en 5 minutes chrono, mais je n’ai jamais réussi à faire ce que je voulais avec Prosody…

Voici 3 liens à mixer pour avoir toutes les infos :

Il est facile d’obtenir un certificat SSL pour ejabberd chez StartCom. On évite ainsi d’avoir un certificat auto-signé et donc un message d’erreur sur la plupart des clients (certains clients ne reconnaissent pas StartCom comme une autorité de certification fiable). Pour plus d’informations, voir cette page.

Installation de Murmur (mumble-server) pour héberger son propre serveur Mumble

Mumble est une alternative libre et gratuite à TeamSpeak qui en plus se permet d’avoir de meilleurs performances et une meilleure qualité audio. Il est très simple d’installer un serveur Mumble. Pour plus d’infos, voir cette page ou celle-ci.

Note : même si le débit en upload est limité sur une ligne ADSL classique, un serveur Mumble fonctionne très bien sur une telle ligne pour un faible nombre d’utilisateurs. Je n’ai pas testé de conditions plus extrêmes.

Il est possible d’obtenir facilement un certificat SSL pour son serveur Mumble chez StartCom. Voir cette page pour plus d’informations.

Installation d’un serveur email

Un très bon guide est disponible sur le wiki debian-fr et (surtout) ici. Pour des compléments, il y a ce guide également (notamment pour l’utilisation d’un smtp externe tel que celui de son FAI ou de son hébergeur pour envoyer des emails, car si on a une adresse IP dynamique, on ne peut héberger de serveur SMTP sans être considéré comme un spammer).

Attention : Héberger son propre serveur email nécessite d’être sûr de sa connexion et de son PC. Si le serveur tombe, les emails ne seront pas récupérés (on peut néanmoins définir des serveurs secondaires pour réceptionner le courrier si le serveur principal tombe). De plus, héberger un serveur email avec une adresse IP dynamique n’est pas vraiment envisageable (pas de SMTP possible car considéré comme spammeur et risque de perte d’emails à chaque changement d’IP). De plus c’est un composant assez critique car un serveur email ouvert va très vite servir de relais de spam.

Note : l’utilisation d’amavisd “génère” deux fois plus de trafic email (dans les logs, il y a deux fois plus d’entrées, c’est tout). Donc logwatch compte deux fois trop d’emails dans ses rapports. Il y a moyen de changer cela, mais ce n’est pas hyper simple (ou alors je n’ai pas trouvé de méthodes simples). Sinon, il faut juste diviser par deux le nombre d’emails qui apparaissent dans logwatch.

Par défaut, Postfix ne logue pas les sujets des emails. Il est possible de modifier ce comportement, voir ici.

Quelques liens supplémentaires :

Héberger ses propres DNS

Héberger ses propres DNS permet de s’affranchir de ceux de son hébergeur / registrar. Mais c’est également un composant assez critique, un résolveur ouvert pouvant être utilisé pour mener des attaques DDOS etc. Je n’ai pas encore pris le temps de regarder cela pour moi, donc je le signale juste, sans informations complémentaires pour l’instant.

Note : Héberger ses propres DNS permet de faire quelques trucs sympas :)

Un serveur Git chez soi

Contrairement à SVN, Git est entièrement décentralisé. Chacun a donc une copie du dépôt, et c’est donc comme si chacun avait son petit serveur en local. Ainsi, il n’y a pas besoin d’une laison internet pour commiter (ce qui est bien pratique dans le train). Il y a bien évidemment de nombreuses autres différences entre les deux, mais ce n’est pas l’objet ici.

Pour mettre en place son serveur Git, le plus simple est d’installer Gitolite. Voici quelques liens :

Note : L’installation de cgit peut être assez compliquée, mais on finit en général par y arriver. À chaque fois que je l’ai mis en place, j’ai passé un peu de temps à le configurer :/, mais ça marche ! :)

Node.js

De plus en plus de scripts utilisent Node.js, en particulier les services proposant de l’édition collaborative et tout ce qui est à la mode aujourd’hui. L’installation de Node.js s’est grandement simplifiée récemment, et je fournis donc les quelques liens essentiels pour vous en sortir (sachant que si vous envisagez d’installer Node.js, vous devez déjà avoir une idée de ce que vous allez faire):

Partagez vos images avec Lutim

Peut-être utilisez-vous imageshack.us et autres imgur pour partager des images rapidement ? Il existe une alternative très pratique et parfaitement fonctionnelle, à mettre sur votre serveur et qui en plus chiffre les images : Lutim. Le projet est disponible sur Github.

Il est écrit en Perl, ce qui complique un poil l’installation. La procédure est entièrement décrite dans le README. À la fin de l’installation, Lutim sera accessible sur un port particulier (8080 par exemple), qu’il vous faudra ouvrir dans votre pare-feu. Si vous voulez le servir sur le port 80, il faudra utiliser Apache en reverse proxy.

Adieu Facebook, bonjour Diaspora

Diaspora* est un réseau social entièrement décentralisé (chacun peut faire tourner son instance, qui communique avec les autres), proche de Facebook ou de Google+. Après un début compliqué, le projet a eu une second jeunesse récemment, et de nombreuses personnes pratiquant l’auto-hébergement ont rejoint le réseau, sur l’impulsion de Cyrille Borne notamment.

L’installation en est d’autant plus facile (documentée, mais pas évidente pour autant du fait des technologies utilisées). Vous trouverez toute la documentation nécessaire sur le wiki du projet et dans cet article.

Un remplaçant pour Google Docs

On peut utiliser etherPad lite (démo visible chez Framasoft) pour les notes et ethercalc (démo sur le site) pour les tableurs. Tous deux sont incroyablement efficaces mais fonctionnent avec NodeJS ce qui demande un peu de configuration…

Alternatives :

  • Simple Spreadsheet qui a l’air très puissant et KISS mais très épuré également. Il est capable de gérer des graphes etc. mais nécessite d’apprendre des formules. Il n’est pas très beau mais gère l’import de fichier CSV (donc peut récupérer des données d’un tableur Excel, mais pas les formules).
  • Gelsheet très tape-à-l’oeil et assez complet mais je n’ai pas trouvé d’options pour importer des données depuis un tableur classique.

Mise en place d’une procédure de sauvegarde

Maintenant que vous vous autohébergez, vous êtes responsables de vos données. Il faut donc faire des sauvegardes régulières des données, mais aussi des fichiers de configuration pour pouvoir réinstaller en cas de besoin (ce qui ne devrait pas arriver, mais on ne sait jamais) sans perdre trop de temps.

Le plus simple, si vous avez 2 disques durs identiques (au moins de la même capacité, sinon vous perdrez de la capacité de stockage), c’est de mettre en place un RAID1.

Sinon, il faut utiliser un support de stockage (clé USB par exemple, qui est fiable, mais pas sur le long terme) et réaliser un petit script de backup. Regarder du côté des scripts bash, des cron jobs et des commandes cp (notamment l’option -a pour archiver) / rsync.

Il peut être utile de garder plusieurs sauvegardes également pour pouvoir récupérer un fichier supprimé par erreur. Cela permet également de retrouver un système à un état antérieur, en cas d’attaque non détectée immédiatement par exemple. À vous de voir.

Attention également aux systèmes de fichiers. Une sauvegarde externe sur un support en FAT est plus simple pour accéder aux sauvegardes rapidement, mais le système de fichiers FAT ne prend pas en compte les droits des fichiers, ce qui peut poser quelques problèmes.

Il ne faut pas oublier également de sauvegarder la base de données de mariadb, grâce à la commande suivante par exemple (crée un fichier SQL EMPACEMENT_DE_LA_SAUVEGARDE contenant le backup de toutes les bases) : 

mysqldump -u root -pPASSWORD --opt --all-databases > EMPLACEMENT_DE_LA_SAUVEGARDE

Pour aller plus loin :

Un mot sur la sécurité

Votre serveur va régulièrement subir des scans de port, des tentatives d’exploitation de failles connues (qui bien sûr ne seront pas présentes sur votre serveur !) etc. Il faut donc surveiller les logs, notamment grâce à logwatch pour ne pas avoir de mauvaise surprise et surtout, réagir calmement en cas de besoin (plus facile à dire qu’à faire), cf. Que faire en cas de soupçons d’un serveur compromis (ubuntu-fr.org).

La plupart de ces attaques passeront à côté de leur but, mais ne surestimez pas non plus la protection de votre serveur.

Au niveau des mesures à prendre pour se protéger un minimum :

  • Suivre les news de la debian security team, grâce à son flux RSS par exemple. Elle communique sur les mises à jour de sécurité.
  • Réaliser des recherches de mise à jour régulièrement (surtout lorsqu’un des paquets installés sur son serveur a fait l’objet d’une mise à jour par la debian security team).
  • Impérativement suivre l’avancement des projets que l’on a installé sur son serveur sans passer directement par les repos (Owncloud par exemple) afin de faire les mises à jour de notre côté et d’éviter de laisser des failles de sécurité sur son serveur. Il n’y a rien de plus inquiétant que de voir que certains blogs tournent encore sous des versions de Wordpress vieilles de plusieurs années et dans lesquelles de nombreuses failles plus ou moins critiques ont été découvertes…
  • Une autre bonne idée est de faire un script se connectant à mariadb = un utilisateur unique sur mariadb, n’ayant des droits que sur la base dont il a besoin. Il est très facile de rajouter des utilisateurs sur phpmyadmin, par l’onglet “Privilèges”.

Aller plus loin avec SSH

Se connecter à Internet en passant par son serveur (SOCKS)

Une fois que vous avez un accès en SSH sur votre machine, vous pouvez vous y connecter de n’importe où dans le monde. On peut alors exploiter cette possibilité pour se connecter à Internet de façon sécurisée dans des milieux à risque, ou pour échapper à un filtrage. Deux exemples :

  • Vous vous connectez à Internet depuis votre bureau mais certains sites sont bloqués. On peut créer un “tunnel” entre votre PC et votre serveur qui sera chiffré. C’est votre serveur qui ira chercher le contenu de la page web que vous voulez voir et qui vous l’enverra via ce tunnel chiffré, vous permettant ainsi d’échapper au filtrage.
  • Vous vous connectez souvent via des réseaux wifi publics. Sachez que dans ce cas, toute votre navigation peut être écoutée facilement, et que si vous vous connectez à un site sans protection particulière (sans HTTPS par exemple), votre mot de passe peut être récupéré. Pour éviter cela, on peut se connecter à son serveur via SSH, et ainsi notre communication sera chiffrée jusqu’à notre serveur, ce qui évite des écoutes indésirées.

Pour se faire, rien de plus simple. Pour Linux, une bonne explication est disponible sur le wiki d’Arch linux. Pour Windows, il y a de bonnes explications ici.

Et après, vous pouvez même avoir un OpenVPN pour le pauvre en utilisant sshuttle.

Monter un disque SSH directement

Sous Linux, il est très facile de monter un disque SSH directement comme un système de fichiers. Nautilus le gère directement, et sinon, regarder du côté de sshfs.

Envoyer des emails avec son serveur

Pour pouvoir envoyer des emails depuis son serveur (pour les notifications Logwatch notamment), il faut reconfigurer exim4 avec la commande dpkg-reconfigure exim4-config. Plus d’informations sont disponibles ici.

Note à propos de FTP et de l’absence de doc sur l’installation d’un serveur FTP

Comme vous l’aurez sûrement remarqué, je n’ai jamais parlé d’installer un serveur FTP sur cette page. Pourtant, la majorité des hébergements mutualisés proposent un accès FTP pour envoyer les scripts sur le serveur.

L’idée est d’envoyer tout ce dont on a besoin par SSH, en utilisant SFTP (qui n’a rien à voir avec FTP). Sous linux, on peut utiliser les commandes scp ou rsync. Sous Windows, on peut utiliser WinSCP. Filezilla gère aussi ce type de transfert de fichiers.

L’intérêt majeur étant que je peux ainsi utiliser directement un truc déjà paramétré sur mon serveur, sans avoir à installer de service supplémentaire. Cela veut donc dire moins de configuration, moins de services qui tournent, et donc moins de risques de faire n’importe quoi.

FTP me servirait si j’avais de nombreux utilisateurs sur mon serveur (comme pour un hébergeur sur son mutualisé par exemple), car je pourrais alors créer facilement des utilisateurs “virtuels” sans leur associer de compte sur la machine. Mais le cas enivsagé dans cette doc est celui d’un particulier souhaitant s’auto-héberger, donc a priori il est un des seuls utilisateurs du serveur. SSH est donc amplement suffisant.

De plus, en utilisant SSH, les transferts sont chiffrés, y compris l’authentification avec nom d’utilisateur / mot de passe (contrairement à FTP, donc pas de problèmes de mot de passe en clair sur un réseau wifi public). Le seul risque est que le port utilisé par SSH soit bloqué sur le réseau, mais je n’ai encore jamais vu de réseaux avec SSH indisponible mais FTP disponible.

Pour ceux qui veulent quand même installer un serveur FTP, ils trouveront quelques liens, sans garantie, sur mon shaarli.

Bonus : Utiliser son nom de domaine pour repérer ses périphériques

Si vous êtes chez OVH (ou n’importe quel hébergeur qui supporte les champs de type DYNHOST), vous pouvez créer un champ de type DYNHOST pour chacun de vos périphériques. En installant ddclient et en le paramétrant sur chacun d’eux, vous pourrez donc toujours avoir les adresses IPs de vos périphériques dans votre zone DNS.

Si vous n’avez pas de champs DYNHOST à disposition, il est toujours possible de faire un petit script PHP qui note l’adresse IP des visiteurs, et de réaliser une requête régulièrement vers cette page depuis chaque machine (avec un petit wget). Et ça peut servir ! :)

Liens en vracs

Licence

Si cette page peut servir et motiver pour passer à l’autohébergement, tant mieux ! Donc, aucune licence particulière, et j’adopte donc la SODAWARE (variante perso de BEERWARE), comme pour pas mal de mes codes. Vous êtes donc libre de la diffuser, réutiliser et de faire un peu tout ce que vous voulez avec (tant que vous ne prétendez pas que les modifications que vous avez apportées sont de moi). Si vous faites quelques chose de cette page, ça serait cool de me faire un petit signe et d’indiquer l’origine, mais rien ne vous l’impose. Ah, et si un jour on se croise par hasard et si vous pensez que cette page le mérite, vous pouvez me payer un coup à boire en retour :).

Historique

Cette partie regroupe des sections anciennement présentes dans le corps de la page, mais déplacée car devenues obsolètes. Je les laisse uniquement à titre historique et ne les maintiendrais pas.

SVN, le gestionnaire de versions

Mise à jour : Attention, cette section peut ne pas être à jour, je la laisse juste au cas où elle puisse servir à quelqu’un. J’ai migré depuis quelques temps vers Git, qui a de nombreux avantages.

Subversion est un gestionnaire de version. Il est notamment connu par les développeurs qui l’utilise pour travailler à plusieurs sur un projet et suivre tout l’historique des modifications des fichiers sources. Subversion vous permettra de créer des répertoires (“repositories”) qui contiendront des fichiers surveillés par subversion et que vous pourrez éditer librement. Subversion gardera un historique de toutes les modifications et vous permettra de résoudre facilement des conflits d’édition. Il faut cependant noter que Subversion ne fonctionne pas avec tous les types de fichiers, en particulier avec les fichiers binaires.

Un bon tutoriel de présentation de Subversion et de son utilisation est disponible sur le Site du Zéro.

Un guide d’installation de SVN est disponible ici. Trac est un gestionnaire complet de projet, à vous de voir si vous en avez besoin, mais il est tout à fait possible d’utiliser SVN sans trac. Si vous ne souhaitez pas l’installer, n’installez pas le paquet trac et arrêtez-vous avant la partie “Initialisation de Trac”.

Notes :

  • pour créer un dossier, svnadmin create /home/svn/monprojet suffit.
  • les dossiers trunk, branches et tags sont des dossiers standards utilisés pour développer. Vous n’êtes pas obligés de les créer (je n’en ai personnellement pas sur mes dépôts SVN). Ils sont pratiques sur de gros projets ou des logiciels qui évolueront beaucoup.
  • je vous conseille de créer vos repos svn dans un dossier repos (ie /home/svn/repos). On pourra ainsi facilement avoir une interface web à une adresse du type http://svn.example.tld et les repos accessibles via http://svn.example.tld/repos/Nom_du_repo.
  • Une fois un repo créé, on peut le déplacer avec mv, comme n’importe quel autre dossier. Pour le supprimer, il suffit de supprimer le répertoire avec rm.
  • Subversion possède aussi un serveur interne, on n’est pas obligé de le faire tourner derrière Apache. Mais le faire tourner derrière Apache, c’est quand même plus propre, plus simple et plus puissant, c’est pourquoi je n’en ai pas parlé.
  • Attention : tester SVN, c’est ne plus pouvoir s’en passer ! :)

À l’issue de ce guide, vous avez des repos SVN fonctionnels partageant tous la même authentification. C’est bien, mais pas top… En effet, on ne peut pas définir de repos publics / privés ou donner des autorisations particulières sur chaque repo à des utilisateurs différents (on n’a pas de contrôle des autorisations par repo, à moins de modifier la configuration d’Apache pour chaque repo, ce qui est vite gênant). C’est ce que je vous propose de mettre en place maintenant. Un bon guide pour mettre cela en place est disponible ici par exemple.

Il est possible d’utiliser une interface web pour SVN, telle que WebSVN. L’installation et la configuration est bien documentée et les fichiers de configuraion sont bien commentés. WebSVN est la meilleure interface que j’ai touvée jusqu’à présent mais il gère mal les repositories publics/privés.

Pour gérer les repos publics/privés, je vous propose un petit “hack” de WebSVN (ce n’est pas terrible, mais ça marche pas trop mal) :

  • Dans le dossier de websvn, créez un fichier connexion.php avec ce contenu : 
    <?php
header('location: '.$_GET['redir']);
?>
  • Dans le dossier templates/calm (je n’ai pas modifié les autres thèmes, on peut faire de même), ajouter avant [websvn-else] (ligne 3) : 
    <p style="font-size: 2em;"><a href="http://svn.domain.tld/connexion.php?redir=[websvn:repurl]">Connexion</a></p>
  • À côté du fichier connexion.php, créez un fichier .htaccess avec ce contenu : 
    <Files monfichier.php>
AuthUserFile /lefichiermotdepasse
AuthGroupFile /dev/null
AuthName "Accès Restreint"
AuthType basic
<Limit GET POST>
    require valid-user
</Limit>
</Files>
  • Voilà, WebSVN devrait demander de vous connecter lorsque vous demandez à voir un repo non public maintenant, et vous rediriger automatiquement vers ce repo après connexion. En revanche, les dépôts non publics ne seront pas listés tant que vous ne serez pas connectés.

Il doit y avoir d’autres façons de bricoler, chacun fait comme il veut. Mais il n’y a aucune solution universelle…

Il existe une option “multiViews” dans WebSVN pour avoir de belles URLs. Il faut alors activer Multiviews dans la configuration du vhost. Une autre solution (plus élégante je trouve car elle supprime le wsvn qui ne sert à rien dans l’adresse) est de ne pas activer Multiviews dans le vhost mais de mettre à la place :

Alias /templates /websvn_path/templates
Alias / /websvn_path/wsvn.php/

Il faut en revanche laisser l’utilisation de multiviews activée dans le fichier de config.

Si vous supprimez le wsvn, l’astuce précédente ne marche plus. Le plus simple est alors de modifier le lien dans le fichier directory.tmpl (supprimer connexion.php). Supprimez également les fichiers connexion.php et .htaccess. Modifiez ensuite le fichier wsvn.php comme suit (ajouter ceci au début du fichier wsvn.php) - Note : le code suivant considère que les htpasswd ont des mots de passe en {SHA} - :

if(!empty($_GET['connexion']))
{
    if(!isset($_SERVER['PHP_AUTH_USER']))
    {
            header('WWW-Authenticate: Basic realm="Acces restreint au SVN"');
            header('HTTP/1.0 401 Unauthorized');
    }
    else
    {
            $htpasswd = file_get_contents('/home/svn/repos/comptes.htpasswd');
            $htpasswd = explode("\n", $htpasswd);

            foreach($htpasswd as $line)
            {
                    $user = explode(":", $line);

        if($_SERVER['PHP_AUTH_USER'] == $user[0] && base64_encode(pack("H*", sha1($_SERVER['PHP_AUTH_PW']))) == substr($user[1], strpos($user[1], '{SHA}') + 5))
                    {
                            $connecte = 1;
                    }
            }
            if(empty($connecte))
            {
                    header('WWW-Authenticate: Basic realm="Acces restreint au SVN"');
                    header('HTTP/1.0 401 Unauthorized');
                    exit();
            }

            if(!empty($_GET['redir']))
                    header('location: '.$_GET['redir']);
            else
                    header('location:""');
    }
}

Alternatives disponibles : Git (prononcé “guite”, utilisé sur Github et traité dans le corps de la page), mercurial (hg), Bazaar … Chacun a ses avantages et ses inconvénients mais je trouve personnellement que subversion est un des plus simples à appréhender.

Mozilla Sync : synchroniser Firefox entre ses différents appareils

Cette partie est devenue obsolète depuis la version 29 de Firefox qui a vu apparaître “Firefox Accounts” et la version 1.5 de Firefox Sync. Les informations pour installer la dernière version sont disponibles chez Mozilla et sur mon blog.

De plus, cette méthode est assez compliquée finalement, et si vous avez déjà installé OwnCloud sur votre serveur, il y a un plugin pour OwnCloud qui fait ça très bien. Enfin, je le note ici mais il y a plus d’explication dans la partie OwnCloud, le support de SNI n’est pas présent dans Android, ce qui peut poser des problèmes avec Firefox Sync sur Android (faciles à résoudre).

Vous utilisez Mozilla sync pour synchroniser vos instances de Firefox (marques-pages etc.) entre vos différents appareils ? Vous pouvez l’installer sur votre serveur (relativement) facilement pour l’utiliser à la place des serveurs Mozilla.

Quelques liens pour commencer :

En gros, voici comment il faut procéder (se référer aux liens précédents pour plus de détails) :

  • Installation des pré-requis : python, mercurial et j’en passe. Pas besoin d’installer mysql-server, on a déjà mariadb.
  • Récupération des sources (hg clone …) dans un dossier, par exemple /usr/local/sync puis compilation (make build).
  • Création d’une base de données et d’un utilisateur dans PHPMyAdmin.
  • Édition du fichier de configuration pour correspondre à ses besoins. Pour cela, ce lien est pas mal (il faut juste s’adapter un petit peu avec les dossiers / nom de comptes etc.).
  • À ce stade, vous avez un serveur sync configuré. 2 possibilités : soit vous faites tourner Sync sur le port 5000 (ou autre), avec le petit serveur fourni par Mozilla, mais c’est pas l’idéal, soit on fait les choses bien et on le passe derrière Apache.
  • Pour le configurer pour tourner derrière Apache, se référer au lien précédent.

Le mieux est de le faire tourner sur MySQL + Apache. Ce lien est bien aussi pour l’installation mais il ne traite pas la partie MySQL. La doc de Mozilla est bien faite et reste une référence aussi.

SimpleID : le fournisseur de service OpenID (méthode de connexion décentralisée pour de nombreux sites)

Je laisse cette sous-partie à titre informatif, mais je ne la maintiendrai plus à l’avenir, n’utilisant plus OpenID. J’ai rencontré plusieurs problèmes récurrents avec SimpleID, qui m’ont fait m’éloigner du projet, et l’authentification par OpenID a peu à peu disparue des sites webs, pour laisser la place à Facebook, Google et consorts. StackExchange est un des seuls gros sites restants qui proposent de se connecter avec OpenID (à ma connaissance). Pour ceux qui recherchent une solution semblable à OpenID, c’est Mozilla Persona qui semble le mieux placé actuellement.

SimpleID vous permet d’héberger un service OpenID sur votre serveur. L’idée de base d’OpenID est de se connecter une fois, sur son instance, puis d’utiliser des passerelles pour se connecter sur tous les autres sites, à la manière des “connect with Google / Facebook”. Quelques liens que j’avais utilisé à l’époque où je l’avais mis en place :