Re: Help with NIS+NFS in Squeeze
Markos wrote: Bob Proulx escreveu: 1. Look in /var/log/syslog for any relevant messages. After a normal boot I can't see any information related to nfs on /var/log/syslog On Server the command cat /var/log/syslog returns: I didn't see anything relevant in that list. But it was a very short snippet of the full file. I assume that was just the parts you didn't know about. Because the original would be quite long. Then I created on client (192.168.0.2) a directory /home/home_server And after the command on client mount -t nfs 192.168.0.1:/home /home/home_servidor You don't need the -t nfs part. It seems odd to me to see it there. Shouldn't hurt though. But I think this is the first time I have seen that coupled together. the /home directory is mounted on client and I can see the messages on /var/log/syslog On Server Feb 10 14:52:29 servidor ypserv[1042]: refused connect from 192.168.0.2:50898 to procedure ypproc_match (pimentel.edu,shadow.byname;-1) Feb 10 14:52:32 servidor ypserv[1042]: refused connect from 192.168.0.2:33712 to procedure ypproc_match (pimentel.edu,shadow.byname;-1) Feb 10 14:52:32 servidor ypserv[1042]: refused connect from 192.168.0.2:36811 to procedure ypproc_match (pimentel.edu,shadow.byname;-1) Shose are nis/yp errors. For the shadow map. Is nis/yp working okay for you? You said that it was. Feb 10 14:54:39 servidor mountd[1052]: authenticated mount request from 192.168.0.2:920 for /home (/home) I think that is a successful notification. On client Feb 10 12:48:11 pc17 kernel: [ 726.729294] RPC: Registered udp transport module. Feb 10 12:48:11 pc17 kernel: [ 726.729298] RPC: Registered tcp transport module. Feb 10 12:48:11 pc17 kernel: [ 726.729300] RPC: Registered tcp NFSv4.1 backchannel transport module. Feb 10 12:48:11 pc17 kernel: [ 726.763223] Slow work thread pool: Starting up Feb 10 12:48:11 pc17 kernel: [ 726.763278] Slow work thread pool: Ready Feb 10 12:48:11 pc17 kernel: [ 726.763341] FS-Cache: Loaded Feb 10 12:48:11 pc17 kernel: [ 726.809331] FS-Cache: Netfs 'nfs' registered for caching Feb 10 12:48:11 pc17 kernel: [ 726.935870] svc: failed to register lockdv1 RPC service (errno 97). Other than that last message those all look like normal startup notifications. I don't know anything about that last message. 2. Change /etc/network/interfaces 'allow-hotplug eth0' to 'auto eth0'. The file /etc/network/interfaces on server is: ... auto eth0 iface eth0 inet static address 192.168.0.1 netmask 255.255.255.0 No upstream gateway? An isolated machine? Otherwise looks okay. The file /etc/network/interfaces on client is: ... auto eth0 iface eth0 inet static address 192.168.0.2 netmask 255.255.255.0 gateway 192.168.0.1 Looks okay. 3. Remove bg from the /etc/fstab options list. Any status on that part of the experiment? Additionally since then I wonder if you are booting with legacy boot order or if you are using the new parallel boot order. Do you have this file: ls -ldog /etc/init.d/.legacy-bootordering There is no such file neither on the client nor the server. Okay. Means you are using the current parallel boot process. dpkg -l | grep ^rc No return of this command. Good! For people upgrading from previous versions there is often lint left behind there and sometimes that lint causes problems. This is a new installation (CD 1 and 2) both the client and the server. Should be good. I'm thinking don't insist too much about it and include the file /etc/ rc.local of the client the command: mount -t nfs 192.168.0.1:/home /home/home_servidor It is not an elegant solution, but it solves the problem for now. If that works then okay. I always hate leaving things in a broken state elsewhere. Because the things you are reporting should be working okay. They work okay for me and many others using the standard bits. But if you are happy at that point then it is your judgement call of when to stop and leave it in a state you can use it. Is there any difference in operation between the mounting of a partition using the /etc/fstab and /etc/rc.local? Not in operation. It only changes how it is started up. It will be identical in operation after that point. Bob signature.asc Description: Digital signature
Re: Help with NIS+NFS in Squeeze
Dear Bob, Em Sáb, 2013-02-09 às 12:52 -0700, Bob Proulx escreveu: Markos wrote: I just checked the configuration file /etc/fstab on the client machine and the server IP address is correct. 192.168.0.1 When writing the message I copied and pasted the IP address of the site that I used as a reference and I forgot to check. Sorry for the mistake. No problem. We have all made those. Do you have any other suggestions? What did you find when you tried the others suggestions? Specifically: 1. Look in /var/log/syslog for any relevant messages. After a normal boot I can't see any information related to nfs on /var/log/syslog On Server the command cat /var/log/syslog returns: Feb 10 14:31:12 servidor rsyslogd: [origin software=rsyslogd swVersion=4.6.4 x-pid=985 x-info=http://www.rsyslog.com;] rsyslogd was HUPed, type 'lightweight'. Feb 10 14:31:12 servidor rsyslogd: [origin software=rsyslogd swVersion=4.6.4 x-pid=985 x-info=http://www.rsyslog.com;] rsyslogd was HUPed, type 'lightweight'. Feb 10 14:31:18 servidor anacron[1067]: Job `cron.daily' terminated Feb 10 14:31:18 servidor anacron[1067]: Normal exit (1 job run) Feb 10 14:32:13 servidor kernel: [ 378.758482] ip_tables: (C) 2000-2006 Netfilter Core Team Feb 10 14:32:13 servidor kernel: [ 378.797306] nf_conntrack version 0.5.0 (16384 buckets, 65536 max) Feb 10 14:32:13 servidor kernel: [ 378.798066] CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use Feb 10 14:32:13 servidor kernel: [ 378.798073] nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or Feb 10 14:32:13 servidor kernel: [ 378.798078] sysctl net.netfilter.nf_conntrack_acct=1 to enable it. Then I created on client (192.168.0.2) a directory /home/home_server And after the command on client mount -t nfs 192.168.0.1:/home /home/home_servidor the /home directory is mounted on client and I can see the messages on /var/log/syslog On Server Feb 10 14:52:29 servidor ypserv[1042]: refused connect from 192.168.0.2:50898 to procedure ypproc_match (pimentel.edu,shadow.byname;-1) Feb 10 14:52:32 servidor ypserv[1042]: refused connect from 192.168.0.2:33712 to procedure ypproc_match (pimentel.edu,shadow.byname;-1) Feb 10 14:52:32 servidor ypserv[1042]: refused connect from 192.168.0.2:36811 to procedure ypproc_match (pimentel.edu,shadow.byname;-1) Feb 10 14:54:39 servidor mountd[1052]: authenticated mount request from 192.168.0.2:920 for /home (/home) On client Feb 10 12:48:11 pc17 kernel: [ 726.729294] RPC: Registered udp transport module. Feb 10 12:48:11 pc17 kernel: [ 726.729298] RPC: Registered tcp transport module. Feb 10 12:48:11 pc17 kernel: [ 726.729300] RPC: Registered tcp NFSv4.1 backchannel transport module. Feb 10 12:48:11 pc17 kernel: [ 726.763223] Slow work thread pool: Starting up Feb 10 12:48:11 pc17 kernel: [ 726.763278] Slow work thread pool: Ready Feb 10 12:48:11 pc17 kernel: [ 726.763341] FS-Cache: Loaded Feb 10 12:48:11 pc17 kernel: [ 726.809331] FS-Cache: Netfs 'nfs' registered for caching Feb 10 12:48:11 pc17 kernel: [ 726.935870] svc: failed to register lockdv1 RPC service (errno 97). 2. Change /etc/network/interfaces 'allow-hotplug eth0' to 'auto eth0'. The file /etc/network/interfaces on server is: # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.0.1 netmask 255.255.255.0 The file /etc/network/interfaces on client is: # The loopback network interface auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.0.2 netmask 255.255.255.0 gateway 192.168.0.1 3. Remove bg from the /etc/fstab options list. Additionally since then I wonder if you are booting with legacy boot order or if you are using the new parallel boot order. Do you have this file: ls -ldog /etc/init.d/.legacy-bootordering There is no such file neither on the client nor the server. And that made me wonder if there are additional files left behind as lint from previous upgrades in /etc/init.d that may be causing problems keeping it using legacy boot ordering. dpkg -l | grep ^rc No return of this command. This is a new installation (CD 1 and 2) both the client and the server. Are there packages installed, removed, but not purged that would contain /etc/init.d files? If you do then it is probably time to do housecleaning. Bob I'm thinking don't insist too much about it and include the file /etc/ rc.local of the client the command: mount -t nfs 192.168.0.1:/home /home/home_servidor It is not an elegant solution, but it solves the problem for now. Is there any difference in operation between the mounting of a partition using the /etc/fstab and /etc/rc.local? Thank you very much for your attention. Markos www.c2o.pro.br -- To
Re: Help with NIS+NFS in Squeeze
Em Seg, 2013-02-04 às 10:18 -0900, Mark Neyhart escreveu: Markos wrote: Dear Bob, Em Dom, 2013-02-03 Ã s 12:48 -0700, Bob Proulx escreveu: Markos wrote: But I can manually mount the /home partition on the clients with the command: mount 192.168.0.1:/home /home Good. The ip address in the above mount command agrees with the address in /etc/network/interfaces. The file /etc/network/interfaces of the server is: # The loopback network interface it self inet loopback iface it auto eth0 iface eth0 inet static address 192.168.0.1 netmask 255.255.255.0 But the ip address you list below in /etc/fstab does not agree with the address in etc/network/interfaces. I copied these options from a site. I was thinking to simplify and replace with just defaults 192.168.10.101:/home /home nfs defaults 0 0 You should replace 192.168.10.101 with 192.168.0.1 In /etc/nsswitch.conf file: passwd: files nis group: files nis shadow: files nis Ok. But what about the files /etc/passwd ... /etc/gshadow. Should remove the + at the end of these files? If you modify the /etc/nsswitch.conf as Bob recommends, remove the + at the end of /etc/passwd ... /etc/gshadow. Mark Neyhart Dear, I just checked the configuration file /etc/fstab on the client machine and the server IP address is correct. 192.168.0.1 When writing the message I copied and pasted the IP address of the site that I used as a reference and I forgot to check. Sorry for the mistake. Do you have any other suggestions? Thanks for your attention, Markos -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1360435041.4033.1.ca...@malgas.petrobras.biz
Re: Help with NIS+NFS in Squeeze
Markos wrote: I just checked the configuration file /etc/fstab on the client machine and the server IP address is correct. 192.168.0.1 When writing the message I copied and pasted the IP address of the site that I used as a reference and I forgot to check. Sorry for the mistake. No problem. We have all made those. Do you have any other suggestions? What did you find when you tried the others suggestions? Specifically: 1. Look in /var/log/syslog for any relevant messages. 2. Change /etc/network/interfaces 'allow-hotplug eth0' to 'auto eth0'. 3. Remove bg from the /etc/fstab options list. Additionally since then I wonder if you are booting with legacy boot order or if you are using the new parallel boot order. Do you have this file: ls -ldog /etc/init.d/.legacy-bootordering And that made me wonder if there are additional files left behind as lint from previous upgrades in /etc/init.d that may be causing problems keeping it using legacy boot ordering. dpkg -l | grep ^rc Are there packages installed, removed, but not purged that would contain /etc/init.d files? If you do then it is probably time to do housecleaning. Bob signature.asc Description: Digital signature
Re: Help with NIS+NFS in Squeeze
Mark Neyhart wrote: Markos wrote: mount 192.168.0.1:/home /home The ip address in the above mount command agrees with the address in /etc/network/interfaces. The file /etc/network/interfaces of the server is: auto eth0 iface eth0 inet static address 192.168.0.1 But the ip address you list below in /etc/fstab does not agree with the address in etc/network/interfaces. 192.168.10.101:/home /home nfs defaults 0 0 Good eye! I missed that critical detail. Bob signature.asc Description: Digital signature
Re: Help with NIS+NFS in Squeeze
Dear Bob, Em Dom, 2013-02-03 às 12:48 -0700, Bob Proulx escreveu: Markos wrote: I'm trying to configure the services NIS+NFS in a small network (7 PCs), all running Squeeze. Okay. Sounds good. The NIS service seems to be working Good. but NFS don't mounts the /home partition on the clients during boot. Focus only on the NFS part of the debugging. Do not be distracted by the NIS/yp part. They may work together in supporting roles but they are completely independent subsystems. This is important information for me. I had no experience with NIS or NFS and I was very confused about the relationship between the two services But I can manually mount the /home partition on the clients with the command: mount 192.168.0.1:/home /home Good. I found the strange message in dmesg: svc: failed to register lockdv1 RPC service (errno 97) I am unfamiliar with that error and searching didn't turn up anything for certain either. How can I discover what is wrong? Almost always the information will be logged in /var/log/syslog and hopefully there will be clues there. Start by looking there. I only have access to computers on weekends. The next weekend I'll check the error messages in syslog and I'll post what I find. Thanks for including much information. However the file I am interested in is /etc/network/interfaces. The new device way is to support a hotpluggable event driven system. That may be incompatible with the traditional nfs mounted home directory environment. Specifically you probably have this: allow-hotplug eth0 Try changing that line to: auto eth0 Then instead of using the new event driven control flow at boot time it will use the old legacy start-at-boot time control flow. This will also re-enable use of 'service networking restart' as one of the working ways to restart the network. I am making available information about mounting of this small network on the site http://www.c2o.pro.br/inf/pimentel/x30.html but unfortunately the content is only in Portuguese. The file /etc/network/interfaces of the server is: # The loopback network interface it self inet loopback iface it auto eth0 iface eth0 inet static address 192.168.0.1 netmask 255.255.255.0 And the client is: # The loopback network interface it self inet loopback iface it auto eth0 iface eth0 inet static address 192.168.0.2 netmask 255.255.255.0 gateway 192.168.0.1 If the problem isolates itself to just that change then please file a bug with the details. I happen to be running with 'auto' for other reasons and nis/yp with nfs mounted home direcotries is working fine for me. In file /etc/fstab I included the line 192.168.10.101:/home /home nfs rw,bg,tcp,rsize=32768,wsize=32768,hard,nointr,nolock,noac,timeo=600,user,auto 0 0 Secondly I would test it without the 'bg' option in the /etc/fstab. This is a philosophical issue but if the machine needs /home to be useful then I believe it should wait for it to be available before presenting a login to a user. Otherwise the user will be confused that they can log in but don't have a home directory. I copied these options from a site. I was thinking to simplify and replace with just defaults 192.168.10.101:/home /home nfs defaults 0 0 What do you think about? echo + /etc/passwd echo + /etc/group echo + /etc/shadow echo + /etc/gshadow I know that is the legacy way but personally these days I prefer to use this configuration instead. It is simpler. In /etc/nsswitch.conf file: passwd: files nis group: files nis shadow: files nis Ok. But what about the files /etc/passwd ... /etc/gshadow. Should remove the + at the end of these files? Bob After some time just reading manuals and mailing lists, I get confused with so much information and a tip from someone more experienced is very important. Thank you verymuch for your attention. Markos, mar...@c2o.pro.br -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1359988210.5200.30.ca...@malgas.petrobras.biz
Re: Help with NIS+NFS in Squeeze
Markos wrote: Dear Bob, Em Dom, 2013-02-03 Ã s 12:48 -0700, Bob Proulx escreveu: Markos wrote: But I can manually mount the /home partition on the clients with the command: mount 192.168.0.1:/home /home Good. The ip address in the above mount command agrees with the address in /etc/network/interfaces. The file /etc/network/interfaces of the server is: # The loopback network interface it self inet loopback iface it auto eth0 iface eth0 inet static address 192.168.0.1 netmask 255.255.255.0 But the ip address you list below in /etc/fstab does not agree with the address in etc/network/interfaces. I copied these options from a site. I was thinking to simplify and replace with just defaults 192.168.10.101:/home /home nfs defaults 0 0 You should replace 192.168.10.101 with 192.168.0.1 In /etc/nsswitch.conf file: passwd: files nis group: files nis shadow: files nis Ok. But what about the files /etc/passwd ... /etc/gshadow. Should remove the + at the end of these files? If you modify the /etc/nsswitch.conf as Bob recommends, remove the + at the end of /etc/passwd ... /etc/gshadow. Mark Neyhart -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51100992.3010...@akleg.gov
Re: Help with NIS+NFS in Squeeze
Markos wrote: I'm trying to configure the services NIS+NFS in a small network (7 PCs), all running Squeeze. Okay. Sounds good. The NIS service seems to be working Good. but NFS don't mounts the /home partition on the clients during boot. Focus only on the NFS part of the debugging. Do not be distracted by the NIS/yp part. They may work together in supporting roles but they are completely independent subsystems. But I can manually mount the /home partition on the clients with the command: mount 192.168.0.1:/home /home Good. I found the strange message in dmesg: svc: failed to register lockdv1 RPC service (errno 97) I am unfamiliar with that error and searching didn't turn up anything for certain either. How can I discover what is wrong? Almost always the information will be logged in /var/log/syslog and hopefully there will be clues there. Start by looking there. Thanks for including much information. However the file I am interested in is /etc/network/interfaces. The new device way is to support a hotpluggable event driven system. That may be incompatible with the traditional nfs mounted home directory environment. Specifically you probably have this: allow-hotplug eth0 Try changing that line to: auto eth0 Then instead of using the new event driven control flow at boot time it will use the old legacy start-at-boot time control flow. This will also re-enable use of 'service networking restart' as one of the working ways to restart the network. If the problem isolates itself to just that change then please file a bug with the details. I happen to be running with 'auto' for other reasons and nis/yp with nfs mounted home direcotries is working fine for me. In file /etc/fstab I included the line 192.168.10.101:/home /home nfs rw,bg,tcp,rsize=32768,wsize=32768,hard,nointr,nolock,noac,timeo=600,user,auto 0 0 Secondly I would test it without the 'bg' option in the /etc/fstab. This is a philosophical issue but if the machine needs /home to be useful then I believe it should wait for it to be available before presenting a login to a user. Otherwise the user will be confused that they can log in but don't have a home directory. echo + /etc/passwd echo + /etc/group echo + /etc/shadow echo + /etc/gshadow I know that is the legacy way but personally these days I prefer to use this configuration instead. It is simpler. In /etc/nsswitch.conf file: passwd: files nis group: files nis shadow: files nis Bob signature.asc Description: Digital signature
Help with NIS+NFS in Squeeze
Dear, Please, I'm confused! I'm trying to configure the services NIS+NFS in a small network (7 PCs), all running Squeeze. The NIS service seems to be working but NFS don't mounts the /home partition on the clients during boot. But I can manually mount the /home partition on the clients with the command: mount 192.168.0.1:/home /home I found the strange message in dmesg: svc: failed to register lockdv1 RPC service (errno 97) How can I discover what is wrong? Thanks for any help. Markos mar...@c2o.pro.br PS: I followed the steps below to configure the NFS (Server): apt-get install nfs-kernel-server In file /etc/exports I included the line /home/ 192.168.0.0/255.255.255.0(rw,sync,no_root_squash) And started the nfs server with the command: /etc/init.d/nfs-kernel-server start And NFS client: apt-get install nfs-common In file /etc/fstab I included the line 192.168.10.101:/home /home nfs rw,bg,tcp,rsize=32768,wsize=32768,hard,nointr,nolock,noac,timeo=600,user,auto 0 0 - And the followed steps to configure the NIS (Server): apt-get install portmap apt-get install nis In /etc/hosts 192.168.0.1servidor.pimentel.eduservidor In /etc/defaultdomain pimentel.edu In /etc/ypserv.securenets 255.255.255.0 192.168.0.0 In /etc/default/nis NISSERVER=master NISCLIENT=false And the command /etc/init.d/nis stop /etc/init.d/nis start And the command /usr/lib/yp/ypinit -m servidor and CTRL+D In the file /etc/ypserv.conf I included dns: no files: 30 slp: no xfr_check_port: yes In the file /etc/yp.conf I included ypserver 192.168.0.1 Edited /var/yp/Makefile MERGE_PASSWD=false MERGE_GROUP=false And after create new users run make at /var/yp And the followed steps to configure the NIS (Client): apt-get install portmap apt-get install nis In file /etc/defaultdomain pimentel.edu In file /etc/yp.conf I included ypserver 192.168.0.1 Then the commands echo + /etc/passwd echo + /etc/group echo + /etc/shadow echo + /etc/gshadow -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1359847811.3691.34.ca...@malgas.petrobras.biz
