Samba4 with Linux and Windows clients wanting to get the same home folder data. Hi A college has students arranged with Linux home directories according to which year they belong to and which class within that year, a or b or whatever, they belong to e.g.: /home2/students/year7/year7a/student1 /home2/students/year7/year7a/student2 ... ... /home2/students/year13/year13a/student2500 To get at the same data on windows, I was thinking of a share for each of the classes e.g. [year7a] path = /home2/students/year7/year7a read only = No browsable = No ... ... [year13a] path = /home2/students/year13/year13a read only = No browsable = No and mapping a drive letter to the share e.g. map Z: to \\server\year7a\%USERNAME% That would make lots of shares but would make it readable to non admins. Is there a limit on the number of shares per installation? Any other ideas of how to go about it? e.g. I thought about OU's but we do not want to administer from Windows. Cheers, Steve
On Mon, 2012-07-02 at 17:39 +0200, steve wrote:> Samba4 with Linux and Windows clients wanting to get the same home > folder data. > > Hi > A college has students arranged with Linux home directories according to > which year they belong to and which class within that year, a or b or > whatever, they belong to e.g.: > /home2/students/year7/year7a/student1 > /home2/students/year7/year7a/student2 > ... > ... > /home2/students/year13/year13a/student2500 > > To get at the same data on windows, I was thinking of a share for each > of the classes e.g. > [year7a] > path = /home2/students/year7/year7a > read only = No > browsable = No > ... > ... > [year13a] > path = /home2/students/year13/year13a > read only = No > browsable = No > > and mapping a drive letter to the share e.g. > map Z: to \\server\year7a\%USERNAME% >Deal with it through your NSS mechanism so that the file server knows for \\server\%USERNAME% where the users home directory is actually located and then you can just use the special [homes] share. I do this with winbind and the unixHomeDirectory attribute in AD. JAB. -- Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk Fife, United Kingdom.
On 02/07/12 17:49, Jonathan Buzzard wrote:> > On Mon, 2012-07-02 at 17:39 +0200, steve wrote: >> Samba4 with Linux and Windows clients wanting to get the same home >> folder data. >> >> Hi >> A college has students arranged with Linux home directories according to >> which year they belong to and which class within that year, a or b or >> whatever, they belong to e.g.: >> /home2/students/year7/year7a/student1 >> /home2/students/year7/year7a/student2 >> ... >> ... >> /home2/students/year13/year13a/student2500 >> >> To get at the same data on windows, I was thinking of a share for each >> of the classes e.g. >> [year7a] >> path = /home2/students/year7/year7a >> read only = No >> browsable = No >> ... >> ... >> [year13a] >> path = /home2/students/year13/year13a >> read only = No >> browsable = No >> >> and mapping a drive letter to the share e.g. >> map Z: to \\server\year7a\%USERNAME% >> > > Deal with it through your NSS mechanism so that the file server knows > for \\server\%USERNAME% where the users home directory is actually > located and then you can just use the special [homes] share. > > I do this with winbind and the unixHomeDirectory attribute in AD. > > JAB. >Hi Jonathan Thanks for the quick response. I think I must be missing something here because as far as I can see, winbindd puts all users into the directory specified in template homedir. [homes] then picks out the user from there. At the moment we are using nss-pam-ldapd to grab the unixHomeDirectory from AD. How do I get winbindd or nss to map unixHomeDirectory to something I can then map to a windows drive letter? Cheers, Steve
On 02/07/12 17:20, steve wrote:> On 02/07/12 17:49, Jonathan Buzzard wrote: >> >> On Mon, 2012-07-02 at 17:39 +0200, steve wrote: >>> Samba4 with Linux and Windows clients wanting to get the same home >>> folder data. >>> >>> Hi >>> A college has students arranged with Linux home directories according to >>> which year they belong to and which class within that year, a or b or >>> whatever, they belong to e.g.: >>> /home2/students/year7/year7a/student1 >>> /home2/students/year7/year7a/student2 >>> ... >>> ... >>> /home2/students/year13/year13a/student2500 >>> >>> To get at the same data on windows, I was thinking of a share for each >>> of the classes e.g. >>> [year7a] >>> path = /home2/students/year7/year7a >>> read only = No >>> browsable = No >>> ... >>> ... >>> [year13a] >>> path = /home2/students/year13/year13a >>> read only = No >>> browsable = No >>> >>> and mapping a drive letter to the share e.g. >>> map Z: to \\server\year7a\%USERNAME% >>> >> >> Deal with it through your NSS mechanism so that the file server knows >> for \\server\%USERNAME% where the users home directory is actually >> located and then you can just use the special [homes] share. >> >> I do this with winbind and the unixHomeDirectory attribute in AD. >> >> JAB. >> > Hi Jonathan > Thanks for the quick response. > > I think I must be missing something here because as far as I can see, > winbindd puts all users into the directory specified in template > homedir. [homes] then picks out the user from there. > > At the moment we are using nss-pam-ldapd to grab the unixHomeDirectory > from AD. How do I get winbindd or nss to map unixHomeDirectory to > something I can then map to a windows drive letter? > > Cheers, > SteveHi Steve, Have you considered using autofs to do all of the mapping work for you, so that you have only one /homes/ (or whatever else you want to call it) to worry about? L
On 07/02/2012 08:39 AM, steve wrote:> Samba4 with Linux and Windows clients wanting to get the same home > folder data. > > Hi > A college has students arranged with Linux home directories according > to which year they belong to and which class within that year, a or b > or whatever, they belong to e.g.: > /home2/students/year7/year7a/student1 > /home2/students/year7/year7a/student2 > ... > ... > /home2/students/year13/year13a/student2500 > > To get at the same data on windows, I was thinking of a share for each > of the classes e.g. > [year7a] > path = /home2/students/year7/year7a > read only = No > browsable = No > ... > ... > [year13a] > path = /home2/students/year13/year13a > read only = No > browsable = No > > and mapping a drive letter to the share e.g. > map Z: to \\server\year7a\%USERNAME% > > That would make lots of shares but would make it readable to non admins. > > Is there a limit on the number of shares per installation? > Any other ideas of how to go about it? e.g. I thought about OU's but > we do not want to administer from Windows.Did you thought about making a new directory ie. /home2/students/data with a link to each real user and then sharing data like that [data] path = /home2/students/data read only = No browsable = No And then use ADUC or ldbedit to specify the connect to attribute and set it to \\servername\data\%username% This fields accept a couple of placeholder I let you discover the others (search engines are your friend). Matthieu.> Cheers, > Steve >-- Matthieu Patou Samba Team http://samba.org
---------- Forwarded message ---------- From: Nico Kadel-Garcia <nkadel at gmail.com> Date: Wed, Jul 4, 2012 at 12:12 PM Subject: Re: [Samba] smb.conf for around 2500 users To: steve <steve at steve-ss.com> On Wed, Jul 4, 2012 at 11:11 AM, steve <steve at steve-ss.com> wrote:> On 03/07/12 10:18, Jonathan Buzzard wrote: >> >> >> On Mon, 2012-07-02 at 18:20 +0200, steve wrote: >> >> [SNIP] >> >>> >>> I think I must be missing something here because as far as I can see, >>> winbindd puts all users into the directory specified in template >>> homedir. [homes] then picks out the user from there. >>> >> >> Yes you are stop using template homedir and configure winbind correctly. > > > OK. template homedir is now removed. Although we are using winbind we are > not running winbindd. All our mapping is done using nss-pam-ldapd. > >> >> >> # deal with NSS and the whole UID/SID id mapping stuff >> idmap backend = tdb >> idmap uid = 2000000 - 2999999 >> idmap gid = 2000000 - 2999999 >> idmap config MYDOMAIN : backend = nss >> idmap config MYDOMAIN : readonly = yes >> idmap config MYDOMAIN : range = 500 - 1999999 >> idmap cache time = 604800 >> idmap negative cache time = 20 >> winbind cache time = 600 >> winbind nss info = rfc2307 >> winbind expand groups = 2 >> winbind nested groups = yes >> winbind use default domain = yes >> winbind enum users = yes >> winbind enum groups = yes >> winbind refresh tickets = yes >> winbind offline logon = false >> > No, we have none of that. Our global is simply: > [global] > server role = domain controller > workgroup = MARINA > realm = hh3.site > netbios name = HH1 > passdb backend = samba4 > wide links = Yes > unix extensions = No > > > >> You need to edit /etc/nsswitch of course. This is the "samba" way of >> doing things. > > > We have > passwd: compat ldap > group: compat ldap > hosts: files mdns4_minimal [NOTFOUND=return] dns > >> >> >> As to suggestions to use autofs on 2500 users, my advice is don't. Works >> well at ~50 users but gets flacky at couple hundred users with random >> things not working 100% of the time that will take you for ever to track >> down to autofs if you do. >> > That's interesting/worrying. Although we have 2500 users, we only have > around 150 computers in the domain, spread over 4 teaching labs. Those are > split about 50:50 Linux:windows so I'd put the maximum number of NFS autofs > mounts to be 80 at most. What do you recon?NFS and autofs buys you some very, very useful things. One is that it can support multiple upstream NFS servers, which might help distribute the load for 2500 users. Another is that by automounting a set of subdirectories, instead of one large master share, you can tune the settings of those mounted directories for security. Another is that you can mix NFSv3 and NFSv4 for environments that need TCP based access or Kerberized authentication for fileshares. Another is that unused material is not mounted and can be deleted or re-arranged on the fileserver, which is priceless when managing 2500 accounts with 2500 home directories. But with 2500 users, and hundreds at a time connected, it's maybe time to think about running the CIFS fileshares directly on the NFS *servers* and get the Samba clients out of the way Why introduce a layer of complexity with a Samba client on top of NFS if the fileserver can do it directly? And if it's too much for one fileserver, maybe it's time to think about splitting up fileservices anyway.> Cheers and thanks for your comments, > Steve > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba
On 04/07/12 18:12, Nico Kadel-Garcia wrote:> On Wed, Jul 4, 2012 at 11:11 AM, steve <steve at steve-ss.com> wrote: >> On 03/07/12 10:18, Jonathan Buzzard wrote: >>> >>> On Mon, 2012-07-02 at 18:20 +0200, steve wrote: >>> >> > NFS and autofs buys you some very, very useful things. One is that it > can support multiple upstream NFS servers, which might help distribute > the load for 2500 users. Another is that by automounting a set of > subdirectories, instead of one large master share, you can tune the > settings of those mounted directories for security. Another is that > you can mix NFSv3 and NFSv4 for environments that need TCP based > access or Kerberized authentication for fileshares. Another is that > unused material is not mounted and can be deleted or re-arranged on > the fileserver, which is priceless when managing 2500 accounts with > 2500 home directories. > > But with 2500 users, and hundreds at a time connected, it's maybe time > to think about running the CIFS fileshares directly on the NFS > *servers* and get the Samba clients out of the way Why introduce a > layer of complexity with a Samba client on top of NFS if the > fileserver can do it directly? And if it's too much for one > fileserver, maybe it's time to think about splitting up fileservices > anyway. > >Hi Nico Yeah, we have to stick with the automounter. Having 2500 home directories held up for only 80 (max) users can't be a good idea. Without a cluster, I can't see how we could deploy multiple NFS servers though. We have 2 replicating DC's one of which is the fileserver. How nice it would be if we could replicate the data over to DC2 and replicate the fileserver and it failedover if necessary. Cheers, Steve
On Wed, Jul 4, 2012 at 1:53 PM, steve <steve at steve-ss.com> wrote:> On 04/07/12 18:12, Nico Kadel-Garcia wrote: >> >> On Wed, Jul 4, 2012 at 11:11 AM, steve <steve at steve-ss.com> wrote: >>> >>> On 03/07/12 10:18, Jonathan Buzzard wrote: >>>> >>>> >>>> On Mon, 2012-07-02 at 18:20 +0200, steve wrote: >>>> >>> >> NFS and autofs buys you some very, very useful things. One is that it >> can support multiple upstream NFS servers, which might help distribute >> the load for 2500 users. Another is that by automounting a set of >> subdirectories, instead of one large master share, you can tune the >> settings of those mounted directories for security. Another is that >> you can mix NFSv3 and NFSv4 for environments that need TCP based >> access or Kerberized authentication for fileshares. Another is that >> unused material is not mounted and can be deleted or re-arranged on >> the fileserver, which is priceless when managing 2500 accounts with >> 2500 home directories. >> >> But with 2500 users, and hundreds at a time connected, it's maybe time >> to think about running the CIFS fileshares directly on the NFS >> *servers* and get the Samba clients out of the way Why introduce a >> layer of complexity with a Samba client on top of NFS if the >> fileserver can do it directly? And if it's too much for one >> fileserver, maybe it's time to think about splitting up fileservices >> anyway. >> >> > Hi Nico > Yeah, we have to stick with the automounter. Having 2500 home directories > held up for only 80 (max) users can't be a good idea. Without a cluster, I > can't see how we could deploy multiple NFS servers though. > L x >Autofs supports a list of NFS servers to be checked, in order, for NFS shares. I've found it very useful in migration situations. We could spend a lot of time going over approaches for that. I've also found it really useful to make "/homedir/{usernames}" a pool of symlinks to an NFS automount layout. That way, I can switch users from one NFS automoun to another by updating the symlinks in a deployed network. Very handy for switching and re-arranging upstream NFS or attached storage in a planned fashion. It ain't perfect, but lord, it's useful.
Maybe Matching Threads
- multi home dir locations
- different logon path for different users - local profiles for a few users only - how?
- Is there a function to interdigitate two columns?
- Security: ads - "net ads user" works, "wbinfo -u" does not
- Samba4: mounting cifs on Linux client no longer preserves acl's