Sytoka Modon a écrit 4538 commentaires

Je ne suis pas d'accord. NFS a des defauts mais ce n'est pas une daube. Sur un réseau local, c'est très performant. Il faut voir qu'avec NFS, il n'y a qu'un seul point de montage partagé pour plusieurs personnes. Pour un serveur, c'est pas plus mal.

Un des défaut de NFS sous linux c'est d'être en pratique en mode noyau. De même pour l'automounter. Du coup, lorsque ca pars en sucette, c'est quasiment le reboot obligatoire. Enfin, j'ai quand même eu des uptime de plus de 365 jours avec un DELL PowerEdge 2500 ! Heureusement que samba est en mode utilisateur, car lui, je le relance bien plus souvent...

Et puis, sur un poste Linux, a part Samba et NFS, la concurrence est faible. Samba est très bien mais aussi très orienté Windows. Je me fiche de toute la partie impression de CIF. Samba ne monte pas et ne démonte pas tout seul (c'est faisable mais pas facile pour une floppée de partage et de personne). Bref, Samba et NFS ont tous les deux des avantages et des inconvénients.

Et puis sur un système UNIX, le root reste le root et peut prendre l'identité de n'importe qui. Il faut savoir ne pas donner le mot de passe root à n'importe qui. D'un autre coté, qui met des mots de passe différent sur chaque machine (moi), qui dé-installe le partage de fichier et l'accès à distance sur le registre sur une machine Windows (moi), qui a un super root de domaine sous Windows (et Samba - smbclient - smbfs)... Essayes de cracker les mots de passe du smbpassword et ceux d'un ancien /etc/passwd sous TripleDES et tu verras que le TripleDES tiens bien plus longtemps.

Les autres systèmes de fichier distribué... et bien justement, on ne les voit pas beaucoup.

Par ailleurs avec NFS, il y a les RPC. Je crois aussi que Sun était à l'origine de CDE (que je n'aime pas)...

Je maintiens que sans NFS, UNIX aurait été viré depuis longtemps des serveurs de calcul donc de la plupart des universités. Il faut revoir l'Histoire dans sa globalité et dans cette histoire, Linux arrive bien tard.

Il ne faut pas oublier que NFS, NIS... ça vient de Sun si mes souvenirs sont bon. Donc oui, Sun a quand même pas mal donné pour des standards ouverts.

Sans NFS, UNIX serait mort depuis longtemps...

Si tu veux. De toute manière, avec SIP, tu ne fais qu'initialiser (en théorie). En pratique, dans la langue commune, SIP va bientôt vouloir dire tout et n'importe quoi à propos de la VoiIP (ca ne vous rapelle rien -> MPeg4).

J'avais espéré que SIP éliminirait la tuyauterie H323. En pratique, on change de tuyauterie donc je ne vois pas spécialement d'intérêt. Ils pouvaient pas faire simple et réduire le nombre de tuyaux ?

Je fais des GPO avec Samba depuis longtemps... C'est vrai que ce n'est pas hyper évolué mais c'est déjà pas mal.

Ce que j'en ai compris, les GPO sont surtout un coup de secedit. J'avais dis comment j'avais fait cela ici :

http://linuxfr.org/submit/comments,17047,532680,5.html

En gros l'idée est de faire généré un ou des fichiers spécifique à chaque machine/personne qui se connecte avec l'option "root pre exec" de samba.

C'est d'ailleurs un des trucs que je trouve des plus génial dans samba, c'est cette possibilité de configurer et de générer des fichiers à chaud. Comparativement, le couple nfs/autofs est d'une rigidité incroyable.

Je viens de faire un tour sur pGina. Ca a l'air vachement intéressant. Il manque cependant cet aspect "scripting" qui est la force de samba. J'ai pas l'impression que dans pGina, on puisse lancer des scripts ici ou là avec tout un tas de paramètre possible.

D'un autre coté, je ne suis pas spécialiste de PAM mais j'ai pas l'impression que cela ce scripte non plus. Le peu que j'en ai vu, ce sont surtout des greffons binaires avec des fichiers de configuration figé.

Tant mieux, le SIP est comme le H323, un truc mal fichu avec des ports à ouvrir de partout.

> sont respectés) ta page sera inutile. D'autre part le web doit rester
> ouvert, et bloquer l'accès au site si le webmaster aime pas le
> navigateur c'est pas terrible (de la même manière je n'aime pas les
> blocages d'autre chose qu'IE).

D'un autre coté, Microsoft signe a tour de bras des accords entre sociétés. Je ne connais pas les termes de ces accords mais ce que je vois en pratique, ce sont des sites programmés avec du VBScript alors que le Javascript suffit largement à la tache. Pour une page un peu plus lourde, ils mettent de l'activeX là où du java (voir du XUL...) marche très bien.

Pour ce qui est du java, il ne marche pas toujours sous Linux, cf le logiciel qui est dans les switch HP et qui rame à mort sous linux, voire plante... On ne me dira pas que l'interface web d'un switch a besoin d'être évolué.

Bref, Microsoft ne fait pas de cadeau et utilise tous les moyens pour poignarder son adversaire dans le dos.

Le dernier MISC n'est pas tendre vis à vis de Symantec. Tant pour l'antivirus que pour le parefeu.

Sachant que Symantec est numéro un sur ce domaine (à ma connaissance). Ils ont peut être du ménage à faire dans leur propre code.

Ils pourraient par exemple commencer à porter leur produit sous UNIX.

Et pourquoi pas XUL. Si on arrive a faire un firefox, ca doit bien marcher pour une autre IHM.

En pratique, ca dépend un peu du type d'IHM que l'on veut faire... Personnellement, je suis plus que tenté de faire toutes mes IHM en script.

Ca ne marche pas car dpkg a besoin des droits root pour écrire dans sa base de données les paquets qu'il a installé. Heureusement, je ne veux pas que n'importe qui me bousille ma base.

Ou, c'est peut être tout simplement celle qu'il utilise...

En effet, ca ne fait qu'un seul PC à installer et à mettre à jour. Ca ne fait aussi qu'une seule source de bruit...

Pour les écrans, ca devient dur d'acheter des tubes aujourd'hui.

Pour ce qui est des petits PC, j'ai des amis qui m'ont dis que la durée de vie de ces PC étaient assez faibles. Des retours d'expériences ?

Comme tu le dis : "c'est possible sans problème avec des soucis". Je crois que l'idée ici est d'avoir encore moins de soucis ;-)

Damned, tu m'as devancé de quelques minutes ;-) Mon commentaire plus bas n'a plus guère d'utilité ;-(

L'objectif est d'avoir un système multi-sièges. Donc trois écrans, trois claviers, trois souris, trois personnes et un seul PC dans le bureau.

L'intérêt est donc de faire les machines un peu plus que les 5% de charge actuelle moyenne... Surtout qu'avec les bi-corps qui arrivent, la capacité à répondre à une demande ponctuelle sera plus grande. Le fait de pouvoir partager une unité centrale est encore plus pertinente.

Je parlais de la place sur la barre du titre. Je viens de me relire et effecctivement, il manquait un mot. Une barre des titres plus étroite que la largeur de la fenêtre permet de voir eventuellement une fenêtre au second plan qu'on n'a pas envie de fusionner avec la première.

> Mais sous fluxbox tu as également la mise en onglet des fenetres

Cela, je le savais. Sinon, je ne serais même pas intervenu sur ce journal avec mon pwm ;-)

Enfin, c'est dommage, c'est de la place perdu. C'est très pratique de gagner ce petit bout de rectangle en haut à droite sur une fenêtre.

Deux petites questions de goût :

Est il possible d'avoir des bords de fenetre à la fvwm ou pwm ? Je n'aime pas du tout la forme NexTStep personnellement. J'aime bien pouvoir tirer la fenêtre par ses quatres coins. Sur les thèmes fournis par le fluxbox dans la GNU/Linux Debian Sarge, les fenêtres sont modifiables en taille que par les deux coins du bas.

Est'il possible d'avoir une barre de titre de la largeur du tire et non de la largeur de la fenêtre ? C'est une foncionalité de pwm que j'adore.

Sinon, fluxbox est très très tentant.

pwm

http://modeemi.fi/~tuomov/pwm/

fvwm

http://www.fvwm.org/

On peux esperer que lorsque OpenOffice2 sortira, le filtre d'export sera au point et on aura un openoffice-1.1.6 ;-)

Pour le moment, La version 2 n'est encore qu'en beta.

Presque toutes ! J'utilise un client lourd pour faire de la web-collaboration. Comme il n'y a pas de support USB, l'application ne peux pas fonctionner (pas de webcam). J'aurais aussi besoin du support son et microphone.

Sinon, pour les autres applications, ca marche très très bien.

Même si je suis à 99% sous Linux, ma secrétaire, pas mal de maître de conférence, de prof et de thésards sont sous Windows. Il y a deux choses vraiment bien avec svn :

-1- Un client Windows super (TortoiseSVN) stable et complétement intégré à l'explorateur de fichier. C'est vraiment facile à utiliser. J'ai amené pas mal de personne à utiliser un système de versionnement grace à ce client.

-2- Une gestion transparente des fichiers binaires. C'était un des défauts majeur de CVS.

Plus évidement pas mal d'autres défaut de CVS comme le fait de ne plus faire d'import sauf à l'initialisation du projet.

Il est vrai que le fait de ne pouvoir commiter dans le train est vraiment génant pour les développeurs. C'est idiot que svn ne le propose pas car il a déjà un cache de tous les fichiers du serveur en local dans ses dossiers .svn (afin notament de pouvoir faire des diff sans contact avec le serveur central). Il devrait donc être possible de faire des commits différés.

Pas à dire, la gestion de version décentralisé, c'est réellement le bazaar... Comment voulez vous que des non informaticiens investissent la dedans ? A coté de CVS et maintenant svn relativement stables et portables, les systèmes décentralisés, intéressants au demeurant, restent sur le bas coté.

N'est'il pas possible de regrouper les forces, d'écrire un cahier des charges (comme au temps du début de subversion) et de programmer ensuite un truc solide et pérenne ?

J'ai trouvé ici ou là des bouts de documentation mais il m'a manqué assez souvent un petit bout. Le réseau qui ne marche pas à cause d'un problème de pare-feu, le script ifup n'est pas installé...

J'ai donc décidé d'écrire bêtement ma procédure et je vous la partage. Ca date de début juillet mais pas grand chose n'est à modifier...

Je suis sous GNU/Linux Debian Sarge. A part les quelques commandes sur les paquetages Debian, le reste doit-être quasiment identique sous une autre distribution.

----------------------------
--- Installation de qemu ---
----------------------------

Récuperation de la dernière snapshot de qemu sur

http://www.dad-answers.com/qemu/

Par exemple, le fichier

qemu-snapshot-2005-07-07_23.tar.bz2

Ce qui peux se faire avec l'uniligne

wget http://www.dad-answers.com/qemu/qemu-snapshot-2005-07-07_23.tar.bz2

On extrait les fichiers de l'archive

tar xvjf qemu-snapshot-2005-07-07_23.tar.bz2

Récuperation de kqemu sur

http://fabrice.bellard.free.fr/qemu/download.html

par exemple le fichier

kqemu-0.6.2-1.tar.gz

Ce qui peux se faire avec l'uniligne

wget http://fabrice.bellard.free.fr/qemu/kqemu-0.6.2-1.tar.gz

On extrait les fichiers dans le dossier qemu-snapshot-2005-07-07_23

cd qemu-snapshot-2005-07-07_23
tar xvzf ../kqemu-0.6.2-1.tar.gz

Récuperation des en-tête du noyau (2.4) ou des sources du noyau (2.6). On met le lien à jour vers linux et on change les droits pour qu'un utilisateur lambda puisse modifier les sources !

sux
aptitude install kernel-headers-2.4.27-2-686
cd /usr/src
rm -f linux
ln -s kernel-headers-2.4.27-2-686 linux
chmod -R ugo+rwX kernel-headers-2.4.27-2-686
chmod -R ugo+rwX kernel-headers-2.4.27-2

On installe les paquets qui manque généralement et on vire le paquet qemu qui gêne.

sux
aptitude install libsdl1.2-dev uml-utilities texi2html sudo
aptitude purge qemu

On retourne en utilisateur lambda dans son dossier qemu

cd qemu-snapshot-2005-07-07_23
./configure

On doit avoir la ligne SDL et kqemu à 'yes'.

make

On retourne sous le compte root pour faire l'installation et bidouiller un fichier système qui manque ensuite (si on veut le réseau) et on installe de nouveau les sources propres

sux
make install

echo '#!/bin/sh' > /etc/qemu-ifup
echo 'sudo -p "Password for $0:" /sbin/ifconfig $1 172.20.0.1' >> /etc/qemu-ifup
chmod a+rx /etc/qemu-ifup

aptitude reinstall kernel-headers-2.4.27-2-686 kernel-headers-2.4.27-2

On fait de même avec sudo. Lancer en root la commande

sux
grep -q '%users ALL = NOPASSWD: /sbin/ifconfig tun0 172.20.0.1' /etc/sudoers || echo '%users ALL = NOPASSWD: /sbin/ifconfig tun0 172.20.0.1' >> /etc/sudoers
/etc/init.d/sudo start

Activer le port forwarding dans le noyau. Mettre les bonnes règles pour faire du NAT.

sux
grep -q 'net/ipv4/ip_forward=1' /etc/sysctl.conf || echo 'net/ipv4/ip_forward=1' >> /etc/sysctl.conf
sysctl -p

/sbin/iptables -A INPUT -i tun0 -j ACCEPT
/sbin/iptables -A OUTPUT -o tun0 -j ACCEPT
/sbin/iptables -A FORWARD -i tun0 -j ACCEPT
/sbin/iptables -A FORWARD -o tun0 -j ACCEPT
/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
/sbin/iptables -A FORWARD -s 172.20.0.0/24 -i tun0 -o eth0 -p tcp -j ACCEPT

On peux sauver les règles iptables pour un prochain reboot

sux
/etc/init.d/iptable save active

On charge les modules noyaux

sux
modprobe kqemu
modprobe tun

Ou pour garder apres un reboot (noyau 2.4)

sux
grep -q 'kqemu' /etc/modules || echo 'kqemu' >> /etc/modules
grep -q 'tun' /etc/modules || echo 'tun' >> /etc/modules

Si cela marche pas, il peux manquer le périphérique kqemu. Normalement, l'installation doit avoir tout fait.

sux
mknod /dev/kqemu c 250 0
chmod 666 /dev/kqemu

De tête, ca ressemble à ça... Cependant, mes différents CD avec leur licences "corporate" n'ont pas marché ;-( L'installation bloque toujours au même niveau.

Mon Win2k n'as jamais passé l'installation complète. Il faut que j'essaye avec cette version. J'ai eu un CD de XP qui a eu la chance de ne pas bloquer à l'installation.

Faut que je tente de nouveau 2000 car les deux ne se comportent pas toujours de la même manière.

Il y a aussi rssh qui est lui-aussi un shell restreint ne permettant que les commandes scp, sftp, cvs, rsync et rdist.

Ce qui est bien avec ce shell est que l'on peut configurer les commandes acceptées. Ce qui manque est que la liste des commandes est paramétrées en dur. J'aurais bien rajouté unison à cette liste.