On Thu, 2015-02-05 at 21:27 +0800, Ian Kent wrote:
> On Thu, 2015-02-05 at 02:14 -0500, Dmitri Pal wrote:
> > On 02/04/2015 09:57 PM, Brendan Kearney wrote:
> > > On Wed, 2015-02-04 at 10:31 -0500, brendan kearney wrote:
> > >> A lot to chew on here. Seems I may need to rethink my approach for
> > >> different scenarios. Will do so and reply in a bit.
> > >>
> > >> As for docs, anything is better than nothing. If there is something
> > >> existing, that will suffice if you can provide links, etc.
> > >>
> > >> Thanks
> > >>
> > >> Brendan
> > >>
> > >> On Feb 4, 2015 3:42 AM, "Ian Kent" <ikent(a)redhat.com>
wrote:
> > >> On Wed, 2015-02-04 at 14:06 +0800, Ian Kent wrote:
> > >> > On Tue, 2015-02-03 at 15:47 +0100, Jakub Hrozek wrote:
> > >> > > On Tue, Feb 03, 2015 at 09:21:10AM -0500, Brendan
Kearney
> > >> wrote:
> > >> > > > On Mon, 2015-02-02 at 14:08 +0100, Jakub
Hrozek wrote:
> > >> > > > > On Mon, Feb 02, 2015 at 06:50:12AM -0500,
Dmitri Pal
> > >> wrote:
> > >> > > > > > On 02/02/2015 01:52 AM, Jakub Hrozek
wrote:
> > >> > > > > > >On Sun, Feb 01, 2015 at
11:17:02AM -0500, Brendan
> > >> Kearney wrote:
> > >> > > > > > >>On Sat, 2015-01-31 at 19:01
-0500, Dmitri Pal
> > >> wrote:
> > >> > > > > > >>>On 01/31/2015 12:23 PM,
Brendan Kearney wrote:
> > >> > > > > > >>>>i want to have an
automount configured so that
> > >> > > > > >
>>>>nas.bpk2.com:/export/music is mounted
> > >> on /home/<username>/Music. i want
> > >> > > > > > >>>>to use the HOME
variable, but several attempts
> > >> have not gotten the job
> > >> > > > > > >>>>done. i have tried
$HOME/Music, ${HOME}/Music,
> > >> and {$HOME}/Music, and
> > >> > > > > > >>>>none have worked.
> > >> > > > > > >>>>
> > >> > > > > > >>>>what is the correct
way to use a variable with
> > >> AutoFS and SSSD? i have
> > >> > > > > > >>>>used the hard values
to get things working for
> > >> my id, but want to have
> > >> > > > > > >>>>this work for all
users.
> > >> > > > > > >>>>
> > >> > > > > > >>>>dn:
> > >> > > > > >
> > >>
>>>>automountKey=/home/brendan/Music,automountMapName=auto.shares,cn=autofs,ou=Daemons,dc=bpk2,dc=com
> > >> > > > > >
>>>>automountinformation: nas.bpk2.com:/export/music
> > >> > > > > > >>>>automountkey:
/home/brendan/Music
> > >> > > > > > >>>>description: music
> > >> > > > > > >>>>objectclass:
automount
> > >> > > > > > >>>>objectclass: top
> > >> >
> > >> > This is a direct mount map entry.
> > >> > You can't use the wildcard key in a direct mount
key.
> > >> >
> > >> > Oddly enough I suspect you could use the &
substitution in
> > >> the mount
> > >> > location but that's generally not useful because it
would
> > >> replace the
> > >> > whole path (the entire key) at it's occurrence in
the mount
> > >> location.
> > >> >
> > >> > You can't use macros in lookup keys with them (or
indirect
> > >> mounts)
> > >> > either because the path is used as the lookup key.
> > >> >
> > >> > I know you think that using the information about the
> > >> requesting could
> > >> > be used but it's not as simple as that.
> > >> >
> > >> > The problem is that multiple processes could request a
mount
> > >> at the same
> > >> > time, resulting in a queue waiting for mount completion,
and
> > >> the user
> > >> > information that is returned will be that of the
process
> > >> that originally
> > >> > triggered the mount and so might not be what you'd
expect.
> > >> There's no
> > >> > straight forward way to fix that.
> > >>
> > >> And, now that I think about it, there's another reason
macros
> > >> aren't
> > >> used in direct mount keys.
> > >>
> > >> At startup the keys in direct mount maps are used to create
> > >> trigger
> > >> mounts for later automounting. That's the only way
direct
> > >> mounts can be
> > >> done so there's no way to do macro substitution, even if
we
> > >> wanted to,
> > >> of macros that don't have an already known value.
> > >>
> > >> Ian
> > >>
> > >> _______________________________________________
> > >> sssd-users mailing list
> > >> sssd-users(a)lists.fedorahosted.org
> > >>
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
> > > i just did some reading through man pages and i find no limitations or
> > > constraints around the use of variables in direct mappings. can you
> > > provide the documentation source you are working from? i want to read
> > > through it and better understand the logic about what can and cant be
> > > done when using direct vs indirect mappings.
>
> Linux autofs has never allowed the use of macros in map keys, accept it,
> that's the way it is.
>
> I must admit that I never investigated using macros in the Solaris
> automounter because I never needed them but I doubt you would be able to
> use them with it either. If you can then I'd reconsider my position on
> maybe trying to add it to autofs.
>
> The man pages might need to be updated to make it clear that using
> macros in Sun format map keys isn't supported and is only possible in
> the mount location field of map entries.
>
> Clearly direct mounts can't possibly support macros based on what I said
> before. I wrote the user space direct mount implementation and did the
> kernel space development for it as well, so believe me when I say this
> is the way it is. Note well I spent a lot of time deciding how to
> implement direct mounts and finally realized the only sensible way to do
> it is the way I've done it. That's probably why the Solaris automounter
> does it in a similar way too.
>
> It may be possible to implement it for indirect map keys but the problem
> of possible queued mount requests I described earlier makes it a
> potential support problem so it's not going to change. Special case code
> to exclude keys that include macros when the browse option is given
> would be difficult as well.
>
> The reference I use is the autofs source git repository at:
>
git://git.kernel.org/pub/scm/linux/storage/autofs/autofs
>
> The bottom line is if it is supported by the Solaris automounter I'll
> consider thinking about how it might be done, otherwise it isn't going
> to happen.
>
> Not only that I think what you require is possible with the current
> autofs implementation but you'll need to change your map configuration
> quite a bit
>
> Ian
>
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
you seem a bit agitated or defensive about me asking for documentation,
and only point me to git for a code checkout or whatever. you have not
provided me with any documentation. and i dont read code. i'm not a
developer, dont expect it of me.
you tell me to accept that what i am looking for is not available, as if
i made demands that i must get what i want. i never said i would not
accept things as they are. in fact, i want documentation around the use
of direct vs indirect mappings so i can better implement things in my
environment, using what functionality is available.
again, can i get some documentation?
This is quite old but does cover many of the concepts of the usage of
Sun-format automount maps. Because it is old the central map storage and
management possibilities aren't discussed in it, other than NIS. I'm not
aware of documentation on deployment methods.
If you are at a site that uses amd-format maps, and they can't change
their maps to Sun-format, and am-utils isn't available in the
distribution in use or the version is too old then this describes
amd-format maps.
I've implemented quite a lot of the functionality described in this in
autofs. If you need something that hasn't been implemented then you will
need to ask if it can be added on the autofs mailing list.
Ian