suPhP & ses caprices
Quest-çe que suPhP ?
Je n’ai pas vraiment le temps d’écrire une éloge sur suPhP, mais en gros, cela permet d’executer les scripts php avec le owner associé au fichier php, et non le owner d’apache !
De ce fait, l’utilisateur toto, n’iras pas tenter de bidouiller les scripts php de titi, car ils n’auront pas le même owner ! Ce qui n’est pas le cas par défaut quand tous les fichiers php sont au minimum dans le groupe www-data.
Quel caprices ?
Bon le caprice que j’ai eu aujourd’hui, et vraiment con, mais j’ai passé 1h dessus, alors je le met ici surtout comme pense bête… En fait, suPhp n’y ais pour rien
J’ai installé un serveur LDAP sur Grumpy (j’essaierais de faire un article là-dessus, un jour), jusque là, pas de rapport direct, mais une fois que tout fonctionne il m’a fallut un front graphique, j’ai donc installé phpldapadmin.
1 | $ aptitude install phpldapadmin |
Je me connecte ensuite à l’interface graphique, et hop tout beigne, au passage je fais quelques louange au dieu père des gestionnaires de paquets ^^ !
Puis je souhaite configurer mon Webmail favoris… Là c’est le drame, il me pètes des erreurs assez perturbantes, comme quoi il ne trouve pas des fichiers de configurations, alors que ceux-ci existent !!!
Après plusieurs test, surtout sur d’autres sites hébergés par Grumpy, je comprend que suPhP ne fait plus son office !
Comment faire pour que ça fonctionne ?
Pour que ça re-fonctionne, il suffit de comprendre pourquoi ça ne fonctionne plus… En fait pour que suPhP soit opérationnel, il faut tout simplement désactiver le module php de apache !
1 2 3 | $ a2dismod php4 $ a2dismod php5 |
On relance, bien sûr apache
1 | $ /etc/init.d/apache2 restart |
Et le tour est joué
$ a2dismod php4
Ajout d’une IP-FailOver
Il y a longtemps, pratiquement au début de Grumpy, nous avions récupéré une IP-Failover, mais pour être tous à fait franc, celle-ci n’a jamais été utilisé, à tel point qu’aujourd’hui le nouveau domaine que j’ai acheté, et que j’ai fait pointer sur l’IP-Failover ne fonctionnait pas !
En fait la manipulation qui avait été omise a été de créer la configuration qui va bien du côté de grumpy, heureusement le guide d’ovh est là pour me sauver : http://guides.ovh.com/nicolas2 (chapitre « Distribution de base > Debian ») !
1 2 3 4 5 6 7 8 9 | # vim /etc/network/interfaces auto eth0:0 iface eth0:0 inet static address IPFAILOVER netmask 255.255.255.255 broadcast IPFAILOVER # /etc/init.d/networking restart |
Et hop le tour est joué, on balise un peu lorsqu’il s’agit de restart les interfaces réseaux, Fail2Ban, m’envoie plusieurs rapports de redémarrage ! Puis le « ping IPFAILOVER », qui tourne, sans effet, depuis 10min dans le xterm d’à-côté, se met miraculeusement à vivre ses premiers échanges
Alléluyah
Notre réseau privé virtuel
Dans mon premier billet, je vais vous parler de ce petit VPN que nous avons mis en place entre Grumpy (le serveur dédié) et quelques autres machines.
Mais avant tout, quelques points d’explications, pour ne pas perdre ceux qui n’ont jamais entendu parler de cette formidable technologie.
Virtual Private Network (Réseau privé virtuel), qu’est ce que c’est ?
On parle de réseau privé virtuel, ou VPN, lorsque deux machines, se trouvant sur deux réseaux différents, établissent un tunnel. Ce tunnel est le plus souvent chiffré, afin qu’une personne écoutant la communication ne soit pas en mesure d’en comprendre le contenu. Ces deux machines sont alors à même de communiquer l’une avec l’autre, comme si un simple câble les reliait.
Ça à l’air sympa, mais à quoi ça sert un VPN ?
Voyons maintenant quelques cas communs où des VPNs sont mis en place.
Le cas typique: l’entreprise et ses employés travaillant à distance
Imaginons que vous soyez un chef d’entreprise soucieux de la productivité de vos employés (comme beaucoup de PDG je suppose
). Ceux-ci sont souvent en déplacement mais ont tout de même besoin d’accéder au réseau local (LAN, Local Area Network) de l’entreprise et à ses ressources (serveur de fichiers, intranet, …).
Vous allez donc demander à votre administrateur réseau de mettre en place une solution VPN qui va permettre aux employés de se connecter à distance au LAN de l’entreprise. Concrètement, vous aurez un serveur VPN, écoutant sur l’Internet, attendant la requête d’un client VPN de l’un de vos employé, connecté à l’autre bout du monde. Un fois la connexion établie, celui-ci pourra communiquer avec une partie, ou l’ensemble des machines du LAN de l’entreprise, tout dépend de la configuration de celui-ci.
Connectons les bureaux !
Toujours dans un soucis de productivité, vous désirez connecter les deux bureaux, espacés d’environ 300 Km. Vous n’allez pas tirer un câble ! (si une fibre, pourquoi ? :-/). Vous allez connecter les deux réseaux à l’aide d’un lien VPN, et au final, tout sera comme si tout était physiquement connecté, et la secrétaire de la ville A pourra sans problème accéder au fichiers du serveur de la ville B.
Point d’accès Wifi, la protection radicale
Cette technique est souvent employée dans les collectivités, par exemple dans les universités, car elle simplifie grandement la gestion des points d’accès aux réseaux sans-fil. Plutôt que de chiffrer le réseau avec les techniques habituelles (clé WEP, chiffrage WPA/WPA2, …), le point d’accès est laissé sans protection. N’importe-qui donc, peut s’y connecter. Seulement, une fois connecté, la seule machine à laquelle on peut parler, est une machine hébergeant un serveur VPN ! Rien d’autre n’est accessible sur ce réseau, pas moyen de router son trafic vers l’Internet.
En revanche, les personnes ayant un accès VPN seront à même de s’y connecter, et ainsi d’ouvrir un tunnel sécurisé avec elle. Ils pourront ainsi communiquer avec le reste du réseau, et souvent avec le reste du monde.
La gestion des utilisateurs est ainsi grandement simplifiée, puisqu’il suffit d’ajouter et de supprimer des comptes sur le serveur VPN suivant le besoins. Si l’administrateur devait changer le mot de passe WPA à chaque fois qu’un utilisateur est supprimé, et le recommuniquer à tout les autres utilisateurs, je vous laisse imaginer la galère (sans compter le manque de traçabilité des utilisateurs, …)
Maintenant que vous avez quelques exemples d’utilisations, je vais rentrer un peu dans le détail et notamment, comment mettre en place un VPN de manière simple.
Les différentes solutions de VPN
Il existe plusieurs solutions pour créer son VPN. Et comme toujours, certaines sont payantes, d’autres gratuites
.
Exemple de solutions matérielles payantes
Et évidemment, lorsqu’on parle de VPNs professionnels, on ne peut pas passer à côté du géant Cisco [1], qui fabrique entre autres des solutions VPN matérielles (c’est-à-dire, une machine, souvent dans un rack, dédiée à cette tâche). Ils sont bien entendu très performant, mais aussi très onéreux (disons qu’il faut avoir l’utilité d’une bête pareille pour se la payer).
Il existe d’autres constructeurs de matériels réseaux professionnels dans ce genre comme par exemple Juniper Networks [2], l’un de leurs fervents concurrents.
Il faut bien comprendre ici que ces entreprises fabriquent du matériel dédié à cette tâche. C’est donc du matériel extrêmement performant mais qui ne fait que ça. C’est pour celà que l’on parle de VPN matériel (hardware).
Et maintenant, ce dont nous (petits particuliers), nous disposons
Bien entendu, lorsque avec Division-par-zero, nous nous sommes posés la question d’un VPN, nous n’allions certainement pas nous tourner vers le genre d’engins vus dans le paragraphe précédent. Déjà, nous n’avons qu’un serveur à notre disposition, et certainement pas les fonds nécessaires, ni le besoin pour acquérir un tel monstre. Donc, que nous reste-t-il ?
Hé bien ! Le monde du libre est encore une fois passé par là ! Et je vais vous présenter tout de suite OpenVPN [3]. OpenVPN fourni une solution VPN sous licence GPL-2 (entre autres), et permet de déployer son réseau VPN de manière simple et efficace. Il tourne sous Linux, xBSD, Windows et surement d’autres
.
La différence fondamentale avec les exemples précédents, c’est qu’ici, nous allons installer notre serveur VPN sur une machine quelconque, possédant un OS qui pourrait aussi bien faire tourner un serveur web, un traitement de texte ou Quake 3. Nous parlons alors de VPN logiciel (software).
C’est cette solution que nous avons retenu pour mettre en place notre VPN.
Et bien d’autres…
En effet, je suis loin de tous les connaitre, il doit exister un tas d’autres solutions. Je citerai par exemple Hamachi, très simple à mettre en œuvre et souvent utilisé par les joueurs qui veulent faire comme si ils étaient en Lan
. Ou encore des solutions L2TP+IPSec, plus compliquées à mettre en place, mais plus « standard » qu’une solution OpenVPN. En effet, OpenVPN parle un langage bien à lui, et il faut un client OpenVPN pour se connecter à un serveur OpenVPN. Avec des solutions L2TP+IPSec, votre réseau à plus de chance d’être « interopérable ». Un exemple bête, Windows, les iPhones, et les téléphones tournant sous Android supportent nativement ce genre de VPNs.
Une présentation de notre infrastructure
Je vais maintenant rapidement vous présenter notre petite infrastructure. Je dois l’avouer, si elle a vu le jour, c’est plus par challenge et par engouement pour le sujet que pour répondre à un réel besoin. Néanmoins aujourd’hui, nous aurions du mal à nous en passer, j’expliquerai à la fin l’utilité que j’en ai tous les jours.
Pour remettre les choses dans le contexte, nous disposons d’un serveur dédié (Grumpy), hébergé chez OVH, allumé 24h/24, avec une IP fixe. Donc lui, peut importe où l’on se trouve, à priori, il est toujours joignable (pour peu d’avoir une connexion Internet fonctionnelle
). Ensuite, nous disposons de nos routeurs respectifs (donc chez nous) :
- Moi (Sékoïa), mon routeur s’appelle Happy, c’est une board Soekris net4801 [4], sur laquelle je rédigerai certainement un billet plus tard
- Division-par-zero, son routeur s’appelle Sleepy, et c’est un vieux PC avec une distribution de Linux appelée IPCop [5], spécialisée dans le routage, firewalling.
Ceux sont eux (à quelques intermédiaires prêt), qui nous relis à l’Internet.
Hé bien ! Pourquoi ne pas connecter tout ce joyeux monde ? Voici donc un petit schéma pour éclaircir les esprits.
Voici donc l’infrastructure dans sa forme la plus simple, pas de VPN, rien. Le nuage représente le reste du monde, en gros l’Internet, Grumpy et nos routeurs respectifs y sont connectés, et nous avons nos réseau locaux respectifs, nommés pour l’occasion lan_happy et lan_sleepy. Jusqu’ici donc, rien d’exceptionnel, vous avez certainement une installation similaire chez vous, à l’aide du box quelconque.
Regardons maintenant le résultat si on crée une connexion VPN entre Happy et Grumpy, et une autre entre Sleepy et Grumpy:
Les deux routeurs sont maintenant connectés à Grumpy par un lien VPN. Il y a une adresse IP à chaque bout, et chacun peut communiquer avec Grumpy comme si ils y étaient reliés par un cable. Mais cette infrastructure a un défaut, Happy et Sleepy ne peuvent pas communiquer entre eux par le biais du VPN. Voici donc une modification de l’architecture afin de palier à ce problème:
Cette fois-ci, nous créons un pont (bridge) entre les deux interfaces du VPN sur Grumpy (tap0 et tap1 sur le schéma précédent). Si vous ne savez pas ce qu’est un pont, cela permet en gros de faire comme si les interfaces dans le pont étaient connectées à un même switch. Ici le pont s’appelle br0, et il contient tap0 et tap1. Un sous-réseau est alors créé (lan_vpn) et Happy et Sleepy peuvent communiquer
.
Une fois les tables de routage correctement configurées sur chacun des routeurs, toutes les machines du réseau lan_happy peuvent communiquer avec celles du réseau lan_sleepy et vice-versa !
Vous allez me dire, pourquoi Grumpy sert d’intermédiaire ici ? Happy et Sleepy pourraient très bien négocier leur lien VPN tout seuls ! C’est vrai, mais ce schéma a l’avantage d’être facilement extensible. Avant, un autre routeur nommé Sneeze (tiens dont !
) était lui aussi connecté au réseau lan_vpn, on comprend alors mieux l’intérêt d’avoir un point « central » de communication. Sneeze est maintenant déconnecté mais qui sait, peut-être qu’un jour un autre nain viendra rejoindre la famille.
Mais nous sommes allé plus loin ! En effet, nous voulions permettre à d’autres machines, n’ayant rien à voir avec ce schéma, de se connecter au réseau. C’est pourquoi nous avons mis en place un autre sous-réseau que voici :
Ce sous-réseau (lan_cert_vpn), permet à quiconque étant connecté, de pouvoir communiquer avec le reste du réseau VPN, c’est à dire toutes les machines des réseaux lan_happy et lan_sleepy. Pour se connecter, il suffit d’avoir un certificat valide (chaque client a un certificat différent). Nous pouvons donc ouvrir un accès à quiconque est connecté à l’Internet !
Vous aurez remarqué que pour l’occasion, Grumpy est devenu un routeur, il doit en effet router le trafic entre lan_cert_vpn et le reste du réseau.
Quelques cas pratiques d’utilisations
Car en effet, au delà de pouvoir dire « oui ! je l’ai fait
», ce réseau peut avoir une certaine utilité. En voici une liste non exhaustive, inspirée de mon utilisation quotidienne :
- Lorsque je suis à l’extérieur (par exemple au travail), je me connecte au vpn lan_cert_vpn et j’ai à tout moments accès à mon PC à mon domicile. Si celui-ci est éteint, je me connecte à Happy et je lance une requête wake on lan sur le réseau lan_happy et il s’allume tout seul
- Étant relié à Grumpy par un sous-réseau « privilégié », je peux me servir du serveur SMTP de celui-ci pour envoyer des mails. Le serveur SMTP est configuré pour ne pas accepter de transférer des mails arrivants de l’Internet, et dont la destination finale n’est pas lui-même. En gros, il ne peut donc que recevoir des mails. Cela est indispensable pour ne pas servir de relai de spam. Mais les machines connectées au VPN ont le droit de l’utiliser comme relai
. - Je peux jouer avec Division-par-zero à des jeux en réseau à peu près comme si on était en Lan Party. Pas exactement car nous ne sommes pas sur le même sous-réseau, donc les options du genre « rechercher les serveurs LAN » dans les jeux ne fonctionnent pas. Néanmoins, en spécifiant l’IP manuellement, pas de problème, et cela nous évite la tâche fastidieuse d’avoir à rediriger les ports sur nos routeurs respectifs.
- Nous pouvons aussi très facilement nous échanger des fichiers comme nos photos de vacances.
J’en oublie surement. Comme vous le voyez, cette infrastructure crée un véritable réseau local, mais virtuel
et surtout très sécurisé.
Et maintenant ?
Vous avez maintenant une vue d’ensemble de l’infrastructure mise en place. Dans ce billet, je ne suis volontairement pas rentré dans les détails. J’ai voulu resté très général, le but étant de montrer ce qu’il est possible de faire et les services offerts par une telle infrastructure.
Celle-ci n’est certainement pas parfaite, et il y a bien entendu d’autres moyens de faire. Le but était avant tout de le faire pour apprendre, et je suis aujourd’hui à même de vous faire partager ce que j’ai appris
. J’espère que ce billet vous donnera des idées. N’hésitez pas à les partager ensuite !
Références
[1] http://www.cisco.com [2] http://www.juniper.net [3] http://www.openvpn.net/index.php/open-source/overview.html [4] http://www.soekris.com/net4801.htm [5] http://sourceforge.net/apps/trac/ipcop/wiki
Sleepy, il fait dodo
Comme je n’ai pas beaucoup de temps ce matin, j’écris un petit billet qui n’a pas une grande importance, mais ça va introduire la notion du parc de nains
Qui est Sleepy ?
Sleepy, c’est à la base une firewall sous une distribution dédié, nommée IpCop ! Je l’utilise pour protéger tous mon réseau domestique, et depuis l’arrivé de Grumpy, ainsi que de son VPN (Sekoïa est en train de rédiger le billet sur le VPN), Sleepy est directement relié aux autres nains (Grumpy donc pour le moment) !
Que fait Sleepy ?
En théorie, comme expliqué plus haut, il relie mon réseau domestique situé dans mon petit village avec les autres nains !
Dans la pratique, il dort dans un coin de ma chambre là ! En effet, il va falloir que je le réveil un jour, mais des événements indépendants de ma volontés font que Sleepy dort (c’était même pas voulus quand j’ai choisis son nom :p) !
Backup avec lftp 4.x
LFTP is sophisticated ftp/http client, file transfer program supporting a number of network protocols.
Site officiel : http://lftp.yar.ru/
Sur mon poste précèdent je vous parlez des soucis que j’avais eu avec les backups, et le protocole FTP, dans ce billet je vais expliquer pourquoi et comment utiliser la version 4.x de lftp sur une debian stable (en effet la branche < 4.0.6 de lftp est en testing à l’heure de ce billet).
Pourquoi LFTP 4 ?
En plus de fait que c’est une version supérieur à la version 3, qui en toutes logique (pas toujours c’est vrai) apporte son lot de mise à jours, et de correction de bugs !
Là où j’ai eu un gros soucis c’est avec les noms des fichiers/dossiers qui commence par un tilde (~). Si on regarde le changelog de lftp, il suffit de faire une recherche sur le mot tilde pour trouver deux dates importantes :
Version 3.5.2 – 2006-07-28
- Fixed mirror for files starting with a tilde.
Version 4.0.1 – 2009-09-17
- Fixed handling of files starting with a tilde in ftp.
Il existe une correction des fichiers qui commencent par un tilde avec l’option mirror, pour la version 3.5.2, effectivement la version de lftp est supérieur à 3.5.2 en stable, et mes fichiers sont bien tout synchronisés, le problème c’est avec l’option –delete de lftp :
1 | lftp bm -e "mirror --delete /source /dest;exit;" |
Cette option à pour effet de supprimer de la destination, les fichiers qui n’existe plus dans la source, afin de faire un véritable miroir.
Et là j’avais une erreur à chaque fois sur mes fichiers commençants par un tilde.
J’ai donc tout de suite testé le problème avec une version de lftp > 4.0.1 sur ma Gentoo, ainsi que sur ma Arch, et je n’avais plus le message d’erreur !
La question suivante a été de savoir si je compilais une version statique de lftp 4.0.1+ pour Grumpy, ou si je trouvais une solution pour installer directement l’outil depuis aptitude dans sa version testing !!
Le problème étant les dépendances, compiler chaque dépendances pour ensuite compiler l’outil en statique ne me semble pas être la solution la plus pérenne ! J’ai donc choisis la solution qui consiste à garder un système en stable, avec quelques outils en testing, on parle ainsi de système mixte !
Installer LFTP 4.0.1+ (testing) sur une Debian stable !
Cela s’adapte à tous les paquets des Debians, pas uniquement pour lftp
Il faut modifier le fichier /etc/apt/apt.conf ou créer un nouveau fichier dans /etc/apt/apt.conf.d/.
Définir le système par défaut
/etc/apt/apt.conf.d/99mixed
APT::Default-Release "stable";
Indiquer où sont les paquets en testing
Dans votre fichier /etc/apt/sources.list, il va falloir dupliquer toutes les lignes qui commencent par deb, et qui contiennent le mot « stable » et/ou le nom de la distribution « etch, lenny, … », puis changer le mot stable par testing, sur les lignes dupliqués, ainsi que le nom de la distribution par le nom de la distribution testing actuel (voir http://packages.debian.org/testing/) !
/etc/apt/sources.list (exemple)
deb http://ftp.fr.debian.org/debian squeeze main testing
Dans cette exemple, lenny est la version stable, je rajoute les paquets de squeeze qui est la version testing actuelle !
La suite est plutôt simple, et doit être adapté suivant le gestionnaire de paquet que vous utilisez habituellement :
aptitude
aptitude -t testing install lftp
apt-get
apt-get -t testing install lftp
Note importante : on le vois écrit trop peu souvent, mais il est important de toujours utiliser le même outil aptitude ou apt-get pour installer des paquets, la différence ce ressent surtout quand vous avez besoin de faire de la place, la gestion des dépendances est pas faite de la même façons entre les outils.
Backup, la fin du monde
Backup : Mot anglais pour sauvegarde informatique. Consiste à copier des fichiers sur un support séparé.
Depuis plus d’un an, quand Grumpy a commencé à vraiment être sollicité pour des sites, j’ai mis en place un système de backup, en utilisant le service fourni par OVH, à savoir un FTP spécial, accessible uniquement par l’ip de Grumpy !
Chaque nuit grâce à une tâche Cron, le script de backup via lftp ce lançait
1 | lftp bck -e "mirror -nR --ignore-time $DIR_LOCAL $DIR_REMOTE;exit;" |
Je ne vais pas expliquer la commande, mais pour ceux qui sont intéressés et qui ne connaissent pas encore lftp, n’hésitez surtout pas à le découvrir (site officiel lftp). L’idée c’est de faire un miroir du répertoire local, vers un dossier en ligne ; pas d’incrémentation par contre !
Comme souvent dans les sauvegardes, tant que tout va bien, pas de soucis
Je reçois toutes les nuits un rapport et parfois il y as un ou deux fichiers en erreur, que je peux corriger rapidement ! Le système fonctionnais bien, même très très bien, plusieurs fois j’ai eux à récupérer des fichiers sur le backup, et aucun soucis !
Le drame c’est produit ce Samedi 7 juin 2010, alors que nous avions décidé avec Sekoïa d’agrandir la partition « / » de seulement 3 Gio, à une partition plus importante. J’ai forcé un backup manuellement, plus un backup de toutes les données possibles (y compris /tmp), on a reboot la machine en rescue on a backup les dernières données importantes (principalement /dev), l’idée était de ne pas avoir à faire une ré-installation !
Mais voila, vu mon style d’écriture au passé, il n’est pas difficile de comprendre que ça a foiré quelques part ! Et ce ne fut absolument pas à l’agrandissement, ça, ça c’est passé très bien, mais ensuite à la restauration du backup, après avoir mis 2h à restaurer « / », j’ai fièrement transmis le rapport à Sekoïa…
Total: 1560 directory, 19108 files, 0 symlinks
C’est là qu’on a percuté « 0 liens symboliques » dans les dossiers systèmes ; je serais bien surpris sous linux de ne trouver aucun liens symboliques dans « /etc » !!!
À ce point, plus trop le choix que de me maudire, mes superbes sauvegardes ne sauvegarde pas les liens, ce qui après coup est très logique puisque les liens symboliques ne font partie des capacités du protocole FTP.
Ce qui fait qu’en plus de perdre l’uptime de 347 jours, nous avons eux la bonne surprise d’avoir à ré-installer entièrement Grumpy ! Du coup maintenant il est sur une Debian toute neuve, et à deux on a pu remettre tous les systèmes avant le dimanche soir ! En particulier le serveur de courriel, le serveur web avec test de tous les sites, les bases de données, les /home/ des utilisateurs, avec les mots de passe anciens !
À la première vu les backups ont tous de même bien fonctionnés puisqu’on a pu tout récup’, c’est la configuration de base qui a du être à refaire, et ça à pris 1 journée de plus que prévu, mais comme c’était le week-end personnes ne c’est plaint !
À deuxième vu, c’etait un peu moins drôle… Quand j’ai mis en place les backups j’avais choisis volontairement de ne pas utiliser l’option –delete de lftp, elle permet de supprimer du répertoire distant les fichiers qui n’existe plus dans le répertoire locale… Ça peux sembler être une bonne idée quand on récupère les fichiers un par un, mais pas quand on fait une récupération complète !
Je me suis retrouvé avec 7000 courriels dans ma boite de réception, datant pour les plus anciens de plus d’un an auparavant !
Donc pas de perte, mais des bidules qui réapparaissent d’outre-tombe
Autant dire que je n’ai aucune fierté pour ce système de sauvegarde !
Dès le dimanche 8, j’ai mis en place le nouveau système de backup, son fonctionnement est relativement aussi complexe, mais les pertes d’informations liées aux protocoles FTP sont minimes voire inexistante, en effet, cela ce passe comme ceci :
- Création d’un fichier tarball par sous-dossier important de / (/var, /etc, …) placé dans le home du user qui gère le backup
- Création d’un fichier tarball avec uniquement les liens symboliques de tous les /home/*
- Miroir FTP de /home
Ainsi je ne perd plus les liens symboliques, même si l’astuce du tarball juste pour les symlinks des /home/ me semble trop proche de la bidouille, je n’ai pas trouvé d’autres solutions viable, car faire un tarball de chaque /home, sachant que le miens fait déjà 40Gio, ça va prendre du temps, et à ce niveau lftp ne fait plus sont office de ne charger que les fichiers nouveaux et modifiées, donc trèèès trèèès long !
La seule perte connue sont les owners sur les fichiers et les dossiers des /home, en effet FTP peux garder les permissions, mais pas les owners, ce qui, une fois qu’on le sait, n’est pas un problème, car les utilisateurs n’ont pas à changer le owner de leurs fichiers ainsi à la restauration il suffit de redonner les bonnes appartenances aux /home/ !
Où tout a commencé !
Voici venu le temps de la création de ce blog dédié à notre serveur dédié Grumpy !
Grumpy a booter hors des chaînes de construction de la société OVH le 16 juin 2008 à 19h 46min 46sec. Pour le plaisir de Sekoïa et Division-par-zero, qui ont pu ce faire une joie de le configurer, en tapant allégrement des commandes de tests :
hdparm -tT /dev/sda
...
Bon, je ne m’en souvient plus aujourd’hui, mais on s’est bien fait plaisir
Il faut savoir que Grumpy, est à base d’une Debian pure, légèrement modifiée pour coller à nos besoins, donc on commence direct par un :
Au passage, on note le choix d’aptitude plutôt que apt-get, puis c’est le début des installations simples mais efficaces :
Et paf en quelques secondes Grumpy est passé du statut de simple serveur dédié grincheux, à serveur de site Web encore plus grincheux
À noter qu’ils ne nous a jamais vraiment fait de reproche à ce qu’on le fasse bosser, en tout cas, on a pas vu d’aggravement dans son humeur grincheuse :-p
Depuis les services on évolués et c’est bien de cela que je souhaite parler sur ce blog !



