Re: CD-ROM RedHat 6.2
Ce 26 octobre Narc Schaefer a écrit: > On Thu, 24 Oct 2002, Félix Hauri wrote: > > > Si vraiement, ce sera volontier, mais il me semble que si tu parles d'un > > cluster de 12 machines identiques, je ne comprend pas pourquoi tu ne > > tentes pas un ``clonage''. > > En particulier vu que Red Hat dispose d'un système d'installation > automatisé de machines individuelles (kickstart), plus propre et adaptable > qu'un simple clonage. Le clonage après installation a aussi d'autres avantages, pour tout ce qu'on peut vouloir configurer après l'installation. > > Sinon, essaie Debian! C'est sympa à administrer! > > Dans ce cas FAI pourrait être intéressant pour dupliquer/documenter > l'installation, en particulier dans le cas où plusieurs machines sont à > intégrer dans un réseau. C'est quoi FAI? > Sinon, le clonage est toujours possible, avec adaptation de > /etc/network/interfaces et du hostname. Quel outil de clonage est le plus confortable? Les serveurs DHCP évitent la gestion des hostname/adresse IP. Anne -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Samba
On Mon, 21 Oct 2002, Blaise Vogel wrote: > > De plus, je n'ai pas vraiment bien compris la gestion des utilisateurs de > > samba. Est-t-il possible de créer des utilisateurs avec un mot de passe qui > > soient complètement indépendants des utilisateurs Linux ? Si oui, comment ? > A ma connaissance, non > elcap:/home/blaise# smbpasswd -a essai > New SMB password: > Retype new SMB password: > User essai does not exist in system password file (usually /etc/passwd). > Cannot > add account without a valid local system user. > Failed to modify password entry for user essai Effectivement, vu que les accès sont en règle générale faits sous le bon UID/GID. Maintenant, pour corriger le problème, soit 8 caractères, il y a: username map (G) This option allows you to specify a file containing a mapping of usernames from the clients to the server. This can be used for several purposes. The most common is to map usernames that users use on DOS or Windows machines to those that the UNIX box uses. The other is to map multiple users to a sin gle username so that they can more easily share files. [ ... ] cf man 5 smb.conf -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: CD-ROM RedHat 6.2
On Thu, 24 Oct 2002, FLUO wrote: > Mais est-ce que mettre juste le noyau 2.4.19 et les 2-3 programmes qui > font tourner un noeud est plus consommateur en ressources qu'un 2.2.x et > ces mêmes 2-3 programmes? > Je pensait que c'était juste les interface graphiques qui bouffaient > plus de ressources. 2.4.x a un comportement mémoire virtuelle souvent moins efficace que 2.2.x, encore que cela dépende des patches et de la configuration de bdflush. Pour le moment ces comportements n'ont pas été un problème pour moi, sauf peut-être en utilisation desktop. Il est d'ailleurs intéressant de constater que l'amélioration de la gestion des verrous en 2.4 (plus de big kernel lock ou presque) a coincidé avec du verrouillage moins efficace ce qui augmente les temps de latence et crée des problèmes jamais vus auparavant sur le même matériel (erreurs de gravage, son qui s'arrête, mauvaise interactivité). Il y a un patch `low latency' pour améliorer cela. Pas encore investigué à fond. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: CD-ROM RedHat 6.2
On Thu, 24 Oct 2002, Félix Hauri wrote: > Si vraiement, ce sera volontier, mais il me semble que si tu parles d'un > cluster de 12 machines identiques, je ne comprend pas pourquoi tu ne > tentes pas un ``clonage''. En particulier vu que Red Hat dispose d'un système d'installation automatisé de machines individuelles (kickstart), plus propre et adaptable qu'un simple clonage. > Sinon, essaie Debian! C'est sympa à administrer! Dans ce cas FAI pourrait être intéressant pour dupliquer/documenter l'installation, en particulier dans le cas où plusieurs machines sont à intégrer dans un réseau. Sinon, le clonage est toujours possible, avec adaptation de /etc/network/interfaces et du hostname. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: message de mail
On Thu, 24 Oct 2002, Dominique Muller wrote: > Au fait, il y aurait pas un moyen pour que les robots des spammeurs ne > puissent pas atteindre les archives de la mail-liste ? Sinon coder les > adresses e-mail ou mettre un mot de passe publique ? Les archives de search.alphanet.ch sont inaccessibles aux engins de recherche (en théorie du moins). On pourrait saboter les adresses e-mail sauf à des personnes enregistrées (patch aux sources de l'interface acceptés). Les autres archives (sous mail.archive.com je crois) sont gérées par un tiers et je n'ai pas regardé. Des archives privées existent peut-être également de façon libre. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: RE : personnel à lhermann@alu
On Fri, 25 Oct 2002, Nicolazzi Marc (DIP) wrote: > Bizarre, mon adresse de retour. [ ... ] > De : Jean-Bruno Luginbühl [mailto:jean_bruno_luginbuhl@;yahoo.fr] Cette ligne est générée par un client mail défectueux: il s'agit d'un entête artificiel qui ne correspond à aucun standard. Ne pas tirer de conclusions. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: mysql search sur les chars avec accents
On Fri, 25 Oct 2002, Slava Zimine wrote: > pourquoi si on fait le search sur le field type 'varchar' le SELECT > ne differencie pas les chars avec ou sans accents? Une idée serait de faire: > je sais que le changement du field vers 'varchar binary' va resoundre > mon problem, mais aussi le SELECT devient case sensitive. SELECT * FROM uhc WHERE lowcase(uhc_longname) = 'nestle'; trouver cette fonction lowcase devrait résoudre ton problème, non ? -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: File system multi os (linux / hpux) à exécution distante (!)
On Sat, 26 Oct 2002, Jean-Claude Schopfer wrote: > /mnt/hpux/monprog < /tmp/config.in > /tmp/monprog.out 2>&1 ssh hpux -l user /data/export/monprog \ < /tmp/config.in > /tmp/monprog.out \ 2>&1 cela suppose que /data/export est le répertoire sur la machine HP/UX et que /data/export/monprog fonctionne sous HP UX et que l'utilisateur est équivalent pour l'authentification (hosts.equiv avec clé d'hôte SSH) sur les machines du réseau. > - modifier le noyau linux pour lui dire que si on essaie > d'exécuter un code se trouvant dans tel ou tel point > de montage, il doit effectuer manière transparente > une connection ssh ? Une façon simple serait que /data/export/mon_programme soit un lien symbolique pointant sur /system-specifics/mon_programme. Lorsque tu lances /mnt/hpux/monprog, cela exécute en fait /system-specifics/mon_programme, un shell script. Si la machine est HPUX (uname -a) lancer /mnt/hpux/monprog.arch-hpux. Sinon, lancer ce qui précède (le ssh, adapter les path). Un script pourrait être écrit pour générer un tel wrapper pour tous les binaires de /data/export/bin, et copier ce wrapper sur les machines. Un wrapper unique pourrait être créé car `basename $0` contient en principe le nom du programme exécuté. Modifier le kernel Linux -- dans ce cas écrire un petit wrapper de système de fichier podfuk en Perl, la difficulté étant d'exécuter le programme sous le bon UID de façon sûre -- devrait être possible, et finalement pas si dur, mais la méthode des liens symboliques ci-dessus a l'avantage de marcher sur n'importe quelle plateforme. > - modifier NFS pour qu'il puisse traiter ce genre de truc ? Certaines versions de systèmes de fichiers réseau (je pense à DomainOS) pouvait contenir des sentier contenant des variables étendues à l'accès. P.ex. /etc/passwd étant en fait /etc/$UNIVERSE/passwd, avec UNIVERSE sysv, bsd ou aegis. > La question est également valable pour deux os de même nature > (linux). Le principe général du système MOSIX est l'exécution transparente d'un programme sur une machine donnée et sa migration, y compris ses flots d'entrée/sortie, voire y compris avec une optimisation d'accès via le mosix file system. Il y a des restrictions quant aux programmes exécutables. MOSIX à ma connaissance ne fonctionne pas à travers les plateformes non binaires-compatibles. Il existe cependant pour d'autres systèmes libres que Linux. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: File system multi os (linux / hpux)
On Sat, 26 Oct 2002 11:06:42 +0200 Jean-Claude Schopfer <[EMAIL PROTECTED]> wrote: > Hellow, > > Attention c long :p > > Le problème que je vais vous présenter ici est très simple mais > sa résolution semble impliquer de lourds développements. > > J'ai une machine x qui tourne sous linux sur une plateforme x86 > cette machine accède depuis /mnt/hpux à un environnement nfs > exporté depuis un serveur qui tourne sur hpux (pa-risc). > > Jusqu'ici aucun problème. je peux lire les informations du > répertoire exporté, je ne peux pas écrire vu que j'en ai pas > les droits, le bonheur koi... > > Vue depuis la machine linux : > > / --> linux > /mnt/hpux --> serveur hpux > > Là où cela se complique c'est que j'ai besoin de pouvoir > exécuter un programme qui se trouve dans ce point de montage > mais PAS EN LOCAL (de toute façon ça ne marcherai pas, vu > que l'architecture est différente) mais bel et bien sur le > serveur. > > Exemple : > > /mnt/hpux/monprog < /tmp/config.in > /tmp/monprog.out 2>&1 > > (cet exemple ne peut pas être modifié, je ne peux pas > lancer inclure une autre commande style ssh, rsh, remsh à cet endroit) je m'y connais pas trop, mais une solution avec rpc (remote procedure call) ne serait pas possible non plus ? il faudrait écrire un programe client qui contacte un programe serveur sur hpux, et lui transmette stdin, et le programe serveur lance 'monprog', en lui donnant stdin et en récuperant stdout pour retransmettre ce dernier au programe client ? Martin -- Open your Windows - Free your Mind - Enjoy http://gnuwin.epfl.ch Martin Herren +41 (0)79 746 57 83 OpenPGP Public key @ http://www.on-the-web.ch/sputnik/gpg.asc msg09270/pgp0.pgp Description: PGP signature
Re: File system multi os(linux / hpux) à exécution distante(!)
On Sat, 26 Oct 2002, Jean-Claude Schopfer wrote: > Hellow, > > Là où cela se complique c'est que j'ai besoin de pouvoir > exécuter un programme qui se trouve dans ce point de montage > mais PAS EN LOCAL (de toute façon ça ne marcherai pas, vu > que l'architecture est différente) mais bel et bien sur le > serveur. > > Exemple : > > /mnt/hpux/monprog < /tmp/config.in > /tmp/monprog.out 2>&1 > > (cet exemple ne peut pas être modifié, je ne peux pas > lancer inclure une autre commande style ssh, rsh, remsh à cet endroit) Bon, est-ce que tu peux faire pointer /tmp/config.in ou /tmp/monprog.out sur des fifo? > je n'ai aucun moyen d'action sur le serveur hpux, je n'ai > pas d'accès sur l'entier du file system, juste une lecture > sur ce répertoire via aujourd'hui nfs. l'administrateur > serait théoriquement disposé à m'offrir l'exécution distante > de ce répertoire si cela était possible. > > quelles serait la solution ? > > - modifier le noyau linux pour lui dire que si on essaie > d'exécuter un code se trouvant dans tel ou tel point > de montage, il doit effectuer manière transparente > une connection ssh ? Me parait complique, je pense qu'entre les tuyaux et les chaussettes, tu dois avoir moyen de moyenner. > - modifier NFS pour qu'il puisse traiter ce genre de truc ? La aussi tu peux bricoler mais la aussi cela me parait compliqué. > - modifier et utiliser chroot pour des exécutions distantes ? ?? > La question est également valable pour deux os de même nature > (linux). > c'est un long débat, de grandes questions, c'est une manière > complétement différente d'aborder les unix...des connections > ssh permanantes via des points de montages permettant l'exécution > distante... avec les stdin et stdout qui fonctionnent cross > os et cross plateforme...plus besoin d'émulateur pour des > applications simples... Tu peux aussi t'amuser a faire tourner un script en permanence sur ton hp-ux, qui attend ses IO standards de deux fifos: Sur HP-UX: --- stdscript.sh -- #!/bin/sh $HOME/bin/monprog < $HOME/fifo.in > /$HOME/fifo.out 2>&1 --- loop.sh -- while true ; do stdscript.sh ; done et sur les machines distante: cat config.in |ssh HPUX cat \>fifo.in & ssh HPUX cat fifo.out >monprog.out > La question est aussi surtout, avez-vous déjà entendu parler > de ce genre de gag ? Le vrai sens de l'expression ``Partage des ressources''... Je m'amuse tous les jours à ce genre de gags ;-) > vlà c tout pour le moment, en informatique, rien n'est impossible, > non ? :p Pire! It's more than one way to do it! Tu peux aussi utiliser ``xinetd'' (voire inetd selon niveau sécurité), sur hp-ux... -- Félix Hauri - <[EMAIL PROTECTED]> - http://www.f-hauri.ch -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
File system multi os (linux / hpux) à exécution distante (!)
Hellow, Attention c long :p Le problème que je vais vous présenter ici est très simple mais sa résolution semble impliquer de lourds développements. J'ai une machine x qui tourne sous linux sur une plateforme x86 cette machine accède depuis /mnt/hpux à un environnement nfs exporté depuis un serveur qui tourne sur hpux (pa-risc). Jusqu'ici aucun problème. je peux lire les informations du répertoire exporté, je ne peux pas écrire vu que j'en ai pas les droits, le bonheur koi... Vue depuis la machine linux : / --> linux /mnt/hpux --> serveur hpux Là où cela se complique c'est que j'ai besoin de pouvoir exécuter un programme qui se trouve dans ce point de montage mais PAS EN LOCAL (de toute façon ça ne marcherai pas, vu que l'architecture est différente) mais bel et bien sur le serveur. Exemple : /mnt/hpux/monprog < /tmp/config.in > /tmp/monprog.out 2>&1 (cet exemple ne peut pas être modifié, je ne peux pas lancer inclure une autre commande style ssh, rsh, remsh à cet endroit) monprog ne fonctionne que sur hpux, je n'ai pas les sources donc aucun moyen de l'exécuter sur le proc de la machine linux. je n'ai aucun moyen d'action sur le serveur hpux, je n'ai pas d'accès sur l'entier du file system, juste une lecture sur ce répertoire via aujourd'hui nfs. l'administrateur serait théoriquement disposé à m'offrir l'exécution distante de ce répertoire si cela était possible. quelles serait la solution ? - modifier le noyau linux pour lui dire que si on essaie d'exécuter un code se trouvant dans tel ou tel point de montage, il doit effectuer manière transparente une connection ssh ? - modifier NFS pour qu'il puisse traiter ce genre de truc ? - modifier et utiliser chroot pour des exécutions distantes ? La question est également valable pour deux os de même nature (linux). Idem pour les liens symboliques. Si aujourd'hui j'ai un lien symbolique tata dans le répertoire qui pointe vers /tmp/toto et que je fais cat /mnt/hpux/tata, c'est le /tmp/toto de linux qui va s'afficher... un /mnt/hpux/reboot rebooterait le serveur hpux (pour autant que j'en ai le droit évidemment et que reboot pointe vers la véritable commande reboot)... c'est un long débat, de grandes questions, c'est une manière complétement différente d'aborder les unix...des connections ssh permanantes via des points de montages permettant l'exécution distante... avec les stdin et stdout qui fonctionnent cross os et cross plateforme...plus besoin d'émulateur pour des applications simples... La question est aussi surtout, avez-vous déjà entendu parler de ce genre de gag ? vlà c tout pour le moment, en informatique, rien n'est impossible, non ? :p @++ JC -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
