Topic: PDC migration 5.5 to 6.0

[Alex]

No! smbpasswd -S only display current SID!
You need rsync /etc/secrets.tdb too.
Then
sbin/e-smith/signal-event post-upgrade

 /sbin/e-smith/signal-event reboot
That's all

[Loek]

Alex,

I also found on one of the many posts on the samba lists that this secrets.tdb file replaces the former MACHINE.SID, I am about to test this and post my results here. Did you clients accept their profiles from the new server?

|  Peter wrote:
|  
|  1. smbpasswd -S on the new server
|  2. a rsync of these files -
|  /etc/group
|  /etc/gshadow
|  /etc/passwd
|  /etc/shadow
|  /etc/smbpasswd
|  3. Shutdown old server
|  4. /sbin/e-smith/signal-event post-upgrade
|  5. /sbin/e-smith/signal-event reboot

This may work if you stick to the same sme version, but still you have to copy the SID and the secrets.tdb (I tested without the secrets and that did not work, t.i., the server works but you'll have to redo all user profiles).

If you migrate to sme6.0 at the same time, then just copying the passwd files will seriously mess up your server. 6.0 uses a series of entries (at least in passwd, I think) that were not in 5.5 (I don't know about 5.6). So you'll have to paste your accounts into these files.

More to follow.

Loek

[PeterG]

Hmmm, when I tried on my v6.0 server it tels me this -

[root@oulton e-smith]# smbpasswd -S
Successfully set domain SID to S-1-5-21-2672183053-1999075282-1853768680.
[root@oulton e-smith]#


and the man pages for smbpasswd tell me this -
"
-S     This  option  causes  smbpasswd to query a domain controller of the domain specified by the work group parameter in smb.conf and store the domain SID in the secrets.tdb file as its  own  machine SID.  This  is  only  useful when configuring a Samba PDC and Samba BDC, or when migrating from a Windows PDC to a Samba PDC.
"

So probably the same thing only different


Presumably the rest of mu mini how to sounds ok?



PeterG.

[PeterG]

Good info, thanks.


I have had a look on the 5.5 up6 server I have here and the same smbpasswd -S is documented as per the 6.0.

I will rebuild the new server as a 5.5 and then try the howto.

Fingers crossed.


PeterG.

[ryan]

This discussion has been helpful for me to understand the problem.

If a simple upgrade from 5.6 to 6.0 keeping the same computer, what must I copy from the 5.6 prior to upgrading so I can copy it back?

ryan

[PeterG]

Only had a chance to very quickly test this and i believe most of it worked, a client was able to login but it then failed when trying to write some sort of file during the login process. I hadn't created any home directories, etc!

Looks promising though, will try again tomorrow.

PeterG.

[Alex]

I'm agree. In this case I have migrating from PDC to PDC. I have executed smbpasswd -S and then have copied secrets.tdb to new machine. Yes, it was in such order. In result I have identical SID by both machines. But in this case it is not clear, why date of change of a secrets.tdb in my case not yesterday's number, and much earlier? I think, that if smbpasswd is carried out on PDC in secrets.tdb it is written nothing. It works only if PDC other machine is. In my case of the machine were not connected to a network simultaneously at executing smbpasswd -S.

[PeterG]

What I failed to remember, is that sme holds user data in its own configuration. doh.

i.e. when looking in the users panel in server-manager, nothing appears even though there are users in the passwd file.

Anyone know what the path is for the e-smith configuration database thingy.

PeterG.

[PeterG]

Right then,

making progress, I think

I used this to migrate the users

http://www.tech-geeks.org/contrib/loveless/batch_users/README-0.6.txt

There are entries in the e-smith accounts database for each maachine but it is one field for each PC.
e.g.
pc8$=machine

I am struggling to get the format correct to get these entries into the database. Anyone help?

After this I think all it needs are the entries from each of the passwd and group (+shadows) files appended and then that might work...

PeterG.

[Loek]

Hi,

I finally succeeded to get the clients in my test environment login to the new installed 6.0 server and keep their old user profiles. The clients don't even notice that the server has been replaced. The secret is indeed copying the secrets.tdb file in /etc (beware: on 6.0 it has to go in /etc/samba !)

You should also set the name and IP of the new server identical to the old one (although have not tested if it would work if you don't).

If you had roaming profiles set to "No" under the workgroup settings using SME 5.5 or 5.6, then you probably were probably using roaming profiles for W2K/XP clients anyway because of a bug in those versions, see http://forums.contribs.org/index.php?topic=15867.msg61253#msg61253

For this situation, to keep the roaming profiles you should set Roaming Profiles to "Yes" and move each profile from
/home/e-smith/files/users/[username]/files/home/profiles/  to  /home/e-smith/files/samba/profiles/[username]/

To be sure to have all settings right, I created all users on 6.0 manually, then copied the data. Then I created the machine accounts using /sbin/e-smith/signal-event machine-account-create MachineName$
but this still required the machines to be added to /etc/samba/smbpasswd, with the same passwords as the had under 5.x (note: on 5.x smbpasswd is located in /etc, not in /etc/samba), but with the UID of the new machine accounts (check in e.g. /etc/passwd)

I works, but altogether it's a lengthy process. It's ok if you have about 10 users, but you don't want to be doing this for a 100 users or more, there may be an easier way. It looks like 6.0 stores user data in LDAP, is this documented somewhere?

Peter, are you moving to 5.6 or also trying to use 6.0? E-smith 5.5 stored the user account in /home/e-smith/accounts. I think replicating a server used to work under these versions if you transferred your data, the password files in /etc and then the files /home/e-smith/accounts and /home/e-smith/configuration (plus of course optional custom templates, installed updates, extensions, etc.) For 6.0 this won't do, but I hope to find an easier procedure than what I have now and then document it.

That's it for now,
Cheers
Loek