Signal 11 (SEGV - Segmentation Fault) after tdb_unpack
I recently newly built Samba 3.0 from CVS, and tried it. I have a problem with it. On connection to it - that is, when giving the password, the connection terminates In the log file for the machine, after a few things like: tdb_unpack(ddffd, 23) - 19 [2003/02/17 12:06:05, 18] ../source/tdb/tdbutil.c:tdb_unpack(558) tdb_unpack(d, 4) - 4 [2003/02/17 12:06:05, 18] ../source/tdb/tdbutil.c:tdb_unpack(558) tdb_unpack(ddffd, 30) - 26 [2003/02/17 12:06:05, 18] ../source/tdb/tdbutil.c:tdb_unpack(558) tdb_unpack(d, 4) - 4 I have: [2003/02/17 12:06:05, 0] ../source/lib/fault.c:fault_report(36) === [2003/02/17 12:06:05, 0] ../source/lib/fault.c:fault_report(37) INTERNAL ERROR: Signal 11 in pid 49179 (post3.0-HEAD) Please read the file BUGS.txt in the distribution [2003/02/17 12:06:05, 0] ../source/lib/fault.c:fault_report(39) === [2003/02/17 12:06:05, 0] ../source/lib/util.c:smb_panic(1415) PANIC: internal error A problem it is. That is when trying to connect to a share, both with Windows and smbclient, after giving the password. The source is slightly patched - with an auth module and a passdb module added, but it used to work previously with the same modifications, and it does not seem related. I don't know what exactly other information would help, I cannot really guess a direction, except the tdb routines, which seem to be fine. A BUGS.txt file does not seem to exist. Will somewhen go into deeper debugging of it, but I wondered if anyone has any idea... Thank you, any help appreciated, -- Tom -- A man on a boat... A cat on a train. He's clearing his throat... She's smearing a stain.
Patch: (Problem with nt acl support when saving Excel or WordFiles)
Hi all,
tried to dig into it, testing with various clients, browsing level 10 logs
and hacking posic_acls.c, which are all almost equally trivial (read: oh
dear it got my head spinning. :).
I think there are basically two problem:
1. Windows clients do not always send ACEs for SMB_ACL_USER_OBJ, SMB_ACL_GROUP_OBJ,
and SMB_ACL_OTHER.
The function ensure_canon_entry_valid() is prepared for that, but tries
to guess values from group or other permissions, respectively, otherwise
falling back to minimum r-- for the owner. Even if the owner had full
permissions before setting ACL. This is the problem with W2k clients.
2. Function set_nt_acl() always chowns *before* attempting to set POSIX ACLs.
This is ok in a take-ownership situation, but must fail if the file is
to be given away. This is the problem with XP clients, trying to transfer
ownership of the original file to the temp file.
The problem with NT4 clients (no ACEs are transferred to the temp file, thus
are lost after moving the temp file to the original name) is a client problem.
It simply doesn't attempt to.
I have played around with that using posic_acls.c from 3.0 merged into 2.2.
As a result I can now present two patches, one for each branch. They
basically modify:
1. Interpret missing SMB_ACL_USER_OBJ, SMB_ACL_GROUP_OBJ, or SMB_ACL_OTHER
as preserve current value instead of attempting to build one ourself.
The original code is still in, but only as fallback in case current values
can't be retrieved.
2. Rearrange set_nt_acl() such that chown is only done before setting
ACLs if there is either no change of owning user, or change of owning
user is towards the current user. Otherwise chown is done after setting
ACLs.
It now seems to produce reasonable results. (Well, as far as it can. If
NT4 doesn't even try to transfer ACEs, only deliberate use of named default
ACEs and/or force group or the crystal ball can help :)
I have tested this with HP-UX, but it shouldn't be platform dependent.
Maybe someone could try on a different platform?
Cheers!
Michael
Index: source/smbd/posix_acls.c
===
RCS file: /cvsroot/samba/source/smbd/posix_acls.c,v
retrieving revision 1.1.4.67
diff -u -r1.1.4.67 posix_acls.c
--- source/smbd/posix_acls.c8 Oct 2002 00:19:43 - 1.1.4.67
+++ source/smbd/posix_acls.c17 Feb 2003 09:47:51 -
@@ -1,8 +1,8 @@
/*
- Unix SMB/Netbios implementation.
- Version 1.9.
+ Unix SMB/CIFS implementation.
SMB NT Security Descriptor / Unix permission conversion.
- Copyright (C) Jeremy Allison 1994-2000
+ Copyright (C) Jeremy Allison 1994-2000.
+ Copyright (C) Andreas Gruenbacher 2002.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -105,7 +105,7 @@
dbgtext( canon_ace index %d. Type = %s , num, pace-attr == ALLOW_ACE ?
allow : deny );
dbgtext( SID = %s , sid_to_string( str, pace-trustee));
if (pace-owner_type == UID_ACE) {
- char *u_name = uidtoname(pace-unix_ug.uid);
+ const char *u_name = uidtoname(pace-unix_ug.uid);
dbgtext( uid %u (%s) , (unsigned int)pace-unix_ug.uid, u_name);
} else if (pace-owner_type == GID_ACE) {
char *g_name = gidtoname(pace-unix_ug.gid);
@@ -331,6 +331,32 @@
}
/
+ Check if we need to return NT4.x compatible ACL entries.
+/
+
+static BOOL nt4_compatible_acls(void)
+{
+ /*
+* Should be
+*
+* const char *compat = lp_acl_compatibility();
+*
+* but we don't have this parameter in 2.2, yet. Always
+* adapt to client.
+*/
+ const char *compat = ;
+
+ if (*compat == '\0') {
+ enum remote_arch_types ra_type = get_remote_arch();
+
+ /* Automatically adapt to client */
+ return (ra_type = RA_WINNT);
+ } else
+ return (strequal(compat, winnt));
+}
+
+
+/
Map canon_ace perms to permission bits NT.
The attr element is not used here - we only process deny entries on set,
not get. Deny entries are implicit on get with ace-perms = 0.
@@ -346,7 +372,19 @@
if ((ace-perms ALL_ACE_PERMS) == ALL_ACE_PERMS) {
nt_mask = UNIX_ACCESS_RWX;
} else if ((ace-perms ALL_ACE_PERMS) == (mode_t)0) {
- nt_mask = UNIX_ACCESS_NONE;
+ /*
+* Windows NT refuses to display ACEs with no permissions in them (but
+* they are perfectly legal with Windows 2000). If the ACE has empty
+* permissions we cannot use 0, so we use
problem with oplocks.
Hi. I use samba with linux 7.2 kernel 4.7, samba 2.2.1a I have this in ma station's log: log.irek [2003/02/17 12:32:07, 0] lib/util_sock.c:read_socket_data(478) read_socket_data: recv failure for 4. Error = Connection reset by peer [2003/02/17 12:48:33, 0] lib/util_sock.c:read_socket_data(478) read_socket_data: recv failure for 4. Error = Connection reset by peer [2003/02/17 13:01:38, 0] smbd/oplock.c:oplock_break(769) oplock_break: receive_smb timed out after 30 seconds. oplock_break failed for file Irek.bat (dev = 900, inode = 915838). [2003/02/17 13:01:38, 0] smbd/oplock.c:oplock_break(843) oplock_break: client failure in oplock break in file Irek.bat What is goin on ? My dos application (writen in foxpro) opened tables, at start very slow, later goes fine, fast. The content of log.irek i show above. Is there any solution to avoid these errors ?? With redhat 6.2 and samba 2.0.2 (?) tehere were no errors. Regards, Irek --r-e-k-l-a-m-a- Tanie bilety lotnicze! http://samoloty.onet.pl
Re: problem with oplocks.
On Mon, 2003-02-17 at 14:42, Ireneusz Piasecki wrote: Hi. I use samba with linux 7.2 kernel 4.7, samba 2.2.1a Is there any solution to avoid these errors ?? With redhat 6.2 and samba 2.0.2 (?) tehere were no errors. Hi, I had the same problems. Upgrade your samba to 2.2.7a and it will work OK. It was fixed about 2.2.6 AFAIK. BTW, oplocks are unreliable by definition, so I don't use them. The small speed improvement (if any) is not worth loosing data integrity from my point of view. Regards, Olaf Fraczyk
crash when setting up default page properties in samba 3.0alpha20
Hello, we have a printserver, which was originally build with samba 2.2.5. For some reason, we switched to samba 3.0alpha20 later, which worked fine. The only problem is, that it crashes when changing the default page properties (NT4: printer - right mouse button - default page properties (translated from german)), like shown in the attached debug output. The printer driver is a HP LaserJet 2100 Series PS Driver. The UNC-Name of the printer is 40 chars long, and in rpc_server/srv_spoolss_nt.c, function convert_devicemode(), is the following code: rpcstr_pull(nt_devmode-devicename,devmode-devicename.buffer, 31, -1, 0); rpcstr_pull(nt_devmode-formname,devmode-formname.buffer, 31, -1, 0); Unfortunatly changing the 31 to some greater value, didn't help. Any hints? Greetings, Peter api_rpcTNP: api_spoolss_rpc op 0x7 - api_rpcTNP: rpc command: SPOOLSS_SETPRINTER [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_debug(81) 00 spoolss_io_q_setprinter [2003/02/06 14:08:59, 6] rpc_parse/parse_prs.c:prs_debug(81) 00 smb_io_pol_hnd printer handle [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) data1: [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 0004 data2: 0001 [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint16(582) 0008 data3: [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint16(582) 000a data4: [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint8s(698) 000c data5: 65 5e 42 3e f8 42 00 00 [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 0014 level: 0002 [2003/02/06 14:08:59, 6] rpc_parse/parse_prs.c:prs_debug(81) 18 spool_io_printer_info_level [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 0018 level: 0002 [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 001c info_ptr: 029a7b00 [2003/02/06 14:08:59, 7] rpc_parse/parse_prs.c:prs_debug(81) 20 spool_io_printer_info_level_2 [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 0020 servername_ptr: 0018d140 [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 0024 printername_ptr: 0018d168 [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 0028 sharename_ptr: 0018d1c8 [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 002c portname_ptr: 0018d210 [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 0030 drivername_ptr: 0018d244 [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 0034 comment_ptr: 0018d288 [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 0038 location_ptr: 0018d2b8 [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 003c devmode_ptr: 0018d31c [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 0040 sepfile_ptr: 0018d2c8 [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 0044 printprocessor_ptr: 0018d2d8 [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 0048 datatype_ptr: 0018d2f8 [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 004c parameters_ptr: 0018d30c [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 0050 secdesc_ptr: [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 0054 attributes: 0018 [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 0058 priority: 0001 [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 005c default_priority: 0001 [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 0060 starttime: [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 0064 untiltime: [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 0068 status: [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 006c cjobs: [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 0070 averageppm: [2003/02/06 14:08:59, 8] rpc_parse/parse_prs.c:prs_debug(81) 74 smb_io_unistr2 servername [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 0074 uni_max_len: 000d [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 0078 undoc : [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611) 007c uni_str_len: 000d [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:dbg_rw_punival(783) 0080 buffer : \.\.p.r.i.n.t.a.d.m.i.n... [2003/02/06 14:08:59, 8] rpc_parse/parse_prs.c:prs_debug(81) 9a smb_io_unistr2 printername [2003/02/06 14:08:59, 5] rpc_parse/parse_prs.c:prs_uint32(611)
Re: Build problem with libiconv
On Mon, Feb 17, 2003 at 07:04:55AM -0500, Ken Cross wrote:
Samba-folk:
When building SAMBA_3_0 on NetBSD (and I think any OS except Linux,
Solaris, or OSF) with iconv support, configure can't figure out that
iconv is really present. It's because in iconv.h, it defines:
#ifndef LIBICONV_PLUG
#define iconv_open libiconv_open
#endif
where LIBICONV_PLUG is defined on OS's with plug libraries (Linux,
Solaris, or OSF). What I've done locally to fix it is:
Index: configure.in
===
RCS file: /cvsroot/samba/source/configure.in,v
retrieving revision 1.300.2.43
diff -p -u -r1.300.2.43 configure.in
--- configure.in14 Feb 2003 00:47:27 - 1.300.2.43
+++ configure.in17 Feb 2003 11:56:37 -
@@ -1490,7 +1490,7 @@ AC_ARG_WITH(libiconv,
AC_MSG_RESULT(yes)
CFLAGS=$CFLAGS -I$withval/include
LDFLAGS=$LDFLAGS -L$withval/lib
-AC_CHECK_LIB(iconv, iconv_open)
+AC_CHECK_LIB(iconv, libiconv_open)
AC_DEFINE_UNQUOTED(WITH_LIBICONV, ${withval},[Path to iconv])
;;
esac ],
However, I think this'll break OS's with plug libraries (Linux, Solaris,
or OSF). What configure should really do is try one (iconv_open) then
the other (libiconv_open). (I'm not sure what's involved in that or I'd
have done it.)
The better approach is to use a code which allows to find all types of ICONV(3).
We use following in Midgard's core for years:
dnl From Bruno Haible.
AC_DEFUN(jm_ICONV,
[
dnl Some systems have iconv in libc, some have it in libiconv (OSF/1 and
dnl those with the standalone portable libiconv installed).
AC_MSG_CHECKING(for iconv in $1)
jm_cv_func_iconv=no
jm_cv_lib_iconv=no
jm_cv_giconv=no
AC_TRY_LINK([#include stdlib.h
#include giconv.h],
[iconv_t cd = iconv_open(,);
iconv(cd,NULL,NULL,NULL,NULL);
iconv_close(cd);],
jm_cv_func_iconv=yes
jm_cv_giconv=yes)
if test $jm_cv_func_iconv != yes; then
AC_TRY_LINK([#include stdlib.h
#include iconv.h],
[iconv_t cd = iconv_open(,);
iconv(cd,NULL,NULL,NULL,NULL);
iconv_close(cd);],
jm_cv_func_iconv=yes)
if test $jm_cv_lib_iconv != yes; then
jm_save_LIBS=$LIBS
LIBS=$LIBS -lgiconv
AC_TRY_LINK([#include stdlib.h
#include giconv.h],
[iconv_t cd = iconv_open(,);
iconv(cd,NULL,NULL,NULL,NULL);
iconv_close(cd);],
jm_cv_lib_iconv=yes
jm_cv_func_iconv=yes
jm_cv_giconv=yes)
LIBS=$jm_save_LIBS
if test $jm_cv_func_iconv != yes; then
jm_save_LIBS=$LIBS
LIBS=$LIBS -liconv
AC_TRY_LINK([#include stdlib.h
#include iconv.h],
[iconv_t cd = iconv_open(,);
iconv(cd,NULL,NULL,NULL,NULL);
iconv_close(cd);],
jm_cv_lib_iconv=yes
jm_cv_func_iconv=yes)
LIBS=$jm_save_LIBS
fi
fi
fi
if test $jm_cv_func_iconv = yes; then
if test $jm_cv_giconv = yes; then
AC_DEFINE(HAVE_GICONV, 1, [Define if you have the iconv() function.])
ICONV_INCLUDE=giconv.h
AC_MSG_RESULT(yes)
ICONV_FOUND=yes
else
AC_DEFINE(HAVE_ICONV, 1, [Define if you have the iconv() function.])
ICONV_INCLUDE=iconv.h
AC_MSG_RESULT(yes)
ICONV_FOUND=yes
fi
else
AC_MSG_RESULT(no)
fi
if test $jm_cv_lib_iconv = yes; then
if test $jm_cv_giconv = yes; then
LIBS=$LIBS -lgiconv
else
LIBS=$LIBS -liconv
fi
fi
])
--
/ Alexander Bokovoy
---
ignorance, n.:
When you don't know anything, and someone else finds out.
RE: WINS server incorrectly ignores 127.0.0.1 requests
Please disregard this stale e-mail. It has been subsumed by bug fix?: 2.2.7a, nmbd/nmbd_packets.c, listen_for_packets() Thanks, Peter Hurley [EMAIL PROTECTED]
[patch] libsmbclient: shared or static libs, never both?
Currently, SAMBA_3_0 uses the following code to decide whether to build
shared or static libs:
[ case $withval in
no)
AC_MSG_RESULT(no)
;;
*)
if test $BLDSHARED = true; then
INSTALLCLIENTCMD_SH=\$(INSTALLCMD)
LIBSMBCLIENT_SHARED=bin/libsmbclient.$SHLIBEXT
LIBSMBCLIENT=libsmbclient
AC_MSG_RESULT(yes)
else
INSTALLCLIENTCMD_A=\$(INSTALLCMD)
LIBSMBCLIENT=libsmbclient
AC_MSG_RESULT(no shared library support -- will supply static library)
fi
;;
esac ],
This makes it an either-or choice. 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.
--
Steve Langasek
postmodern programmer
diff -uNr samba-3.0alpha21.orig/source/aclocal.m4 samba-3.0alpha21/source/aclocal.m4
--- samba-3.0alpha21.orig/source/aclocal.m4 2003-02-16 19:34:05.0 -0600
+++ samba-3.0alpha21/source/aclocal.m4 2003-02-16 22:00:20.0 -0600
@@ -485,3 +485,67 @@
done
$1=[$]ac_new_flags
])
+
+dnl AC_ENABLE_SHARED - implement the --enable-shared flag
+dnl Usage: AC_ENABLE_SHARED[(DEFAULT)]
+dnl Where DEFAULT is either `yes' or `no'. If omitted, it defaults to
+dnl `yes'.
+AC_DEFUN([AC_ENABLE_SHARED],
+[define([AC_ENABLE_SHARED_DEFAULT], ifelse($1, no, no, yes))dnl
+AC_ARG_ENABLE(shared,
+changequote(, )dnl
+ --enable-shared[=PKGS]build shared libraries
+[default=AC_ENABLE_SHARED_DEFAULT],
+changequote([, ])dnl
+[p=${PACKAGE-default}
+case $enableval in
+yes) enable_shared=yes ;;
+no) enable_shared=no ;;
+*)
+ enable_shared=no
+ # Look at the argument we got. We use all the common list separators.
+ IFS=${IFS= }; ac_save_ifs=$IFS; IFS=${IFS}:,
+ for pkg in $enableval; do
+if test X$pkg = X$p; then
+ enable_shared=yes
+fi
+
+ done
+ IFS=$ac_save_ifs
+ ;;
+esac],
+enable_shared=AC_ENABLE_SHARED_DEFAULT)dnl
+])
+
+dnl AC_ENABLE_STATIC - implement the --enable-static flag
+dnl Usage: AC_ENABLE_STATIC[(DEFAULT)]
+dnl Where DEFAULT is either `yes' or `no'. If omitted, it defaults to
+dnl `yes'.
+AC_DEFUN([AC_ENABLE_STATIC],
+[define([AC_ENABLE_STATIC_DEFAULT], ifelse($1, no, no, yes))dnl
+AC_ARG_ENABLE(static,
+changequote(, )dnl
+ --enable-static[=PKGS]build static libraries
+[default=AC_ENABLE_STATIC_DEFAULT],
+changequote([, ])dnl
+[p=${PACKAGE-default}
+case $enableval in
+yes) enable_static=yes ;;
+no) enable_static=no ;;
+*)
+ enable_static=no
+ # Look at the argument we got. We use all the common list separators.
+ IFS=${IFS= }; ac_save_ifs=$IFS; IFS=${IFS}:,
+ for pkg in $enableval; do
+if test X$pkg = X$p; then
+ enable_static=yes
+fi
+ done
+ IFS=$ac_save_ifs
+ ;;
+esac],
+enable_static=AC_ENABLE_STATIC_DEFAULT)dnl
+])
+
+dnl AC_DISABLE_STATIC - set the default static flag to --disable-static
+AC_DEFUN([AC_DISABLE_STATIC],
+[AC_BEFORE([$0],[AC_LIBTOOL_SETUP])dnl
+AC_ENABLE_STATIC(no)])
diff -uNr samba-3.0alpha21.orig/source/configure.in
samba-3.0alpha21/source/configure.in
--- samba-3.0alpha21.orig/source/configure.in 2003-02-16 19:34:08.0 -0600
+++ samba-3.0alpha21/source/configure.in2003-02-16 22:05:07.0 -0600
@@ -6,6 +6,9 @@
AC_INIT(include/includes.h)
AC_CONFIG_HEADER(include/config.h)
+AC_DISABLE_STATIC
+AC_ENABLE_SHARED
+
#
# Directory handling stuff to support both the
# legacy SAMBA directories and FHS compliant
@@ -983,9 +986,8 @@
AC_LIBTESTFUNC(security, getprpwnam)
AC_LIBTESTFUNC(sec, getprpwnam)
-# this bit needs to be modified for each OS that is suported by
-# smbwrapper. You need to specify how to created a shared library and
-# how to compile C code to produce PIC object files
+# Assume non-shared by default and override below
+BLDSHARED=false
# these are the defaults, good for lots of systems
HOST_OS=$host_os
@@ -996,12 +998,16 @@
PICSUFFIX=po
POBAD_CC=#
SHLIBEXT=so
-# Assume non-shared by default and override below
-BLDSHARED=false
-AC_MSG_CHECKING([ability to build shared libraries])
-# and these are for particular systems
-case $host_os in
+if test $enable_shared = yes; then
+ # this bit needs to be modified for each OS that is suported by
+ # smbwrapper. You need to specify how to created a shared library and
+ # how to compile C code to produce PIC object files
+
+ AC_MSG_CHECKING([ability to build shared libraries])
+
+ # and these are for particular systems
+ case $host_os in
*linux*) AC_DEFINE(LINUX,1,[Whether the host os is linux])
BLDSHARED=true
LDSHFLAGS=-shared
@@ -1145,13 +1151,14 @@
*)
AC_DEFINE(STAT_ST_BLOCKSIZE,512)
;;
-esac
-AC_SUBST(DYNEXP)
-AC_MSG_RESULT($BLDSHARED)
Question about srv_spoolss_send_event_to_client()
In rpc_server/srv_spoolss_nt.c:srv_spoolss_send_event_to_client(): Could someone tell me why the following lines of code were added? if (Printer-printer_type == PRINTER_HANDLE_IS_PRINTSERVER) msg-flags |= PRINTER_MESSAGE_ATTRIBUTES; The problem is that sending expanded NOTIFY_INFO_DATA in the RRPCN request for a printserver causes W2k clients to ** NOT ** send RFNPCNEX requests. The upshot is that when a W2k client opens the Printers window on the print server and selects a printer, the printer status will not change during subsequent operations (say pausing and unpausing). Commenting out the lines of code above had the desired effect (i.e., fixed that problem), but I'm concerned since someone put it in to begin with. If the above is absolutely necessary, then the fix is much more complicated. Thanks, Peter Hurley [EMAIL PROTECTED]
Re: problem with oplocks.
On Mon, Feb 17, 2003 at 02:53:14PM +0100, Olaf Fr?czyk wrote: On Mon, 2003-02-17 at 14:42, Ireneusz Piasecki wrote: Hi. I use samba with linux 7.2 kernel 4.7, samba 2.2.1a Is there any solution to avoid these errors ?? With redhat 6.2 and samba 2.0.2 (?) tehere were no errors. Hi, I had the same problems. Upgrade your samba to 2.2.7a and it will work OK. It was fixed about 2.2.6 AFAIK. BTW, oplocks are unreliable by definition, so I don't use them. The small speed improvement (if any) is not worth loosing data integrity from my point of view. Um... Just curious, but how are oplocks are unreliable by definition? Chris -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
Max file size limit in Samba
Hi I am using Samba on Linux. I noticed that I cannot create a file size of more than 2 GB. Is there a fix for this? Thanks a lot. Mary
Re: Max file size limit in Samba
On Mon, 17 Feb 2003, mary manohar wrote: Hi I am using Samba on Linux. I noticed that I cannot create a file size of more than 2 GB. Is there a fix for this? Update to Linux kernel 2.4.x and to a recent version of samba that has been compiled on kernel 2.4.x. - John T. -- John H Terpstra Email: [EMAIL PROTECTED]
Re: Annoying Minor Bug In Winbind 2.2.x
On 17 Feb 2003, Boyce, Nick [EMAIL PROTECTED] wrote: OK - I've been trying to apply the patch that Tim posted (to supersede Martin's first cut) to the Samba 2.2.7a source file for util_sock.c, but get errors applying the patch no matter what I do. Thanks for trying that. I guess the posted patch was against CVS, so could someone please repost the patch for the 2.2.7a-rel version of the file ? I'll do that. -- Martin If it's worth doing, it's worth doing for money.
Re: Annoying Minor Bug In Winbind 2.2.x
On 17 Feb 2003, Boyce, Nick [EMAIL PROTECTED] wrote: Here's what I get if I apply the posted patch : As I said I'll send you an update just for 2.2. But in general, in case you're interested, here are some tips on applying mismatched patches: MYBOX:/usr/local/src/samba-2.2.7a/source/lib# patch util_sock.c patch-util_sock.txt.orig patching file util_sock.c Hunk #1 succeeded at 1018 with fuzz 2 (offset 133 lines). Hunk #2 FAILED at 1037. Hunk #3 FAILED at 1094. 2 out of 3 hunks FAILED -- saving rejects to file util_sock.c.rej In general the best thing to do now is leave the main diff alone, and only work on the rejected parts in the .rej file. Basically you need to work out why patch thinks the 2.2 source file doesn't look like the before version of the rejected patch. After deleting the line containing #ifdef HAVE_UNIXSOCKET (because I noticed it doesn't appear in my 2.2.7a version of util_sock.c), I get a little further : MYBOX:/usr/local/src/samba-2.2.7a/source/lib# patch util_sock.c patch-util_sock.txt patching file util_sock.c Hunk #1 succeeded at 1018 with fuzz 2 (offset 133 lines). patch: malformed patch at line 102: @@ -966,25 +961,26 @@ Do you mean you deleted that line from the patch? That's probably what is causing the malformed patch error: the line numbers in the patch no longer add up. However, if you install the patchutils package, then you can run recountdiff to fix the lines up after you edit a diff, and it should then apply. patchutils is very very cool. -- Martin
Detecting true64
Does anyone know how to detect a truu64 system in configure.in ? I'm going through my patchlist and there is a big optimisation that can be done on systems where the getgrnam() call works (True64 is listed as the only broken system) and I'd like to add this to all branches by adding a BROKEN_GETGRNAM define for True64. Jeremy.
interesting fact about StrCaseCmp
StrCaseCmp (and strequal) in HEAD has the interesting side-effect that it only compares the first PSTRING_LEN (1024) bytes of the strings. I suppose comparing strings longer than that is probably a bit unlikely, but it still seems kind of dangerous. Would it be OK to change it to use dynamic allocation? -- Martin
Re: interesting fact about StrCaseCmp
On Tue, 2003-02-18 at 11:01, Martin Pool wrote: StrCaseCmp (and strequal) in HEAD has the interesting side-effect that it only compares the first PSTRING_LEN (1024) bytes of the strings. I suppose comparing strings longer than that is probably a bit unlikely, but it still seems kind of dangerous. Would it be OK to change it to use dynamic allocation? I think so. Possibly only for long strings? But then that is probably micro-optimization. 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 signature.asc Description: This is a digitally signed message part
Re: interesting fact about StrCaseCmp
On 18 Feb 2003, Andrew Bartlett [EMAIL PROTECTED] wrote:
Possibly only for long strings? But then that is probably
micro-optimization.
If we really cared about optimizing this function, then we would
compare character-by-character rather than converting both strings to
uppercase first. This is a bit hard for some wierd encodings I know,
but it ought to be possible to do it in charcnv.c.
The case where we compare, for example, a thousand-character string to
the empty string is ridiculously slow at the moment.
I don't know if this is a problem for Samba overall or not, so I'm not
touching it at the moment.
int StrCaseCmp(const char *s, const char *t)
{
pstring buf1, buf2;
unix_strupper(s, strlen(s)+1, buf1, sizeof(buf1));
unix_strupper(t, strlen(t)+1, buf2, sizeof(buf2));
return strcmp(buf1,buf2);
}
--
Martin
RE: bug fix?: 2.2.7a, nmbd/nmbd_packets.c, listen_for_packets()
On Mon, 2003-02-17 at 14:02, Peter Hurley wrote: When running a WINS server using the following configuration: [global] wins support = yes interfaces = 192.168.1.0/24 bind interfaces only = true the WINS server erroneously discards 127.0.0.1 requests from SMBD children. This happens whenever libsmb/resolve_wins() is called. I ran into this trying to understand why bringing up a Print dialog would take 6 secs, but I would guess that there are other places this would come up. I don't see how this is erroneous. If you specifically configure Samba not to listen on an interface, I might imagine that it might just happen to not listen on that interface. The documentation is quite clear on this matter - you really should include localhost in your interface list. I think there are several good reasons to include this fix: 1) I think the documentation is ambiguous on this subject. Then this is a very good argument for a doco patch. 2) interfaces= is an overloaded option. Setting the loopback address in interfaces= has both SMBD and NMBD listening to it. But in the default mode, SMBD will only listen to all broadcast addresses EXCEPT loopback, whereas NMBD will listen to every address. This is incorrect. SMBD listens on wildcard, while NMBD listens on each detected broadcast interface and on the wildcard. NMBD later discards packets if 'bind interfaces only' is set, as an attempted security measure. Given that we might be running a different nmbd on localhost, and that we don't always have a wins server running locally, I'm not sure that forcing localhost into the list is the best idea. 3) I've seen quite a few misconfigured interfaces=. I think this is probably a very common oversight that goes largely undetected. In my case, I was running this misconfiguration on one server for two years, and on another for 9 mos. It was only because I decided to seriously bulldog a seemlingly unrelated problem (long time to bring up Print dialog) that I uncovered the misconfiguration for myself. I think that some extra testparm logic would go a long way here. 4) I believe this to be the most serious. The only indication that something is wrong is that things run slow or sporadically slow. But slow-running stuff is hard to diagnose. It could be network hardware, server hardware, misconfigured network hardware, corrupted firewalls, complex multi-subnet installations, etc. The security-conscious (a lot of people) are going to and do use bind interfaces only = yes, without realizing all the ramifications. A lot of posts on the samba list are about complex problems that start: it's running slow. Remember the thread, How Samba let us down? Quite a furor: interestingly, Chris de Vidal states in his e-mail of 23 October 2002, 10:46:29, I did try WINS in testing; I would see WINS server appears to be down...Have you seen better documents on implementing Samba WINS... I think in this situation a small change could go a long way. It may do so, but we need to make sure it's also the 'correct' fix. We sill need a way to control the way nmbd binds to interfaces, and to allow multiple nmbd servers per physical machine. (People do multi-hosting like this). 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 signature.asc Description: This is a digitally signed message part
Re: Detecting true64
On Mon, 17 Feb 2003 [EMAIL PROTECTED] wrote: Does anyone know how to detect a truu64 system in configure.in ? I'm going through my patchlist and there is a big optimisation that can be done on systems where the getgrnam() call works (True64 is listed as the only broken system) and I'd like to add this to all branches by adding a BROKEN_GETGRNAM define for True64. You figure out whether or not the OS is confused about what it is: Tru64 (formerly known as Digital UNIX, formerly known as DEC OSF/1 ...) Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
Re: Detecting true64
On 17 Feb 2003, [EMAIL PROTECTED] wrote: Does anyone know how to detect a truu64 system in configure.in ? I'm going through my patchlist and there is a big optimisation that can be done on systems where the getgrnam() call works (True64 is listed as the only broken system) and I'd like to add this to all branches by adding a BROKEN_GETGRNAM define for True64. Note that it really is Tru64. I guess misspelling makes it more dynamic. config.guess should detect a hostname of something like alphaev7-dec-osf4.0f See e.g. http://studio.imagemagick.org/pipermail/magick-bugs/2002-November/000881.html configure.in should call AC_CANONICAL_HOST, and then examine $host_os, probably with something like case $host_os in osf*) ;; The config.guess is actually quite old compared to the current GNU distribution, so I might update that in HEAD and 3_0. This might improve correctness or robustness in detecting some platforms. -- Martin We use Film Gimp on all talking animal jobs -- Caroline Dahllöf
Re: Detecting true64
On Tue, 2003-02-18 at 10:08, [EMAIL PROTECTED] wrote: Does anyone know how to detect a truu64 system in configure.in ? I'm going through my patchlist and there is a big optimisation that can be done on systems where the getgrnam() call works (True64 is listed as the only broken system) and I'd like to add this to all branches by adding a BROKEN_GETGRNAM define for True64. Yikes - I didn't really look at that code before - it's horrid! That must really cost on winbind-appliance systems. For the record, this call is not made any more since my @group expansion patch for 'boring' logins, but some 'force group' variants, 'security=share' setups and the SAMR 'add/delete user from group' we still need to call it. 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 signature.asc Description: This is a digitally signed message part
Doxygen janitor?
Is there any kind of consensus (he says, hopefully) that Doxygen is a good idea? If I'm looking at code is it OK to cleanup comments into standard form? -- Martin
Re: Doxygen janitor?
On Tue, 2003-02-18 at 10:50, Martin Pool wrote: Is there any kind of consensus (he says, hopefully) that Doxygen is a good idea? If I'm looking at code is it OK to cleanup comments into standard form? Go for it! 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 signature.asc Description: This is a digitally signed message part
Re: Doxygen janitor?
On Tue, 18 Feb 2003, Martin Pool wrote: Is there any kind of consensus (he says, hopefully) that Doxygen is a good idea? If I'm looking at code is it OK to cleanup comments into standard form? Yes, please do ... Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
Re: interesting fact about StrCaseCmp
On Tue, 18 Feb 2003 11:35:32 +1100
Martin Pool [EMAIL PROTECTED] wrote:
On 18 Feb 2003, Andrew Bartlett [EMAIL PROTECTED] wrote:
Possibly only for long strings? But then that is probably
micro-optimization.
If we really cared about optimizing this function, then we would
compare character-by-character rather than converting both strings to
uppercase first. This is a bit hard for some wierd encodings I know,
but it ought to be possible to do it in charcnv.c.
Actually you got me thinking and it's not all that hard. In fact I think
there are a lot of good optamizations you can make in this function. For
example you only have to convert to wide characters if *both* characters
are multibyte sequences. If only one has the high bit on they cannot
possibly match even caseless so *str1 != *str2 clause will return.
Here's some rough code. I didn't even try to compile this.
int
utf8casecmp(const char *str1, size_t sn1, const char *str2, size_t sn2)
{
size_t n1, n2;
wchar_t ucs1, ucs2;
mbstate_t ps1, ps2;
unsigned char uc1, uc2;
memset(ps1, 0, sizeof(ps1));
memset(ps2, 0, sizeof(ps2));
while (sn1 0 sn2 0) {
if ((*str1 0x80) (*str2 0x80)) { /* both multibyte */
if ((n1 = mbrtowc(ucs1, str1, sn, ps1)) 0 ||
(n2 = mbrtowc(ucs2, str2, sn, ps2)) 0) {
perror(mbrtowc);
return -1;
}
if (ucs1 != ucs2
(ucs1 = towupper(ucs1)) != (ucs2 = towupper(ucs2))) {
return ucs1 ucs2 ? -1 : 1;
}
sn1 -= n1; str1 += n1;
sn2 -= n2; str2 += n2;
} else { /* neither or one multibyte */
uc1 = toupper(*str1);
uc2 = toupper(*str2);
if (uc1 != uc2) {
return uc1 uc2 ? -1 : 1;
} else if (uc1 == '\0') {
return 0;
}
sn1--; str1++;
sn2--; str2++;
}
}
return 0;
}
Note this assumes you're running in a UTF-8 locale. I don't know how
you handle locales. Otherwise you'll need to switch out the mbrtowc
functions. But I think the algorithm is sound.
Mike
--
A program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes the potential for it to be applied to tasks that are
conceptually similar and, more important, to tasks that have not
yet been conceived.
Re: interesting fact about StrCaseCmp
On Tue, Feb 18, 2003 at 11:01:53AM +1100, Martin Pool wrote: StrCaseCmp (and strequal) in HEAD has the interesting side-effect that it only compares the first PSTRING_LEN (1024) bytes of the strings. I suppose comparing strings longer than that is probably a bit unlikely, but it still seems kind of dangerous. Would it be OK to change it to use dynamic allocation? What exactly do you want to do here ? I'm not clear what you mean ? Jeremy.
Re: interesting fact about StrCaseCmp
On 18 Feb 2003, [EMAIL PROTECTED] wrote: What exactly do you want to do here ? I'm not clear what you mean? The thing I noticed is that StrCaseCmp (and indeed many charcnv function) truncate strings to 1024 characters. I got here following a Valgrind assertion which may or may not be related, but it certainly seems like a bug. What I was proposing in the first instance was to use talloced or malloced buffers rather than a fixed 1024 byte space. There are already some charcnv routines that do this and in any case it is straightforward to do it for other cases using the standard measure-allocate-copy method. Andrew expressed concern that allocating buffers would be inefficient, but these functions are already extremely inefficient so I don't think an extra malloc would matter. In fact, it's worse, because unix_strupper (for example) uses a 1024-*byte* buffer to hold a UCS2 string. I don't think it will overflow, but it will truncate any strings that pass through down to 512 characters. It's not so hard to imagine a 512-character string. Basically I just wanted to push on with moving away from pstrings/fstrings, which I understood from Andrew Tim to be the current direction. -- Martin
Re: interesting fact about StrCaseCmp
On Tue, Feb 18, 2003 at 03:23:40PM +1100, Martin Pool wrote: On 18 Feb 2003, [EMAIL PROTECTED] wrote: What exactly do you want to do here ? I'm not clear what you mean? The thing I noticed is that StrCaseCmp (and indeed many charcnv function) truncate strings to 1024 characters. I got here following a Valgrind assertion which may or may not be related, but it certainly seems like a bug. What I was proposing in the first instance was to use talloced or malloced buffers rather than a fixed 1024 byte space. There are already some charcnv routines that do this and in any case it is straightforward to do it for other cases using the standard measure-allocate-copy method. You're not talking about allocating them for every call are you ? We call these functions a lot. Jeremy.
Re: ideas for optimizations with large groups
On Wed, Mar 06, 2002 at 11:24:23AM +, Chris Wakelin wrote:
We had big problems with an upgrade to Samba 2.2.3a on Solaris 8 due
to this groups change. Samba 2.2.2 was fine, but had occassional
oplock problems (hence the desire to upgrade). We have a large number
(~1000) of (sometimes large) NIS groups.
I've patched our version of Samba 2.2.3a in lib/util_getent.c
get_users_in_group() commenting out the line :-
if (strchr(gname,*lp_winbind_separator())) {
(and the lines following the if statement) so that the old
getgrnam() calls are used instead (as they are for winbindd).
This fixes the problem for us, but I'd like strongly to support
David's suggestion that the change to using getgrent() be made a
compile-time option for Tru64 only.
It took some time, but I finally got to this, sorry :-).
Jeremy.
