RE: Winbindd limited by select
Good point about non-smbd processes being winbindd clients. I've got some myself :-) Also agreed about benefits of shutting down idle connections -- just not done yet. Ken Ken Cross Network Storage Solutions Phone 865.675.4070 ext 31 [EMAIL PROTECTED] -Original Message- From: Michael Steffens [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 15, 2003 11:46 AM To: Ken Cross Cc: 'Mike Sweet'; 'Multiple recipients of list SAMBA-TECHNICAL' Subject: Re: Winbindd limited by select Ken Cross wrote: > I was suggesting the other way around -- the number of winbindd fd's > shouldn't be more than the max # of smbd's (well, maybe a *few* more). But if you are having a system hard limit of 1024 FDs per process, for example, which you can't raise via setrlimit, you could only configure less than that number of smbds. Coupling these numbers does not make sense IMHO for another reason: Every process can become a winbind client, even without knowing about winbind or Samba, via NSS and PAM. How to take these into account? I think winbindd shutting down idle connections (not immediately, there may further requests come along quickly, and never if a connection carries a getpwent/getgrent status) is less trouble. Cheers! Michael
Re: Winbindd limited by select
Ken Cross wrote: I was suggesting the other way around -- the number of winbindd fd's shouldn't be more than the max # of smbd's (well, maybe a *few* more). But if you are having a system hard limit of 1024 FDs per process, for example, which you can't raise via setrlimit, you could only configure less than that number of smbds. Coupling these numbers does not make sense IMHO for another reason: Every process can become a winbind client, even without knowing about winbind or Samba, via NSS and PAM. How to take these into account? I think winbindd shutting down idle connections (not immediately, there may further requests come along quickly, and never if a connection carries a getpwent/getgrent status) is less trouble. Cheers! Michael
Re: Winbindd limited by select
Ken Cross wrote: My $0.02... Mike Sweet wrote: Sooo, my recommendations are as follows: 1. Provide a configure option (--with-maxfiles or similar) to configure the upper limit you want to support in SAMBA. 2. Provide a smb.conf option to control the max number of file descriptors. There's currently a "max smbd processes" in 3.0. Would that suffice for max number of fd's for winbindd? It might; I'm not sure how winbindd and smbd are tied together (I don't use it myself...) 3. Provide a definition on Solaris for FD_SETSIZE before including so that the correct version of select() is used. It's not just Solaris - I think it's fairly universal. And it must be defined before It doesn't work on Linux or OSX, and of the systems in our (ESP's) build farm (AIX, FreeBSD, HP-UX, IRIX, Linux, OSX, Solaris, and Tru64) only Solaris uses a different select() function when dealing with more than 1024 fd's. In this case, we are only setting FD_SETSIZE to get the right version of select, not to increase the size of fd_set. We could just #ifdef __sun and define select to select_large_fdset, however that is only appropriate for newer versions of Solaris (starting with 7 IIRC). 4. On startup, query the current FD limit and set it to the smaller of the "maxfiles" definition, the max value reported by the kernel, and the max value in smb.conf. And call setrlimit with this value. Right. 5. Allocate the fd_set buffers [(maxfiles + 7) / 8 bytes] and replace all use of FD_ZERO with memset/bzero with the correct size. It currently (and correctly, IMO) computes the largest *actual* fd and uses that. If you have that info, great. In CUPS, we just memcpy() a common input/output set to temporary ones (makes tracking FDs simpler...) -- __ Michael Sweet, Easy Software Products [EMAIL PROTECTED] Printing Software for UNIX http://www.easysw.com
RE: Winbindd limited by select
I was suggesting the other way around -- the number of winbindd fd's shouldn't be more than the max # of smbd's (well, maybe a *few* more). Ken -Original Message- From: Michael Steffens [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 15, 2003 11:18 AM To: Ken Cross Cc: 'Mike Sweet'; 'Multiple recipients of list SAMBA-TECHNICAL' Subject: Re: Winbindd limited by select Ken Cross wrote: > My $0.02... > > > Mike Sweet wrote: > >>Sooo, my recommendations are as follows: >> >>1. Provide a configure option (--with-maxfiles or similar) >> to configure the upper limit you want to support in SAMBA. >>2. Provide a smb.conf option to control the max number of >> file descriptors. > > > There's currently a "max smbd processes" in 3.0. Would that suffice > for max number of fd's for winbindd? I don't think so. It's not desireable to restrict the number of smbds to the number of FDs that winbindd can have simultanously, IMHO. Michael
Re: Winbindd limited by select
Michael Steffens wrote: Mike Sweet wrote: Sooo, my recommendations are as follows: 1. Provide a configure option (--with-maxfiles or similar) to configure the upper limit you want to support in SAMBA. 2. Provide a smb.conf option to control the max number of file descriptors. 3. Provide a definition on Solaris for FD_SETSIZE before including so that the correct version of select() is used. 4. On startup, query the current FD limit and set it to the smaller of the "maxfiles" definition, the max value reported by the kernel, and the max value in smb.conf. 5. Allocate the fd_set buffers [(maxfiles + 7) / 8 bytes] and replace all use of FD_ZERO with memset/bzero with the correct size. 6. Make sure all calls to FD_SET and FD_CLR are updated to not use "&set", since "set" is now allocated. Sounds good! And, for winbindd's client connections, shut down idle connections when the limit is about to be exceeded? Right. CUPS keeps track of the last activity for each client, and shuts down inactive connections after a configurable amount of time (30 seconds by default). Would need to also take FDs for TCP connections, TDBs, logs, etc into account. For CUPS we limit the number of network connections to 1/3 of the available file descriptors (to account for log files, pipes, IPP and other data files, and job processing; I'm sure there are other (more accurate) ways of tracking this, and for winbindd you'll likely have different requirements... -- __ Michael Sweet, Easy Software Products [EMAIL PROTECTED] Printing Software for UNIX http://www.easysw.com
Re: Winbindd limited by select
Ken Cross wrote: My $0.02... Mike Sweet wrote: Sooo, my recommendations are as follows: 1. Provide a configure option (--with-maxfiles or similar) to configure the upper limit you want to support in SAMBA. 2. Provide a smb.conf option to control the max number of file descriptors. There's currently a "max smbd processes" in 3.0. Would that suffice for max number of fd's for winbindd? I don't think so. It's not desireable to restrict the number of smbds to the number of FDs that winbindd can have simultanously, IMHO. Michael
RE: Winbindd limited by select
My $0.02... Mike Sweet wrote: > Sooo, my recommendations are as follows: > > 1. Provide a configure option (--with-maxfiles or similar) >to configure the upper limit you want to support in SAMBA. > 2. Provide a smb.conf option to control the max number of >file descriptors. There's currently a "max smbd processes" in 3.0. Would that suffice for max number of fd's for winbindd? > 3. Provide a definition on Solaris for FD_SETSIZE before >including so that the correct version of >select() is used. It's not just Solaris - I think it's fairly universal. And it must be defined before > 4. On startup, query the current FD limit and set it to the >smaller of the "maxfiles" definition, the max value >reported by the kernel, and the max value in smb.conf. And call setrlimit with this value. > 5. Allocate the fd_set buffers [(maxfiles + 7) / 8 bytes] >and replace all use of FD_ZERO with memset/bzero with >the correct size. It currently (and correctly, IMO) computes the largest *actual* fd and uses that. > 6. Make sure all calls to FD_SET and FD_CLR are updated to >not use "&set", since "set" is now allocated. Sure. Ken Ken Cross Network Storage Solutions Phone 865.675.4070 ext 31 [EMAIL PROTECTED]
Re: Winbindd limited by select
Mike Sweet wrote: Sooo, my recommendations are as follows: 1. Provide a configure option (--with-maxfiles or similar) to configure the upper limit you want to support in SAMBA. 2. Provide a smb.conf option to control the max number of file descriptors. 3. Provide a definition on Solaris for FD_SETSIZE before including so that the correct version of select() is used. 4. On startup, query the current FD limit and set it to the smaller of the "maxfiles" definition, the max value reported by the kernel, and the max value in smb.conf. 5. Allocate the fd_set buffers [(maxfiles + 7) / 8 bytes] and replace all use of FD_ZERO with memset/bzero with the correct size. 6. Make sure all calls to FD_SET and FD_CLR are updated to not use "&set", since "set" is now allocated. Sounds good! And, for winbindd's client connections, shut down idle connections when the limit is about to be exceeded? Would need to also take FDs for TCP connections, TDBs, logs, etc into account. Michael
Re: Winbindd limited by select
Michael Steffens wrote: ... I'm wondering, basically concerning all platforms, whether this is about the size of fd_set, or about the number of FDs the kernel will actually assign to a process. If the latter one is not limited, wouldn't a single excessive FD consumer impact other processes? Some OS's have a hard limit (typically 1024 file descriptors, but some have a smaller limit), while others allow for greater numbers of file descriptors. In both cases, the current process file descriptor limit (see "man getrlimit" and "man setrlimit") is used to determine how many file descriptors are allowed/allocated. As for the actual memory footprint of a process, I don't know if most kernels use a static allocation or if they dynamically increase the size of the fd table as needed by the process... CUPS now uses getrlimit and setrlimit to query/manipulate the maximum number of file descriptors, and then allocates a fd_set buffer of the appropriate size for the number of file descriptors. The only platform we've had to make adjustments for has been MacOS X, which reports a rlim_max value of 2^32-1; our original implementation would then try to set the limit to that value and allocate fd_set's. Apple quickly pointed this out to us when they tested the latest CVS :), and we now have a configure-time maximum that is used as a limit when the kernel reports a larger maximum - this also allows us to tailor CUPS for smaller or larger servers, without impacting the default configuration (which continues to behave exactly as before...) Sooo, my recommendations are as follows: 1. Provide a configure option (--with-maxfiles or similar) to configure the upper limit you want to support in SAMBA. 2. Provide a smb.conf option to control the max number of file descriptors. 3. Provide a definition on Solaris for FD_SETSIZE before including so that the correct version of select() is used. 4. On startup, query the current FD limit and set it to the smaller of the "maxfiles" definition, the max value reported by the kernel, and the max value in smb.conf. 5. Allocate the fd_set buffers [(maxfiles + 7) / 8 bytes] and replace all use of FD_ZERO with memset/bzero with the correct size. 6. Make sure all calls to FD_SET and FD_CLR are updated to not use "&set", since "set" is now allocated. -- __ Michael Sweet, Easy Software Products [EMAIL PROTECTED] Printing Software for UNIX http://www.easysw.com
RE: Winbindd limited by select
Michael:
It's both. I hadn't mentioned it, but I also had to add this to
winbindd:
rlim.rlim_cur = 1500; // Files
rlim.rlim_max = rlim.rlim_cur;
stat = setrlimit( RLIMIT_NOFILE, &rlim );
if( stat != 0 ) DEBUG(0, ("Failed to set file limits: %s",
strerror(errno) ) );
The default file limit in NetBSD is 128, so that killed winbindd sooner
than the fd set.
However, in NetBSD, there's no real limit to the size of the fd set
passed in the select function. If it's larger than the size defined in
the kernel (256), the kernel just malloc's more to accommodate it. So
changing FD_SETSIZE in the calling program was sufficient to fix the
problem.
Ken
Ken Cross
Network Storage Solutions
Phone 865.675.4070 ext 31
[EMAIL PROTECTED]
-Original Message-
From: Michael Steffens [mailto:[EMAIL PROTECTED]]
Sent: Saturday, February 15, 2003 7:39 AM
To: David Collier-Brown -- Customer Engineering
Cc: [EMAIL PROTECTED]; Ken Cross; 'Multiple recipients of list
SAMBA-TECHNICAL'
Subject: Re: Winbindd limited by select
David Collier-Brown -- Customer Engineering wrote:
> Ken Cross wrote:
>
>>> #define FD_SETSIZE 2048 /* Max # of winbindd connections */
>>>
>>>must occur before the first invocation of .
>>>
>>>This could be a build option, but it might be much simpler to
>>>hard-code it in local.h, which is what I did to fix it.
>>>
>>>Can somebody check the implications of this on Solaris, HPUX, etc.?
>
>
> On Solaris, compiled as a 32-bit app, the limit
> applies. Compiled as a 64-bit app, you can have
> as many FDs as you want.
>
> However, there is currently no good reason to build
> Samba as a 64-bit app: it doesn't need a bigger
> address space.
I'm wondering, basically concerning all platforms, whether this is about
the size of fd_set, or about the number of FDs the kernel will actually
assign to a process.
If the latter one is not limited, wouldn't a single excessive FD
consumer impact other processes?
Cheers!
Michael
Re: Winbindd limited by select
David Collier-Brown -- Customer Engineering wrote: Ken Cross wrote: #define FD_SETSIZE 2048 /* Max # of winbindd connections */ must occur before the first invocation of . This could be a build option, but it might be much simpler to hard-code it in local.h, which is what I did to fix it. Can somebody check the implications of this on Solaris, HPUX, etc.? On Solaris, compiled as a 32-bit app, the limit applies. Compiled as a 64-bit app, you can have as many FDs as you want. However, there is currently no good reason to build Samba as a 64-bit app: it doesn't need a bigger address space. I'm wondering, basically concerning all platforms, whether this is about the size of fd_set, or about the number of FDs the kernel will actually assign to a process. If the latter one is not limited, wouldn't a single excessive FD consumer impact other processes? Cheers! Michael
Re: Winbindd limited by select
Michael Steffens wrote: Ken Cross wrote: There is pretty much a one-to-one correspondence between the number of smbd processes open (i.e. connected users) and winbindd file descriptors (per fstat). Hmm, it may be platform specific. smbd connects winbindd both directly and via NSS. On HP-UX it consumes two client pipes per smbd, and this might be due to linking libnss_winbind.1 with "-B symbolic", having symbols resolved locally, such that the two ways used by every smbd don't share client environment? It's just a guess. It seems correct, the behaviour is depending on how the NSS backend library was linked. Build libnss_winbind.1 without the linker option "-B symbolic" and, bingo, there is only one client connection per smbd. For the PAM module libpam_winbind.1 preferred local resolution of symbols with "-B symbolic" is still required to work properly. So optimally the two backend libraries should be linked differently. Cheers! Michael
Re: Winbindd limited by select
Ken Cross wrote: > > #define FD_SETSIZE 2048 /* Max # of winbindd connections */ > > > > must occur before the first invocation of . > > > > This could be a build option, but it might be much simpler to hard-code > > it in local.h, which is what I did to fix it. > > > > Can somebody check the implications of this on Solaris, HPUX, etc.? On Solaris, compiled as a 32-bit app, the limit applies. Compiled as a 64-bit app, you can have as many FDs as you want. However, there is currently no good reason to build Samba as a 64-bit app: it doesn't need a bigger address space. --dave -- David Collier-Brown, | Always do right. This will gratify Sun Microsystems DCMO | some people and astonish the rest. Toronto, Ontario | (905) 415-2849 or x52849 | [EMAIL PROTECTED]
Re: Winbindd limited by select
Ken Cross wrote: There is pretty much a one-to-one correspondence between the number of smbd processes open (i.e. connected users) and winbindd file descriptors (per fstat). Hmm, it may be platform specific. smbd connects winbindd both directly and via NSS. On HP-UX it consumes two client pipes per smbd, and this might be due to linking libnss_winbind.1 with "-B symbolic", having symbols resolved locally, such that the two ways used by every smbd don't share client environment? It's just a guess. I think forking would be counter-productive since winbindd caches so much stuff. A lot of it's in tdb files, though, so... Agreed. And as far as 2.2 is concerned, a complete restructuring doesn't make sense any more. One can improve robustness and scalability with less modifications. Frankly, I'm not sure what the smbd's are doing with winbindd after authentication. I have observed that they are looking up uid->sid and gid->sid mappings very frequently. Yes, even if the Windows client seems really idle (user left desk and does not read or write anything) such lookups are triggered at least once per minute for every client. The frequency increases when a user is working actively. Plus lookups of name->sid, "user in group", and so on, but these are far less frequent. The latter ones can't be cached easily, but the set of id mappings an smbd comes across can. There's another discussion looming about closing idle connections to winbindd. Is this a separate discussion? I would consider them related :) Andrew Esh wrote: Better yet: Have winbindd fork the same way smbd does, on a per-client basis. Someone should probably figure out what quality of the example network caused winbindd to consume so many sockets. Are there really that many requests being queued up at once? Shifting to a forking model would simply consume the same number and more processes. They are limited too. Winbind's client connections persist as long as the client processes are alive, and are waiting for further requests. Clients never explicitly close the pipe, even if they had only one lookup during their lifetime. This is fine, as it makes clients submitting multiple requests in a row more efficient. And it gives winbindd the chance to store get??ent states in the winbindd connection environment. But if connection consumption gets excessive, why not look around for idle clients, and shut them down? (Note, "idle" does not mean the client is idle, just that it doesn't presently send requests to winbindd.) We also need to be sure all the requests are making progress. If one gets hung, the client program would probably repeat the request, expending another instance of everything. Are there really 2048 users actively trying to make winbindd requests at the same time? This is very unlikely, even more with smbds caching id mappings. And client requests are always processed, even if the client connection has been shut down. Client gets a broken pipe error on send and retries, opening a new connection. Shutting down another one that has been idle for a long time, if we are still at threshold. It is the same as when you restart winbindd while clients are alive. They just reconnect as soon as they are having a new request. Very gracefully :) Perhaps this is the result of a very network-common failed NIS request, which falls through the passwd list in /etc/nsswitch.conf, and winds up asking winbindd about the same non-existent user. What is the content of the requests, and is there some way to fix the system so the users don't cause them to be issued at such a high rate? Should they even be forwarded to winbindd at all? In such situations you will most probably see only one client connection carrying many requests (if there is one process failing on many users), or client connections popping up and going away rapidly (if there are many processes failing on one user each). Neither of them is a big problem for file descriptor consumption. Maybe winbindd is piling up requests as it searches for a domain controller at the head of its "password server" list which is no longer working, or is no longer in DNS. Reorder that list, and winbindd might begin to process requests fast enough to stay ahead of the influx rate. No, winbindd is working happily and rapidly (well, most of the time, and if it isn't permanently kept busy with id mapping lookups :). It's the unused socket file descriptors which pile up. They do not leak, but are presently unused. Cheers! Michael
RE: Winbindd limited by select
There is pretty much a one-to-one correspondence between the number of smbd processes open (i.e. connected users) and winbindd file descriptors (per fstat). I think forking would be counter-productive since winbindd caches so much stuff. A lot of it's in tdb files, though, so... Frankly, I'm not sure what the smbd's are doing with winbindd after authentication. There's another discussion looming about closing idle connections to winbindd. Ken Ken Cross Network Storage Solutions Phone 865.675.4070 ext 31 [EMAIL PROTECTED] -Original Message- From: Esh, Andrew [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 12, 2003 7:34 PM To: 'Martin Pool'; Michael Steffens Cc: Ken Cross; 'Multiple recipients of list SAMBA-TECHNICAL' Subject: RE: Winbindd limited by select Better yet: Have winbindd fork the same way smbd does, on a per-client basis. Someone should probably figure out what quality of the example network caused winbindd to consume so many sockets. Are there really that many requests being queued up at once? Shifting to a forking model would simply consume the same number and more processes. They are limited too. We also need to be sure all the requests are making progress. If one gets hung, the client program would probably repeat the request, expending another instance of everything. Are there really 2048 users actively trying to make winbindd requests at the same time? Perhaps this is the result of a very network-common failed NIS request, which falls through the passwd list in /etc/nsswitch.conf, and winds up asking winbindd about the same non-existent user. What is the content of the requests, and is there some way to fix the system so the users don't cause them to be issued at such a high rate? Should they even be forwarded to winbindd at all? Maybe winbindd is piling up requests as it searches for a domain controller at the head of its "password server" list which is no longer working, or is no longer in DNS. Reorder that list, and winbindd might begin to process requests fast enough to stay ahead of the influx rate. > -Original Message- > From: Martin Pool [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 12, 2003 5:56 PM > To: Michael Steffens > Cc: Ken Cross; 'Multiple recipients of list SAMBA-TECHNICAL' > Subject: Re: Winbindd limited by select > > > On 12 Feb 2003, Michael Steffens <[EMAIL PROTECTED]> wrote: > > > It's 60 by default after installation, but is tunable (with reboot). > > Maybe hp should sell per-fd licences :-/ > > > The solution (and this should also work on other platforms) was to > > have winbindd housekeep its client connections by shutting down idle > > connections, and have clients reconnect when required: > > > > > http://lists.samba.org/pipermail/samba-technical/2003-February /042210.html > > The threshold was chosen to be 100 active connections, which keeps > winbindd well below 300 FDs. Below 140, actually, including network > sockets and open database and log files. I wonder how well it would work to have one winbindd process per n clients, in addition to shutting down idle clients... -- Martin
RE: Winbindd limited by select
Better yet: Have winbindd fork the same way smbd does, on a per-client basis. Someone should probably figure out what quality of the example network caused winbindd to consume so many sockets. Are there really that many requests being queued up at once? Shifting to a forking model would simply consume the same number and more processes. They are limited too. We also need to be sure all the requests are making progress. If one gets hung, the client program would probably repeat the request, expending another instance of everything. Are there really 2048 users actively trying to make winbindd requests at the same time? Perhaps this is the result of a very network-common failed NIS request, which falls through the passwd list in /etc/nsswitch.conf, and winds up asking winbindd about the same non-existent user. What is the content of the requests, and is there some way to fix the system so the users don't cause them to be issued at such a high rate? Should they even be forwarded to winbindd at all? Maybe winbindd is piling up requests as it searches for a domain controller at the head of its "password server" list which is no longer working, or is no longer in DNS. Reorder that list, and winbindd might begin to process requests fast enough to stay ahead of the influx rate. > -Original Message- > From: Martin Pool [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 12, 2003 5:56 PM > To: Michael Steffens > Cc: Ken Cross; 'Multiple recipients of list SAMBA-TECHNICAL' > Subject: Re: Winbindd limited by select > > > On 12 Feb 2003, Michael Steffens <[EMAIL PROTECTED]> wrote: > > > It's 60 by default after installation, but is tunable (with reboot). > > Maybe hp should sell per-fd licences :-/ > > > The solution (and this should also work on other platforms) was to > > have winbindd housekeep its client connections by shutting down > > idle connections, and have clients reconnect when required: > > > > > http://lists.samba.org/pipermail/samba-technical/2003-February /042210.html > > The threshold was chosen to be 100 active connections, which keeps > winbindd well below 300 FDs. Below 140, actually, including network > sockets and open database and log files. I wonder how well it would work to have one winbindd process per n clients, in addition to shutting down idle clients... -- Martin
Re: Winbindd limited by select
On 12 Feb 2003, Michael Steffens <[EMAIL PROTECTED]> wrote: > It's 60 by default after installation, but is tunable (with reboot). Maybe hp should sell per-fd licences :-/ > The solution (and this should also work on other platforms) was to > have winbindd housekeep its client connections by shutting down > idle connections, and have clients reconnect when required: > > http://lists.samba.org/pipermail/samba-technical/2003-February/042210.html > > The threshold was chosen to be 100 active connections, which keeps > winbindd well below 300 FDs. Below 140, actually, including network > sockets and open database and log files. I wonder how well it would work to have one winbindd process per n clients, in addition to shutting down idle clients... -- Martin msg06032/pgp0.pgp Description: PGP signature
Re: Winbindd limited by select
On Wed, Feb 12, 2003 at 10:23:14PM +, [EMAIL PROTECTED] wrote: > > Better still why not use poll() instead of select() in the winbindd > > main loop? > > Because not everyone has poll() :-(. Some have poll build on select. > Some people have poll() and it doesn't work So many bugs, so > little time... :-). OK so theoretically we could use poll() if it's there or fall back to select() modulo an unknown number of bugs on an unknown number of systems. It does sound like a lot of work doesn't it? )-: Tim.
Re: Winbindd limited by select
On Thu, Feb 13, 2003 at 09:03:54AM +1100, Tim Potter wrote: > On Wed, Feb 12, 2003 at 04:26:21PM -0500, Michael B. Allen wrote: > > > > This is set at compile-time, not run-time. This line: > > > > > > #define FD_SETSIZE 2048 /* Max # of winbindd connections */ > > > > > > must occur before the first invocation of . > > > > > > This could be a build option, but it might be much simpler to hard-code > > > it in local.h, which is what I did to fix it. > > > > Better still add a check to see if the limit has been reached and return > > an error. > > Better still why not use poll() instead of select() in the winbindd > main loop? Because not everyone has poll() :-(. Some have poll build on select. Some people have poll() and it doesn't work So many bugs, so little time... :-). Jeremy.
Re: Winbindd limited by select
On Wed, Feb 12, 2003 at 04:26:21PM -0500, Michael B. Allen wrote: > > This is set at compile-time, not run-time. This line: > > > > #define FD_SETSIZE 2048 /* Max # of winbindd connections */ > > > > must occur before the first invocation of . > > > > This could be a build option, but it might be much simpler to hard-code > > it in local.h, which is what I did to fix it. > > Better still add a check to see if the limit has been reached and return > an error. Better still why not use poll() instead of select() in the winbindd main loop? Tim.
RE: Winbindd limited by select
We should probably do both. IMO, 256 (the default in NetBSD) is wy too low and we should have a way to increase it. OTOH, if something goes nuts, it should detect the fact that too many connections have occurred and log the error. Ken Ken Cross Network Storage Solutions Phone 865.675.4070 ext 31 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Michael B. Allen Sent: Wednesday, February 12, 2003 4:26 PM To: Ken Cross Cc: [EMAIL PROTECTED] Subject: Re: Winbindd limited by select On Wed, 12 Feb 2003 07:36:19 -0500 "Ken Cross" <[EMAIL PROTECTED]> wrote: > I've run into a problem with winbindd in both 2.2.x and 3.0 where it > just locks up after a while on large, busy networks. > > We finally tracked down the problem to the fact that the C library > "select" function is limited by default to 256 file descriptors in > NetBSD (1024 in FreeBSD, 2048 in Linux). So once 256 (or whatever) > smbd processes connected to winbindd, it broke pretty badly and was > very hard to kill. > > This is set at compile-time, not run-time. This line: > > #define FD_SETSIZE 2048 /* Max # of winbindd connections */ > > must occur before the first invocation of . > > This could be a build option, but it might be much simpler to > hard-code it in local.h, which is what I did to fix it. Better still add a check to see if the limit has been reached and return an error. Mike -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived.
Re: Winbindd limited by select
On Wed, 12 Feb 2003 07:36:19 -0500 "Ken Cross" <[EMAIL PROTECTED]> wrote: > I've run into a problem with winbindd in both 2.2.x and 3.0 where it > just locks up after a while on large, busy networks. > > We finally tracked down the problem to the fact that the C library > "select" function is limited by default to 256 file descriptors in > NetBSD (1024 in FreeBSD, 2048 in Linux). So once 256 (or whatever) smbd > processes connected to winbindd, it broke pretty badly and was very hard > to kill. > > This is set at compile-time, not run-time. This line: > > #define FD_SETSIZE 2048 /* Max # of winbindd connections */ > > must occur before the first invocation of . > > This could be a build option, but it might be much simpler to hard-code > it in local.h, which is what I did to fix it. Better still add a check to see if the limit has been reached and return an error. Mike -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived.
Re: Winbindd limited by select
On Wed, Feb 12, 2003 at 07:36:19AM -0500, Ken Cross wrote: > Samba-folk: > > I've run into a problem with winbindd in both 2.2.x and 3.0 where it > just locks up after a while on large, busy networks. > > We finally tracked down the problem to the fact that the C library > "select" function is limited by default to 256 file descriptors in > NetBSD (1024 in FreeBSD, 2048 in Linux). So once 256 (or whatever) smbd > processes connected to winbindd, it broke pretty badly and was very hard > to kill. > > This is set at compile-time, not run-time. This line: > > #define FD_SETSIZE 2048 /* Max # of winbindd connections */ > > must occur before the first invocation of . > > This could be a build option, but it might be much simpler to hard-code > it in local.h, which is what I did to fix it. > > Can somebody check the implications of this on Solaris, HPUX, etc.? Great catch ! I'll fix this asap ! Jeremy.
RE: winbindd losing trust relationship once in a while (Samba 3.0)
> -Original Message- > From: Ken Cross [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 12, 2003 3:41 PM > To: Nir Soffer; 'Tim Potter'; [EMAIL PROTECTED] > Subject: RE: winbindd losing trust relationship once in a > while (Samba 3.0) > > > The patch works on SAMBA_3_0 as of 5 minutes ago. How did > you patch it > manually? Well, I looked at the patch saw that it moves the static variable last_scan outside of the function and inserted the last_scan = 0 wherever it should be. > The messages you see below are normal and don't indicate any real > problems. Except the fact that wbinfo -u didn't work. Downloading the CVS again, this is what I got when I ran wbinfo -u (without any patch) 2003/02/12 18:15:37, 6] rpc_parse/parse_prs.c:prs_debug(81) 18 smb_io_pol_hnd domain_pol [2003/02/12 18:15:37, 5] rpc_parse/parse_prs.c:prs_uint32(592) 0018 data1: [2003/02/12 18:15:37, 5] rpc_parse/parse_prs.c:prs_uint32(592) 001c data2: [2003/02/12 18:15:37, 5] rpc_parse/parse_prs.c:prs_uint16(563) 0020 data3: [2003/02/12 18:15:37, 5] rpc_parse/parse_prs.c:prs_uint16(563) 0022 data4: [2003/02/12 18:15:37, 5] rpc_parse/parse_prs.c:prs_uint8s(679) 0024 data5: 00 00 00 00 00 00 00 00 [2003/02/12 18:15:37, 5] rpc_parse/parse_prs.c:prs_ntstatus(621) 002c status: NT_STATUS_INVALID_PARAMETER [2003/02/12 18:15:37, 10] nsswitch/winbindd.c:client_write(460) client_write: wrote 1300 bytes. [2003/02/12 18:15:37, 10] nsswitch/winbindd.c:winbind_client_read(414) client_read: read 0 bytes. Need 1312 more for a full request. [2003/02/12 18:15:37, 5] nsswitch/winbindd.c:winbind_client_read(419) read failed on sock 12, pid 6200: EOF > Ken -- Nir Soffer -=- Software Engineer, Exanet Inc. -=- "The poor little kittens; They lost their mittens; And now you all must die. Mew, Mew, Mew, Mew, And now you all must die." www.sluggy.com, 24/10/02 > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] amba.org] On Behalf Of Nir Soffer Sent: Wednesday, February 12, 2003 8:15 AM To: Tim Potter; [EMAIL PROTECTED] Subject: RE: winbindd losing trust relationship once in a while (Samba 3.0) [snip] > > I wonder whether the trusted domains patch that went by today > fixes this > as well? Would you mind trying it? Since the patch doesn't apply to a20, and I couldn't be bothered to check why properly - I downloaded the CVS version, for the hell of it. The patch didn't apply to that either, so I did it manually. Both before and after the patch, not only did the trusted domains not work, but I couldn't do a wbinfo -u that worked. This snippet probably explains why: [2003/02/12 15:14:42, 10] nsswitch/winbindd.c:winbind_client_read(414) client_read: read 1312 bytes. Need 0 more for a full request. [2003/02/12 15:14:42, 10] nsswitch/winbindd.c:process_request(297) process_request: request fn LIST_USERS [2003/02/12 15:14:42, 3] nsswitch/winbindd_user.c:winbindd_list_users(533) [21233]: list users [2003/02/12 15:14:42, 10] nsswitch/winbindd.c:client_write(460) client_write: wrote 1300 bytes. [2003/02/12 15:14:42, 10] nsswitch/winbindd.c:winbind_client_read(414) client_read: read 0 bytes. Need 1312 more for a full request. [2003/02/12 15:14:42, 5] nsswitch/winbindd.c:winbind_client_read(419) read failed on sock 12, pid 21233: EOF So, sorry, but that doesn't seem to work. Alpha 20 was the last version that actually worked for me... -- Nir Soffer -=- Software Engineer, Exanet Inc. -=- "The poor little kittens; They lost their mittens; And now you all must die. Mew, Mew, Mew, Mew, And now you all must die." www.sluggy.com, 24/10/02>
Re: Winbindd limited by select
Hi Ken, Ken Cross wrote: I've run into a problem with winbindd in both 2.2.x and 3.0 where it just locks up after a while on large, busy networks. We finally tracked down the problem to the fact that the C library "select" function is limited by default to 256 file descriptors in NetBSD (1024 in FreeBSD, 2048 in Linux). So once 256 (or whatever) smbd processes connected to winbindd, it broke pretty badly and was very hard to kill. This is set at compile-time, not run-time. This line: #define FD_SETSIZE 2048 /* Max # of winbindd connections */ must occur before the first invocation of . This could be a build option, but it might be much simpler to hard-code it in local.h, which is what I did to fix it. Can somebody check the implications of this on Solaris, HPUX, etc.? This will hardly do on HP-UX, because there is a kernel parameter "maxfiles" controlling the per-process max number of filedescriptors. It's 60 by default after installation, but is tunable (with reboot). I would not recommend to set it too high, since it's also a fuse against single user processes eating up all available file descriptors (controlled by nfiles). We have hit the limit *very* quickly on our Winbind production box, of course, and I have increased maxfiles to 300. Still quite low when expecting a couple of hundret smbd to become winbind clients. Each of them consuming two FDs. The solution (and this should also work on other platforms) was to have winbindd housekeep its client connections by shutting down idle connections, and have clients reconnect when required: http://lists.samba.org/pipermail/samba-technical/2003-February/042210.html The threshold was chosen to be 100 active connections, which keeps winbindd well below 300 FDs. Below 140, actually, including network sockets and open database and log files. This only works out well if clients don't connect too frequently, however, and http://lists.samba.org/pipermail/samba-technical/2003-February/042170.html helped achieving this. I'm tracking winbindd shutting down sockets for about a week now, and have extended the DEBUG line in remove_idle_client() to also print idle time of removal candidates. With about 100 concurrent smbds (i.e. ~200 client pipes) it almost always finds connections idle for more than an hour. I would assume forcing these to reconnect should have no measurable impact, and the solution should scale to a multitude of its current load. It can't be applied directly to 3.0, however. I'm assuming that identifying idle connections is more complicated there, as both read and write buffers can be empty while waiting for a request to complete. But it should nevertheless be possible. Cheers! Michael
RE: winbindd losing trust relationship once in a while (Samba 3.0)
The patch works on SAMBA_3_0 as of 5 minutes ago. How did you patch it manually? The messages you see below are normal and don't indicate any real problems. Ken -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Nir Soffer Sent: Wednesday, February 12, 2003 8:15 AM To: Tim Potter; [EMAIL PROTECTED] Subject: RE: winbindd losing trust relationship once in a while (Samba 3.0) [snip] > > I wonder whether the trusted domains patch that went by today > fixes this > as well? Would you mind trying it? Since the patch doesn't apply to a20, and I couldn't be bothered to check why properly - I downloaded the CVS version, for the hell of it. The patch didn't apply to that either, so I did it manually. Both before and after the patch, not only did the trusted domains not work, but I couldn't do a wbinfo -u that worked. This snippet probably explains why: [2003/02/12 15:14:42, 10] nsswitch/winbindd.c:winbind_client_read(414) client_read: read 1312 bytes. Need 0 more for a full request. [2003/02/12 15:14:42, 10] nsswitch/winbindd.c:process_request(297) process_request: request fn LIST_USERS [2003/02/12 15:14:42, 3] nsswitch/winbindd_user.c:winbindd_list_users(533) [21233]: list users [2003/02/12 15:14:42, 10] nsswitch/winbindd.c:client_write(460) client_write: wrote 1300 bytes. [2003/02/12 15:14:42, 10] nsswitch/winbindd.c:winbind_client_read(414) client_read: read 0 bytes. Need 1312 more for a full request. [2003/02/12 15:14:42, 5] nsswitch/winbindd.c:winbind_client_read(419) read failed on sock 12, pid 21233: EOF So, sorry, but that doesn't seem to work. Alpha 20 was the last version that actually worked for me... -- Nir Soffer -=- Software Engineer, Exanet Inc. -=- "The poor little kittens; They lost their mittens; And now you all must die. Mew, Mew, Mew, Mew, And now you all must die." www.sluggy.com, 24/10/02>
RE: Winbindd limited by select
On HP-UX 11.x, the default is 2048 for FD_SETSIZE. You can also (according to man page for select()) handle this dynamically, if you are concerned for memory footprint for your application. An example from the man page: The user can also allocate the space for fd_set structure dynamically, depending upon the number of file descriptors to be tested. The following code segment illustrates the basic concepts. int num_of_fds,s; struct fd_set *f; /* * Set num_of_fds to the required value. * User can set it to the maximum possible value the kernel is * configured for, by using sysconf(_SC_OPEN_MAX). * Note that, if you are not using these many files, you are * wasting too much space. */ num_of_fds = sysconf(_SC_OPEN_MAX); s = sizeof(long); /* * howmany is a macro defined in sys/types.h */ f = (struct fd_set *)malloc(s*howmany(num_of_fds, s*8); /* * Use f wherever struct fd_set * is used. * It can be used to test num_of_fds file descriptors. */ So, might be a couple of ways to skin this cat :-) (I don't mean literally, for all you cat lovers out there!) Don > -Original Message- > From: Ken Cross [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 12, 2003 7:36 > To: 'Multiple recipients of list SAMBA-TECHNICAL' > Subject: Winbindd limited by select > > > Samba-folk: > > I've run into a problem with winbindd in both 2.2.x and 3.0 where it > just locks up after a while on large, busy networks. > > We finally tracked down the problem to the fact that the C library > "select" function is limited by default to 256 file descriptors in > NetBSD (1024 in FreeBSD, 2048 in Linux). So once 256 (or > whatever) smbd > processes connected to winbindd, it broke pretty badly and > was very hard > to kill. > > This is set at compile-time, not run-time. This line: > > #define FD_SETSIZE 2048 /* Max # of winbindd connections */ > > must occur before the first invocation of . > > This could be a build option, but it might be much simpler to > hard-code > it in local.h, which is what I did to fix it. > > Can somebody check the implications of this on Solaris, HPUX, etc.? > > Thanks, > Ken Cross > Network Storage Solutions >
RE: winbindd losing trust relationship once in a while (Samba 3.0)
[snip] > > I wonder whether the trusted domains patch that went by today > fixes this > as well? Would you mind trying it? Since the patch doesn't apply to a20, and I couldn't be bothered to check why properly - I downloaded the CVS version, for the hell of it. The patch didn't apply to that either, so I did it manually. Both before and after the patch, not only did the trusted domains not work, but I couldn't do a wbinfo -u that worked. This snippet probably explains why: [2003/02/12 15:14:42, 10] nsswitch/winbindd.c:winbind_client_read(414) client_read: read 1312 bytes. Need 0 more for a full request. [2003/02/12 15:14:42, 10] nsswitch/winbindd.c:process_request(297) process_request: request fn LIST_USERS [2003/02/12 15:14:42, 3] nsswitch/winbindd_user.c:winbindd_list_users(533) [21233]: list users [2003/02/12 15:14:42, 10] nsswitch/winbindd.c:client_write(460) client_write: wrote 1300 bytes. [2003/02/12 15:14:42, 10] nsswitch/winbindd.c:winbind_client_read(414) client_read: read 0 bytes. Need 1312 more for a full request. [2003/02/12 15:14:42, 5] nsswitch/winbindd.c:winbind_client_read(419) read failed on sock 12, pid 21233: EOF So, sorry, but that doesn't seem to work. Alpha 20 was the last version that actually worked for me... -- Nir Soffer -=- Software Engineer, Exanet Inc. -=- "The poor little kittens; They lost their mittens; And now you all must die. Mew, Mew, Mew, Mew, And now you all must die." www.sluggy.com, 24/10/02>
RE: winbindd losing trust relationship once in a while (Samba 3.0)
That patch (or the one that Tim is submitting) should fix it. Without it, the wbinfo -m action clears the trusted domain list, but it get restored within 5 minutes. Note that the patch is to the cvs version -- it may need tweaking for a20 or a21. Ken -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Tim Potter Sent: Wednesday, February 12, 2003 5:55 AM To: Nir Soffer Cc: [EMAIL PROTECTED] Subject: Re: winbindd losing trust relationship once in a while (Samba 3.0) On Wed, Feb 12, 2003 at 10:47:38AM +0200, Nir Soffer wrote: > Scenario: Fresh compile of Samba 3.0, both a20 and a21. Attempt to use > attached smb.conf. > > EXANET-QA is a part of the EXANET-IL domain (e.g - EXANET-IL is the > parent domain). EXANET-QA is supposedly set in compatibility mode. > > Under certain combinations winbindd seems to be losing it's capability > to contact the parent DC. > > Samba 3.0a20 works, spordically, unless you do some things (wbinfo -m, > see below). Samba 3.0a21 doesn't work at all for me. > > Attached are level 10 logs. I wonder whether the trusted domains patch that went by today fixes this as well? Would you mind trying it? http://lists.samba.org/pipermail/samba-technical/2003-February/042367.ht ml Tim.
Re: winbindd losing trust relationship once in a while (Samba 3.0)
On Wed, Feb 12, 2003 at 10:47:38AM +0200, Nir Soffer wrote: > Scenario: Fresh compile of Samba 3.0, both a20 and a21. Attempt to use attached >smb.conf. > > EXANET-QA is a part of the EXANET-IL domain (e.g - EXANET-IL is the parent domain). >EXANET-QA is supposedly set in compatibility mode. > > Under certain combinations winbindd seems to be losing it's capability to contact >the parent DC. > > Samba 3.0a20 works, spordically, unless you do some things (wbinfo -m, see below). > Samba 3.0a21 doesn't work at all for me. > > Attached are level 10 logs. I wonder whether the trusted domains patch that went by today fixes this as well? Would you mind trying it? http://lists.samba.org/pipermail/samba-technical/2003-February/042367.html Tim.
Re: Winbindd problem enumerating lots of groups
On Sun, Jan 05, 2003 at 11:21:02PM -0500, Ken Cross wrote: > Sure, it isn't obvious. > > "start" isn't where the list is in number of entries, it's an index into > some data structure (coming from the DC, I think). The num_entries > would increment by 513 (in my tests), but cli_samr_enum_dom_groups would > set start to 7509 after the first call. Basically, > cli_samr_enum_dom_groups must manage start once it's initialized to > zero. > > The symptoms that I saw were large numbers of duplicate group names. I > have ~2000 groups on this test server, but enum_groups returned > 9000. > It was because start only got incremented by 513 rather than 7509 each > time through the loop. > > Another good data point is the fact that it was broken before I changed > it and worked after. ;-) Understood - thanks ! I've applied it to 3.0 and HEAD. Thanks a *lot*, Jeremy.
RE: Winbindd problem enumerating lots of groups
Sure, it isn't obvious.
"start" isn't where the list is in number of entries, it's an index into
some data structure (coming from the DC, I think). The num_entries
would increment by 513 (in my tests), but cli_samr_enum_dom_groups would
set start to 7509 after the first call. Basically,
cli_samr_enum_dom_groups must manage start once it's initialized to
zero.
The symptoms that I saw were large numbers of duplicate group names. I
have ~2000 groups on this test server, but enum_groups returned > 9000.
It was because start only got incremented by 513 rather than 7509 each
time through the loop.
Another good data point is the fact that it was broken before I changed
it and worked after. ;-)
Ken
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of
[EMAIL PROTECTED]
Sent: Sunday, January 05, 2003 11:03 PM
To: Ken Cross
Cc: [EMAIL PROTECTED]
Subject: Re: Winbindd problem enumerating lots of groups
On Sun, Jan 05, 2003 at 07:22:33PM -0500, Ken Cross wrote:
> I found and fixed a problem where winbindd had trouble enumerating
> *lots* of groups (~2000 in my case). This is in SAMBA_3_0, but it's
> in other versions, too.
>
> The problem was in the enum_dom_groups routine in winbindd_rcp.c, line
> 153:
>
> do {
> struct acct_info *info2 = NULL;
> uint32 count = 0, start = *num_entries; <-- here
>
> "start" is being re-initialized every time through the loop. It
> mustn't be.
>
> The fix is easy - move it to the top of the routine a few lines up:
>
> uint32 start = 0;
Are you sure this is correct ? Yes, start is being initialized to
*num_entries (which starts at zero the first time through the
loop) but then at the bottom of the loop *num_entries is incremented as
so :
(*num_entries) += count;
So the next time around the loop start will be incremented
by count. It is then used as the next group index to fetch
in the call :
status = cli_samr_enum_dom_groups(hnd->cli, mem_ctx2,
&dom_pol,
&start,
0x, /* buffer
size? */
&info2, &count);
The current code looks correct to me. Can you explain better why you
think this is wrong ?
Thanks,
Jeremy.
Re: Winbindd problem enumerating lots of groups
On Sun, Jan 05, 2003 at 07:22:33PM -0500, Ken Cross wrote:
> I found and fixed a problem where winbindd had trouble enumerating
> *lots* of groups (~2000 in my case). This is in SAMBA_3_0, but it's in
> other versions, too.
>
> The problem was in the enum_dom_groups routine in winbindd_rcp.c, line
> 153:
>
> do {
> struct acct_info *info2 = NULL;
> uint32 count = 0, start = *num_entries; <-- here
>
> "start" is being re-initialized every time through the loop. It mustn't
> be.
>
> The fix is easy - move it to the top of the routine a few lines up:
>
> uint32 start = 0;
Are you sure this is correct ? Yes, start is being initialized
to *num_entries (which starts at zero the first time through the
loop) but then at the bottom of the loop *num_entries is incremented
as so :
(*num_entries) += count;
So the next time around the loop start will be incremented
by count. It is then used as the next group index to fetch
in the call :
status = cli_samr_enum_dom_groups(hnd->cli, mem_ctx2, &dom_pol,
&start,
0x, /* buffer size? */
&info2, &count);
The current code looks correct to me. Can you explain better
why you think this is wrong ?
Thanks,
Jeremy.
RE: winbindd & nscd on Solaris 2.7
Andrew, Killing nscd fixed the problem. thanks for the pointer Matt McC > Matthew McCowan wrote: >> >> running samba 2.2.5 on a solaris 2.7 with winbindd pointing to an NT4 >> PDC. >> >> Occasionally winbindd will hand out the wrong uid to a user trying to >> attach to the solaris box thru any PAM enabled service (telnet, smbd, >> ssh, etc). For example Alice will login to a shell using her normal >> credentials and winbindd will give her Bob's uid, even though "getent >> passwd" clearly shows Bob(uid)!=Alice(uid). >> >> The quick (not the track down bug and bludgeon it to death!) fix is to >> kill winbindd, stop the nscd (name service cache daemon) remove the >> winbindd_cache.tdb and restart winbindd (and optionally restart nscd). > > Some ideas in tracking it down: > > When it's 'broken', is is 'always broken'? That is, is it consistant? > In a different environment (ldap server with not so good indexes) I It's definitely cactus for any user trying to set up a new session. When I'm told it's gone toes up I usually test it by trying to ssh to it (PAM enabled sshd on the solaris box). I've got the keys setup so I should immediately get a bash shell, so if it asks for a password its a good indicator that its 'broke' > found problems with a user being there in an enumeration, but not for a > getpwnam(). In this vain, what does 'id Alice' and 'id Bob' give you, > and how do they compare to getent passwd. will test next time it happens > > Also, can you try and kill ncsd? After that, I would look into the as above > static cache in nss_winbind - depending on the desing of your ncsd, > there could be corruption of that structure. Cheers Matt McC
Re: winbindd & nscd on Solaris 2.7
> Matthew McCowan wrote: >> >> running samba 2.2.5 on a solaris 2.7 with winbindd pointing to an NT4 >> PDC. >> >> Occasionally winbindd will hand out the wrong uid to a user trying to >> attach to the solaris box thru any PAM enabled service (telnet, smbd, >> ssh, etc). For example Alice will login to a shell using her normal >> credentials and winbindd will give her Bob's uid, even though "getent >> passwd" clearly shows Bob(uid)!=Alice(uid). >> >> The quick (not the track down bug and bludgeon it to death!) fix is to >> kill winbindd, stop the nscd (name service cache daemon) remove the >> winbindd_cache.tdb and restart winbindd (and optionally restart nscd). > > Some ideas in tracking it down: > > When it's 'broken', is is 'always broken'? That is, is it consistant? > In a different environment (ldap server with not so good indexes) I It's definitely cactus for any user trying to set up a new session. When I'm told it's gone toes up I usually test it by trying to ssh to it (PAM enabled sshd on the solaris box). I've got the keys setup so I should immediately get a bash shell, so if it asks for a password its a good indicator that its 'broke' > found problems with a user being there in an enumeration, but not for a > getpwnam(). In this vain, what does 'id Alice' and 'id Bob' give you, > and how do they compare to getent passwd. will test next time it happens > > Also, can you try and kill ncsd? After that, I would look into the as above > static cache in nss_winbind - depending on the desing of your ncsd, > there could be corruption of that structure. Cheers Matt McC
Re: winbindd & nscd on Solaris 2.7
Matthew McCowan wrote: > > Howdy all, > > running samba 2.2.5 on a solaris 2.7 with winbindd pointing to an NT4 PDC. > > Occasionally winbindd will hand out the wrong uid to a user trying to attach > to the solaris box thru any PAM enabled service (telnet, smbd, ssh, etc). > For example Alice will login to a shell using her normal credentials and > winbindd will give her Bob's uid, even though "getent passwd" clearly shows > Bob(uid)!=Alice(uid). > > The quick (not the track down bug and bludgeon it to death!) fix is to kill > winbindd, stop the nscd (name service cache daemon) remove the > winbindd_cache.tdb and restart winbindd (and optionally restart nscd). > > I must say that the functionality provided by winbindd is nothing short of > fantastic. Open source single sign-on may finally be moving out of the realm > of myth and legend. Super effort! > > Guess I see if 2.2.6 has a fix ... Some ideas in tracking it down: When it's 'broken', is is 'always broken'? That is, is it consistant? In a different environment (ldap server with not so good indexes) I found problems with a user being there in an enumeration, but not for a getpwnam(). In this vain, what does 'id Alice' and 'id Bob' give you, and how do they compare to getent passwd. Also, can you try and kill ncsd? After that, I would look into the static cache in nss_winbind - depending on the desing of your ncsd, there could be corruption of that structure. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
Re: winbindd and missing 0x1c role on UNICAST_SUBNET
> Please check this out - thanks !
>
> Jeremy.
>
> Index: nmbd/nmbd_logonnames.c
> ===
> RCS file: /data/cvs/samba/source/nmbd/nmbd_logonnames.c,v
> retrieving revision 1.11
> diff -u -r1.11 nmbd_logonnames.c
> --- nmbd/nmbd_logonnames.c 30 Jan 2002 06:08:22 - 1.11
> +++ nmbd/nmbd_logonnames.c 8 Oct 2002 18:09:54 -
> @@ -109,6 +109,16 @@
>/* Tell the namelist writer to write out a change. */
>subrec->work_changed = True;
>
> + /*
> + * Add the WORKGROUP<1C> name to the UNICAST subnet with the IP address
> + * for this subnet so we will respond to queries on this name.
> + */
> + {
> + struct nmb_name nmbname;
> + make_nmb_name(&nmbname,global_myworkgroup,0x1c);
> + insert_permanent_name_into_unicast(subrec, &nmbname, 0x1c);
> + }
> +
>DEBUG(0,("become_logon_server_success: Samba is now a logon server \
> for workgroup %s on subnet %s\n", work->work_group, subrec->subnet_name));
> }
Works for me.Just out of curiousity, why couldn't you just use the
registered_name parameter handed into the function instead of remaking the
nmbname?
Thanks for the great work,
Kevin
Re: winbindd and missing 0x1c role on UNICAST_SUBNET
On Tue, Oct 08, 2002 at 09:39:29AM +0200, Volker Lendecke wrote:
> On Mon, Oct 07, 2002 at 05:35:35PM -0400, Kevin Stefanik wrote:
> > from log.nmbd:
> > process_node_status_request: status request for name U_MTPPI<1c> from IP
> > 192.168.92.56 on subnet UNICAST_SUBNET.
>
> I had the same problem, and patched nmbd a bit. I'm not sure it's
> the right fix, but here it is. Whoever is currently feeling authoritative
> of nmbd, feel free to commit it :-)
This is a very close fix - thanks. I think the correct fix may be below.
The difference between yours and this is that my fix only adds the name
into the unicast subnet once we've successfully claimed the 0x1c name,
and also adds the IP address of every interface we've claimed the name
on to the unicast subnet name record. This will allow us to respond with
all our interfaces, not just the primary one.
Please check this out - thanks !
Jeremy.
Index: nmbd/nmbd_logonnames.c
===
RCS file: /data/cvs/samba/source/nmbd/nmbd_logonnames.c,v
retrieving revision 1.11
diff -u -r1.11 nmbd_logonnames.c
--- nmbd/nmbd_logonnames.c 30 Jan 2002 06:08:22 - 1.11
+++ nmbd/nmbd_logonnames.c 8 Oct 2002 18:09:54 -
@@ -109,6 +109,16 @@
/* Tell the namelist writer to write out a change. */
subrec->work_changed = True;
+ /*
+ * Add the WORKGROUP<1C> name to the UNICAST subnet with the IP address
+ * for this subnet so we will respond to queries on this name.
+ */
+ {
+ struct nmb_name nmbname;
+ make_nmb_name(&nmbname,global_myworkgroup,0x1c);
+ insert_permanent_name_into_unicast(subrec, &nmbname, 0x1c);
+ }
+
DEBUG(0,("become_logon_server_success: Samba is now a logon server \
for workgroup %s on subnet %s\n", work->work_group, subrec->subnet_name));
}
Re: winbindd and missing 0x1c role on UNICAST_SUBNET
On Tue, 8 Oct 2002, Kevin Stefanik wrote: > Okay, then. I'm attaching what I'm using... I just moved your registration > line into the _success function so it gets called for each subnet (basically > subnet->ip) on which the server successfully registers 0x1c. I'll just hope > that 2.2.6 will have this fixed one way or another and I can go back to > (nearly) stock sambas. It will. Jeremy and I talked about it yesterday. expect a 2.2.6rc12 release so you can verify that everything is kosher. cheers, jerry
Re: winbindd and missing 0x1c role on UNICAST_SUBNET
Okay, then. I'm attaching what I'm using... I just moved your registration line into the _success function so it gets called for each subnet (basically subnet->ip) on which the server successfully registers 0x1c. I'll just hope that 2.2.6 will have this fixed one way or another and I can go back to (nearly) stock sambas. Thanks again, Kevin On Tuesday 08 October 2002 11:12 am, [EMAIL PROTECTED] wrote: > > I do have one question, though. If a samba PDC has multiple interfaces, > > would you want the PDC role registered with the PDC's ip on each > > interface? I think that would be accomplished if your > > insert_permanent_name_into_unicast were moved inside the subnet list > > loop, and called for each subnet instead of FIRST_SUBNET. Or maybe I > > don't understand how the unicast subnet works? > > Jerry and Jeremy will take care of that problem. I don't really understand > nmbd well enough. > > Volker --- ../samba-2.2.6pre2/source/nmbd/nmbd_logonnames.c Thu May 2 21:03:18 2002 +++ source/nmbd/nmbd_logonnames.c Tue Oct 8 11:32:18 2002 @@ -107,6 +107,9 @@ */ servrec->serv.type |= SV_TYPE_DOMAIN_CTRL; + /* register on unicast as well */ + insert_permanent_name_into_unicast(subrec, registered_name, 0x1c); + /* Tell the namelist writer to write out a change. */ subrec->work_changed = True;
Re: winbindd and missing 0x1c role on UNICAST_SUBNET
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > I do have one question, though. If a samba PDC has multiple interfaces, would > you want the PDC role registered with the PDC's ip on each interface? I > think that would be accomplished if your insert_permanent_name_into_unicast > were moved inside the subnet list loop, and called for each subnet instead of > FIRST_SUBNET. Or maybe I don't understand how the unicast subnet works? Jerry and Jeremy will take care of that problem. I don't really understand nmbd well enough. Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID ADE377D8, Fingerprint available: phone +49 551 370 iD8DBQE9ovX3ZeeQha3jd9gRApbkAJ4tRF3zWiShlsOaTuEDk/BZgrrORwCfZeoJ 7XNZqZKSeE3aAIDjjh8jxHE= =zzbg -END PGP SIGNATURE-
Re: winbindd and missing 0x1c role on UNICAST_SUBNET
That's a much cleaner solution than what I was proposing. Thanks.
I do have one question, though. If a samba PDC has multiple interfaces, would
you want the PDC role registered with the PDC's ip on each interface? I
think that would be accomplished if your insert_permanent_name_into_unicast
were moved inside the subnet list loop, and called for each subnet instead of
FIRST_SUBNET. Or maybe I don't understand how the unicast subnet works?
Thanks,
Kevin
On Tuesday 08 October 2002 03:39 am, Volker Lendecke wrote:
> On Mon, Oct 07, 2002 at 05:35:35PM -0400, Kevin Stefanik wrote:
> > from log.nmbd:
> > process_node_status_request: status request for name U_MTPPI<1c> from IP
> > 192.168.92.56 on subnet UNICAST_SUBNET.
>
> I had the same problem, and patched nmbd a bit. I'm not sure it's
> the right fix, but here it is. Whoever is currently feeling authoritative
> of nmbd, feel free to commit it :-)
>
> Volker
>
> diff -u -r1.11 nmbd_logonnames.c
> --- nmbd/nmbd_logonnames.c 30 Jan 2002 06:08:22 - 1.11
> +++ nmbd/nmbd_logonnames.c 6 Oct 2002 09:58:09 -
> @@ -139,6 +139,7 @@
> void add_logon_names(void)
> {
>struct subnet_record *subrec;
> + struct nmb_name nmbname;
>
>for (subrec = FIRST_SUBNET; subrec; subrec =
> NEXT_SUBNET_INCLUDING_UNICAST(subrec)) {
> @@ -146,7 +147,6 @@
>
> if (work && (work->log_state == LOGON_NONE))
> {
> - struct nmb_name nmbname;
>make_nmb_name(&nmbname,global_myworkgroup,0x1c);
>
>if (find_name_on_subnet(subrec, &nmbname, FIND_SELF_NAME) == NULL)
> @@ -162,4 +162,6 @@
>}
> }
>}
> + make_nmb_name(&nmbname,global_myworkgroup,0x1c);
> + insert_permanent_name_into_unicast(FIRST_SUBNET, &nmbname, 0x1c);
> }
Re: winbindd and missing 0x1c role on UNICAST_SUBNET
On Mon, Oct 07, 2002 at 05:35:35PM -0400, Kevin Stefanik wrote:
> from log.nmbd:
> process_node_status_request: status request for name U_MTPPI<1c> from IP
> 192.168.92.56 on subnet UNICAST_SUBNET.
I had the same problem, and patched nmbd a bit. I'm not sure it's
the right fix, but here it is. Whoever is currently feeling authoritative
of nmbd, feel free to commit it :-)
Volker
diff -u -r1.11 nmbd_logonnames.c
--- nmbd/nmbd_logonnames.c 30 Jan 2002 06:08:22 - 1.11
+++ nmbd/nmbd_logonnames.c 6 Oct 2002 09:58:09 -
@@ -139,6 +139,7 @@
void add_logon_names(void)
{
struct subnet_record *subrec;
+ struct nmb_name nmbname;
for (subrec = FIRST_SUBNET; subrec; subrec = NEXT_SUBNET_INCLUDING_UNICAST(subrec))
{
@@ -146,7 +147,6 @@
if (work && (work->log_state == LOGON_NONE))
{
- struct nmb_name nmbname;
make_nmb_name(&nmbname,global_myworkgroup,0x1c);
if (find_name_on_subnet(subrec, &nmbname, FIND_SELF_NAME) == NULL)
@@ -162,4 +162,6 @@
}
}
}
+ make_nmb_name(&nmbname,global_myworkgroup,0x1c);
+ insert_permanent_name_into_unicast(FIRST_SUBNET, &nmbname, 0x1c);
}
msg03575/pgp0.pgp
Description: PGP signature
Re: winbindd NTLMSSP helper
Henrik Nordström wrote: > > On Sun, 8 Sep 2002, Andrew Bartlett wrote: > > > For these I would much prefer (unless you have a very good reason) to > > just use PAM. That way we keep the number of interfaces down. (We have > > to maintain the PAM suff regardless). > > I would prefer if there was a "direct" alternative, not requiring PAM. > Mainly for simplicity of administration, but also because we have to > support some systems not using PAM... Yes, maintaining the squid stuff separate to the OS has it's advantages. > Btw, is it at all possible to build winbindd on systems not supporting PAM > and/or NSS? Yes, but it might not be there by default. Add --with-winbind in these cases. > > But if it just 'falls out' of the design (we will want one way to do > > plaintext, just for testing sanity) then it's fine. > > As the plaintext support will be needed anyway for testing I don't think > adding a couple of stream protocols for it will be much of a deal. It will just be a few extra helper functions, and a switch, so I suppose that's fine. > > For now, you guys 'own' the protocol but I don't mind either way. > > Ok. > > > > What about a also supporting a stream oriented NTLM mode? > > > > I don't see the need - most applications doing this so frequently that > > they need a stream mode are doing NTLMSSP anyway. Less interfaces > > again... > > Right. > > > That's what we need to do with a privileged pipe - the idea is to avoid > > needing to add a dependency on SO_PEERCRED. > > Either way is fine by me. > > Note: You still need smb.conf options to specify the required privileges.. > instead of verifying with SO_PEERCRED this is then used to set the > permissions of the privileged pipe when created by winbindd. The current idea is that that privileged pipe would live in a subdirectory of Samba's LOCKDIR. The administrator would then be free to set the privileges on the pipe directory, without smb.conf options. Clients would contact the 'normal' winbind pipe to locate the privileged pipe, or there would be a symlink as /tmp/.winbind/priv-pipe. Better ideas are most welcome... > I'll try to collect all of this into a single document. Thanks, -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
Re: winbindd NTLMSSP helper
On Sun, 8 Sep 2002, Andrew Bartlett wrote: > For these I would much prefer (unless you have a very good reason) to > just use PAM. That way we keep the number of interfaces down. (We have > to maintain the PAM suff regardless). I would prefer if there was a "direct" alternative, not requiring PAM. Mainly for simplicity of administration, but also because we have to support some systems not using PAM... Btw, is it at all possible to build winbindd on systems not supporting PAM and/or NSS? > But if it just 'falls out' of the design (we will want one way to do > plaintext, just for testing sanity) then it's fine. As the plaintext support will be needed anyway for testing I don't think adding a couple of stream protocols for it will be much of a deal. > For now, you guys 'own' the protocol but I don't mind either way. Ok. > > What about a also supporting a stream oriented NTLM mode? > > I don't see the need - most applications doing this so frequently that > they need a stream mode are doing NTLMSSP anyway. Less interfaces > again... Right. > That's what we need to do with a privileged pipe - the idea is to avoid > needing to add a dependency on SO_PEERCRED. Either way is fine by me. Note: You still need smb.conf options to specify the required privileges.. instead of verifying with SO_PEERCRED this is then used to set the permissions of the privileged pipe when created by winbindd. I'll try to collect all of this into a single document. Regards Henrik
Re: winbindd: Here's a replacement get_id_from_sid() that gets UNIXu id/gid from /home/dir
On Fri, 2002-08-02 at 03:10, Ferguson, Ross wrote: > > rebuilding winbindd with the enclosed replacement function gets the UNIX > uid/gid from the users home directory. If it fails in anyway, it returns > (g/u)id of 'nobody' This obviously allows specifically assigned uid's per > user, allowing them to create files in there home directories while > maintaining security. I'm running this with 2.2.5 on Solaris9 Proof of > concept only. Not ported / tested on any other platform. > Enjoy >Ross I really like the concept. A quick look at the implementation shows a problem, though. The home directory should come from the "template homedir" parameter. Given the proof of concept nature of the code, such a shortcut is quite acceptable. Also, I don't think that putting this into the core winbind code is necessarily the right place. It and the 50 other concepts that people come up with will eventually lead to some pretty signifcant bloat. A while back I was working on a plug-in system for the idmap functionality. I have been sidetracked for a while on that project, though. I think that this concept would be an awesome plug-in. See http://www.cae.wisc.edu/~gerdts/samba/ for my implementation so far. Andrew gave me a todo list that has yet to be todone. http://lists.samba.org/pipermail/samba-technical/2002-May/036877.html Mike
Re: Winbindd Success :) [was Re: winbindd, (radio)active directoryand other pains...]
Mike Gerdts wrote: > On Thu, 2002-07-18 at 02:03, Bogdan Iamandei wrote: > > >>1). I don't seem to be able to specify multiple ranges of ID's for >>winbindd. For example: >> >>winbind uid = 1000-2 25000-3 >> >>Would this be possible in the future? :) Please? :) >> >>2). For some reason winbindd is reading the winbindd_cache.tdb and >>winbindd_idmap.tdb after a restart. All would be fine, but if I change >>the UID ranges, winbindd will still use the old range. The workaround >>is to remove those two TDBs and try again. > > > Are you proposing that if winbindd finds a UID in the cache that does > not fit in the range that a new UID from the range should be assigned? > That wouldn't be too hard to implement, but I am not sure that it is > desirable. The side effect would be that all the files and ACLs that > were created would maintain the old uids. When the user gets a new uid, > files that they previously created or ACLs that they were added to would > not be accessible with the new uid. Damn - I haven't thought of this. You're right. > > >>3). (not really a nitpick - more like a small warning) Beware of nscd >>daemon on Solaris. It basically takes a little while until it kicks in >>for the first time. > > > A while back I reported a bug in winbindd that caused it to crash nscd. > While debugging this problem, I found that winbindd was horribly slow > without the caching done by nscd. After fixing the problem so that nscd > would stay alive, name lookups became MUCH faster because repeat lookups > were being answered by nscd rather than by winbindd. > > I suspect that this slowness is because winbindd talking to PDC across > the WAN rather than the local PDC. I never really looked into it. > Since I didn't see other people complaining about slowness, I assumed > that it was something wierd with our domain configuration. Hmm... not really - since same authentication - going over the WAN to the Kerberos5 swerver goes faster. But then again - the usernames are all in the local passwd file, so lookup is necessary. >>4). After a while (5-10 minutes) running samba, attempting to connect >>a share - takes a long - long time and in the end it fails with >>something like Error - 0. I'll have to test it some more - before giving >>some more details though. > > > I have seen that one too, but forget the exact circumstances. Ahaa! so it's not only my perception. That's good to know. Ino!~ -- I have seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tannhauser Gate. All those moments will be lost in time, like tears in rain. Time to die.
Re: Winbindd Success :) [was Re: winbindd, (radio)active directoryand other pains...]
On Thu, 2002-07-18 at 02:03, Bogdan Iamandei wrote: > 1). I don't seem to be able to specify multiple ranges of ID's for > winbindd. For example: > > winbind uid = 1000-2 25000-3 > > Would this be possible in the future? :) Please? :) > > 2). For some reason winbindd is reading the winbindd_cache.tdb and > winbindd_idmap.tdb after a restart. All would be fine, but if I change > the UID ranges, winbindd will still use the old range. The workaround > is to remove those two TDBs and try again. Are you proposing that if winbindd finds a UID in the cache that does not fit in the range that a new UID from the range should be assigned? That wouldn't be too hard to implement, but I am not sure that it is desirable. The side effect would be that all the files and ACLs that were created would maintain the old uids. When the user gets a new uid, files that they previously created or ACLs that they were added to would not be accessible with the new uid. > 3). (not really a nitpick - more like a small warning) Beware of nscd > daemon on Solaris. It basically takes a little while until it kicks in > for the first time. A while back I reported a bug in winbindd that caused it to crash nscd. While debugging this problem, I found that winbindd was horribly slow without the caching done by nscd. After fixing the problem so that nscd would stay alive, name lookups became MUCH faster because repeat lookups were being answered by nscd rather than by winbindd. I suspect that this slowness is because winbindd talking to PDC across the WAN rather than the local PDC. I never really looked into it. Since I didn't see other people complaining about slowness, I assumed that it was something wierd with our domain configuration. > 4). After a while (5-10 minutes) running samba, attempting to connect > a share - takes a long - long time and in the end it fails with > something like Error - 0. I'll have to test it some more - before giving > some more details though. I have seen that one too, but forget the exact circumstances. Mike
Winbindd Success :) [was Re: winbindd, (radio)active directory andother pains...]
Alexander Bokovoy wrote: > On Wed, Jul 17, 2002 at 04:23:14PM +1000, Bogdan Iamandei wrote: > >> I am trying to make winbindd talk to the local AD swerver here >>and it is not too clear to me whether there's a difference between >>2.2.6-pre and 3.0-pre. >> >> It seems to me that 2.2.6-pre is not really working (unless I > > It indeed shouldn't work as it lacks AD functionality completely. Yeah - I discovered that after trying to use 3.0 > > >>am doing somehthing wrong) and 3.0-pre is not compiling the shared >>libs in nsswitch because of an error in configure script at the point >>where it checks whether the compiler can create shared libs. This >>happens with Sun's CC. However - there is a problem with the configure script which seems to pass the wrong parameters to sun's CC and the result is that the shared library test fails. GCC passes that test fine. CC creates the libraries if I edit and force the configure script to skip those tests and just assume that "yes the damned compiled knows how to and can create shared libs" >> >> So, my questions are: is there any difference between winbind >>in Samba2.2.6pre and HEAD? Is there anyone who got winbindd talking >>to an AD on Solaris/Sparc? If yes - how? :) > > There is a huge difference between winbindd's code in those CVS branches. > HEAD has support for AD while SAMBA_2_2 hasn't. Could you please show what > configure reports in config.status for this check of shared libs? I finally got it working. Authentication to the local AD works absolutely great. Thanks guys! :) A few nitpicks. 1). I don't seem to be able to specify multiple ranges of ID's for winbindd. For example: winbind uid = 1000-2 25000-3 Would this be possible in the future? :) Please? :) 2). For some reason winbindd is reading the winbindd_cache.tdb and winbindd_idmap.tdb after a restart. All would be fine, but if I change the UID ranges, winbindd will still use the old range. The workaround is to remove those two TDBs and try again. 3). (not really a nitpick - more like a small warning) Beware of nscd daemon on Solaris. It basically takes a little while until it kicks in for the first time. 4). After a while (5-10 minutes) running samba, attempting to connect a share - takes a long - long time and in the end it fails with something like Error - 0. I'll have to test it some more - before giving some more details though. Ino!~ -- I have seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tannhauser Gate. All those moments will be lost in time, like tears in rain. Time to die.
Re: winbindd, (radio)active directory and other pains...
On Wed, Jul 17, 2002 at 04:23:14PM +1000, Bogdan Iamandei wrote: > I am trying to make winbindd talk to the local AD swerver here > and it is not too clear to me whether there's a difference between > 2.2.6-pre and 3.0-pre. > > It seems to me that 2.2.6-pre is not really working (unless I It indeed shouldn't work as it lacks AD functionality completely. > am doing somehthing wrong) and 3.0-pre is not compiling the shared > libs in nsswitch because of an error in configure script at the point > where it checks whether the compiler can create shared libs. This > happens with Sun's CC. > > So, my questions are: is there any difference between winbind > in Samba2.2.6pre and HEAD? Is there anyone who got winbindd talking > to an AD on Solaris/Sparc? If yes - how? :) There is a huge difference between winbindd's code in those CVS branches. HEAD has support for AD while SAMBA_2_2 hasn't. Could you please show what configure reports in config.status for this check of shared libs? -- / Alexander Bokovoy --- ... but giving people the power to do even silly things is what Linux is all about. - Linus Torvalds on linux-kernel
Re: winbindd architecture
On Sat, Jul 13, 2002 at 04:21:47AM +0930, Richard Sharpe wrote: : > > > We have to node status to get the *name* of the PDC, becouse the > > > NETLOGON RPC requires that. Windows machines to a NETLOGON Mailslot > > > message, but we don't do that at present. > > > > So you join the domain without knowing the domain name? > > No, of course you know the domain name. That is passed in on the smbpasswd > command line after -j or the net join command. > > The issue is finding the DC. We can do that by looking it up in WINS or in > DNS if they are using Active directory. However, windows dows a GETDC > NetLOGON mailslot request, which we should do as well. If memory serves, > we look up #1C. > > > In order to do the node status, you first have to have an IP or DNS name > > for the node you want to query. How is that obtained? > > WINS or DNS once you have found the NetBIOS name of the DC. Right... That's my point, I guess. If you know the NTdomain name then you know the PDC's name. It should answer to #1B (as DMB) and also to #1C (a group name, but the PDC is always the first IP in the Name Query Response from the WINS server). In any case, I don't see why a Node Status Query would be needed, and even if it is used I don't see why the unexpected.tdb would be needed since NT responds to the correct port. Chris -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
Re: winbindd architecture
On Thu, 11 Jul 2002, Christopher R. Hertel wrote: > On Fri, Jul 12, 2002 at 10:44:54AM +1000, Andrew Bartlett wrote: > > "Christopher R. Hertel" wrote: > > > > > Anyway, if the unexpected.tdb is the reason that winbindd needs nmbd, then > > > I think it could be made optional. I imagine that winbindd would be > > > sending regular name queries in order to find the PDC, probably looking > > > for #1B. The 1B address is actually the DMB identifier, but in > > > Windows the DMB and PDC must be the same node. It is possible that a Node > > > Status query is also being sent, to verify that the 1B node also has the > > > 1C name registered (1C means "I am an NT Domain Controller). That could > > > be an issue with a Samba DMB. If that's the case, though, W/95 can't be a > > > PDC anyway so not getting a reply shouldn't be a problem. > > > > > > Again, I'm not in sync with the discussion so if that's totally bogus > > > please disregard. > > > > We have to node status to get the *name* of the PDC, becouse the > > NETLOGON RPC requires that. Windows machines to a NETLOGON Mailslot > > message, but we don't do that at present. > > So you join the domain without knowing the domain name? No, of course you know the domain name. That is passed in on the smbpasswd command line after -j or the net join command. The issue is finding the DC. We can do that by looking it up in WINS or in DNS if they are using Active directory. However, windows dows a GETDC NetLOGON mailslot request, which we should do as well. If memory serves, we look up #1C. > In order to do the node status, you first have to have an IP or DNS name > for the node you want to query. How is that obtained? WINS or DNS once you have found the NetBIOS name of the DC. Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: winbindd architecture
On Fri, Jul 12, 2002 at 10:44:54AM +1000, Andrew Bartlett wrote: > "Christopher R. Hertel" wrote: > > > Anyway, if the unexpected.tdb is the reason that winbindd needs nmbd, then > > I think it could be made optional. I imagine that winbindd would be > > sending regular name queries in order to find the PDC, probably looking > > for #1B. The 1B address is actually the DMB identifier, but in > > Windows the DMB and PDC must be the same node. It is possible that a Node > > Status query is also being sent, to verify that the 1B node also has the > > 1C name registered (1C means "I am an NT Domain Controller). That could > > be an issue with a Samba DMB. If that's the case, though, W/95 can't be a > > PDC anyway so not getting a reply shouldn't be a problem. > > > > Again, I'm not in sync with the discussion so if that's totally bogus > > please disregard. > > We have to node status to get the *name* of the PDC, becouse the > NETLOGON RPC requires that. Windows machines to a NETLOGON Mailslot > message, but we don't do that at present. So you join the domain without knowing the domain name? In order to do the node status, you first have to have an IP or DNS name for the node you want to query. How is that obtained? Curious... (in more ways than one) Chris -)- PS. If it's only W/95 that responds incorrectly to the Node Status Query, then we really don't need the information in unexpected.tdb. -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
Re: winbindd architecture
On Fri, Jul 12, 2002 at 02:07:29AM +0930, Richard Sharpe wrote: > On Thu, 11 Jul 2002, Tim Potter wrote: > > > On Thu, Jul 11, 2002 at 03:57:11PM -0400, Leducq Dominique wrote: > > > > > Le Mercredi 20 F?vrier 2002 12:51, Tim Potter a ?crit : > > > > Nmbd needs to be running on the local system as there are some lookup > > > > requests send by winbindd that are sent by Windows NT domain controllers > > > > to the incorrect port which is a bug in Windows. ?Nmbd receives these > > > > packets and stores them in a database (unexpected.tdb) which winbindd > > > > reads from. > > > > > > I would need some more details about this. Could you please tell me : > > > > > > - which versions of the OS are involved (NT 4 to XP) ? Only as PDC ? > > > - which kind of requests ? > > > - which port ? (I guess it replies to port 137 or 445 instead of source port > > > of the request...) > > > > >From memory it is the network request that locates the PDC name on the > > network. I think it is only Windows NT 4 but I haven't tested it. It > > is one of the udp ports - 139 I think. > > Also from memory, but I believe that Win9X does that as well. I think name > lookup requests to a Win9X machine are sent back to port 137. As far as I know, NT replies correctly to name queries and node status queries (both on port 137). The help generated by 'nmblookup -?' state that it's only W/95 that has this problem, and I think it's only early versions of W/95, and only when sent a Node Status query. I have a test machine at home which runs W/95, responds correctly to a Name Query, but responds to port 137 when sent a Node Status. Chris -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
Re: winbindd architecture
"Christopher R. Hertel" wrote: > Anyway, if the unexpected.tdb is the reason that winbindd needs nmbd, then > I think it could be made optional. I imagine that winbindd would be > sending regular name queries in order to find the PDC, probably looking > for #1B. The 1B address is actually the DMB identifier, but in > Windows the DMB and PDC must be the same node. It is possible that a Node > Status query is also being sent, to verify that the 1B node also has the > 1C name registered (1C means "I am an NT Domain Controller). That could > be an issue with a Samba DMB. If that's the case, though, W/95 can't be a > PDC anyway so not getting a reply shouldn't be a problem. > > Again, I'm not in sync with the discussion so if that's totally bogus > please disregard. We have to node status to get the *name* of the PDC, becouse the NETLOGON RPC requires that. Windows machines to a NETLOGON Mailslot message, but we don't do that at present. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
Re: winbindd architecture
On Thu, Jul 11, 2002 at 07:04:39AM -0700, Tim Potter wrote: > On Thu, Jul 11, 2002 at 03:57:11PM -0400, Leducq Dominique wrote: > > > Le Mercredi 20 F?vrier 2002 12:51, Tim Potter a ?crit : > > > Nmbd needs to be running on the local system as there are some lookup > > > requests send by winbindd that are sent by Windows NT domain controllers > > > to the incorrect port which is a bug in Windows. ?Nmbd receives these > > > packets and stores them in a database (unexpected.tdb) which winbindd > > > reads from. > > > > I would need some more details about this. Could you please tell me : > > > > - which versions of the OS are involved (NT 4 to XP) ? Only as PDC ? > > - which kind of requests ? > > - which port ? (I guess it replies to port 137 or 445 instead of source > > port of the request...) > > >From memory it is the network request that locates the PDC name on the > network. I think it is only Windows NT 4 but I haven't tested it. It > is one of the udp ports - 139 I think. Tim, I haven't followed this closely so I may talking about the wrong things, but in general terms... The NBT Name Service is on UDP/137. Early versions of Windows/95 reply to this port instead of the originating source port when sent a Node Status Request. I don't know of anything else that makes that mistake, and it only happens on the Node Status Request, so it's fairly limited. The NBT Datagram Service is used for service announcement (browse list stuff). That's on port UDP/138. I have heard that there are problems with Windows boxes (9x and NT) always replying to 138 when they should reply to the originating source port. I don't have specifics on that one. If NT is involved, then port 445 isn't an issue. NT runs SMB over the NBT Session Service, which is TCP/139. Anyway, if the unexpected.tdb is the reason that winbindd needs nmbd, then I think it could be made optional. I imagine that winbindd would be sending regular name queries in order to find the PDC, probably looking for #1B. The 1B address is actually the DMB identifier, but in Windows the DMB and PDC must be the same node. It is possible that a Node Status query is also being sent, to verify that the 1B node also has the 1C name registered (1C means "I am an NT Domain Controller). That could be an issue with a Samba DMB. If that's the case, though, W/95 can't be a PDC anyway so not getting a reply shouldn't be a problem. Again, I'm not in sync with the discussion so if that's totally bogus please disregard. Chris -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
Re: winbindd architecture
On Thu, 11 Jul 2002, Tim Potter wrote: > On Thu, Jul 11, 2002 at 03:57:11PM -0400, Leducq Dominique wrote: > > > Le Mercredi 20 F?vrier 2002 12:51, Tim Potter a ?crit : > > > Nmbd needs to be running on the local system as there are some lookup > > > requests send by winbindd that are sent by Windows NT domain controllers > > > to the incorrect port which is a bug in Windows. ?Nmbd receives these > > > packets and stores them in a database (unexpected.tdb) which winbindd > > > reads from. > > > > I would need some more details about this. Could you please tell me : > > > > - which versions of the OS are involved (NT 4 to XP) ? Only as PDC ? > > - which kind of requests ? > > - which port ? (I guess it replies to port 137 or 445 instead of source port > > of the request...) > > >From memory it is the network request that locates the PDC name on the > network. I think it is only Windows NT 4 but I haven't tested it. It > is one of the udp ports - 139 I think. Also from memory, but I believe that Win9X does that as well. I think name lookup requests to a Win9X machine are sent back to port 137. Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: winbindd architecture
On Thu, Jul 11, 2002 at 03:57:11PM -0400, Leducq Dominique wrote: > Le Mercredi 20 F?vrier 2002 12:51, Tim Potter a ?crit : > > Nmbd needs to be running on the local system as there are some lookup > > requests send by winbindd that are sent by Windows NT domain controllers > > to the incorrect port which is a bug in Windows. ?Nmbd receives these > > packets and stores them in a database (unexpected.tdb) which winbindd > > reads from. > > I would need some more details about this. Could you please tell me : > > - which versions of the OS are involved (NT 4 to XP) ? Only as PDC ? > - which kind of requests ? > - which port ? (I guess it replies to port 137 or 445 instead of source port > of the request...) >From memory it is the network request that locates the PDC name on the network. I think it is only Windows NT 4 but I haven't tested it. It is one of the udp ports - 139 I think. Tim.
Re: winbindd architecture
Le Mercredi 20 Février 2002 12:51, Tim Potter a écrit : > Nmbd needs to be running on the local system as there are some lookup > requests send by winbindd that are sent by Windows NT domain controllers > to the incorrect port which is a bug in Windows. Nmbd receives these > packets and stores them in a database (unexpected.tdb) which winbindd > reads from. I would need some more details about this. Could you please tell me : - which versions of the OS are involved (NT 4 to XP) ? Only as PDC ? - which kind of requests ? - which port ? (I guess it replies to port 137 or 445 instead of source port of the request...) thanks, Dominique
RE: Winbindd!
I really need the answer ... The question is hard to ask so i try to give an example.. There is a sharing on Linux with Samba 2.2.4 called Shared1... We are using winbindd for unified logons and all the users and groups of our domains and trusted domains are mapped in the unix machine... These are supposed to be OK. There are two domain users called teknolojy\andrew and teknolojy\tim... These domains are Win2000 domains... And users are windows 2000 users... The need is to use Linux servers as print and file servers in our Win2000 domains with unified logons... Sharing1 points the directory /var/documents and drwxrwxrwx is given to it File system ext3... Is it possible to give r/w rights to teknology\andrew whereas we give only r permission to teknolojy\tim... And also teknolojy\domain users will have the only read permission..??? That means is it possible to implement all the rights ,that Win2000 supports, in Samba? ( Full Control, Read, Write, Execute... ) Because of Unix drwxrwxrwx rules, it doesnt seem to me YES to the answer of the question! Because drwxrwxrwx , owner, group and world is only 3 parameter. But i can need different parameteres for each of my users? Do you know the one who successfully imlement it fully in his company? Many thanks. -Original Message- From: Andrew Bartlett [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 19, 2002 11:04 AM To: Tim Potter Cc: Osman Tufanogullari (Garanti Teknoloji); [EMAIL PROTECTED] Subject: Re: Winbindd! Tim Potter wrote: > > On Wed, Jun 19, 2002 at 09:15:31AM +0300, Osman Tufanogullari (Garanti Teknoloji) >wrote: > > One more question. Today i also work on it but when you look into a share's >properties on NT or 2000 desktop, there is a Security tab on this panel... > > > > If you have a share on a linux server ( intented to use as a file & print server >), from a windows NT or 2000 desktop, > > > > Can we define security parameters (adding and deleting user with read/write >rights) using that panel? > > I think share level security is supported in the 2.2 series of Samba. > Give it a try and find out! Watch that language! Per-share ACLs are supported in 2.2 and above. 'Share level security' is somthing compleatly different - 'security = share' in smb.conf - and is somthing we have always supported. (It refers to one password per share, not one password per user. Samba implments this, but takes 'guesses' at the username instead... Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
Re: Winbindd!
Tim Potter wrote: > > On Wed, Jun 19, 2002 at 09:15:31AM +0300, Osman Tufanogullari (Garanti Teknoloji) >wrote: > > One more question. Today i also work on it but when you look into a share's >properties on NT or 2000 desktop, there is a Security tab on this panel... > > > > If you have a share on a linux server ( intented to use as a file & print server >), from a windows NT or 2000 desktop, > > > > Can we define security parameters (adding and deleting user with read/write >rights) using that panel? > > I think share level security is supported in the 2.2 series of Samba. > Give it a try and find out! Watch that language! Per-share ACLs are supported in 2.2 and above. 'Share level security' is somthing compleatly different - 'security = share' in smb.conf - and is somthing we have always supported. (It refers to one password per share, not one password per user. Samba implments this, but takes 'guesses' at the username instead... Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
Re: Winbindd!
On Wed, Jun 19, 2002 at 09:15:31AM +0300, Osman Tufanogullari (Garanti Teknoloji) wrote: > Many Thanks Tim for your quick response... > > After sending the mail below, I ran Winbindd with -d3 -i options and i saw that >winbindd was looking for the PDCs' IP adresses of the trusted domains... The first >file winbindd was looking into was lmhosts... > > So, I wrote the domain controllers' IP adresses of the trusted domains into the >lmhosts file in the format > > IPadrssofPDC Domain-Name > > This fixed the problem... Hmm - this may indicate a WINS related problem on your network. I'm glad you got it working though. (-: > But there is another problem now... Our company has ten thousands of user and >thousands of groups.. user count is about 15000... > Sometimes winbindd crashes...I run winbindd deamon, but sometimes later when i use >ps -ef, i cannot see ./winbindd in the list. It kills itself somehow but i dont >know... But sometimes it is in the list running for hours... Bummer - can you get a stack backtrace of winbindd crashing? > One more question. Today i also work on it but when you look into a share's >properties on NT or 2000 desktop, there is a Security tab on this panel... > > If you have a share on a linux server ( intented to use as a file & print server ), >from a windows NT or 2000 desktop, > > Can we define security parameters (adding and deleting user with read/write rights) >using that panel? I think share level security is supported in the 2.2 series of Samba. Give it a try and find out! Tim.
RE: Winbindd!
Many Thanks Tim for your quick response... After sending the mail below, I ran Winbindd with -d3 -i options and i saw that winbindd was looking for the PDCs' IP adresses of the trusted domains... The first file winbindd was looking into was lmhosts... So, I wrote the domain controllers' IP adresses of the trusted domains into the lmhosts file in the format IPadrssofPDC Domain-Name This fixed the problem... But there is another problem now... Our company has ten thousands of user and thousands of groups.. user count is about 15000... Sometimes winbindd crashes...I run winbindd deamon, but sometimes later when i use ps -ef, i cannot see ./winbindd in the list. It kills itself somehow but i dont know... But sometimes it is in the list running for hours... One more question. Today i also work on it but when you look into a share's properties on NT or 2000 desktop, there is a Security tab on this panel... If you have a share on a linux server ( intented to use as a file & print server ), from a windows NT or 2000 desktop, Can we define security parameters (adding and deleting user with read/write rights) using that panel? Thanks in advance... -Original Message- From: Tim Potter [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 19, 2002 2:35 AM To: Osman Tufanogullari (Garanti Teknoloji) Cc: [EMAIL PROTECTED] Subject: Re: Winbindd! On Tue, Jun 18, 2002 at 01:55:44PM +0300, Osman Tufanogullari (Garanti Teknoloji) wrote: > But after starting winbindd deamon, > > wbinfo -m ( trusted domain names ) --> OK > wbinfo -t ( check secret ) --> OK > wbinfo -n username ( sid from username ) --> OK > wbinfo -s sid ( username from sid) --> OK > > options work properly. > > But > > wbinfo -u and wbinfo -g end with error > "Error looking up domain users", > "Error looking up domain groups". Are you running with the RestrictAnonymous registry setting? Alternately are you running a Windows 2000 environment only? You may need to set a username and password for winbindd so it can connect to the domain controllers without using an anonymous session. Tim.
Re: Winbindd!
On Tue, Jun 18, 2002 at 01:55:44PM +0300, Osman Tufanogullari (Garanti Teknoloji) wrote: > But after starting winbindd deamon, > > wbinfo -m ( trusted domain names ) --> OK > wbinfo -t ( check secret ) --> OK > wbinfo -n username ( sid from username ) --> OK > wbinfo -s sid ( username from sid) --> OK > > options work properly. > > But > > wbinfo -u and wbinfo -g end with error > "Error looking up domain users", > "Error looking up domain groups". Are you running with the RestrictAnonymous registry setting? Alternately are you running a Windows 2000 environment only? You may need to set a username and password for winbindd so it can connect to the domain controllers without using an anonymous session. Tim.
Re: winbindd-NT_STATUS_CANT_ACCESS_DOMAIN_INFO
On Fri, Jun 07, 2002 at 06:12:10PM -0400, Ingmar Koecher wrote: > First I apologize if I am not posting this to the correct list, but it seems > rather specific and I haven't had any success posting it to the regular samba > list (but then I might just be impatient). > > I am running Samba as of CVS yesterday evening, Redhat 7.2, winbindd is > configured to use a domain user instead of anonymous connections, and the PDC > is NT4. Have you joined the domain? To validate a user's password Samba needs to be a member of the domain. Running 'net rpc join -U administrator%password' should do the trick. Tim.
Re: winbindd uid and gid range assumptions
On Tue, May 14, 2002 at 08:20:03AM -0400, Mike Gerdts wrote: > On Mon, 2002-05-13 at 18:42, Andrew Bartlett wrote: > > Moving over the socket is a very expencive operation, particularly > > compared to a simple if statement. Also, where we know that a uid is > > local, we need to check with code that winbind isn't linked to - the > > passdb backend. > > So in a situation where you have UIDs interspersed between NIS and > domain users, it may be cheaper to check to see if it is local first > followed by winbind. At least this may be better in my situation, as > each of my NFS/Samba servers is already an NIS slave. Even though a UID > lookup may have to talk to nscd and/or ypserv, it is still on the same > machine, thus avoiding network delays. > > Perhaps this would be a place where the plug-in architecture could be > useful as well. Checks could all be relegated to idmap_ops->islocal(). > The default op could be to check the winbind id range. Others that are > willing to or need to pay the price of a socket operation will have the > option of doing so. Presumably islocal() would not just be a straight > BOOL operation. I could imagine it replying True, False, LocalFirst, or > DomainFirst. Sounds like an interesting idea. > > But yes, we need to deal with things like getting the uid from the SFU > > LDAP schema, so this may well change in the future. > > Do you have any relative time frame or rough release number that you are > shooting for? No, its just an idea in my HEAD until I get a chance to look at it, or sombody codes me up a patch :-). > Do you see a plug-in that merges the functionality of the existing idmap > to the architecture present in the VFS, or should I start barking up a > different tree? That seems to be the current plugin arch, but we may move across to a more centralised scheme at some stage. Andrew Bartlett
Re: winbindd uid and gid range assumptions
On Mon, 2002-05-13 at 18:42, Andrew Bartlett wrote: > Moving over the socket is a very expencive operation, particularly > compared to a simple if statement. Also, where we know that a uid is > local, we need to check with code that winbind isn't linked to - the > passdb backend. So in a situation where you have UIDs interspersed between NIS and domain users, it may be cheaper to check to see if it is local first followed by winbind. At least this may be better in my situation, as each of my NFS/Samba servers is already an NIS slave. Even though a UID lookup may have to talk to nscd and/or ypserv, it is still on the same machine, thus avoiding network delays. Perhaps this would be a place where the plug-in architecture could be useful as well. Checks could all be relegated to idmap_ops->islocal(). The default op could be to check the winbind id range. Others that are willing to or need to pay the price of a socket operation will have the option of doing so. Presumably islocal() would not just be a straight BOOL operation. I could imagine it replying True, False, LocalFirst, or DomainFirst. > But yes, we need to deal with things like getting the uid from the SFU > LDAP schema, so this may well change in the future. Do you have any relative time frame or rough release number that you are shooting for? Do you see a plug-in that merges the functionality of the existing idmap to the architecture present in the VFS, or should I start barking up a different tree? Mike
Re: winbindd uid and gid range assumptions
Mike Gerdts wrote: > > It seems as though there was an assumption that users of winbindd would > have switched entirely to NT domain authentication or that they would > have distinct range of UIDs/GIDs for /etc/passwd (or NIS) and NT domain. > Is there any good reason to not just let get_id_from_sid() in > nsswitch/winbindd_idmap.c do all the checking? It seems as though the > optimization achieved by the multitude of checks is minimal and greatly > reduces the chances integration possibilities between winbindd and > traditional unix authentication. Moving over the socket is a very expencive operation, particularly compared to a simple if statement. Also, where we know that a uid is local, we need to check with code that winbind isn't linked to - the passdb backend. But yes, we need to deal with things like getting the uid from the SFU LDAP schema, so this may well change in the future. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
Re: winbindd problem
On Thu, Apr 11, 2002 at 12:47:08PM -0500, Esh, Andrew wrote: > Here it is: > > http://support.microsoft.com/default.aspx?scid=kb;en-us;Q143474 > > It's a key in the Registry called: > > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\RestrictAnonymous > > If it's not there (the default), anonymous logins are allowed. Here's my collection of links on the subject: http://support.microsoft.com/support/kb/articles/Q143/4/74.ASP http://support.microsoft.com/support/kb/articles/Q246/2/61.ASP http://www1.securityfocus.com/frames/?focus=microsoft&content=/focus/microsoft/nt/restrict.html You can also use rpcclient to test whether it is turned on for a given machine. Run rpcclient pdcname -U% -c querydispinfo. If you get an error (hmm - haven't done it in a while so I can't remember the exact name of it) then you probably have restrict anonymous set for that machine. You can then run rpcclient with -Uusername%password and it should work when the anonymous connection did not. Hmm - maybe I should put a level 0 debug in the winbindd log file when that particular error is encountered? Tim.
RE: winbindd problem
Title: RE: winbindd problem Here it is: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q143474 It's a key in the Registry called: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\RestrictAnonymous If it's not there (the default), anonymous logins are allowed. -Original Message- From: Richard Sharpe [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 12:43 PM To: Esh, Andrew Cc: Orwig, Paul; 'MCCALL,DON (HP-USA,ex1)'; '[EMAIL PROTECTED]' Subject: RE: winbindd problem On Thu, 11 Apr 2002, Esh, Andrew wrote: > How can this be checked? Where is it set? Hmmm, Andrew, you ask the hard questions, don't you? Check in the registry. I am not sure what key. Search google as well. > -Original Message- > From: Richard Sharpe [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 11, 2002 12:20 PM > To: Orwig, Paul > Cc: 'MCCALL,DON (HP-USA,ex1)'; '[EMAIL PROTECTED]' > Subject: RE: winbindd problem > > > On Thu, 11 Apr 2002, Orwig, Paul wrote: > > > Yes, it fails at the startup. > > I've been trying various ideas, stopping and restarting winbindd, and > > occasionally it works, only to break on the next try. > > The last time it worked, I had started it without a debug setting. 8-b > > Hmmm, is it possible that some of your DCs have restrict-anonymous set and > some don't? > > You may need to use the username and passwd stuff that Tim talked about. I > know I will be :-) > > -- Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
RE: winbindd problem
On Thu, 11 Apr 2002, Orwig, Paul wrote: > Hmmm... > My NT admins assure me that they have had the annonymous restriction on for > months. > I wonder if when they are modifying the database, the restriction is > nullified... > OR, they could be removing the restriction momentarily for something else... I don't know :-) > I will get a user/password from the NT admins and try from there. This is > separate from the domain-join secret? Yes, it is separate ... check the code in samba/source/nsswitch ... You use wbinfo to store the extra info in the secrets TDB ... However, as I say, this is only possible with a recent version of Samba 2.2.x. Secondly, it might simply be that there is a problem on HP/UX. A network trace would be useful. You could restrict the packets you supply to only the winbindd stuff using Ethereal and its ability save only some packets etc. > Paul Orwig > Pacific Life > > -Original Message- > From: Richard Sharpe [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 11, 2002 10:47 AM > To: Orwig, Paul > Cc: 'MCCALL,DON (HP-USA,ex1)'; '[EMAIL PROTECTED]' > Subject: RE: winbindd problem > > > On Thu, 11 Apr 2002, Orwig, Paul wrote: > > > Just so I understand... > > The fact that wbinfo -t replies with "secret is good" says that it is able > > to talk to the domain controller and should be able to request users/group > > listing. Right? > > Well, yes, but, as Tim pointed out in response to my erroneous statement, > the fact that wbinfo -t says that the secret is good means that the trust > account secrets stored in tdb are OK. > > winbindd uses anonymous connections to retrieve its information by > default, unless you have told it a valid account and password on the > DC[s]. > > In the presence of restrict-anonymous, this will not work, and if some of > your DCs have restrict-anonymous set and some not, you may get > intermittent failures. > > Regards > - > Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], > [EMAIL PROTECTED] > -- Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
RE: winbindd problem
Hmmm... My NT admins assure me that they have had the annonymous restriction on for months. I wonder if when they are modifying the database, the restriction is nullified... OR, they could be removing the restriction momentarily for something else... I will get a user/password from the NT admins and try from there. This is separate from the domain-join secret? Paul Orwig Pacific Life -Original Message- From: Richard Sharpe [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 10:47 AM To: Orwig, Paul Cc: 'MCCALL,DON (HP-USA,ex1)'; '[EMAIL PROTECTED]' Subject: RE: winbindd problem On Thu, 11 Apr 2002, Orwig, Paul wrote: > Just so I understand... > The fact that wbinfo -t replies with "secret is good" says that it is able > to talk to the domain controller and should be able to request users/group > listing. Right? Well, yes, but, as Tim pointed out in response to my erroneous statement, the fact that wbinfo -t says that the secret is good means that the trust account secrets stored in tdb are OK. winbindd uses anonymous connections to retrieve its information by default, unless you have told it a valid account and password on the DC[s]. In the presence of restrict-anonymous, this will not work, and if some of your DCs have restrict-anonymous set and some not, you may get intermittent failures. Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
RE: winbindd problem
On Fri, 12 Apr 2002, Richard Sharpe wrote: > On Thu, 11 Apr 2002, Orwig, Paul wrote: > > > Just so I understand... > > The fact that wbinfo -t replies with "secret is good" says that it is able > > to talk to the domain controller and should be able to request users/group > > listing. Right? > > Well, yes, but, as Tim pointed out in response to my erroneous statement, > the fact that wbinfo -t says that the secret is good means that the trust > account secrets stored in tdb are OK. > > winbindd uses anonymous connections to retrieve its information by > default, unless you have told it a valid account and password on the > DC[s]. BTW, this functioanlity is only in 2.2.4pre, I think. > In the presence of restrict-anonymous, this will not work, and if some of > your DCs have restrict-anonymous set and some not, you may get > intermittent failures. -- Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
RE: winbindd problem
On Thu, 11 Apr 2002, Orwig, Paul wrote: > Just so I understand... > The fact that wbinfo -t replies with "secret is good" says that it is able > to talk to the domain controller and should be able to request users/group > listing. Right? Well, yes, but, as Tim pointed out in response to my erroneous statement, the fact that wbinfo -t says that the secret is good means that the trust account secrets stored in tdb are OK. winbindd uses anonymous connections to retrieve its information by default, unless you have told it a valid account and password on the DC[s]. In the presence of restrict-anonymous, this will not work, and if some of your DCs have restrict-anonymous set and some not, you may get intermittent failures. Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
RE: winbindd problem
They all have restrict-anonymous. I am confused, now... I have been working under the impression that the domain secret was used by winbindd. Why would I want to use a different username/password? Paul Orwig Pacific Life -Original Message- From: Richard Sharpe [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 10:20 AM To: Orwig, Paul Cc: 'MCCALL,DON (HP-USA,ex1)'; '[EMAIL PROTECTED]' Subject: RE: winbindd problem On Thu, 11 Apr 2002, Orwig, Paul wrote: > Yes, it fails at the startup. > I've been trying various ideas, stopping and restarting winbindd, and > occasionally it works, only to break on the next try. > The last time it worked, I had started it without a debug setting. 8-b Hmmm, is it possible that some of your DCs have restrict-anonymous set and some don't? You may need to use the username and passwd stuff that Tim talked about. I know I will be :-)
RE: winbindd problem
On Thu, 11 Apr 2002, Esh, Andrew wrote: > How can this be checked? Where is it set? Hmmm, Andrew, you ask the hard questions, don't you? Check in the registry. I am not sure what key. Search google as well. > -Original Message- > From: Richard Sharpe [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 11, 2002 12:20 PM > To: Orwig, Paul > Cc: 'MCCALL,DON (HP-USA,ex1)'; '[EMAIL PROTECTED]' > Subject: RE: winbindd problem > > > On Thu, 11 Apr 2002, Orwig, Paul wrote: > > > Yes, it fails at the startup. > > I've been trying various ideas, stopping and restarting winbindd, and > > occasionally it works, only to break on the next try. > > The last time it worked, I had started it without a debug setting. 8-b > > Hmmm, is it possible that some of your DCs have restrict-anonymous set and > some don't? > > You may need to use the username and passwd stuff that Tim talked about. I > know I will be :-) > > -- Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
RE: winbindd problem
I originally had the password server = * It is now net to dc1name,dc2name,dc3name,dc4name I did a test monday where I set it to each DC, one-at-a-time and none of them worked. I can try one domain controller at-a-time for multiple tries and see what happens. How long after starting winbindd should I wait before trying the wbinfo -u command? I have been running a tail -f log.winbindd and waiting for it to pause. Just so I understand... The fact that wbinfo -t replies with "secret is good" says that it is able to talk to the domain controller and should be able to request users/group listing. Right? Paul Orwig Pacific Life -Original Message- From: MCCALL,DON (HP-USA,ex1) [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 8:32 AM To: 'Orwig, Paul'; MCCALL,DON (HP-USA,ex1) Cc: '[EMAIL PROTECTED]' Subject: RE: winbindd problem Well, that's just wierd. I haven't run into anything like this before. in your smb.conf file, have you set password server = * or can you set password server = pdcname and then try it multiple times (with the same pdcname) and finally get it to work? Don -Original Message- From: Orwig, Paul [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 9:40 AM To: 'MCCALL,DON (HP-USA,ex1)'; Orwig, Paul Cc: '[EMAIL PROTECTED]' Subject: RE: winbindd problem Yes, it fails at the startup. I've been trying various ideas, stopping and restarting winbindd, and occasionally it works, only to break on the next try. The last time it worked, I had started it without a debug setting. 8-b Paul Orwig Pacific Life 949-219-7082 -Original Message- From: MCCALL,DON (HP-USA,ex1) [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 10, 2002 6:50 AM To: 'Orwig, Paul'; 'Richard Sharpe' Cc: '[EMAIL PROTECTED]' Subject: RE: winbindd problem Hi Paul, Just want to make sure I understand: when this fails, it fails right from startup? And WHAT do you do to get it to finally work again? Don -Original Message- From: Orwig, Paul [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 6:36 PM To: 'Richard Sharpe'; Orwig, Paul Cc: '[EMAIL PROTECTED]' Subject: RE: winbindd problem 1) We have joined the domain. Samba is running fine without winbind. 2) We have only this one copy of winbindd 3) We are using PAM_SMB without a problem. 4) ROOT# wbinfo -t Secret is good More ideas? Paul -Original Message- From: Richard Sharpe [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 4:28 PM To: Orwig, Paul Cc: '[EMAIL PROTECTED]' Subject: Re: winbindd problem On Tue, 9 Apr 2002, Orwig, Paul wrote: > Question: > How does winbindd determine whether to do annonymous or authenticated > queries? > How does winbindd determine what user to authenticate with? > Can winbindd be forced to use a specific user/password to query the PDC? It uses the trust account info from the secrets database. You have to join the domain. > Problem: > winbindd seems to work intermittantly. > wbinfo -u returns "Error looking up domain users" I have seen a number of reasons for this: 1. You have not joined the domain 2. There are old copies of winbindd or smbd/nmbd from a different domain 3. There is no connectivity to the DC Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
RE: winbindd problem
Title: RE: winbindd problem How can this be checked? Where is it set? -Original Message- From: Richard Sharpe [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 12:20 PM To: Orwig, Paul Cc: 'MCCALL,DON (HP-USA,ex1)'; '[EMAIL PROTECTED]' Subject: RE: winbindd problem On Thu, 11 Apr 2002, Orwig, Paul wrote: > Yes, it fails at the startup. > I've been trying various ideas, stopping and restarting winbindd, and > occasionally it works, only to break on the next try. > The last time it worked, I had started it without a debug setting. 8-b Hmmm, is it possible that some of your DCs have restrict-anonymous set and some don't? You may need to use the username and passwd stuff that Tim talked about. I know I will be :-)
RE: winbindd problem
On Thu, 11 Apr 2002, Orwig, Paul wrote: > Yes, it fails at the startup. > I've been trying various ideas, stopping and restarting winbindd, and > occasionally it works, only to break on the next try. > The last time it worked, I had started it without a debug setting. 8-b Hmmm, is it possible that some of your DCs have restrict-anonymous set and some don't? You may need to use the username and passwd stuff that Tim talked about. I know I will be :-)
RE: winbindd problem
Well, that's just wierd. I haven't run into anything like this before. in your smb.conf file, have you set password server = * or can you set password server = pdcname and then try it multiple times (with the same pdcname) and finally get it to work? Don -Original Message- From: Orwig, Paul [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 9:40 AM To: 'MCCALL,DON (HP-USA,ex1)'; Orwig, Paul Cc: '[EMAIL PROTECTED]' Subject: RE: winbindd problem Yes, it fails at the startup. I've been trying various ideas, stopping and restarting winbindd, and occasionally it works, only to break on the next try. The last time it worked, I had started it without a debug setting. 8-b Paul Orwig Pacific Life 949-219-7082 -Original Message- From: MCCALL,DON (HP-USA,ex1) [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 10, 2002 6:50 AM To: 'Orwig, Paul'; 'Richard Sharpe' Cc: '[EMAIL PROTECTED]' Subject: RE: winbindd problem Hi Paul, Just want to make sure I understand: when this fails, it fails right from startup? And WHAT do you do to get it to finally work again? Don -Original Message- From: Orwig, Paul [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 6:36 PM To: 'Richard Sharpe'; Orwig, Paul Cc: '[EMAIL PROTECTED]' Subject: RE: winbindd problem 1) We have joined the domain. Samba is running fine without winbind. 2) We have only this one copy of winbindd 3) We are using PAM_SMB without a problem. 4) ROOT# wbinfo -t Secret is good More ideas? Paul -Original Message- From: Richard Sharpe [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 4:28 PM To: Orwig, Paul Cc: '[EMAIL PROTECTED]' Subject: Re: winbindd problem On Tue, 9 Apr 2002, Orwig, Paul wrote: > Question: > How does winbindd determine whether to do annonymous or authenticated > queries? > How does winbindd determine what user to authenticate with? > Can winbindd be forced to use a specific user/password to query the PDC? It uses the trust account info from the secrets database. You have to join the domain. > Problem: > winbindd seems to work intermittantly. > wbinfo -u returns "Error looking up domain users" I have seen a number of reasons for this: 1. You have not joined the domain 2. There are old copies of winbindd or smbd/nmbd from a different domain 3. There is no connectivity to the DC Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
RE: winbindd problem
Yes, it fails at the startup. I've been trying various ideas, stopping and restarting winbindd, and occasionally it works, only to break on the next try. The last time it worked, I had started it without a debug setting. 8-b Paul Orwig Pacific Life 949-219-7082 -Original Message- From: MCCALL,DON (HP-USA,ex1) [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 10, 2002 6:50 AM To: 'Orwig, Paul'; 'Richard Sharpe' Cc: '[EMAIL PROTECTED]' Subject: RE: winbindd problem Hi Paul, Just want to make sure I understand: when this fails, it fails right from startup? And WHAT do you do to get it to finally work again? Don -Original Message- From: Orwig, Paul [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 6:36 PM To: 'Richard Sharpe'; Orwig, Paul Cc: '[EMAIL PROTECTED]' Subject: RE: winbindd problem 1) We have joined the domain. Samba is running fine without winbind. 2) We have only this one copy of winbindd 3) We are using PAM_SMB without a problem. 4) ROOT# wbinfo -t Secret is good More ideas? Paul -Original Message- From: Richard Sharpe [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 4:28 PM To: Orwig, Paul Cc: '[EMAIL PROTECTED]' Subject: Re: winbindd problem On Tue, 9 Apr 2002, Orwig, Paul wrote: > Question: > How does winbindd determine whether to do annonymous or authenticated > queries? > How does winbindd determine what user to authenticate with? > Can winbindd be forced to use a specific user/password to query the PDC? It uses the trust account info from the secrets database. You have to join the domain. > Problem: > winbindd seems to work intermittantly. > wbinfo -u returns "Error looking up domain users" I have seen a number of reasons for this: 1. You have not joined the domain 2. There are old copies of winbindd or smbd/nmbd from a different domain 3. There is no connectivity to the DC Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: Winbindd in HEAD: cannot deal with 15,000 users+ -stack trace with HEAD code
Mike Papper wrote: > > I figured out how-to create the libnss_winbind.so. I made it and ran my tests > again. The test uses aPDC with 15,000 users to which I run a script that > adds and removes 2 users and 1 group continously. Sorry to do this to you, but could you re-run with current HEAD (so I can match line numbers) and do a 'bt full' to get the local variables? Also include the value of any pointers you think might be relevent - like the 'names' pointer/array etc. Thanks! -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
RE: winbindd problem
Hi Paul, Just want to make sure I understand: when this fails, it fails right from startup? And WHAT do you do to get it to finally work again? Don -Original Message- From: Orwig, Paul [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 6:36 PM To: 'Richard Sharpe'; Orwig, Paul Cc: '[EMAIL PROTECTED]' Subject: RE: winbindd problem 1) We have joined the domain. Samba is running fine without winbind. 2) We have only this one copy of winbindd 3) We are using PAM_SMB without a problem. 4) ROOT# wbinfo -t Secret is good More ideas? Paul -Original Message- From: Richard Sharpe [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 4:28 PM To: Orwig, Paul Cc: '[EMAIL PROTECTED]' Subject: Re: winbindd problem On Tue, 9 Apr 2002, Orwig, Paul wrote: > Question: > How does winbindd determine whether to do annonymous or authenticated > queries? > How does winbindd determine what user to authenticate with? > Can winbindd be forced to use a specific user/password to query the PDC? It uses the trust account info from the secrets database. You have to join the domain. > Problem: > winbindd seems to work intermittantly. > wbinfo -u returns "Error looking up domain users" I have seen a number of reasons for this: 1. You have not joined the domain 2. There are old copies of winbindd or smbd/nmbd from a different domain 3. There is no connectivity to the DC Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: winbindd problem
On Wed, 10 Apr 2002, Tim Potter wrote: > On Wed, Apr 10, 2002 at 10:45:54AM +0930, Richard Sharpe wrote: > > > > I see an entry in the log.winbindd that states: > > > > The secrets database would appear to have crap! Try rejoining the domain > > and seeing if that works. > > You are getting the different secrets confused. The secrets called > SECRETS_AUTH_* are used by winbindd when making connections to the > domain controller. The domain join secrets are called > SECRETS_MACHINE_ACCT_PASS. You are right :-( The trick appears to be to store the correct info in the right places ... Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: winbindd problem
On Wed, Apr 10, 2002 at 10:45:54AM +0930, Richard Sharpe wrote: > > I see an entry in the log.winbindd that states: > > The secrets database would appear to have crap! Try rejoining the domain > and seeing if that works. You are getting the different secrets confused. The secrets called SECRETS_AUTH_* are used by winbindd when making connections to the domain controller. The domain join secrets are called SECRETS_MACHINE_ACCT_PASS. Tim.
RE: winbindd problem
On Tue, 9 Apr 2002, Orwig, Paul wrote:
> I am not certain of the annonymous queries.
username = secrets_fetch(SECRETS_AUTH_USER, NULL);
password = secrets_fetch(SECRETS_AUTH_PASSWORD, NULL);
if (username && *username) {
pwd_set_cleartext(&creds->pwd, password);
pwd_make_lm_nt_16(&creds->pwd, password);
fstrcpy(creds->user_name, username);
fstrcpy(creds->domain, lp_workgroup());
DEBUG(3, ("IPC$ connections done %s\\%s\n", creds->domain,
creds->user_name));
} else
DEBUG(3, ("IPC$ connections done anonymously\n"));
The above is the code that is relevant to your message.
> I see an entry in the log.winbindd that states:
The secrets database would appear to have crap! Try rejoining the domain
and seeing if that works.
> [2002/04/05 17:59:35, 3] nsswitch/winbindd_cm.c:cm_init_creds(211)
> IPC$ connections done anonymously
>
> followed by a message:
>
> [2002/04/05 17:59:35, 3] lib/util_sock.c:open_socket_out(830)
> Connecting to 10.141.1.170 at port 445
> [2002/04/05 17:59:35, 2] lib/util_sock.c:open_socket_out(858)
> error connecting to 10.141.1.170:445 (Invalid argument)
This is a non-problem. It simply means that the underlying library tried
to connect to the domain controller via port 445 (non NetBIOS over TCP/IP
type connections), and failed because the DC was not listening on that
port.
> I noticed this last one each time winbindd fails.
>
> I can send debug level 3 and debug level 5 logs of the startup.
They might be needed, or even a level 10. A network trace taken via
tcpdump might also be needed ...
> If this makes any difference, I have switched winbindd on and off a few
> times via the nsswitch.conf entries.
> It is currently off until we can get winbindd running reliably.
Hmmm, I have not had these problems, and I chop and change winbindd
against domain controllers (one, and NT4 PDC, the other a Samba 2.2.3pre
PDC), and I run it all the time in a variety of member servers.
Regards
-
Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Re: winbindd problem
On Tue, Apr 09, 2002 at 04:52:21PM -0700, Orwig, Paul wrote: > I am not certain of the annonymous queries. > I see an entry in the log.winbindd that states: > > [2002/04/05 17:59:35, 3] nsswitch/winbindd_cm.c:cm_init_creds(211) > IPC$ connections done anonymously > > followed by a message: > > [2002/04/05 17:59:35, 3] lib/util_sock.c:open_socket_out(830) > Connecting to 10.141.1.170 at port 445 > [2002/04/05 17:59:35, 2] lib/util_sock.c:open_socket_out(858) > error connecting to 10.141.1.170:445 (Invalid argument) > > I noticed this last one each time winbindd fails. You can set the user to authenticate with by using the --set-auth-user option to wbinfo. # wbinfo --set-auth-user=DOMAIN\\user%password After this has been done there should be an entry like "IPC connections done by user DOMAIN\\user" in the log file. Tim.
RE: winbindd problem
I am not certain of the annonymous queries. I see an entry in the log.winbindd that states: [2002/04/05 17:59:35, 3] nsswitch/winbindd_cm.c:cm_init_creds(211) IPC$ connections done anonymously followed by a message: [2002/04/05 17:59:35, 3] lib/util_sock.c:open_socket_out(830) Connecting to 10.141.1.170 at port 445 [2002/04/05 17:59:35, 2] lib/util_sock.c:open_socket_out(858) error connecting to 10.141.1.170:445 (Invalid argument) I noticed this last one each time winbindd fails. I can send debug level 3 and debug level 5 logs of the startup. If this makes any difference, I have switched winbindd on and off a few times via the nsswitch.conf entries. It is currently off until we can get winbindd running reliably. Paul -Original Message- From: Richard Sharpe [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 5:40 PM To: Orwig, Paul Cc: 'MCCALL,DON (HP-USA,ex1)'; '[EMAIL PROTECTED]' Subject: RE: winbindd problem On Tue, 9 Apr 2002, Orwig, Paul wrote: > 1) It works until I have to stop and restart it. Do you mean when you have to stop and restart winbindd? I have not had that problem. > 2) We have four domain controllers. I went through each of them, one-by-one > with the same problem. Do you have a network trace? > I'm really curious why it chooses annonymous queries when I see: > ROOT# wbinfo -t > Secret is good This just means that winbindd is happy with the secrets in the database, but it has contacted a domain controller and logged on using the trust account info. Are you certain that it uses anonymous queries? Do you have a trace. Ethereal can make sense of some of those these days, esp if you capture from when winbindd starts up. Also, what does the log file say about what winbindd is doing? Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
RE: winbindd problem
On Tue, 9 Apr 2002, Orwig, Paul wrote: > 1) It works until I have to stop and restart it. Do you mean when you have to stop and restart winbindd? I have not had that problem. > 2) We have four domain controllers. I went through each of them, one-by-one > with the same problem. Do you have a network trace? > I'm really curious why it chooses annonymous queries when I see: > ROOT# wbinfo -t > Secret is good This just means that winbindd is happy with the secrets in the database, but it has contacted a domain controller and logged on using the trust account info. Are you certain that it uses anonymous queries? Do you have a trace. Ethereal can make sense of some of those these days, esp if you capture from when winbindd starts up. Also, what does the log file say about what winbindd is doing? Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
RE: winbindd problem
1) It works until I have to stop and restart it. 2) We have four domain controllers. I went through each of them, one-by-one with the same problem. I'm really curious why it chooses annonymous queries when I see: ROOT# wbinfo -t Secret is good Paul -Original Message- From: MCCALL,DON (HP-USA,ex1) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 3:26 PM To: 'Orwig, Paul'; '[EMAIL PROTECTED]' Subject: RE: winbindd problem Hi Paul, You say this is intermittent? You may have mentioned this earlier, but 1. once you start up winbindd, if it works, does it keep working until you have to restart it for some reason? What do you have for your 'password server' line in your smb.conf? If you are using "*", could you try using the pdc name instead, and see if this helps? (I'm thinking maybe it fails when it is contacting one of the OTHER dc's, and therein lies the intermittency - jst at thought) Hope this helps, Don -Original Message- From: Orwig, Paul [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 5:53 PM To: '[EMAIL PROTECTED]' Subject: winbindd problem Question: How does winbindd determine whether to do annonymous or authenticated queries? How does winbindd determine what user to authenticate with? Can winbindd be forced to use a specific user/password to query the PDC? Problem: winbindd seems to work intermittantly. wbinfo -u returns "Error looking up domain users" I am using samba 2.2.3a on HPUX 11 and NT 4.0 Domain Controllers that deny annonymous queries. log.winbindd: [2002/04/09 14:04:03, 1] lib/debug.c:debug_message(248) INFO: Debug class all level = 1 (pid 20800 from pid 20800) [2002/04/09 14:04:03, 1] param/loadparm.c:service_ok(2158) NOTE: Service printers is flagged unavailable. [2002/04/09 14:04:03, 2] lib/interface.c:add_interface(81) added interface ip=10.141.1.191 bcast=10.141.255.255 nmask=255.255.0.0 [2002/04/09 14:04:03, 2] lib/interface.c:add_interface(81) added interface ip=127.0.0.1 bcast=127.255.255.255 nmask=255.0.0.0 [2002/04/09 14:04:03, 1] nsswitch/winbindd_util.c:get_domain_info(137) getting trusted domain list [2002/04/09 14:04:03, 3] libsmb/namequery.c:resolve_lmhosts(752) resolve_lmhosts: Attempting lmhosts lookup for name ap-dc01<0x20> [2002/04/09 14:04:03, 3] libsmb/namequery.c:resolve_hosts(792) resolve_hosts: Attempting host lookup for name ap-dc01<0x20> [2002/04/09 14:04:03, 3] libsmb/namequery.c:resolve_lmhosts(752) resolve_lmhosts: Attempting lmhosts lookup for name ap-dc02<0x20> [2002/04/09 14:04:03, 3] libsmb/namequery.c:resolve_hosts(792) resolve_hosts: Attempting host lookup for name ap-dc02<0x20> [2002/04/09 14:04:03, 3] libsmb/namequery.c:resolve_lmhosts(752) resolve_lmhosts: Attempting lmhosts lookup for name ap-dc03<0x20> [2002/04/09 14:04:03, 3] libsmb/namequery.c:resolve_hosts(792) resolve_hosts: Attempting host lookup for name ap-dc03<0x20> [2002/04/09 14:04:03, 3] libsmb/namequery.c:resolve_lmhosts(752) resolve_lmhosts: Attempting lmhosts lookup for name ap-dc04<0x20> [2002/04/09 14:04:03, 3] libsmb/namequery.c:resolve_hosts(792) resolve_hosts: Attempting host lookup for name ap-dc04<0x20> [2002/04/09 14:04:03, 3] lib/util_sock.c:open_socket_in(798) bind succeeded on port 0 [2002/04/09 14:04:03, 3] libsmb/namequery.c:resolve_lmhosts(752) resolve_lmhosts: Attempting lmhosts lookup for name AP-DC02<0x20> [2002/04/09 14:04:03, 3] libsmb/namequery.c:resolve_hosts(792) resolve_hosts: Attempting host lookup for name AP-DC02<0x20> [2002/04/09 14:04:03, 3] nsswitch/winbindd_cm.c:cm_init_creds(211) IPC$ connections done anonymously [2002/04/09 14:04:03, 3] lib/util_sock.c:open_socket_out(830) Connecting to 10.141.1.170 at port 445 [2002/04/09 14:04:03, 2] lib/util_sock.c:open_socket_out(858) error connecting to 10.141.1.170:445 (Invalid argument) [2002/04/09 14:04:03, 3] lib/util_sock.c:open_socket_out(830) Connecting to 10.141.1.170 at port 139 [2002/04/09 14:04:04, 1] nsswitch/winbindd_util.c:add_trusted_domain(103) adding domain PMA_NB
RE: winbindd problem
1) We have joined the domain. Samba is running fine without winbind. 2) We have only this one copy of winbindd 3) We are using PAM_SMB without a problem. 4) ROOT# wbinfo -t Secret is good More ideas? Paul -Original Message- From: Richard Sharpe [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 4:28 PM To: Orwig, Paul Cc: '[EMAIL PROTECTED]' Subject: Re: winbindd problem On Tue, 9 Apr 2002, Orwig, Paul wrote: > Question: > How does winbindd determine whether to do annonymous or authenticated > queries? > How does winbindd determine what user to authenticate with? > Can winbindd be forced to use a specific user/password to query the PDC? It uses the trust account info from the secrets database. You have to join the domain. > Problem: > winbindd seems to work intermittantly. > wbinfo -u returns "Error looking up domain users" I have seen a number of reasons for this: 1. You have not joined the domain 2. There are old copies of winbindd or smbd/nmbd from a different domain 3. There is no connectivity to the DC Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
RE: winbindd problem
Hi Paul, You say this is intermittent? You may have mentioned this earlier, but 1. once you start up winbindd, if it works, does it keep working until you have to restart it for some reason? What do you have for your 'password server' line in your smb.conf? If you are using "*", could you try using the pdc name instead, and see if this helps? (I'm thinking maybe it fails when it is contacting one of the OTHER dc's, and therein lies the intermittency - jst at thought) Hope this helps, Don -Original Message- From: Orwig, Paul [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 5:53 PM To: '[EMAIL PROTECTED]' Subject: winbindd problem Question: How does winbindd determine whether to do annonymous or authenticated queries? How does winbindd determine what user to authenticate with? Can winbindd be forced to use a specific user/password to query the PDC? Problem: winbindd seems to work intermittantly. wbinfo -u returns "Error looking up domain users" I am using samba 2.2.3a on HPUX 11 and NT 4.0 Domain Controllers that deny annonymous queries. log.winbindd: [2002/04/09 14:04:03, 1] lib/debug.c:debug_message(248) INFO: Debug class all level = 1 (pid 20800 from pid 20800) [2002/04/09 14:04:03, 1] param/loadparm.c:service_ok(2158) NOTE: Service printers is flagged unavailable. [2002/04/09 14:04:03, 2] lib/interface.c:add_interface(81) added interface ip=10.141.1.191 bcast=10.141.255.255 nmask=255.255.0.0 [2002/04/09 14:04:03, 2] lib/interface.c:add_interface(81) added interface ip=127.0.0.1 bcast=127.255.255.255 nmask=255.0.0.0 [2002/04/09 14:04:03, 1] nsswitch/winbindd_util.c:get_domain_info(137) getting trusted domain list [2002/04/09 14:04:03, 3] libsmb/namequery.c:resolve_lmhosts(752) resolve_lmhosts: Attempting lmhosts lookup for name ap-dc01<0x20> [2002/04/09 14:04:03, 3] libsmb/namequery.c:resolve_hosts(792) resolve_hosts: Attempting host lookup for name ap-dc01<0x20> [2002/04/09 14:04:03, 3] libsmb/namequery.c:resolve_lmhosts(752) resolve_lmhosts: Attempting lmhosts lookup for name ap-dc02<0x20> [2002/04/09 14:04:03, 3] libsmb/namequery.c:resolve_hosts(792) resolve_hosts: Attempting host lookup for name ap-dc02<0x20> [2002/04/09 14:04:03, 3] libsmb/namequery.c:resolve_lmhosts(752) resolve_lmhosts: Attempting lmhosts lookup for name ap-dc03<0x20> [2002/04/09 14:04:03, 3] libsmb/namequery.c:resolve_hosts(792) resolve_hosts: Attempting host lookup for name ap-dc03<0x20> [2002/04/09 14:04:03, 3] libsmb/namequery.c:resolve_lmhosts(752) resolve_lmhosts: Attempting lmhosts lookup for name ap-dc04<0x20> [2002/04/09 14:04:03, 3] libsmb/namequery.c:resolve_hosts(792) resolve_hosts: Attempting host lookup for name ap-dc04<0x20> [2002/04/09 14:04:03, 3] lib/util_sock.c:open_socket_in(798) bind succeeded on port 0 [2002/04/09 14:04:03, 3] libsmb/namequery.c:resolve_lmhosts(752) resolve_lmhosts: Attempting lmhosts lookup for name AP-DC02<0x20> [2002/04/09 14:04:03, 3] libsmb/namequery.c:resolve_hosts(792) resolve_hosts: Attempting host lookup for name AP-DC02<0x20> [2002/04/09 14:04:03, 3] nsswitch/winbindd_cm.c:cm_init_creds(211) IPC$ connections done anonymously [2002/04/09 14:04:03, 3] lib/util_sock.c:open_socket_out(830) Connecting to 10.141.1.170 at port 445 [2002/04/09 14:04:03, 2] lib/util_sock.c:open_socket_out(858) error connecting to 10.141.1.170:445 (Invalid argument) [2002/04/09 14:04:03, 3] lib/util_sock.c:open_socket_out(830) Connecting to 10.141.1.170 at port 139 [2002/04/09 14:04:04, 1] nsswitch/winbindd_util.c:add_trusted_domain(103) adding domain PMA_NB
Re: winbindd problem
On Tue, 9 Apr 2002, Orwig, Paul wrote: > Question: > How does winbindd determine whether to do annonymous or authenticated > queries? > How does winbindd determine what user to authenticate with? > Can winbindd be forced to use a specific user/password to query the PDC? It uses the trust account info from the secrets database. You have to join the domain. > Problem: > winbindd seems to work intermittantly. > wbinfo -u returns "Error looking up domain users" I have seen a number of reasons for this: 1. You have not joined the domain 2. There are old copies of winbindd or smbd/nmbd from a different domain 3. There is no connectivity to the DC Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
