Re: two questions about autofs on FBSD
On 1/8/20 13:09 , Edward Tomasz Napierała wrote: > I'm afraid linking isn't supported. I've always considered it > an optimization that made sense back when NFS could have significant > overhead and nowadays just wasn't worth it. > > One thing you could try is to use nullfs(5) instead of NFS for this > specific case. I no longer remember all the details, but simply adding > '-t nullfs' to the map entry above should work. Part of the problem for me is that I need to use the same map files on multiple OSs. :/path/to/thing works in Linux but doesn't work in FBSD. I haven't had a chance to try -t nullfs yet but I'm going to bet it doesn't work in Linux. Then there's omnios ... > Executing "automount" will refresh top-level mounts (ie all the filesystems > of type "autofs"); running "automount -c" will flush cached maps referenced > from /etc/auto_master. Thanks. I'll try that next time this project comes around on the guitar (which is to say, probably Friday). nomad ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: two questions about autofs on FBSD
On 0103T1602, Lee Damon wrote: > I am (reluctantly) replacing am-utils (amd) with autofs. To do this I > need to replace a lot of functionality that I've had embedded for a very > long time and which my users absolutely rely on. I have two (so far) > questions that I need to solve before I can proceed with this process. > > Question 1 - One of those features is the ability to use a symlink > instead of a NFS mount. For a simplistic example: > > /homes/accountname -> /net/server/home/accountname > > On Linux this is a : entry in /etc/auto.homes: > accountname :/net/server/home/accountname > > but when I test it on FBSD 11-3 I get: > automountd[1784]: "mount -t nfs -o automounted,retrycnt=1 > /net/[redacted]/vol/home/[redacted] /homes/[redacted]/", pid 1785, > terminated with exit status 1 > > Which sure looks like it is trying to NFS mount the local filesystem, > which clearly won't work. > > I use this functionality all over the place including linking into AFS > space and making smart decisions of which subdirectory to present, so I > can't just turn all of the links into NFS mounts. > > I found a bug report against the 10.1 version of autofs asking for the > linking functionality but it was closed with no comment. I'm not finding > any other documentation that references how to do a link. I'm afraid linking isn't supported. I've always considered it an optimization that made sense back when NFS could have significant overhead and nowadays just wasn't worth it. One thing you could try is to use nullfs(5) instead of NFS for this specific case. I no longer remember all the details, but simply adding '-t nullfs' to the map entry above should work. > The media mount seems to be done via a special script instead of just a > link. So, I have to ask, is this something that can be done? How do I do it? Media mounts are handled by executable maps, aka special maps; there's nothing media-specific in autofs itself, apart from the /etc/autofs/special_media shell script. Now that you mention it, there is a /etc/autofs/include_nis_nullfs special map which does the nullfs symlink, although it's to be used with NIS. Might be useful if adding "-t nullfs" in a static map file isn't enough. > Question 2 - How do I get automount to reload a map if a filesystem is > already mounted? It looks like issuing the "automount" command with no > flags should get it to reload maps but it seems to be ignoring any > changes to a map if that map has anything active. > > 99% of my map updates are to add a new filesystem to an existing map and > I need all of the hosts to pick up the changes the next time CM runs. On > Linux "systemctl reload autofs" does it but "service automount reload" > doesn't exist, and as I said, "automount" ignores map changes for active > maps. I'm _certain_ I'm missing something simple and obvious here, I > can't believe there's no way to reload an active map. > > Any information related to either question is much appreciated. Executing "automount" will refresh top-level mounts (ie all the filesystems of type "autofs"); running "automount -c" will flush cached maps referenced from /etc/auto_master. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
two questions about autofs on FBSD
I am (reluctantly) replacing am-utils (amd) with autofs. To do this I need to replace a lot of functionality that I've had embedded for a very long time and which my users absolutely rely on. I have two (so far) questions that I need to solve before I can proceed with this process. Question 1 - One of those features is the ability to use a symlink instead of a NFS mount. For a simplistic example: /homes/accountname -> /net/server/home/accountname On Linux this is a : entry in /etc/auto.homes: accountname :/net/server/home/accountname but when I test it on FBSD 11-3 I get: automountd[1784]: "mount -t nfs -o automounted,retrycnt=1 /net/[redacted]/vol/home/[redacted] /homes/[redacted]/", pid 1785, terminated with exit status 1 Which sure looks like it is trying to NFS mount the local filesystem, which clearly won't work. I use this functionality all over the place including linking into AFS space and making smart decisions of which subdirectory to present, so I can't just turn all of the links into NFS mounts. I found a bug report against the 10.1 version of autofs asking for the linking functionality but it was closed with no comment. I'm not finding any other documentation that references how to do a link. The media mount seems to be done via a special script instead of just a link. So, I have to ask, is this something that can be done? How do I do it? Question 2 - How do I get automount to reload a map if a filesystem is already mounted? It looks like issuing the "automount" command with no flags should get it to reload maps but it seems to be ignoring any changes to a map if that map has anything active. 99% of my map updates are to add a new filesystem to an existing map and I need all of the hosts to pick up the changes the next time CM runs. On Linux "systemctl reload autofs" does it but "service automount reload" doesn't exist, and as I said, "automount" ignores map changes for active maps. I'm _certain_ I'm missing something simple and obvious here, I can't believe there's no way to reload an active map. Any information related to either question is much appreciated. thanks nomad ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Interaction between make & autofs/automountd
On Tue, Apr 05, 2016 at 01:58:40PM +0200, Edward Tomasz Napierała wrote: > ... > > > > automountd: waiting for request from the kernel > > automountd: not forking due to -d flag; will exit after servicing a single > > request > > automountd: got request 553: from map -hosts, path /net/, prefix "/net", > > key "share", options "nosuid,intr" > > automountd: parsing map "-hosts" > > automountd: executing "/etc/autofs/special_hosts share" as pid 12717 > > RPC: Unknown host > > showmount: can't do exports rpc > > automountd: "/etc/autofs/special_hosts share", pid 12717, terminated with > > exit status 1 > > automountd: failed to handle special map "-hosts" > > automountd: completing request 553 with error 5 > > > > > > So if the above is to be believed (which I certainly hope!), something > > is causing invocation of: > > > > /etc/autofs/special_hosts share > > > > which is problematic, as the argument (if any) to /etc/autofs/special_hosts > > is expected to be an entry name from /etc/hosts (or equivalent). > > > > In turn, this appears to be happening because something is invoking > > automountd with 'key "share"' -- and I'm not seeing what is doing that, > > but "make" seems to be one of the few(?) things that prompts this > > behavior. > > Hm, that's curious. Could you perhaps try to use ktrace(1) to see > if something is eg trying to access /net/share for some reason? Aye -- and sure enough, it's smake(1). Here's what appears to be the relevant excerpt of the decoded ktrace, from an invocation of: ktrace -di make -C /usr/ports/sysutils/dmidecode -V PKGNAME ... 26861 make CALL close(0x3) 26861 make RET close 0 26861 make CALL stat(0x7fffce10,0x7fffcd98) 26861 make NAMI "/net/howland/c/ports/sysutils/dmidecode/obj.amd64" 26861 make RET stat -1 errno 2 No such file or directory 26861 make CALL stat(0x7fffce10,0x7fffcd98) 26861 make NAMI "/net/howland/c/ports/sysutils/dmidecode/obj" 26861 make RET stat -1 errno 2 No such file or directory 26861 make CALL stat(0x7fffe090,0x7fffcd98) 26861 make NAMI "/usr/obj/net/howland/c/ports/sysutils/dmidecode" 26861 make RET stat -1 errno 2 No such file or directory 26861 make CALL stat(0x7fffc9f0,0x7fffc978) 26861 make NAMI "/net/howland/c/ports/sysutils/dmidecode/share/mk" 26861 make RET stat -1 errno 2 No such file or directory 26861 make CALL stat(0x7fffc9f0,0x7fffc978) 26861 make NAMI "/net/howland/c/ports/sysutils/share/mk" 26861 make RET stat -1 errno 2 No such file or directory 26861 make CALL stat(0x7fffc9f0,0x7fffc978) 26861 make NAMI "/net/howland/c/ports/share/mk" 26861 make RET stat -1 errno 2 No such file or directory 26861 make CALL stat(0x7fffc9f0,0x7fffc978) 26861 make NAMI "/net/howland/c/share/mk" 26861 make RET stat -1 errno 2 No such file or directory 26861 make CALL stat(0x7fffc9f0,0x7fffc978) 26861 make NAMI "/net/howland/share/mk" 26861 make RET stat -1 errno 2 No such file or directory 26861 make CALL stat(0x7fffc9f0,0x7fffc978) 26861 make NAMI "/net/share/mk" 26861 make RET stat -1 errno 2 No such file or directory 26861 make CALL stat(0x7fffc9f0,0x7fffc978) 26861 make NAMI "/share/mk" 26861 make RET stat -1 errno 2 No such file or directory 26861 make CALL open(0x6a229d,0x120004<O_NONBLOCK|O_DIRECTORY|O_CLOEXEC>,0x2f) 26861 make NAMI "/usr/share/mk" 26861 make RET open 3 26861 make CALL fstatfs(0x3,0x7fffcfd8) 26861 make RET fstatfs 0 I'm happy to provide the whole thing, if that would be useful. But the above looks as if make(1) is trying to find a local override for /usr/share/mk/ (which override I don't have). I suppose it's also possible that other programs might do similar things. > > In the mean time, I've now circumvented the issue in my case by > > creating a CNAME named "share" that points to the hostname of the > > NFS server. And sure enough, I no longer see the whines. > > > > While that does give a clear(er) indication of the nature of the > > problem, I suspect I'm setting myself up for "interesting modes of > > failure" when I need to refer to data that reside on a different > > NFS server (also accessed via the automounter). > > Well, the requests were already failing with EIO, it's just that > they fail much q
Re: Interaction between make & autofs/automountd
On 0404T0549, David Wolfskill wrote: > On Mon, Jan 11, 2016 at 07:28:49AM -0800, David Wolfskill wrote: > > ... > > A couple of the machines use autofs & automountd to make the ports tree > > available on demand. (In the case of the 3rd, I manually mount it when > > needed, but that's not at issue for this note, and I won't pursue that > > further here.) > > > > The machines that use autofs do so by using symlinks and the existing > > maps; e.g.: > > > > albert(10.2-S)[7] ls -lT /usr/ports > > lrwxr-xr-x 1 root wheel 20 Dec 21 04:15:39 2010 /usr/ports -> > > /net/howland/c/ports > > ... > > > > The contents of /etc/autofs are "vanilla" -- I have not changed > > them. I did modify /etc/auto_master a bit, to remove the "nobrowse" > > option for -net. > > > > For most purposes, including: > > * svn update > > * cd to a port directory > > * Updating files in distfiles > > * reading arbitrary files in the tree > > > > this works well, and there's no indication of any problems or issues. > > > > I recently noticed, thiough, that running "portmaster -aF" generates a > > large number of messages. > > > > I was able to narrow this down to portmaster's invocation of (e.g.) > > * cd /usr/ports/sysutils/dmidecode > > * make -V PKGNAME > > > > The "cd" seems OK; it's the "make -V PKGNAME" -- even if I invoke it by: > > hand. It works, but at the expense of messages: > > > > albert(10.2-S)[4] dirs; date; make -V PKGNAME; date > > /usr/ports/sysutils/dmidecode > > Mon Jan 11 07:26:45 PST 2016 > > dmidecode-3.0 > > Mon Jan 11 07:26:47 PST 2016 > > albert(10.2-S)[5] > > > > Jan 11 15:26:45 albert automountd[13912]: "/etc/autofs/special_hosts > > share", pid 13913, terminated with exit status 1 > > Jan 11 15:26:45 albert automountd[13912]: failed to handle special map > > "-hosts" > > Jan 11 15:26:45 albert kernel: WARNING: autofs_trigger_one: request for > > /net/ completed with error 5 > > Jan 11 15:26:46 albert automountd[13915]: "/etc/autofs/special_hosts > > share", pid 13916, terminated with exit status 1 > > Jan 11 15:26:46 albert automountd[13915]: failed to handle special map > > "-hosts" > > Jan 11 15:26:46 albert kernel: WARNING: autofs_trigger_one: request for > > /net/ completed with error 5 > > Jan 11 15:26:47 albert automountd[13918]: "/etc/autofs/special_hosts > > share", pid 13919, terminated with exit status 1 > > Jan 11 15:26:47 albert automountd[13918]: failed to handle special map > > "-hosts" > > Jan 11 15:26:47 albert kernel: WARNING: autofs_trigger_one: request for > > /net/ completed with error 5 > > ... > > The above got to bugging me enough that I looked into it again, and I > stumbled across <https://forums.freebsd.org/threads/49012/> in the > process of trying figure out what was wrong. Using the clue there (of > manually starting automountd in debugging mode), I find: > > automountd: waiting for request from the kernel > automountd: not forking due to -d flag; will exit after servicing a single > request > automountd: got request 553: from map -hosts, path /net/, prefix "/net", key > "share", options "nosuid,intr" > automountd: parsing map "-hosts" > automountd: executing "/etc/autofs/special_hosts share" as pid 12717 > RPC: Unknown host > showmount: can't do exports rpc > automountd: "/etc/autofs/special_hosts share", pid 12717, terminated with > exit status 1 > automountd: failed to handle special map "-hosts" > automountd: completing request 553 with error 5 > > > So if the above is to be believed (which I certainly hope!), something > is causing invocation of: > > /etc/autofs/special_hosts share > > which is problematic, as the argument (if any) to /etc/autofs/special_hosts > is expected to be an entry name from /etc/hosts (or equivalent). > > In turn, this appears to be happening because something is invoking > automountd with 'key "share"' -- and I'm not seeing what is doing that, > but "make" seems to be one of the few(?) things that prompts this > behavior. Hm, that's curious. Could you perhaps try to use ktrace(1) to see if something is eg trying to access /net/share for some reason? > In the mean time, I've now circumvented the issue in my case by > creating a CNAME named "share" that points to the hostname of the > NFS server. And sure enough, I no longer see the whines. > > While that does give a clear(er) indication of the nature of the > problem, I suspect I'm setting myself up for "interesting modes of > failure" when I need to refer to data that reside on a different > NFS server (also accessed via the automounter). Well, the requests were already failing with EIO, it's just that they fail much quicker now :-) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Interaction between make & autofs/automountd
On Mon, Jan 11, 2016 at 07:28:49AM -0800, David Wolfskill wrote: > ... > A couple of the machines use autofs & automountd to make the ports tree > available on demand. (In the case of the 3rd, I manually mount it when > needed, but that's not at issue for this note, and I won't pursue that > further here.) > > The machines that use autofs do so by using symlinks and the existing > maps; e.g.: > > albert(10.2-S)[7] ls -lT /usr/ports > lrwxr-xr-x 1 root wheel 20 Dec 21 04:15:39 2010 /usr/ports -> > /net/howland/c/ports > ... > > The contents of /etc/autofs are "vanilla" -- I have not changed > them. I did modify /etc/auto_master a bit, to remove the "nobrowse" > option for -net. > > For most purposes, including: > * svn update > * cd to a port directory > * Updating files in distfiles > * reading arbitrary files in the tree > > this works well, and there's no indication of any problems or issues. > > I recently noticed, thiough, that running "portmaster -aF" generates a > large number of messages. > > I was able to narrow this down to portmaster's invocation of (e.g.) > * cd /usr/ports/sysutils/dmidecode > * make -V PKGNAME > > The "cd" seems OK; it's the "make -V PKGNAME" -- even if I invoke it by: > hand. It works, but at the expense of messages: > > albert(10.2-S)[4] dirs; date; make -V PKGNAME; date > /usr/ports/sysutils/dmidecode > Mon Jan 11 07:26:45 PST 2016 > dmidecode-3.0 > Mon Jan 11 07:26:47 PST 2016 > albert(10.2-S)[5] > > Jan 11 15:26:45 albert automountd[13912]: "/etc/autofs/special_hosts share", > pid 13913, terminated with exit status 1 > Jan 11 15:26:45 albert automountd[13912]: failed to handle special map > "-hosts" > Jan 11 15:26:45 albert kernel: WARNING: autofs_trigger_one: request for /net/ > completed with error 5 > Jan 11 15:26:46 albert automountd[13915]: "/etc/autofs/special_hosts share", > pid 13916, terminated with exit status 1 > Jan 11 15:26:46 albert automountd[13915]: failed to handle special map > "-hosts" > Jan 11 15:26:46 albert kernel: WARNING: autofs_trigger_one: request for /net/ > completed with error 5 > Jan 11 15:26:47 albert automountd[13918]: "/etc/autofs/special_hosts share", > pid 13919, terminated with exit status 1 > Jan 11 15:26:47 albert automountd[13918]: failed to handle special map > "-hosts" > Jan 11 15:26:47 albert kernel: WARNING: autofs_trigger_one: request for /net/ > completed with error 5 > ... The above got to bugging me enough that I looked into it again, and I stumbled across <https://forums.freebsd.org/threads/49012/> in the process of trying figure out what was wrong. Using the clue there (of manually starting automountd in debugging mode), I find: automountd: waiting for request from the kernel automountd: not forking due to -d flag; will exit after servicing a single request automountd: got request 553: from map -hosts, path /net/, prefix "/net", key "share", options "nosuid,intr" automountd: parsing map "-hosts" automountd: executing "/etc/autofs/special_hosts share" as pid 12717 RPC: Unknown host showmount: can't do exports rpc automountd: "/etc/autofs/special_hosts share", pid 12717, terminated with exit status 1 automountd: failed to handle special map "-hosts" automountd: completing request 553 with error 5 So if the above is to be believed (which I certainly hope!), something is causing invocation of: /etc/autofs/special_hosts share which is problematic, as the argument (if any) to /etc/autofs/special_hosts is expected to be an entry name from /etc/hosts (or equivalent). In turn, this appears to be happening because something is invoking automountd with 'key "share"' -- and I'm not seeing what is doing that, but "make" seems to be one of the few(?) things that prompts this behavior. In the mean time, I've now circumvented the issue in my case by creating a CNAME named "share" that points to the hostname of the NFS server. And sure enough, I no longer see the whines. While that does give a clear(er) indication of the nature of the problem, I suspect I'm setting myself up for "interesting modes of failure" when I need to refer to data that reside on a different NFS server (also accessed via the automounter). Peace, david -- David H. Wolfskill da...@catwhisker.org Those who would murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Interaction between make & autofs/automountd
Dating from back when I was building ports on each of the 3 machines on one of my networks using portmaster(8), I have had my ports tree implemented as an SVN working copy that resides on a ReadyNAS, which is thus accessed via NFS. The 3 machines are running "recent" FreEBSD stable/10 (amd64): the build machine is updated daily, and is thus updated to r293654; the other 2 machines are only updated weekly, so they are presently updated to r293620. A couple of the machines use autofs & automountd to make the ports tree available on demand. (In the case of the 3rd, I manually mount it when needed, but that's not at issue for this note, and I won't pursue that further here.) The machines that use autofs do so by using symlinks and the existing maps; e.g.: albert(10.2-S)[7] ls -lT /usr/ports lrwxr-xr-x 1 root wheel 20 Dec 21 04:15:39 2010 /usr/ports -> /net/howland/c/ports albert(10.2-S)[8] cat -n auto_master 1 # $FreeBSD: stable/10/etc/auto_master 283242 2015-05-21 13:42:37Z trasz $ 2 # 3 # Automounter master map, see auto_master(5) for details. 4 # 5 /net-hosts -nosuid,intr 6 # When using the -media special map, make sure to edit devd.conf(5) 7 # to move the call to "automount -c" out of the comments section. 8 #/media -media -nosuid 9 #/- -noauto albert(10.2-S)[9] The contents of /etc/autofs are "vanilla" -- I have not changed them. I did modify /etc/auto_master a bit, to remove the "nobrowse" option for -net. For most purposes, including: * svn update * cd to a port directory * Updating files in distfiles * reading arbitrary files in the tree this works well, and there's no indication of any problems or issues. I recently noticed, thiough, that running "portmaster -aF" generates a large number of messages. I was able to narrow this down to portmaster's invocation of (e.g.) * cd /usr/ports/sysutils/dmidecode * make -V PKGNAME The "cd" seems OK; it's the "make -V PKGNAME" -- even if I invoke it by: hand. It works, but at the expense of messages: albert(10.2-S)[4] dirs; date; make -V PKGNAME; date /usr/ports/sysutils/dmidecode Mon Jan 11 07:26:45 PST 2016 dmidecode-3.0 Mon Jan 11 07:26:47 PST 2016 albert(10.2-S)[5] Jan 11 15:26:45 albert automountd[13912]: "/etc/autofs/special_hosts share", pid 13913, terminated with exit status 1 Jan 11 15:26:45 albert automountd[13912]: failed to handle special map "-hosts" Jan 11 15:26:45 albert kernel: WARNING: autofs_trigger_one: request for /net/ completed with error 5 Jan 11 15:26:46 albert automountd[13915]: "/etc/autofs/special_hosts share", pid 13916, terminated with exit status 1 Jan 11 15:26:46 albert automountd[13915]: failed to handle special map "-hosts" Jan 11 15:26:46 albert kernel: WARNING: autofs_trigger_one: request for /net/ completed with error 5 Jan 11 15:26:47 albert automountd[13918]: "/etc/autofs/special_hosts share", pid 13919, terminated with exit status 1 Jan 11 15:26:47 albert automountd[13918]: failed to handle special map "-hosts" Jan 11 15:26:47 albert kernel: WARNING: autofs_trigger_one: request for /net/ completed with error 5 So I'm wondering why make(1) appears to be doing something that causes this -- while nothing else (that I've noticed so far) does. Peace, david -- David H. Wolfskill da...@catwhisker.org Those who would murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
AUTOFS (automount) and NFS server not playing together nicely
At the risk of being dubbed insane, here goes: On five FreeBSD 10.1-RELEASE-p9 production servers autofs(5) is enabled and working as advertised. On the same servers nfs v3 clients are also fat, dumb and happy. On a test server where autofs(5) is also enabled and working well, I am testing nfs v3 (later v4) server. Strange things are happening. When nfs mountd(8) is running, the autofs(5) auto-mount (via automountd) function seems to work, but the autofs(5) auto-unmount (via autounmountd) never occurs. Without nfs mountd(8), when the filesystem /disc is auto-mounted (via autoumountd), the mount(8) command shows status of (ufs, local, journaled soft-updates, auto-mounted) for the auto-mounted filesystem and after the autofs(5) timeout period (600 seconds) the filesystem is auto-unmounted (via autounmountd). No problem. With nfs mountd(8) the mount(8) command shows (ufs, local, journaled soft-updates). The auto-mounted filesystem is never (a long, long time) unmounted. Big problem. Without nfs mountd(8) running, the mount(8) command mount -o automounted /dev/ada0p8 /disc mounts the filesystem and the mount(8) command shows (ufs, local, journaled soft-updates, automounted) for the manually mounted filesystem and after the autofs(5) timeout period (600 seconds) the filesystem is auto-unmounted even though it was not mounted automatically. No problem. With nfs mountd(8), the mount(8) command mount -o automounted /dev/ada0p8 /disc mounts the filesystem but the mount(8) command shows (ufs, local, journaled soft-updates) and after the timeout period (600 seconds) the filesystem is remains mounted. Big problem. It appears that nfs mountd(8) is interferring with the mount(8) command's -o option processing but admittedly that is just a very weak SWAG. I have adequate hardware (real and virtual) to do any testing that may be suggested. Most days there is no time constraint either. The /etc/auto_master file is two lines: 1:/net -hosts -nobrowse,nosuid(original) 2:/-/etc/autofs/auto_disc The /etc/autofs/auto_disc file is one line: 1:/disc -fstype=ufs :/dev/ada0p8 Once again, everything works well when nfs mountd(8) is not present in the system. Thanks for any assistance that you may be able to supply. David Boyd. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
amd/autofs
Hi! What is a status of autofs (in the context of AMD) in FreeBSD these days? Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: autofs
Dmitriy Kirhlarov [EMAIL PROTECTED] writes: I'm find in source tree : /usr/src/lib/libautofs /usr/src/sbin/mount_autofs /usr/src/share/examples/autofs /usr/src/share/man/man5/autofs.5 Sorry, for stupid question. Could somebody explain me, how I can build it and why it doesn't build by default? I don't think it works. I was going to try to finish it at some point myself, but I lost the deployment environment I was using it for. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
autofs
Hi, list. I'm find in source tree : /usr/src/lib/libautofs /usr/src/sbin/mount_autofs /usr/src/share/examples/autofs /usr/src/share/man/man5/autofs.5 Sorry, for stupid question. Could somebody explain me, how I can build it and why it doesn't build by default? WBR. Dmitriy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
autofs
Hi, list. Why autofs was exclude from FreeBSD? By. Dmitriy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: autofs
Dmitriy Kirhlarov wrote on Fri 10.06.2005 14:34 Why autofs was exclude from FreeBSD? google says: http://lists.freebsd.org/pipermail/freebsd-fs/2004-September/000737.html http://freebsdaddicts.org/forum/viewtopic.php?pid=1042 --- 8 snip --- markm 2004-11-10 19:54:18 UTC FreeBSD src repository Modified files: sys/conf files sys/modules Makefile Removed files: sys/modules/autofs Makefile sys/fs/autofsautofs.h autofs_util.c autofs_vfsops.c autofs_vnops.c Log: Remove at request of author, perhaps to be re-added later. -- Regards, Holger Kipp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
