On 17/06/2020 14:25, Nathaniel W. Turner via samba wrote:> I realize I never followed up with this. The problem here turned out to be > that I was doing a "reload" of the samba services (smb, nmb, winbind) to > pick up my ID mapping changes in smb.conf. Switching my test case to do a > "restart" instead resolved the issue.'reload' just makes the Samba service reload smb.conf after changes to it, it doesn't touch anything else> More details: > > The test case basically did the following: > 1. Join AD using "realm join --client-software=winbind ..." > 2. Reconfigure smb.conf based on a custom template (as shown in prior > emails).Why is 'realm' re-writing the smb.conf, this sounds like a major bug to me, perhaps there should either be another switch --smb-conf=do_not_touch, or realm shouldn't touch smb.conf if '--client-software=winbind' is set. The other option is to use what Samba provides: 'net ads join'> 3. Reload samba services. > 4. Log in as an AD user (or use wbinfo -i ...) > > The problem was a combination of a few things: > * Step 3 didn't completely eradicate the old idmapping configuration from > the runtime. It seems a "restart" is needed here.Probably if 'realm' wasn't so 'helpful', you wouldn't have this problem i.e. setup smb.conf before the join, the join doesn't change the smb.conf and everything works first time. Rowland
On Wed, Jun 17, 2020 at 9:53 AM Rowland penny via samba < samba at lists.samba.org> wrote:> On 17/06/2020 14:25, Nathaniel W. Turner via samba wrote: > > I realize I never followed up with this. The problem here turned out to > be > > that I was doing a "reload" of the samba services (smb, nmb, winbind) to > > pick up my ID mapping changes in smb.conf. Switching my test case to do a > > "restart" instead resolved the issue. > 'reload' just makes the Samba service reload smb.conf after changes to > it, it doesn't touch anything else >Yeah. It wasn't clear to me which smb.conf settings were picked up by a reload, and which required a restart. Most share configuration changes only appear to require a reload, but it seems idmap configuration changes require a restart (of the winbind service, at least).> Why is 'realm' re-writing the smb.conf, this sounds like a major bug to > me, perhaps there should either be another switch > --smb-conf=do_not_touch, or realm shouldn't touch smb.conf if > '--client-software=winbind' is set. The other option is to use what > Samba provides: 'net ads join' >Well, maybe. What 'realm' does here is mostly helpful, as it handles changing the security, workgroup, and related values as appropriate for the AD domain (and changes them back when you run "realm leave"). But it sets suboptimal (IMO) idmap config values, hence the need to rewrite smb.conf after the 'realm join'. Probably if 'realm' wasn't so 'helpful', you wouldn't have this problem> i.e. setup smb.conf before the join, the join doesn't change the > smb.conf and everything works first time. >Yes, I think that's accurate. =) n
On 17/06/2020 15:12, Nathaniel W. Turner via samba wrote:> Yeah. It wasn't clear to me which smb.conf settings were picked up by a > reload, and which required a restart. Most share configuration changes only > appear to require a reload, but it seems idmap configuration changes > require a restart (of the winbind service, at least).Well, yes that is true, but you normally would only set these once.>> Why is 'realm' re-writing the smb.conf, this sounds like a major bug to >> me, perhaps there should either be another switch >> --smb-conf=do_not_touch, or realm shouldn't touch smb.conf if >> '--client-software=winbind' is set. The other option is to use what >> Samba provides: 'net ads join' >> > Well, maybe. What 'realm' does here is mostly helpful, as it handles > changing the security, workgroup, and related values as appropriate for the > AD domain (and changes them back when you run "realm leave"). But it sets > suboptimal (IMO) idmap config values, hence the need to rewrite smb.conf > after the 'realm join'.OK, back to the 'do not touch smb.conf' switch> > Probably if 'realm' wasn't so 'helpful', you wouldn't have this problem >> i.e. setup smb.conf before the join, the join doesn't change the >> smb.conf and everything works first time. >> > Yes, I think that's accurate. =)Someone just needs to convince red hat to do that ;-) Rowland