À propos de KDE, Ubuntu et les Logiciels Libres
Par billux
Cet article fait parti d’une longue série d’articles sur la configuration d’un home serveur. Tous les articles de cette série sont disponibles dans la catégorie « Configuration d’un home serveur ».
Ça faisait un moment que je ne m’étais plus occupé du serveur. Il faut dire qu’en ce moment je suis pas mal pris entre les études et…
Bon j’évite de raconter ma vie et je passe aux choses sérieuses.
Aujourd’hui, pas de gros tutoriels en vue, mais quelques petites astuces pour vous simplifier la vie.
apticron, où comment être prévenu d’une mise à jour
Le problème : comment savoir si il y a des mises à jour à faire sur le serveur ?
Deux solutions :
- Soit vous vous connectez régulièrement sur le serveur et faites un
sudo apt-get update && sudo apt-get upgrade
C’est pas très marrant et je doute que vous y pensez chaque matin en vous réveillant ;
- Soit vous utilisez apticron
.
Apticron est en fait un script bash qui est appelé régulièrement par cron (par défaut tous les jours à 22h11). Il vérifie si il y a des mises à jour (par un simple apt-get dist-upgrade) et envoi son rapport par mail à root.
Pour l’installer, comme d’hab’ :
sudo apt-get install apticron
Ensuite vous pouvez changer l’heure et la périodicité d’exécution du script :
sudo vim /etc/cron.d/apticron
Je vous conseille le mettre vers les 06h (au lieu des 22h), car c’est là où il y a très peu d’activité (du moins pour un serveur web).
Vous pouvez également changer l’adresse email de destination (directive « EMAIL ») dans le fichier /etc/apticron/apticron.conf, ainsi que diverses options.
Si mises à jour il y a, vous recevrez un mail listant les paquets à mettre à jour, ainsi que les changelogs de chaque paquet :
Aperçu d'un rapport apticron envoyé par mail
Synchronisation automatique de l’heure
Un serveur à l’heure est important, ne serait ce que pour les logs. Malheureusement, l’horloge des cartes mère à tendance à avancer/retarder au fil du temps. Vous pouvez alors vous synchroniser à des serveurs de temps via NTP (Network Time Protocol).
Il vous suffit d’installer ntp, un démon qui va synchroniser régulièrement l’heure système à un ou plusieurs serveurs de temps.
sudo apt-get install ntp
Le démon fonctionne dès l’installation, vous pouvez changer les serveurs de temps et d’autres options de configuration dans le fichier /etc/ntp.conf.
Attention quand même : Lors de la première synchro, mon heure système avançait d’un peu plus de 39 secondes (J’ai trouvé ça beaucoup d’ailleurs). Le changement d’heure brutal peut ne pas plaire à tous le monde (notamment à dovecot et postfix). Pensez à regarder les logs !
tail /var/log/syslog
Jan 10 15:50:15 heimdall ntpd[7605]: kernel time sync status 0040
Jan 10 15:50:23 heimdall ntpd[7605]: synchronized to 91.121.121.160, stratum 2
Jan 10 15:49:43 heimdall ntpd[7605]: time reset -39.551643 s
Jan 10 15:49:44 heimdall dovecot: Time just moved backwards by 39 seconds. This might cause a lot of problems, so I'll just kill myself now. http://wiki.dovecot.org/TimeMovedBackwards
Jan 10 15:51:12 heimdall postfix/smtpd[7616]: warning: SASL: Connect to private/auth failed: Connection refused
Jan 10 15:51:12 heimdall postfix/smtpd[7616]: fatal: no SASL authentication mechanisms
Jan 10 15:51:13 heimdall postfix/master[6285]: warning: process /usr/lib/postfix/smtpd pid 7616 exit status 1
En général, il suffit de les redémarrer :
sudo /etc/init.d/dovecot restart
sudo /etc/init.d/postfix restart
Pour voir l’heure système :
date
Par billux
Cet article fait parti d’une longue série d’article sur la configuration d’un home serveur. Tous les articles de cette série sont disponibles dans la catégorie « Configuration d’un home serveur ».
Enfin le serveur web .
J’ai choisi d’utiliser lighttpd (prononcez lighty, c’est plus simple). Il est moins gourmand qu’Apache en terme d’utilisation mémoire et de charge CPU, tout en étant aussi performant et sécurisé bien sûr, donc parfait pour notre petit serveur. Par contre, il est moins complet qu’Apache : par exemple, il ne supporte pas les fichiers .htaccess, il faut tout définir dans le fichier de configuration général.
Installation
La présentation étant faite, vous pouvez commencer à installer le paquet :
sudo apt-get install lighttpd
Voilà votre serveur web fonctionne déjà ! Mais nous n’allons pas nous arrêter là, c’est pas intéressant quand tous marche du premier coup 
.
Quelques optimisations
En fonction du système utilisé :
Si vous avez un noyau Linux 2.6 (dans 99% des cas), rajoutez ces 2 lignes dans le fichier /etc/lighttpd/lighttpd.conf :
server.event-handler = "linux-sysepoll"
server.network-backend = "linux-sendfile"
Sinon, allez voir la doc pour savoir quelles valeurs mettre
Compression :
Si ce module est activé, et si le navigateur du client le supporte, les données envoyées seront compressées pour réduire l’utilisation de la bande passante. Ça peut être intéressant pour un home serveur, puisque les FAI fournissent en général une bande passante en upload minable.
Vérifiez qu’il est bien chargé (à priori il l’est) :
server.modules = (
...
"mod_compress",
...
)
PHP & MySQL
Tout dépend de ce que vous voulez mettre sur votre serveur, mais vous aurez très probablement besoin de PHP et MySQL.
Pour les installer :
sudo apt-get install php5-cgi php5-mysql mysql-serveur-5.0
Configuration de PHP :
D’abord, il faut activer le module dans votre lighttpd.conf, comme ceci :
server.modules = (
...
"mod_fastcgi"
)
Puis définir quelques chemins :
fastcgi.server = ( ".php" => ((
"bin-path" => "/usr/bin/php5-cgi",
"socket" => "/var/run/lighttpd/php-fastcgi.socket"
)))
Ensuite, je vous conseille d’aller faire un petit tour dans le fichier /etc/php5/cgi/php.ini. C’est le fichier de configuration géréral de php, et il y a de quoi faire si vous voulez augmenter un peu la sécurité de votre serveur. System-linux a fait un très bon article dessus, j’en ferai peut être un si je trouve des trucs à rajouter.
Configuration de MySQL :
Normalement, lors de l’installation vous avez dû entrer un mot de passe root pour la base. Si ce n’est pas le cas :
sudo dpkg-reconfigure mysql-serveur-5.0
Votre base est prête à l’emploi. Comme pour PHP, on reviendra peut être dessus pour l’optimiser et la sécuriser un peu mieux.
Un groupe webadmin
Un petit truc pratique pour pouvoir gérer votre site correctement sans être root. Rappelez vous, on avait créé un groupe sysadmin, pour avoir le droit d’utiliser sudo. Maintenant, on va créer un groupe webadmin, qui aura tous les droits dans le répertoire /var/www :
sudo addgroup webadmin
sudo chgrp -R webadmin /var/www
sudo chmod g+ws -R /var/www
Enfin, vous pouvez vous ajouter au groupe :
sudo votre-login webadmin
Ouverture dans le pare feu
Quand vous serez près à ouvrir votre site au monde entier ( 
), ouvrez le port 80 sur votre routeur et dans le script d’iptables.
Pour fail2ban, il ne gère pas nativement lighttpd. Mais ce n’est pas grave, un certain Buanzo a déjà écrit la regexp qui faut. Téléchargez le fichier puis placez le dans /etc/fail2ban/filter.d/.
Ensuite, éditez le fichier /etc/fail2ban/jail.conf pour y mettre ceci :
[lighttpd-fastcgi]
enabled = true
port = http,https
filter = lighttpd-fastcgi
logpath = /var/log/lighttpd/error.log
maxretry = 6
Et relancez votre pare feu bien sûr.
Voila pour le serveur web. Suivant, ce que j’aurai fait sur mon serveur je ferai sûrement des tutos pour la gestion du https, de l’URL rewriting (pour Wordpress par exemple), l’utilisation de Xcache (pour éviter de ré exécuter le php des pages à chaque requêtes), l’installation d’un webmail (si ce n’est pas aussi simple qu’un Wordpress), etc…
Donc ce n’est pas fini !
Par billux
Cet article fait parti d’une longue série d’article sur la configuration d’un home serveur. Tous les articles de cette série sont disponible dans la catégorie « Configuration d’un home serveur ».
Maintenant que vous gérez votre serveur mail, c’est vous qui en êtes responsable. Autrement dit, si vous perdez vos mails vous ne pourrez vous en prendre qu’à vous. Personnellement je vois ça comme un avantage, mais vous le prenez comme vous voulez, toujours est-il qu’il vaut mieux penser à faire des sauvegardes régulières des maildirs.
Bonne nouvelle pour vous, j’ai réalisé un script qui s’occupe de cette tâche. Il est en Perl et sous licence GNU GPL (ça va de soit ).
C’est ici pour le télécharger.
Vu que je l’ai fait surtout pour répondre à mon cas à moi, il se peut qu’il ne vous convienne pas. Si vous le modifiez, n’hésitez pas à me dire ce que vous avez amélioré d’ailleurs. Vous pouvez aussi me proposer certaines idées à rajouter, j’essaierai de les ajouter dans la limite de mon temps libre.
Une petite présentation rapide du script
Voici, ce qu’il fait :
- Il récupère la liste des utilisateurs ainsi que leur home depuis le fichier /etc/passwd.
- Il arrête les services postfix et dovecot (pour éviter que l’un deux écrive dans la maildir alors qu’on est en train de la sauvegarder).
- Pour chaque utilisateur, il fait appel à rsync (donc ne copie que ce qui a été ajouté ou modifié) pour sauvegarder sa maildir vers un dossier local.
- Il redémarre postfix et dovecot une fois la copie terminée.
- Si un périphérique externe est présent (clé/disque USB, montage NFS, …) il fait de nouveau un rsync depuis les maildirs copiées localement vers le périphérique externe spécifié.
- Éventuellement, démontage du périphérique si il était démonté avant l’exécution.
Déjà, une petite explication sur le double rsync, qui peut paraître lourd. Effectivement, pourquoi ne pas sauvegarder directement la maildirs vers le périphérique externe ?
Plusieurs raisons :
- D’abord, comme Postfix est arrêté pendant la copie, il faut éviter qu’il le soit trop longtemps ; si vous n’avez pas de chance et qu’un serveur smtp essaye de contacter le votre pour lui envoyer un mail, personne ne répondra (bon normalement, il réessayera plus tard mais bon on sait jamais). Donc la manière la plus rapide de copier la maildir et encore de la copier sur le disque dur lui même. Ensuite on aura tout le temps pour la copier ailleurs.
- Deuxièmement, la copie d’un endroit à l’autre du disque est ce qu’il y a de plus sûr. Imaginez que votre script s’exécute la nuit et que, pas de chance, la veille vous aviez retiré la clé USB pour vous en servir et ne l’aviez pas rebranché (la fatigue, toussa…). Ou alors que le serveur de fichier sur lequel vous copiez habituellement vos sauvegardes ne répond pas par exemple. À ce moment là, vous êtes bien content d’avoir quand même une copie sur le disque dur qui s’est faite.
- Et puis imaginez que ce n’est pas le disque qui lâche, mais juste que vous avez fait une fausse manip ou un bug de dovecot ou votre client mail. Le fait d’avoir une copie en local accélérera beaucoup la récupération, que de devoir allez chercher le tout depuis un autre endroit.
Ensuite, vous constaterez qu’au début du script, vous avez la possibilité de définir pas mal de truc : les répertoires de sauvegarde local et distant, le périphérique à utiliser, les options à passer à rsync (que ce soit pour la copie locale ou distante, …).
À noter quand même : je me suis aperçu que peu de systèmes de fichier n’apprécient le noms des fichiers des maildirs (du style 1257622696.P32064Q174M509794.heimdall:2,S), à commencer par le FAT. Donc pensez, si vous utilisez une clé USB à la passer en ext2 par exemple. Sinon, une autre solution peut être d’utiliser tar -u. Ainsi tar va archiver tous les fichiers en un seul (donc plus de problème avec les noms de fichier) et -u (pour –update) va mettre à jour l’archive avec les fichiers modifiés ou ajoutés (un peu comme rsync).
Ajout du script à cron
Pour pouvoir l’exécuter périodiquement, vous allez faire appel à cron. Placez le script dans /etc/cron.daily, /etc/cron.weekly, … ou modifiez la crontab si aucun ne vous conviennent (au choix, c’est vous qui voyez).
sudo mv backup.pl /etc/cron.daily/backup
(Attention à bien enlever le .pl, sinon le cron n’exécutera pas le script)
Rendez le bien sûr exécutable, et c’est terminé :
sudo chmod +x /etc/cron.daily/backup.pl
Vous recevrez alors un mail à chaque fois qu’il sera exécuté. Si ça vous embête, rajoutez
MAILTO=/dev/null
dans le fichier /etc/crontab.
Voila, pour la prochaine fois, je pense qu’on attaquera le serveur web (j’hésite encore sur celui que je vais choisir, même si je penche sur Lighttpd). Mais on reviendra sur le serveur mail pour l’antispam et le webmail.
Par billux
Peut-être avez vous déjà rencontré ce problème, il n’est pas possible de se connecter en SSH sur un serveur lorsqu’on se trouve derrière un proxy.
Je m’en suis aperçu quelques jours après le début des cours à l’IUT de Nancy lorsque j’ai voulu créer un tunnel SSH (on verra comment par la suite) pour pouvoir accéder à mes mails, les messageries instantanées, etc… Le réseau de l’université se trouve en effet derrière un proxy qui bloque tout et n’importe quoi (en fait seul les ports http et https sont autorisés). Souvenir du réseau wifi de l’IUT de Marseille où on pouvait télécharger en P2P les films ISOs Linux en quelques minutes… 
Pour résoudre le problème (du ssh, pas du P2P), il y a deux choses à faire.
Coté serveur
Bien entendu, comme le proxy bloque tout sauf http et https, il n’y a pas de miracles, il faut faire écouter le serveur SSH sur le port https (les transfert sont chiffrés pour https et SSH, le proxy ne peut pas voir la différence). Pour ça, modifiez votre /etc/ssh/sshd_config pour changer la valeur de « Port » :
Port 443
Redémarrez OpenSSH et assurez vous de changer les ports également dans votre pare feux et votre routeur.
Coté client
À priori, on peut croire que le problème est maintenant résolu, le serveur écoute sur le port https, le proxy laisse passer les données sur le port https, et le client indique de ce connecter par le port https. Et bien non, ce n’est pas aussi simple, et je n’ai eu la réponse qu’aujourd’hui, pendant un cours sur les serveurs web.
En fait, le fait de passer par un proxy interdit de faire une connection direct entre le client et le serveur (un proxy étant fait pour s’intercaler entre les échanges). Il faut donc dire explicitement au proxy d’établir une connection direct entre les deux machines, et de ne plus s’en mêler ensuite. C’est grâce à la commande HTTP CONNECT que c’est possible (vous voyez mieux le rapport avec les serveurs web à présent ).
Pour réaliser ça en pratique, on va utiliser corkscrew. Installez le puis modifiez votre fichier client /etc/ssh/ssh_config comme ceci :
Host univers-libre.net-proxy
Hostname univers-libre.net
Port 443
ProxyCommand /usr/bin/corkscrew vivianen.iuta.univ-nancy2.fr 3128 %h %p
Host univers-libre.net
Port 443
Explications :
on a définit 2 configurations (host, dans le fichier) : une dans le cas normal (univers-libre.net) et une autre avec un proxy (univers-libre.net-proxy). Ainsi, si vous êtes derrière le proxy, vous devrez taper :
ssh univers-libre.net-proxy
Dans le cas contraire :
ssh univers-libre.net
Dans la configuration avec proxy, on indique que, en fait le vrai nom n’est pas univers-libre.net-proxy mais univers-libre.net (avec la directive hostname). Le port est bien sûr fixé à 443 (https) dans les 2 cas.
Viens la ligne ProxyCommand : on dit à OpenSSH de faire appel à corkscrew en lui passant en paramètre l’adresse du proxy (ici vivianen.iuta.univ-nancy2.fr), le port du proxy (3128 qui est le port par défaut des proxies). %h et %p indiquent respectivement l’hôte à atteindre et son port (univers-libre.net et 443).
Maintenant que vous avez un accès SSH sur votre serveur à vous la liberté . Vous pouvez alors créer un tunnel SSH pour certaines applications, en rajoutant une ligne de ce type dans le fichier /etc/ssh/ssh_config de votre client :
LocalForward 143 localhost:143
Dans cet exemple je dis de rediriger toutes les demandes de connections qui sont envoyées sur le port 143 (imap), vers le même port et sur le même serveur que le serveur SSH (localhost). Ainsi mon client mail pourra accéder à mon serveur imap, le tout de façon transparente, mais crypté dans le tunnel .
