On Tue, Jan 11, 2000 at 11:31:16AM +0100, Coetmeur, Alain wrote:
> > Anyway. My problem being that the smbmount script supplied in the
> > latest Samba didn't work with the existing mount_smbfs,
> I've a working one for 2.0.5, but you seem to use
> the latest samba smbmount that support directly mountoptions
> (they say you can just ln -s /bin/smbmount /sbin/mount.smb)
Apparently, yes, although I haven't tried it... oh yes, it does work.
> > echo "shaslam@server xyzzy" > ~/.auto-samba.passwd
>
> in older mount.smb script there was the uuname=unixname that
> was asking to read a ~unixname/.smb-pass to find the password.
> as you say, it is a must!
> the only better way would be an unreadable shadow map with a password
> changing
> command like "/bin/passwd"... quite complex.
Or a daemon listening at /tmp/smbpasswd-agent which you can feed
passwords into and it hands them off to autofs as required. But this
doesn't protect you against Eevil R00Ters(tm) any more than a file,
although it is more transient.
> another needed functionality is to support host
> or share wildcards (at least the any "*" wildcard),
> and prioriy rules.
OK, yes
> telling that my password
> is by default "DOM/gandalf" except on "bigiron" server
> where it is "local/lord", and except on any //*/demo share
> where the user is DOM2/guest with "dummy" password...
Hmm, changing usernames so easily isn't something I've allowed
for... or, really, allowing slashes in usernames...
> > * -fstype=autofs,-Duser=& file:/etc/auto.sambasub
>
> by the way, the -Dvariable=value seems to work for you, which autofs
> version do you use ... I did'nt get to make them work.
3.1.3
> my opinion is that mount.smb should support a kind of password
> fetching that avoid divulgating it in the command line... anyway
> one could make a script that fetch the password (like the one
> proposed in samba samples), and this would be more flexible until a
> widespread way can be hardwired in smbmount.
Yep.
> another idea, is that program maps may be sufficient to implement
> this, without adding a new map type for each file system... do you
> see reasons that make program maps unuseable for such work?
> performance may be an issue ?
I've never used the program maps- tbh, I didn't even think of
implementing all this using one. I might give it a try.
SRH
--
Steve Haslam, Production Engineer, Excite UK [EMAIL PROTECTED]
i sit and stare at the gun pointed at my head
and think about all the possibilities
