Petit probleme du jour, j'essaie desesperement d'utiliser un client
FreeBSD (i386) sur un serveur NIS NetBSD (sparc64).
Le serveur NetBSD fonctionne. J'arrive a lancer ypcat passwd, a me
connecter en local, a recupere les informations sur un client Linux.
En revanche, le client FreeBSD merdoie dans les grandes largeurs et
je n'ai rien trouve pour corriger le tir.
Le processus ypbind sur le nisdomain rend immediatement la main,
prouvant qu'il atteint bien le serveur. Mais je ne recupere aucune
des tables NIS. Je ne vois pas bien d'ou provient le
dysfonctionnement.
Sur le serveur, les tables sont dans /var/yp/domainname
legendre# ls -l
total 1168
-r-------- 1 root wheel 12798 Aug 2 11:12 Makefile
-rw-r--r-- 1 root wheel 0 Aug 2 11:16 aliases.time
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 group.bygid.db
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 group.byname.db
-rw-r--r-- 1 root wheel 0 Aug 2 11:16 group.time
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 hosts.byaddr.db
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 hosts.byname.db
-rw-r--r-- 1 root wheel 0 Aug 2 11:16 hosts.time
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 ipnodes.byaddr.db
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 ipnodes.byname.db
-rw-r--r-- 1 root wheel 0 Aug 2 11:16 ipnodes.time
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 mail.aliases.db
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 mail.byaddr.db
-rw------- 1 root wheel 32768 Aug 2 11:16 master.passwd.byname.db
-rw------- 1 root wheel 32768 Aug 2 11:16 master.passwd.byuid.db
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 netid.byname.db
-rw-r--r-- 1 root wheel 0 Aug 2 11:16 netid.time
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 networks.byaddr.db
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 networks.byname.db
-rw-r--r-- 1 root wheel 0 Aug 2 11:16 networks.time
-rw------- 1 root wheel 32768 Aug 2 11:16 passwd.byname.db
-rw------- 1 root wheel 32768 Aug 2 11:16 passwd.byuid.db
-rw------- 1 root wheel 0 Aug 2 11:16 passwd.time
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 protocols.byname.db
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 protocols.bynumber.db
-rw-r--r-- 1 root wheel 0 Aug 2 11:16 protocols.time
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 rpc.bynumber.db
-rw-r--r-- 1 root wheel 0 Aug 2 11:16 rpc.time
-rw-r--r-- 1 root wheel 540672 Aug 2 11:16 services.byname.db
-rw-r--r-- 1 root wheel 0 Aug 2 11:16 services.time
-rw------- 1 root wheel 42 Aug 2 11:12 ypservers
-rw------- 1 root wheel 32768 Aug 2 11:12 ypservers.db
legendre#
Sur le client, un ypcat passwd ne rend pas la main (il n'echoue meme
pas sur un timeout).
Une idee ?
Cordialement,
JKB
PS: desole pour le manque d'accent, je poste depuis une antique vt100
qui ne les comprend pas...
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
JKB
Le Sat, 2 Aug 2014 10:10:00 +0000 (UTC), JKB écrivait :
Bonjour a tous,
Petit probleme du jour, j'essaie desesperement d'utiliser un client FreeBSD (i386) sur un serveur NIS NetBSD (sparc64).
Le serveur NetBSD fonctionne. J'arrive a lancer ypcat passwd, a me connecter en local, a recupere les informations sur un client Linux. En revanche, le client FreeBSD merdoie dans les grandes largeurs et je n'ai rien trouve pour corriger le tir.
Le processus ypbind sur le nisdomain rend immediatement la main, prouvant qu'il atteint bien le serveur. Mais je ne recupere aucune des tables NIS. Je ne vois pas bien d'ou provient le dysfonctionnement.
Sur le serveur, les tables sont dans /var/yp/domainname
legendre# ls -l total 1168 -r-------- 1 root wheel 12798 Aug 2 11:12 Makefile -rw-r--r-- 1 root wheel 0 Aug 2 11:16 aliases.time -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 group.bygid.db -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 group.byname.db -rw-r--r-- 1 root wheel 0 Aug 2 11:16 group.time -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 hosts.byaddr.db -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 hosts.byname.db -rw-r--r-- 1 root wheel 0 Aug 2 11:16 hosts.time -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 ipnodes.byaddr.db -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 ipnodes.byname.db -rw-r--r-- 1 root wheel 0 Aug 2 11:16 ipnodes.time -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 mail.aliases.db -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 mail.byaddr.db -rw------- 1 root wheel 32768 Aug 2 11:16 master.passwd.byname.db -rw------- 1 root wheel 32768 Aug 2 11:16 master.passwd.byuid.db -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 netid.byname.db -rw-r--r-- 1 root wheel 0 Aug 2 11:16 netid.time -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 networks.byaddr.db -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 networks.byname.db -rw-r--r-- 1 root wheel 0 Aug 2 11:16 networks.time -rw------- 1 root wheel 32768 Aug 2 11:16 passwd.byname.db -rw------- 1 root wheel 32768 Aug 2 11:16 passwd.byuid.db -rw------- 1 root wheel 0 Aug 2 11:16 passwd.time -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 protocols.byname.db -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 protocols.bynumber.db -rw-r--r-- 1 root wheel 0 Aug 2 11:16 protocols.time -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 rpc.bynumber.db -rw-r--r-- 1 root wheel 0 Aug 2 11:16 rpc.time -rw-r--r-- 1 root wheel 540672 Aug 2 11:16 services.byname.db -rw-r--r-- 1 root wheel 0 Aug 2 11:16 services.time -rw------- 1 root wheel 42 Aug 2 11:12 ypservers -rw------- 1 root wheel 32768 Aug 2 11:12 ypservers.db legendre#
Sur le client, un ypcat passwd ne rend pas la main (il n'echoue meme pas sur un timeout).
Une idee ?
Cordialement,
JKB
PS: desole pour le manque d'accent, je poste depuis une antique vt100 qui ne les comprend pas...
Quelques precisions. J'ai l'impression que le serveur netbsd ne repond pas aux requetes rpl du NIS. Pour les pontages NFS, ca fonctionne pourtant normalement depuis le meme client.
13:02:35.617190 IP 192.168.0.102.49742 > 192.168.0.255.sunrpc: UDP, length 112 13:02:35.617220 IP 192.168.0.102.49742 > 192.168.0.255.sunrpc: UDP, length 112 13:02:43.623320 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP, length 112 13:02:43.623439 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP, length 112 13:02:43.623472 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP, length 112 13:02:43.623503 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP, length 112 13:02:47.636476 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP, length 112 13:02:47.636566 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP, length 112 13:02:47.636587 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP, length 112 13:02:47.636625 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP, length 112 13:02:55.646495 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP, length 112 13:02:55.646600 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP, length 112 13:02:55.646635 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP, length 112 13:02:55.646666 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP, length 112 13:02:59.657718 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP, length 112 13:02:59.657812 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP, length 112 13:02:59.657844 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP, length 112 13:02:59.657876 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP, length 112 13:03:07.663208 IP 192.168.0.102.34051 > 192.168.0.255.sunrpc: UDP, length 112 13:03:07.663314 IP 192.168.0.102.34051 > 192.168.0.255.sunrpc: UDP, length 112 13:03:07.663355 IP 192.168.0.102.34051 > 192.168.0.255.sunrpc: UDP, length 112 13:03:07.663387 IP 192.168.0.102.34051 > 192.168.0.255.sunrpc: UDP, length 112 13:03:11.676807 IP 192.168.0.102.34051 > 192.168.0.255.sunrpc: UDP, length 112 13:03:11.676900 IP 192.168.0.102.34051 > 192.168.0.255.sunrpc: UDP, length 112
Etrange.
JKB
Le Sat, 2 Aug 2014 10:10:00 +0000 (UTC),
JKB <jkb@koenigsberg.invalid> écrivait :
Bonjour a tous,
Petit probleme du jour, j'essaie desesperement d'utiliser un client
FreeBSD (i386) sur un serveur NIS NetBSD (sparc64).
Le serveur NetBSD fonctionne. J'arrive a lancer ypcat passwd, a me
connecter en local, a recupere les informations sur un client Linux.
En revanche, le client FreeBSD merdoie dans les grandes largeurs et
je n'ai rien trouve pour corriger le tir.
Le processus ypbind sur le nisdomain rend immediatement la main,
prouvant qu'il atteint bien le serveur. Mais je ne recupere aucune
des tables NIS. Je ne vois pas bien d'ou provient le
dysfonctionnement.
Sur le serveur, les tables sont dans /var/yp/domainname
legendre# ls -l
total 1168
-r-------- 1 root wheel 12798 Aug 2 11:12 Makefile
-rw-r--r-- 1 root wheel 0 Aug 2 11:16 aliases.time
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 group.bygid.db
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 group.byname.db
-rw-r--r-- 1 root wheel 0 Aug 2 11:16 group.time
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 hosts.byaddr.db
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 hosts.byname.db
-rw-r--r-- 1 root wheel 0 Aug 2 11:16 hosts.time
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 ipnodes.byaddr.db
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 ipnodes.byname.db
-rw-r--r-- 1 root wheel 0 Aug 2 11:16 ipnodes.time
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 mail.aliases.db
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 mail.byaddr.db
-rw------- 1 root wheel 32768 Aug 2 11:16 master.passwd.byname.db
-rw------- 1 root wheel 32768 Aug 2 11:16 master.passwd.byuid.db
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 netid.byname.db
-rw-r--r-- 1 root wheel 0 Aug 2 11:16 netid.time
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 networks.byaddr.db
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 networks.byname.db
-rw-r--r-- 1 root wheel 0 Aug 2 11:16 networks.time
-rw------- 1 root wheel 32768 Aug 2 11:16 passwd.byname.db
-rw------- 1 root wheel 32768 Aug 2 11:16 passwd.byuid.db
-rw------- 1 root wheel 0 Aug 2 11:16 passwd.time
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 protocols.byname.db
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 protocols.bynumber.db
-rw-r--r-- 1 root wheel 0 Aug 2 11:16 protocols.time
-rw-r--r-- 1 root wheel 32768 Aug 2 11:16 rpc.bynumber.db
-rw-r--r-- 1 root wheel 0 Aug 2 11:16 rpc.time
-rw-r--r-- 1 root wheel 540672 Aug 2 11:16 services.byname.db
-rw-r--r-- 1 root wheel 0 Aug 2 11:16 services.time
-rw------- 1 root wheel 42 Aug 2 11:12 ypservers
-rw------- 1 root wheel 32768 Aug 2 11:12 ypservers.db
legendre#
Sur le client, un ypcat passwd ne rend pas la main (il n'echoue meme
pas sur un timeout).
Une idee ?
Cordialement,
JKB
PS: desole pour le manque d'accent, je poste depuis une antique vt100
qui ne les comprend pas...
Quelques precisions. J'ai l'impression que le serveur netbsd ne
repond pas aux requetes rpl du NIS. Pour les pontages NFS, ca
fonctionne pourtant normalement depuis le meme client.
13:02:35.617190 IP 192.168.0.102.49742 > 192.168.0.255.sunrpc: UDP,
length 112
13:02:35.617220 IP 192.168.0.102.49742 > 192.168.0.255.sunrpc: UDP,
length 112
13:02:43.623320 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP,
length 112
13:02:43.623439 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP,
length 112
13:02:43.623472 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP,
length 112
13:02:43.623503 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP,
length 112
13:02:47.636476 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP,
length 112
13:02:47.636566 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP,
length 112
13:02:47.636587 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP,
length 112
13:02:47.636625 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP,
length 112
13:02:55.646495 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP,
length 112
13:02:55.646600 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP,
length 112
13:02:55.646635 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP,
length 112
13:02:55.646666 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP,
length 112
13:02:59.657718 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP,
length 112
13:02:59.657812 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP,
length 112
13:02:59.657844 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP,
length 112
13:02:59.657876 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP,
length 112
13:03:07.663208 IP 192.168.0.102.34051 > 192.168.0.255.sunrpc: UDP,
length 112
13:03:07.663314 IP 192.168.0.102.34051 > 192.168.0.255.sunrpc: UDP,
length 112
13:03:07.663355 IP 192.168.0.102.34051 > 192.168.0.255.sunrpc: UDP,
length 112
13:03:07.663387 IP 192.168.0.102.34051 > 192.168.0.255.sunrpc: UDP,
length 112
13:03:11.676807 IP 192.168.0.102.34051 > 192.168.0.255.sunrpc: UDP,
length 112
13:03:11.676900 IP 192.168.0.102.34051 > 192.168.0.255.sunrpc: UDP,
length 112
Le Sat, 2 Aug 2014 10:10:00 +0000 (UTC), JKB écrivait :
Bonjour a tous,
Petit probleme du jour, j'essaie desesperement d'utiliser un client FreeBSD (i386) sur un serveur NIS NetBSD (sparc64).
Le serveur NetBSD fonctionne. J'arrive a lancer ypcat passwd, a me connecter en local, a recupere les informations sur un client Linux. En revanche, le client FreeBSD merdoie dans les grandes largeurs et je n'ai rien trouve pour corriger le tir.
Le processus ypbind sur le nisdomain rend immediatement la main, prouvant qu'il atteint bien le serveur. Mais je ne recupere aucune des tables NIS. Je ne vois pas bien d'ou provient le dysfonctionnement.
Sur le serveur, les tables sont dans /var/yp/domainname
legendre# ls -l total 1168 -r-------- 1 root wheel 12798 Aug 2 11:12 Makefile -rw-r--r-- 1 root wheel 0 Aug 2 11:16 aliases.time -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 group.bygid.db -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 group.byname.db -rw-r--r-- 1 root wheel 0 Aug 2 11:16 group.time -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 hosts.byaddr.db -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 hosts.byname.db -rw-r--r-- 1 root wheel 0 Aug 2 11:16 hosts.time -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 ipnodes.byaddr.db -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 ipnodes.byname.db -rw-r--r-- 1 root wheel 0 Aug 2 11:16 ipnodes.time -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 mail.aliases.db -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 mail.byaddr.db -rw------- 1 root wheel 32768 Aug 2 11:16 master.passwd.byname.db -rw------- 1 root wheel 32768 Aug 2 11:16 master.passwd.byuid.db -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 netid.byname.db -rw-r--r-- 1 root wheel 0 Aug 2 11:16 netid.time -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 networks.byaddr.db -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 networks.byname.db -rw-r--r-- 1 root wheel 0 Aug 2 11:16 networks.time -rw------- 1 root wheel 32768 Aug 2 11:16 passwd.byname.db -rw------- 1 root wheel 32768 Aug 2 11:16 passwd.byuid.db -rw------- 1 root wheel 0 Aug 2 11:16 passwd.time -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 protocols.byname.db -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 protocols.bynumber.db -rw-r--r-- 1 root wheel 0 Aug 2 11:16 protocols.time -rw-r--r-- 1 root wheel 32768 Aug 2 11:16 rpc.bynumber.db -rw-r--r-- 1 root wheel 0 Aug 2 11:16 rpc.time -rw-r--r-- 1 root wheel 540672 Aug 2 11:16 services.byname.db -rw-r--r-- 1 root wheel 0 Aug 2 11:16 services.time -rw------- 1 root wheel 42 Aug 2 11:12 ypservers -rw------- 1 root wheel 32768 Aug 2 11:12 ypservers.db legendre#
Sur le client, un ypcat passwd ne rend pas la main (il n'echoue meme pas sur un timeout).
Une idee ?
Cordialement,
JKB
PS: desole pour le manque d'accent, je poste depuis une antique vt100 qui ne les comprend pas...
Quelques precisions. J'ai l'impression que le serveur netbsd ne repond pas aux requetes rpl du NIS. Pour les pontages NFS, ca fonctionne pourtant normalement depuis le meme client.
13:02:35.617190 IP 192.168.0.102.49742 > 192.168.0.255.sunrpc: UDP, length 112 13:02:35.617220 IP 192.168.0.102.49742 > 192.168.0.255.sunrpc: UDP, length 112 13:02:43.623320 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP, length 112 13:02:43.623439 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP, length 112 13:02:43.623472 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP, length 112 13:02:43.623503 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP, length 112 13:02:47.636476 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP, length 112 13:02:47.636566 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP, length 112 13:02:47.636587 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP, length 112 13:02:47.636625 IP 192.168.0.102.10275 > 192.168.0.255.sunrpc: UDP, length 112 13:02:55.646495 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP, length 112 13:02:55.646600 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP, length 112 13:02:55.646635 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP, length 112 13:02:55.646666 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP, length 112 13:02:59.657718 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP, length 112 13:02:59.657812 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP, length 112 13:02:59.657844 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP, length 112 13:02:59.657876 IP 192.168.0.102.60136 > 192.168.0.255.sunrpc: UDP, length 112 13:03:07.663208 IP 192.168.0.102.34051 > 192.168.0.255.sunrpc: UDP, length 112 13:03:07.663314 IP 192.168.0.102.34051 > 192.168.0.255.sunrpc: UDP, length 112 13:03:07.663355 IP 192.168.0.102.34051 > 192.168.0.255.sunrpc: UDP, length 112 13:03:07.663387 IP 192.168.0.102.34051 > 192.168.0.255.sunrpc: UDP, length 112 13:03:11.676807 IP 192.168.0.102.34051 > 192.168.0.255.sunrpc: UDP, length 112 13:03:11.676900 IP 192.168.0.102.34051 > 192.168.0.255.sunrpc: UDP, length 112
Etrange.
JKB
Michel Talon
JKB wrote:
Petit probleme du jour, j'essaie desesperement d'utiliser un client FreeBSD (i386) sur un serveur NIS NetBSD (sparc64).
J'ai utilisé pendant des années un client FreeBSD sur un serveur NIS Linux sans problème autre que l'autorisation de transmettre /etc/shadow sur Linux donc je pense que l'implémentation du client est sans souci.
-- Michel Talon
JKB wrote:
Petit probleme du jour, j'essaie desesperement d'utiliser un client
FreeBSD (i386) sur un serveur NIS NetBSD (sparc64).
J'ai utilisé pendant des années un client FreeBSD sur un serveur NIS Linux
sans problème autre que l'autorisation de transmettre /etc/shadow sur Linux
donc je pense que l'implémentation du client est sans souci.
Petit probleme du jour, j'essaie desesperement d'utiliser un client FreeBSD (i386) sur un serveur NIS NetBSD (sparc64).
J'ai utilisé pendant des années un client FreeBSD sur un serveur NIS Linux sans problème autre que l'autorisation de transmettre /etc/shadow sur Linux donc je pense que l'implémentation du client est sans souci.
-- Michel Talon
JKB
Le 02 Aug 2014 17:05:00 GMT, Michel Talon écrivait :
JKB wrote:
Petit probleme du jour, j'essaie desesperement d'utiliser un client FreeBSD (i386) sur un serveur NIS NetBSD (sparc64).
J'ai utilisé pendant des années un client FreeBSD sur un serveur NIS Linux sans problème autre que l'autorisation de transmettre /etc/shadow sur Linux donc je pense que l'implémentation du client est sans souci.
Certes. J'ai aussi utilise sans probleme un client NetBSD sur un serveur Linux. La, j'ai un client FreeBSD (parce que c'est un vieux portable daubesque avec ACPI moisi qui se vautre au boot de NetBSD) qui n'arrive pas a se connecter sur un serveur NetBSD. Un client NetBSD y arrive. Le rpcbind de NetBSD ne repond pas aux requetes du FreeBSD alors que le FreeBSD est bien capable de monter par le meme rpcbind les disques exportes en nfs par le meme NetBSD.
Bref, on n'est pas encore dans le dialogue NIS proprement dit mais dans la negociation rpcbind. Je pensais au debut que c'etait un probleme de host.allow/deny, mais dans ce cas, le montage nfs serait impossible.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le 02 Aug 2014 17:05:00 GMT,
Michel Talon <talon@lpthe.jussieu.fr> écrivait :
JKB wrote:
Petit probleme du jour, j'essaie desesperement d'utiliser un client
FreeBSD (i386) sur un serveur NIS NetBSD (sparc64).
J'ai utilisé pendant des années un client FreeBSD sur un serveur NIS Linux
sans problème autre que l'autorisation de transmettre /etc/shadow sur Linux
donc je pense que l'implémentation du client est sans souci.
Certes. J'ai aussi utilise sans probleme un client NetBSD sur un
serveur Linux. La, j'ai un client FreeBSD (parce que c'est un vieux
portable daubesque avec ACPI moisi qui se vautre au boot de NetBSD)
qui n'arrive pas a se connecter sur un serveur NetBSD. Un client
NetBSD y arrive. Le rpcbind de NetBSD ne repond pas aux requetes du
FreeBSD alors que le FreeBSD est bien capable de monter par le meme
rpcbind les disques exportes en nfs par le meme NetBSD.
Bref, on n'est pas encore dans le dialogue NIS proprement dit mais
dans la negociation rpcbind. Je pensais au debut que c'etait un
probleme de host.allow/deny, mais dans ce cas, le montage nfs serait
impossible.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le 02 Aug 2014 17:05:00 GMT, Michel Talon écrivait :
JKB wrote:
Petit probleme du jour, j'essaie desesperement d'utiliser un client FreeBSD (i386) sur un serveur NIS NetBSD (sparc64).
J'ai utilisé pendant des années un client FreeBSD sur un serveur NIS Linux sans problème autre que l'autorisation de transmettre /etc/shadow sur Linux donc je pense que l'implémentation du client est sans souci.
Certes. J'ai aussi utilise sans probleme un client NetBSD sur un serveur Linux. La, j'ai un client FreeBSD (parce que c'est un vieux portable daubesque avec ACPI moisi qui se vautre au boot de NetBSD) qui n'arrive pas a se connecter sur un serveur NetBSD. Un client NetBSD y arrive. Le rpcbind de NetBSD ne repond pas aux requetes du FreeBSD alors que le FreeBSD est bien capable de monter par le meme rpcbind les disques exportes en nfs par le meme NetBSD.
Bref, on n'est pas encore dans le dialogue NIS proprement dit mais dans la negociation rpcbind. Je pensais au debut que c'etait un probleme de host.allow/deny, mais dans ce cas, le montage nfs serait impossible.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Manuel Bouyer
JKB wrote: [...]
Quelques precisions. J'ai l'impression que le serveur netbsd ne repond pas aux requetes rpl du NIS. Pour les pontages NFS, ca fonctionne pourtant normalement depuis le meme client.
13:02:35.617190 IP 192.168.0.102.49742 > 192.168.0.255.sunrpc: UDP, length 112
192.168.0.255 c'est l'adresse broadcast ? est-ce que cote NetBSD le netmask est bon ? (i.e. qu'il considere bien que 192.168.0.255 est sont adresse broadcast) ? pas de filtre IP qui pourrait les bloquer ?
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
JKB <jkb@koenigsberg.invalid> wrote:
[...]
Quelques precisions. J'ai l'impression que le serveur netbsd ne
repond pas aux requetes rpl du NIS. Pour les pontages NFS, ca
fonctionne pourtant normalement depuis le meme client.
13:02:35.617190 IP 192.168.0.102.49742 > 192.168.0.255.sunrpc: UDP,
length 112
192.168.0.255 c'est l'adresse broadcast ?
est-ce que cote NetBSD le netmask est bon ? (i.e. qu'il considere
bien que 192.168.0.255 est sont adresse broadcast) ?
pas de filtre IP qui pourrait les bloquer ?
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--
Quelques precisions. J'ai l'impression que le serveur netbsd ne repond pas aux requetes rpl du NIS. Pour les pontages NFS, ca fonctionne pourtant normalement depuis le meme client.
13:02:35.617190 IP 192.168.0.102.49742 > 192.168.0.255.sunrpc: UDP, length 112
192.168.0.255 c'est l'adresse broadcast ? est-ce que cote NetBSD le netmask est bon ? (i.e. qu'il considere bien que 192.168.0.255 est sont adresse broadcast) ? pas de filtre IP qui pourrait les bloquer ?
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
JKB
Le Mon, 18 Aug 2014 19:53:15 +0000 (UTC), Manuel Bouyer écrivait :
JKB wrote: [...]
Quelques precisions. J'ai l'impression que le serveur netbsd ne repond pas aux requetes rpl du NIS. Pour les pontages NFS, ca fonctionne pourtant normalement depuis le meme client.
13:02:35.617190 IP 192.168.0.102.49742 > 192.168.0.255.sunrpc: UDP, length 112
est-ce que cote NetBSD le netmask est bon ? (i.e. qu'il considere bien que 192.168.0.255 est sont adresse broadcast) ? pas de filtre IP qui pourrait les bloquer ?
Aucun filtrage de port ni firewall. Le serveur NFS fonctionne sur la même machine.
La configuration réseau est un peu bizarre puisque cette machine me sert de passerelle pour utiliser une connexion Wimax à la campagne (je suis actuellement à 500 bornes de la machine au travers d'un openvpn pour vérifier).
gem0 est connectée au modem wimax (avec DHCP et tout le toutim). hme0-hme7 sont montées en brige0 pour connecter le reste du LAN. Je me suis demandé un moment si ce n'était pas une facétie du bridge, mais je ne vois pas pourquoi.
Naturellement, le client FreeBSD est paramétré de la même façon. J'ai bien essayé d'installer un NetBSD sur le client, mais le noyau se bauge lamentablement au démarrage tant l'Aspire 1700 est buggué...
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le Mon, 18 Aug 2014 19:53:15 +0000 (UTC),
Manuel Bouyer <bouyer@nerim.net> écrivait :
JKB <jkb@koenigsberg.invalid> wrote:
[...]
Quelques precisions. J'ai l'impression que le serveur netbsd ne
repond pas aux requetes rpl du NIS. Pour les pontages NFS, ca
fonctionne pourtant normalement depuis le meme client.
13:02:35.617190 IP 192.168.0.102.49742 > 192.168.0.255.sunrpc: UDP,
length 112
est-ce que cote NetBSD le netmask est bon ? (i.e. qu'il considere
bien que 192.168.0.255 est sont adresse broadcast) ?
pas de filtre IP qui pourrait les bloquer ?
Aucun filtrage de port ni firewall. Le serveur NFS fonctionne sur la
même machine.
La configuration réseau est un peu bizarre puisque cette machine me
sert de passerelle pour utiliser une connexion Wimax à la campagne
(je suis actuellement à 500 bornes de la machine au travers d'un
openvpn pour vérifier).
gem0 est connectée au modem wimax (avec DHCP et tout le toutim).
hme0-hme7 sont montées en brige0 pour connecter le reste du LAN.
Je me suis demandé un moment si ce n'était pas une facétie du
bridge, mais je ne vois pas pourquoi.
Naturellement, le client FreeBSD est paramétré de la même façon.
J'ai bien essayé d'installer un NetBSD sur le client, mais le noyau
se bauge lamentablement au démarrage tant l'Aspire 1700 est
buggué...
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Mon, 18 Aug 2014 19:53:15 +0000 (UTC), Manuel Bouyer écrivait :
JKB wrote: [...]
Quelques precisions. J'ai l'impression que le serveur netbsd ne repond pas aux requetes rpl du NIS. Pour les pontages NFS, ca fonctionne pourtant normalement depuis le meme client.
13:02:35.617190 IP 192.168.0.102.49742 > 192.168.0.255.sunrpc: UDP, length 112
est-ce que cote NetBSD le netmask est bon ? (i.e. qu'il considere bien que 192.168.0.255 est sont adresse broadcast) ? pas de filtre IP qui pourrait les bloquer ?
Aucun filtrage de port ni firewall. Le serveur NFS fonctionne sur la même machine.
La configuration réseau est un peu bizarre puisque cette machine me sert de passerelle pour utiliser une connexion Wimax à la campagne (je suis actuellement à 500 bornes de la machine au travers d'un openvpn pour vérifier).
gem0 est connectée au modem wimax (avec DHCP et tout le toutim). hme0-hme7 sont montées en brige0 pour connecter le reste du LAN. Je me suis demandé un moment si ce n'était pas une facétie du bridge, mais je ne vois pas pourquoi.
Naturellement, le client FreeBSD est paramétré de la même façon. J'ai bien essayé d'installer un NetBSD sur le client, mais le noyau se bauge lamentablement au démarrage tant l'Aspire 1700 est buggué...
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
> est-ce que cote NetBSD le netmask est bon ? (i.e. qu'il considere > bien que 192.168.0.255 est sont adresse broadcast) ? > pas de filtre IP qui pourrait les bloquer ?
Aucun filtrage de port ni firewall. Le serveur NFS fonctionne sur la même machine.
La configuration réseau est un peu bizarre puisque cette machine me sert de passerelle pour utiliser une connexion Wimax à la campagne (je suis actuellement à 500 bornes de la machine au travers d'un openvpn pour vérifier).
gem0 est connectée au modem wimax (avec DHCP et tout le toutim). hme0-hme7 sont montées en brige0 pour connecter le reste du LAN. Je me suis demandé un moment si ce n'était pas une facétie du bridge, mais je ne vois pas pourquoi.
Ha si ca pourrait. Je me demande s'il n'y a pas un probleme avec le broadcast justement. Il me semble qu'il y a un PR a ce sujet mais je n'ai pas trop suivit.
Peut-etre que donner l'adresse du seveur NIS a FreeBSD au lieu de le laisser trouver par broadcast peut resoudre le probleme ?
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
> est-ce que cote NetBSD le netmask est bon ? (i.e. qu'il considere
> bien que 192.168.0.255 est sont adresse broadcast) ?
> pas de filtre IP qui pourrait les bloquer ?
Aucun filtrage de port ni firewall. Le serveur NFS fonctionne sur la
même machine.
La configuration réseau est un peu bizarre puisque cette machine me
sert de passerelle pour utiliser une connexion Wimax à la campagne
(je suis actuellement à 500 bornes de la machine au travers d'un
openvpn pour vérifier).
gem0 est connectée au modem wimax (avec DHCP et tout le toutim).
hme0-hme7 sont montées en brige0 pour connecter le reste du LAN.
Je me suis demandé un moment si ce n'était pas une facétie du
bridge, mais je ne vois pas pourquoi.
Ha si ca pourrait. Je me demande s'il n'y a pas un probleme avec le broadcast
justement. Il me semble qu'il y a un PR a ce sujet mais je n'ai pas trop
suivit.
Peut-etre que donner l'adresse du seveur NIS a FreeBSD au lieu de le laisser
trouver par broadcast peut resoudre le probleme ?
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--
> est-ce que cote NetBSD le netmask est bon ? (i.e. qu'il considere > bien que 192.168.0.255 est sont adresse broadcast) ? > pas de filtre IP qui pourrait les bloquer ?
Aucun filtrage de port ni firewall. Le serveur NFS fonctionne sur la même machine.
La configuration réseau est un peu bizarre puisque cette machine me sert de passerelle pour utiliser une connexion Wimax à la campagne (je suis actuellement à 500 bornes de la machine au travers d'un openvpn pour vérifier).
gem0 est connectée au modem wimax (avec DHCP et tout le toutim). hme0-hme7 sont montées en brige0 pour connecter le reste du LAN. Je me suis demandé un moment si ce n'était pas une facétie du bridge, mais je ne vois pas pourquoi.
Ha si ca pourrait. Je me demande s'il n'y a pas un probleme avec le broadcast justement. Il me semble qu'il y a un PR a ce sujet mais je n'ai pas trop suivit.
Peut-etre que donner l'adresse du seveur NIS a FreeBSD au lieu de le laisser trouver par broadcast peut resoudre le probleme ?
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
JKB
Le Mon, 25 Aug 2014 19:04:38 +0000 (UTC), Manuel Bouyer écrivait :
> est-ce que cote NetBSD le netmask est bon ? (i.e. qu'il considere > bien que 192.168.0.255 est sont adresse broadcast) ? > pas de filtre IP qui pourrait les bloquer ?
Aucun filtrage de port ni firewall. Le serveur NFS fonctionne sur la même machine.
La configuration réseau est un peu bizarre puisque cette machine me sert de passerelle pour utiliser une connexion Wimax à la campagne (je suis actuellement à 500 bornes de la machine au travers d'un openvpn pour vérifier).
gem0 est connectée au modem wimax (avec DHCP et tout le toutim). hme0-hme7 sont montées en brige0 pour connecter le reste du LAN. Je me suis demandé un moment si ce n'était pas une facétie du bridge, mais je ne vois pas pourquoi.
Ha si ca pourrait. Je me demande s'il n'y a pas un probleme avec le broadcast justement. Il me semble qu'il y a un PR a ce sujet mais je n'ai pas trop suivit.
Merci pour cette indication. Penses-tu au PR43379 ou au 48104 ? Il me semble que ce n'est pas exactement le même problème.
Peut-etre que donner l'adresse du seveur NIS a FreeBSD au lieu de le laisser trouver par broadcast peut resoudre le probleme ?
Je vais essayer, mais ce ne sera pas avant les vacances de la Toussaint voire la fin de l'année...
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le Mon, 25 Aug 2014 19:04:38 +0000 (UTC),
Manuel Bouyer <bouyer@nerim.net> écrivait :
> est-ce que cote NetBSD le netmask est bon ? (i.e. qu'il considere
> bien que 192.168.0.255 est sont adresse broadcast) ?
> pas de filtre IP qui pourrait les bloquer ?
Aucun filtrage de port ni firewall. Le serveur NFS fonctionne sur la
même machine.
La configuration réseau est un peu bizarre puisque cette machine me
sert de passerelle pour utiliser une connexion Wimax à la campagne
(je suis actuellement à 500 bornes de la machine au travers d'un
openvpn pour vérifier).
gem0 est connectée au modem wimax (avec DHCP et tout le toutim).
hme0-hme7 sont montées en brige0 pour connecter le reste du LAN.
Je me suis demandé un moment si ce n'était pas une facétie du
bridge, mais je ne vois pas pourquoi.
Ha si ca pourrait. Je me demande s'il n'y a pas un probleme avec le broadcast
justement. Il me semble qu'il y a un PR a ce sujet mais je n'ai pas trop
suivit.
Merci pour cette indication. Penses-tu au PR43379 ou au 48104 ? Il
me semble que ce n'est pas exactement le même problème.
Peut-etre que donner l'adresse du seveur NIS a FreeBSD au lieu de le laisser
trouver par broadcast peut resoudre le probleme ?
Je vais essayer, mais ce ne sera pas avant les vacances de la
Toussaint voire la fin de l'année...
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
> est-ce que cote NetBSD le netmask est bon ? (i.e. qu'il considere > bien que 192.168.0.255 est sont adresse broadcast) ? > pas de filtre IP qui pourrait les bloquer ?
Aucun filtrage de port ni firewall. Le serveur NFS fonctionne sur la même machine.
La configuration réseau est un peu bizarre puisque cette machine me sert de passerelle pour utiliser une connexion Wimax à la campagne (je suis actuellement à 500 bornes de la machine au travers d'un openvpn pour vérifier).
gem0 est connectée au modem wimax (avec DHCP et tout le toutim). hme0-hme7 sont montées en brige0 pour connecter le reste du LAN. Je me suis demandé un moment si ce n'était pas une facétie du bridge, mais je ne vois pas pourquoi.
Ha si ca pourrait. Je me demande s'il n'y a pas un probleme avec le broadcast justement. Il me semble qu'il y a un PR a ce sujet mais je n'ai pas trop suivit.
Merci pour cette indication. Penses-tu au PR43379 ou au 48104 ? Il me semble que ce n'est pas exactement le même problème.
Peut-etre que donner l'adresse du seveur NIS a FreeBSD au lieu de le laisser trouver par broadcast peut resoudre le probleme ?
Je vais essayer, mais ce ne sera pas avant les vacances de la Toussaint voire la fin de l'année...
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Manuel Bouyer
JKB wrote:
>> gem0 est connectée au modem wimax (avec DHCP et tout le toutim). >> hme0-hme7 sont montées en brige0 pour connecter le reste du LAN. >> Je me suis demandé un moment si ce n'était pas une facétie du >> bridge, mais je ne vois pas pourquoi. > > Ha si ca pourrait. Je me demande s'il n'y a pas un probleme avec le broadcast > justement. Il me semble qu'il y a un PR a ce sujet mais je n'ai pas trop > suivit.
Merci pour cette indication. Penses-tu au PR43379 ou au 48104 ? Il me semble que ce n'est pas exactement le même problème.
Le 48104, ca ressemble a ton probleme (la machine locale ne voit pas les broadcasts)
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
JKB <jkb@koenigsberg.invalid> wrote:
>> gem0 est connectée au modem wimax (avec DHCP et tout le toutim).
>> hme0-hme7 sont montées en brige0 pour connecter le reste du LAN.
>> Je me suis demandé un moment si ce n'était pas une facétie du
>> bridge, mais je ne vois pas pourquoi.
>
> Ha si ca pourrait. Je me demande s'il n'y a pas un probleme avec le broadcast
> justement. Il me semble qu'il y a un PR a ce sujet mais je n'ai pas trop
> suivit.
Merci pour cette indication. Penses-tu au PR43379 ou au 48104 ? Il
me semble que ce n'est pas exactement le même problème.
Le 48104, ca ressemble a ton probleme (la machine locale ne voit pas
les broadcasts)
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--
>> gem0 est connectée au modem wimax (avec DHCP et tout le toutim). >> hme0-hme7 sont montées en brige0 pour connecter le reste du LAN. >> Je me suis demandé un moment si ce n'était pas une facétie du >> bridge, mais je ne vois pas pourquoi. > > Ha si ca pourrait. Je me demande s'il n'y a pas un probleme avec le broadcast > justement. Il me semble qu'il y a un PR a ce sujet mais je n'ai pas trop > suivit.
Merci pour cette indication. Penses-tu au PR43379 ou au 48104 ? Il me semble que ce n'est pas exactement le même problème.
Le 48104, ca ressemble a ton probleme (la machine locale ne voit pas les broadcasts)
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
JKB
Le Tue, 26 Aug 2014 17:29:52 +0000 (UTC), Manuel Bouyer écrivait :
JKB wrote:
>> gem0 est connectée au modem wimax (avec DHCP et tout le toutim). >> hme0-hme7 sont montées en brige0 pour connecter le reste du LAN. >> Je me suis demandé un moment si ce n'était pas une facétie du >> bridge, mais je ne vois pas pourquoi. > > Ha si ca pourrait. Je me demande s'il n'y a pas un probleme avec le broadcast > justement. Il me semble qu'il y a un PR a ce sujet mais je n'ai pas trop > suivit.
Merci pour cette indication. Penses-tu au PR43379 ou au 48104 ? Il me semble que ce n'est pas exactement le même problème.
Le 48104, ca ressemble a ton probleme (la machine locale ne voit pas les broadcasts)
Certes, mais il me semblait que le patch avait été intégré au noyau vers le 15 juin. Mon noyau est plus récent puisque je suis -current pour sparc64.
Je viens de jeter un oeil à mon arbre de sources et le moins que je puisse dire est que je ne vois pas trop le rapport entre le patch proposé pour résoudre le 48104 et les fichiers du 7.99.1 :-(
Bien cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le Tue, 26 Aug 2014 17:29:52 +0000 (UTC),
Manuel Bouyer <bouyer@nerim.net> écrivait :
JKB <jkb@koenigsberg.invalid> wrote:
>> gem0 est connectée au modem wimax (avec DHCP et tout le toutim).
>> hme0-hme7 sont montées en brige0 pour connecter le reste du LAN.
>> Je me suis demandé un moment si ce n'était pas une facétie du
>> bridge, mais je ne vois pas pourquoi.
>
> Ha si ca pourrait. Je me demande s'il n'y a pas un probleme avec le broadcast
> justement. Il me semble qu'il y a un PR a ce sujet mais je n'ai pas trop
> suivit.
Merci pour cette indication. Penses-tu au PR43379 ou au 48104 ? Il
me semble que ce n'est pas exactement le même problème.
Le 48104, ca ressemble a ton probleme (la machine locale ne voit pas
les broadcasts)
Certes, mais il me semblait que le patch avait été intégré au noyau
vers le 15 juin. Mon noyau est plus récent puisque je suis -current
pour sparc64.
Je viens de jeter un oeil à mon arbre de sources et le moins que je
puisse dire est que je ne vois pas trop le rapport entre le patch
proposé pour résoudre le 48104 et les fichiers du 7.99.1 :-(
Bien cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Tue, 26 Aug 2014 17:29:52 +0000 (UTC), Manuel Bouyer écrivait :
JKB wrote:
>> gem0 est connectée au modem wimax (avec DHCP et tout le toutim). >> hme0-hme7 sont montées en brige0 pour connecter le reste du LAN. >> Je me suis demandé un moment si ce n'était pas une facétie du >> bridge, mais je ne vois pas pourquoi. > > Ha si ca pourrait. Je me demande s'il n'y a pas un probleme avec le broadcast > justement. Il me semble qu'il y a un PR a ce sujet mais je n'ai pas trop > suivit.
Merci pour cette indication. Penses-tu au PR43379 ou au 48104 ? Il me semble que ce n'est pas exactement le même problème.
Le 48104, ca ressemble a ton probleme (la machine locale ne voit pas les broadcasts)
Certes, mais il me semblait que le patch avait été intégré au noyau vers le 15 juin. Mon noyau est plus récent puisque je suis -current pour sparc64.
Je viens de jeter un oeil à mon arbre de sources et le moins que je puisse dire est que je ne vois pas trop le rapport entre le patch proposé pour résoudre le 48104 et les fichiers du 7.99.1 :-(
Bien cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
JKB
Le Tue, 26 Aug 2014 18:55:35 +0000 (UTC), JKB écrivait :
Le Tue, 26 Aug 2014 17:29:52 +0000 (UTC), Manuel Bouyer écrivait :
JKB wrote:
>> gem0 est connectée au modem wimax (avec DHCP et tout le toutim). >> hme0-hme7 sont montées en brige0 pour connecter le reste du LAN. >> Je me suis demandé un moment si ce n'était pas une facétie du >> bridge, mais je ne vois pas pourquoi. > > Ha si ca pourrait. Je me demande s'il n'y a pas un probleme avec le broadcast > justement. Il me semble qu'il y a un PR a ce sujet mais je n'ai pas trop > suivit.
Merci pour cette indication. Penses-tu au PR43379 ou au 48104 ? Il me semble que ce n'est pas exactement le même problème.
Le 48104, ca ressemble a ton probleme (la machine locale ne voit pas les broadcasts)
Certes, mais il me semblait que le patch avait été intégré au noyau vers le 15 juin. Mon noyau est plus récent puisque je suis -current pour sparc64.
Je viens de jeter un oeil à mon arbre de sources et le moins que je puisse dire est que je ne vois pas trop le rapport entre le patch proposé pour résoudre le 48104 et les fichiers du 7.99.1 :-(
Bien cordialement,
JKB
Bon. Je me penche a nouveau sur ce probleme. En forcant l'adresse IP du serveur dans le rc.conf de FreeBSD, ca passe. Mais je me fais jeter par le mecanisme PAM cote FreeBSD.
Le NIS (et amd) est parfaitement bien configure. J'arrive dans un xterm a faire un su - utilisateur. Le home de l'utilisateur est monte et els droits bien affectes. ypcat renvoie les informations adequates.
Mais les mots de passe exportes par NetBSD sont au format sha1 et FreeBSD s'attend visiblement a du SHA512. Comment faire comprendre au mecanisme pam de FreeBSD que le passwd est au format sha1 ?
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le Tue, 26 Aug 2014 18:55:35 +0000 (UTC),
JKB <jkb@koenigsberg.invalid> écrivait :
Le Tue, 26 Aug 2014 17:29:52 +0000 (UTC),
Manuel Bouyer <bouyer@nerim.net> écrivait :
JKB <jkb@koenigsberg.invalid> wrote:
>> gem0 est connectée au modem wimax (avec DHCP et tout le toutim).
>> hme0-hme7 sont montées en brige0 pour connecter le reste du LAN.
>> Je me suis demandé un moment si ce n'était pas une facétie du
>> bridge, mais je ne vois pas pourquoi.
>
> Ha si ca pourrait. Je me demande s'il n'y a pas un probleme avec le broadcast
> justement. Il me semble qu'il y a un PR a ce sujet mais je n'ai pas trop
> suivit.
Merci pour cette indication. Penses-tu au PR43379 ou au 48104 ? Il
me semble que ce n'est pas exactement le même problème.
Le 48104, ca ressemble a ton probleme (la machine locale ne voit pas
les broadcasts)
Certes, mais il me semblait que le patch avait été intégré au noyau
vers le 15 juin. Mon noyau est plus récent puisque je suis -current
pour sparc64.
Je viens de jeter un oeil à mon arbre de sources et le moins que je
puisse dire est que je ne vois pas trop le rapport entre le patch
proposé pour résoudre le 48104 et les fichiers du 7.99.1 :-(
Bien cordialement,
JKB
Bon. Je me penche a nouveau sur ce probleme. En forcant l'adresse IP
du serveur dans le rc.conf de FreeBSD, ca passe. Mais je me fais
jeter par le mecanisme PAM cote FreeBSD.
Le NIS (et amd) est parfaitement bien configure. J'arrive dans un
xterm a faire un su - utilisateur. Le home de l'utilisateur est
monte et els droits bien affectes. ypcat renvoie les informations
adequates.
Mais les mots de passe exportes par NetBSD sont au format sha1 et
FreeBSD s'attend visiblement a du SHA512. Comment faire comprendre
au mecanisme pam de FreeBSD que le passwd est au format sha1 ?
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Tue, 26 Aug 2014 18:55:35 +0000 (UTC), JKB écrivait :
Le Tue, 26 Aug 2014 17:29:52 +0000 (UTC), Manuel Bouyer écrivait :
JKB wrote:
>> gem0 est connectée au modem wimax (avec DHCP et tout le toutim). >> hme0-hme7 sont montées en brige0 pour connecter le reste du LAN. >> Je me suis demandé un moment si ce n'était pas une facétie du >> bridge, mais je ne vois pas pourquoi. > > Ha si ca pourrait. Je me demande s'il n'y a pas un probleme avec le broadcast > justement. Il me semble qu'il y a un PR a ce sujet mais je n'ai pas trop > suivit.
Merci pour cette indication. Penses-tu au PR43379 ou au 48104 ? Il me semble que ce n'est pas exactement le même problème.
Le 48104, ca ressemble a ton probleme (la machine locale ne voit pas les broadcasts)
Certes, mais il me semblait que le patch avait été intégré au noyau vers le 15 juin. Mon noyau est plus récent puisque je suis -current pour sparc64.
Je viens de jeter un oeil à mon arbre de sources et le moins que je puisse dire est que je ne vois pas trop le rapport entre le patch proposé pour résoudre le 48104 et les fichiers du 7.99.1 :-(
Bien cordialement,
JKB
Bon. Je me penche a nouveau sur ce probleme. En forcant l'adresse IP du serveur dans le rc.conf de FreeBSD, ca passe. Mais je me fais jeter par le mecanisme PAM cote FreeBSD.
Le NIS (et amd) est parfaitement bien configure. J'arrive dans un xterm a faire un su - utilisateur. Le home de l'utilisateur est monte et els droits bien affectes. ypcat renvoie les informations adequates.
Mais les mots de passe exportes par NetBSD sont au format sha1 et FreeBSD s'attend visiblement a du SHA512. Comment faire comprendre au mecanisme pam de FreeBSD que le passwd est au format sha1 ?
Cordialement,
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr