RE: svn commit: samba r15333 - in branches/SAMBA_3_0/source: .
Jeremy, I went back to the C manual and read up on this. Declaring a function that takes no arguments by using an empty list (as in ()) is the nonprototyped form. Declaring the same function by using the a list consisting only of (void) is the prototyped form. Your change is fine. Prototypes are good. I guess my PL/I was showing thru. I apologize. Unfortunately, both our in-house C compiler and GCC both passed the nonprototyped form. Who had the compiler that barfed at it? PG -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Saturday, April 29, 2006 7:34 PM To: [EMAIL PROTECTED] Subject: svn commit: samba r15333 - in branches/SAMBA_3_0/source: . Author: jra Date: 2006-04-29 23:33:39 + (Sat, 29 Apr 2006) New Revision: 15333 WebSVN: http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=revroot=sambarev=1533 3 Log: Paulg broke the function prototyping of decl_static_XX. Needs to be (void), not (). Paulg please check this. Jeremy. Modified: branches/SAMBA_3_0/source/aclocal.m4 Changeset: Modified: branches/SAMBA_3_0/source/aclocal.m4 === --- branches/SAMBA_3_0/source/aclocal.m42006-04-29 23:33:36 UTC (rev 15332) +++ branches/SAMBA_3_0/source/aclocal.m42006-04-29 23:33:39 UTC (rev 15333) @@ -57,7 +57,7 @@ string_shared_modules=$string_shared_modules $1 elif test x$DEST = xSTATIC; then [init_static_modules_]translit([$4], [A-Z], [a-z])=$[init_static_modules_]translit([$4], [A-Z], [a-z]) $1_init(); - [decl_static_modules_]translit([$4], [A-Z], [a-z])=$[decl_static_modules_]translit([$4], [A-Z], [a-z]) extern NTSTATUS $1_init(); + [decl_static_modules_]translit([$4], [A-Z], [a-z])=$[decl_static_modules_]translit([$4], [A-Z], [a-z]) extern NTSTATUS $1_init(void); string_static_modules=$string_static_modules $1 $4_STATIC=$$4_STATIC $2 AC_SUBST($4_STATIC)
RE: svn commit: samba r11376 - in trunk/source: .
Ooops. Thanks. Will try not to forget this in the future. PG -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] rg] On Behalf Of [EMAIL PROTECTED] Sent: Friday, October 28, 2005 12:54 PM To: [EMAIL PROTECTED] Subject: svn commit: samba r11376 - in trunk/source: . Author: jra Date: 2005-10-28 16:54:18 + (Fri, 28 Oct 2005) New Revision: 11376 WebSVN: http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=revroot=samb arev=11376 Log: Janitor for paulg - ensure the HEAD versions are updated also. Jeremy. Modified: trunk/source/config.guess trunk/source/config.sub Changeset: Sorry, the patch is too large (1593 lines) to include; please use WebSVN to see it! WebSVN: http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=revroot=samb arev=11376
[Samba] RE: CRLF -- LF
No, I don't. But I do know that Samba provides transparent file access -- it has no idea what data is in the files it offers to the clients. It could be a database, a JPEG, a text document, or an executable program. What you suggest would be an extremely bad idea. You need better clients -- it is the clients that interpret the contents of the file. Samba is just another file access method. In the future, do not send blanket email to the Samba developers. Post your questions to the public [EMAIL PROTECTED] mailing list, and read previous responses at the list archives. See http://lists.samba.org for details. PG -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 27, 2005 2:22 PM To: [EMAIL PROTECTED] Subject: CRLF -- LF Hi Paul, I'm trying to set up a samba envirment beetwen a PC (Windows 2000) and a server (UNIX solaris 9.0). When a user is copying a text file, Samba should use ASCII when the file is copied so the file will only have LF (LineFeed) when the file is copied to the server. When the user is copy from UNIX to PC the file will have both CR (CarragieReturn) and LF. When images are copied, samba should use Binary mode. Do you know how I shall do to make this work? Best Regards! Magnus -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
[Samba] FW: Help The Procedure Number is out of range - v2.2.8a
If anyone can help Rudolphus, please reply to him and cc this list. Please do not reply to me personally. Thanks PG -Original Message- From: Rudolphus Wagenaar [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 8:07 AM To: 'Green, Paul' Subject: RE: Help The Procedure Number is out of range - v2.2.8a Hello mr green I have been strugeling voor week of 3 with this problem. i want to have an xp machine to jion mij samba pdc. i have followed the instructions on the internet . made a machine account , made users in samba and linux. edit the registry of xp and joind mij domain whit the user account with root and password. this work well. but when i reboot and a user will login, there is an error generated on de xp machine . the procedure number is out of range. i,m running suse 8.2 wiht samba 2.28a the error message is: the procedure number is out of range. do you now what to do thanks Rudolphus -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
[Samba] FW: Samba Linux and Windows 2000 Server
-Original Message- From: Ilkka Valkonen [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 7:48 AM To: [EMAIL PROTECTED] Subject: Samba Linux and Windows 2000 Server Dear Mr. Green, I have find, that You have good knowledge of Samba. If You have time, can You answer to following question: We have in or net one Windows NT 4.0 server and Windows 2000 server. With Samba I can get connection to NT server but with Windows 2000 server with sbmclient from Linux I get message connection refused. Is there some services, which must be used in Windows 2000 server or is the reason, that this Windows 2000 server is our Domain controller. Best Regards Ilkka Valkonen -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
[Samba] FW: Besoin d'aide au sujet de swat
Can anyone help out Marie-Christine?
Thanks
PG
-Original Message-
From: Marie-Christine DRACK [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 04, 2003 8:54 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Besoin d'aide au sujet de swat
bonjour,
je vous écris car je n'arrive pas à me connecter à swat alors que le fichier
est configurer normalement.Voici mon fichier swat, a tout hasard:
service swat
{
port = 901
socket_type = stream
wait = no
only_from = 127.0.0.1
user = root
server = /usr/sbin/swat
log_on_failure += USERID
disable = no
}
Je n'accede a swat que depuis mon serveur.
Par ailleur j'utilise red hat 8.0 d'où la version des packages samba est
2.2.5-10.
Pouvez-vous m'aidiquer les rectification que je devrais faire afin que cela
fonctionne.
Merci d'avance car c'est une installation que je dois présenter demain.
--
To unsubscribe from this list go to the following URL and read the
instructions: http://lists.samba.org/mailman/listinfo/samba
RE: CVS update: sambaweb
You are correct! Thanks. PG -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, May 05, 2003 8:25 PM To: [EMAIL PROTECTED] Subject: CVS update: sambaweb Date: Tue May 6 00:25:07 2003 Author: mimir Update of /home/cvs/sambaweb In directory dp.samba.org:/tmp/cvs-serv608 Modified Files: samba.html Log Message: A few typo (specifically in Marc's last name) fixes. I hope I do correctly remember it's Stratus port, not Stratos... Rafal Revisions: samba.html 1.188 = 1.189 http://www.samba.org/cgi-bin/cvsweb/sambaweb/samba.html?r1=1.188r2=1.189
RE: [SECURITY] Samba 2.2.8 available for download
Andrew Bartlett [mailto:[EMAIL PROTECTED] wrote: On Mon, 2003-03-31 at 06:12, Green, Paul wrote: Green, Paul [mailto:[EMAIL PROTECTED] wrote: The 2.2.8 release notes say: A buffer overrun condition exists in the SMB/CIFS packet fragment re-assembly code in smbd which would allow an attacker to cause smbd to overwrite arbitrary areas of memory in its own process address space. This could allow a skilled attacker to inject binary specific exploit code into smbd. I have written a short test case (available upon request) to confirm that Stratus VOS, when running on the HP PA-RISC hardware, is not susceptible to such an attack. While such an attack can indeed be used to insert code onto the VOS stack, as soon as the processor attempts to begin executing the code it will take a no-execute permission fault or an invalid-page fault. Therefore, the last sentence of this warning in the 2.2.8 release notes about inject[ing] binary specific exploit code into smbd does not apply to VOS on HP PA-RISC. As other experts have noted, there are probably other OS/Hardware combinations that are also immune to this attack. I hope other maintainers will post such information so that we can have a public record, and not needlessly scare our customers. I would not be so confident. You don't need to modify the code that will be executed, or cause a jump to your exploit to cause mischief. If you can overwrite an arbitrary position in memory, I'm sure you can find some variable that is critical to Samba's internal state, and go from there. I agree with your comment, but in my defense, I was trying to respond to the comment in the release notes about injecting binary-specific exploit code. That can't happen on VOS when it is running on PA-RISC. We're in the process of porting VOS to the Intel Pentium family, and one of the things we're investigating is how to prevent this same attack on that chip. We're reasonably confident we'll be able to prevent this attack there, too. I think most of the attempts to attack Samba on VOS would result in denial of service, but I agree it is possible that someone could get Samba to bypass one of its internal checks. I'm far more concerned about the issue of injecting binary-specific code, because a successful attack of that type would open up the entire resources of the machine to the attacker. Having said all this, because some of my customers are interested in receiving the 2.2.x version of Samba for VOS, and because the 2.2.x version has the fix for the buffer overruns, and also because 3.0 is not yet ready for prime time, I hope that the patches I'm submitting to 2.2.x will be applied. I'm willing to apply them myself, and monitor the build farm for any fallout, if I'm granted access. plug I've been porting Samba to VOS since version 2.0.5, working on POSIX and open-source software since 1996, and been a software developer since 1969. I have extensive experience in operating systems and compilers and have been the architect and lead developer for the Stratus VOS POSIX environment. I have made it a rule to test all patches on both VOS and Solaris before submitting them to samba-technical. I'm also the maintainer of the ports of Perl and OpenSSL to VOS, among others. /plug Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Technologies, Maynard, MA USA Voice: +1 978-461-7557; FAX: +1 978-461-3610
[patch] Fix source/Makefile.in to clean up everything
The everything target makes some additional files that are not cleaned-up by make clean. This patch corrects the oversight. It should be applied to both head and 3_0. Tested today by me on Stratus VOS. Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Technologies, Maynard, MA USA Voice: +1 978-461-7557; FAX: +1 978-461-3610 Speaking from Stratus not for Stratus diff -urp old/samba/source/Makefile.in new/samba/source/Makefile.in --- old/samba/source/Makefile.inFri Mar 28 14:26:56 2003 +++ new/samba/source/Makefile.inSun Mar 30 14:20:12 2003 @@ -129,6 +129,8 @@ TORTURE_PROGS = bin/[EMAIL PROTECTED]@ b BIN_PROGS = $(BIN_PROGS1) $(BIN_PROGS2) $(BIN_PROGS3) @EXTRA_BIN_PROGS@ +EVERYTHING_PROGS = bin/[EMAIL PROTECTED]@ bin/[EMAIL PROTECTED]@ bin/[EMAIL PROTECTED]@ + SHLIBS = @SHLIB_PROGS@ @LIBSMBCLIENT@ SCRIPTS = $(srcdir)/script/smbtar $(srcdir)/script/addtosmbpass $(srcdir)/script/convert_smbpasswd \ @@ -1184,7 +1186,8 @@ TOPFILES=dynconfig.o dynconfig.po clean: delheaders python_clean -rm -f core */*~ *~ */*.o */*.po */*.po32 */[EMAIL PROTECTED]@ \ - $(TOPFILES) $(BIN_PROGS) $(SBIN_PROGS) $(MODULES) $(TORTURE_PROGS) $(LIBSMBCLIENT) .headers.stamp + $(TOPFILES) $(BIN_PROGS) $(SBIN_PROGS) $(MODULES) $(TORTURE_PROGS) \ + $(LIBSMBCLIENT) $(EVERYTHING_PROGS) .headers.stamp # This is quite ugly actually.. But we need to make # sure the changes to include/config.h are used. @@ -1279,7 +1282,7 @@ ctags: ctags `find $(srcdir) -name *.[ch] | grep -v /CVS/` realclean: clean delheaders - -rm -f config.log $(BIN_PROGS) $(MODULES) $(SBIN_PROGS) bin/.dummy script/findsmb + -rm -f config.log bin/.dummy script/findsmb distclean: realclean -rm -f include/stamp-h
[patch] Fix samba_2_2 to build on Stratus VOS
This patch back-ports Makefile.in and configure.in logic from head/3.0 to 2.2 so that Stratus VOS can build Samba 2.2 properly. I have tested it extensively on Stratus VOS without any problems (and of course it is tested frequently in the other trees). Please apply it to Samba 2.2. Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Technologies, Maynard, MA USA Voice: +1 978-461-7557; FAX: +1 978-461-3610 Speaking from Stratus not for Stratus diff -urp old/samba_2_2/source/Makefile.in new/samba_2_2/source/Makefile.in --- old/samba_2_2/source/Makefile.inSun Feb 9 17:44:55 2003 +++ new/samba_2_2/source/Makefile.inTue Feb 11 07:35:51 2003 @@ -17,6 +17,7 @@ [EMAIL PROTECTED]@ [EMAIL PROTECTED]@ [EMAIL PROTECTED]@ [EMAIL PROTECTED]@ [EMAIL PROTECTED]@ [EMAIL PROTECTED]@ [EMAIL PROTECTED]@ @@ -96,13 +97,15 @@ WINBIND_SPROGS = @WINBIND_STARGETS@ WINBIND_PAM_PROGS = @WINBIND_PAM_TARGETS@ WINBIND_LPROGS = @WINBIND_LTARGETS@ -SPROGS = bin/smbd bin/nmbd bin/swat -PROGS1 = bin/smbclient bin/smbspool bin/testparm bin/testprns bin/smbstatus bin/smbcontrol bin/tdbbackup bin/make_printerdef @RUNPROG@ -PROGS2 = bin/smbpasswd bin/make_smbcodepage bin/rpcclient bin/make_unicodemap bin/smbcacls @WRAPPROG@ @WRAP@ @WRAP32@ @PAM_MOD@ @PDBEDIT@ @LIBSMBCLIENT@ +SPROGS = bin/smbd$(EXEEXT) bin/nmbd$(EXEEXT) bin/swat$(EXEEXT) +PROGS1 = bin/smbclient$(EXEEXT) bin/smbspool$(EXEEXT) bin/testparm$(EXEEXT) bin/testprns$(EXEEXT) bin/smbstatus$(EXEEXT) \ + bin/smbcontrol$(EXEEXT) bin/tdbbackup$(EXEEXT) bin/make_printerdef$(EXEEXT) @RUNPROG@ +PROGS2 = bin/smbpasswd$(EXEEXT) bin/make_smbcodepage$(EXEEXT) bin/rpcclient$(EXEEXT) bin/make_unicodemap$(EXEEXT) \ + bin/smbcacls$(EXEEXT) @WRAPPROG@ @WRAP@ @WRAP32@ @PAM_MOD@ @PDBEDIT@ @LIBSMBCLIENT@ MPROGS = @MPROGS@ LPROGS = $(WINBIND_PAM_PROGS) $(WINBIND_LPROGS) -PROGS = $(PROGS1) $(PROGS2) $(MPROGS) bin/nmblookup -TORTURE_PROGS = bin/smbtorture bin/msgtest bin/masktest bin/locktest bin/locktest2 +PROGS = $(PROGS1) $(PROGS2) $(MPROGS) bin/nmblookup$(EXEEXT) +TORTURE_PROGS = bin/smbtorture$(EXEEXT) bin/msgtest$(EXEEXT) bin/masktest$(EXEEXT) bin/locktest$(EXEEXT) bin/locktest2$(EXEEXT) SHLIBS = @LIBSMBCLIENT@ SCRIPTS = $(srcdir)/script/smbtar $(srcdir)/script/findsmb @@ -438,27 +441,28 @@ libsmbclient : CHECK bin/libsmbclient.a torture : CHECK $(TORTURE_PROGS) -smbtorture : CHECK bin/smbtorture +smbtorture : CHECK bin/smbtorture$(EXEEXT) +bin/smbtorture : CHECK bin/smbtorture$(EXEEXT) -masktest : CHECK bin/masktest +masktest : CHECK bin/masktest$(EXEEXT) -msgtest : CHECK bin/msgtest +msgtest : CHECK bin/msgtest$(EXEEXT) -locktest : CHECK bin/locktest +locktest : CHECK bin/locktest$(EXEEXT) -smbcacls : CHECK bin/smbcacls +smbcacls : CHECK bin/smbcacls$(EXEEXT) -locktest2 : CHECK bin/locktest2 +locktest2 : CHECK bin/locktest2$(EXEEXT) -rpctorture : CHECK bin/rpctorture +rpctorture : CHECK bin/rpctorture$(EXEEXT) -bin/rpccheck: $(RPCCHECK_OBJ) bin/.dummy +bin/rpccheck$(EXEEXT): $(RPCCHECK_OBJ) bin/.dummy @echo Linking $@ @$(CC) $(FLAGS) -o $@ $(RPCCHECK_OBJ) $(LDFLAGS) $(LIBS) -debug2html : CHECK bin/debug2html +debug2html : CHECK bin/debug2html$(EXEEXT) -smbfilter : CHECK bin/smbfilter +smbfilter : CHECK bin/smbfilter$(EXEEXT) nsswitch : CHECK $(WINBIND_PROGS) $(WINBIND_SPROGS) $(LPROGS) @@ -512,128 +516,127 @@ bin/.dummy: dir=bin $(MAKEDIR); fi @: $@ || : $@ # what a fancy emoticon! -bin/smbd: $(SMBD_OBJ) bin/.dummy +bin/smbd$(EXEEXT): $(SMBD_OBJ) bin/.dummy @echo Linking $@ @$(CC) $(FLAGS) -o $@ $(SMBD_OBJ) $(LDFLAGS) $(DYNEXP) $(LIBS) $(LDAPLIBS) -bin/nmbd: $(NMBD_OBJ) bin/.dummy +bin/nmbd$(EXEEXT): $(NMBD_OBJ) bin/.dummy @echo Linking $@ @$(CC) $(FLAGS) -o $@ $(NMBD_OBJ) $(LDFLAGS) $(LIBS) -bin/swat: $(SWAT_OBJ) bin/.dummy +bin/swat$(EXEEXT): $(SWAT_OBJ) bin/.dummy @echo Linking $@ @$(CC) $(FLAGS) -o $@ $(SWAT_OBJ) $(LDFLAGS) $(DYNEXP) $(LIBS) $(LDAPLIBS) -bin/rpcclient: $(RPCCLIENT_OBJ) bin/.dummy +bin/rpcclient$(EXEEXT): $(RPCCLIENT_OBJ) bin/.dummy @echo Linking $@ @$(CC) $(FLAGS) -o $@ $(RPCCLIENT_OBJ) $(LDFLAGS) $(DYNEXP) $(TERMLDFLAGS) $(TERMLIBS) $(LIBS) $(LDAPLIBS) -bin/smbclient: $(CLIENT_OBJ) bin/.dummy +bin/smbclient$(EXEEXT): $(CLIENT_OBJ) bin/.dummy @echo Linking $@ @$(CC) $(FLAGS) -o $@ $(CLIENT_OBJ) $(LDFLAGS) $(TERMLDFLAGS) $(TERMLIBS) $(LIBS) -bin/smbspool: $(CUPS_OBJ) bin/.dummy +bin/smbspool$(EXEEXT): $(CUPS_OBJ) bin/.dummy @echo Linking $@ @$(CC) $(FLAGS) -o $@ $(CUPS_OBJ) $(LDFLAGS) $(LIBS) -bin/smbmount: $(MOUNT_OBJ) bin/.dummy +bin/smbmount$(EXEEXT): $(MOUNT_OBJ) bin/.dummy @echo Linking $@ @$(CC) $(FLAGS) -o $@ $(MOUNT_OBJ) $(LDFLAGS) $(LIBS) -bin/smbmnt: $(MNT_OBJ) bin/.dummy +bin/smbmnt$(EXEEXT): $(MNT_OBJ) bin/.dummy @echo Linking $@ @$(CC) $(FLAGS) -o $@ $(MNT_OBJ) $(LDFLAGS) $(LIBS) -bin/smbumount:
RE: [SECURITY] Samba 2.2.8 available for download
Green, Paul [mailto:[EMAIL PROTECTED] wrote: The 2.2.8 release notes say: A buffer overrun condition exists in the SMB/CIFS packet fragment re-assembly code in smbd which would allow an attacker to cause smbd to overwrite arbitrary areas of memory in its own process address space. This could allow a skilled attacker to inject binary specific exploit code into smbd. I have written a short test case (available upon request) to confirm that Stratus VOS, when running on the HP PA-RISC hardware, is not susceptible to such an attack. While such an attack can indeed be used to insert code onto the VOS stack, as soon as the processor attempts to begin executing the code it will take a no-execute permission fault or an invalid-page fault. Therefore, the last sentence of this warning in the 2.2.8 release notes about inject[ing] binary specific exploit code into smbd does not apply to VOS on HP PA-RISC. As other experts have noted, there are probably other OS/Hardware combinations that are also immune to this attack. I hope other maintainers will post such information so that we can have a public record, and not needlessly scare our customers. Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Technologies, Maynard, MA USA Voice: +1 978-461-7557; FAX: +1 978-461-3610 Speaking from Stratus not for Stratus
[pseudo-patch] source/web/swat.c
Samba 3.0, Line 1269 of web/swat.c references TRUE rather than the POSIX-ly correct True. There may be others; this is the one that killed the build on Stratus VOS. Would whoever checked in this change please correct it? Many thanks. PG -- Paul Green, Senior Technical Consultant, Stratus Technologies, Maynard, MA USA Voice: +1 978-461-7557; FAX: +1 978-461-3610 Speaking from Stratus not for Stratus
[pseudo-patch] utils/smbpasswd.c in 2.2 and 3.0
The build farm is reporting that line 37 of the compilation of utils/smbpasswd.c (2.2 and 3.0 branches) is failing on Stratus VOS because jht checked in a patch on 3/22 that adds a reference to FALSE (on a source line that already has many correctly-coded references to False...sigh). Please fix this. Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Technologies. Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request.
[pseudo-patch] passdb/pdb_interface.c
Re: build farm errors for Stratus VOS on head and 3.0. I would be grateful if whomever added a reference to FALSE to line 31 of passdb/pdb_interface.c would change it to False. The latter is the POSIX name for the macro; the former is non-POSIX. Or grant me ([EMAIL PROTECTED]) cvs access and I'll do it. Thanks. PG -- Paul Green, Senior Technical Consultant, Stratus Technologies. Voice: +1 (978) 461-7557; FAX: +1 (978) 461-3610
RE: [SECURITY] Samba 2.2.8 available for download
The 2.2.8 release notes say: A buffer overrun condition exists in the SMB/CIFS packet fragment re-assembly code in smbd which would allow an attacker to cause smbd to overwrite arbitrary areas of memory in its own process address space. This could allow a skilled attacker to inject binary specific exploit code into smbd. Comment: It seems to me that the ability of a skilled attacker to inject binary specific exploit code into smbd is dependent upon the processor architecture. On a chip that fails to distinguish between code and data, I can readily see how a skilled attacker could inject binary specific code using a buffer overrun. However, on a chip that does distinguish areas of virtual memory that are code, and areas that are data, and further disallows execution of data (absent a specific operating system call to change the access mode of that region of virtual memory), it seems to me that it would be almost impossible for even a highly skilled attacker to inject binary specific code. I consider myself highly skilled on the Stratus VOS operating system and I can't for the life of my see how I could get the HP PA-RISC microprocessor to execute code that came down the wire as data. Question: Would someone please confirm or refute my hypothesis? Some of my customers are asking me about this vulnerability, and as all of the Stratus VOS customers are using Samba on a microprocessor that draws a strong distinction between virtual memory used for data (e.g., stack, heap, static data) versus virtual memory used by executable code, it is my current strong belief that we are not susceptible to this vulnerability as described in the release notes. [I can see how an attacker could mount a DoS attack, of course]. [[Meta comment: vulnerabilities that require combinations of code holes and microprocessor design flaws and/or operating system holes should be so labeled, IMHO. Blanket statements needlessly scare people, and needlessly let certain vendors of chips with weak hardware security controls, or OS vendors with same, off the hook.]] Patch Availability - - As this is a security issue, patches for this flaw specific to earlier versions of Samba will be posted on the [EMAIL PROTECTED] mailing list as requested. Well, if my hypothesis is incorrect, I'd like to request a patch against 2.0.7. Either that, or I'm going to send you a lot of patches to get 2.2.8 to build on VOS... Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Technologies. Voice: +1 (978) 461-7557; FAX: +1 (978) 461-3610
[patch] resend samba_2_2 exe patch
This is a resend of a patch I originally submitted on Feb 9th to the samba_2_2 tree. It is probably too late to include it in the forthcoming 2.2.8 release, but if so, I would request that it be applied soon afterwards. It is similar to changes I submitted to head and 3.0 some time ago. I've been running this patch here for some time without problems. It simply teachs Makefile.in and configure.in to observe any possible executable extension. After it is applied, the follow change must be made to the build farm: --- build_test.fns.old Sun Mar 2 15:01:02 2003 +++ build_test.fns Sun Mar 2 15:01:27 2003 @@ -127,7 +127,7 @@ do_make proto everything torture ;; samba_2_2) -do_make everything bin/smbtorture +do_make everything ;; rsync) do_make all (the bin/smbtorture is redundant wrong when there are extensions). Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Technologies, Maynard, MA USA Voice: +1 978-461-7557; FAX: +1 978-461-3610 Speaking from Stratus not for Stratus diff -urp old/samba_2_2/source/Makefile.in new/samba_2_2/source/Makefile.in --- old/samba_2_2/source/Makefile.inSun Feb 9 17:44:55 2003 +++ new/samba_2_2/source/Makefile.inTue Feb 11 07:35:51 2003 @@ -17,6 +17,7 @@ [EMAIL PROTECTED]@ [EMAIL PROTECTED]@ [EMAIL PROTECTED]@ [EMAIL PROTECTED]@ [EMAIL PROTECTED]@ [EMAIL PROTECTED]@ [EMAIL PROTECTED]@ @@ -96,13 +97,15 @@ WINBIND_SPROGS = @WINBIND_STARGETS@ WINBIND_PAM_PROGS = @WINBIND_PAM_TARGETS@ WINBIND_LPROGS = @WINBIND_LTARGETS@ -SPROGS = bin/smbd bin/nmbd bin/swat -PROGS1 = bin/smbclient bin/smbspool bin/testparm bin/testprns bin/smbstatus bin/smbcontrol bin/tdbbackup bin/make_printerdef @RUNPROG@ -PROGS2 = bin/smbpasswd bin/make_smbcodepage bin/rpcclient bin/make_unicodemap bin/smbcacls @WRAPPROG@ @WRAP@ @WRAP32@ @PAM_MOD@ @PDBEDIT@ @LIBSMBCLIENT@ +SPROGS = bin/smbd$(EXEEXT) bin/nmbd$(EXEEXT) bin/swat$(EXEEXT) +PROGS1 = bin/smbclient$(EXEEXT) bin/smbspool$(EXEEXT) bin/testparm$(EXEEXT) bin/testprns$(EXEEXT) bin/smbstatus$(EXEEXT) \ + bin/smbcontrol$(EXEEXT) bin/tdbbackup$(EXEEXT) bin/make_printerdef$(EXEEXT) @RUNPROG@ +PROGS2 = bin/smbpasswd$(EXEEXT) bin/make_smbcodepage$(EXEEXT) bin/rpcclient$(EXEEXT) bin/make_unicodemap$(EXEEXT) \ + bin/smbcacls$(EXEEXT) @WRAPPROG@ @WRAP@ @WRAP32@ @PAM_MOD@ @PDBEDIT@ @LIBSMBCLIENT@ MPROGS = @MPROGS@ LPROGS = $(WINBIND_PAM_PROGS) $(WINBIND_LPROGS) -PROGS = $(PROGS1) $(PROGS2) $(MPROGS) bin/nmblookup -TORTURE_PROGS = bin/smbtorture bin/msgtest bin/masktest bin/locktest bin/locktest2 +PROGS = $(PROGS1) $(PROGS2) $(MPROGS) bin/nmblookup$(EXEEXT) +TORTURE_PROGS = bin/smbtorture$(EXEEXT) bin/msgtest$(EXEEXT) bin/masktest$(EXEEXT) bin/locktest$(EXEEXT) bin/locktest2$(EXEEXT) SHLIBS = @LIBSMBCLIENT@ SCRIPTS = $(srcdir)/script/smbtar $(srcdir)/script/findsmb @@ -438,27 +441,28 @@ libsmbclient : CHECK bin/libsmbclient.a torture : CHECK $(TORTURE_PROGS) -smbtorture : CHECK bin/smbtorture +smbtorture : CHECK bin/smbtorture$(EXEEXT) +bin/smbtorture : CHECK bin/smbtorture$(EXEEXT) -masktest : CHECK bin/masktest +masktest : CHECK bin/masktest$(EXEEXT) -msgtest : CHECK bin/msgtest +msgtest : CHECK bin/msgtest$(EXEEXT) -locktest : CHECK bin/locktest +locktest : CHECK bin/locktest$(EXEEXT) -smbcacls : CHECK bin/smbcacls +smbcacls : CHECK bin/smbcacls$(EXEEXT) -locktest2 : CHECK bin/locktest2 +locktest2 : CHECK bin/locktest2$(EXEEXT) -rpctorture : CHECK bin/rpctorture +rpctorture : CHECK bin/rpctorture$(EXEEXT) -bin/rpccheck: $(RPCCHECK_OBJ) bin/.dummy +bin/rpccheck$(EXEEXT): $(RPCCHECK_OBJ) bin/.dummy @echo Linking $@ @$(CC) $(FLAGS) -o $@ $(RPCCHECK_OBJ) $(LDFLAGS) $(LIBS) -debug2html : CHECK bin/debug2html +debug2html : CHECK bin/debug2html$(EXEEXT) -smbfilter : CHECK bin/smbfilter +smbfilter : CHECK bin/smbfilter$(EXEEXT) nsswitch : CHECK $(WINBIND_PROGS) $(WINBIND_SPROGS) $(LPROGS) @@ -512,128 +516,127 @@ bin/.dummy: dir=bin $(MAKEDIR); fi @: $@ || : $@ # what a fancy emoticon! -bin/smbd: $(SMBD_OBJ) bin/.dummy +bin/smbd$(EXEEXT): $(SMBD_OBJ) bin/.dummy @echo Linking $@ @$(CC) $(FLAGS) -o $@ $(SMBD_OBJ) $(LDFLAGS) $(DYNEXP) $(LIBS) $(LDAPLIBS) -bin/nmbd: $(NMBD_OBJ) bin/.dummy +bin/nmbd$(EXEEXT): $(NMBD_OBJ) bin/.dummy @echo Linking $@ @$(CC) $(FLAGS) -o $@ $(NMBD_OBJ) $(LDFLAGS) $(LIBS) -bin/swat: $(SWAT_OBJ) bin/.dummy +bin/swat$(EXEEXT): $(SWAT_OBJ) bin/.dummy @echo Linking $@ @$(CC) $(FLAGS) -o $@ $(SWAT_OBJ) $(LDFLAGS) $(DYNEXP) $(LIBS) $(LDAPLIBS) -bin/rpcclient: $(RPCCLIENT_OBJ) bin/.dummy +bin/rpcclient$(EXEEXT): $(RPCCLIENT_OBJ) bin/.dummy @echo Linking $@ @$(CC) $(FLAGS) -o $@ $(RPCCLIENT_OBJ) $(LDFLAGS) $(DYNEXP) $(TERMLDFLAGS) $(TERMLIBS) $(LIBS) $(LDAPLIBS) -bin/smbclient: $(CLIENT_OBJ) bin/.dummy +bin/smbclient$(EXEEXT): $(CLIENT_OBJ) bin/.dummy @echo Linking $@ @$(CC)
Long file names in Samba tests
Sadly, the system on which I labor supports only a 32-byte limit for a filename. This seemed plenty when we designed the file system in 1980... I've finally gotten the builds to get to the point where they can run the test suite, and I have discovered that the (head/3.0) shell script tries to create names of the form: basicsmb.smb.conf.hostsdeny.template (36 bytes). basicsmb.smb.conf.preexec_cl_fail.template (42 bytes). Would anyone object if I submit some patches to shorten such test suite file names to fit within 32 characters? Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Technologies, Maynard, MA USA Voice: +1 978-461-7557; FAX: +1 978-461-3610 Speaking from Stratus not for Stratus
RE: Samba 3.0 CVS: configure problem
It can't find libiconv.so.2. The test is bad because this should not have aborted configure. The clues are these lines: configure:20621: checking for test routines configure:20637: gcc -o conftest -O -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 conftest.c -lsec -lgen -lresolv -lsocket -lnsl -ldl -liconv 5 configure:20640: $? = 0 configure:20642: ./conftest ld.so.1: ./conftest: fatal: libiconv.so.2: open failed: No such file or directory ./configure: line 1: 28954 Killed ./conftest$ac_exeext configure:20645: $? = 137 configure: program exited with status 137 configure: failed program was: [snip] configure:20655: error: cant find test code. Aborting config and now it dies. HTH PG -- Paul Green, Senior Technical Consultant, Stratus Technologies. Day: +1 978-461-7557; FAX: +1 978-461-3610 Speaking from Stratus not for Stratus -Original Message- From: Joe Meslovich [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 26, 2003 10:30 AM To: [EMAIL PROTECTED] Subject: Samba 3.0 CVS: configure problem I got the latest CVS copy of samba 3.0 today. I ran autogen.sh to create configure. And then I configured the system --with-quotas --with-acl-support. The configure script bombs when it gets to the part about test routines. It ends with: error: cant find test code. Aborting config I am including a gzipped copy of my config.log. The system is Solaris 9 x86. I installed the recommended GNU libiconv-1.8 in /usr/local yesterday. I tried configuring a CVS copy of Samba 3.0 from the 19th of February --with-libiconv=/usr/local. That configure failed in the same way, but configureing with only --with-quotas and --with-acl-support worked. I then tried the same with a copy from today the 26th. I cannot get configure to finish properly at all. I am not certain if the error is related to libiconv. That is why I included the log. Joe Meslovich [EMAIL PROTECTED] Associate Network/Systems Engineer IT Center Tel: (540) 828 - 5343
make clean clean cleaner
Or maybe that should read make make clean clean cleaner... make clean fails to clean up the files that were built by make everything over and above make all. Hence, this patch to head. Test here successfully. Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Technologies, Maynard, MA USA Voice: +1 978-461-7557; FAX: +1 978-461-3610 Speaking from Stratus not for Stratus diff -urp old/samba/source/Makefile.in new/samba/source/Makefile.in --- old/samba/source/Makefile.inMon Feb 24 13:46:47 2003 +++ new/samba/source/Makefile.inMon Feb 24 13:54:05 2003 @@ -126,6 +126,10 @@ TORTURE_PROGS = bin/[EMAIL PROTECTED]@ b BIN_PROGS = $(BIN_PROGS1) $(BIN_PROGS2) $(BIN_PROGS3) @EXTRA_BIN_PROGS@ +EVERYTHING_PROGS = bin/[EMAIL PROTECTED]@ bin/[EMAIL PROTECTED]@ bin/[EMAIL PROTECTED]@ + +EVERYTHING_SBIN = bin/[EMAIL PROTECTED]@ bin/libsmbclient.a + SHLIBS = @SHLIB_PROGS@ @LIBSMBCLIENT@ SCRIPTS = $(srcdir)/script/smbtar $(srcdir)/script/addtosmbpass $(srcdir)/script/convert_smbpasswd \ @@ -1131,7 +1135,8 @@ TOPFILES=dynconfig.o dynconfig.po clean: delheaders python_clean -rm -f core */*~ *~ */*.o */*.po */*.po32 */[EMAIL PROTECTED]@ \ - $(TOPFILES) $(BIN_PROGS) $(SBIN_PROGS) $(MODULES) $(TORTURE_PROGS) .headers.stamp + $(TOPFILES) $(BIN_PROGS) $(SBIN_PROGS) $(MODULES) $(TORTURE_PROGS) \ + $(EVERYTHING_PROGS) $(EVERYTHING_SBIN) .headers.stamp # Making this target will just make sure that the prototype files # exist, not necessarily that they are up to date. Since they're @@ -1221,7 +1226,7 @@ ctags: ctags `find $(srcdir) -name *.[ch] | grep -v /CVS/` realclean: clean delheaders - -rm -f config.log $(BIN_PROGS) $(MODULES) $(SBIN_PROGS) bin/.dummy script/findsmb + -rm -f config.log bin/.dummy script/findsmb distclean: realclean -rm -f include/stamp-h
[patch] configure.in bug setting authlibs
AC_SEARCH_LIBS and AC_CHECK_LIB are used to find a function and then add its
library to the LIBS variable. The macros can deal with the fact that the
function might be missing, in a library, or available but not in any
library. The configure script, in both head and 3.0, uses these macros to
find the crypt function. In addition, configure uses the true clause to
set AUTHLIBS to hold the name of the library containing crypt. However,
it slips up and assumes that crypt, if found, must be in a library. On my
system, crypt is available but not in any library. Thus, configure
mistakenly sets AUTHLIBS=-lcrypt, but I don't have libcrypt.a, and so I die.
The attached patch corrects this, and removes what I think is a redundant
call to AC_SEARCH_LIBS. I did an extensive analysis, and AFAICT this patch
will work properly in all cases (with or without pam). But I would
appreciate another set of eyes looking it over.
Secondly, AC_SEARCH_LIBS and AC_CHECK_LIB are careful to prepend any new
library to the LIBS variable, whereas the old code dealing with AUTHLIBS
appends newly-discovered libraries. I changed the AUTHLIBS reference to
prepend as well. This may not matter now, but it seems good practice.
I have tested this patch on Stratus VOS and on Sun Solaris. On the Sun, I
tested it --with-pam and --without-pam. It behaved as I expected and desired
in all cases. I'd be grateful if it could be applied to HEAD and 3_0.
pg.samba.030220.txt
Thanks
PG
--
Stratus Technologies
111 Powdermill Road
Maynard, MA 01754-3409 U.S.A.
Paul Green
Senior Technical Consultant
TEL +1 (978) 461-7557
FAX +1 (978) 461-3610
diff -urp old/samba/source/configure.in new/samba/source/configure.in
--- old/samba/source/configure.in Wed Feb 19 10:55:02 2003
+++ new/samba/source/configure.in Thu Feb 20 07:27:19 2003
-727,11 +727,6 fi
AC_FUNC_MEMCMP
###
-# test for where we get crypt() from
-AC_SEARCH_LIBS(crypt, [crypt], [AUTHLIBS=$AUTHLIBS -lcrypt;
- AC_DEFINE(HAVE_CRYPT,1,[Whether the system has the crypt() function])])
-
-###
# Readline included by default unless explicitly asked not to
test ${with_readline+set} != set with_readline=yes
-2408,15 +2403,10 AC_ARG_WITH(pam_smbpass,
###
-# test for where we get crypt() from, but only
-# if not using PAM
-if test x$with_pam_for_crypt = xno; then
-AC_CHECK_FUNCS(crypt)
-if test x$ac_cv_func_crypt = xno; then
-AC_CHECK_LIB(crypt, crypt, [AUTHLIBS=$AUTHLIBS -lcrypt;
- AC_DEFINE(HAVE_CRYPT,1,[Whether crypt() is available])])
-fi
-fi
+# test for where we get crypt() from
+AC_SEARCH_LIBS(crypt, [crypt],
+ [test $ac_cv_search_crypt = none required || AUTHLIBS=-lcrypt $AUTHLIBS
+ AC_DEFINE(HAVE_CRYPT,1,[Whether the system has the crypt() function])])
##
## moved after the check for -lcrypt in order to
RE: [patch] libsmbclient: shared or static libs, never both?
Steve Langasek [mailto:vorlon@xx] suggests: Sometimes, it's useful to be able to build (and install) static libraries even on platforms that support shared libraries. The attached patch brings in a few macros from libtool's aclocal.m4, to add --enable-shared and --enable-static options to configure as a step in this direction. As the person who most recently touched this logic, I support such an addition. Making this logic explicit and controllable would be a lot more transparent than the current detective work (not that you could entirely eliminate that however). Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Technologies. Day: +1 978-461-7557; FAX: +1 978-461-3610 Speaking from Stratus not for Stratus
RE: Samba 3.0: vfs_netatalk.c
Anthony Liguori [mailto:[EMAIL PROTECTED]] wrote: scandir() (and it's [alpha|version]sort() brethren) is a BSD/Linux-ism and therefore isn't very portable. Since this is in a VFS module (and therefore only optional) I guess this is ok. then Herb Lewis [mailto:[EMAIL PROTECTED]] found this info: IRIX: scandir, scandir64, alphasort, alphasort64 BSD: scandir, alphasort I just checked and neither scandir* nor alphasort* are in POSIX-1996 or POSIX-2001. I'm not trying to build vfs_netatalk here on VOS, but if I was, it looks like I'd be writing some code first. I don't consider these functions portable either. My vote is for sticking with functions in POSIX if at all possible. PG -- Paul Green, Senior Technical Consultant, Stratus Technologies. Day: +1 978-461-7557; FAX: +1 978-461-3610 Speaking from Stratus not for Stratus
RE: patch -- have samba_2_2 handle executable extensions
This is a patch for samba_2_2 that changes it to handle any executable extensions. A while back I submitted a similar patch for head and 3_0, which were applied in due course. Due to an error in the build_farm scripts, after this patch is applied, the samba_2_2 subcase within the action_build function in build_test.fns must be changed so that it reads do_make everything not do_make everything bin/smbtorture Turns out that everything already includes building the smbtorture program. (But if it didn't, the rule should have simply read smbtorture not bin/smbtorture). Patch attached. Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Technologies. Day: +1 978-461-7557; FAX: +1 978-461-3610 Speaking from Stratus not for Stratus --- build_test.fns.old Mon Feb 10 11:47:13 2003 +++ build_test.fns Mon Feb 10 11:47:28 2003 @@ -122,7 +122,7 @@ do_make proto everything torture ;; samba_2_2) - do_make everything bin/smbtorture + do_make everything ;; rsync) do_make all
RE: 2.0.7-XP compability ?
Ulf Bertilsson [mailto:[EMAIL PROTECTED]] asks: How can I best identify if this is in my os custiom posix wrapper, or an issue in the samba 2.0.7 core code ? I can give you a version of source/lib/system.c for 2.0.7 that has built-in tracing capabilities. We don't have truss on our system, so I added similar support directly into system.c. Drop me a line if you think it would help you out. PG -- Paul Green, Senior Technical Consultant, Stratus Technologies, Maynard, MA USA Voice: +1 978-461-7557; FAX: +1 978-461-3610 Speaking from Stratus not for Stratus
RE: help needed : Error : The specified user does not exist.
Please post this question to [EMAIL PROTECTED] This list is for developers. Thanks PG -Original Message- From: Adil Hussain [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 2:17 PM To: [EMAIL PROTECTED] Subject: help needed : Error : The specified user does not exist. i want to configure samba as PDC .i installed the samba on the linux box machine and configure it accordingly. I am trying to connect the windows 2000(server) as a client of this domain. when i press ok after writing the domain name at the windows 2000 (as a client). It gives me a window , asking for the Name and Password and when i give it the root/[password] to it, it says The following error occured attempting to join the domain [domain name] The specified user does not exist. please help me in this regard becuase i tried many tutorials to solve this problem, but its still annoying me. thnaks best regards Adil __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
RE: Patch to configure.in for Stratus VOS
@#$%T My mailer wrapped some lines here! Beware. I'll see if I can repost this.
RE: recursive mutexes in appl_head winbindd_cm.c?
Martin Pool [mailto:[EMAIL PROTECTED]] I hypothesized to ab that in NT there is some kind of table indexed by IP (or client name?) holding the challenges. I wonder why? I found a similar limitation in a commercial RADIUS server I was testing against. Any given person could have only one challenge outstanding at a time. When I tried to login the same test must-challenge user on two different terminals at the same time, only one of them ever got in. I had designed and written my own intermediary server that could handle this case, so I was disappointed to find out that my effort was for naught. The protocol spec was silent on whether this case had to be implemented. PG
RE: please report to samba-technical@samba.org
Umm, what OS? What version of Samba? Who/what is the client (Windows version xyz?) What were the clients doing to make this happen? (if you know)... Can you make a test case? Thanks PG -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 4:21 AM To: [EMAIL PROTECTED] Subject: please report to [EMAIL PROTECTED] here you are: [2003/01/08 08:26:20, 0] rpc_parse/parse_spoolss.c:spoolss_io_devmode(607) spoolss_io_devmode: Unknown specversion in devicemode [0x0] [2003/01/08 08:26:20, 0] rpc_parse/parse_spoolss.c:spoolss_io_devmode(608) spoolss_io_devmode: please report to [EMAIL PROTECTED]! [2003/01/08 08:26:20, 0] rpc_parse/parse_spoolss.c:spoolss_io_devmode(607) spoolss_io_devmode: Unknown specversion in devicemode [0x0] [2003/01/08 08:26:20, 0] rpc_parse/parse_spoolss.c:spoolss_io_devmode(608) spoolss_io_devmode: please report to [EMAIL PROTECTED]! [2003/01/10 12:38:30, 0] rpc_client/cli_spoolss_notify.c:spoolss_connect_to_client(98) [2003/01/10 12:38:31, 0] rpc_client/cli_spoolss_notify.c:spoolss_connect_to_client(98) best regards Wolfgang Fürtbauer -- Wolfgang Fuertbauer (E-Mail: [EMAIL PROTECTED]) EBEWE Pharma Tel: ++43 7665 8123 315 Mondseestrasse 11 Fax: ++43 7665 8123 11 4866 Unterach, Austria http://www.ebewe.com
RE: files larger than 4GB. Lack of feedback not helpful ...
Richard, We still love you! Thanks for all of your hard work on Samba. PG -Original Message- From: Richard Sharpe [mailto:[EMAIL PROTECTED]] Sent: Monday, December 30, 2002 3:01 PM To: [EMAIL PROTECTED] Subject: Re: files larger than 4GB. Lack of feedback not helpful ... Sigh, It seems amazing, but seems to happen so often. People find it easy enough to complain about bugs on a weekend. Others seem to find the time on a weekend to duplicate, and fix the bug complained of, but then nary a word of thanks is heard when the fix is produced :-( Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
RE: Returning the size of the file to Clients
John E. Malmberg [mailto:[EMAIL PROTECTED]] wrote: Samba makes calls on behalf of the client to return a file size. Samba also makes POSIX stat() calls on its own behalf, only some of which actually care about the file size (some of them are checking access, for example). The problem for this on OpenVMS, is that some of the text file sizes include the record information. I have the same problem on Stratus VOS. We natively implement COBOL file types (sequential, relative, and fixed), each of which contain record length information in addition to the data, and which also, when used to hold text, typically do not include the trailing newline character in the record. When these files are sent to the client they are converted to a byte stream format like UNIX uses. But this results in a file that is a slightly different size than the physical size of the file, usually smaller. Agreed. Only some applications, such as wordpad seem to be sensitive to this, as others use the amount of data transferred. It has been reported that wordpad adds garbage bytes to the end of the buffer for the difference. WordPad was my Achilles heel as well. I ran a trace and found that Samba 2.0.7 called stat() 48 times on a small test file when Windows NT4 was listing a directory and opening a file with WordPad. I don't know how many of these calls were due to Samba and how many were due to WordPad. The 2.2.4 port of Samba to OpenVMS solves this by reading the entire file in order to give the correct size. This of course creates a big performance hit when displaying a directory. I did the same thing, in our implementation of (f)stat. I was at least able to use an OS call that merely returned the size of the next record, w/o transferring the data, but it was still a big hit. I contemplated creating a file size cache in our POSIX runtime to at least reduce the number of times we had to do this. But in the end, we decided that this was a general problem that the VOS kernel had to solve, so we taught the kernel to keep track of the POSIX size of a file in parallel with the historic, proprietary size. And then we taught the POSIX runtime to use this value when it was available. Huge improvement. Is there anyway to differentiate for when the Client is opening a file for an application, and when a directory is being listed? I never found one. But I wasn't familiar with the SMB protocol, either, so all I had to go on was the Samba source code. For a while, I had patches to Samba to call two different versions of (f)stat; one that would return the estimated size, and one that would calculate and return the exact size. The problem is that there are a lot of calls to stat within Samba, and as you discovered, some of them come from the client at the other end of the wire, and have to return the right value. I couldn't really get my scheme to work, and so gave it up and changed VOS. I am also going to look to see if there is a more optimal way to calculate the size of these text files. Well, we didn't patent our method, so you are free to use it... :-). Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Technologies. Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request.
RE: Samba CPU Usage with large directories ...
Scott Taylor [mailto:[EMAIL PROTECTED]] wrote: We have a samba server running version 2.2.5 on kernel 2.4.18 with the SGI XFS patch. The shared volume consists of an XFS partition on a 3-ware raid5 controller. The network connection is via a 4 port bonded pipe to the switch. We notice that the samba CPU usage during write operations increases dramatically once a directory contains more than a certian number of files - thought to be somewhere around the 1500 to 2000 mark. We have tried allowing samba more memory, which did not seem to help - and have had little or no success finding any information on the web, hence this post. My guess (and that's all it is) is that this is an operating system issue. I presume you are using Linux 2.4.18 although you didn't say. Try writing a small C benchmark program that just does straight fopen/fread/frwrite/fclose operations, and time them, and see how you fare. I'll bet you find that the system calls (esp. the open call) take a lot longer on the big directories. Make sure your benchmark program uses the same file naming conventions as your real code, in case the problem has something to do with the efficiency of hashing or searching the specific names. PG -- Paul Green, Senior Technical Consultant, Stratus Technologies. Day: +1 978-461-7557; FAX: +1 978-461-3610 Speaking from Stratus not for Stratus
RE: Patch for 3_0 configure.in ??
Rats. Missed this in testing. (My fault). I think someone has fixed this already by escaping the $-sign. The issue is controlling when the $(EXEEXT) gets expanded. PG -Original Message- From: Alexander Bokovoy [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 05, 2002 6:23 AM To: [EMAIL PROTECTED] Subject: Re: Patch for 3_0 configure.in ?? On Thu, Dec 05, 2002 at 11:44:36AM +0100, [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! I've never done anything in configure.in. What about the following? This is correct. I'm also seeing these EXEEXT: no such file or directory responses. $(EXEEXT) in /bin/sh != $(EXEEXT) in Make. Index: configure.in === RCS file: /kunden/vl/cvs/samba/source/configure.in,v retrieving revision 1.300.2.25 diff -u -r1.300.2.25 configure.in - --- configure.in2002/12/04 19:47:01 1.300.2.25 +++ configure.in2002/12/05 10:43:37 @@ -3054,8 +3054,8 @@ AC_MSG_RESULT(yes) AC_DEFINE(WITH_WINBIND,1,[Whether to build winbind]) - - EXTRA_BIN_PROGS=$EXTRA_BIN_PROGS bin/wbinfo$(EXEEXT) - - EXTRA_SBIN_PROGS=$EXTRA_SBIN_PROGS bin/winbindd$(EXEEXT) + EXTRA_BIN_PROGS=$EXTRA_BIN_PROGS bin/wbinfo$EXEEXT + EXTRA_SBIN_PROGS=$EXTRA_SBIN_PROGS bin/winbindd$EXEEXT if test x$BLDSHARED= xtrue; then SHLIB_PROGS=$SHLIB_PROGS nsswitch/libnss_winbind.so if test x$with_pam= xÑes; then -- / Alexander Bokovoy --- Do not overtax your powers.
RE: [PATCH] Fix 3.0 to observe executable extensions
Andrew, Thanks for taking the exe stuff. I'll examine the shm issues and report back. PG -Original Message- From: Andrew Bartlett [mailto:[EMAIL PROTECTED]] Sent: Saturday, November 30, 2002 10:22 PM To: [EMAIL PROTECTED] Cc: Multiple recipients of list SAMBA-TECHNICAL Subject: Re: [PATCH] Fix 3.0 to observe executable extensions On Sat, 2002-11-30 at 15:05, [EMAIL PROTECTED] wrote: The following patch changes the 3.0 version of Samba to discover and use a required executable extension, if required by the host OS. It also changes torture/torture.c to use shm_open() if shmget() is unavailable. This is basically the same change that I just submitted to head. I've applied the exe suffix part of these changes to HEAD and 3.0, but I would like to see the torture changes split out a bit if possible - is it possible to emulate somthing like shmget() with shm_open()? This could be added to lib/system.c. We try to avoid #ifdef in mainline code. 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: Need clue regarding CAP_NT_FIND.
Christopher R. Hertel [mailto:[EMAIL PROTECTED]] asked: There doesn't seem to be any documentation regarding the CAP_NT_FIND capability bit. Where might I look for clues? I've checked the Leach/Naik IETF drafts and the SNIA doc. Chris -)- Google found this document, which seems to give a clue. I have no idea whether it is accurate: http://samba.cadcamlab.org/lists/samba-technical/Feb2000/00310.html PG
RE: samba on lynxos 3.0
Olaf Flebbe [mailto:[EMAIL PROTECTED]] wrote: I had some (expected) problems compiling samba 2.2.7 on LynxOS 3.0.1 [snip] Unfortunatly there is no crypt() available on Lynxos. So you have to work around this issue somehow. With a little work, you can probably port the FreeBSD version of crypt.c to your system. The FreeBSD license should not give you any problems. Take a look at http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libcrypt/crypt.c PG -- Paul Green, Senior Technical Consultant, Stratus Technologies. Day: +1 978-461-7557; FAX: +1 978-461-3610 Speaking from Stratus not for Stratus
RE: build issue w/samba head
Jerry wrote: On Tue, 26 Nov 2002, Green, Paul wrote: In the last day, someone has added a call to inet_aton to samba/source/lib/util_str.c. Stratus VOS does not have this function. Rsync happens to have a substitute implementation of this function in rsync/lib/compat.c, and (I imagine) the configure test to activate it. Can we get this added to samba head? I can take care of this, but probably not for a few days... arrgghh... fixing it now. Thanks very much! PG
autoconf differences between 3.0 and head
In preparing and testing a patch to Makefile.in and configure.in, I noticed that the configure script for samba_3_0 was built with a much newer version (2.54) of autoconf than the copy in head (2.13). Is this deliberate? (doubt it). Would it be possible for someone to update the copy in head using a newer release of the autoconf macros? I don't have access to the newer version, and I can't really test my patch on this old version. Many thanks. PG -- Paul Green, Senior Technical Consultant, Stratus Computer, Inc. Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request.
RE: autoconf differences between 3.0 and head
Great, thanks! PG -Original Message- From: Jelmer Vernooij [mailto:[EMAIL PROTECTED]] Sent: Monday, November 25, 2002 11:44 PM To: Green, Paul Cc: Samba Technical (E-mail) Subject: Re: autoconf differences between 3.0 and head On Mon, Nov 25, 2002 at 08:55:28AM -0500, Green, Paul wrote about 'autoconf differences between 3.0 and head': In preparing and testing a patch to Makefile.in and configure.in, I noticed that the configure script for samba_3_0 was built with a much newer version (2.54) of autoconf than the copy in head (2.13). Is this deliberate? (doubt it). It's just because I built the one in 3.0 (I use 2.54) and Tim generated the one in HEAD (using 2.13) - not by policy. Would it be possible for someone to update the copy in head using a newer release of the autoconf macros? I don't have access to the newer version, and I can't really test my patch on this old version. Many thanks. I'll update the copy in HEAD. Jelmer
make question
I need to make a change to the Samba (3.0 and head) makefiles because my system has a required executable suffix. I know how to do this; I'm testing the patch now. My question is, must I assume that Samba might be built by some rather simplistic (to be kind) make programs, or can I assume that, say, (GNU make) features like $(addsuffix ...) are universally available? Judging by the existing makefile, the answer appears to be assume the worst... Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Computer, Inc. Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request.
RE: Segfault with net ads password
James,
I know you aren't going to be thrilled to hear me say this, but when you
don't get a response from the list, it is an indication that whoever knows
or owns the code in question is probably away from the list or otherwise
distracted. Asking again is probably not going to help much. I know it
isn't easy, but I suggest that you take a deep breath and start inserting
additional DEBUG** statements to work your way thru the logic of the code.
In my experience, finding these sorts of problems when you don't know the
source code, but do know the programming language and the general system
calls involved takes about a day or two of hard work. If you have a nice
repeatable test case, then count yourself lucky. By struggling through and
debugging it yourself, you will learn a lot about the modules and the code
involved, and that can be worth the trouble.
**DEBUG is the Samba macro for printing out info into the log file. While
cryptic at first glance, a few minutes of study should reveal how it works,
and permit you to add more of them in key places.
Oh, and thanks for your patience. By the way, sending HTML mail to this
list is generally a poor idea; anyone reading the mail in digest form will
see the raw HTML and probably ignore the mail. Even some ordinary mail
programs still don't deal with HTML mail. This alone might cause some
people to ignore your otherwise clearly-written posts. Note that there is
nothing in your letter that requires the use of HTML. Perhaps you can
adjust your mail client to send text instead.
HTH
PG
--
Paul Green, Senior Technical Consultant, Stratus Technologies.
Voice: +1 (978) 461-7557; FAX: +1 (978) 461-3610
Speaking from Stratus not for Stratus
-Original Message-
From: James Willard [mailto:james;whispering.org]
Sent: Monday, November 11, 2002 6:48 PM
To: [EMAIL PROTECTED]
Subject: FW: Segfault with net ads password
Hi All,
I'm still having the issues I've described below. I've tried to give as much
detail as possible, and I'm hoping to help fix this segfault bug in what
will become Samba 3. I don't believe that this problem is isolated to me and
I do believe that it does affect every other user. Please help me and allow
me to help the Samba project.
Thanks,
James Willard
[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED]
[mailto:samba-technical-admin;lists.samba.org] On Behalf Of James Willard
Sent: Friday, November 01, 2002 6:04 PM
To: 'Esh, Andrew'; [EMAIL PROTECTED]
Subject: RE: Segfault with net ads password
Andrew,
It seems like you're right about the null pointer. Given the code block you
mentioned, I rebuilt with --enable-krb5developer and ran gdb over it again
with a breakpoint at net_ads_password() and displaying ads, ads-auth, and
ads-auth.kdc_server. The following is the output from gdb at the line just
before line 885 where kerberos_set_password() is called:
3: ads-auth = {realm = 0x0, password = 0x0, user_name = 0x0, kdc_server =
0x0, flags = 0, time_offset = 0}
2: ads-auth.kdc_server = 0x0
1: ads = (ADS_STRUCT *) 0x81af8e0
And of course, the call itself... null values and all...
(usernames/passwords substituted)
(gdb)
kerberos_set_password (kpasswd_server=0x0, auth_principal=0x815c560
[EMAIL PROTECTED],
auth_password=0x815c57c Adminpass, target_principal=0xbbe5
[EMAIL PROTECTED],
new_password=0x81535a0 User, time_offset=0) at libads/krb5_setpw.c:470
470 return krb5_set_password(kpasswd_server, target_principal,
new_password, time_offset);
Ok, this officially goes beyond my abilities... who maintains the net ads
portion of Samba that could help me look into this further?
Thanks,
James Willard
[EMAIL PROTECTED]
-Original Message-
From: Esh, Andrew [mailto:AEsh;tricord.com]
Sent: Friday, November 01, 2002 4:54 PM
To: 'James Willard'; [EMAIL PROTECTED]
Subject: RE: Segfault with net ads password
Importance: High
Looks like this bit of code is failing:
utils/net_ads.c, lines 877-886, function net_ads_password
/* use the realm so we can eventually change passwords for users
in realms other than default */
if (!(ads = ads_init(realm, NULL, NULL))) return -1;
asprintf(prompt, Enter new password for %s:, argv[0]);
new_password = getpass(prompt);
ret = kerberos_set_password(ads-auth.kdc_server, auth_principal,
auth_password, argv[0], new_password,
ads-auth.time_offset);
the last line is reached with ads-auth.kdc_server as a bad (null?)
pointer. The ads_init function creates the ads structure and zeroes it.
It doesn't appear to me as though ads_init initializes ads-auth, and I
don't see where else it gets set.
-Original Message-
From: James Willard [mailto:james;whispering.org]
Sent: Friday, November 01, 2002 2:23 PM
To: [EMAIL PROTECTED]
Subject: RE: Segfault with net ads password
And as a follow-up to myself... The following is a backtrace from gdb:
Program received signal SIGSEGV, Segmentation
RE: Fixed: OpLocks caused the corruptions/slowness (Was: How Samba let us down)
Jay Ts [mailto:jay;jayts.cx] said: [excerpt] I know this is a tough issue, and I'm not sure what I'd do if I were in the driver's seat. Perhaps as a minimum, adding some documentation to the /docs directory, as Chris suggests, and also putting lines in the example smb.conf files showing how to turn off oplocks, and why. Or maybe the example smb.conf files should turn them off, with a comment explaining that the lines can be removed if the Samba server isn't serving database files, and has good network hardware, etc. Jay, your thoughts on how to fix the oplock-related corruption problem has reminded me of a long-held belief that I hold regarding the process of maintaining open-source software. The following (semi) rant is not directed at you personally, but at the Samba community. This is my personal view, not necessarily shared by anyone else on the team. (Well, I hope others share it, but I'll leave it to them to say so). My opinion is that the right fix is for anyone who is experiencing data corruption of any sort, whether with oplocks on, off, or sideways, to work with the Samba team to come up with a reproducible test case so that we can root cause the true source of the problem. Then, we can design and test some sort of fix, and no one else will ever have to worry about it. Anything less than this is guesswork. We *might* be able to think of an effective fix with the slim information we have now. We *absolutely* should be able to get a great fix with full cooperation. I'll go further and say that if you are using open-source/free software and not willing to perform this task, then you should not bother to report problems at all, but should simply stop using the software. Yes, this is an extreme position. But the ONLY way we can make Samba or any other open-source package better is with the full cooperation of the user community. Yes, I know we are asking you to spend precious time and resources on a task that benefits others more than it benefits you. But isn't this the nature of the entire open-source movement? Aren't you getting something of extremely high value for a rock-bottom price when it all works? Isn't that worth something to you? Go read Eric Raymond's essay on The Cathedral and The Bazaar; it may help give you some perspective on this movement. (http://www.tuxedo.org/~esr/). Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Computer, Inc. Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request. Speaking from Stratus not for Stratus
Thoughts on pre-production testing
Please take what I am about to say as a comment made by one computing professional to other professionals, not as personal remarks. These are my personal reflections from 30+ years of experience and not necessarily the opinions of my employer. Obviously my thoughts are motivated by today's discussions, but I hope to discuss this at a more abstract level. I participate in a number of open-source teams, and I have intimate software maintenance experience through my work, and I believe that the Samba team is the equal of any software development team anywhere. After factoring in the complexity of the problem that Samba tries to solve, the Samba team is better than any other team that I know about. As computer professionals, we owe it to our clients to thoroughly test new computing environments before releasing them to our users. I've had the privilege of working for computer vendors since 1973, and during that time I have visited or spoken with hundreds of customers in a wide variety of enterprises. I've served on, or led, many crisis-resolution teams. I say all of this so that you know that I have extensive experience in this area and am not making up ideas out of whole cloth. When a new version of a system or application is put into production and fails in some manner, the manager of that system has no acceptable excuse except I screwed up. I have heard all too many customers say We are unable to test the system to the level required by the production system. This is a feeble excuse and shows a lack of training or experience. When I hear one of our customers say it, I always challenge their statement. I share stories about how other customers test their complex production systems. I rarely have seen a case where a production system cannot be tested in advance. In almost all cases, the truth is closer to the statement We willingly risk failure on the production system to save the expense of adequate testing. People make all kinds of excuses: We can't simulate the traffic; the system is too complex; we don't have the staff, equipment, etc., etc., etc. Balderdash. Any incoming data flow can be simulated or recorded and replayed. Production systems can be broken down into subsystems, and the subsystems can be thoroughly tested. Backup systems can be used to test new versions of production software or configurations. You can purchase extra equipment just for testing. In some cases you can temporarily bring up new versions on the production system during off-peak hours. With the appropriate level of effort, any system can be tested.** However, if you truly cannot test an application to the level required by production, then it is incumbent upon you to design a roll-out program that mitigates the risks when the inevitable failure occurs. For example, instead of a big-bang cut-over, bring up a small number of users and slowly add more. Pay end-users to come in during off-hours and bang on a test version running on the real network. Make up synthetic loads. Break down the conversion into smaller steps that can be done independently. Of course, regardless of how you conduct your testing, there is always a nonzero probability of failure; we are human beings, after all; we do occasionally screw up. Therefore, design (and test!) a fall-back plan so that you have criteria and a procedure for reverting to the previous version. The least you can do is to gracefully and quickly revert to the older version. If you have not tested your system to the maximum load level, how on earth do you know where it will top out? How do you know that it won't break completely if it gets just a little busier? These are digital systems, after all, and can work perfectly at 10 transactions per second (tps), and die horribly at 11 tps. Applications and operating systems are chock-a-block full of queues and hard limits, any one of which can be a bottleneck or source of failure. My experience as an operating system engineer is that we find all sorts of interesting problems at maximum loading. In my opinion, if you haven't driven your system as hard as you can, you aren't a computing professional. People who follow good change control procedures, who thoroughly test their software and systems before deployment, and who do maximum load testing, rarely encounter business-threatening (and job-threatening) outages. These people are true professionals. People who do not perform these steps should not be surprised when they encounter problems. ** In a large enterprise, the department responsible for testing frequently does not bear the economic impact of failure. Due to a phenomena that I have dubbed micro-optimization, the testing department is often denied the resources to perform its work to a level appropriate to the task. In my view, this reflects a major managerial and organizational failure of the entire enterprise. As computing professionals, we need to forge closer working relationships with our end-users to
RE: rpc_client/cli_dfs.c (not?) moved to libsmb/cli_dfs.c
Tim Potter [mailto:[EMAIL PROTECTED]] wrote: On Sun, Oct 13, 2002 at 09:00:17PM -0400, Green, Paul wrote: HEAD has cli_dfs.c in the directory source/rpc_client. 2_2 and 3_0 have cli_dfs.c in the directory source/libsmb. These file locations match source/Makefile.in *except* in 3_0, where it claims that cli_dfs.c is in source/rpc_client. [snip] I'm just wondering whether your cvs trees are out of date. The version of Makefile.in in CVS for samba 3.0 looks in rpc_client for cli_dfs.c Hmm. I'm using rsync not CVS...Looks like I am getting the same version of Makefile.in using rsync that you see using CVS (good), but where is the actual file when you extract it from CVS? rsync puts the file into libsmb not into rpc_client. I tried deleting the rpc_client and libsmb directories and re-running the script, but it didn't help. This file is still in a different directory than Makefile.in expects. Whatever is going on, it is affecting many other samba_3_0 builds in the build farm; e.g. AIX, Linux, FreeBSD, Solaris 8, and my VOS system. So I don't think it is anything I'm doing or not doing. See http://build.samba.org and look at the failing samba_3_0 builds I tried moving cli_dfs.c from libsmb into rpc_client (by hand) and discovered that now cli_lsarpc.c is in the wrong dir. Could it be that someone back-ported some changes from head into Makefile.in but didn't move the files themselves? Here are the typical error messages. These are from the existing broken FreeBSD 3.3 build, but they are the same ones I got before I tried to fix it up by hand. configure: warning: running as non-root will disable some tests awk: script/mkproto.awk:117: (FILENAME=registry/reg_printing.c FNR=814) fatal: cannot open file `rpc_client/cli_dfs.c' for reading (No such file or directory) In file included from include/includes.h:798, from smbd/server.c:22: include/proto.h:1: unterminated `#if' conditional Thanks. PG -- Paul Green, Senior Technical Consultant, Stratus Computer, Inc. Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request. Speaking from Stratus not for Stratus
RE: rpc_client/cli_dfs.c (not?) moved to libsmb/cli_dfs.c
Gerald Carter [mailto:[EMAIL PROTECTED]] On Mon, 14 Oct 2002, Green, Paul wrote: Hmm. I'm using rsync not CVS...Looks like I am getting the same version of Makefile.in using rsync that you see using CVS (good), but where is the actual file when you extract it from CVS? rsync puts the file into libsmb not into rpc_client. Fixed. Was a missing line in CVS/Entries in the ftp/pub/unpacked directory which is where rsync gets its files from. Sorry about the annoyance. Thanks, Jerry! PG -- Paul Green, Senior Technical Consultant, Stratus Computer, Inc. Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request. Speaking from Stratus not for Stratus
RE: Sequence of buffers for reply_write
We've had similar issues on the Stratus VOS system. This isn't a Samba issue; Samba is just passing along the behavior of the top-level clients (Winword, WordPad, Excel, and so forth). The Microsoft clients presume the ability to position to anywhere in the file and write data, and they don't restrict themselves to writing data in any particular order. (Hey, they presume a POSIX world; not so surprising, really). These repositionings cannot be applied to our proprietary files, either. Any attempt to reposition leads to reporting a sudden file system failure to the client (which in turn leads to the Microsoft clients displaying a rather obscure error message). I changed Samba so that our proprietary files cannot be opened for writing; I force such files to be opened only for reading (by lying and saying that the user does not have write permission to such files). If you try to modify a read-only file, the Microsoft editors give a cogent error message. I can supply a patch for the 2.0 branch for this fix. You can check this by enabling debug messages in Samba. You can then see the sequence of calls made by a client. Your workaround sounds ok to me. Of course, it will have performance issues on large files. I'd be interested in getting a copy of your patch, if and when you implement it. PG -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 3:21 PM To: [EMAIL PROTECTED] Subject: Sequence of buffers for reply_write We are using a version of Samba that works in the Tandem OSS environment. It works with no problems. I have been trying to modify it to work with special edit files that exist on Tandem. The edit files are in a proprietary format and positioning is based on a RecordNumber. Basically, I have everything working except being able to write large files that require multiple 65K buffers to be transmitted. It seems the buffers that are passed to the reply_write() function are out of sequence... For example, the line below where startpos=262144 should be the last buffer but it is actually the 3rd buffer. I can't use the startpos to position correctly in the file because positioning in the Edit files is based on RecordNumber... not byte number. (Embedded image moved to file: pic06334.pcx) I was just wondering if what I am seeing makes sense to anyone. I can get around it by writing to memory then dumping the memory contents to disk on the close Any help would be appreciated. Pete
Patches to samba 3.0, alpha19 for Stratus VOS
I would like to propose the following patches to Samba 3.0, alpha19 so that it will build a little easier on my system. We have a fairly strict POSIX-96 implementation that is missing a few Unix-specific features. Samba comes very close to building cleanly, and with just a few more changes, is able to build on VOS. This is not the complete set of patches to get samba to run on VOS; it is just the subset that I feel properly belongs in the master code base. I have tested these changes on Stratus VOS and on a Solaris workstation. samba-3.0-alpha19 builds fine on both platforms with these changes. None of these changes are VOS-specific; and I believe they are safe for all of the Samba build platforms. Here is an explanation of the proposed changes. 1. Our file system is limited to 32-character file names, so I have renamed a few files to fit within that limit. I did my best to track down references to these files and change them to the new names. I found references to the first 2 files, but I found no references to the last 4 files. I was forced to make some arbitrary decisions to get down to 32 characters; if someone has a better suggestion, have at it. All I care is that the names fit. Affected files: samba/docs/docbook/projdoc/PAM-Authentication-and-Samba.sgml samba/docs/htmldocs/PAM-Authentication-and-Samba.html samba/source/aparser/spool_io_printer_driver_info_level_3.prs samba/source/aparser/spool_io_printer_driver_info_level_6.prs samba/testsuite/build_farm/basicsmb.smb.conf.hostsequiv.template samba/testsuite/build_farm/basicsmb.smb.conf.invalidusers.template 2. We do not provide the syslog() function or syslog.h header. Samba almost doesn't care, but there is one dangling reference. Affected files: source/include/includes.h 3. Removal of the only reference to the non-POSIX declaration caddr_t. Affected file: source/lib/util_sock.c 4. Cleanup of mis-matched references to S_ISUID and S_ISVTX. (Bug fix!). Affected file: source/libsmb/clifile.c 5. Conditional inclusion of sys/select.h. Affected file: source/nsswitch/winbind_nss_config.h 6. We do not implement System-V style shared memory. The only client that uses this feature is the profiling code. This code is already pretty much #ifdef'd out when not in use. I simply ifdef'd out a few more spots. Affected files: source/profile/profile.c source/utils/status.c samba_patch.txt.gz Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Technologies. Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request. samba_patch.txt.gz Description: Binary data
RE: Patches to samba 3.0, alpha19 for Stratus VOS
Jelmer Vernooij [mailto:[EMAIL PROTECTED]] writes: On Wed, Aug 21, 2002 at 05:03:21PM -0400, Green, Paul wrote about 'Patches to samba 3.0, alpha19 for Stratus VOS': I would like to propose the following patches to Samba 3.0, alpha19 so that it will build a little easier on my system. We have a fairly strict POSIX-96 implementation that is missing a few Unix-specific features. Samba comes very close to building cleanly, and with just a few more changes, is able to build on VOS. This is not the complete set of patches to get samba to run on VOS; it is just the subset that I feel properly belongs in the master code base. I have tested these changes on Stratus VOS and on a Solaris workstation. samba-3.0-alpha19 builds fine on both platforms with these changes. None of these changes are VOS-specific; and I believe they are safe for all of the Samba build platforms. Patch applied but without shortening the names. The problematic files are not necessary for samba to function properly anyway. Thanks very much. I appreciate it. I thought that was probably true for the last 4 files; is it also true for the sgml/html files? Those files were only 1 character over the limit...sigh. PG
POSIX-2001 spec is online and free
I thought that people might be interested to know that the new 2001 revision of the POSIX specification (IEEE Std 1003.1-2001) is available online, for free (simple registration required), at the following URL: http://www.unix-systems.org/version3 If you want an electronic copy (PDF format), you can purchase it for US $176 (IEEE member price; $220 otherwise) at www.ieee.org. The 1996 edition of POSIX (ISO/IEC 9945-1:1996) costs $224 and is available from ANSI (www.ansi.org). Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Technologies. Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request.
RE: Eliminating gettimeofday from construct_reply
Andrew Bartlett [mailto:[EMAIL PROTECTED]] wrote: Richard Sharpe wrote: Hi, I looked at this issue, and it looks possible to accumulate the timeouts that have occured in receive_message_or_smb and count those up. Given that the resolution of the dead time parameter is in minutes, this would seem to not get too far out of whack. Sounds like a fair optimization to me - assuming that's what it is for. Pardon my skepticism, but is there any evidence that calling gettimeofday from this location in the code is actually contributing in any material way to the performance of Samba? Any measurements? If there isn't, then you are just optimizing based on by guess and by golly, and could be (almost certainly will be) introducing a maintenance headache, or an unwitting platform dependency, by trying to second-guess them. You could also make operating Samba from within a debugger (or during profiling) rather touchy, since your accumulating probably won't work in the face of breakpoints. If this code was mine, I'd insist that you prove to me that this change would result in at least a 3% or more gain in performance. I seriously doubt whether you could reach this bar. Why? Well, in all probability the TCP stack does multiple time calls all on its own for every packet, and the cost of sending the data probably far outweighs the cost of reading the clock, so I think this time call is lost in the noise. soapbox (1) Operating system engineers know that their time routines are going to get heavily called and generally try to optimize them. We certainly try on our OS. (2) This routine has fairly high resolution. If you don't need this level of resolution, you might use time(), which is probably cheaper, and certainly no more expensive (and POSIX-compliant, whereas gettimeofday() is not in POSIX-96). (3) Optimize based on measurements not reading code. /soapbox Let me just add that I've wasted all too many working days in my career by trying to optimize code by inspection. When I actually take the time to run a benchmark and then optimize the hot spots, I get much better results in much less (human) time. Thanks. PG -- Paul Green, Senior Technical Consultant, Stratus Computer, Inc. Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request.
RE: Possible bug: File changed as we read it
Bert Buckley [mailto:[EMAIL PROTECTED]] writes (edited for brevity): Synopsis: I do daily dumps from a Linux box of the Windows machines on my network. (Kernel 2.4.7-10, Redhat 7.2., samba-2.2.1a-4 ) These are done overnight. I mount the appropriate shared directories as a samba filesystem and use tar to incrementally dump all recently changed files (using their time stamp). [snip] I now get a number of errors of the form: tar: ./Toxocara/Restore/Toxocara.mdb: file changed as we read it The files that generate these errors are completely static. There are 4 to 6 of them. It seems always to be the same files. Their timestamps look perfectly normal. There is nothing that I can find that is altering these files. Their timestamps have not changed. I have seen tar do this when the number of bytes returned by reading the file does not agree with the size return by stat(). You can verify this by writing a small test program that stats the file and then reads until EOF counting up the bytes read. If this small test case fails, then tar is absolved. Are these local files or remotely-mounted (NFS) files? Are they sparse files? Yeah, these things should not matter, but... Oh, and are the copies created by tar the same as the originals or not? You didn't say. (And then the completely generic answer...) Your version of Samba is rather old. You might try the current version (2.2.5). Hope this sheds a small amount of light. PG
RE: Draft of branch maintainence and release plans....
David Lee [mailto:[EMAIL PROTECTED]] wrote (edited for brevity): Could I add a few things for consideration? To a first approximation, I'm assuming that the foundation work can only be done by the Samba Team. (Is this a fair assumption in the items listed?) In the case of the panic action, as I will elaborate shortly, I believe that a few OS experts could work independently and then submit some work back to the Samba Team. panic action Some months ago we had a discussion about panic action, and agreed on the desirability of improving the default behaviour, so that, if reasonably possible, it would automatically attempt to invoke a debugging program to dump a backtrace into that smbd's own log file. And in the last few days, this list has seen another example of a sys.admin. who (like me and many others of us) would have been able to benefit if a default debug/backtrace had been in place. I would be willing to work (off-list) with a small number of OS experts to agree on an API for producing a back-trace of the stack. I know how we do this for VOS, I know some of the issues involved, and I believe that such an API definition should be independent of Samba. The challenge is to produce an OS-independent API that is flexible enough to accommodate the rather wide variety of operating systems, while hiding the guts of the mechanism from the callers. (The code to actually traverse the stack and produce output that can be interpreted by mortals or even by code is almost certainly going to be OS-specific, but I think we can probably produce an API that we can all then implement). If anyone else considers themselves qualified interested, please contact me off-list. Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Technologies. Day: +1 978-461-7557; FAX: +1 978-461-3610 Speaking from Stratus not for Stratus
RE: [PATCH] Clean up samba-3.0 for POSIX-96
Gerald (Jerry) Carter [mailto:[EMAIL PROTECTED]] writes:
On Fri, 31 May 2002 [EMAIL PROTECTED] wrote:
source/lib/interfaces.c conditionally include sys/time.h and
sys/sockio.h (autoconf macros
already exist)
This change broke SAMBA_2_2. The reason is that lib/interfaces.c
is used in the autoconf test so sys/sockio.h would never be
included. Any thoughts? I've removed it from 2.2. for now
and will look into it some more.
Try this patch. I copied the #include of sys/sockio.h inside of the 3
ifdef'd regions that need it. This kind of even makes sense, because now on
systems that don't implement any of the 3 ways of determining the
interfaces, they don't need sys/sockio.h. (And we don't implement any of
the 3 ways, and don't have this header). This should be a safe patch for
everyone.
Now that I see what is going on, and where I went wrong, I can't help but
notice that there is another HAVE_xxx macro referenced before #include
config.h (HAVE_SYS_TIME_H). I took a brief look at configure, and it does
not appear to ever set HAVE_SYS_TIME_H. But I also see some logic about
site-config files, so perhaps that's a way. At any rate, since I don't need
to change this, and since it is presumably not harming anyone, I have left
it alone. There are also some other HAVE_xxx macros after the #include of
config.h but again, I left these alone.
I re-ran configure and make after this change, and both work ok. This patch
is against the 2.2.4 sources prior to my previous change (I assume that's
where you backed the file up to).
If my changes were applied to the 3.0 tree, then this change needs to be
made there too.
### START OF PATCH ###
--- oldsambasourcelibinterfaces.cWed Jun 5 12:57:57 2002
+++ newsambasourcelibinterfaces.cWed Jun 5 12:58:11 2002
@@ -44,10 +44,6 @@
#endif
#include net/if.h
-#ifndef SIOCGIFCONF
-#include sys/sockio.h
-#endif
-
#ifdef AUTOCONF_TEST
struct iface_struct {
char name[16];
@@ -81,6 +77,10 @@ struct iface_struct {
#if HAVE_IFACE_IFCONF
+#ifndef SIOCGIFCONF
+#include sys/sockio.h
+#endif
+
/* this works for Linux 2.2, Solaris 2.5, SunOS4, HPUX 10.20, OSF1
V4.0, Ultrix 4.4, SCO Unix 3.2, IRIX 6.4 and FreeBSD 3.2.
@@ -153,6 +153,10 @@ static int _get_interfaces(struct iface_
#elif HAVE_IFACE_IFREQ
+#ifndef SIOCGIFCONF
+#include sys/sockio.h
+#endif
+
#ifndef I_STR
#include sys/stropts.h
#endif
@@ -247,6 +251,10 @@ static int _get_interfaces(struct iface_
}
#elif HAVE_IFACE_AIX
+
+#ifndef SIOCGIFCONF
+#include sys/sockio.h
+#endif
/***
*
this one is for AIX (tested on 4.2)
### END OF PATCH ###
Thanks
PG
--
Paul Green, Senior Technical Consultant, Stratus Technologies.
Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request.
RE: Broken change to lib/interfaces.c in last night's 2_2 CVS - Fix Enclosed
Mea culpa. Thanks, Rich. PG Richard Bollinger [mailto:[EMAIL PROTECTED]] writes: Problem is that there are ifdef tests depending on the contents of config.h before it's included. This patch moves up that include to the beginning:
RE: samba-patches heads up
Andrew Bartlett [mailto:[EMAIL PROTECTED]] writes: Green, Paul wrote: A brief note that I am building Samba 2.2.4 with a fussy POSIX environment and catching a number of small bugs and minor glitches in the source code. I am posting the patches to [EMAIL PROTECTED] I am pleased to say that the source code of Samba 2.2.4 is significantly cleaner with respect to the POSIX-1996 standard than the old 2.0.7 version, which was the last release we ported to Stratus VOS. (Our POSIX environment has grown and matured in the intervening time as well, which also helps). I note in passing that there seems to be quite a backlog in the samba-patches queue; I'm sorry to add to it. The 'direct to interested parties' queue is much shorter... CC me and the list on a bulk (but sane) patch, and I'll see what I can do. (I can apply these to HEAD, but I try not to mess with 2.2). Thanks, will do this later this week, after the holiday. PG
RE: Some people owe me doc updates...
Gerald Carter [mailto:[EMAIL PROTECTED]] writes: I need smb.conf entries for * admin log * inherit acls * lock spin count * lock spin time * winbind use default domain And yes I could look in the code, but the rule is you add a parameter, you update the docs. Thanks for the help on this. I'm just about to release 2.2.4 as soon as I get the smb.conf man page up to date. Suggestion: in the future turn down code changes w/o accompanying documentation changes. Yes, it is a tough stance, and yes, you might lose a few nice features, or a few coders. But I think it more likely that people will accept the new situation and rise to the challenge. Samba is a critical product these days and having such a requirement would simply recognize that fact. In actuality, I think the actual policy would be to simply defer the commit until the author supplies the documentation changes. Over on the perl5-porters list, where I've been working for ~6 months, we have a pretty good record of getting code changes, docu changes, and test case additions or changes all at the same time. Not perfect, but pretty good. Of course, maybe you are doing this already, and because I've been away for a while I didn't notice. If that's the case, ignore this. PG
