Conception d'un serveur privé - Page 1

Le topic de montreuillois tombe au moment où j'avais une question un peu liée à cela. J'ai décidé par défi de suivre un maximum de recommandations de Prism Break, et plusieurs éléments me poussent à l'idée de mettre en place un serveur privé, notamment bien sûr sur le contrôle de ses données.
Cependant, pas simplement transformer mon pc en serveur, mais utiliser une machine dédié avec une disponibilité maximale, maintenant que mon débit ADSL montant est intéressant pour cela.
Et je souhaite recueillir quelques avis pour cela.

Car on peut trouver de nombreux tutos et conseils sur la toile pour héberger son serveur, mais la première étape est rarement mise en avant, à savoir tout simplement choisir la machine qui fera serveur.
À parcourir un peu, j'ai découvert ArkOS pour le Raspberry Pi. Cependant, je pense à un serveur sur le long terme qui va héberger plusieurs services comme l'hébergement (à commencer par tous mes sites web plutôt que de continuer à louer des mutualisés), les mails, du cloud personnel (dont vidéos, musiques...), un pod Diaspora pour mes proches et peut-être à l'occasion des applications plus lourdes. Je ne sais pas si je peux miser sur un Raspberry pour supporter tout cela.

Je me suis penché sur Materiel.net sur des machines serveurs, cela semble plutôt dédié à un usage professionnel et sort de mon budget. Aussi peut-être un mini-pc à petit prix peu gourmand, peu bruyant et qui se place facilement à installer à côté de la box. Plus conséquent qu'un Raspberry, et suffisant pour les besoins sus-cités.
Pour le faire tourner après cela, une distrib Yunohost ou TurnKey (deux Debian custom). J'aimerai essayer quelque chose de simple et préinstallé, et non me prendre la tête une énième fois quand je dois configurer Apache pour une nouvelle machine.
Après quoi en dehors des DNS je pense y obtenir une relative indépendance.

Des avis sur les choix sur lesquels je me suis penché et/ou des conseils pour la suite ?

Ca recoupe un peu un autre topic sur les NAS...
Il y a deux points critiques : la disponibilité et la pérennité des données. C'est lié, mais pas totalement intriqué.
Au niveau disponibilité, ça pose un problème : ton réseau, chez toi, peut sauter, pour une raison ou pour une autre (défaillance de ton FAI, déménagement, défaillance d'un de tes matériels actifs, du serveur...).
Au niveau pérennité et fiabilité, ton serveur peut lâcher (disque(s), données corrompues, piratage...).
Du coup, si ça devient un système critique, tu vas devoir te farcir de la redondance. Et cette redondance va devoir se faire tant au niveau des données (si ça n'est que ça, tu peux imaginer encrypter toutes tes données et sauvegarder ces données cryptées/hashées chez un hébergeur classique) que de la disponibilité (là, il va falloir que tu réfléchisses à de la redondance de données et de service, avec deux solutions : la redondance est en lecture seule - solution facile - ou en lecture/écriture - là, il faut aussi penser à mettre en place des mécanismes de synchro bidirectionnels).
Rien de tout ça n'est indispensable. À l'heure actuelle, même si j'en suis arrivé à un point critique, j'arrive à vivre sans pendant une semaine (c'est ce qui s'est passé pendant mon déménagement). Plus, ça devient dangereux. Mais si tout brûle, j'avoue que c'est un peu la merde (je fais une sauvegarde manuellement tous les 6 mois qui est destinée à être délocalisée, mais 6 mois, c'est beaucoup).

Pour le reste, quasi tout peut-être hébergé par tes soins à condition d'avoir un serveur avec un minimum de puissance. Parce que c'est là que va vite se trouver la limite : un NAS classique est vite juste pour héberger tous les services dont on peut avoir besoin, même ponctuellement.
Cela dit, un Core i5 avec 4 Go de RAM est normalement largement suffisant (par contre, il vaut mieux se tourner vers les versions destinées aux portables, pour éviter qu'ils ne consomment trop pour rien).

Mais si tu es comme moi, tu vas aussi rencontrer un autre souci : tu auras un tel goût pour le délocalisé qu'avoir tes services accessibles de partout et à n'importe quelle heure que tu voudras avoir ton environnement de travail dispo de la même façon. Si tu es sous Linux, tu t'en sors assez facilement (avec VNC/X). Mais si tu es sous Windows, il va te falloir un Linux pour les services et Windows dans une VM, accessible à distance, pour le côté bureau.
Et là, c'est quand même un sacré pied... même sur ta tablette, à l'autre bout du monde, tu bosses dans ton environnement de travail (pour peu que tu aies une connexion correcte, quand même, mais ça passe même avec des débits très moyens).

Sinon, tu peux aussi avoir un serveur DNS sur ton serveur, hein... comme ça, seul toi saura quelles requêtes DNS tu as demandé...

Ca serait pas mieux dans les catégories informatiques ?

Nil > je ne saisis pas bien l'intérêt de sauvegarder les hash de tes données

J'ai lu un certain nombre de mentions d'ownCloud.

flan > euh oui, autant pour moi, tu peux supprimer ce mot-là, j'étais dans autre chose au boulot (avec des hash, justement, ce qui explique probablement cela )

J'attends le jour où sur Linux on aura l'équivalent de l'application serveur dispo sur OS X (et avec une gestion de certificats qui fonctionne, si possible ). Je suis sûr que ça aurait pas mal de succès ^^

Sinon, très sérieusement, le fait d'avoir une machine sur laquelle tournent plusieurs VM résout beaucoup de problèmes... une VM windows, une VM avec le DSM de Synology et une VM avec un Linux en complément...

Perso, je bosse sur un système de réinstallation automatique. Dans un fichier de conf', on décrit les paramètres du réseau et le stockage des documents (comme le nom de domaine, les adresses IP/MAC des machines, les comptes utilisateurs, quel service sur quelle machine, etc.), et ça réinstalle tous les services nécessaires sur les machines en question (quitte à réinstaller les machines une fois qu'il y a un serveur DHCP). Le but, c'est de sauvegarder uniquement les documents, et de réinstaller tout le reste plutôt que de sauvegarder des images du système.

C'est peu ou prou ce qu'on a adopté au boulot pour la virtualisation des postes de travail : les postes en question sont virtualisés, et il y a un snapshot stable qui est rechargé intégralement au lancement. Les documents et paramètres applicatifs sont respectivement dans un dossier réseau et dans le profil itinérant.

non, justement, le but est de ne pas avoir de snapshot qui possède la configuration. L'équivalent serait de réinstaller et de reconfigurer la machine automatiquement, comme ce que permettent Puppet/Salt/Chef/...

Ah ok, je vois... mais c'est un peu lent au démarrage, du coup, non ?

Nil (./12) :
Ah ok, je vois... mais c'est un peu lent au démarrage, du coup, non ?

tu ne le fais pas tous les jours uniquement quand ça crashe.
par contre, puppet/salt/.../ vérifie que l'état reste identique (liste des paquets installés, fichiers de configuration qui ne bougent pas, etc..)

Ce n'est pas du tout la même problématique ceci dit.

Dans le cadre de serveurs, utiliser un snapshot est souvent une mauvaise idée si ce n'est pas dans un cadre très limité : rapidement tu vas en avoir plusieurs à maintenir, car il est rare que toutes tes applications supportent (ou simplement soient validées) avec le même jeu de fonctionnalités.

Pour limiter la prolifération des snapshots, il est possible de ne faire un snapshot que minimaliste, avec seulement le dénominateur commun. Mais dans ce cas, tu dois réinstaller tout le reste. Retour à la case départ.

De toutes façons, même si ton installation automatisée avec puppet ou équivalent te prenais, disons, 10h, ça resterait négligeable par rapport au temps d'approvisionnement habituel dans un contexte professionnel (validation de projet, budget, commande, etc)

Néanmoins, l'exemple de Nil n'est pas des serveurs, mais des postes de travail à durée de vie éphémère, qui sont, je suppose, créés à partir d'un modèle à l'ouverture de la session et détruits au logout. Dans ce cas, passser par des heures d'installation n'aurait pas de sens, et le principal inconvénient des snapshots ne s'applique pas aux postes de travail ^^

spectras (./14) :
De toutes façons, même si ton installation automatisée avec puppet ou équivalent te prenais, disons, 10h, ça resterait négligeable par rapport au temps d'approvisionnement habituel dans un contexte professionnel (validation de projet, budget, commande, etc)

D'autant que ça ne nécessite pas d'intervention humaine

spectras (./14) :
Néanmoins, l'exemple de Nil n'est pas des serveurs, mais des postes de travail à durée de vie éphémère, qui sont, je suppose, créés à partir d'un modèle à l'ouverture de la session et détruits au logout. Dans ce cas, passser par des heures d'installation n'aurait pas de sens, et le principal inconvénient des snapshots ne s'applique pas aux postes de travail ^^

En fait, on a un fonctionnement particulier : tous nos postes de travail virtuels (qui sont une minorité, la plupart des postes sont - ou sont voués à devenir - des clients légers qui ramènent un TSE) sont créés à partir d'un snapshot initial. Mais ce snapshot évolue ensuite de façon indépendante (essentiellement à cause de problèmes de licences pour des applications qu'on ne peut déployer que sur un seul poste). Du coup, le snapshot évolue avec le temps, mais uniquement lors des installations d'applications par les administrateurs (en réalité, il n'y en a qu'un qui soit autorisé à installer PUIS à faire un instantané ; je peux installer ce que je veux sur un poste virtualisé mais, au démarrage suivant, ça ressortira le snapshot précédent).