Hi all, Would it be really complex to add some code to have more database files? The database I have to fill is too large to be hosted into $samba_db/private/DC=DOMAIN,DC=EXAMPLE,DC=COM which is limited to 4GB. The idea would be to create files to host OUs created a domain's root level. For example an OU to host groups: OU=Groups,DC=DOMAIN,DC=EXAMPLE,DC=COM would be hosted in file named: $samba_db/private/OU=Groups,DC=DOMAIN,DC=EXAMPLE,DC=COM As there is already something to have separated DB files (CN=CONFIGURATION, DC=DOMAINDNSZONES...) perhaps this change would not be to complex... Having that we would be able to create files to host users in their own file, computers in some other (if displaced from builtin "computers" OU) and so on. Best regards, mathias
Here is the answer from Andrew Bartlett sent to samba-technical (which I don't read enough, so I missed the reply) Sent by Andrew Bartlett June the 10th at 00:49 Title was "Samba and LDB at 150k+ (was: Re: [Samba] 32 bits limit?)" .... No, it isn't possible to split it up that way, because then we would need complex logic to allow move operations between LDB files, as well as logic to allow a subtree search correctly. The split of one ldb file per partition works very well for a number of operations, because it matches the LDAP semantics we need. On the other hand, changing the key-value store under the database, but keeping the layer above the key-value store largely the same seems like a massive change, but both layers are themselves quite mature, they just have not been used together before. What I'm getting at is that with the right testing, I think this (or perhaps an alternative using ntdb) is the less risky approach, and the one the follows the direction the Samba Team would like to go in. The point of database It would also be the appropriate way to introduce other efficiencies in the database format (such as a dual normalised/original data store, improved indexes or SD caching). .... 2015-06-11 11:03 GMT+02:00 mathias dufresne <infractory at gmail.com>:> Hi all, > > Would it be really complex to add some code to have more database files? > > The database I have to fill is too large to be hosted into > $samba_db/private/DC=DOMAIN,DC=EXAMPLE,DC=COM which is limited to 4GB. > > The idea would be to create files to host OUs created a domain's root > level. > For example an OU to host groups: OU=Groups,DC=DOMAIN,DC=EXAMPLE,DC=COM > would be hosted in file named: > $samba_db/private/OU=Groups,DC=DOMAIN,DC=EXAMPLE,DC=COM > > As there is already something to have separated DB files > (CN=CONFIGURATION, DC=DOMAINDNSZONES...) perhaps this change would not be > to complex... > > Having that we would be able to create files to host users in their own > file, computers in some other (if displaced from builtin "computers" OU) > and so on. > > Best regards, > > mathias >
On Thu, Jun 11, 2015 at 11:03:08AM +0200, mathias dufresne wrote:> Hi all, > > Would it be really complex to add some code to have more database files?Would trusts help you? Individual domains could become smaller. Volker -- SerNet GmbH, Bahnhofsallee 1b, 37081 G?ttingen phone: +49-551-370000-0, fax: +49-551-370000-9 AG G?ttingen, HRB 2816, GF: Dr. Johannes Loxen http://www.sernet.de, mailto:kontakt at sernet.de
Hi Volker, First I apologize for very late reply. I did tests in the meantime... Trust relationships are the option we keep in mind. As trusts are for now bidirectional-full-trust they give us possibility to increase domain size. If we have to split our domain we will split in one domain for users and another for computers (meaning users' MS Windows computers as they need to be included into AD, which is not the case for UNIX/Linux boxes, and because MS Windows clients are almost as numerous as users). The others choices are to have users + computers in same domain, with several domains. This implies we reproduce management processes on each domain. Having one domain for users and another for computers we won't have to reproduce processes. Of course processes to manage computers and users should be quiet similar so somewhere we will have to reproduce these processes, but it seems to me (I can be wrong ;) that would generate less work during run... Another good point is once we don't need any more trust relationships we could move users from their domain to computers' domain almost automagically. Having computers spread on several domain means to remove these computers from their domain then integrate them in the one chosen as main domain when we'll aggregate them to remove trust relationship(s). In parallel Oliver Liebel tells around 2 months ago he'll be able to find funds to develop LMDB backend (in some mail with title "s4 ldb tdb limits") which could solve the DB size limitation. And the company I'm working for is still discussing internally (without me :p) about investing for same development (and others). That's where are my thoughts regarding scaling this domain... Critics are welcome :) Cheers, mathias 2015-06-11 13:22 GMT+02:00 Volker Lendecke <Volker.Lendecke at sernet.de>:> On Thu, Jun 11, 2015 at 11:03:08AM +0200, mathias dufresne wrote: > > Hi all, > > > > Would it be really complex to add some code to have more database files? > > Would trusts help you? Individual domains could become > smaller. > > Volker > > -- > SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen > phone: +49-551-370000-0, fax: +49-551-370000-9 > AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen > http://www.sernet.de, mailto:kontakt at sernet.de >