Bonjour à tous,
En bon nostalgique, je regrette l'époque (que je n'ai pas connue) de l'architecture unité centrale / terminal. J'y vois plusieurs avantages:
- une seule machine à administrer,
- les données sont centralisées (ce qui simplifie la gestion des sauvegardes),
- l'environnement de travail se retrouve d'un terminal à l'autre.
- les terminaux n'ont pas besoin de puissance de calcul.
Aujourd'hui on pourrait imaginer que les terminaux, constitués de portables et autres mini-ordinateurs n'aient en local qu'un boot loader évolué (voire une distribution hyper minimaliste), qui irait chercher dans l'unité centrale son noyau, l'arborescence de répertoires, et la configuration qui convient, pour offrir à l'utilisateur son environnement de travail (et profiterait du shutdown pour se mettre à jour s'il se trouve qu'elle héberge plus qu'un simple boot-loader).
On pourrait même penser qu'une simple commande permettrait à l'utilisateur de synchroniser son portable avec l'unité centrale pour pouvoir utiliser celui-ci en déplacement (chez moi, les portables servent le plus souvent à passer du salon au bureau, mais pas seulement). De même une simple commande pourrait permettre donner le choix d'utiliser la puissance de calcul locale ou distante.
Enfin, si plutôt que d'utiliser des cables tout ceci pouvait se faire via le wifi, ce serait encore plus pratique.
Je sais que plan9 propose une telle architecture distribuée, et c'est magique tellement ça fonctionne bien. Mais à part nous permettre de jouer avec cette architecture, plan9 n'a pas beaucoup d'avantages. Est-ce qu'il existe des façons de faire ce genre de choses simplement sur linux et bsd?
Merci d'avance pour vos pistes d'explorations.
# Cloud
Posté par GaMa (site web personnel) . Évalué à 6.
Et le cloud, c'est quoi pour toi ?
Gmail, Facebook, dropbox ?
FirefoxOS, ChromeOS ?
Matthieu Gautier|irc:starmad
[^] # Re: Cloud
Posté par paulez (site web personnel) . Évalué à 3.
D'ailleurs il y a ça dans le cloud http://aws.amazon.com/fr/workspaces/.
[^] # Re: Cloud
Posté par Sygne (site web personnel) . Évalué à 4.
« L'utilisation de clients lourd pour accéder à ses données mises en réseau en échange de leur exploitation commerciale et politique. »
J'ai gagné quelque chose ?
Au cas où ce n'était pas une blague, je rappelle que ce ne sont pas seulement les données mais aussi les utilitaires que j'entends mettre sur serveur. Si tu m'expliques comment le cloud répond à mon problème pour les trois exécutables indispensables que sont bash, openbox, et firefox, je suis prêt à y réfléchir.
[^] # Re: Cloud
Posté par GaMa (site web personnel) . Évalué à 1.
Ça c'est un problème de politique (commerciale). C'est un choix volontaire. En soit, la technique du cloud n'impose pas que tes données soient exploitées commercialement.
Mais la main au porte monnaies et tu verras que tes données seront vachement moins exploitées.
C'était pas vraiment une blague non.
Je pense que le cloud est tous simplement devenu la nouvelle archie client/serveur de notre époque. Nos ordinateurs étant plus puissant qu'à l'époque, ils font tout simplement plus de choses. Mais fondamentalement, c'est la même chose.
Avant on avait un terminal qui ne gérait que l'input/output utilisateur.
Aujourd'hui on à des ordi plus puissant et complexe, mais du point de vu du cloud on a globalement la même chose:
Dans l'idée du cloud, te ne maintient jamais les serveur de google, amazon, facebook, skype ou dropbox. Tu peux aller sur n'importe quel ordi équipé d'un navigateur web, tu rentres trois mots de passe et tu retrouves toutes tes données. Et pas que tes données, tu peux aussi en créer, tu peux envoyer des mails ou pocker tes amis.
C'est différent, mais c'est juste la même chose un niveau au dessus.
Ce journal c'est fait pourrir car il a dit que le web était en OS. Mais en dehors de l'erreur sémantique c'est pas faux. Toutes les fonctionnalités sont de plus en plus déportées vers les nuages comme, à une époque, les fonctionnalité étaient sur le serveur et le client ne faisait pas grand chose.
Matthieu Gautier|irc:starmad
[^] # Re: Cloud
Posté par Sygne (site web personnel) . Évalué à 1.
Non, ça n'a rien à voir, et ton post est hors sujet. Je demande comment n'avoir qu'une machine à administrer pour plusieurs terminaux légers, tu me parles de clients lourds, ayant chacun leur système d'exploitation, et ayant besoin d'un navigateur web pour accéder aux données évaporées et faire tourner des appli javascript qui ne font pas le quart de ce que font les logiciels dont j'ai besoin.
Ou alors tu m'expliques comment le cloud répond à mon problème pour les trois applications déjà proposées en exemple: bash, openbox, firefox.
[^] # Re: Cloud
Posté par GaMa (site web personnel) . Évalué à 6.
Dans ton post d'origine je lis :
À aucun moment je lis des truc du genre :
Comment je fais pour savoir que tu as un problème ? Comment je fais pour savoir que ton problème c'est de faire tourner des applis lourdes sur des serveurs distants ?
Pour avoir une réponse à une question précise, le mieux c'est de la poser. Tourner autour du pot, ça peut donner des pistes mais te seras gentils de ne pas reprocher aux autres de répondre à la mauvaise question.
Maintenant, pour répondre à ta question : Ta fais comme il y a 20 ans.
Matthieu Gautier|irc:starmad
[^] # Re: Cloud
Posté par Sygne (site web personnel) . Évalué à 2.
C'est bien ce que je me disais: c'était mieux à vent.
PS:
Excuse-moi si j'ai pu paraître offensant. Dans mon esprit, « une seule machine à administrer », « les données sont centralisées », « l'environnement de travail se retrouve d'un terminal à l'autre », « les terminaux n'ont pas besoin de puissance de calcul », « un boot loader évolué qui irait chercher dans l'unité centrale son noyau », « une simple commande pourrait permettre donner le choix d'utiliser la puissance de calcul locale ou distante » et « plan9 propose une telle architecture distribuée », orientait tellement les « pistes d'exploration » demandées hors des chemins du cloud, que je ne comprenais pas pourquoi tu insistais.
Je comprends mieux maintenant.
# LTSP avec ou sans le fat-client
Posté par NeoX . Évalué à 6.
LTSP installé sur un "serveur"
permet à un PC sans disque dur de booter au travers du reseau et d'aller chercher son OS et ses fichiers sur le serveur.
il utilise alors la puissance distante pour les logiciels.
neanmoins il est possible de lui passer une option (manuellement ou automatiquement) pour utiliser les ressources locales (option fat-client)
le mode automatique permet de preciser certains criteres comme la quantité de ram par exemple.
le projet LTSP sert aussi de base de depart au projet ABULEDU il me semble.
[^] # Re: LTSP avec ou sans le fat-client
Posté par Sygne (site web personnel) . Évalué à 2.
Merci, LTSP a l'air d'être exactement ce que je cherche. Tu l'as utilisé un peu ? Tu en penses quoi ?
[^] # Re: LTSP avec ou sans le fat-client
Posté par NeoX . Évalué à 2.
je l'ai utilisé entre 2000 et 2002 pour permettre aux personnels au stock d'utiliser l'appli maison sur des machines trop vieilles pour l'appli mais parfaite pour faire un terminal graphique.
depuis j'ai jamais mis en place en prod,
juste quelques maquettes
[^] # Re: LTSP avec ou sans le fat-client
Posté par Sygne (site web personnel) . Évalué à 2.
Effectivement, ça a dû beaucoup évoluer depuis 2002.
Grâce au mot clé lstp, j'ai pu trouver un simili équivalent pour netbsd. Tout ça me semble très bon…
[^] # Re: LTSP avec ou sans le fat-client
Posté par NeoX . Évalué à 3.
apres si tu veux juste faire du "bureau a distance", le protocole à l'epoque c'etait XDMCP.
en gros il te faut juste un OS de base pour gerer la machine cliente (LTSP le gere via DHCP/PXE/NFS)
puis le gestionnaire de login se branche sur le serveur XDMCP qui va ensuite faire tourner les applis.
en reseau local y a pas besoin de plus, meme en terme de securité
par contre si tu veux exposer le service de bureau à distance sur internet, faut prevoir d'autres solutions.
[^] # Re: LTSP avec ou sans le fat-client
Posté par Sygne (site web personnel) . Évalué à 2.
Depuis la version 5, ltsp utilise simplement ssh -x.
D'après ce que j'ai pu comprendre, le fonctionnement de ltsp est finalement très standardisé: boot PXE, montage du système de fichier via nfs, puis ssh -x (ou simplement startx pour les clients lourds). Le système de fichier du client, s'il diffère de celui du serveur, est peuplé via un chroot sur le serveur, et en utilisant le gestionnaire de paquet de la distribution. Enfin, chaque client peut configurer /etc/ avec les fichiers qui lui sont propres.
[^] # Re: LTSP avec ou sans le fat-client
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
Un collègue a mis ça en place dans une salle de cours où nous enseignons la programmation. C'est parfaitement fonctionnel. Et pourtant le serveur est un vieux pentium 4. Et il supporte sans broncher le moins du monde ses quatorze clients légers.
Le seul petit défaut de LTSP serait, selon moi, que l'installation ne se fait pas toujours en cinq minutes. La dernière fois que nous l'avons fait, une petite erreur de départ nous a coûté au moins une heure de travail (il nous a fallu pas mal de temps pour comprendre lesquels des serveurs employés par LTSP dysfonctionnaient). Ceci dit, installer et maintenir un parc complet en quelques minutes, il me semble que c'est déjà plus qu'appréciable.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: LTSP avec ou sans le fat-client
Posté par totof2000 . Évalué à 3. Dernière modification le 09 décembre 2013 à 10:40.
Sans vouloir entrer dans le troll, est-ce que l'arrivée de Wayland remettra en cause les solutions que vous avez mis en place ?
[^] # Re: LTSP avec ou sans le fat-client
Posté par ChickenKiller . Évalué à 2.
Perso j'ai mis ça en production sur plusieurs sites, la plus grosse appli à 20-30 clients, ça tourne 24/24 sans problème.
Par contre je n'utilise pas la notion de fat-client.
Avantages:
- Dépannage super facile même par des non technicien si la boite boite est cramée on en met une nouvelle à la place, on branche et roule.
- L'administration centralisée fait gagné un temps ENORME.
- Très facile de (re)dimensionner les ressources nécessaires.
- pas d'USB ou de CDROM actif par défaut (parfois pas facile à désactiver sur des clients lourds)
- possibilité de "jail" certains clients sur une seule appli
Problèmes:
- Dépendance très forte du réseau (plus de réseau -> tout se fige).
- Je n'ai pas trouvé pour le moment le moyen de faire booter pxe sur du wifi. Du coup dans le cas d'applications "mobile" faut revenir au vieux système de client lourd.
Notre schéma précédent était plus en mode serveur Linux-poste windows… Les machines étant en atelier, on passait notre temps à les changer/configurer/déveroller. Un gain de temps certains !
En se basant sur des clients léger, pas de disques, pas de ventilation qui s'encrasse, pas d'USB ou de CDROM avec qui tout le monde fait n'importe quoi.
[^] # Re: LTSP avec ou sans le fat-client
Posté par Sygne (site web personnel) . Évalué à 2.
Tes remarques, et celles de Pierre Matthieu Anglade finissent de me convaincre. Il reste à voir si j'aurai le courage de faire le saut, car mine de rien, c'est une petite révolution pour moi et mon foyer.
J'y ai vaguement réfléchi, et je pensais simplement synchroniser un système de fichier local avec celui du serveur:
- soit simplement pour booter et lancer
ssh -x, la synchronisation se faisant alors lors de l'extinction de la machine cliente.- soit pour avoir un copie de son espace de travail en déplacement. Dans ce cas, je pensais ne faire la synchronisation qu'à la demande: du serveur vers le portable avant le voyage, du portable vers le serveur après le voyage.
- rsync me semble être un bon candidat pour la synchronisation.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.