>Date: Mon, 1 Feb 1999 14:25:03 +1300
>From: Joe Abley
>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 for the amd ma
< 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
> all.
Works just fine on a somewhat older 3.0 (which is still running the
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
> 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 br
> 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
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
"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 t
> 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 on
> > 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 clear
> 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 re
> 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
In article <91639.917702...@zippy.cdrom.com>,
Jordan K. Hubbard 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 version 2 a
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 yesterday,
13 matches
Mail list logo
