En lisant les récits du sysadmin de la "city of Largo" qui a déployé un
parc de 300 machines diskless ou presque montées en terminaux X, j'ai eu
envie de voir comment faire ça au mieux.
Dans son récit, il exlique qu'il a un serveur d'applications qui fait
tourner KDE, et pour répartir la charge il dispose d'un autre serveur
bureautique qui fait tourner des wordperfect.
Depuis leur desktop, les utilisateurs lancent un rsh vers la machine
bureautique en passant le display en argument.
Pour l'instant, je connais deux moyens de faire ça :
rsh et ssh. rsh n'est pas aussi sécurisé que ssh.
Ma question : Quelle méthode est la plus performante pour un réseau
moyennement rapide ?
Avec ssh, on peut passer un argument de compression afin de gagner un
peu de temps (...), et on peut choisir la méthode de cryptage.
D'après la page de man, blowfish est moins forte mais plus rapide.
Quel est le meilleur moyen pour lancer des applis distantes, en intranet
(donc notion de sécurité moins importante qu'en internet) de façon la
plus rapide possible ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
DINH Viêt Hoà
Ma question : Quelle méthode est la plus performante pour un réseau moyennement rapide ? Avec ssh, on peut passer un argument de compression afin de gagner un peu de temps (...), et on peut choisir la méthode de cryptage. D'après la page de man, blowfish est moins forte mais plus rapide.
Quel est le meilleur moyen pour lancer des applis distantes, en intranet (donc notion de sécurité moins importante qu'en internet) de façon la plus rapide possible ?
Cela ne dépend-il pas de la vitesse du processeur, ainsi que de la bande passante disponible sur le réseau ? Si tes processeurs arriver à débiter du ssh beaucoup plus rapidement que le réseau, ssh convient par exemple.
-- DINH V. Hoa,
"ça doit être une racaille pour être aussi con" -- Cent-Quarante-Six
Ma question : Quelle méthode est la plus performante pour un réseau
moyennement rapide ?
Avec ssh, on peut passer un argument de compression afin de gagner un
peu de temps (...), et on peut choisir la méthode de cryptage.
D'après la page de man, blowfish est moins forte mais plus rapide.
Quel est le meilleur moyen pour lancer des applis distantes, en intranet
(donc notion de sécurité moins importante qu'en internet) de façon la
plus rapide possible ?
Cela ne dépend-il pas de la vitesse du processeur, ainsi que de la bande
passante disponible sur le réseau ?
Si tes processeurs arriver à débiter du ssh beaucoup plus rapidement que
le réseau, ssh convient par exemple.
--
DINH V. Hoa,
"ça doit être une racaille pour être aussi con" -- Cent-Quarante-Six
Ma question : Quelle méthode est la plus performante pour un réseau moyennement rapide ? Avec ssh, on peut passer un argument de compression afin de gagner un peu de temps (...), et on peut choisir la méthode de cryptage. D'après la page de man, blowfish est moins forte mais plus rapide.
Quel est le meilleur moyen pour lancer des applis distantes, en intranet (donc notion de sécurité moins importante qu'en internet) de façon la plus rapide possible ?
Cela ne dépend-il pas de la vitesse du processeur, ainsi que de la bande passante disponible sur le réseau ? Si tes processeurs arriver à débiter du ssh beaucoup plus rapidement que le réseau, ssh convient par exemple.
-- DINH V. Hoa,
"ça doit être une racaille pour être aussi con" -- Cent-Quarante-Six
Stephane Chazelas
2003/11/21, 08:52(+00), Nicolas Ecarnot:
En lisant les récits du sysadmin de la "city of Largo" qui a déployé un parc de 300 machines diskless ou presque montées en terminaux X, j'ai eu envie de voir comment faire ça au mieux.
Oui, enfin, c'est ce qu'on faisait partout avant que les ordinateurs individuels deviennent si puissants.
Dans son récit, il exlique qu'il a un serveur d'applications qui fait tourner KDE, et pour répartir la charge il dispose d'un autre serveur bureautique qui fait tourner des wordperfect. Depuis leur desktop, les utilisateurs lancent un rsh vers la machine bureautique en passant le display en argument.
Pour l'instant, je connais deux moyens de faire ça : rsh et ssh. rsh n'est pas aussi sécurisé que ssh.
ssh est à peu près l'équivalent de mettre une porte blindée sur ton appart. Donc, si t'habites dans un quartier chaud et que t'es un peu parano ou que t'as des pièces de très grandes valeur dans ton appart', ça peut valoir le coup, sinon, c'est un peu cher.
Ma question : Quelle méthode est la plus performante pour un réseau moyennement rapide ?
Pas de gain de performance par ssh.
Avec ssh, on peut passer un argument de compression afin de gagner un peu de temps (...), et on peut choisir la méthode de cryptage. D'après la page de man, blowfish est moins forte mais plus rapide.
Si tu veux utiliser des machines en terminaux X, c'est que ce sont des petites config. Je dirais que le goulot d'étranglement se situerait plutot de ce côté que de la bande passante du réseau alors. Pour ssh, tu peux utiliser un chiffrage pour l'authentification si ton réseau n'est pas sûr, mais pour le contenu, à moins que tu aies d'autres mots de passe qui circulent (ou autres données confidentielles), utiliser un cipher "none" m'a toujours paru amplement suffisant.
Quel est le meilleur moyen pour lancer des applis distantes, en intranet (donc notion de sécurité moins importante qu'en internet) de façon la plus rapide possible ?
En lisant les récits du sysadmin de la "city of Largo" qui a déployé un
parc de 300 machines diskless ou presque montées en terminaux X, j'ai eu
envie de voir comment faire ça au mieux.
Oui, enfin, c'est ce qu'on faisait partout avant que les
ordinateurs individuels deviennent si puissants.
Dans son récit, il exlique qu'il a un serveur d'applications qui fait
tourner KDE, et pour répartir la charge il dispose d'un autre serveur
bureautique qui fait tourner des wordperfect.
Depuis leur desktop, les utilisateurs lancent un rsh vers la machine
bureautique en passant le display en argument.
Pour l'instant, je connais deux moyens de faire ça :
rsh et ssh. rsh n'est pas aussi sécurisé que ssh.
ssh est à peu près l'équivalent de mettre une porte blindée sur
ton appart. Donc, si t'habites dans un quartier chaud et que
t'es un peu parano ou que t'as des pièces de très grandes valeur
dans ton appart', ça peut valoir le coup, sinon, c'est un peu
cher.
Ma question : Quelle méthode est la plus performante pour un réseau
moyennement rapide ?
Pas de gain de performance par ssh.
Avec ssh, on peut passer un argument de compression afin de gagner un
peu de temps (...), et on peut choisir la méthode de cryptage.
D'après la page de man, blowfish est moins forte mais plus rapide.
Si tu veux utiliser des machines en terminaux X, c'est que ce
sont des petites config. Je dirais que le goulot d'étranglement
se situerait plutot de ce côté que de la bande passante du
réseau alors. Pour ssh, tu peux utiliser un chiffrage pour
l'authentification si ton réseau n'est pas sûr, mais pour le
contenu, à moins que tu aies d'autres mots de passe qui
circulent (ou autres données confidentielles), utiliser un
cipher "none" m'a toujours paru amplement suffisant.
Quel est le meilleur moyen pour lancer des applis distantes, en intranet
(donc notion de sécurité moins importante qu'en internet) de façon la
plus rapide possible ?
En lisant les récits du sysadmin de la "city of Largo" qui a déployé un parc de 300 machines diskless ou presque montées en terminaux X, j'ai eu envie de voir comment faire ça au mieux.
Oui, enfin, c'est ce qu'on faisait partout avant que les ordinateurs individuels deviennent si puissants.
Dans son récit, il exlique qu'il a un serveur d'applications qui fait tourner KDE, et pour répartir la charge il dispose d'un autre serveur bureautique qui fait tourner des wordperfect. Depuis leur desktop, les utilisateurs lancent un rsh vers la machine bureautique en passant le display en argument.
Pour l'instant, je connais deux moyens de faire ça : rsh et ssh. rsh n'est pas aussi sécurisé que ssh.
ssh est à peu près l'équivalent de mettre une porte blindée sur ton appart. Donc, si t'habites dans un quartier chaud et que t'es un peu parano ou que t'as des pièces de très grandes valeur dans ton appart', ça peut valoir le coup, sinon, c'est un peu cher.
Ma question : Quelle méthode est la plus performante pour un réseau moyennement rapide ?
Pas de gain de performance par ssh.
Avec ssh, on peut passer un argument de compression afin de gagner un peu de temps (...), et on peut choisir la méthode de cryptage. D'après la page de man, blowfish est moins forte mais plus rapide.
Si tu veux utiliser des machines en terminaux X, c'est que ce sont des petites config. Je dirais que le goulot d'étranglement se situerait plutot de ce côté que de la bande passante du réseau alors. Pour ssh, tu peux utiliser un chiffrage pour l'authentification si ton réseau n'est pas sûr, mais pour le contenu, à moins que tu aies d'autres mots de passe qui circulent (ou autres données confidentielles), utiliser un cipher "none" m'a toujours paru amplement suffisant.
Quel est le meilleur moyen pour lancer des applis distantes, en intranet (donc notion de sécurité moins importante qu'en internet) de façon la plus rapide possible ?
Le Fri, 21 Nov 2003 10:23:15 +0100, DINH Viêt Hoà disait :
Quel est le meilleur moyen pour lancer des applis distantes, en intranet (donc notion de sécurité moins importante qu'en internet) de façon la plus rapide possible ?
Cela ne dépend-il pas de la vitesse du processeur, ainsi que de la bande passante disponible sur le réseau ? Si tes processeurs arriver à débiter du ssh beaucoup plus rapidement que le réseau, ssh convient par exemple.
Certes, mais autant choisir un protocole qui - fait le moins ramer mon serveur. Dans mon cas, je n'ai en fait aucun besoin de sécurité (l'encodage de ssh ne m'apporte rien en intranet) - pèse le moins lourd sur le réseau. La compression est une bonne chose, mais le mieux est encore de ne pas avoir besoin de compresser, dans le cas d'un protocole léger.
Donc puisque je ne connais pas finement les performances de chaque solution, peut-être que certains d'entre vous ont plus d'expérience dans ce domaine ?
-- Nicolas Ecarnot
Le Fri, 21 Nov 2003 10:23:15 +0100,
DINH Viêt Hoà <dinh.viet.hoa@free.fr> disait :
Quel est le meilleur moyen pour lancer des applis distantes, en intranet
(donc notion de sécurité moins importante qu'en internet) de façon la
plus rapide possible ?
Cela ne dépend-il pas de la vitesse du processeur, ainsi que de la bande
passante disponible sur le réseau ?
Si tes processeurs arriver à débiter du ssh beaucoup plus rapidement que
le réseau, ssh convient par exemple.
Certes, mais autant choisir un protocole qui
- fait le moins ramer mon serveur. Dans mon cas, je n'ai en fait aucun
besoin de sécurité (l'encodage de ssh ne m'apporte rien en intranet)
- pèse le moins lourd sur le réseau. La compression est une bonne chose,
mais le mieux est encore de ne pas avoir besoin de compresser, dans le
cas d'un protocole léger.
Donc puisque je ne connais pas finement les performances de chaque
solution, peut-être que certains d'entre vous ont plus d'expérience dans
ce domaine ?
Le Fri, 21 Nov 2003 10:23:15 +0100, DINH Viêt Hoà disait :
Quel est le meilleur moyen pour lancer des applis distantes, en intranet (donc notion de sécurité moins importante qu'en internet) de façon la plus rapide possible ?
Cela ne dépend-il pas de la vitesse du processeur, ainsi que de la bande passante disponible sur le réseau ? Si tes processeurs arriver à débiter du ssh beaucoup plus rapidement que le réseau, ssh convient par exemple.
Certes, mais autant choisir un protocole qui - fait le moins ramer mon serveur. Dans mon cas, je n'ai en fait aucun besoin de sécurité (l'encodage de ssh ne m'apporte rien en intranet) - pèse le moins lourd sur le réseau. La compression est une bonne chose, mais le mieux est encore de ne pas avoir besoin de compresser, dans le cas d'un protocole léger.
Donc puisque je ne connais pas finement les performances de chaque solution, peut-être que certains d'entre vous ont plus d'expérience dans ce domaine ?
-- Nicolas Ecarnot
DINH Viêt Hoà
Certes, mais autant choisir un protocole qui - fait le moins ramer mon serveur. Dans mon cas, je n'ai en fait aucun besoin de sécurité (l'encodage de ssh ne m'apporte rien en intranet) - pèse le moins lourd sur le réseau. La compression est une bonne chose, mais le mieux est encore de ne pas avoir besoin de compresser, dans le cas d'un protocole léger.
le protocole X est un standard et je pense que c'est un point qui suffit pas mal à faire ce choix. X est un protocole qui concerne l'affichage, beaucoup d'images passent, on n'y peut rien ... pour réduire la bande passant, la seule solution est d'y mettre de la compression.
-- DINH V. Hoa,
"ça doit être une racaille pour être aussi con" -- Cent-Quarante-Six
Certes, mais autant choisir un protocole qui
- fait le moins ramer mon serveur. Dans mon cas, je n'ai en fait aucun
besoin de sécurité (l'encodage de ssh ne m'apporte rien en intranet)
- pèse le moins lourd sur le réseau. La compression est une bonne chose,
mais le mieux est encore de ne pas avoir besoin de compresser, dans le
cas d'un protocole léger.
le protocole X est un standard et je pense que c'est un point qui suffit
pas mal à faire ce choix.
X est un protocole qui concerne l'affichage, beaucoup d'images
passent, on n'y peut rien ... pour réduire la bande passant, la seule
solution est d'y mettre de la compression.
--
DINH V. Hoa,
"ça doit être une racaille pour être aussi con" -- Cent-Quarante-Six
Certes, mais autant choisir un protocole qui - fait le moins ramer mon serveur. Dans mon cas, je n'ai en fait aucun besoin de sécurité (l'encodage de ssh ne m'apporte rien en intranet) - pèse le moins lourd sur le réseau. La compression est une bonne chose, mais le mieux est encore de ne pas avoir besoin de compresser, dans le cas d'un protocole léger.
le protocole X est un standard et je pense que c'est un point qui suffit pas mal à faire ce choix. X est un protocole qui concerne l'affichage, beaucoup d'images passent, on n'y peut rien ... pour réduire la bande passant, la seule solution est d'y mettre de la compression.
-- DINH V. Hoa,
"ça doit être une racaille pour être aussi con" -- Cent-Quarante-Six
Nicolas Ecarnot
Le Fri, 21 Nov 2003 11:13:06 +0100, Stephane Chazelas disait :
Pour ssh, tu peux utiliser un chiffrage pour l'authentification si ton réseau n'est pas sûr, mais pour le contenu, à moins que tu aies d'autres mots de passe qui circulent (ou autres données confidentielles), utiliser un cipher "none" m'a toujours paru amplement suffisant.
Apparement, le cipher none a disparu depuis un moment de la distribution officielle d'openssh.
C'est lourd.
-- Nicolas Ecarnot
Le Fri, 21 Nov 2003 11:13:06 +0100,
Stephane Chazelas <cette.adresse@est.invalid> disait :
Pour ssh, tu peux utiliser un chiffrage pour
l'authentification si ton réseau n'est pas sûr, mais pour le
contenu, à moins que tu aies d'autres mots de passe qui
circulent (ou autres données confidentielles), utiliser un
cipher "none" m'a toujours paru amplement suffisant.
Apparement, le cipher none a disparu depuis un moment de la distribution
officielle d'openssh.
Le Fri, 21 Nov 2003 11:13:06 +0100, Stephane Chazelas disait :
Pour ssh, tu peux utiliser un chiffrage pour l'authentification si ton réseau n'est pas sûr, mais pour le contenu, à moins que tu aies d'autres mots de passe qui circulent (ou autres données confidentielles), utiliser un cipher "none" m'a toujours paru amplement suffisant.
Apparement, le cipher none a disparu depuis un moment de la distribution officielle d'openssh.
C'est lourd.
-- Nicolas Ecarnot
Erwann ABALEA
On 21 Nov 2003, Nicolas Ecarnot wrote:
Apparement, le cipher none a disparu depuis un moment de la distribution officielle d'openssh.
Oui, pour plusieurs raisons: - il est 'insecure' (obviously), - un bon cryptosytème symétrique ne bouffe pas énormément de temps CPU pour chiffrer et déchiffrer les données.
Par exemple, sur ma machine, arcfour (RC4) est capable de chiffrer/déchiffrer entre 22 et 32 Mo par seconde, alors que Blowfish reste dans la fourchette 9-12 Mo par seconde. RC4 bien utilisé est considéré comme sûr. Et ma machine est un PII/400.
Apparement, le cipher none a disparu depuis un moment de la distribution
officielle d'openssh.
Oui, pour plusieurs raisons:
- il est 'insecure' (obviously),
- un bon cryptosytème symétrique ne bouffe pas énormément de temps CPU
pour chiffrer et déchiffrer les données.
Par exemple, sur ma machine, arcfour (RC4) est capable de
chiffrer/déchiffrer entre 22 et 32 Mo par seconde, alors que Blowfish
reste dans la fourchette 9-12 Mo par seconde. RC4 bien utilisé est
considéré comme sûr. Et ma machine est un PII/400.
Apparement, le cipher none a disparu depuis un moment de la distribution officielle d'openssh.
Oui, pour plusieurs raisons: - il est 'insecure' (obviously), - un bon cryptosytème symétrique ne bouffe pas énormément de temps CPU pour chiffrer et déchiffrer les données.
Par exemple, sur ma machine, arcfour (RC4) est capable de chiffrer/déchiffrer entre 22 et 32 Mo par seconde, alors que Blowfish reste dans la fourchette 9-12 Mo par seconde. RC4 bien utilisé est considéré comme sûr. Et ma machine est un PII/400.
Apparement, le cipher none a disparu depuis un moment de la distribution officielle d'openssh.
Oui, pour plusieurs raisons: - il est 'insecure' (obviously),
non mais il est clair que des fois on n'a besoin que de l'identification des machines (les certificats) et le contenu de ce qui passe n'est pas forcément confidentiel.
-- DINH V. Hoa,
"ça doit être une racaille pour être aussi con" -- Cent-Quarante-Six
On 21 Nov 2003, Nicolas Ecarnot wrote:
Apparement, le cipher none a disparu depuis un moment de la distribution
officielle d'openssh.
Oui, pour plusieurs raisons:
- il est 'insecure' (obviously),
non mais il est clair que des fois on n'a besoin que de l'identification
des machines (les certificats) et le contenu de ce qui passe n'est pas
forcément confidentiel.
--
DINH V. Hoa,
"ça doit être une racaille pour être aussi con" -- Cent-Quarante-Six
Apparement, le cipher none a disparu depuis un moment de la distribution officielle d'openssh.
Oui, pour plusieurs raisons: - il est 'insecure' (obviously),
non mais il est clair que des fois on n'a besoin que de l'identification des machines (les certificats) et le contenu de ce qui passe n'est pas forcément confidentiel.
-- DINH V. Hoa,
"ça doit être une racaille pour être aussi con" -- Cent-Quarante-Six
