Samba Upgrade-iad

[ray klassen]

First of all let me congratulate the wiki writers. The step by step classic-upgrade guide is very helpful. Here are my notes on the various steps of the upgrade. 

-- created a vanilla debian wheezy install, installed all the prerequisites as well as "devscripts," 
--compiled, installed samba using samba-4.1.2 
-- created symbolic links from /usr/local/samba/bin to /usr/local/bin and /usr/local/samba/sbin to /usr/local/sbin because those directories are in $PATH and from /usr/local/samba/etc/ to /etc/samba and from /usr/local/samba/var/log.* to /var/log/samba/* so that those files will be where I expect.
-- installed slapd, copied over the current ldap files, configured slapd to load them-- copied smb.conf and various *db files to a directory-- downloaded the debian bind9 source deb, added  --with-dlopen=yes to EXTRA_FEATURES= in the debian/rules file
--ran debuild -us -uc  from bind9 source dir -- created debs with dlopen support (this is what devscripts was for. 
--ran samba-tool doman classicupgrade... with --dns-backend=BIND_DLZ etc.--several colisions had to be edited out of the ldap directory before the upgrade would complete         -- a trusted domain account had to be removed-- an early phase of the classicupgrade script warned me that it would not be imported, but a later phase choked apparently because it hadn't been imported. Bug?         -- two groups had different groupnames but the same DisplayName. that had to be changed.
 -- played around with dns. Found that windows boxes really like to talk to the domain controller itself and not a slave.

ONGOING MOP-UP
-- have been busy reconnecting all the services that depended on ldap to active directory, learning kerberos

-----------------
Some things did not work as expected. 1) all the computers did not automatically join the new domain. Some did and some did not. The computers that were at the head office presumably in the same broadcast domain all joined automatically, once I configured the domain controller as DNS server assigned by DHCP. The computers at our satellite offices (approximately 30) did not. This maybe because I had LMHOSTS files on all those machines, except that after delete and reboot, (DNS still pointed at the DC -- I didn't forget) they didn't autoconnect. I have manually had to move them from OURDOMAIN to OURDOMAIN.sample.com and then they function normally as domain members.
THE SHOW STOPPER (not addressed anywhere although I would think it a fairly obvious course of action): Our main production file server is still running samba 3 and I didn't see any reason to upgrade it at this point, as from my experiments earlier I found that the permission semantics would now be NTFSish and I had a fair amount of data being shared in numerous shares with the assumption of unix permissions -- lots of "force group" and "create mask" directives. So I would think that having created an AD DC I could load up winbind and just connect to the new domain controller and it successfully did join. And Then... nothing. Winbind could not download any list of users. wbinfo -u gave me nothing. after a lot of searching I found that "wbinfo -t" would test your your connection (not having used much winbind before, I didn't know) and it appeared that the secrets.tdb file did not have the right info for winbind to use. Not knowing anything else to do I shut down samba and winbind, deleted secrets.tdb and performed a net join again. After that wbinfo -t was successful and wbinfo -u gave the standard list of users.  reconfiguring nss from ldap to winbind, etc. is documented elsewhere.

!!!  if fhis is a standard method (i.e. if simply deleting secrets.tdb is acceptable)  I'll put something on the wiki (I can) in the classic upgrade page about repurposing an existing samba3/LDAP domain controller. Because it really is a showstopper when you can't actually connect back to your data. 
-- The other thing that had to be done was any shares in smb.conf on the repurposed file server with limited access based on user or group had to be changed to "ourdomain\user" or "ourdomain\group" but this, though painful was just par for the course.

Anyhow, the wiki seems to indicate that you want accounts of upgrades. here's mine with emphasis on the stuff that wasn't covered as well as it might have been