storing our machine account name in secrets.tdb

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Volker Lendecke wrote:

> Gerald (Jerry) Carter wrote:
>> Volker,  Are you sure this is worth it?  I mean a
>> dhcp client that doesn't specify its name in smb.conf
>> is just broken in my opinion.  I consider this more
>> of a configuration error and covering over it might
>> cause more pain that is fixes.
> 
> Do you think so? I could imagine becoming more 
> robust if we store the correct account name we joined
> as in secrets.tdb. Can't say 100% why, but to me
> this just "feels" the right thing to do. Storing
> the hostname in secrets.tdb makes renaming
> a single step, the admin does not have to make sure
> that the smb.conf or hostname is correctly adapted.

Yeah but this only solves a problem with NTLM.  If
you start changing the hostname anyways I'd expect
a lot of Krb5 stuff to start failing anyways (inside
and outside of Samba).  If we were still in the NT4
domain model I'd probably be a little more easy going
on this.  But so many things in Krb5 rely on correctly
configured hostnames, playing these types of games
will I think only lead to more special cases in the
code.

Right now we rely on global_myname().  What you are
proposing will give us global_myname() and
global_myaccountname() which may or may not be the
same thing. And because of the possible inconsistency,
I believe that we will end up with things that
work most of the time (when the two values are
the same) but fail in corner cases that will be hard
to track down.

My belief is based on a lot of the problems we had
when dealing with winbindd on a Samba DC and when to use
the domain name (domain trust creds) and when to use
the machine name (domain member creds) in things
like the RPC bind and NTLMSSP exchanges.

>> I mean all systems I can think Linux or otherwise
>> allow you to decouple the hostname from the DHCP
>> address and name.
> 
> Sure, but fully taking care of the machine account 
> with all aspects ourselves takes away this duty
> from the admin. I'm not really enthusiastic about
> this change, so if you have real concerns it might
> destabilize things I might think about other solutions.

I think this could very easily start to get confusing.
Suppose we join as FOO with no name defined in smb.conf.
Later the admin decides to set the name BAR in smb.conf.
Users access \\BAR but we use FOO$ as our name?  Or does
the admin have to run some addition command to update
secrets.tdb and rename the account in the domain ?

Perhaps I'm in the minority in that I believe that
either an admin show be able to correctly configure
machines or else rely on a higher level tool that
configures the OS correctly.  And we should be able
to rely on that information rather than trying to
work around broken configurations all the time.

As much as we like to joke about it, Samba is not
an operating system.  I've had to deal with configuring
hostnames on enough Linux distros and proprietary
Unix platforms to know how different it can be.  And
as portable as Samba is, we're not that portable and
nor should we be reconfiguring the OS (e.g. /etc/hosts)
for the admin.  That is the job of management tools.  We
are plumbing.

I'll give you an example of what I mean.  Support
smbclient tries to connect to a remote CIFS server
and gets back a KRB5_ERR_CLOCK_SKEW.  Should it try
to sync the system clock somehow?  No.  The operating
system has to provides some means of clock synchronization
and we should rely on that.  If someone wants to write
an app that uses smbclient and would also sync the
system clock if necessary, that's great.  But it should
be their headache ant not ours.  Samba is enough of a
monolithic kitchen sink as it is now.

Of course, this is just my opinion.  If you have code
and things turn out to not as bad as I think they will
be, then I'll change my tune.  Or if a majority of people
think that the change would be beneficial, I'm just one
person and cannot/will not block it.

PS: I would be much more agreeable to the idea if we
were going our own distro and could actually control
the OS to a degree.




cheers, jerry
=====================================================================
Samba                                    ------- http://www.samba.org
Centeris                         -----------  http://www.centeris.com
"What man is a man who does not make the world better?"      --Balian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF9wOUIR7qMdg1EfYRAuOOAKDVgLYaAlXk9506NQbMPUysmuycZQCg5sYU
JOAWFY1mrj4XEbURP/PlHKw=
=34xr
-----END PGP SIGNATURE-----