WINBINDD_SOCKET_DIR hardcoded
Dmitry Butskoy
buc at odusz.so-cdu.ru
Thu Oct 12 15:05:44 GMT 2006
Volker Lendecke wrote:
>On Thu, Oct 12, 2006 at 06:25:09PM +0400, Dmitry Butskoy wrote:
>
>
>>We had a task to cause a fileserver to work in two different domains
>>simultaneously. (Such a task was needed for gradual switching of clients
>>from the one domain to another, without global system's stopping etc.)
>>
>>Such a task requires two instances of Samba. One uses normal
>>config/lib/cache pathes, other uses an alternate.
>>
>>Samba has a good possibility to differ config file's path (-s option),
>>log file dir (-l), lock and pid directories ("lock directory", "pid
>>directory" in the config file). But one thing has remained unhandled --
>>it is now hardcoded WINBINDD_SOCKET_DIR path.
>>
>>
>
>Hardcoding that is deliberate. If you do a
>
>getent passwd <username>
>
>which winbind should that command connect to?
>
Use an option for pam_winbind, i.e.:
"auth required pam_winbind.so config=/etc/another_conf
try_first_pass " ...
>Winbind _is_
>a global resource,
>
If it is not a "religious postulate" :), then let it be not so global...
BTW, why then private sock is under alterable cache dir
(/var/cache/samba/winbindd_privileged)? ;)
> the migration scenario you are describing
>is correctly handled with Windows trust relationships.
>
>
Not in our case. We have NT domain (Samba) and AD domain, which cannot
be in NT-compatible mode.
Anyway, I am sure that such an option spoils nothing at all.
~buc
More information about the samba-technical
mailing list