Re: smbgroupedit patch
On Fri, 2002-08-09 at 19:43, Andrew Bartlett wrote:
> "Bradley W. Langhorst" wrote:
> >
> > I propose the following changes to smbgroupedit in HEAD
> > to keep others from getting burned as I did by a
> > subtle change of group type during a unix association
> >
> > I can't believe how long it took me to figure out why my
> > my groups weren't showing up.
>
> Yes, the tools isn't the most intuitive - and that's *after* I allowed
> SIDs to be specified by name...
I wasn't trying to make a comment about the tool - more about my own
shortcoming... I think it is pretty intuitive now, just that little
quirk about reverting to unknown group type was tough.
> > - if (sid_type != SID_NAME_UNKNOWN) {
> > - if (sid_type != SID_NAME_WKN_GRP) {
>
> Why not just do an explict test on type builtin then...
i thought that was a test on builtin groups...
i screwed the direction of that diff up though so maybe that was
confusing.
> > /* If a new Unix group is specified, check and change */
> > if (group!=NULL) {
> > + if (strncmp(group,"-1", strlen(group)) == 0){
> > + printf("Dissociating unix groups from ntgroup: %s\n",
> > map.nt_name);
> > + map.gid=-1; /*dissociate the unix group*/
>
> Looks like a good idea - but we might to better to just have an option
> to 'disassociate'.
i thought about that but I wasn't sure how to fit it in
maybe a -c "group name" -d option?
> > + printf("The UNIX group: &s does not exist\n",
> > group);
>
> Did you actually compile this? That looks like an aperstand to me, not
> a % (percentage, format qualifier...).
ack that's a typo
it does compile but just prints out &s instead of "users", forgot to
test that bit of code
brad
win2k client and domain groups [Samba as PDC]
Hi there, I'm running into interesting problem with win2k client system joining PDC on Samba. PDC (called DOMAIN) configured with "domain admin group = @dadmins" and client is able to successfully join the domain. Let assume that we're logging in to win2k called COMPUTER as member of the @dadmins. Now, lets open Computer Management -> Local Users and Groups -> Groups -> Administrators The entries will be (this is an example): Administrator (this is local account) DOMAIN\unix_group.2147483404 As far as I understand, record unix_group.[blah-blah] represents @dadmins and shows absence of unix <-> windows groups translation (my guess is this is should be Domain Admins, as a native Windows group). However, if the second entry somehow removed (intruder, mistake, etc.) the user is unable to login: his username/password will be accepted and then he will have continuously restarted explorer. Moreover, if user removed from domain admins group, he is unable to login at all (I assume that this is problem of permissions conflict -- he had full control and no he has limited control, but profile still keeps full control setting). Here is another problem: if you're deleting this DOMAIN entry, you can't create it again: Windows doesn't know anything about unix_group.2147483404. It has Domain Admins, but if you try to add it, client will respond with error -- "no such group". Any comments/suggestion how to fix this? --ivan
Re: Odd error message in winbind
Nir Soffer wrote:
>
> > Nir Soffer wrote:
> > >
> > > > > On a Linux machine, running Samba 2.2.4, we got this
> > error message:
> > > > >
> > > > > Aug 7 01:47:01 node1-mgmt winbindd[7034]: [2002/08/07
> > 01:47:01, 0]
> > > > > rpc_client/cli_pipe.c:rpc_api_pipe(359)
> > > > > Aug 7 01:47:01 node1-mgmt winbindd[7034]: cli_pipe:
> > > > return critical
> > > > > error. Error was SUCCESS - 0
> > > > >
> > > > > Previous to that error message, winbindd ran without fault
> > > > for nearly 30
> > > > > days.
> > > >
> > > > The DC 'went away'. (Which closed the pipe, and left 0
> > in the error
> > > > feild - yes we need a better way do handle this...).
> > >
> > > I guessed something to that effect, but I don't believe something
> > > happened to the DC, that's what's bothering me. I'll need
> > to check that
> > > out.
> > >
> > > So if hit this DEBUG statement
> > > DEBUG(0, ("cli_pipe: return critical error. Error was %s\n",
> > > cli_errstr(cli)));
> > >
> > > When the error is 0 I should:
> > >
> > > DEBUG(0, ("cli_pipe: Critical error - the pipe has closed.
> > The DC has
> > > probably been disconnected") )
> > >
> > > or something?
> > >
> > > need a patch?
> >
> > I'll take a patch that actually does the real job - that code needs to
> > be 'upgraded' to NTSTATUS. Follow the functions, and you will
> > eventually get to 'cli_receive_smb()'. This is what is generating the
> > error - so it should probably get the DEBUG(), and a sensible NTSTATUS
> > value should be returned down the chain.
>
> Tracking down the code leads me at the end to receive_smb, which
> probably returns a false when it fails to receive anything. But then
> again, it could fail on anything, so nailing it down there seems wrong.
>
> client_receive_smb appears to be merely a wrapper for receive_smb...
>
> Ugh. This stuff is hairy. What exactly needs to happen? Does the code
> have to see if there's BOTH an error from client_receive_smb, and if
> there's no status set, and then conclude all it is is a broken link?
If receive_smb fails, then the server has cut the link. At this point
we should unconditionally return a particular NTSTATUS error. I don't
know which one yet - pick one from include/nterr.h
> > It's really the BOOLs everywhere that causes the problem.
>
> I haven't figured that one out yet -
>
> A. What exactly _is_ the construct for keeping a status code, from
> looking at clierrstr I see that there are 3 classes of error message,
> each handled sepreately and differently (RAP messages, whatever the hell
> they may be, NT STATUS messages, and DOS and SMB messages (?!) which are
> apparently handled together? (?!?)
We can be sent either a DOS or an NT error. DOS errors are a pain to
deal with, so we normally convert these to NTSTATUS values
> B. Why not return an int value that some meaning like most C functions
> do?
Thats what the NTSTATUS is, it's a uint32 dressed up in such a way that
it is assignment incompatible with int, becouse we got a *lot* of bugs
with people getting it and BOOL confused, and therefore using the wrong
'if' test on it. (0 for succcess as opposed to 1 for success).
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
Hey, whats up?
My buddies and I were average people, just like you...Then we had our great idea...find young hot girls and proposition them to fool around on video tape.Armed with a camera, a smooth tongue, and a couple of bucks we have made quite a few interesting videos!BEST OF ALL... MY SITE IS 100% FREE!! If this sounds like something of interest to you, http:[EMAIL PROTECTED]";>click here You will be glad you did. If you never want to hear from me again, please click here and I will remove you from all future mailings. - Get your free WebMail account from Sympatico-Lycos at www.sympatico.ca -
Re: NT BDC on SAMBA-LDAP Domain
Nucleo Anti-Virus wrote: > > Does anybody knows about SAM replication in HEAD ?? I need to put a NT > BDC server to work in my SAMBA-LDAP Domain . Not possible in any version of Samba. 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
State of AD join to samba
Ok, at this point, what's in HEAD matches what I've got here. I've checked in all my code so far, so y'all should be able to duplicate the ADS DC stuff I've done. I still don't get through a join, but get more details correct than before. You'll have no chance at this point of doing a netbios-less ADS DC because a win client will expect to get a response via MS's weird CLDAP that right now nmbd will take care of for you. Lots of folks have joined in giving me various bits of information, and I'd like to thank y'all for it...and keep it coming. We've got a long way to go here, but good progress has been made. Jim McDonough IBM Linux Technology Center Samba Team 6 Minuteman Drive Scarborough, ME 04074 USA [EMAIL PROTECTED] [EMAIL PROTECTED] Phone: (207) 885-5565 IBM tie-line: 776-9984
Re: Another showstopper in 2.2.5
On Mon, Aug 12, 2002 at 03:19:49PM +0200, Fredrik Ohrn wrote:
>
>
> Ok, here's another showstopper I have started to get alot over the last
> week.
>
> Average user complains that that he can't open Word/Excel/PowerPoint
> document foo because it is already opened by another (unknown) user.
> But he had no problems working with the document some time ago.
>
> This happens a lot with Win98 clients and sometimes with WinXP but it's
> not as common.
>
>
> After some digging I have figured out that the samba process serving the
> document the first time is dead BUT according to smbstatus samba still
> thinks the process is alive and the file locked...
>
>
> A small example:
>
> [root@olivia ~]# /usr/local/samba/bin/smbstatus | grep lottab
> lottab lottab stdvgl6887 studv-5-118 (129.16.xxx.xxx) Mon Aug 12
>08:31:16 2002
> 6490 DENY_WRITE 0x1 RDONLY NONE
>/olivia/home3/stdvgl/lottab/netscape/rpclsvc_se.dll Mon Aug 12 08:16:33 2002
> 6490 DENY_NONE 0x3 RDWR NONE
>/olivia/home3/stdvgl/lottab/eudora/EudPriv/Ads/Eudora.idx Mon Aug 12 08:16:38 2002
> <... lots more nixed ...>
>
> Lets look for pid 6490
>
> [root@olivia ~]# ps -ef | grep 6490
> root 7240 7150 0 08:40 pts/400:00:00 grep 6490
>
> Not found! Lets look for the username instead:
>
> [root@olivia ~]# ps -ef | grep lottab
> lottab6887 18504 0 08:31 ?00:00:00 /usr/local/samba/bin/smbd -D
>
> Look mom! A new smbd process is now serving this user.
>
>
> There is no trace what so ever in the logfile on why the smbd died.
There is code in locking/locking.c:get_share_modes() to test if a pid
associated with a share entry still exists. If it does not then the entry
is deleted and not returned.
See this code (around line 482) :
/*
* Ensure that each entry has a real process attached.
*/
for (i = 0; i < num_share_modes; ) {
share_mode_entry *entry_p = &shares[i];
if (process_exists(entry_p->pid)) {
DEBUG(10,("get_share_modes: %s\n", share_mode_str(i,
entry_p) ));
i++;
} else {
DEBUG(10,("get_share_modes: deleted %s\n",
share_mode_str(i, entry_p) ));
memcpy( &shares[i], &shares[i+1],
sizeof(share_mode_entry) * (num_share_modes -
i - 1));
num_share_modes--;
del_count++;
}
}
Can you instrument this code for a lower debug level s o you can see
why you are getting share mode entries returned for processes that
no longer exist.
Cheers,
Jeremy.
Re: Fcntl hangs in 2.2.5 on Solaris
On Mon, Aug 12, 2002 at 03:01:14PM -0400, David Collier-Brown wrote: > Ok, I've been looking at portable locking mechanisms and fcntl. > > A Smarter Colleague (Mark) pointed out that there are > scalability issues with fcntl locks on both Solaris > and Linux, but quite different ones. We haven't yet hit any scalability problems with fcntl locks on Linux. We use them in Samba a *lot* with the tdb's. Sorry Dave, as far as I can see this (at least the Samba fcntl issue) is a Solaris only problem :-) :-). > Instead, we've been > working with the posix locks, to make them as robust as possible. > In particular, I'm using pthread_mutex_lock() in my code > at work, to do locking on Linux and Solaris, and have been > reasonably happy with it: I'm planning to shift another > program over from realtime semaphores to pthread_mutex_locks > to make avoiding priority inversions easier. > > This would be a better mechnaism to use for the "spinlocks" > case, removing the sparc-only ldstub calls, and the gcc-only > assembler, in favor of a lock that doesn't spin, and does > have good behavior under evil stresses. > In particular, for anyone who supports EOWNERDEAD, we > can put in under #ifdef EOWNERDEAD a call to a guaranteed cleanup > routine, (pthread_mutex_consistent_np) which will recover the state, > after which it can be straightened out, released or recreated. > It also doesn't spin (;-)) > > So: while it's actually in the workaround code, there is > a robust and low-cost lock we can use. > > I'd like to work with someone who groks the spinlock code > to see if we can do this. The tdb spinlock code is really unsafe to use in a production environment due to the potential to lock up the entire db on abend. Now I know you can make no consistency guarentees on abend even with fcntl locks, but when a process abends with an fcntl lock the lock is at least released to allow others to attempt a cleanup. Please just fix the Solaris fcntl lock problem :-) :-). Jeremy.
NT BDC on SAMBA-LDAP Domain
Does anybody knows about SAM replication in HEAD ?? I need to put a NT BDC server to work in my SAMBA-LDAP Domain . thanks Julio Brasilia/ Brazil
Re: Another showstopper in 2.2.5
On Mon, 12 Aug 2002, Fredrik Ohrn wrote: > > > Ok, here's another showstopper I have started to get alot over the last > week. > > Tonight I'll see if I can figure out a way to force the problem and use > the panic action to get more clues. Does anyone have a good recepie for > 'panic action' that just dumps a backtrace into a logfile? > OK, I've done some more tinkering. I havn't found a better way to trigger this then to open a Word doc, type some, save, sit around, type some, save, sit around. It takes patience... After a while the save fails and Word pops up the following mesage: The save failed due to out of memory or disk space. (F:\foobar\~WRL0005.TMP) In this example the initial smbd has pid 19957, I have rasied it's debug level to 10 with smbcontrol, se the attached logfile. I did the save a Word document dance. Suddenly it freezes for about 30 seconds, then it pops up the mesage. A quick look with smbstatus: [root@olivia bin]# ./smbstatus | grep ohrn ohrn ohrn staff20033 canine (129.16.214.84) Mon Aug 12 14:43:28 2002 19957 DENY_NONE 0x2019f RDWR NONE /olivia/home3/sys/ohrn/foobar/~WRL0005.tmp Mon Aug 12 14:43:26 2002 Notice that I am now served by pid 20033 and pid 19957 is dead. Apparently it's pid 20033 that refuses the save, unfortunatley I don't have any logs since the debug level is reset back to 0. Tomorrow night I'll change it directly in the smb.conf and redo the experiment. The next observation is that pid 19957 didn't crash, atleast not in a way that is caught by 'panic action'. I have double checked my gdb recepie by manually doing kill -SEGV and that works. Options if interest are: oplocks = no, deadtime = 0, keepalive = 30 A correction of the topic, it's v2.2.6-pre1, I forgot that it was still up and running. This is on a linux box running kernel v2.4.19 in case it's of any importance. The client is running Windows XP. So, what do I do next? Regards, Fredrik -- "It is easy to be blinded to the essential uselessness of computers by the sense of accomplishment you get from getting them to work at all." - Douglas Adams Fredrik Öhrn Chalmers University of Technology [EMAIL PROTECTED] Sweden smbd.canine.log.gz Description: GNU Zip compressed data
Re: Fcntl hangs in 2.2.5 on Solaris
Ok, I've been looking at portable locking mechanisms and fcntl. A Smarter Colleague (Mark) pointed out that there are scalability issues with fcntl locks on both Solaris and Linux, but quite different ones. Instead, we've been working with the posix locks, to make them as robust as possible. In particular, I'm using pthread_mutex_lock() in my code at work, to do locking on Linux and Solaris, and have been reasonably happy with it: I'm planning to shift another program over from realtime semaphores to pthread_mutex_locks to make avoiding priority inversions easier. This would be a better mechnaism to use for the "spinlocks" case, removing the sparc-only ldstub calls, and the gcc-only assembler, in favor of a lock that doesn't spin, and does have good behavior under evil stresses. In particular, for anyone who supports EOWNERDEAD, we can put in under #ifdef EOWNERDEAD a call to a guaranteed cleanup routine, (pthread_mutex_consistent_np) which will recover the state, after which it can be straightened out, released or recreated. It also doesn't spin (;-)) So: while it's actually in the workaround code, there is a robust and low-cost lock we can use. I'd like to work with someone who groks the spinlock code to see if we can do this. --dave -- David Collier-Brown, | Always do right. This will gratify Performance & Engineering | some people and astonish the rest. Americas Customer Engineering, | -- Mark Twain (905) 415-2849 | [EMAIL PROTECTED]
Logging on to Win2k Machine which is part of Samba domain
Hello, I am seeing some strange behavior from Samba and I am unable to determine if it is a Samba bug or a configuration problem. I am running Samba 2.2.5 on a SuSE 7.2 server. I have several machines running Win2k Service Pack 2 and 1 running Win2k service pack 3. (I am not deploying Service Pack 3 until I have tested it thoroughly.) The Samba server is acting as a primary domain controller. The Win2k machines have been joined to the domain so their machine accounts and machine passwords exist in both /etc/passwd and the samba password database. I am using just Samba, no PAM or LDAP. When the machine reboots and the user is asked to enter his username and password, the error "The system cannot log you on to the domain because the systems computer account in its primary domain is missing or the password on that account is incorrect." Haveing searched Deja and seen that this error can be caused by incorrect permissiosn on [NetLogon], I proceeded to check permissions. [NetLogon] is defined as /home/%U I checked to make sure that the guest account (ftp) is in /etc/passwd and the Samba password database. I then checked the permissions for /home/ftp to ensure that in fact the user ftp has full read/write/execute permissions. Still the problem exists. I also made sure that requiresignandseal in the registry was disabled and that the local security policys on all the machines had encrypted communications disabled. In looking at log.nmbd I see lots of entries for process_logon_packet(69) with code = 0x12. I have not yet found anything relevant to that. I did notice that if I do not try to log on to the computer imediately after reboot, but let the computer sit for 30-60 seconds at the logon prompt, I have a much easier time logging on to the computer. In either case, with enough retries, I can log on to the computer and thus into the domain. This is what leads me to believe the problem is not a configuration problem. Bill Miller [EMAIL PROTECTED]
Re: Another showstopper in 2.2.5
Mike Gerdts wrote: > On the surface, it appears as though a panic action program that does > lock scrubbing would be useful. I'm also discussing a posix add-on than supports returning EWNERDEAD, with one of My Smarter Colleages[tm]... --dave -- David Collier-Brown, | Always do right. This will gratify Performance & Engineering | some people and astonish the rest. Americas Customer Engineering, | -- Mark Twain (905) 415-2849 | [EMAIL PROTECTED]
Re: Another showstopper in 2.2.5
Le Lundi 12 Août 2002 17:39, Mike Gerdts a écrit : > On Mon, 2002-08-12 at 10:54, David Collier-Brown wrote: > > Fredrik Ohrn wrote: > > > OK, I'll try 30 instead of the default 300. But I don't expect it to > > > help, in this case it seems that it's the smbd process that blows up, > > > not the client. > > > > Ok, I was afraid of that! > > > > Blown SMBDs are Bad Things (:-)) > > I have run into this same problem from time to time with 2.2.2. I was > hoping that the upgrade to 2.2.5 that I did yesterday would fix it... > > On the surface, it appears as though a panic action program that does > lock scrubbing would be useful. I envision a standalone program that > takes a filename and pid as an argument. If it encouters a lock > belonging to the given pid, it removes the lock from the database. > > Perhaps if the program is given only one argument (the lock file) it > traverses the tdb checking to see if each pid mentioned is alive. > > What would this break? > > Mike I thought that this was already done internally at start of the new smbd for a client ? It scans the locking.tdb to get rid of old locks. I still think the code that deals with theses locks is to be reviewed deeply. As I showed in a post concerning fifo files, it appears locks are not always handled at the correct moment... Pascal
samba-2.2.5/source/lib/nameresolve.c:resolve_wins() only tries once?
am i correct in supposing that a call to internal_resolve_name() that gets dispatched to resolve_wins() will only take a shot at one WINS server before returning False? i'm thinking it would be nice if this weren't the case, e.g., if you have security = domain name resolve order = wins wins server = wins1 wins2 wins3 password server = * and a client connects, a new smbd (with an unexpurgated copy of the wins server list) gets forked, the smbd can't locate a domain con- troller because wins1 is down so get_dc_list() returns a failed lookup status from internal_resolve_name()'s 0x1c and 0x1b queries to wins1, so the client is denied, client goes away, another client connects, another forked smbd tries contacting wins1 etc. or maybe i'm confused about the authentication/domain_client_validate() process, in which case, please let me know. in any case, i suppose there are better configuration options
Re: Another showstopper in 2.2.5
On Mon, 2002-08-12 at 10:54, David Collier-Brown wrote: > Fredrik Ohrn wrote: > > > OK, I'll try 30 instead of the default 300. But I don't expect it to help, > > in this case it seems that it's the smbd process that blows up, not the > > client. > Ok, I was afraid of that! > > Blown SMBDs are Bad Things (:-)) I have run into this same problem from time to time with 2.2.2. I was hoping that the upgrade to 2.2.5 that I did yesterday would fix it... On the surface, it appears as though a panic action program that does lock scrubbing would be useful. I envision a standalone program that takes a filename and pid as an argument. If it encouters a lock belonging to the given pid, it removes the lock from the database. Perhaps if the program is given only one argument (the lock file) it traverses the tdb checking to see if each pid mentioned is alive. What would this break? Mike
Re: Another showstopper in 2.2.5
Fredrik Ohrn wrote: > OK, I'll try 30 instead of the default 300. But I don't expect it to help, > in this case it seems that it's the smbd process that blows up, not the > client. Ok, I was afraid of that! Blown SMBDs are Bad Things (:-)) --dave -- David Collier-Brown, | Always do right. This will gratify Performance & Engineering | some people and astonish the rest. Americas Customer Engineering, | -- Mark Twain (905) 415-2849 | [EMAIL PROTECTED]
Re: Another showstopper in 2.2.5
On Mon, 12 Aug 2002, David Collier-Brown wrote: > Fredrik Ohrn wrote: > > > Look mom! A new smbd process is now serving this user. > > > > There is no trace what so ever in the logfile on why the smbd died. > > > Hmmn: could you set keepalive = 30, and see if > samba cleans up and releases the locks held? > I'm almost about to reccomend keepalive = 3600 > as a default... > > It's an option to clean up after clients which > exploded, blue-screened or just started to flake. > Alas, it tends to hide PC problems by working > around them. > OK, I'll try 30 instead of the default 300. But I don't expect it to help, in this case it seems that it's the smbd process that blows up, not the client. /Fredrik -- "It is easy to be blinded to the essential uselessness of computers by the sense of accomplishment you get from getting them to work at all." - Douglas Adams Fredrik Öhrn Chalmers University of Technology [EMAIL PROTECTED] Sweden
Re: Another showstopper in 2.2.5
Fredrik Ohrn wrote: > Look mom! A new smbd process is now serving this user. > > There is no trace what so ever in the logfile on why the smbd died. Hmmn: could you set keepalive = 30, and see if samba cleans up and releases the locks held? I'm almost about to reccomend keepalive = 3600 as a default... It's an option to clean up after clients which exploded, blue-screened or just started to flake. Alas, it tends to hide PC problems by working around them. --dave -- David Collier-Brown, | Always do right. This will gratify Performance & Engineering | some people and astonish the rest. Americas Customer Engineering, | -- Mark Twain (905) 415-2849 | [EMAIL PROTECTED]
RE: Odd error message in winbind
> Nir Soffer wrote:
> >
> > > > On a Linux machine, running Samba 2.2.4, we got this
> error message:
> > > >
> > > > Aug 7 01:47:01 node1-mgmt winbindd[7034]: [2002/08/07
> 01:47:01, 0]
> > > > rpc_client/cli_pipe.c:rpc_api_pipe(359)
> > > > Aug 7 01:47:01 node1-mgmt winbindd[7034]: cli_pipe:
> > > return critical
> > > > error. Error was SUCCESS - 0
> > > >
> > > > Previous to that error message, winbindd ran without fault
> > > for nearly 30
> > > > days.
> > >
> > > The DC 'went away'. (Which closed the pipe, and left 0
> in the error
> > > feild - yes we need a better way do handle this...).
> >
> > I guessed something to that effect, but I don't believe something
> > happened to the DC, that's what's bothering me. I'll need
> to check that
> > out.
> >
> > So if hit this DEBUG statement
> > DEBUG(0, ("cli_pipe: return critical error. Error was %s\n",
> > cli_errstr(cli)));
> >
> > When the error is 0 I should:
> >
> > DEBUG(0, ("cli_pipe: Critical error - the pipe has closed.
> The DC has
> > probably been disconnected") )
> >
> > or something?
> >
> > need a patch?
>
> I'll take a patch that actually does the real job - that code needs to
> be 'upgraded' to NTSTATUS. Follow the functions, and you will
> eventually get to 'cli_receive_smb()'. This is what is generating the
> error - so it should probably get the DEBUG(), and a sensible NTSTATUS
> value should be returned down the chain.
Tracking down the code leads me at the end to receive_smb, which
probably returns a false when it fails to receive anything. But then
again, it could fail on anything, so nailing it down there seems wrong.
client_receive_smb appears to be merely a wrapper for receive_smb...
Ugh. This stuff is hairy. What exactly needs to happen? Does the code
have to see if there's BOTH an error from client_receive_smb, and if
there's no status set, and then conclude all it is is a broken link?
> It's really the BOOLs everywhere that causes the problem.
I haven't figured that one out yet -
A. What exactly _is_ the construct for keeping a status code, from
looking at clierrstr I see that there are 3 classes of error message,
each handled sepreately and differently (RAP messages, whatever the hell
they may be, NT STATUS messages, and DOS and SMB messages (?!) which are
apparently handled together? (?!?)
B. Why not return an int value that some meaning like most C functions
do?
Nir.
--
Nir Soffer -=- Software Engineer, Exanet Inc. -=-
"Father, why are all the children weeping? / They are merely crying son
O, are they merely crying, father? / Yes, true weeping is yet to come"
-- Nick Cave and the Bad Seeds, The Weeping Song
Another showstopper in 2.2.5
Ok, here's another showstopper I have started to get alot over the last week. Average user complains that that he can't open Word/Excel/PowerPoint document foo because it is already opened by another (unknown) user. But he had no problems working with the document some time ago. This happens a lot with Win98 clients and sometimes with WinXP but it's not as common. After some digging I have figured out that the samba process serving the document the first time is dead BUT according to smbstatus samba still thinks the process is alive and the file locked... A small example: [root@olivia ~]# /usr/local/samba/bin/smbstatus | grep lottab lottab lottab stdvgl6887 studv-5-118 (129.16.xxx.xxx) Mon Aug 12 08:31:16 2002 6490 DENY_WRITE 0x1 RDONLY NONE /olivia/home3/stdvgl/lottab/netscape/rpclsvc_se.dll Mon Aug 12 08:16:33 2002 6490 DENY_NONE 0x3 RDWR NONE /olivia/home3/stdvgl/lottab/eudora/EudPriv/Ads/Eudora.idx Mon Aug 12 08:16:38 2002 <... lots more nixed ...> Lets look for pid 6490 [root@olivia ~]# ps -ef | grep 6490 root 7240 7150 0 08:40 pts/400:00:00 grep 6490 Not found! Lets look for the username instead: [root@olivia ~]# ps -ef | grep lottab lottab6887 18504 0 08:31 ?00:00:00 /usr/local/samba/bin/smbd -D Look mom! A new smbd process is now serving this user. There is no trace what so ever in the logfile on why the smbd died. Tonight I'll see if I can figure out a way to force the problem and use the panic action to get more clues. Does anyone have a good recepie for 'panic action' that just dumps a backtrace into a logfile? Regards, Fredrik -- "It is easy to be blinded to the essential uselessness of computers by the sense of accomplishment you get from getting them to work at all." - Douglas Adams Fredrik Öhrn Chalmers University of Technology [EMAIL PROTECTED] Sweden
Network Neighbourhood listing in SAMBA PDC
Hi All, I have been using samba 2.2.1a as the PDC till now without any problem. But for the last few days i am not getting network neighbourhood windows machines listing. I have the options OS level 255 Domain master yes Preferred Master yes Local master yes in my smb.conf. FYI this samba is also acting as wins server. Here interested thing is when i searches for some m/c(in client windows ), it gives me that without any problem. Can someone enlighten on this issue. Regards, -Yash -- Yashpal Nagar Systems Administrator Delhicall Centres 'Gurgaon' Ph 0124-6223849 , cell 9811499273 ---
Re: Odd error message in winbind
Nir Soffer wrote:
>
> > > On a Linux machine, running Samba 2.2.4, we got this error message:
> > >
> > > Aug 7 01:47:01 node1-mgmt winbindd[7034]: [2002/08/07 01:47:01, 0]
> > > rpc_client/cli_pipe.c:rpc_api_pipe(359)
> > > Aug 7 01:47:01 node1-mgmt winbindd[7034]: cli_pipe:
> > return critical
> > > error. Error was SUCCESS - 0
> > >
> > > Previous to that error message, winbindd ran without fault
> > for nearly 30
> > > days.
> >
> > The DC 'went away'. (Which closed the pipe, and left 0 in the error
> > feild - yes we need a better way do handle this...).
>
> I guessed something to that effect, but I don't believe something
> happened to the DC, that's what's bothering me. I'll need to check that
> out.
>
> So if hit this DEBUG statement
> DEBUG(0, ("cli_pipe: return critical error. Error was %s\n",
> cli_errstr(cli)));
>
> When the error is 0 I should:
>
> DEBUG(0, ("cli_pipe: Critical error - the pipe has closed. The DC has
> probably been disconnected") )
>
> or something?
>
> need a patch?
I'll take a patch that actually does the real job - that code needs to
be 'upgraded' to NTSTATUS. Follow the functions, and you will
eventually get to 'cli_receive_smb()'. This is what is generating the
error - so it should probably get the DEBUG(), and a sensible NTSTATUS
value should be returned down the chain.
It's really the BOOLs everywhere that causes the problem.
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: Odd error message in winbind
> > On a Linux machine, running Samba 2.2.4, we got this error message:
> >
> > Aug 7 01:47:01 node1-mgmt winbindd[7034]: [2002/08/07 01:47:01, 0]
> > rpc_client/cli_pipe.c:rpc_api_pipe(359)
> > Aug 7 01:47:01 node1-mgmt winbindd[7034]: cli_pipe:
> return critical
> > error. Error was SUCCESS - 0
> >
> > Previous to that error message, winbindd ran without fault
> for nearly 30
> > days.
>
> The DC 'went away'. (Which closed the pipe, and left 0 in the error
> feild - yes we need a better way do handle this...).
I guessed something to that effect, but I don't believe something
happened to the DC, that's what's bothering me. I'll need to check that
out.
So if hit this DEBUG statement
DEBUG(0, ("cli_pipe: return critical error. Error was %s\n",
cli_errstr(cli)));
When the error is 0 I should:
DEBUG(0, ("cli_pipe: Critical error - the pipe has closed. The DC has
probably been disconnected") )
or something?
need a patch?
> It looks like the PDC has changed the machine account password on the
> account, your local machine name has changed or the account on the DC
> has been deleted. Could the DC have been restored from a backup, with
> 'old' passwords?
I believe not... As I said, I will have to check that out.
> Anyway, try a rejoin and see if that helps.
I was hoping to avoid a machine account reset, or a rejoin, but I
assumed that's what I'll have to do anyway.
Thanks!
Nir.
--
Nir Soffer -=- Software Engineer, Exanet Inc. -=-
"Father, why are all the children weeping? / They are merely crying son
O, are they merely crying, father? / Yes, true weeping is yet to come"
-- Nick Cave and the Bad Seeds, The Weeping Song
Re: Odd error message in winbind
Nir Soffer wrote: > > Hello! > > On a Linux machine, running Samba 2.2.4, we got this error message: > > Aug 7 01:47:01 node1-mgmt winbindd[7034]: [2002/08/07 01:47:01, 0] > rpc_client/cli_pipe.c:rpc_api_pipe(359) > Aug 7 01:47:01 node1-mgmt winbindd[7034]: cli_pipe: return critical > error. Error was SUCCESS - 0 > > Previous to that error message, winbindd ran without fault for nearly 30 > days. The DC 'went away'. (Which closed the pipe, and left 0 in the error feild - yes we need a better way do handle this...). > After that error message, we got a few of these sequences: > > Aug 8 10:19:25 node1-mgmt winbindd[7034]: [2002/08/08 10:19:25, 0] > libsmb/cli_netlogon.c:new_cli_nt_setup_creds(209) > Aug 8 10:19:25 node1-mgmt winbindd[7034]: new_cli_nt_setup_creds: > auth2 challenge failed NT_STATUS_ACCESS_DENIED > Aug 8 10:19:25 node1-mgmt winbindd[7034]: [2002/08/08 10:19:25, 0] > nsswitch/winbindd_cm.c:cm_get_netlogon_cli(796) > Aug 8 10:19:25 node1-mgmt winbindd[7034]: error connecting to domain > password server: NT_STATUS_ACCESS_DENIED > > I'm assuming something in winbindd's state got iffy, and then > authentication failed. I don't have access to the PDC to see if maybe > the error was caused by an event there, but I was wondering if anyone > knows what's going on there. It looks like the PDC has changed the machine account password on the account, your local machine name has changed or the account on the DC has been deleted. Could the DC have been restored from a backup, with 'old' passwords? Anyway, try a rejoin and see if that helps. 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: wins lookup is broken
Hey Don, Thanks for replying, fortunatly I just discovered that the windows admin gave me bogus information regarding wins server, have entered the right ip now and it works like a treat. Thanks for the info Bryan -Original Message- From: MCCALL,DON (HP-USA,ex1) [mailto:[EMAIL PROTECTED]] Sent: 08 August 2002 15:54 To: 'Hunt, Bryan'; '[EMAIL PROTECTED]' Subject: RE: wins lookup is broken Hello brian, as far as I know, wins lookup works fine. You ARE getting to the wins server, it is just saying NO, it doesn't have the name HUNTB<0x20> registered. Are you sure that the computer HUNTB is actually registering with the wins server? if it's a MS wins server, you can use the wins mgmt gui to LOOK at the names registered, and verify that HUNTB is amoung them. If it's a SAMBA wins server, you should be able to do a strings command on the wins.dat file and see something like HUNTB#20 ## IPADDR You might want to post your smb.conf file as well (after stripping the comments, to avoid list clutter)... Hope this helps, Don -Original Message- From: Hunt, Bryan [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 08, 2002 3:36 To: '[EMAIL PROTECTED]' Subject: wins lookup is broken Hello All, I am on a network. It has an address of 192.168.2.0. It has a master browser 192.168.2.128 which is running a wins server on port 137. I have confirmed this by running nmap against the server and it is running ok. If I run the following command ::: smbclient -d10 -L huntb -U huntb -N, I get the output shown below. Notice the way it tries 3 times to send the request to the wins server ... This is how many times it is set to do it in the name_query function in namequery.c . It then gives up and eventually does name resolution via broadcast to the 192.168.2.255 address. Even if I set the box up as a wins server and it is querying itself it will produce the same result. Does anyone know if the wins name resolution is broken and has it been fixed in any cvs version of the code ? I've been reading through the code but my "c" is fairly crap so I'm just getting the general jist of things. The reason it would be cool if this were to be working is that it would mean the people in linux unfriendly offices could use konqueror (which uses libsmb) to connect to machines by smb name without being limited to their own subnet. Kindest Regards Bryan Hunt added interface ip=192.168.2.112 bcast=192.168.2.255 nmask=255.255.255.0 Client started (version 2.0.10). resolve_wins: Attempting wins lookup for name huntb<0x20> bind succeeded on port 0 nmb packet from 192.168.2.128(137) header: id=10376 opcode=Query(0) response=No header: flags: bcast=No rec_avail=No rec_des=Yes trunc=No auth=No header: rcode=0 qdcount=1 ancount=0 nscount=0 arcount=0 question: q_name=HUNTB<20> q_type=32 q_class=1 Sending a packet of len 50 to (192.168.2.128) on port 137 nmb packet from 192.168.2.128(137) header: id=10376 opcode=Query(0) response=No header: flags: bcast=No rec_avail=No rec_des=Yes trunc=No auth=No header: rcode=0 qdcount=1 ancount=0 nscount=0 arcount=0 question: q_name=HUNTB<20> q_type=32 q_class=1 Sending a packet of len 50 to (192.168.2.128) on port 137 nmb packet from 192.168.2.128(137) header: id=10376 opcode=Query(0) response=No header: flags: bcast=No rec_avail=No rec_des=Yes trunc=No auth=No header: rcode=0 qdcount=1 ancount=0 nscount=0 arcount=0 question: q_name=HUNTB<20> q_type=32 q_class=1 Sending a packet of len 50 to (192.168.2.128) on port 137 resolve_hosts: Attempting host lookup for name huntb<0x20> resolve_lmhosts: Attempting lmhosts lookup for name huntb<0x20> getlmhostsent: lmhost entry: 127.0.0.1 localhost resolve_bcast: Attempting broadcast lookup for name huntb<0x20> bind succeeded on port 0 nmb packet from 192.168.2.255(137) header: id=10377 opcode=Query(0) response=No header: flags: bcast=Yes rec_avail=No rec_des=Yes trunc=No auth=No header: rcode=0 qdcount=1 ancount=0 nscount=0 arcount=0 question: q_name=HUNTB<20> q_type=32 q_class=1 Sending a packet of len 50 to (192.168.2.255) on port 137 read_udp_socket: lastip 192.168.2.111 lastport 137 read: 62 parse_nmb: packet id = 10377 Received a packet of len 62 from (192.168.2.111) port 137 nmb packet from 192.168.2.111(137) header: id=10377 opcode=Query(0) response=Yes header: flags: bcast=No rec_avail=No rec_des=Yes trunc=No auth=Yes header: rcode=0 qdcount=0 ancount=1 nscount=0 arcount=0 answers: nmb_name=HUNTB<20> rr_type=32 rr_class=1 ttl=30 answers 0 char `o hex 6000C0A8026F Got a positive name query response from 192.168.2.111 ( 192.168.2.111 ) Connecting to 192.168.2.111 at port 139 write_socket(3,76) write_socket(3,76) wrote 76 Sent session request got smb length of 0 size=0 smb_com=0x0 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=0 smb_flg2=0 smb_tid=0 smb_pid=0 smb_uid=0 smb_mid=0 smt_wct=0 smb_bcc=0 session request ok write_socket(3,168) write_socket(3,1
Odd error message in winbind
Hello! On a Linux machine, running Samba 2.2.4, we got this error message: Aug 7 01:47:01 node1-mgmt winbindd[7034]: [2002/08/07 01:47:01, 0] rpc_client/cli_pipe.c:rpc_api_pipe(359) Aug 7 01:47:01 node1-mgmt winbindd[7034]: cli_pipe: return critical error. Error was SUCCESS - 0 Previous to that error message, winbindd ran without fault for nearly 30 days. After that error message, we got a few of these sequences: Aug 8 10:19:25 node1-mgmt winbindd[7034]: [2002/08/08 10:19:25, 0] libsmb/cli_netlogon.c:new_cli_nt_setup_creds(209) Aug 8 10:19:25 node1-mgmt winbindd[7034]: new_cli_nt_setup_creds: auth2 challenge failed NT_STATUS_ACCESS_DENIED Aug 8 10:19:25 node1-mgmt winbindd[7034]: [2002/08/08 10:19:25, 0] nsswitch/winbindd_cm.c:cm_get_netlogon_cli(796) Aug 8 10:19:25 node1-mgmt winbindd[7034]: error connecting to domain password server: NT_STATUS_ACCESS_DENIED I'm assuming something in winbindd's state got iffy, and then authentication failed. I don't have access to the PDC to see if maybe the error was caused by an event there, but I was wondering if anyone knows what's going on there. Thanks, Nir. -- Nir Soffer -=- Software Engineer, Exanet Inc. -=- "Father, why are all the children weeping? / They are merely crying son O, are they merely crying, father? / Yes, true weeping is yet to come" -- Nick Cave and the Bad Seeds, The Weeping Song
