On Thu, 3 May 2018 08:40:37 +0100 Rowland Penny via samba <samba at lists.samba.org> wrote:> On Wed, 2 May 2018 19:21:46 -0300 > "Ethy H. Brito" <ethy.brito at inexo.com.br> wrote: > > This is where it is all going wrong, Your PDC isn't using LDAP, so > you will have to rely on the winbind 'rid' backend. The lines below are > wrong in several ways:LDAP was not necessary back those days S3 was brought to life. Few users, few shares.> > > idmap uid = 100000-200000 > > idmap gid = 100000-200000 > > idmap cache time = 60 > > idmap config *:range = 100000-200000 > > idmap config *:backend = rid > > 'idmap uid' & 'idmap gid' are deprecated, you should use the 'idmap > config' linesThis is garbage from dozens of unfortunate tests I did. Sorry. I just Removed these lines.> The ranges overlap > You cannot use the 'rid' backend with the '*' domainOK. Noted.> You will never get the same IDs on the PDC and Unix domain member (this > isn't really a problem)I know that. But at least the returned uid should respect the "idmap config" displacement and always return the source uid plus a constant displacement. At least it is what I was expecting. Am I wrong?> > Try it like this: > > idmap config *:range = 3000-7999 > idmap config *:backend = tdb > idmap config PEGASE:range = 100000-200000 > idmap config PEGASE:backend = ridI got a small progress here. Now jgarcia uid is inside the "range". Thanks. S4# id jgarcia uid=103032(jgarcia) gid=100513(none) \ groups=100513(none),103032(jgarcia),101094(5p6l3d1$),\ 101119(jgomes-pc$),10001(BUILTIN\users) but "base" id does not match. jgarcia uid is 1094 at S3. I'd like it to be 101094 at S4. the group names which jgarcia belongs make no sense either (5p6l3d1$ ?!?! this one should be named jgarcia). Also, jgarcia's primary group changed from 1094 at S3 to 100513 at S4. This would not be a problem *if* rsync could "translate" uids during the copy. Remember I am migrating data from S3 to S4. It is much easier to correlate uid (or gid) 1094 with 101094 than to 103032. Is that possible S4 have learned garbage from my previous tests and stored it somewhere?? if so, can my mess be undone ? Suggestions?> > I feel I should also warn you that Microsoft is making it harder & > harder to use Windows with an NT4-style domain, you really should > consider upgrading to AD.This S3 server will be discontinued soon and this S4 will be promoted to AD, I hope! For the moment S4 is pulling data from S3 via rsync every 2 hours. I think any configurations for S4 may be changed/erased with no harm to the data, which must be preserved at S4. No user is accessing S4. All this is to make this migration transparent to the current users. There are a few dozens of PCs I do not want to deal, "rejoing" them to a new domain. This will take hours! Lots of. BTW, do you guys have a better way to migrate painlessly? Cheers Ethy
On Thu, 3 May 2018 10:17:48 -0300 "Ethy H. Brito via samba" <samba at lists.samba.org> wrote:> > You will never get the same IDs on the PDC and Unix domain member > > (this isn't really a problem) > > I know that. But at least the returned uid should respect the "idmap > config" displacement and always return the source uid plus a constant > displacement. At least it is what I was expecting. Am I wrong?No, you should get the same UID on the Unix domain member at all times, it will just be a different on to the PDC.> > > > > Try it like this: > > > > idmap config *:range = 3000-7999 > > idmap config *:backend = tdb > > idmap config PEGASE:range = 100000-200000 > > idmap config PEGASE:backend = rid > > I got a small progress here. Now jgarcia uid is inside the "range". > Thanks. > > S4# id jgarcia > uid=103032(jgarcia) gid=100513(none) \ > groups=100513(none),103032(jgarcia),101094(5p6l3d1$),\ > 101119(jgomes-pc$),10001(BUILTIN\users) > > but "base" id does not match. jgarcia uid is 1094 at S3.I am willing to bet the RID for 'jgarcia' is '3032' The winbind 'rid' backend uses this formula to calculate the ID: ID = RID + LOW_RANGE_ID> I'd like it to be 101094 at S4.OK, change their RID to '1094' on S3, though this will probably break something else ;-)> > the group names which jgarcia belongs make no sense either > (5p6l3d1$ ?!?! this one should be named jgarcia).This I don't understand.> > Also, jgarcia's primary group changed from 1094 at S3 to 100513 at S4.No it didn't, every windows users primary group is Domain Users and the RID for this is '513' (100000 + 513 = 100513)> > This would not be a problem *if* rsync could "translate" uids during > the copy. Remember I am migrating data from S3 to S4. > It is much easier to correlate uid (or gid) 1094 with 101094 than to > 103032.I thought rsync synced by name> > Is that possible S4 have learned garbage from my previous tests and > stored it somewhere?? if so, can my mess be undone ?possibly, try running 'net cache flush' on the S4 machine.> > Suggestions? > > > > > > I feel I should also warn you that Microsoft is making it harder & > > harder to use Windows with an NT4-style domain, you really should > > consider upgrading to AD. > > This S3 server will be discontinued soon and this S4 will be promoted > to AD, I hope! > > For the moment S4 is pulling data from S3 via rsync every 2 hours. > I think any configurations for S4 may be changed/erased with no harm > to the data, which must be preserved at S4. No user is accessing S4. > > All this is to make this migration transparent to the current users. > There are a few dozens of PCs I do not want to deal, "rejoing" them > to a new domain. This will take hours! Lots of.It might be easier in the long run to set up a new AD domain and move everything to that. Rowland
On Thu, 3 May 2018 15:07:30 +0100 Rowland Penny via samba <samba at lists.samba.org> wrote:> On Thu, 3 May 2018 10:17:48 -0300 > "Ethy H. Brito via samba" <samba at lists.samba.org> wrote: > > > > > You will never get the same IDs on the PDC and Unix domain member > > > (this isn't really a problem) > > > > I know that. But at least the returned uid should respect the "idmap > > config" displacement and always return the source uid plus a constant > > displacement. At least it is what I was expecting. Am I wrong? > > No, you should get the same UID on the Unix domain member at all times, > it will just be a different on to the PDC.I get the same uid all time but not the one I expect. I'd expect that idmap return "UNIX_UID + LOW_RANGE_ID" as the new uid. But as you said idmap uses RID instead. My mistaken thought. This leads me to another questions: and how RID is guessed at S3?? From a random number? RID=UID should be an educated guess, don't you think?> > I got a small progress here. Now jgarcia uid is inside the "range". > > Thanks. > > > > S4# id jgarcia > > uid=103032(jgarcia) gid=100513(none) \ > > groups=100513(none),103032(jgarcia),101094(5p6l3d1$),\ > > 101119(jgomes-pc$),10001(BUILTIN\users) > > > > but "base" id does not match. jgarcia uid is 1094 at S3. > > I am willing to bet the RID for 'jgarcia' is '3032'How do I check this at S3 command line ? Or even better, how do I list each and every SIDs for users and groups at S3?> > I'd like it to be 101094 at S4. > > OK, change their RID to '1094' on S3, though this will probably break > something else ;-)I am pretty sure it will break things.> > > > > the group names which jgarcia belongs make no sense either > > (5p6l3d1$ ?!?! this one should be named jgarcia). > > This I don't understand.The "id jgarcia" returns, among other groups, 101094(5p6l3d1$). 1094 is the UNIX primary group for user jgarcia. This group is named, at S3, "jgarcia", like the username. I'm inclined to think that this 1010194 is just a big coincidence and that number refer to another RID group not related to the jgarcia unix group 1094. And why this name "5p6l3d1$" is so messed up?? Where this came from? Other thing I do not get is why wbinfo does not returns all groups jgarcia is in. I mentioned this on first email of this tread. Why "id other_user" returns "no such user" for a bunch of users, been "other_user" obtained from "wbinfo -u"> > > > > Also, jgarcia's primary group changed from 1094 at S3 to 100513 at S4. > > No it didn't, every windows users primary group is Domain Users and > the RID for this is '513' (100000 + 513 = 100513)Make sense.> > > > > This would not be a problem *if* rsync could "translate" uids during > > the copy. Remember I am migrating data from S3 to S4. > > It is much easier to correlate uid (or gid) 1094 with 101094 than to > > 103032. > > I thought rsync synced by nameNope. It syncs uid/gid number based. So it would be very easy to write a script that changes the files/directories permissions that rsync writes, from UID 1019 (jgarcia) to uid 101019 *if* the SID was "UID + LOW_RANGE_ID". Cruel world!! I am pretty screwed here!> > > > > Is that possible S4 have learned garbage from my previous tests and > > stored it somewhere?? if so, can my mess be undone ? > > possibly, try running 'net cache flush' on the S4 machine.Nope. Same results.> > > > All this is to make this migration transparent to the current users. > > There are a few dozens of PCs I do not want to deal, "rejoing" them > > to a new domain. This will take hours! Lots of. > > It might be easier in the long run to set up a new AD domain and move > everything to that.This leads me to re-join every station. Not good!