Date: Mon, 1 Feb 1999 14:25:03 +1300
From: Joe Abley jab...@clear.co.nz
Never had a problem with it. Just to confirm that amd is not hideously
broken beyond the point where _some_ people can use it just fine.
Likewise, though nearly all of our NFS activity is among FreeBSD boxen.
And we use NIS
Yes, to be consistent with the state of world WRT NFS. Or at least with
the leader -- Solaris. This has been the default in 3.0-C since the
am-utils import.
Yeah, well, amd is a whole other ball of wax. That's clearly broken
in both 3.0-stable and 4.0-current
Why is it clearly
Why is it clearly broken? proto=tcp,vers=3 is what is in 3.0-RELEASE,
Amd in 3.0 works for many. I won't defend that the new Amd works the
best with us, but then neither did the old Amd.
Erm, I haven't tried it between 3.0 and 3.0 boxes because all my test
environments currently involve one
Jordan K. Hubbard wrote:
Why is it clearly broken? proto=tcp,vers=3 is what is in 3.0-RELEASE,
Amd in 3.0 works for many. I won't defend that the new Amd works the
best with us, but then neither did the old Amd.
Erm, I haven't tried it between 3.0 and 3.0 boxes because all my test
Of all the gin joints in all the towns in all the world, Jordan K.
Hubbard had to walk into mine and say:
Why is it clearly broken? proto=tcp,vers=3 is what is in 3.0-RELEASE,
Amd in 3.0 works for many. I won't defend that the new Amd works the
best with us, but then neither did the old
I use -l /tmp/.automsg (or some other filename that lusers aren't likely
..snip..
I've found that am-utils is much more verbose than previous versions of
amd so you may not want to leave it that way permanently ...
/var/log/amd.log and add it to /etc/newsyslog.conf.
Since this is what I use,
Err On all of the machines where I use amd, I don't use -l syslog.
I use -l /tmp/.automsg (or some other filename that lusers aren't likely
You're right, that does produce more information. Unfortunatly, not
enough to help diagnose the problem. :( I think something more
fundamental is
I've been using amd on bleeding-edge current for the past year or so with
no problems - the servers in my case are Solaris 2.5.1 boxes.
I remember becoming extremely confused when I configured my first amd map
file, since there was no coherent documentation to be found at the time, but
I ended up
On Sun, 31 Jan 1999 04:18:25 -0800, Jordan K. Hubbard
j...@zippy.cdrom.com said:
Erm, I haven't tried it between 3.0 and 3.0 boxes because all my test
environments currently involve one of each (4.0 and 3.0), but I can
certainly say that in none of these test environments does amd work at
Scenario: Two machines, releng3.freebsd.org (running 3.0-stable) and
current.freebsd.org (running 4.0-current). releng3 has all the disk
space and is the NFS server. current is an NFS client and uses
releng3 for its CVS repository, FTP snapshot stashing area, etc.
As of the day before
In article 91639.917702...@zippy.cdrom.com,
Jordan K. Hubbard j...@zippy.cdrom.com wrote:
As of the day before yesterday, I started getting all manner of NFS
errors on current and checked the amd.conf file it was using.
Version 3 of NFS seemed to be the default (!) for amd so I changed
it to
errors on current and checked the amd.conf file it was using.
Version 3 of NFS seemed to be the default (!) for amd
Yes, to be consistent with the state of world WRT NFS. Or at least with
the leader -- Solaris. This has been the default in 3.0-C since the
am-utils import.
it to version 2
Yes, to be consistent with the state of world WRT NFS. Or at least with
the leader -- Solaris. This has been the default in 3.0-C since the
am-utils import.
Yeah, well, amd is a whole other ball of wax. That's clearly broken
in both 3.0-stable and 4.0-current and we're going to have to
13 matches
Mail list logo
