On 06/30/09 00:50, Jim Klimov wrote:
Hello all,
I have a question on PSARC/2009/184 (SMB/CIFS Share Exec Properties)
[http://arc.opensolaris.org/caselog/PSARC/2009/184/]
This subject was interesting to me, especially after reading this page by Ed
Plese:
http://www.edplese.com/samba-with-zfs.html, who suggests snapshots on every
connection, per-connection clones for development environments, etc.
After reading the maillog of the case, I'm left puzzled with more questions than
I had initially. I'd quite appreciate a clarification from authors of the
feature,
to stay confident that I mixed it all up but the feature is stable and useful ;)
First of all, the maillog discussion did not commit to specifying *when* are the
map/unmap scripts called. Am I correct to assume that "map" will be called after
a successful identification and authentication of a user (it does have Windows
name and Unix uid as passable parameters, after all) - and will not be called if
the user is not successfully authernticated?
It's not related to authentication, although a user will never get
to the map/unmap scripts if the authentication fails.
From a client perspective, when mapping a single share, it may appear
that authentication and mapping a share is a single operation but at
the protocol level these are distinct and separate operations.
The map script is run while connecting a tree (mapping a share).
The unmap script is run while disconnecting a tree (unmapping a share).
If you map multiple shares on a client, you are only authenticated once,
prior to the first share being connected. All connections are then
made on that authenticated session. The map script will be run every
time you connect to a share and the unmap script will be run whenever
a share is disconnected. Note that Windows clients will automatically
disconnect and reconnect under the covers on a regular basis - be
careful what you do in your scripts.
Rather than respond to each point below, perhaps I can cover them by
saying that this is a powerful feature and "with great power comes
great responsibility." Use it with caution and test your scripts in
a safe environment before you unleash them on your users. I'd
recommend excessive testing of all scripts (not just the map/unmap
ones) before they are delivered for general use.
There are no spurious restrictions on what you can execute with the
map/unmap scripts. As an administrator, you already have the power to
shoot yourself in the foot, blow your legs off or demolish the network.
So there's nothing new here with the addition of map/unmap scripts.
Alan
One of the usecases suggests creation of Autohome directories upon mapping a
specific share. Could someone please elaborate on that phrase?
- what is the share to be mapped this way (a generic /export/home lookalike?)
- are the individual user homes directories or dedicated personal ZFS datasets
(possibly created on the fly upon the first connection)?
- is it intended that individual home dirs become SMB shares in their own right
(\\server\username) or directories in one common share (\\server\homes\user)?
Also, is this mechanism intended for use only with sharectl (as in examples), or
with "zfs set sharesmb=..." as well? If yes, is it possible to make it
un-inheritable
by sub-datasets created some (any) time later (I guess it's more of a zfs
question,
but I suddenly found myself in the vague about this - perhaps I should've slept
more)?
While reading the usecase I'm having a brainlock along these lines: *if* the
users'
homes are dedicated ZFS datasets (perhaps under a common "export/home" zfs
dataset), and *if* such datasets can have the "map" property set or inherited to
allow for auto-creation of homes and sharing them, then:
1) How do we call the pre-inexistent user's home dir share in the first place?
That is, before the home dir is created and shared, there is no share name and
no zfs dataset with a sharesmb property, to which we can add this "map"
attribute.
2) How do we protect from any typo becoming a new sub-dataset of something?
(Theoretical bug. It's biting me, but I don't know even how to formulate it
well)
Say, the map attribute points to a script which creates homedir ZFS datasets
according to a pathname. Then, this map attribute is inherited by each of these
homedir datasets, and they in turn become shares with an active exec-map.
And then access to any filename potentially triggers this mapping - and so on
recursively.
Would this be a problem of a script's author/sysadmin (for writing and using such
a poor script), or is there some general solution built into the implementation?
HTMAS,
//Jim
_______________________________________________
cifs-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
