Causons un peu desktop, poste client. Attention, pas dans le sens :
- "la transparence xorg roxor"
Le stateless n'est pas nouveau et d'ailleurs ça a été fait. En même temps ça n'a jamais été réellement fait... C'est toujours compliqué à mettre en oeuvre, à déployer, ce n'est pas générique, il y a des contraintes, etc...
Red Hat veut faire du stateless (traduction svp) un élément centrale.
C'est particulièrement intéressant en entreprise.
Red Hat a défriché le terrain.
Introduction par Havoc Pennington (assez technique) :
http://people.redhat.com/~hp/stateless/StatelessLinux.pdf(...) ("Introduction to stateless Linux - Proposal for the Fedora Project")
David Malcolm a fait un Howto :
http://people.redhat.com/dmalcolm/stateless/stateless-linux-HOWTO-e(...)
Les développements déjà réalisés (sous GPL, évidemment) :
http://people.redhat.com/dmalcolm/stateless/(...)
L'annonce et le thread sur fedora-devel-list :
https://listman.redhat.com/archives/fedora-devel-list/2004-September(...)
Quelques réflèxions sans beaucoup de recul :
- Techniquement, Linux a fait des progrès énormes dans le desktop. Udev, Hal, SeLinux,etc permettent d'envisager des postes clients "exploitables" sans jamais utiliser le compte root ni rogner sur la sécurité.
- Il ne faut pas sous-estimer Red Hat et c'est un évènement important même si actuellement il n'y a presque rien de concrêt. À mon sens, il ne faut pas prendre à la légère cette "annonce" (qui n'en est pas vraiment une...).
- Le rôle et l'importance de Fedora dans Red Hat est encore affirmé. C'est pour ceux qui en doute...
- Petit à petit, et avec une "véritable" vision/projet, Red Hat s'investit dans le desktop (pour entreprise).
- Ce projet va aussi améliorer le Linux "non-stateless" (lire le papier d'Havoc).
- Ça va prendre du temps...
Puisque j'y suis, Colin Charles présente les nouveautés les plus importantes de FC3 (test 2 prévue pour le 20 septembre) et donc aussi de RHEL 4 :
http://www.bytebot.net/talks/FC3-t2rawhide-whatsnew.pdf(...)
Journal stateless Linux
14
sept.
2004
# stateless = sans état
Posté par Bruno Ethvignot (site web personnel) . Évalué à 10.
En informatique, stateless se rapporte à un système ou à un protocole qui ne garde pas un état persistant entre les transactions.
D'après http://www.granddictionnaire.com/(...)
stateless = sans état
Essai de traduction de http://en.wikipedia.org/wiki/Stateless_server(...) :
Un serveur sans état est un serveur qui traite chaque requête comme une transaction indépendante, dissociée des demandes précédentes. Ceci simplifie la conception de serveur parce qu'il n'a pas besoin d'allouer d'espace pour traiter avec les instances en cours ou de s'inquiéter de le libérer si un client meurt en plein milieu de la transaction. Un inconvénient est qu'il peut être nécessaire d'inclure plus d'informations dans chaque requête, ces informations supplémentaires devant être interprétées à chaque fois par le serveur.
Un exemple d'un serveur sans état est un serveur web. Ceux-ci acceptent les requêtes (URL) qui spécifient complètement le document demandé et n'exigent aucun contexte ou mémoire de requêtes précédentes.
Opposez ceci avec un serveur FTP traditionnel qui maintient une session interactive avec l'utilisateur. Une requête d'un fichier au serveur suppose que l'utilisateur a été authentifié et que le répertoire courant et le mode de transfert soient initialisés.
[^] # Re: stateless = sans état
Posté par Pior . Évalué à 3.
Mais je ne vois pas le rapport avec le desktop.
Qu'est ce que ça veut dire ça ? RH veut appliquer le concept du stateless partout ?
Des examples concrets ? Merci bien.
[^] # Re: stateless = sans état
Posté par nojhan (site web personnel, Mastodon) . Évalué à 5.
Il s'agit en gros d'avoir des ordis qui tournent avec les données centralisées sur un serveur tout en évitant de faire tourner les applis sur celui-ci (j'imagine que ça doit booter sur le réseau et utiliser NFS...)
Enfin ils précisent bien que RH ne veut pas "appliquer le concept du stateless partout" (c'est fou ce qu'on voit ce genre de simplification revenir à tout bout de champs ici) mais veut en faire une solution complémentaire.
[^] # Re: stateless = sans état
Posté par 007 . Évalué à 4.
Mon entreprise a le serveur A.
J'ai aussi les clients A, B, C, D, E, F.
Je bosse sur le client A qui a un montage NFS (car ce client n'a pas de disque dure).
Puis je vais bosser sur le client C qui utilise ses disque dure. C'est plus rapide et confortable.
Puis je vais sur une client D qui est loin du serveur et un montage NFS de root n'est pas envisable. J'utilise alors un CD-ROM.
Puis je vais sur le client E qui a un disque dure. Je bosse et il y a une coupure de réseau. Néanmoins je peux continuer de bosser.
Je rentre comme d'habitude chez moi avec le client F. Je vais bosser en étant déconnecté du serveur. Il va de soit qu'avant d'utiliser autres clients, je dois synchroniser mon client F avec le serveur.
Je fais tout ça sans perdre mes donnés, sans les copier manuellement d'une machine une à autre. Sans jamais vérifier que j'ai la bonne version de logiciel.
Si je veux installer une bécane, c'est très simple. Je boote sur le réseau ou une CD-ROM, je fais "install" et c'est terminé. Puis je me connecte à mon compte habituel. Pas besoin d'être admin ou root. Si je veux connecter une imprimante, je la branche. Si c'est hotplug, c'est terminé sinon il y aura un programme à lancer.
"sans état", n'est pas synonyme de sans disques.
Il est claire que ça ne va pas être réalisé en semaine... Mais techniquement c'est actuellement envisageable.
[^] # Re: stateless = sans état
Posté par gebura . Évalué à 2.
par contre je me pause une question: ca risque pas d etre trop coton a gerer les syncronisations pour les fichiers utilisateurs sans utiliser un systeme de control de version a la cvs ?
Par ce que si jamais tu commence à taf sur une session et que tu prends pas le temps de syncroniser ton boulot avant de changer de poste ca risque d etre vite le bordel dans ce cas.
Biensur dans l absolue c est mieux de faire mais, pour reprendre ton exemple, si la connexion reseau du client E ne revient pas avant que tu rentres finir ton taf chez toi tu risque de t amuser le lendemain...
[^] # Re: sans état
Posté par 007 . Évalué à 1.
Mais ... Red Hat a acheté sistina qui développe lvm2 et device-mapper. Or device-mapper support les "snapshots" mais Red Hat a aussi un solution cluster qui supporte ça.
Dans un premier temps, cette techno sera sûrement (avis perso) utilisée pour le serveur d'"OS" (l'image de référence du système client). Actuellement il y a un "double-buffering" bien rustique.
Couplé à rpm, ça peut permettre de mettre à jours l'"OS" de référence (sur le serveur) sans géner les clients en cours de mise à jours.
> Par ce que si jamais tu commence à taf sur une session et que tu prends pas le temps de syncroniser ton boulot avant de changer de poste ca risque d etre vite le bordel dans ce cas.
Pour la partie client, il y aura évidement un "gestionnaire de conflit" lorsque tu feras l'importation.
Il est claire que si tu ouvres deux sessions en même temps (session précedente non fermée pour x raison), le serveur va gueuler (t'avertir gentillement). Comme le client va mettre un gros warning si tu ouvres une sessions sans en informer le serveur.
Il y a toujours un moment où il faut un minimum de contrôle. Si tu veux être libre à 100 %, tu ne choisi pas ce modèle sans état (côté client).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.