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