Quantcast

Upgrade from S3 to a Samba4 DC

classic Classic list List threaded Threaded
89 messages Options
12345
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrade from S3 to a Samba4 DC [with LDAPSAM] [NOTE!]

Adam Tauno Williams
Quoting Adam Tauno Williams <[hidden email]>:

> Quoting Adam Tauno Williams <[hidden email]>:
>> On Fri, 2011-09-09 at 14:27 +0200, Tarjei Huse wrote:
>>> On 09/08/2011 11:11 PM, Andrew Bartlett wrote:
>>>> On Thu, 2011-09-08 at 16:56 -0400, Adam Tauno Williams wrote:
>>>>> Gotcha.  And it goes much further.  Are users with the same name as
>>>>> groups an issue?  There is only one uid=bie object in the LDAPSAM.
>>>> Users with the same name as groups have always been prohibited in
>>>> Windows, even with NT4.  I'm not sure there is anything we can do except
>>>> fail here, but I'm open to suggestions.
>>> Document it?
>> It is reasonably well documented [I knew about it].  That is just an
>> NT/Windows thing.  Anyone managing Windows should already know about
>> that [from the Microsoft documentation], IMO.  The only really issue
>> regarding that is that S3 LDAPSAM was pretty fast-and-loose with
>> enforcing rules.   Does S3 LDAPSAM even use the "cn" attribute as the
>> group name?  It appears to use the "description" attribute in most
>> places [at least that is what appears on the screen when looking at a
>> security descriptor].
> Indeed it does use "description" as the name of at least the group  
> and that value is case-insensitive [again, obvious in hind-sight].

Nope, my bad.  The attribute that need to be case-insensitive unique  
is "displayName".

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrade from S3 to a Samba4 DC [with LDAPSAM] [SUCCESS!]

Adam Tauno Williams
In reply to this post by Adam Tauno Williams
Quoting Adam Tauno Williams <[hidden email]>:

> Quoting Adam Tauno Williams <[hidden email]>:
>
>> Quoting Adam Tauno Williams <[hidden email]>:
>>> Quoting tataia <[hidden email]>:
>>>> It happens for groups that have sambaGroupType =5
>>>> replace 5 with 4
>>> Gotcha.  And it goes much further.  Are users with the same name  
>>> as groups an issue?  There is only one uid=bie object in the  
>>> LDAPSAM.
>> Hrm... so I manually exclude user "bie" and import users completes.
>> But then the script fails while adding users to group.  I've  
>> verified that sambaSID=S-1-5-21-2037442776-3290224752-88127236-9272  
>> [a user] and sambaSID=S-1-5-21-2037442776-3290224752-88127236-1201  
>> [a group] both exist (and both exist only once).
>
> Setting the "debug level" in the S3 smb.conf file seems to work  
> [which is handy].
>
> ???? Is there a way or level to specifically log what LDB is trying  
> to do / look for / add ???
>
> Both S-1-5-21-2037442776-3290224752-88127236-9272 and  
> S-1-5-21-2037442776-3290224752-88127236-1201 exist in the S3 LDAPSAM.
>
> At a debug level of 256 this output looks like -
>
> [root@localhost samba-master]# ./source4/setup/upgrade_from_s3  
> smb.conf /tmp/x --libdir=/root/s3
> Reading smb.conf
> INFO: Current debug levels:
>   all: 256
>   tdb: 256
>   printdrivers: 256
>   lanman: 256
>   smb: 256
>   rpc_parse: 256
>   rpc_srv: 256
>   rpc_cli: 256
>   passdb: 256
>   sam: 256
>   auth: 256
>   winbind: 256
>   vfs: 256
>   idmap: 256
>   quota: 256
>   acls: 256
>   locking: 256
>   msdfs: 256
>   dmapi: 256
>   registry: 256
> doing parameter domain master = yes
> doing parameter preferred master = yes
> doing parameter domain logons = yes
> doing parameter logon script = %G.bat
> doing parameter logon path = \\BARBEL\PROFILES\%U
> doing parameter logon drive = f:
> doing parameter logon home = \\ARABIS-RED\HOMEDIR
> doing parameter wins support = yes
> doing parameter name resolve order = wins host
> doing parameter dns proxy = yes
> doing parameter map to guest = Bad User
> doing parameter passdb backend = ldapsam:ldap://192.168.1.9/
> doing parameter ldap ssl = no
> doing parameter ldap admin dn =  
> uid=CIFSDC,ou=System,ou=Entities,ou=SAM,o=Morrison Industries,c=US
> doing parameter ldap suffix = o=Morrison Industries,c=US
> doing parameter ldap group suffix = ou=Groups,ou=SAM
> doing parameter ldapsam:trusted = yes
> doing parameter idmap backend = ldap:ldap://localhost
> WARNING: The "idmap backend" option is deprecated
> doing parameter ldap idmap suffix = ou=idMap,ou=CIFS,ou=SubSystems
> doing parameter idmap uid = 40000-50000
> WARNING: The "idmap uid" option is deprecated
> doing parameter idmap gid = 40000-50000
> WARNING: The "idmap gid" option is deprecated
> doing parameter winbind use default domain = yes
> doing parameter username map = /etc/samba/username.map
> doing parameter deadtime = 15
> doing parameter log level = 0 winbind:2
> Provisioning
> /root/s3/secrets.tdb
> no talloc stackframe around, leaking memory
> Exporting account policy
> Exporting groups
> Exporting users
>   Skipping wellknown rid=998 (for username=pc01845$)
>   Skipping wellknown rid=500 (for username=root)
> Next rid = 9973
> Looking up IPv4 addresses
> Looking up IPv6 addresses
> No IPv6 address will be assigned
> Setting up share.ldb
> Setting up secrets.ldb
> Setting up the registry
> Setting up the privileges database
> Setting up idmap db
> Setting up SAM db
> Setting up sam.ldb partitions and settings
> Setting up sam.ldb rootDSE
> Pre-loading the Samba 4 and AD schema
> Adding DomainDN: DC=micore,DC=us
> Adding configuration container
> Setting up sam.ldb schema
> Reopening sam.ldb with new schema
> Setting up sam.ldb configuration data
> Setting up display specifiers
> Adding users container
> Modifying users container
> Adding computers container
> Modifying computers container
> Setting up sam.ldb data
> Setting up sam.ldb users and groups
> Setting up self join
> Setting up sam.ldb rootDSE marking as synchronized
> Assuming bind9 DNS server backend
> Adding DNS accounts
> Populating CN=System,DC=micore,DC=us
> See /tmp/x/private/named.conf for an example configuration include  
> file for BIND
> and /tmp/x/private/named.txt for further documentation required for  
> secure DNS updates
> A Kerberos configuration suitable for Samba 4 has been generated at  
> /tmp/x/private/krb5.conf
> Fixing provision GUIDs
> Please install the phpLDAPadmin configuration located at  
> /tmp/x/private/phpldapadmin-config.php into  
> /etc/phpldapadmin/config.php
> Once the above files are installed, your Samba4 server will be ready to use
> Server Role:           domain controller
> Hostname:              BARBEL
> NetBIOS Domain:        BACKBONE
> DNS Domain:            micore.us
> DOMAIN SID:            S-1-5-21-2037442776-3290224752-88127236
> Admin password:        ************************
> Importing WINS database
> Importing Account policy
> Could not set account policy, ((21, "objectclass_attrs: attribute  
> 'minPwdLength' on entry 'DC=micore,DC=us' contains at least one  
> invalid value!"))
> Importing idmap database
> Cannot open idmap database, Ignoring: (2): No such file or directory
> Ignoring unknown parameter "server role"
> Importing groups
> Group already exists  
> sid=S-1-5-21-2037442776-3290224752-88127236-514, groupname=Domain  
> Guests existing_groupname=Domain Guests, Ignoring.
> Group already exists sid=S-1-5-32-544, groupname=Administrators  
> existing_groupname=Administrators, Ignoring.
> Could not add group name=Print Operators ((68, "samldb: Account name  
> (sAMAccountName) 'Print Operators' already in use!"))
> Could not add group name=Mor-Value Parts ((68, "samldb: Account name  
> (sAMAccountName) 'Mor-Value Parts' already in use!"))
> Group already exists  
> sid=S-1-5-21-2037442776-3290224752-88127236-512, groupname=Domain  
> Admins existing_groupname=Domain Admins, Ignoring.
> Importing users
> Adding users to groups
> ProvisioningError: Could not add member  
> 'S-1-5-21-2037442776-3290224752-88127236-9272' to group  
> 'S-1-5-21-2037442776-3290224752-88127236-1201' as either group or  
> user record doesn't exist: Unable to find GUID for DN

BAM! The script has completed successfully;  primarily this required  
hacking some print statements into the script to help pin-point what  
exactly was happening and then performing some janitorial work in the  
elderly LDAPSAM.

1 - Group "displayName" has to be case-insensitive unique.
1.1. - You [obviously, these is NT land] can't have groups and users  
of the same name.
2 - If the script doesn't import a user building the group membership  
will fail;  although the script never complains about a user it didn't  
import.
3 - If a sambaSAMAccount object isn't fully initialized [for example,  
has not password] it doesn't appear to get imported.
4 - If you have groups with the same name a Built-In group import of  
the groups will merrily pass it over but membership assignment will  
fail since that is based on SID.  This can be initially confusing [see  
#2].  We had a "Print Operators" group with a SID other than the  
expected built-in SID, this crashed the script.  I suspect in LDAPSAMs  
that have been around a very long time [like ours] running into  
something like this probably won't be that uncommon.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrade from S3 to a Samba4 DC [with LDAPSAM]

Michael Wood-8
In reply to this post by Adam Tauno Williams
Hi

On 11 September 2011 13:57, Adam Tauno Williams <[hidden email]> wrote:
[...]

> I'm not certain that is really why the script was failing.  Renaming the
> group to not be so-named did *not* resolve the issue.  The script didn't
> fail with a particularly clear error messages.
>
> Just -
> s4_passdb.add_sam_account(userdata[username])
> passdb.error: Unable to add sam account 'bie', (-1073741725,User exists)
>
> Which doesn't really indicate why it can't add the SAM account;  would
> an already existing *group* of the same name cause a "User exists"
> error?

I wouldn't be too surprised.

--
Michael Wood <[hidden email]>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrade from S3 to a Samba4 DC [with LDAPSAM]

Andrew Bartlett
In reply to this post by Adam Tauno Williams
On Sun, 2011-09-11 at 07:57 -0400, Adam Tauno Williams wrote:

> On Fri, 2011-09-09 at 14:27 +0200, Tarjei Huse wrote:
> > On 09/08/2011 11:11 PM, Andrew Bartlett wrote:
> > > On Thu, 2011-09-08 at 16:56 -0400, Adam Tauno Williams wrote:
> > >> Quoting tataia <[hidden email]>:
> > >>> It happens for groups that have sambaGroupType =5
> > >>> replace 5 with 4
> > >> Gotcha.  And it goes much further.  Are users with the same name as  
> > >> groups an issue?  There is only one uid=bie object in the LDAPSAM.
> > > Users with the same name as groups have always been prohibited in
> > > Windows, even with NT4.  I'm not sure there is anything we can do except
> > > fail here, but I'm open to suggestions.
> > Document it?
>
> It is reasonably well documented [I knew about it].  That is just an
> NT/Windows thing.  Anyone managing Windows should already know about
> that [from the Microsoft documentation], IMO.  The only really issue
> regarding that is that S3 LDAPSAM was pretty fast-and-loose with
> enforcing rules.   Does S3 LDAPSAM even use the "cn" attribute as the
> group name?  It appears to use the "description" attribute in most
> places [at least that is what appears on the screen when looking at a
> security descriptor].
>
> > Would it be possible for the upgrade script to have a pre flight test
> > that checks for gotchas like this and lists the offending entries with
> > suggested changes?
>
> I'm not certain that is really why the script was failing.  Renaming the
> group to not be so-named did *not* resolve the issue.  The script didn't
> fail with a particularly clear error messages.
>
> Just -
> s4_passdb.add_sam_account(userdata[username])
> passdb.error: Unable to add sam account 'bie', (-1073741725,User exists)
>
> Which doesn't really indicate why it can't add the SAM account;  would
> an already existing *group* of the same name cause a "User exists"
> error?

Yes, it would cause that error from that interface (we could fix that
interface I guess).

I took an alternate approach, and we now (as of current master) perform
a pre-flight check for duplicate user and group names, as well as user
and group SIDs before the provision stage.  

The advantage of this approach is that we list all the duplicates, and
we have the space to make verbose recommendations (patches from
experienced users most welcome)

The command has also been renamed in preparation for the Samba 4.0 alpha
17 release, it is now 'samba domain samba3upgrade'.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrade from S3 to a Samba4 DC [with LDAPSAM]

Andrew Bartlett
In reply to this post by Adam Tauno Williams
On Sun, 2011-09-11 at 07:57 -0400, Adam Tauno Williams wrote:

> On Fri, 2011-09-09 at 14:27 +0200, Tarjei Huse wrote:
> > On 09/08/2011 11:11 PM, Andrew Bartlett wrote:
> > > On Thu, 2011-09-08 at 16:56 -0400, Adam Tauno Williams wrote:
> > >> Quoting tataia <[hidden email]>:
> > >>> It happens for groups that have sambaGroupType =5
> > >>> replace 5 with 4
> > >> Gotcha.  And it goes much further.  Are users with the same name as  
> > >> groups an issue?  There is only one uid=bie object in the LDAPSAM.
> > > Users with the same name as groups have always been prohibited in
> > > Windows, even with NT4.  I'm not sure there is anything we can do except
> > > fail here, but I'm open to suggestions.
> > Document it?
>
> It is reasonably well documented [I knew about it].  That is just an
> NT/Windows thing.  Anyone managing Windows should already know about
> that [from the Microsoft documentation], IMO.  The only really issue
> regarding that is that S3 LDAPSAM was pretty fast-and-loose with
> enforcing rules.   Does S3 LDAPSAM even use the "cn" attribute as the
> group name?  It appears to use the "description" attribute in most
> places [at least that is what appears on the screen when looking at a
> security descriptor].
>
> > Would it be possible for the upgrade script to have a pre flight test
> > that checks for gotchas like this and lists the offending entries with
> > suggested changes?
>
> I'm not certain that is really why the script was failing.  Renaming the
> group to not be so-named did *not* resolve the issue.  The script didn't
> fail with a particularly clear error messages.
>
> Just -
> s4_passdb.add_sam_account(userdata[username])
> passdb.error: Unable to add sam account 'bie', (-1073741725,User exists)
>
> Which doesn't really indicate why it can't add the SAM account;  would
> an already existing *group* of the same name cause a "User exists"
> error?

Yes, it would cause that error from that interface (we could fix that
interface I guess).

I took an alternate approach, and we now (as of current master) perform
a pre-flight check for duplicate user and group names, as well as user
and group SIDs before the provision stage.  

The advantage of this approach is that we list all the duplicates, and
we have the space to make verbose recommendations (patches from
experienced users most welcome)

The command has also been renamed in preparation for the Samba 4.0 alpha
17 release, it is now 'samba-tool domain samba3upgrade'.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrade from S3 to a Samba4 DC [with LDAPSAM] [SUCCESS!]

Andrew Bartlett
In reply to this post by Adam Tauno Williams
On Mon, 2011-09-12 at 11:20 -0400, Adam Tauno Williams wrote:

> Quoting Adam Tauno Williams <[hidden email]>:
>
> > Quoting Adam Tauno Williams <[hidden email]>:
> >
> >> Quoting Adam Tauno Williams <[hidden email]>:
> >>> Quoting tataia <[hidden email]>:
> >>>> It happens for groups that have sambaGroupType =5
> >>>> replace 5 with 4
> >>> Gotcha.  And it goes much further.  Are users with the same name  
> >>> as groups an issue?  There is only one uid=bie object in the  
> >>> LDAPSAM.
> >> Hrm... so I manually exclude user "bie" and import users completes.
> >> But then the script fails while adding users to group.  I've  
> >> verified that sambaSID=S-1-5-21-2037442776-3290224752-88127236-9272  
> >> [a user] and sambaSID=S-1-5-21-2037442776-3290224752-88127236-1201  
> >> [a group] both exist (and both exist only once).
> >
> > Setting the "debug level" in the S3 smb.conf file seems to work  
> > [which is handy].
> >
> > ???? Is there a way or level to specifically log what LDB is trying  
> > to do / look for / add ???
> >
> > Both S-1-5-21-2037442776-3290224752-88127236-9272 and  
> > S-1-5-21-2037442776-3290224752-88127236-1201 exist in the S3 LDAPSAM.
> >
> > At a debug level of 256 this output looks like -
> >
> > [root@localhost samba-master]# ./source4/setup/upgrade_from_s3  
> > smb.conf /tmp/x --libdir=/root/s3
> > Reading smb.conf
> > INFO: Current debug levels:
> >   all: 256
> >   tdb: 256
> >   printdrivers: 256
> >   lanman: 256
> >   smb: 256
> >   rpc_parse: 256
> >   rpc_srv: 256
> >   rpc_cli: 256
> >   passdb: 256
> >   sam: 256
> >   auth: 256
> >   winbind: 256
> >   vfs: 256
> >   idmap: 256
> >   quota: 256
> >   acls: 256
> >   locking: 256
> >   msdfs: 256
> >   dmapi: 256
> >   registry: 256
> > doing parameter domain master = yes
> > doing parameter preferred master = yes
> > doing parameter domain logons = yes
> > doing parameter logon script = %G.bat
> > doing parameter logon path = \\BARBEL\PROFILES\%U
> > doing parameter logon drive = f:
> > doing parameter logon home = \\ARABIS-RED\HOMEDIR
> > doing parameter wins support = yes
> > doing parameter name resolve order = wins host
> > doing parameter dns proxy = yes
> > doing parameter map to guest = Bad User
> > doing parameter passdb backend = ldapsam:ldap://192.168.1.9/
> > doing parameter ldap ssl = no
> > doing parameter ldap admin dn =  
> > uid=CIFSDC,ou=System,ou=Entities,ou=SAM,o=Morrison Industries,c=US
> > doing parameter ldap suffix = o=Morrison Industries,c=US
> > doing parameter ldap group suffix = ou=Groups,ou=SAM
> > doing parameter ldapsam:trusted = yes
> > doing parameter idmap backend = ldap:ldap://localhost
> > WARNING: The "idmap backend" option is deprecated
> > doing parameter ldap idmap suffix = ou=idMap,ou=CIFS,ou=SubSystems
> > doing parameter idmap uid = 40000-50000
> > WARNING: The "idmap uid" option is deprecated
> > doing parameter idmap gid = 40000-50000
> > WARNING: The "idmap gid" option is deprecated
> > doing parameter winbind use default domain = yes
> > doing parameter username map = /etc/samba/username.map
> > doing parameter deadtime = 15
> > doing parameter log level = 0 winbind:2
> > Provisioning
> > /root/s3/secrets.tdb
> > no talloc stackframe around, leaking memory
> > Exporting account policy
> > Exporting groups
> > Exporting users
> >   Skipping wellknown rid=998 (for username=pc01845$)
> >   Skipping wellknown rid=500 (for username=root)
> > Next rid = 9973
> > Looking up IPv4 addresses
> > Looking up IPv6 addresses
> > No IPv6 address will be assigned
> > Setting up share.ldb
> > Setting up secrets.ldb
> > Setting up the registry
> > Setting up the privileges database
> > Setting up idmap db
> > Setting up SAM db
> > Setting up sam.ldb partitions and settings
> > Setting up sam.ldb rootDSE
> > Pre-loading the Samba 4 and AD schema
> > Adding DomainDN: DC=micore,DC=us
> > Adding configuration container
> > Setting up sam.ldb schema
> > Reopening sam.ldb with new schema
> > Setting up sam.ldb configuration data
> > Setting up display specifiers
> > Adding users container
> > Modifying users container
> > Adding computers container
> > Modifying computers container
> > Setting up sam.ldb data
> > Setting up sam.ldb users and groups
> > Setting up self join
> > Setting up sam.ldb rootDSE marking as synchronized
> > Assuming bind9 DNS server backend
> > Adding DNS accounts
> > Populating CN=System,DC=micore,DC=us
> > See /tmp/x/private/named.conf for an example configuration include  
> > file for BIND
> > and /tmp/x/private/named.txt for further documentation required for  
> > secure DNS updates
> > A Kerberos configuration suitable for Samba 4 has been generated at  
> > /tmp/x/private/krb5.conf
> > Fixing provision GUIDs
> > Please install the phpLDAPadmin configuration located at  
> > /tmp/x/private/phpldapadmin-config.php into  
> > /etc/phpldapadmin/config.php
> > Once the above files are installed, your Samba4 server will be ready to use
> > Server Role:           domain controller
> > Hostname:              BARBEL
> > NetBIOS Domain:        BACKBONE
> > DNS Domain:            micore.us
> > DOMAIN SID:            S-1-5-21-2037442776-3290224752-88127236
> > Admin password:        ************************
> > Importing WINS database
> > Importing Account policy
> > Could not set account policy, ((21, "objectclass_attrs: attribute  
> > 'minPwdLength' on entry 'DC=micore,DC=us' contains at least one  
> > invalid value!"))
> > Importing idmap database
> > Cannot open idmap database, Ignoring: (2): No such file or directory
> > Ignoring unknown parameter "server role"
> > Importing groups
> > Group already exists  
> > sid=S-1-5-21-2037442776-3290224752-88127236-514, groupname=Domain  
> > Guests existing_groupname=Domain Guests, Ignoring.
> > Group already exists sid=S-1-5-32-544, groupname=Administrators  
> > existing_groupname=Administrators, Ignoring.
> > Could not add group name=Print Operators ((68, "samldb: Account name  
> > (sAMAccountName) 'Print Operators' already in use!"))
> > Could not add group name=Mor-Value Parts ((68, "samldb: Account name  
> > (sAMAccountName) 'Mor-Value Parts' already in use!"))
> > Group already exists  
> > sid=S-1-5-21-2037442776-3290224752-88127236-512, groupname=Domain  
> > Admins existing_groupname=Domain Admins, Ignoring.
> > Importing users
> > Adding users to groups
> > ProvisioningError: Could not add member  
> > 'S-1-5-21-2037442776-3290224752-88127236-9272' to group  
> > 'S-1-5-21-2037442776-3290224752-88127236-1201' as either group or  
> > user record doesn't exist: Unable to find GUID for DN
>
> BAM! The script has completed successfully;  primarily this required  
> hacking some print statements into the script to help pin-point what  
> exactly was happening and then performing some janitorial work in the  
> elderly LDAPSAM.
>
> 1 - Group "displayName" has to be case-insensitive unique.
> 1.1. - You [obviously, these is NT land] can't have groups and users  
> of the same name.
> 2 - If the script doesn't import a user building the group membership  
> will fail;  although the script never complains about a user it didn't  
> import.
> 3 - If a sambaSAMAccount object isn't fully initialized [for example,  
> has not password] it doesn't appear to get imported.
> 4 - If you have groups with the same name a Built-In group import of  
> the groups will merrily pass it over but membership assignment will  
> fail since that is based on SID.  This can be initially confusing [see  
> #2].  We had a "Print Operators" group with a SID other than the  
> expected built-in SID, this crashed the script.  I suspect in LDAPSAMs  
> that have been around a very long time [like ours] running into  
> something like this probably won't be that uncommon.

If you could prepare some patches to assist sites like yours in
debugging Samba3 upgrades I would very much appreciate it.  In
particular, details about the users which didn't import and what is
special about them would be useful.  I'm quite willing to make it fail
if it cannot import a user, if that would make debugging easier.

Your feedback here is particularly valuable.

Thanks,

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrade from S3 to a Samba4 DC [with LDAPSAM] [SUCCESS!]

Matthias Dieter Wallnöfer-3
In reply to this post by Andrew Bartlett
Andrew,

just my two cents: if I would like to perform the upgrade by using s3's testparm I need the following patch: http://gitweb.samba.org/mdw/samba.git/?p=mdw/samba.git;a=commitdiff;h=9b16083e7d50275daf7c33f659f336360d553b1e. Obviously this approach isn't tested by torture since it broke yesterday. Could we apply that one?

Thanks,
Matthias

On Mon, 2011-09-12 at 11:20 -0400, Adam Tauno Williams wrote:

> Quoting Adam Tauno Williams <[hidden email]>:
>
> > Quoting Adam Tauno Williams <[hidden email]>:
> >
> >> Quoting Adam Tauno Williams <[hidden email]>:
> >>> Quoting tataia <[hidden email]>:
> >>>> It happens for groups that have sambaGroupType =5
> >>>> replace 5 with 4
> >>> Gotcha.  And it goes much further.  Are users with the same name 
> >>> as groups an issue?  There is only one uid=bie object in the 
> >>> LDAPSAM.
> >> Hrm... so I manually exclude user "bie" and import users completes.
> >> But then the script fails while adding users to group.  I've 
> >> verified that sambaSID=S-1-5-21-2037442776-3290224752-88127236-9272 
> >> [a user] and sambaSID=S-1-5-21-2037442776-3290224752-88127236-1201 
> >> [a group] both exist (and both exist only once).
> >
> > Setting the "debug level" in the S3 smb.conf file seems to work 
> > [which is handy].
> >
> > ???? Is there a way or level to specifically log what LDB is trying 
> > to do / look for / add ???
> >
> > Both S-1-5-21-2037442776-3290224752-88127236-9272 and 
> > S-1-5-21-2037442776-3290224752-88127236-1201 exist in the S3 LDAPSAM.
> >
> > At a debug level of 256 this output looks like -
> >
> > [root@localhost samba-master]# ./source4/setup/upgrade_from_s3 
> > smb.conf /tmp/x --libdir=/root/s3
> > Reading smb.conf
> > INFO: Current debug levels:
> >   all: 256
> >   tdb: 256
> >   printdrivers: 256
> >   lanman: 256
> >   smb: 256
> >   rpc_parse: 256
> >   rpc_srv: 256
> >   rpc_cli: 256
> >   passdb: 256
> >   sam: 256
> >   auth: 256
> >   winbind: 256
> >   vfs: 256
> >   idmap: 256
> >   quota: 256
> >   acls: 256
> >   locking: 256
> >   msdfs: 256
> >   dmapi: 256
> >   registry: 256
> > doing parameter domain master = yes
> > doing parameter preferred master = yes
> > doing parameter domain logons = yes
> > doing parameter logon script = %G.bat
> > doing parameter logon path = \\BARBEL\PROFILES\%U
> > doing parameter logon drive = f:
> > doing parameter logon home = \\ARABIS-RED\HOMEDIR
> > doing parameter wins support = yes
> > doing parameter name resolve order = wins host
> > doing parameter dns proxy = yes
> > doing parameter map to guest = Bad User
> > doing parameter passdb backend = ldapsam:ldap://192.168.1.9/
> > doing parameter ldap ssl = no
> > doing parameter ldap admin dn = 
> > uid=CIFSDC,ou=System,ou=Entities,ou=SAM,o=Morrison Industries,c=US
> > doing parameter ldap suffix = o=Morrison Industries,c=US
> > doing parameter ldap group suffix = ou=Groups,ou=SAM
> > doing parameter ldapsam:trusted = yes
> > doing parameter idmap backend = ldap:ldap://localhost
> > WARNING: The "idmap backend" option is deprecated
> > doing parameter ldap idmap suffix = ou=idMap,ou=CIFS,ou=SubSystems
> > doing parameter idmap uid = 40000-50000
> > WARNING: The "idmap uid" option is deprecated
> > doing parameter idmap gid = 40000-50000
> > WARNING: The "idmap gid" option is deprecated
> > doing parameter winbind use default domain = yes
> > doing parameter username map = /etc/samba/username.map
> > doing parameter deadtime = 15
> > doing parameter log level = 0 winbind:2
> > Provisioning
> > /root/s3/secrets.tdb
> > no talloc stackframe around, leaking memory
> > Exporting account policy
> > Exporting groups
> > Exporting users
> >   Skipping wellknown rid=998 (for username=pc01845$)
> >   Skipping wellknown rid=500 (for username=root)
> > Next rid = 9973
> > Looking up IPv4 addresses
> > Looking up IPv6 addresses
> > No IPv6 address will be assigned
> > Setting up share.ldb
> > Setting up secrets.ldb
> > Setting up the registry
> > Setting up the privileges database
> > Setting up idmap db
> > Setting up SAM db
> > Setting up sam.ldb partitions and settings
> > Setting up sam.ldb rootDSE
> > Pre-loading the Samba 4 and AD schema
> > Adding DomainDN: DC=micore,DC=us
> > Adding configuration container
> > Setting up sam.ldb schema
> > Reopening sam.ldb with new schema
> > Setting up sam.ldb configuration data
> > Setting up display specifiers
> > Adding users container
> > Modifying users container
> > Adding computers container
> > Modifying computers container
> > Setting up sam.ldb data
> > Setting up sam.ldb users and groups
> > Setting up self join
> > Setting up sam.ldb rootDSE marking as synchronized
> > Assuming bind9 DNS server backend
> > Adding DNS accounts
> > Populating CN=System,DC=micore,DC=us
> > See /tmp/x/private/named.conf for an example configuration include 
> > file for BIND
> > and /tmp/x/private/named.txt for further documentation required for 
> > secure DNS updates
> > A Kerberos configuration suitable for Samba 4 has been generated at 
> > /tmp/x/private/krb5.conf
> > Fixing provision GUIDs
> > Please install the phpLDAPadmin configuration located at 
> > /tmp/x/private/phpldapadmin-config.php into 
> > /etc/phpldapadmin/config.php
> > Once the above files are installed, your Samba4 server will be ready to use
> > Server Role:           domain controller
> > Hostname:              BARBEL
> > NetBIOS Domain:        BACKBONE
> > DNS Domain:            micore.us
> > DOMAIN SID:            S-1-5-21-2037442776-3290224752-88127236
> > Admin password:        ************************
> > Importing WINS database
> > Importing Account policy
> > Could not set account policy, ((21, "objectclass_attrs: attribute 
> > 'minPwdLength' on entry 'DC=micore,DC=us' contains at least one 
> > invalid value!"))
> > Importing idmap database
> > Cannot open idmap database, Ignoring: (2): No such file or directory
> > Ignoring unknown parameter "server role"
> > Importing groups
> > Group already exists 
> > sid=S-1-5-21-2037442776-3290224752-88127236-514, groupname=Domain 
> > Guests existing_groupname=Domain Guests, Ignoring.
> > Group already exists sid=S-1-5-32-544, groupname=Administrators 
> > existing_groupname=Administrators, Ignoring.
> > Could not add group name=Print Operators ((68, "samldb: Account name 
> > (sAMAccountName) 'Print Operators' already in use!"))
> > Could not add group name=Mor-Value Parts ((68, "samldb: Account name 
> > (sAMAccountName) 'Mor-Value Parts' already in use!"))
> > Group already exists 
> > sid=S-1-5-21-2037442776-3290224752-88127236-512, groupname=Domain 
> > Admins existing_groupname=Domain Admins, Ignoring.
> > Importing users
> > Adding users to groups
> > ProvisioningError: Could not add member 
> > 'S-1-5-21-2037442776-3290224752-88127236-9272' to group 
> > 'S-1-5-21-2037442776-3290224752-88127236-1201' as either group or 
> > user record doesn't exist: Unable to find GUID for DN
>
> BAM! The script has completed successfully;  primarily this required 
> hacking some print statements into the script to help pin-point what 
> exactly was happening and then performing some janitorial work in the 
> elderly LDAPSAM.
>
> 1 - Group "displayName" has to be case-insensitive unique.
> 1.1. - You [obviously, these is NT land] can't have groups and users 
> of the same name.
> 2 - If the script doesn't import a user building the group membership 
> will fail;  although the script never complains about a user it didn't 
> import.
> 3 - If a sambaSAMAccount object isn't fully initialized [for example, 
> has not password] it doesn't appear to get imported.
> 4 - If you have groups with the same name a Built-In group import of 
> the groups will merrily pass it over but membership assignment will 
> fail since that is based on SID.  This can be initially confusing [see 
> #2].  We had a "Print Operators" group with a SID other than the 
> expected built-in SID, this crashed the script.  I suspect in LDAPSAMs 
> that have been around a very long time [like ours] running into 
> something like this probably won't be that uncommon.

If you could prepare some patches to assist sites like yours in
debugging Samba3 upgrades I would very much appreciate it.  In
particular, details about the users which didn't import and what is
special about them would be useful.  I'm quite willing to make it fail
if it cannot import a user, if that would make debugging easier.

Your feedback here is particularly valuable.

Thanks,

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrade from S3 to a Samba4 DC [with LDAPSAM] [SUCCESS!]

Andrew Bartlett
On Tue, 2011-09-13 at 09:00 +0100, Matthias Dieter Wallnöfer wrote:
> Andrew,
>
> just my two cents: if I would like to perform the upgrade by using s3's testparm I need the following patch: http://gitweb.samba.org/mdw/samba.git/?p=mdw/samba.git;a=commitdiff;h=9b16083e7d50275daf7c33f659f336360d553b1e. Obviously this approach isn't tested by torture since it broke yesterday. Could we apply that one?

Thanks for spotting that.  To fix this properly, our blackbox tests need
to be extended, both to confirm that the upgraded database includes the
users we expect and to use the testparm option against testparm from the
local build.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrade from S3 to a Samba4 DC [with LDAPSAM]

Thys
In reply to this post by tataia
Thanks! I've had exactly this problem. Is it an issue to change group types from 5 to 4? We do not really use the built-in groups (type 5). Can we also just delete these and will the upgrade provision recreate the standard built-in groups?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrade from S3 to a Samba4 DC [with LDAPSAM]

Andrew Bartlett
On Tue, 2011-09-13 at 03:30 -0700, Thys wrote:
> Thanks! I've had exactly this problem. Is it an issue to change group types
> from 5 to 4? We do not really use the built-in groups (type 5). Can we also
> just delete these and will the upgrade provision recreate the standard
> built-in groups?

Yes, the default BUILTIN groups are created by Samba4: we never actually
import them, because we know we will have them.  That's why it's only
adding members that fails.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

samba-tool domain samba3upgrade behaviour

Andrew Bartlett
In reply to this post by Matthias Dieter Wallnöfer-3
On Tue, 2011-09-13 at 18:48 +1000, Andrew Bartlett wrote:
> On Tue, 2011-09-13 at 09:00 +0100, Matthias Dieter Wallnöfer wrote:
> > Andrew,
> >
> > just my two cents: if I would like to perform the upgrade by using s3's testparm I need the following patch: http://gitweb.samba.org/mdw/samba.git/?p=mdw/samba.git;a=commitdiff;h=9b16083e7d50275daf7c33f659f336360d553b1e. Obviously this approach isn't tested by torture since it broke yesterday. Could we apply that one?
>
> Thanks for spotting that.  To fix this properly, our blackbox tests need
> to be extended, both to confirm that the upgraded database includes the
> users we expect and to use the testparm option against testparm from the
> local build.

I have an autobuild pending that should address the need to test
--testparm and fixes a few other issues.  The need to check the upgrade
database for expected values remains however.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrade from S3 to a Samba4 DC [with LDAPSAM] [SUCCESS!]

Matthias Dieter Wallnöfer-3
In reply to this post by Matthias Dieter Wallnöfer-3
Andrew,

I've found another issue: older versions than Samba 3.4 don't
incorporate the "state directory" parameter yet. Instead there has to be
used the "lock directory" directive. Could this patch work?
http://gitweb.samba.org/samba.git/?p=mdw/samba.git;a=commitdiff;h=472b320a17320f69450950763ff999267cddd080

Thanks,
Matthias

Matthias Dieter Wallnöfer wrote:

> Andrew,
>
> just my two cents: if I would like to perform the upgrade by using s3's testparm I need the following patch: http://gitweb.samba.org/mdw/samba.git/?p=mdw/samba.git;a=commitdiff;h=9b16083e7d50275daf7c33f659f336360d553b1e. Obviously this approach isn't tested by torture since it broke yesterday. Could we apply that one?
>
> Thanks,
> Matthias
>
> On Mon, 2011-09-12 at 11:20 -0400, Adam Tauno Williams wrote:
>> Quoting Adam Tauno Williams<[hidden email]>:
>>
>>> Quoting Adam Tauno Williams<[hidden email]>:
>>>
>>>> Quoting Adam Tauno Williams<[hidden email]>:
>>>>> Quoting tataia<[hidden email]>:
>>>>>> It happens for groups that have sambaGroupType =5
>>>>>> replace 5 with 4
>>>>> Gotcha.  And it goes much further.  Are users with the same name
>>>>> as groups an issue?  There is only one uid=bie object in the
>>>>> LDAPSAM.
>>>> Hrm... so I manually exclude user "bie" and import users completes.
>>>> But then the script fails while adding users to group.  I've
>>>> verified that sambaSID=S-1-5-21-2037442776-3290224752-88127236-9272
>>>> [a user] and sambaSID=S-1-5-21-2037442776-3290224752-88127236-1201
>>>> [a group] both exist (and both exist only once).
>>> Setting the "debug level" in the S3 smb.conf file seems to work
>>> [which is handy].
>>>
>>> ???? Is there a way or level to specifically log what LDB is trying
>>> to do / look for / add ???
>>>
>>> Both S-1-5-21-2037442776-3290224752-88127236-9272 and
>>> S-1-5-21-2037442776-3290224752-88127236-1201 exist in the S3 LDAPSAM.
>>>
>>> At a debug level of 256 this output looks like -
>>>
>>> [root@localhost samba-master]# ./source4/setup/upgrade_from_s3
>>> smb.conf /tmp/x --libdir=/root/s3
>>> Reading smb.conf
>>> INFO: Current debug levels:
>>>     all: 256
>>>     tdb: 256
>>>     printdrivers: 256
>>>     lanman: 256
>>>     smb: 256
>>>     rpc_parse: 256
>>>     rpc_srv: 256
>>>     rpc_cli: 256
>>>     passdb: 256
>>>     sam: 256
>>>     auth: 256
>>>     winbind: 256
>>>     vfs: 256
>>>     idmap: 256
>>>     quota: 256
>>>     acls: 256
>>>     locking: 256
>>>     msdfs: 256
>>>     dmapi: 256
>>>     registry: 256
>>> doing parameter domain master = yes
>>> doing parameter preferred master = yes
>>> doing parameter domain logons = yes
>>> doing parameter logon script = %G.bat
>>> doing parameter logon path = \\BARBEL\PROFILES\%U
>>> doing parameter logon drive = f:
>>> doing parameter logon home = \\ARABIS-RED\HOMEDIR
>>> doing parameter wins support = yes
>>> doing parameter name resolve order = wins host
>>> doing parameter dns proxy = yes
>>> doing parameter map to guest = Bad User
>>> doing parameter passdb backend = ldapsam:ldap://192.168.1.9/
>>> doing parameter ldap ssl = no
>>> doing parameter ldap admin dn =
>>> uid=CIFSDC,ou=System,ou=Entities,ou=SAM,o=Morrison Industries,c=US
>>> doing parameter ldap suffix = o=Morrison Industries,c=US
>>> doing parameter ldap group suffix = ou=Groups,ou=SAM
>>> doing parameter ldapsam:trusted = yes
>>> doing parameter idmap backend = ldap:ldap://localhost
>>> WARNING: The "idmap backend" option is deprecated
>>> doing parameter ldap idmap suffix = ou=idMap,ou=CIFS,ou=SubSystems
>>> doing parameter idmap uid = 40000-50000
>>> WARNING: The "idmap uid" option is deprecated
>>> doing parameter idmap gid = 40000-50000
>>> WARNING: The "idmap gid" option is deprecated
>>> doing parameter winbind use default domain = yes
>>> doing parameter username map = /etc/samba/username.map
>>> doing parameter deadtime = 15
>>> doing parameter log level = 0 winbind:2
>>> Provisioning
>>> /root/s3/secrets.tdb
>>> no talloc stackframe around, leaking memory
>>> Exporting account policy
>>> Exporting groups
>>> Exporting users
>>>     Skipping wellknown rid=998 (for username=pc01845$)
>>>     Skipping wellknown rid=500 (for username=root)
>>> Next rid = 9973
>>> Looking up IPv4 addresses
>>> Looking up IPv6 addresses
>>> No IPv6 address will be assigned
>>> Setting up share.ldb
>>> Setting up secrets.ldb
>>> Setting up the registry
>>> Setting up the privileges database
>>> Setting up idmap db
>>> Setting up SAM db
>>> Setting up sam.ldb partitions and settings
>>> Setting up sam.ldb rootDSE
>>> Pre-loading the Samba 4 and AD schema
>>> Adding DomainDN: DC=micore,DC=us
>>> Adding configuration container
>>> Setting up sam.ldb schema
>>> Reopening sam.ldb with new schema
>>> Setting up sam.ldb configuration data
>>> Setting up display specifiers
>>> Adding users container
>>> Modifying users container
>>> Adding computers container
>>> Modifying computers container
>>> Setting up sam.ldb data
>>> Setting up sam.ldb users and groups
>>> Setting up self join
>>> Setting up sam.ldb rootDSE marking as synchronized
>>> Assuming bind9 DNS server backend
>>> Adding DNS accounts
>>> Populating CN=System,DC=micore,DC=us
>>> See /tmp/x/private/named.conf for an example configuration include
>>> file for BIND
>>> and /tmp/x/private/named.txt for further documentation required for
>>> secure DNS updates
>>> A Kerberos configuration suitable for Samba 4 has been generated at
>>> /tmp/x/private/krb5.conf
>>> Fixing provision GUIDs
>>> Please install the phpLDAPadmin configuration located at
>>> /tmp/x/private/phpldapadmin-config.php into
>>> /etc/phpldapadmin/config.php
>>> Once the above files are installed, your Samba4 server will be ready to use
>>> Server Role:           domain controller
>>> Hostname:              BARBEL
>>> NetBIOS Domain:        BACKBONE
>>> DNS Domain:            micore.us
>>> DOMAIN SID:            S-1-5-21-2037442776-3290224752-88127236
>>> Admin password:        ************************
>>> Importing WINS database
>>> Importing Account policy
>>> Could not set account policy, ((21, "objectclass_attrs: attribute
>>> 'minPwdLength' on entry 'DC=micore,DC=us' contains at least one
>>> invalid value!"))
>>> Importing idmap database
>>> Cannot open idmap database, Ignoring: (2): No such file or directory
>>> Ignoring unknown parameter "server role"
>>> Importing groups
>>> Group already exists
>>> sid=S-1-5-21-2037442776-3290224752-88127236-514, groupname=Domain
>>> Guests existing_groupname=Domain Guests, Ignoring.
>>> Group already exists sid=S-1-5-32-544, groupname=Administrators
>>> existing_groupname=Administrators, Ignoring.
>>> Could not add group name=Print Operators ((68, "samldb: Account name
>>> (sAMAccountName) 'Print Operators' already in use!"))
>>> Could not add group name=Mor-Value Parts ((68, "samldb: Account name
>>> (sAMAccountName) 'Mor-Value Parts' already in use!"))
>>> Group already exists
>>> sid=S-1-5-21-2037442776-3290224752-88127236-512, groupname=Domain
>>> Admins existing_groupname=Domain Admins, Ignoring.
>>> Importing users
>>> Adding users to groups
>>> ProvisioningError: Could not add member
>>> 'S-1-5-21-2037442776-3290224752-88127236-9272' to group
>>> 'S-1-5-21-2037442776-3290224752-88127236-1201' as either group or
>>> user record doesn't exist: Unable to find GUID for DN
>> BAM! The script has completed successfully;  primarily this required
>> hacking some print statements into the script to help pin-point what
>> exactly was happening and then performing some janitorial work in the
>> elderly LDAPSAM.
>>
>> 1 - Group "displayName" has to be case-insensitive unique.
>> 1.1. - You [obviously, these is NT land] can't have groups and users
>> of the same name.
>> 2 - If the script doesn't import a user building the group membership
>> will fail;  although the script never complains about a user it didn't
>> import.
>> 3 - If a sambaSAMAccount object isn't fully initialized [for example,
>> has not password] it doesn't appear to get imported.
>> 4 - If you have groups with the same name a Built-In group import of
>> the groups will merrily pass it over but membership assignment will
>> fail since that is based on SID.  This can be initially confusing [see
>> #2].  We had a "Print Operators" group with a SID other than the
>> expected built-in SID, this crashed the script.  I suspect in LDAPSAMs
>> that have been around a very long time [like ours] running into
>> something like this probably won't be that uncommon.
> If you could prepare some patches to assist sites like yours in
> debugging Samba3 upgrades I would very much appreciate it.  In
> particular, details about the users which didn't import and what is
> special about them would be useful.  I'm quite willing to make it fail
> if it cannot import a user, if that would make debugging easier.
>
> Your feedback here is particularly valuable.
>
> Thanks,
>
> Andrew Bartlett
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrade from S3 to a Samba4 DC [with LDAPSAM]

Adam Tauno Williams
In reply to this post by Andrew Bartlett
Quoting Andrew Bartlett <[hidden email]>:
> The command has also been renamed in preparation for the Samba 4.0 alpha
> 17 release, it is now 'samba domain samba3upgrade'.

I'm puzzled by how to read that.  Does that mean I use the "samba"  
program to invoke the upgrade?  After a git pull the previous upgrade  
script is gone;  but the syntax to get the same functionality doesn't  
seem obvious.

/opt/s4/sbin/samba domain samba3upgrade --help

doesn't provide any insight.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrade from S3 to a Samba4 DC [with LDAPSAM]

Adam Tauno Williams
Quoting Adam Tauno Williams <[hidden email]>
> Quoting Andrew Bartlett <[hidden email]>:
>> The command has also been renamed in preparation for the Samba 4.0 alpha
>> 17 release, it is now 'samba domain samba3upgrade'.
> I'm puzzled by how to read that.  Does that mean I use the "samba"  
> program to invoke the upgrade?  After a git pull the previous  
> upgrade script is gone;  but the syntax to get the same  
> functionality doesn't seem obvious.
> /opt/s4/sbin/samba domain samba3upgrade --help
> doesn't provide any insight.

Ah ha!  You meant "samba-tool domain samba3upgrade"


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

state dir and samba-tool domain samba3upgrade

Andrew Bartlett
In reply to this post by Matthias Dieter Wallnöfer-3
On Tue, 2011-09-13 at 17:55 +0200, Matthias Dieter Wallnöfer wrote:
> Andrew,
>
> I've found another issue: older versions than Samba 3.4 don't
> incorporate the "state directory" parameter yet. Instead there has to be
> used the "lock directory" directive. Could this patch work?
> http://gitweb.samba.org/samba.git/?p=mdw/samba.git;a=commitdiff;h=472b320a17320f69450950763ff999267cddd080

I don't think that's the right place to do it.  If this varies by
version of Samba 3.x that we are upgrading from, then this must have
been inherited from the invocation of the testparm binary.

If so, we should change that code to detect that the parameter was not
found.

"state directory" is a complex issue, as it essentially varied depending
on if Samba 3.x was compiled with --enable-fhs, and even then it varied
depending on if the user specified it - have a look at the tortured
logic in source3/param/loadparm.c.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: state dir and samba-tool domain samba3upgrade

Matthias Dieter Wallnöfer-3
What do you think about this approach:
http://gitweb.samba.org/samba.git/?p=mdw/samba.git;a=commitdiff;h=7e4fb523893e681659e2e64586f6bcf0af36a588?

Thanks,
Matthias

Andrew Bartlett wrote:

> On Tue, 2011-09-13 at 17:55 +0200, Matthias Dieter Wallnöfer wrote:
>> Andrew,
>>
>> I've found another issue: older versions than Samba 3.4 don't
>> incorporate the "state directory" parameter yet. Instead there has to be
>> used the "lock directory" directive. Could this patch work?
>> http://gitweb.samba.org/samba.git/?p=mdw/samba.git;a=commitdiff;h=472b320a17320f69450950763ff999267cddd080
> I don't think that's the right place to do it.  If this varies by
> version of Samba 3.x that we are upgrading from, then this must have
> been inherited from the invocation of the testparm binary.
>
> If so, we should change that code to detect that the parameter was not
> found.
>
> "state directory" is a complex issue, as it essentially varied depending
> on if Samba 3.x was compiled with --enable-fhs, and even then it varied
> depending on if the user specified it - have a look at the tortured
> logic in source3/param/loadparm.c.
>
> Andrew Bartlett
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: state dir and samba-tool domain samba3upgrade

Andrew Bartlett
On Wed, 2011-09-14 at 10:14 +0200, Matthias Dieter Wallnöfer wrote:
> What do you think about this approach:
> http://gitweb.samba.org/samba.git/?p=mdw/samba.git;a=commitdiff;h=7e4fb523893e681659e2e64586f6bcf0af36a588?

I'm much happier with that approach.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: state dir and samba-tool domain samba3upgrade

Matthias Dieter Wallnöfer-3
So I push that one?

Andrew Bartlett wrote:
> On Wed, 2011-09-14 at 10:14 +0200, Matthias Dieter Wallnöfer wrote:
>> What do you think about this approach:
>> http://gitweb.samba.org/samba.git/?p=mdw/samba.git;a=commitdiff;h=7e4fb523893e681659e2e64586f6bcf0af36a588?
> I'm much happier with that approach.
>
> Andrew Bartlett
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: state dir and samba-tool domain samba3upgrade

Andrew Bartlett
On Wed, 2011-09-14 at 10:43 +0200, Matthias Dieter Wallnöfer wrote:
> So I push that one?

Yes please push it (I had planned to sign off and push with any other
work I was doing, but didn't get to it today).

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upgrade from S3 to a Samba4 DC [with LDAPSAM]

Adam Tauno Williams
In reply to this post by Adam Tauno Williams
Quoting Adam Tauno Williams <[hidden email]>:

> Quoting Adam Tauno Williams <[hidden email]>
>> Quoting Andrew Bartlett <[hidden email]>:
>>> The command has also been renamed in preparation for the Samba 4.0 alpha
>>> 17 release, it is now 'samba domain samba3upgrade'.
>> I'm puzzled by how to read that.  Does that mean I use the "samba"  
>> program to invoke the upgrade?  After a git pull the previous  
>> upgrade script is gone;  but the syntax to get the same  
>> functionality doesn't seem obvious.
>> /opt/s4/sbin/samba domain samba3upgrade --help
>> doesn't provide any insight.
> Ah ha!  You meant "samba-tool domain samba3upgrade"


smbclient --version
Version 4.0.0alpha18-GIT-fa5475e

This works, with one bug.  It doesn't generate an Administrator  
password (which the previous script would auto-generate one).

$ export PATH=$PATH:/opt/s4/bin:/opt/s4/sbin
$ samba-tool domain samba3upgrade --libdir=/tmp/x /tmp/x/smb.conf
....
Server Role:           domain controller
Hostname:              BARBEL
NetBIOS Domain:        BACKBONE
DNS Domain:            micore.us
DOMAIN SID:            S-1-5-21-2037442776-**************
Admin password:        None  <<<< ????
Importing WINS database
Importing Account policy
....

Which then leaves me puzzled how to set an administrator password.

"samba-tool domain samba3upgrade --help" doesn't mention a parameter  
to predetermine one.

"samba-tool user password --username=administrator" prompts for a  
password.  Entering a blank password doesn't seem to explicitly fail  
but the operation fails with -

ERROR: Failed to change password : Connection to SAMR pipe of PDC of  
domain 'BACKBONE' failed: NT_STATUS_OBJECT_NAME_NOT_FOUND


12345
Loading...