Re: [Emc-users] NFS hassles [Was: Spindle hooked to dc servo amp]
On 21.07.12 12:51, Gene Heskett wrote: On Saturday 21 July 2012 12:14:51 Erik Christiansen did opine: To make sure we only have to debug nfs, what about trying in /etc/exports: /my/shared/filesystem 192.168.71.0/24(rw) I just changed it to this style on lathe, and it works, but shouldn't I have a ,sync after the rw? OK, then that's not only a fix, but is more robust, since it doesn't rely on DNS being and staying good. You can put the sync in, and it is probably good form. However: In releases of nfs-utils up to and including 1.0.0, this option was the default. In all releases after 1.0.0, sync is the default, and async must be explicitly requested if needed. To help make system administrators aware of this change, 'exportfs' will issue a warning if neither sync nor async is specified. So if a sudo exportfs -r does issue the warning, then sync ought to be optional, due to the default behaviour. (Yeah, I know, it's cheap insurance to just chuck it in.) ... That seems to be working on lathe. So I changed the shop machines export file to hard address, and left the ,sync option in, restarted its nfs- kernel-server, and now its working from a cli at least. and so is mc although I haven't tried to copy anything yet. Now that's good to hear. While fixing up DNS could be an interesting exercise, that doesn't make any swarf, or empty out the aircon drip tray, I figure. Erik -- Price's Advice: It's all a game -- play it to have fun. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] NFS hassles [Was: Spindle hooked to dc servo amp]
On Sunday 22 July 2012 09:02:29 Erik Christiansen did opine:
On 21.07.12 12:51, Gene Heskett wrote:
On Saturday 21 July 2012 12:14:51 Erik Christiansen did opine:
To make sure we only have to debug nfs, what about trying in
/etc/exports:
/my/shared/filesystem 192.168.71.0/24(rw)
I just changed it to this style on lathe, and it works, but shouldn't
I have a ,sync after the rw?
OK, then that's not only a fix, but is more robust, since it doesn't
rely on DNS being and staying good.
You can put the sync in, and it is probably good form. However:
In releases of nfs-utils up to and including 1.0.0, this option was
the default. In all releases after 1.0.0, sync is the default, and
async must be explicitly requested if needed. To help make
system administrators aware of this change, 'exportfs' will issue a
warning if neither sync nor async is specified.
So if a sudo exportfs -r does issue the warning, then sync ought to
be optional, due to the default behaviour.
(Yeah, I know, it's cheap insurance to just chuck it in.)
That returns the same info as a restart:exportfs: (on all currently online
machines)
/etc/exports [1]: Neither 'subtree_check' or 'no_subtree_check' specified
for export 192.168.71.3/24:/home/gene/.
Assuming default behaviour ('no_subtree_check').
NOTE: this default has changed since nfs-utils version 1.0.x
That ,no_subtre_check was in the default file before I elided it AIR.
That seems to be working on lathe. So I changed the shop machines
export file to hard address, and left the ,sync option in, restarted
its nfs- kernel-server, and now its working from a cli at least. and
so is mc although I haven't tried to copy anything yet.
Now that's good to hear. While fixing up DNS could be an interesting
exercise, that doesn't make any swarf, or empty out the aircon drip
tray, I figure.
The aircon drip tray is 100% optional if the window unit is tipped down to
the outside end. In fact, at the expense of some corrosion of the
condenser coils, not a huge problem in the real world, if you dam it up so
the condenser is running ankle deep in the drip water, you will raise the
units efficiency a bit because the heat transfer to the evaporating water
will reduce the high side pressures a bit and the compressor doesn't have
to work as hard. I worked for a tv service shop in the '50's where they
were damed up enough that the fan blade ticked the surface of the standing
water distributing it over the rear of the condenser. Worked great.
Your trivia factoid for the day. :)
Erik
True, but a small loophole, without it I can't make my .hal available so
the knowledgeable folks here can tell me I'm an idiot. :)
Which FWIW no one has, yet. I just put fresh copies as of now in the
Genes-os9-stf/GCode link of my web page. Critique's welcomed.
Which brings up a question since I have an error component to the filtered
pid.0.error output that doesn't scale with requested speed. So I think I
have a scale factor off in the encoders setp someplace. I say this because
I an under the impression that if all the pid.0.(P,I,D)gains are zeroed,
should it not take a pid.0.FF0 setp of 100 (%?) to make the pid
transparent? I don't have that condition now and I believe that to be part
of my problem, since this error signal wanders around, it makes my
electronic fuse stuff a bit touchy. It does work, I haven't blown a fuse
recently, but I think I've also had a nuisance trip or 17. Nothing damaged
either.
And I still haven't fired up that new rework station. :(
Cheers, Gene
--
There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
My web page: http://coyoteden.dyndns-free.com:85/gene is up!
Don't hit a man when he's down -- kick him; it's easier.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] NFS hassles [Was: Spindle hooked to dc servo amp]
On 20.07.12 10:51, Gene Heskett wrote: On Friday 20 July 2012 10:18:49 Erik Christiansen did opine: Would it help if we again posted some advice on how to most easily change the uids on one host to match another? While that could I suppose be useful when the distro's involved are mix-n- match, I fail to see the utility of it when I am uid:gid 1000 on all 4 machines, all installed from our own 10.04-4 LTS install cd. That's fair, since you've already done all we were suggesting. So that source of trouble has been eliminated. Much more useful would be some real examples that all I'd need to translate would be to my hostnames or even hardcoded addresses. To my knowledge, there does not seem to be a way to make these services startup like a babbling idiot and tell us what they are doing, or why they can't do it. That would be 1000's of times more useful. True. When it's failing, what do the logfiles say? ISTR that it's one of the first places you usually look, admittedly. The nfs-kernel-server package unsurprisingly logs stuff in /var/log/kern.log, and seems to be reasonably talkative, even when things are going well. Without a hint from the logs, we're reduced to shooting in the dark, or at least through a growing cloud of BP smoke of our own making. ATM, my /etc/exports file contains 1 non-commented line: /home/gene/ coyote.coyote.den(rw,sync,no_subtree_check) How does your DNS respond to that hostname, if you try a dig coyote.coyote.den, or if not, does at least ping coyote.coyote.den pick up the right IP address? (i.e. are we certain that the problem is in NFS?) Just for comparison, I've gotten away with nothing more than lines like this in /etc/exports: /export/share 192.168.1.0/24(rw) On all machines with the FQDN of that machine edited in. Similarly, the only active line in /etc/auto.master on all machines is: /net -hosts I've never tried autofs. In this case, it seems to be another potential source of gremlins. Your aversion to editing /etc/fstab is noted, but if we append a line to nfs mount a remote filesystem, it (a) shouldn't interfere with preceding mounts, IIRC, and (b) can be tested before shutting down, by invoking the mount command just with either the filesystem or mountpoint as argument. That will cause its /etc/fstab entry to be used for mounting, and prove the pudding. Once that works, then editing finger-fumbles have been tested, and a reboot need not be feared. (Later, autofs mounting could be tried, if desired, once NFS is known to work.) ... When I was running pclos on this box, with its 2.6.38.8 kernel, this all worked flawlessly except for the uid:gid problems when copying files so I always had to become root and fix that. Ah ... so the other boxes are unchanged, and the problem ought to be on this box. It's still a puzzle, without some logfile or cage-kicking clues. So how do I go about making autofs and nfs-kernel-server get all mouthy so I can see where it fails? Right now it all comes back 'OK' but doesn't actually connect anyplace but on lathe.coyote.den, which does create a /net/lathe subdirectory, but its empty. The /net directories are empty after many restarts of those 2 services in /etc/init.d on the other 2 boxes, this one and shop.coyote.den. Lappy hasn't been out of the case locally in a month or more and ATM is not on my priority list until I need it. Oh, not much is mounting at all? (I'd incorrectly recalled that it only gummed up after some time.) All the more reason for testing nfs without autofs. An IP-address-netmask pair, as worked for me, might also be worth trying. If you can post what happens when the abovementioned sticks are poked into the cage, we'll hopefully be a step closer to identifying the gremlins. Erik -- In 80% aller Software-, Hardware-, etc. Probleme hilft die AEG-Methode: Ausschalten, Einschalten, Geht wieder. OR In 80% of all Software-, Hardware-, etc. problems, the AEG method helps: Switch Off, Switch On, Goes again. (Hmmm ... it's better in the original language.) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] NFS hassles [Was: Spindle hooked to dc servo amp]
On 20.07.12 12:18, Jon Elson wrote: Erik Christiansen wrote: Would it help if we again posted some advice on how to most easily change the uids on one host to match another? Gee, something like : sudo chown -Rf x:y directory will do most of the job, then you need to make sure the group and owners exist. Edit the file /etc/group and passwd with the right group and user IDs. Yes, but having posted a more verbose version of that last time IDs were a problem, I wasn't going to push it a second time if it wasn't welcome. However, it looks like the IDs are tidied up now, so we're denied that quick fix. Erik -- That's one of the remarkable things about life. It's never so bad that it can't get worse. - Calvin -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] NFS hassles [Was: Spindle hooked to dc servo amp]
On Saturday 21 July 2012 06:55:06 Erik Christiansen did opine: On 20.07.12 10:51, Gene Heskett wrote: On Friday 20 July 2012 10:18:49 Erik Christiansen did opine: Would it help if we again posted some advice on how to most easily change the uids on one host to match another? While that could I suppose be useful when the distro's involved are mix-n- match, I fail to see the utility of it when I am uid:gid 1000 on all 4 machines, all installed from our own 10.04-4 LTS install cd. That's fair, since you've already done all we were suggesting. So that source of trouble has been eliminated. Much more useful would be some real examples that all I'd need to translate would be to my hostnames or even hardcoded addresses. To my knowledge, there does not seem to be a way to make these services startup like a babbling idiot and tell us what they are doing, or why they can't do it. That would be 1000's of times more useful. True. When it's failing, what do the logfiles say? ISTR that it's one of the first places you usually look, admittedly. The nfs-kernel-server package unsurprisingly logs stuff in /var/log/kern.log, I didn't know that, thank you. and seems to be reasonably talkative, even when things are going well. Not so much, but maybe a clue from service nfs-kernel-server restart: Jul 21 06:53:30 coyote kernel: [69826.321565] nfsd: last server has exited, flushing export cache Jul 21 06:53:31 coyote kernel: [69827.534764] svc: failed to register lockdv1 RPC service (errno 97). Jul 21 06:53:31 coyote kernel: [69827.535528] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory Jul 21 06:53:31 coyote kernel: [69827.535545] NFSD: starting 90-second grace period What is this lockdv1 RPC service? Without a hint from the logs, we're reduced to shooting in the dark, or at least through a growing cloud of BP smoke of our own making. ATM, my /etc/exports file contains 1 non-commented line: /home/gene/ coyote.coyote.den(rw,sync,no_subtree_check) How does your DNS respond to that hostname, if you try a dig coyote.coyote.den, or if not, does at least ping coyote.coyote.den pick up the right IP address? And this is nuking futz: root@coyote:/etc/init.d# dig coyote.coyote.den ; DiG 9.7.0-P1 coyote.coyote.den ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 58240 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;coyote.coyote.den. IN A ;; ANSWER SECTION: coyote.coyote.den. 60 IN A 8.15.7.122 coyote.coyote.den. 60 IN A 63.251.179.29 ;; AUTHORITY SECTION: coyote.coyote.den. 65535 IN NS WSC2.JOMAX.NET. coyote.coyote.den. 65535 IN NS WSC1.JOMAX.NET. ;; Query time: 113 msec ;; SERVER: 192.168.71.1#53(192.168.71.1) ;; WHEN: Sat Jul 21 07:00:29 2012 ;; MSG SIZE rcvd: 123 Totally AFU! root@coyote:/etc/init.d# ping -c3 coyote.coyote.den PING coyote.coyote.den (192.168.71.3) 56(84) bytes of data. 64 bytes from coyote.coyote.den (192.168.71.3): icmp_seq=1 ttl=64 time=0.022 ms 64 bytes from coyote.coyote.den (192.168.71.3): icmp_seq=2 ttl=64 time=0.016 ms 64 bytes from coyote.coyote.den (192.168.71.3): icmp_seq=3 ttl=64 time=0.025 ms In fact my local address is 192.168.71.3, and the router says my wan address is 204.111.65.217 and since I'm on a cable modem, that hasn't changed in 2+ years. My hosts file: 127.0.0.1 localhost 192.168.71.3coyote.coyote.den coyote 192.168.71.1router.coyote.den router 192.168.71.4shop.coyote.den shop 192.168.71.5lathe.coyote.denlathe 192.168.71.6lappy.coyote.denlappy # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts And resolv.conf: nameserver 192.168.71.1 domain coyote.coyote.den search hosts,dns Where the router is the gateway, which fwds the dns requests to one of the shentel servers, 209.55.24.10 or 209.55.27.13 (i.e. are we certain that the problem is in NFS?) Just for comparison, I've gotten away with nothing more than lines like this in /etc/exports: /export/share 192.168.1.0/24(rw) On all machines with the FQDN of that machine edited in. Similarly, the only active line in /etc/auto.master on all machines is: /net-hosts I've never tried autofs. In this case, it seems to be another potential source of gremlins. Your aversion to editing /etc/fstab is noted, but if we append a line to nfs mount a remote filesystem, it (a) shouldn't interfere with preceding mounts, IIRC, and (b) can be tested before shutting down, by invoking the mount command just with either the filesystem or mountpoint as argument. That will cause its /etc/fstab entry to be used for mounting, and prove
Re: [Emc-users] NFS hassles [Was: Spindle hooked to dc servo amp]
Gene: I'm not going to comment your recent emails because 1) I don't want to take the time to understand the information scattered through them and 2) the result would be unreadable:-) Assuming all hosts have the appropriate packages installed, some thoughts are: 1) maybe this is all working anyhow. Do you understand the autofs way is not actually to mount a remote directory until such time as a user tries to use it and that remote directories are unmounted after a period of unuse? Simply ls'ing the mount point isn't sufficient. It would show nil just as you report. 2) don't go any farther until you can reliably ssh between any two hosts on your network using their symbolic host names. If there are three hosts, you have 6 tests (ssh from a to b and c, from b to c and a, and from c to a). If ssh doesn't succeed, neither will the nfs executables. 3) start simple and add complexity. Forget about autofs for a moment. On each host, you should be able to start an nfs server exporting a single directory and then mount that directory manually on each client of that server. It took me just a few minutes to get this far with three new virtual Ubuntu hosts---one installed from the LinuxCNC LiveCD---running on my main machine. Again, there would be 6 tests if you want to be exhaustive about it. By the way, assuming your exports file permits it, you can mount on a particular host a directory exported by that same host. This enables doing some elementary tests without running from console to console. 4) now introduce autofs, one host at a time, and test that you can access directories exported from elsewhere, keeping 1) in mind. I have other things to do, but I'll try to get to this tonight with my virtual testbed. 5) the /var/log directory is loaded with log files. In addition to the/var/log/kern.log file already mentioned, you can look at /var/log/syslog. 6) nfs is a heterogeneous constellation of executables and configuration files which grew like kudzu over the years as different vendors got on the Sun Microsystems bandwagon. The Linux versions of these came from various sources as well. Most of the executables allow a debug option (-d) of some sort, but you have to be creative to figure out how to invoke it since some of the executables run as daemons. Remember that any executable intended to be a daemon can be run stand-alone for testing purposes. I do not claim to be an nfs guru. Indeed, I'm not even a big fan of nfs. Despite its irritations, however, it can serve (pun intended) us well. I've been gone for a while but I assume NIST still has a patchwork quilt of hundreds of hosts from many vendors running as clients and servers across the 600-acre Gaithersburg campus and between Gaithersburg MD and Boulder Colorado. Some folks ran tightly coupled to it, max'ing their use of its capabilities to manage every aspect including the boot process, the hosts and passwd files, yada yada yada; some, like me, used it only to access shared application programs and their license-key pools. Of course we had a number of NFS administrators who had to be put in their place from time to time when they started thinking they talked directly to God. Just my 2 cents worth. Regards, Kent -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] NFS hassles [Was: Spindle hooked to dc servo amp]
On 21.07.12 07:51, Gene Heskett wrote: On Saturday 21 July 2012 06:55:06 Erik Christiansen did opine: and seems to be reasonably talkative, even when things are going well. Not so much, but maybe a clue from service nfs-kernel-server restart: Jul 21 06:53:30 coyote kernel: [69826.321565] nfsd: last server has exited, flushing export cache Since most of your mounts aren't working, let's check that this doesn't mean that all the nfs daemons have left the building. A quick $ ps -ef | grep nfsd shows bunches of them here, and I've always made sure there were at least 4 of them running on a server. You get nowhere if they're gone, and I have had it happen, both on HPUX and Solaris boxes, back when I thought I knew how this stuff works. Jul 21 06:53:31 coyote kernel: [69827.534764] svc: failed to register lockdv1 RPC service (errno 97). Jul 21 06:53:31 coyote kernel: [69827.535528] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory Jul 21 06:53:31 coyote kernel: [69827.535545] NFSD: starting 90-second grace period What is this lockdv1 RPC service? Yeah. It has a real guilty look, doesn't it? Just looking at it, I guess it's a version 1 lock daemon, which the log entry is telling us is a Remote Procedure Call service. (RPC is an ancient unix protocol for making procedure calls on other machines across the network. If you do a man -a rpc, you'll see that you could use it to get at nfs and portmapper services from a C program.) Incidentally, nfs needs one of them too, IIRC: $ ps -ef | egrep portmap daemon 701 1 0 16:22 ?00:00:00 portmap The registration failure doesn't have to mean much, though. I have the same here: Jul 21 17:39:34 ratatosk kernel: [ 4638.217979] svc: failed to register lockdv1 RPC service (errno 97). I'm happy with this: $ ps -ef | egrep '(lockd|statd)' # egrep, not just grep. ;-) root15 2 0 16:22 ?00:00:00 [kblockd/0] root 3073 1 0 17:39 ?00:00:00 rpc.statd -L root 3340 2 0 17:39 ?00:00:00 [lockd] NFS does need lockd and statd, to work properly, AFAIR, but it doesn't have to be lockdv1, I figure. ... How does your DNS respond to that hostname, if you try a dig coyote.coyote.den, or if not, does at least ping coyote.coyote.den pick up the right IP address? And this is nuking futz: ... Crook DNS results cropped to shorten things. Totally AFU! OK, we don't want to rely on DNS to resolve those hostnames. ;-) ... Good ping results wuz here. My hosts file: 127.0.0.1 localhost 192.168.71.3 coyote.coyote.den coyote 192.168.71.1 router.coyote.den router 192.168.71.4 shop.coyote.den shop 192.168.71.5 lathe.coyote.denlathe 192.168.71.6 lappy.coyote.denlappy # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts And resolv.conf: nameserver 192.168.71.1 domain coyote.coyote.den searchhosts,dns Where the router is the gateway, which fwds the dns requests to one of the shentel servers, 209.55.24.10 or 209.55.27.13 That's similar to what I have here, and a ping checks /etc/hosts, but dig doesn't, although I have: $ more /etc/host.conf # The order line is only used by old versions of the C library. order hosts,bind multi on And there's a likely explanation for why dns doesn't check /ets/hosts here either, because that C library is the resolver library. ... More good ping results elided. I do not have a local to this machine dns server (adns, dnsmasq, etc) installed, and just installed dnswalk to see what it says: root@coyote:/var# dnswalk -adilrfFm coyote.coyote.den. Checking coyote.coyote.den. BAD: SOA record not found for coyote.coyote.den. !BAD: coyote.coyote.den. has NO authoritative nameservers! !BAD: All zone transfer attempts of coyote.coyote.den. failed! !0 failures, 0 warnings, 3 errors. To make sure we only have to debug nfs, what about trying in /etc/exports: /my/shared/filesystem 192.168.71.0/24(rw) (I've forgotten the names of what you're exporting) Now we don't have to resolve any hostnames, which eliminates another potential cause of the observed failure. The other mount attributes won't hurt, but they're both defaults now, IIUC. And of coarse there is no /var/named directory. I figured the hosts files should handle the local stuff if its not in the hosts file, send it to the gateway, my router, which is a Buffalo Hi-Power running genuine dd-wrt. So despite the dig results, I should be covered. Humm, hostname returns the alias! root@coyote:/var# hostname coyote Should be, but what happens with 192.168.71.0/24(rw) in /etc/exports, I wonder? Should it not be returning the FQDN? Try: $ hostname --fqdn So there are 3 head scratchers above. I just ran hostname and
Re: [Emc-users] NFS hassles [Was: Spindle hooked to dc servo amp]
On Saturday 21 July 2012 11:53:33 Kent A. Reed did opine: Gene: I'm not going to comment your recent emails because 1) I don't want to take the time to understand the information scattered through them and 2) the result would be unreadable:-) Assuming all hosts have the appropriate packages installed, some thoughts are: 1) maybe this is all working anyhow. Do you understand the autofs way is not actually to mount a remote directory until such time as a user tries to use it and that remote directories are unmounted after a period of unuse? Simply ls'ing the mount point isn't sufficient. It would show nil just as you report. I am aware of that. Now here it gets odd. I can cd to /net/lathe, or /net/shop (I should change its name to mill, but it was first) and then see the home dir exported. And I haven't changed anything since the last time mc would not do the cd. And just now, mc can cd to /net/shop/home or /net/lathe/home, but is getting no perms errors from any attempt to cd into the home/gene tree. Humm, a what the F moment, it says here that root:root owns /net/lathe/home/gene! But if I ssh -Y into lathe, an ls -l says /home/gene is indeed owned by gene:gene. Do I have an export rule boogered? 2) don't go any farther until you can reliably ssh between any two hosts on your network using their symbolic host names. If there are three hosts, you have 6 tests (ssh from a to b and c, from b to c and a, and from c to a). If ssh doesn't succeed, neither will the nfs executables. ssh -Y logins will let me use vim, and I can run linuxcnc over the link, but gedit 'can't open display'. As I'm using the neauvou display driver here, I think that could be related, the last time I was running the nvidia drivers it worked. 3) start simple and add complexity. Forget about autofs for a moment. On each host, you should be able to start an nfs server exporting a single directory and then mount that directory manually on each client of that server. It took me just a few minutes to get this far with three new virtual Ubuntu hosts---one installed from the LinuxCNC LiveCD---running on my main machine. Again, there would be 6 tests if you want to be exhaustive about it. By the way, assuming your exports file permits it, you can mount on a particular host a directory exported by that same host. This enables doing some elementary tests without running from console to console. 4) now introduce autofs, one host at a time, and test that you can access directories exported from elsewhere, keeping 1) in mind. I have other things to do, but I'll try to get to this tonight with my virtual testbed. 5) the /var/log directory is loaded with log files. In addition to the/var/log/kern.log file already mentioned, you can look at /var/log/syslog. 6) nfs is a heterogeneous constellation of executables and configuration files which grew like kudzu over the years as different vendors got on the Sun Microsystems bandwagon. The Linux versions of these came from various sources as well. Most of the executables allow a debug option (-d) of some sort, but you have to be creative to figure out how to invoke it since some of the executables run as daemons. Remember that any executable intended to be a daemon can be run stand-alone for testing purposes. I do not claim to be an nfs guru. Indeed, I'm not even a big fan of nfs. Despite its irritations, however, it can serve (pun intended) us well. I've been gone for a while but I assume NIST still has a patchwork quilt of hundreds of hosts from many vendors running as clients and servers across the 600-acre Gaithersburg campus and between Gaithersburg MD and Boulder Colorado. Some folks ran tightly coupled to it, max'ing their use of its capabilities to manage every aspect including the boot process, the hosts and passwd files, yada yada yada; some, like me, used it only to access shared application programs and their license-key pools. Of course we had a number of NFS administrators who had to be put in their place from time to time when they started thinking they talked directly to God. Chuckle, I've dealt with the type. Peter Principle at work. :) Just my 2 cents worth. Potentially worth more, thanks Kent. Regards, Kent -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users Cheers, Gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order.
Re: [Emc-users] NFS hassles [Was: Spindle hooked to dc servo amp]
On Saturday 21 July 2012 12:14:51 Erik Christiansen did opine: On 21.07.12 07:51, Gene Heskett wrote: On Saturday 21 July 2012 06:55:06 Erik Christiansen did opine: and seems to be reasonably talkative, even when things are going well. Not so much, but maybe a clue from service nfs-kernel-server restart: Jul 21 06:53:30 coyote kernel: [69826.321565] nfsd: last server has exited, flushing export cache Since most of your mounts aren't working, let's check that this doesn't mean that all the nfs daemons have left the building. A quick $ ps -ef | grep nfsd shows bunches of them here, and I've always made sure there were at least 4 of them running on a server. You get nowhere if they're gone, and I have had it happen, both on HPUX and Solaris boxes, back when I thought I knew how this stuff works. Same here, at least 7 or 8 copies. Owned by root.. Jul 21 06:53:31 coyote kernel: [69827.534764] svc: failed to register lockdv1 RPC service (errno 97). Jul 21 06:53:31 coyote kernel: [69827.535528] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory Jul 21 06:53:31 coyote kernel: [69827.535545] NFSD: starting 90-second grace period What is this lockdv1 RPC service? Yeah. It has a real guilty look, doesn't it? Just looking at it, I guess it's a version 1 lock daemon, which the log entry is telling us is a Remote Procedure Call service. (RPC is an ancient unix protocol for making procedure calls on other machines across the network. If you do a man -a rpc, you'll see that you could use it to get at nfs and portmapper services from a C program.) Incidentally, nfs needs one of them too, IIRC: $ ps -ef | egrep portmap daemon 701 1 0 16:22 ?00:00:00 portmap Yup, got one as expected. The registration failure doesn't have to mean much, though. I have the same here: Jul 21 17:39:34 ratatosk kernel: [ 4638.217979] svc: failed to register lockdv1 RPC service (errno 97). I'm happy with this: $ ps -ef | egrep '(lockd|statd)' # egrep, not just grep. ;-) root15 2 0 16:22 ?00:00:00 [kblockd/0] root 3073 1 0 17:39 ?00:00:00 rpc.statd -L root 3340 2 0 17:39 ?00:00:00 [lockd] I get this: gene@coyote:~$ ps -ef|egrep 'lockd|statd' root30 2 0 Jul20 ?00:00:00 [kblockd/0] root31 2 0 Jul20 ?00:00:00 [kblockd/1] root32 2 0 Jul20 ?00:00:00 [kblockd/2] root33 2 0 Jul20 ?00:00:00 [kblockd/3] statd 1323 1 0 Jul20 ?00:00:00 rpc.statd -L gene 4657 2848 0 12:17 pts/600:00:00 egrep lockd|statd root 25280 2 0 07:44 ?00:00:00 [lockd] So its there. NFS does need lockd and statd, to work properly, AFAIR, but it doesn't have to be lockdv1, I figure. ... How does your DNS respond to that hostname, if you try a dig coyote.coyote.den, or if not, does at least ping coyote.coyote.den pick up the right IP address? And this is nuking futz: ... Crook DNS results cropped to shorten things. Totally AFU! OK, we don't want to rely on DNS to resolve those hostnames. ;-) ... Good ping results wuz here. My hosts file: 127.0.0.1 localhost 192.168.71.3coyote.coyote.den coyote 192.168.71.1router.coyote.den router 192.168.71.4shop.coyote.den shop 192.168.71.5lathe.coyote.denlathe 192.168.71.6lappy.coyote.denlappy # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts And resolv.conf: nameserver 192.168.71.1 domain coyote.coyote.den search hosts,dns Where the router is the gateway, which fwds the dns requests to one of the shentel servers, 209.55.24.10 or 209.55.27.13 That's similar to what I have here, and a ping checks /etc/hosts, but dig doesn't, although I have: $ more /etc/host.conf # The order line is only used by old versions of the C library. order hosts,bind multi on And there's a likely explanation for why dns doesn't check /ets/hosts here either, because that C library is the resolver library. ... More good ping results elided. I do not have a local to this machine dns server (adns, dnsmasq, etc) installed, and just installed dnswalk to see what it says: root@coyote:/var# dnswalk -adilrfFm coyote.coyote.den. Checking coyote.coyote.den. BAD: SOA record not found for coyote.coyote.den. !BAD: coyote.coyote.den. has NO authoritative nameservers! !BAD: All zone transfer attempts of coyote.coyote.den. failed! !0 failures, 0 warnings, 3 errors. To make sure we only have to debug nfs, what about trying in /etc/exports: /my/shared/filesystem 192.168.71.0/24(rw) I just changed it to
[Emc-users] NFS hassles [Was: Spindle hooked to dc servo amp]
On 17.07.12 20:08, Jon Elson wrote: Gene Heskett wrote: What the heck is the diff, I own that file on all 4 machines! OK, well, there's one of your problems. NFS is a local files system on each node, and you MUST coordinate file owner IDs across all the systems, or use proxies. sftp avoids that problem, as each end of the sftp session is logged into its machine, and files brought across get the local owner's permissions. Gene, Jon's giving you the good oil there. Those vagrant uids you've had floating about on the various boxes have provided us all with entertainment for a while now. If the amusement value can't be done without, then one way to overcome the NFS requirement that uids and gids match across hosts, is to use id squashing, I believe. (Though I've never allowed the chaos which would warrant using it, and it seems like just papering over cracks, in this case.) Would it help if we again posted some advice on how to most easily change the uids on one host to match another? Erik -- Once, adv.: Enough. - Ambrose Bierce, The Devil's Dictionary -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] NFS hassles [Was: Spindle hooked to dc servo amp]
On Friday 20 July 2012 10:18:49 Erik Christiansen did opine: On 17.07.12 20:08, Jon Elson wrote: Gene Heskett wrote: What the heck is the diff, I own that file on all 4 machines! OK, well, there's one of your problems. NFS is a local files system on each node, and you MUST coordinate file owner IDs across all the systems, or use proxies. sftp avoids that problem, as each end of the sftp session is logged into its machine, and files brought across get the local owner's permissions. Gene, Jon's giving you the good oil there. Those vagrant uids you've had floating about on the various boxes have provided us all with entertainment for a while now. If the amusement value can't be done without, then one way to overcome the NFS requirement that uids and gids match across hosts, is to use id squashing, I believe. (Though I've never allowed the chaos which would warrant using it, and it seems like just papering over cracks, in this case.) Would it help if we again posted some advice on how to most easily change the uids on one host to match another? Erik While that could I suppose be useful when the distro's involved are mix-n- match, I fail to see the utility of it when I am uid:gid 1000 on all 4 machines, all installed from our own 10.04-4 LTS install cd. Much more useful would be some real examples that all I'd need to translate would be to my hostnames or even hardcoded addresses. To my knowledge, there does not seem to be a way to make these services startup like a babbling idiot and tell us what they are doing, or why they can't do it. That would be 1000's of times more useful. ATM, my /etc/exports file contains 1 non-commented line: /home/gene/ coyote.coyote.den(rw,sync,no_subtree_check) On all machines with the FQDN of that machine edited in. Similarly, the only active line in /etc/auto.master on all machines is: /net-hosts All machines share the same hosts file listing the 192.168.xx.x address, its FQDN and alias, a listing of the whole local net. The exports file on the other machines I can't show because I shut them all off last night due to lots of nearby sky fireworks. From memory each exports file has: /home/gene/ shop.coyote.den(rw,sync,no_subtree_check) /home/gene/ lathe.coyote.den(rw,sync,no_subtree_check) /home/gene/ lappy.coyote.den(rw,sync,no_subtree_check) When I was running pclos on this box, with its 2.6.38.8 kernel, this all worked flawlessly except for the uid:gid problems when copying files so I always had to become root and fix that. So how do I go about making autofs and nfs-kernel-server get all mouthy so I can see where it fails? Right now it all comes back 'OK' but doesn't actually connect anyplace but on lathe.coyote.den, which does create a /net/lathe subdirectory, but its empty. The /net directories are empty after many restarts of those 2 services in /etc/init.d on the other 2 boxes, this one and shop.coyote.den. Lappy hasn't been out of the case locally in a month or more and ATM is not on my priority list until I need it. Thanks Guys. Cheers, Gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) My web page: http://coyoteden.dyndns-free.com:85/gene is up! The rule is, jam to-morrow and jam yesterday, but never jam today. -- Lewis Carroll -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] NFS hassles [Was: Spindle hooked to dc servo amp]
Erik Christiansen wrote: Would it help if we again posted some advice on how to most easily change the uids on one host to match another? Gee, something like : sudo chown -Rf x:y directory will do most of the job, then you need to make sure the group and owners exist. Edit the file /etc/group and passwd with the right group and user IDs. Jon -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
