Il y a environ deux mois, j'avais posté une question sur le forum linuxfr pour monter un serveur personnel…
Après plusieurs essais, je pense avoir trouvé une solution assez simple et économique. Pour rappel, les conditions sine qua non étaient:
- 100% Compatible Debian Linux
- Fanless
- Basse consomation (e.g ARM)
- Prise ethernet.
- Pas de micrologiciels binaires.
Et idéalement:
- Compatible RAID logiciel, soit sur carte SD, soit sur mini disque dur 2"5
- Debian Linux préinstallé
- Bluetooth
- Bon marché.
Aujourd'hui, je voudrais vous faire gracieusement profiter de ma solution, toute bête et pas chère, avec même d'autres avantages, comme nous verrons plus loin.
La solution la plus satisfaisante semblait être un boitier NAS avec le micrologiciel modifié, avec une Debian bootstrap.
Mais cette solution a un gros désavantage: Si un jour je veux changer de boitier, il n'est pas possible de simplement prendre les disques, et les mettre dans un autre boitier. La partition de boot système est stockée dans le micrologiciel du constructeur, et je devrais à nouveau flasher le boitier, en espérant trouver le même modèle.
Je me suis finalement orienté vers un ordinateur portable, en changeant le lecteur CD par un second disque dur, en RAID logiciel. Il y a plusieurs avantages:
- Je ne suis plus limité dans la taille de la partition de boot.
- Je n'ai pas besoin d'utiliser un noyau spécial, le dernier noyau Debian générique suffit à faire démarrer la bête.
- En cas de coupure de courant, je peux tenir entre une et deux heures.
- Comme sur un serveur pro, je peux remplacer l'alimentation « à chaud ».
- Le jour ou mon ordi me lache, je peux simplement mettre les disques durs dans un autre ordinateur portable.
- J'ai une connexion réseau de secours intégrée (wifi)
- Beaucoup plus modulaire qu'un boitier NAS, plus de sorties USB, entrées PCMCIA (ou plus récent, je peux ajouter une carte réseau supplémentaire ou une carte eSATA ou USB3)
- J'ai une liste de paquets disponibles plus importante, et je peux mettre à jour mon système normalement, avec apt-get. Aujourd'hui je l'utilse comme serveur web, mpd, owncloud, etc…
- Avec l'expérience, j'ai l'impression que les composants d'ordinateurs portables sont moins fragiles que les composants de PC traditionnels. J'ai utilisé un vieux laptop toshiba comme serveur MPD pendant dix ans.
- Il y a un écran et un clavier intégré, si besoin.
- Le firewall est très puissant, je peux par exemple utiliser les extensions GeoIP d'iptables pour ne laisser passer que quelques pays utiliser mon serveur web.
A part le ventilo qui se met parfois en route (très rarement), je n'ai trouvé aucun inconvénient. La consommation électrique est peut être un peu plus importante qu'un boitier NAS, mais reste en dessous d'un boitier micro serveur. Il faut que je vérifie mes tâches cron pour trouver ce qui déclenche parfois le ventilo, mais j'ai une pléthore de solutions.
Donc pour résumer, voici la procédure, toute simple:
- Installer Linux sur un laptop, en utilisant le lecteur CD interne. Choisir l'option LVM et RAID logiciel, même si vous n'avez qu'un seul disque.
- Une fois installé, éteindre votre portable, et remplacer le lecteur CD/DVD par un second disque dur.
- Une fois allumé Linux reconstruit la seconde partition en tâche de fond.
- Refermez le portable, l'écran s'éteint et ne consomme rien.
Si cela vous intéresse, je précise que j'ai également un boitier NAS de 2Tb pour le gros stockage.
Quelques liens:
- Boitier pour second disque dur, £20: http://bit.ly/1dDKfn3
- Second disque dur SATA 80G £15, http://amzn.to/1dDKHSf
- Portable HP Compaq: Je l'ai eu gratuitement, mais on en trouve pour £60
Soit, environ £100 ou environ 120€ pour un serveur personnel simple. En augmentant le budget, vous devriez avoir plus de puissance et de stockage, si nécessaire.
Voilà, j'attends vos remarques.
# Merci
Posté par NeoX . Évalué à 4. Dernière modification le 23 mars 2014 à 17:53.
merci de ce retour instructif.
tu as pu mesurer la consommation de ce "NAS" maison ?
[^] # Re: Merci
Posté par André Rodier . Évalué à 2.
Non pas vraiment.
Je ne suis pas certain que ce soit régulier non plus.
Cela dit, je n'ai pas trouvé de service externe qui me donne autant de contrôle, c'est la raison pour laquelle j'ai décidé d'utiliser mon propre serveur.
[^] # Re: Merci
Posté par oinkoink_daotter . Évalué à 5.
Si c'est un laptop, c'est une info qui est souvent remontée en ACPI et trouvable dans /proc. Chargeur débranché par contre.
# discrimination sur les pays
Posté par karchnu . Évalué à 6.
Tout d'abord, bravo à toi pour avoir fait ce pas ; monter son serveur (avec les mails et tout et tout) ça va dans le sens de la décentralisation, et c'est réellement une bonne chose. Petit bémol cependant:
Le firewall est très puissant, je peux par exemple utiliser les extensions GeoIP d'iptables pour ne laisser passer que quelques pays utiliser mon serveur web.
Je n'aime pas ça. Ça veut clairement dire que ton serveur sera accessible qu'à X endroits sur la planète, pas pour les autres. Que tu cherches à protéger ton serveur se comprend, qu'on commence à discriminer les pays c'en est une autre.
Bien entendu, tu restes seul maître à bord, mais éthiquement ça me gène (et ça ne regarde que moi ;) ).
Bonne continuation.
[^] # Re: discrimination sur les pays
Posté par Frank-N-Furter . Évalué à -7.
Foutaises.
Depending on the time of day, the French go either way.
[^] # Re: discrimination sur les pays
Posté par André Rodier . Évalué à 4.
En fait, c'est une question de bande passante, je n'ai pas vraiment le choix.
Malheureusement, si je ne le fait pas, 90% des requêtes que je reçois sont des tentatives d'exploitation de failles phpmyadmin / joomla / wordpress / … à partir de pays comme la chine.
Cela me bouffe autant ma bande passante que l'énergie électrique, sans parler de la pérennité du serveur qui en prends un coup.
Une autre solution serait d'utiliser fail2ban, mais ce sera sur du plus long terme, et vu la quantité c'est plutôt inefficace.
Le fait est que j'héberge un site pour une amie, qui offre des services au nord de Londres. Donc, les port 80 et 443 ne sont pour l'instant accessible que depuis la France et l'Angleterre.
Voilà.
[^] # L'Antifrance ne passera pas
Posté par AgentSteel (site web personnel) . Évalué à 4.
Je fais pareil sur mon serveur. Ca diminue quand même bien la surface d'attaque (web). Tant pis pour le "nous sommes tous frères, c'est pas gentil gnagnagna" :)
[^] # Re: L'Antifrance ne passera pas
Posté par anaseto . Évalué à 4. Dernière modification le 23 mars 2014 à 22:08.
En moins radical, sur mon serveur, j'ai un script qui recherche périodiquement des pétitions typiques d'attaques dans les logs qui n'auraient aucune raison d'être faites, et je bannis que ces IPs là, du moins temporairement. Je fais pareil pour les bots qui respectent pas le robots.txt. L'avantage c'est que quelqu'un qui utilise le site en toute normalité ne sera pas banni à moins de partager la même IP qu'un attaquant bien sûr, ou à moins de l'avoir bien cherché :)
Et cette méthode est d'expérience suffisante pour arrêter à peu près toutes les attaques qui prennent de la bande passante sur un serveur maison.
[^] # Re: L'Antifrance ne passera pas
Posté par barmic . Évalué à 8.
Ton script tu l'aurais pas appelé fail2ban ?
Sinon portsentry peut être pas mal.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: L'Antifrance ne passera pas
Posté par anaseto . Évalué à 1. Dernière modification le 24 mars 2014 à 08:35.
En fait, à l'époque je savais pas que fail2ban existait (je savais pas grand chose tout court), et maintenant comme c'est suffisant pour mes besoins, j'ai pas creusé plus la question.
Et puis c'était pas totalement précis ce que j'ai dit : quand des requêtes bizarres sont faites, je collecte les IPs direct depuis le serveur web avec dancer (qui n'est pas root), et je les envoie dans un fichier, qui lui est lu périodiquement pour bannir les IPs collectées. Pour ce qui est de lire les logs périodiquement je l'utilise surtout pour rechercher les tentatives de ssh.
Donc, oui, c'est du pas très professionnel, et construit en fonction de ce que je voyais dans les logs : faudra que je regarde du côté de fail2ban un de ces jours :)
[^] # Re: L'Antifrance ne passera pas
Posté par anaseto . Évalué à 1.
Et aussi les tentatives de relay pour le serveur mail.
Mais sinon, c'est vrai que ça marche assez bien.
[^] # Re: L'Antifrance ne passera pas
Posté par neil . Évalué à 4. Dernière modification le 24 mars 2014 à 17:00.
Autant se faire une règle pf pour ça (ou iptables/denyhosts sous Linux).
[^] # Re: discrimination sur les pays
Posté par flan (site web personnel) . Évalué à 1.
J'ai du mal à comprendre ce qui te gêne.
[^] # Re: discrimination sur les pays
Posté par Zylabon . Évalué à 6.
Met toi à la place des gens de bonne foi qui se retrouvent blacklisté… L'internet ouvert et neutre en prendrait un vilain coup si tout le monde faisait ça.
Please do not feed the trolls
[^] # Re: discrimination sur les pays
Posté par Maclag . Évalué à 10.
Ben perso j'habite en Chine et je ne pratique pas les attaques contre les services. Je ne crois pas avoir besoin d'élaborer plus loin.
Peut-être que les services sont au nord de Londres et donc je n'en aurai pas besoin même si je passe par Londres un jour. Enfin vu que je ne suis pas aller voir de quoi il s'agit de toute façon…
# Le ventilateur
Posté par Martin Peres (site web personnel) . Évalué à 3.
Pas bête le coup du laptop :)
Par contre, ça sert à rien que tu cherches un tâche cron pour le ventilateur. Si tu veux pas qu'il ventile, faut que tu évites de faire chauffer ton laptop. C'est aussi bête que ça.
Tu peux tester de le mettre en position verticale, la convection naturelle devrait aider. Cela dit, je doute que ça soit suffisant pour compenser toute la consommation. Tu devrais essayer de faire la chasse aux Watts. Tu pourrais aussi avoir besoin d'un serveur X pour pouvoir avoir une consommation plus faible. Si c'est une carte graphique NVIDIA, faut pas utiliser Nouveau.
[^] # Re: Le ventilateur
Posté par Victor . Évalué à 5.
Est-ce que tu peux expliquer cette phrase ?
"Tu pourrais aussi avoir besoin d'un serveur X pour pouvoir avoir une consommation plus faible"
J'ai du mal à capter pourquoi utiliser X réduirait la consommation, j'imagine qu'il y a un lien avec les pilotes graphiques qui ont des mécanismes pour diminuer la conso mais c'est pas très clair pour moi là… j'aurais cru que ne pas utiliser X suffit à ne pas utiliser la carte graphique.
[^] # Re: Le ventilateur
Posté par Martin Peres (site web personnel) . Évalué à 10.
Tant que les pilotes graphiques ne sont pas lancés, la carte graphique se trouve dans l'état dans lequel le bios l'a laissé. Pour réduire la consommation, il faut lancer un pilote qui activera le clock/power gating et diminuera la tension d'alimentation de la carte. Ça peut économiser facile 5W sur un laptop.
Dans le cas d'un pilote propriétaire, celui-ci est rarement lancé tant qu'il n'y a pas de serveur X. Du coup, conso plus haute.
C'est plus clair?
[^] # Re: Le ventilateur
Posté par Victor . Évalué à 2.
Yep, merci :)
[^] # Re: Le ventilateur
Posté par navaati . Évalué à 4.
Et sinon ya pas moyen d'éteindre carrément la carte graphique (genre, au niveau du bus pci-e) ?
[^] # Re: Le ventilateur
Posté par karteum59 . Évalué à 2. Dernière modification le 25 mars 2014 à 10:07.
ça m'intéresse aussi: y'a pas moyen d'envoyer les commandes qui-vont-bien en CLI (e.g. ACPI) plutôt que de lancer un serveur X ? Autre question: KMS ne fait pas déjà le boulot que tu décris ?
Par ailleurs: que se passe t-il si on lance un serveur X dans un script, et que l'on ferme ce dernier ? (je présume que la carte graphique restera dans l'état où le serveur X l'a laissée ?)
[^] # Re: Le ventilateur
Posté par Martin Peres (site web personnel) . Évalué à 3.
Faut regarder du coté de switcheroo. Je sais pas si toutes les cartes mères sont supportées, mais ça peut aider
# Mise en veille
Posté par Snark . Évalué à 1.
C'est intéressant, mais il faut quand même penser à régler l'appareil pour ne pas se mettre en veille quand on le ferme.
D'ailleurs, j'ai un portable qui se met en veille quand on n'est pas devant même quand on le laisse ouvert et c'est bien pénible: je lui demande des choses à distance, et d'un seul coup il ne répond plus…
[^] # Re: Mise en veille
Posté par bobo38 . Évalué à 2.
oui il faut y penser…
# x86 vs Arm
Posté par Sygne (site web personnel) . Évalué à 7.
Moi aussi je réfléchis à l'installation d'un serveur personnel, et j'en suis venu à la même conclusion que toi, à savoir qu'une architecture x86 est peut-être bien plus pertinente qu'une architecture arm. Et ce, pour plusieurs raisons:
Les interfaces: il est difficile de trouver une carte arm avec plusieurs ports sata,
et si on veut en outre un minimum de connectique, cela devient vite très cher.
Le support à long terme: je doute que dans quelques années, il y ait encore des personnes de bonne volonté pour mettre à jour l'os d'une carte arm qui n'est plus commercialisée. Je ne serais pas étonné que ces cartes restent confinées à une version spécifique du noyau et du boot-loader.
La consommation: x86 fait des progrès, et sur le papier, on trouve des processeurs x86 qui consomment aussi peu que les processeurs arm.
L'uniformisation: n'avoir qu'une architecture à gérer, c'est tout de même plus simple.
[^] # Re: x86 vs Arm
Posté par Babelouest (site web personnel) . Évalué à 1.
Si le but est de faire un serveur maison, pourquoi une machine ARM ne suffirait pas ?
il y a des nanos libres qui ont aussi un port SATA. Sinon on peut aussi brancher sur le réseau un NAS monté en NFS.
Pourquoi préférer l'architecture x86 dans ce cas ? (c'est une vraie question)
[^] # Re: x86 vs Arm
Posté par zebra3 . Évalué à 4.
Niveau matos, cette page du wiki Debian est intéressante et c'est moins cher qu'un portable.
Je pense acquérir d'ailleurs une Wandboard Quad prochainement, même si je ne connais pas du tout ARM.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: x86 vs Arm
Posté par Sygne (site web personnel) . Évalué à 3.
Pour faire un serveur de fichiers justement, car les cartes ARM avec plusieurs ports sata ne sont pas légion, et les astuces à base de multiplexeur de ports usb alimentés ne me semblent pas très convaincantes.
Dans mon cas particulier, j'aimerais en outre partager des exécutables entre le serveur et les clients. Il est vrai que rien n'empêche le serveur d'avoir un répertoire contenant les exécutables correspondant à l'architecture des clients, mais j'aimerais éviter.
Enfin, je ne sais pas comment juger des perspectives de support à long terme des cartes arm. J'ai l'impression que souvent celles-ci sont fournies par leurs fabricants avec des patchs pour le noyau et le boot loader. Qu'en sera-t-il dans cinq ou dix ans? Je n'en sais rien. Quant au X86, je suis à peu près certain que le support s'améliorera avec le temps.
[^] # Re: x86 vs Arm
Posté par Grégory Soutadé (site web personnel) . Évalué à 1.
Mon SheevaPlug tourne depuis 3 ans et demi avec une Debian vanilla (le bootloader on ne le touche pas et le noyau est celui de Debian stable (3.2.0-4)). Pour les cartes nues et/ou moins populaires, le support à long terme est peut être plus aléatoire.
[^] # Re: x86 vs Arm
Posté par AgentSteel (site web personnel) . Évalué à 2.
C'est quand même un poil moins pénible d'intervenir sur un PC x86 standard que sur un plug headless, en cas de problème de boot par exemple (j'ai du seagate dockstar pour ma part)
[^] # Re: x86 vs Arm
Posté par Grégory Soutadé (site web personnel) . Évalué à 1.
C'est exact. En cas de problème au démarrage, il y a un lien série (via micro-USB) sur le Sheeva, mais ce n'est pas forcément le cas sur toutes, et puis ça nécessite un PC à côté.
D'un autre côté, pour avoir un problème au démarrage, il faut … redémarrer. C'est soit après une coupure d'électricité, soit après une MAJ noyau, donc peu fréquent sur une Debian stable.
[^] # Re: x86 vs Arm
Posté par karteum59 . Évalué à 3. Dernière modification le 25 mars 2014 à 01:29.
Bah il me semble que plein de raisons sont justement données dans le post juste au dessus auquel tu réponds: le support à long terme est pour moi une très bonne raison d'éviter ARM (que j'apprécie beaucoup par ailleurs). Comme tu le sais (ou pas), le matériel ARM n'est pas capable de s'introspecter, contrairement au x86 avec l'ACPI. Sur ARM, la description des composants se fait soit avec un support explicite de ton SoC+carte-mère dans le noyau (d'où pb de support à long terme), soit avec le device-tree. La 2ème solution est plus pérenne, mais tu l'as quand même dans l'os si tu récupères un jour une carte ARM vierge sans réussir à trouver le .dtb correspondant sur le net (< ma_vie >j'ai un Novo7 Advanced II brické, et j'ai bien du mal à retrouver le kernel et le .fex correspondant sur le net pour tenter de debricker le bousin< /ma_vie >)
Pire: de nombreux fabricants de chipsets (notamment asiatiques, notamment (au hasard)… Rockchip et Mediatek) refusent fréquemment de se conformer à la GPL et de livrer les sources du kernel pour leur SoC.
Avec du x86, tu prends la distro que tu veux, et tu es à peu près sûr que ça boote et que ça marche du premier coup (et que ce sera toujours le cas dans 5 ans). Alors qu'avec ARM…
[^] # Re: x86 vs Arm
Posté par karteum59 . Évalué à 7. Dernière modification le 25 mars 2014 à 02:09.
…et accessoirement, on trouve énormément de vieux laptops sur le marché de l'occasion (parfois avec un écran ou une carte graphique cassée) qui ne demandent qu'à continuer leur vie en tant que serveur plutôt que d'être jeté à la benne pendant que d'autres personnes achètent de nouvelles machines (ARM ou pas) pensant faire du bien à la planète en prenant des cartes basse consommation (alors que c'est le process de fabrication qui consomme le plus). J'ai récemment acheté sur leboncoin un Lenovo x200 (CPU Core 2 P8600, 2 Go RAM, 160 Go disque dur, GPU X4500, etc.) pour 100 € ! (le clavier était UK, mais je m'en fous). A moins d'avoir un besoin spécifique (e.g. les GPIO sur une carte Raspberry Pi), pourquoi acheter une carte ARM si c'est "juste" pour faire serveur alors qu'on trouve de telles machines en occasion ? (et encore, mon exemple de x200 est un très bon desktop mais serait franchement surdimensionné pour un serveur. On trouve des machines parfaitement aptes à faire serveur pour moins de 50 € !)
# PlugComputers
Posté par Grégory Soutadé (site web personnel) . Évalué à 1.
Un NAS, c'est l'équivalent d'un PlugComputer (SheevaPlug, dreamplug, cubox, cubox-i…) avec un pool de disques (+ éventuellement du RAID matériel).
Ces ordinateurs-prise ont tous les avantages que tu cites (sauf peut être le bon marché) sans les inconvénients d'un laptop (encombrant, consomme donc chauffe) et tu peux facilement exporter tout ou partie du système avec rsync/cp/ftp/nfs (excepté le bootloader qui est spécifique à la machine) via une carte SD/clé USB et le réimporter sur un système compatible. De plus, la puissance de calcul est largement suffisante pour un serveur de mail et supporte même d'autres services (ssh, web, forge, musique…).
Cerise sur le gâteau : tu peux faire du LVM/RAID en connectant des disques plus importants soit en direct, soit via un hub.
Je trouve dommage d'utiliser de grosses machines énergivores (hormis recyclage) alors qu'on peut faire la même chose avec ce genre de bestioles !
[^] # Re: PlugComputers
Posté par Grégory Soutadé (site web personnel) . Évalué à 1.
Problème de rafraîchissement, je n'avais pas vu les derniers messages, désolé.
[^] # Re: PlugComputers
Posté par barmic . Évalué à 1.
La plupart des NAS m'ont l'air vachement fermés, non ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.