On 30/11/11 17:46, Adam Tauno Williams wrote:
On Wed, 2011-11-30 at 17:37 +0100, steve wrote:
On 30/11/11 16:40, Matthieu Patou wrote:
Matthieu,
On 30/11/2011 08:09, steve wrote:
Yep. I realise the 'alphaness' of Samba 4 but I think I am not alone
with my issue. I think I should be easy to fix now before it goes beta.
Certainly true, why not trying to start working on solution on your own,
by doing the first move you have much more insurance that someone else
will help you to make it good for master tree.
Well, I'm no developer and only have an old laptop running from a usb
memory stick for testing but I've made a start by adding a home
directory attribute to Samba 4 user database using phpldapadmin. But now
I'm stuck since I don't know where or how the roaming profiles are
stored. In Samba 3 there were stored in the /home of the user.
The statement "In Samba 3 there were stored in the /home of the user" is
false. They are stored where they are configured to be stored; we do
not store profiles in home directories [and generall i think that is a
bad idea]. Samba4 provisions a shared volume for storing a user's
roaming profile.
By default something like -
[profiles]
path = /usr/local/samba/var/profiles
read only = no
Which is very much the same as S3.
With AD
it seems that they are all be saved in a [profiles] share.
Yes, and the nothing changed there.
think I understand so I think the solution to single sign on with Samba
4 would be linking the roaming profile to a users /home folder.
No. The roaming profile is the roaming profile, the user's home
directory is the user's home directory. You can map a drive to their
home directory or use folder redirection via policy [just like in
Samba3].
the profiles share subfolder the /home folder for Linux. With Samba3 and
LDAP, all this was centralised and easy to administer.
I don't know about "easy". After many years it feels a bit more like
cleverly-hacked.
:)
would create an LDAP user for you and give him the Samba attributes he
needed. It even created his home folder too. It was simple for a linux
user to logon to windows and vica versa. Samba 4 takes away this
centralisation. It also has the inconvenience of having to use windows
to administer the Samba server.
This loss is temporary until the tool-chain catches up to Samba 4 -
which provides Python bindings, command line tools, and [of course] the
entire AD RPC approach.
I feel that Samba dev's have forgotten that Linux clients are just as
important as windows clients in the network. They seem to think that
Linux is only ever used as a server and clients are only ever windows 7!
Heh, I think the current situation sucks for servers to! :) But nobody
has forgotten anything - it is just not there yet. A simple issue of
resource constraints.
Another bit I don't get is where is a file that is created on a windows
client is stored on the Samba server? The documentation is not clear
here. As basic as that.
That works the same as in Samba 3.
Does any of this make sense?
The frustration, yes, and it is shared. Getting from S3 to AD has been
ugly going so far. But many of your presumptions are incorrect; you
are assuming that things configured by your tool-chain are fundamental
Samba behaviors.
OK I think I'm getting somewhere.
I have a Samba 3 user who authenticates against LDAP. He has a /home
folder and see his files either from a linux client or from a windows
client.
If I could get an answer to my next question, I'd be there:
Starting from nothing, how would I create a new user under Samba 4 who
could see his files on both windows and Linux clients? Under Samba 4 I
cannot find where his /home folder comes into the equation!
Thanks for your patience.
Steve.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
