Sytoka Modon a écrit 4546 commentaires

> Si l'on considère les 1424 docteurs en post doc à l'étranger depuis

Et alors, c'est très bien. Cela participe de la diffusion de la culture francaise ;-) De toute manière le gouvernement n'a rien compris en disant que c'est un problème de salaire au mérite alors que nous voulons tout simplement des vrais postes de permanents dans la recherche publique.

Pour en revenir au sujet. Sais tu combien de post doc étranger reste en france ? Sais tu combien de médecin étranger pratique en france à des salaires inférieurs (ce qui est pour moi de l'Apartheid) ?

Bref, c'est pour moi une phrase à deux balles irrespectueuse de toutes ces personnes qui ont quitté leur pays pour venir travailler en france.

> compressed (c), « compressé » ─ expérimental

Désolé, je n'avais pas vu cette ligne.

Cela m'a l'air un peu trop expérimental pour pouvoir être utilisé en backup. De plus, il ne précise pas le type de système de fichiers pouvant supporté cette fonctionalité. Or je ne mets que du ext3 sur mes sauvegardes.

L'autre voie utilisant fuse m'a l'air bien aussi ;-)

Contexte : je débarque dans un nouveau service depuis une quizaine.

Question charge, je suis autour de 150 utilisateurs... J'ai pas mal entendus de problème sur la tenue en charge d'openldap. Pour le moment, ca a l'air de tenir.

Question schema, je pense me faire mes propres outils en perl (ou bash) à partir d'une base existante. Le système tourne en production avec un seul annuaire ldap pour le moment ! Je suis en train de placer des secondaires ici ou là, a des endroits stratégiques. La base utilisateur est aussi à refaire, tous les utilisateurs ne sont pas des mêmes classes ! Mais ca marche...

Bref, j'aurais préféré commencer mieux mon entrée en matière concernant ldap. C'est en forgeant qu'on devient forgeron.

Les solutions que tu me proposes m'intéresse grandement dès que j'aurais stabilisé et fiabilisé mon système actuel avec les moyens actuels...

Ton lien m'a l'air de n'avoir aucun rapprt car c'est une page de léa qui parle des attribut étendus.

Par contre, je suis moi aussi preneur. Je sais que l'on peux faire cela sur des partitions en lecture seule (c'est utilisé dans les knoppix et dérivées pour diminuer la taille de l'image -- ou plutôt pour augmenter le nombre de logciels par CD).

Comme je fais moi aussi mes sauvegardes sur disques, une partition compressée de manière transparente serait le bonheur.

Peut être aller voir du coté des périphériques loop, ou du coté du device mapper qui remplace la technique du loop pour les systèmes de fichiers chiffrés.

> d'un autre coté, quand on parle de NSS-LDAP, il me semblait que
> cela sous entendait que l'on avait lu le manuel :(

J'avais lu pas mal de doc mais j'étais passé à coté de celle-là. Ca arrive... Si tu fouille un peu sur le net, tu verrais 50000 doc pour t'expliquer qu'il faut mettre un slapd esclave via slurpd mais très peu parlent d'une solution simple utilisant ces esclaves (à part samba).

La solution avec heartbeat + lvs fonctionne mais c'est vrai que je souhaitais un truc plus simple ou les clients intérrogent la première base qui répond. Ca ne me pose aucun problème de configuration même sur un gros parc machine car les postes s'autoconfigurent avec cfengine ;-)

Et puis heartbeat, si mes souvenirs sont bons (pas essayé les dernières versions), ca ne marche qu'entre deux machines. Comme tu fait si tu as un maître et trois esclaves ?

Autre question dans la même veine, est'il possible de configurer courier (imap) pour qu'il puisse intérroger plusieurs annuaires ?

Si le portable voyage beaucoup, il y a des cas où on est obligé de le donner a distance...

Sinon, a moins de verouiller complètement dès le BIOS, on sais ca que vaut réellement un mot de passe root ! C'est très facile a casser sur une machine.

Et même en verouillant le BIOS, il suffit de demonter le disque dur et de le monter sur une autre machine pour le changer. C'est vachement dur (en général une vis a déviser).

Bref, personnellement, je n'ai pas confiance dans les portables qui voyagent...

Mais depuis que je sais que NFSv4 authentifie les personnes et pas seulement les machines comme sous NFSv3, le problème du root est bien moins crucial.

Il suffit de voir cette daube de gconf qui ne sers à rien ...

On peux cependant reprendre dans SMB ce qui est bien. Par exemple, l'authentification des utilisateurs et virer ce qui est pourris (le partage par n'importe qui n'importe comment, le partage d'impression, les élections pour être master du voisinage réseau, le mélange avec les RPC...)

Je suis d'accord, mais je pense par exemple à un portable en libre service utilisé par pleins de personnes mais pas en même temps.

Il est clair que sur une machine réellement multi-utilisateurs, le mot de passe root ne doit pas être diffuser. C'est rarement le cas des portables or ce sont les portables qui posent des problèmes d'administration aujourd'hui.

> Tu as un message privé...

OK, je te repond la dessus tout a l'heure.

Sinon, root_squash ou pas, ca ne change pas grand chose.

Je suis root sur une machine, je fais su - toto et je prends l'identité de toto et peux alors lire les fichiers de toto sur le serveur.

Le problème est que sur un portable qui se balade, la personne a le mot de passe root DONC peut prendre l'identité de n'importe quel compte accessible sur cette machine. Dès que les machines se font confiances, cette personne a donc accès a tous les fichiers exportés sur des partages NFS, quel que soit les droits posés dessus... CQFD.

Je précise que je n'ai jamais utilisé NFSv4. Donc je navigue a vue. Je ne suis pas là pour descendre NFS que j'utilise tous les jours et que je trouve parfois bien plus pratique que Samba.

Pour moi, d'après ce que j'ai compris, NFS identifie les machines et non les personnes. Dans la version 4, c'est nettement supérieur à ce qui se faisait dans la version 3 (en gros, les netgroup).

Le problème d'après moi est que si tu authorises une personne a accéder à un serveur NFS(v4) sur sa machine avec son compte, alors si elle a le mot de passe root, elle peux accéder aux données concernant les autres personnes qui aurait accès à cette même machine. Chose non possible avec Samba.

C'est justement le problème !

La machine A doit rendre accessible des fichiers pour toto qui travaille sur la machine B en lecture ecriture.

A partir de ce moment là, il faut avoir le controle du root de la machine B ce qui est difficile pour un protocole qui irait sur internet parce que les machines pourraient etre distantes de pas mal de bornes.

Avec un partage de type samba, il n'y a pas ce problème... Mais cela a aussi des inconvénients. Par exemple avec NFS, tu te logues et avec l'automounteur, tu as toutes tes données en lecture écriture (enfin, avec le module pam pmount, on peux faire a peu près pareil avec samba). L'autre avantage est de pouvoir mutualiser les points de montages et les requètes sur le serveur nfs entre les utilisateurs.

Dans les laboratoires de recherche, on a de plus en plus affaire a du nomadisme. NFSv4 ne semble pas pouvoir répondre à cette problématique.

Je connais un peu NFS et Samba ainsi que NIS. Je les utilise tous les trois tous les jours ;-)

Les fichiers de toto sont une la machine A, tu te logues sur la machine B, tu passes en root et tu fais su - toto. Tu as alors acces a tous les fichiers de toto sur la machine A alors que tu es sur la machine B !

Avec Samba, cela ne marche pas car même si tu devient toto sur la machine B, cela ne te donne pas le droit de lire les fichiers sur la machine A. C'est tout.

Au niveau performance, je suis d'accord et j'utilise nfs en local entre mes machines UNIX dont je controle le root !

C'est pour cela qu'avoir un NFS qui tient sur internet me parait à la fois mieux (car ca ira aussi mieux en local) mais je ne vois pas bien comment je pourrais avoir confiance en des machines distribués sur le net et dont je ne maitrise pas le root.

Au niveau NIS, tu gères qui est dans la base NIS et il n'y a pas que le root qui est exclus ! En pratique, tu ne met que la plage des uid de tes utilisateurs. NIS n'est pas super sécurisé mais combien de personne tourne avec un ldap sans ssl ! D'un point de vue sécurité, ldap sans ssl n'est pas franchement mieux que nis. Il suffit de mettre un poste client de l'annuaire et de faire un "getent password" pour s'en rendre compte. La aussi, il faut maitriser les root locaux que le ldap soit avec ssl ou sans ssl.

Question : comment maitrises tu le root des portables qui passe leur temps a voyager ?

J'espère avoir été plus clair ;-)

Il est possible de sécurisé ftp pour qu'il devienne très sur, soit via la couche ssl, soit par la voie plus surprenante (moins classique) ; OPIE.

OPIE est une infrastructure de "One Time Password". Même si le mot de passe transite en clair sur le réseau, il n'est pas possible de s'en reservir. Le mot de passe change à chaque fois selon une suite prédéfnit. Or la clef de la suite est personnel et ne transite jamais sur le réseau.

Il y a à l'heure atuelle (NFSv3) deux trucs "chiants" qui ne marchent pas, à ma connaisssance, sous debian/sarge :

- pas de gestion des acl

- pas de gestion de l'option -ghost par l'automounteur.

Cette dernière option permet de voir les dossiers qui pourrait être automounté dans un repertoire via la commande ls ou via un explorateur de fichier. Pour les débutants qui cliquent dans un explorateur, la non prise en charge de cette option est fatale.

Il y a des trucs super avec Samba. Par exemple ;

- le root d'une machine n'est pas capable de réellement prendre l'identité d'une autre personne. Faire sous root "su - toto" permettra d'avoir un shell sous toto mais aucunement d'avoir accès aux données de toto. Avec NFS, si ! Or comment voulez faire confiance a une tentacule de PC distribué sur le net dont vous ne seriez pas sur des root...

- j'adore la possibilité de pouvoir lancer des scripts via les hooks "root pre exec...". Je trouve cela super souple. Je crée ainsi pas mal de script .bat à chaud en fonction de la personne mais aussi de la machine. OK, on doit pouvoir faire cela avec apache2 et j'envisage de transférer une partie de mes scripts utilisant un transport CIF vers du transport http, mais bon, c'est pratique ces hooks.

OK, samba a aussi plein de défauts. Pas de point de montage partagé entre utlisateurs, un protocole qui fait tout et n'importe quoi (partage de fichier, impression...). Ce serait bien de pouvoir avoir un paquet samba qui n'ai pas le code concernant l'impression par exemple.

En forth, c'est un peu diférrent (mais je ne suis spécialiste du LISP) car le langage est semi-compilé (ce qui est assez rare). Il y a des langages avec macro (assez faible dans le cas du C par exemple) mais en Forth, c'est un langage a mot. Tout est mot (a vrai dire, ca ressemble un peu au lisp sauf que la notation est la RPN et que tout le fonctionnement repose sur deux piles : une pile de données et une pile des adresses de retour)

Tu peux ensuite décider qu'un mot est "immédiate". Il sera donc exécuté lors de la phase de semi-compilation. Cependant, la syntaxe d'un mot "immediate" est exactemet la meme que celui d'un autre mot. C'est juste son contexte d'execution qui change.

Ca pourrait faire penser aux évaluations différées ou immédiates en Mathematica ou en Mapple selon le type d'affectation (= ou := pour Mathematica), voire la même chose avec le gnu/make.

Ici, c'est un peu différent puisque cela ne concerne pas l'affectation mais la propriété d'un mot.

> pertinent, mais j'ai l'impression que ça revient à dire: ça serait bien
> que l'on puisse programmer des design patterns. Pour l'instant on
> ne peut pas les programmer, ce sont des concepts que le

C'est ce qui me plaisait en Forth. Il y avait la possibilité de créer des mots avec la propriété "immédiate" qui s'éxécutaient lors de la pré-compilation (Forth est un langage semi-compilé). Il était assez facile pour un utilisateur lambda (comme moi) de rajouter ses propres structures de controle au langage.

De ce point de vue, les langages modernes sont bien pauvres.

Avec même un bout en allemand... au niveau d'une photo

Le principal problème est que même sans marge, on arrive pas a recadrer l'image au dernier moment. Or la photo n'a jamais la même dimension que la place sur le papier, donc il faut recadrer au dernier moment. Or pas un logiciel ne propose de recadrer a ce moment là (sauf le logiciel de Canon sous Windows).

Mais c'est pas terrible...

J'ai déjà posé une question à propos de l'impression sous GNU/Linux. Les problèmes sont les suivants (en gros) : éliminer les blancs pour une impression de, par exemple, 4 photos par pages en perdant le moins de papier, donc ensuite un redimensionnement de l'image *au dernier moment* pour décider des zones qui seront sacrifié (forcément, la dimension sur la page n'est JAMAIS la dimension de l'image).

Bref, je ne connais rien de bien sous GNU/Linux pour le moment.

A mon avis, c'est un problème de route. Il suffit de mettre l'url que tu veux dans une route utilisant eth0 pour que celle-ci soit prise en compte.

D'ailleurs, avis personnel, il serait bien d'avoir une commande route plus performante, plus au niveau d'un firewall. Du style prendre la route eth0 pour les paquets vers un port 80 mais la route prenant le chemin eth1 pour les paquets vers un (autre ou le même) serveur http (443). Pour le moment, c'est à ma connaissance impossible sous GNU/Linux.

Je ne sais pas pour vous mais la HP1510 me parait vachement solide pour une utilisation familiale.

J'ai une HP1510 qui marche très bien mais effectivement la qualité n'est pas au top.

J'ai du mettre l'imprimante sur le poste windows pour l'installer ! Impossible de faire un truc à distance. Une vrai merde. Le logiciel fournis pour imprimer des photos par HP est aussi complètement anti-ergonomique et mal fichue... par rapport au logiciel Canon qui ne fait qu'imprimer et le fait très bien. Monsieur HP, prenez en de la graine et virez moi tout ce fatras de code qui n'est pas dans votre spécialité.

Ensuite, tout roule... J'imprime à distance depuis tous les postes vers mon poste Linux. Il suffit d'oublier samba (Je n'ai jamais aimé qu'on mélange partage de fichier et file d'attente d'impression. Quelqu'un sais t'il comment virer tout le code concernant l'impression de samba). Quid alors ? On imprime tout simplement sur une file d'attente lpr depuis Windows ! Par expérience, ca marche 10 fois mieux que cette foutue impression samba + cups ;-)

> Bon après, si le binaire en question est un .zip (par exemple), c'est
> sur que la modif d'une ligne d'un fichier dans le zip produit un delta
> ridiculement gros, mais ca c'est un problème du à la nature du

Dommage que les zip et les tar (gz) ne soient pas pris en compte car les fichiers d'openoffice (swx ou odt) sont des archives zip. Or je ne sais pas pour vous mais j'en vois passer de plus en plus ;-)

Je sais, c'est moi qui l'ai mis ;-)

Dans ce cas, pourquoi n'as tu pas centré principalement ton journal sur ce moteur ?