Re: [Samba] [Pkg-samba-maint] winbind with samba 3.5.6 on debian squeeze
On Sun, Aug 21, 2011 at 01:21:45PM +0200, Harry Jede wrote: I have a bug in the winbind package, Version: 2:3.5.6~dfsg-3squeeze4 winbindd is not responding to a ping # smbcontrol winbindd ping Can't find pid for destination 'winbindd' Workaround for users who wish to play the winbind game on squeeze: # cd /var/run/samba # ls *pid nmbd.pid smbd.pid winbindd-winbindd.conf.pid There is no winbindd.pid :-( , but a winbindd-winbindd.conf.pid To workaround this bug, until the package is fixed, edit /etc/init.d/winbind and put these three lines in start) just after start-stop-daemon ... cd $PIDDIR ln -s winbindd-winbindd.conf.pid winbindd.pid cd - restart winbind and all is fine # smbcontrol winbindd ping PONG from pid 5363 This problem is not reproducible for me. Are you passing any non-standard options to winbindd in $WINBINDD_OPTS (/etc/default/winbind)? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] ANNOUNCE: cifs-utils release 4.1 available for download
Hi Jeff, On Tue, Mar 23, 2010 at 10:10:44AM -0400, Jeff Layton wrote: This release is primarily a number of small bugfixes and cleanups. I wanted to do a release with those prior to the coming overhaul of mount.cifs to allow it to more safely be installed setuid root. Could you please provide detached GPG signatures for cifs-utils on the download site, so we have some cryptographic assurance of the integrity of the tarballs as we do for the samba tarballs? Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Samba 3.4 Panic in Debian
On Tue, Jan 26, 2010 at 01:29:08PM -0500, Sam Hartman wrote: OK. Can someone on the Samba side confirm that the Linux kernel only supports DES for some Samba related Kerberos operation? Specific details on what is going on would be useful. The kernel is only involved when one is using CIFS mounts, which aren't relevant to winbind and domain joining; so this shouldn't be a kernel issue. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Samba 3.4 Panic in Debian
On Tue, Jan 26, 2010 at 05:03:51PM -0500, Sam Hartman wrote: Steve == Steve Langasek vor...@debian.org writes: Steve On Tue, Jan 26, 2010 at 01:29:08PM -0500, Sam Hartman wrote: OK. Can someone on the Samba side confirm that the Linux kernel only supports DES for some Samba related Kerberos operation? Specific details on what is going on would be useful. Steve The kernel is only involved when one is using CIFS mounts, Steve which aren't relevant to winbind and domain joining; so this Steve shouldn't be a kernel issue. OK. Then I currently have no idea why allow_weak_crypto would be desirable for Samba. In the case of AD realms that were continuously upgraded from NT4 domains, you may have accounts only using RC4 as an enctype for backwards-compatibility with pre-AD systems. I don't know if this is the reason these users are seeing problems, but it's the only case I can think of why allow_weak_crypto should be needed. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Samba 3.4 Panic in Debian
On Tue, Jan 26, 2010 at 02:22:36PM -0800, Steve Langasek wrote: On Tue, Jan 26, 2010 at 05:03:51PM -0500, Sam Hartman wrote: Steve == Steve Langasek vor...@debian.org writes: Steve On Tue, Jan 26, 2010 at 01:29:08PM -0500, Sam Hartman wrote: OK. Can someone on the Samba side confirm that the Linux kernel only supports DES for some Samba related Kerberos operation? Specific details on what is going on would be useful. Steve The kernel is only involved when one is using CIFS mounts, Steve which aren't relevant to winbind and domain joining; so this Steve shouldn't be a kernel issue. OK. Then I currently have no idea why allow_weak_crypto would be desirable for Samba. In the case of AD realms that were continuously upgraded from NT4 domains, you may have accounts only using RC4 as an enctype for backwards-compatibility with pre-AD systems. I don't know if this is the reason these users are seeing problems, but it's the only case I can think of why allow_weak_crypto should be needed. Sorry, having looked at the source now, I see that the weak crypto handling is specific to DES, not RC4; and if Samba were *only* using RC4, this error would not happen. However, Samba requests both RC4 and DES, a historical remnant of the time when DES was the only enctype in common between all Kerberos implementations. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Samba 3.4 Panic in Debian
On Wed, Jan 27, 2010 at 05:13:37PM +0100, Volker Lendecke wrote: OK. Then I currently have no idea why allow_weak_crypto would be desirable for Samba. In the case of AD realms that were continuously upgraded from NT4 domains, you may have accounts only using RC4 as an enctype for backwards-compatibility with pre-AD systems. I don't know if this is the reason these users are seeing problems, but it's the only case I can think of why allow_weak_crypto should be needed. Sorry, having looked at the source now, I see that the weak crypto handling is specific to DES, not RC4; and if Samba were *only* using RC4, this error would not happen. However, Samba requests both RC4 and DES, a historical remnant of the time when DES was the only enctype in common between all Kerberos implementations. Referring to the SUBJECT: Where is this leading to a panic in Samba 3.4, I got lost in the meantime. I'm afraid I don't know. I was cc:ed on this somewhat mid-thread, and haven't seen any panics; what I know about is http://bugs.debian.org/566977, which reports that after upgrade to MIT Kerberos 1.8alpha1, samba domain joins are failing because of the need for allow_weak_crypto to be set before setting DES tgs enctypes is permitted. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Re: cifs verses smbfs for Linux clients
On Tue, Feb 19, 2008 at 08:58:54PM +0100, Volker Lendecke wrote: On Tue, Feb 19, 2008 at 08:22:56PM +0100, Christian Perrier wrote: At least considering to distribute it (or a derived work) as part of the samba distribution could help samba users to switch from smbfs to cifs? Sorry, we can't. Looks nice, but is GPLv2 only. Is this a problem practically, or is it a matter of the Samba Team's licensing policy? As this is a stand-alone shell script, I wouldn't expect there to be any license compatibility issues; but if it's a requirement that even shell scripts be GPLv3 to ship with Samba, I'll concede GPLv2 or greater. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
[Samba] Re: Bug#219197: PANIC: internal error
Mike, On Wed, Jan 21, 2004 at 11:29:33AM -0800, Mike Fedyk wrote: On Wed, Jan 21, 2004 at 11:10:40AM -0800, Mike Fedyk wrote: I'm still looking through my logs to see if there are any new traces there. All clients are win2k, except for scitex which is win98. And here are some more: Based on your other message indicating that you're essentially seeing segfaults in main() in the smbd process, something I've never seen, I'm more than a little concerned about the accuracy of these backtraces. Are you using stock libc on this system? What version of gcc did you use when recompiling samba for debugging symbols? Did you use the Debian packages as a base for this build, or did you use the upstream tarball -- and if the latter, what options did you pass to ./configure? The backtraces you've included below do NOT suggest that the binaries have intact debugging symbols, as several of the functions on the stack have no names associated with them. Do you get different results from gdb (using the default Debian 'panic action' script)? Cheers, -- Steve Langasek postmodern programmer comp.team-c-jhernand-[2004/01/20 16:15:29, 0] lib/util.c:smb_panic(1408) comp.team-c-jhernand: BACKTRACE: 11 stack frames: comp.team-c-jhernand- #0 /usr/sbin/smbd(smb_panic+0x101) [0x81bdcb1] comp.team-c-jhernand- #1 /usr/sbin/smbd [0x81ac097] comp.team-c-jhernand- #2 [0xe420] comp.team-c-jhernand- #3 /usr/sbin/smbd [0x808ac2a] comp.team-c-jhernand- #4 /usr/sbin/smbd(reply_trans+0x53e) [0x808b62e] comp.team-c-jhernand- #5 /usr/sbin/smbd [0x80c7dca] comp.team-c-jhernand- #6 /usr/sbin/smbd [0x80c8030] comp.team-c-jhernand- #7 /usr/sbin/smbd(process_smb+0x8c) [0x80c823c] comp.team-c-jhernand- #8 /usr/sbin/smbd(smbd_process+0x168) [0x80c8eb8] comp.team-c-jhernand- #9 /usr/sbin/smbd(main+0x4bc) [0x8228d4c] comp.team-c-jhernand- #10 /lib/tls/libc.so.6(__libc_start_main+0x108) [0x401c5798] comp.team-d-horacio-[2004/01/16 15:05:45, 0] lib/util.c:smb_panic(1408) comp.team-d-horacio: BACKTRACE: 20 stack frames: comp.team-d-horacio- #0 /usr/sbin/smbd(smb_panic+0x101) [0x81bdc41] comp.team-d-horacio- #1 /usr/sbin/smbd [0x81ac027] comp.team-d-horacio- #2 /lib/libc.so.6 [0x401da498] comp.team-d-horacio- #3 /lib/libc.so.6(malloc+0x93) [0x40221d33] comp.team-d-horacio- #4 /usr/sbin/smbd(talloc+0x4a) [0x81c2b6a] comp.team-d-horacio- #5 /usr/sbin/smbd(talloc_memdup+0x1e) [0x81c2dae] comp.team-d-horacio- #6 /usr/sbin/smbd(talloc_strdup+0x2e) [0x81c2e0e] comp.team-d-horacio- #7 /usr/sbin/smbd(strftime+0x1ba5) [0x8077d91] comp.team-d-horacio- #8 /usr/sbin/smbd(mangle_map_filename+0x17) [0x80cef27] comp.team-d-horacio- #9 /usr/sbin/smbd(mangle_map+0x6c) [0x80cd8dc] comp.team-d-horacio- #10 /usr/sbin/smbd [0x80ab074] comp.team-d-horacio- #11 /usr/sbin/smbd [0x80ac9cb] comp.team-d-horacio- #12 /usr/sbin/smbd(reply_trans2+0x684) [0x80b4344] comp.team-d-horacio- #13 /usr/sbin/smbd [0x80c7dca] comp.team-d-horacio- #14 /usr/sbin/smbd [0x80c8030] comp.team-d-horacio- #15 /usr/sbin/smbd(process_smb+0x8c) [0x80c823c] comp.team-d-horacio- #16 /usr/sbin/smbd(smbd_process+0x168) [0x80c8eb8] comp.team-d-horacio- #17 /usr/sbin/smbd(main+0x4bc) [0x8228cdc] comp.team-d-horacio- #18 /lib/libc.so.6(__libc_start_main+0xc6) [0x401c6da6] comp.team-d-horacio- #19 /usr/sbin/smbd(chroot+0x35) [0x8077121] pgp0.pgp Description: PGP signature -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
Re: A please report me error
On Tue, Mar 25, 2003 at 03:46:27PM -0500, Dave Collier-Brown wrote: In today's CVS, I caught this message zip by while configuring: ... checking net/if.h presence... yes configure: WARNING: net/if.h: present but cannot be compiled configure: WARNING: net/if.h: check for missing prerequisite headers? configure: WARNING: net/if.h: proceeding with the preprocessor's result configure: WARNING: ## ## configure: WARNING: ## Report this to [EMAIL PROTECTED] ## configure: WARNING: ## ## checking for net/if.h... yes Anyone want to pass it on the gnuvians, as asked? Given that the configure script is no longer stored in CVS, this may be a problem specific to the version of autoconf that you have installed on your system. Have you checked if there's a more recent version available than what you're running? -- Steve Langasek postmodern programmer pgp0.pgp Description: PGP signature
Re: Browsing across subnets without WINS
On Wed, Mar 19, 2003 at 09:30:18AM -0500, Alex @ Avantel wrote: It's my understanding that this problem has been solved with the MS approach to browsing the WAN - what is the limitation in samba that prevents that from working? AFAIK it's either the limitation of the samba LMB/DMB or name resolution (WINS) - or is it somehting else? If all of your DMBs are Samba-based, then you can use Samba's 'enhanced browsing' and 'remote browse sync' options to improve things. Read up on these options in the smb.conf documentation. No need to - been there, done that, it works. The limitation is still the same - IF there is only one samba server on a subnet, THEN there can only be one workgroup on the subnet or browsing will break accross the WAN. If you use a MS server, that's not the case. Or am I wrong on that too? I think this is wishful thinking on your part. I've never seen any signs that MS servers get this right. -- Steve Langasek postmodern programmer pgp0.pgp Description: PGP signature
Re: Browsing across subnets without WINS
On Wed, Mar 19, 2003 at 11:07:08AM -0600, Christopher R. Hertel wrote: On Wed, Mar 19, 2003 at 10:06:39AM -0600, Steve Langasek wrote: On Wed, Mar 19, 2003 at 09:30:18AM -0500, Alex @ Avantel wrote: : No need to - been there, done that, it works. The limitation is still the same - IF there is only one samba server on a subnet, THEN there can only be one workgroup on the subnet or browsing will break accross the WAN. Huh!? No, you can have multiple workgroups on the subnet. The LMBs on the subnet should exchange browse lists for their workgroups. That's how the browse lists get merged. The LMBs then upload the combined lists to their respective DMBs. I would believe that there *could* be bugs in the browse list merger, but I would need to see packet traces to believe it is real--and then I'd still need to study those traces to find out whose bug it really is. I have seen odd behavior from Windows (eg. some versions of Windows get the announcement period wrong in the HostAnnounce messages...things like that). The point is, though, that to have multiple workgroups you need to have multiple LMBs. The problem comes from using Win9x as an LMB, since Win9x does NOT do its job of exchanging browse lists with the DMB. You do also need to have some 'exchange point' -- a subnet with representatives (functional LMBs) of the various workgroups. Without that, the MS browsing protocols give no way to find out who's in those other workgroups. So indeed, if you have a configuration where each remote site represents a workgroup, or the only shared subnets are running stupid Win9x machines, it becomes difficult to move between the workgroups without investing in some hardware for a number of LMBs at one of the sites. This can be done with a single Unix machine, though, running multiple discrete copies of nmbd on different IPs -- I haven't seen anyone do *that* with Windows yet. :) -- Steve Langasek postmodern programmer pgp0.pgp Description: PGP signature
Re: Compilation problem : Samba 2.2.8 ACL on Debian Woody
Sebastien, On Tue, Mar 18, 2003 at 05:23:14PM +0100, Sebastien Munch wrote: Samba 2.2.8 with ACL support on Debian Woody won't compile, and I haven't found why. Searched for hours, asked on #samba-technical (freenode), but no solution... Have you tried Christian Perrier's ACL-enabled packages at http://www.perrier.eu.org/debian ? -- Steve Langasek postmodern programmer pgp0.pgp Description: PGP signature
Re: Problem with preexec ?
On Fri, Mar 07, 2003 at 02:10:14PM +0100, Lars O. Grobe wrote: [profiles] path = \\%L\%H\profile.%m Once there have been problems if profiles were stored in home directories, there were issues with connections being kept open. Is this still the case with current Samba version, or has there been a solution I didn't hear about? That problem affects the 'logon path' global option. The 'path' option on a share must *always* be a Unix path. -- Steve Langasek postmodern programmer pgp0.pgp Description: PGP signature
Re: Help with spoolss printing
On Tue, Mar 04, 2003 at 03:46:17PM +, Mike Brodbelt wrote: Mike Brodbelt wrote: Gerald (Jerry) Carter wrote: Please retest against 2.2.8pre2. OK - I'll need to build my own packages, which I was hoping to avoid, so testing against the new version will probably take me a day or so. Having tried this, 2.2.8 doesn't compile for me. Found the files in packaging/Debian (very nice, make this *lots* easier), but no go:- Compiling lib/util.c lib/util.c: In function `state_path': lib/util.c:1876: `STATEDIR' undeclared (first use in this function) lib/util.c:1876: (Each undeclared identifier is reported only once lib/util.c:1876: for each function it appears in.) lib/util.c: In function `cache_path': lib/util.c:1896: `CACHEDIR' undeclared (first use in this function) make[1]: *** [lib/util.o] Error 1 make[1]: Leaving directory `/usr/local/local_pkg/samba/samba-2.2.8pre2/source' make: *** [build-stamp] Error 2 As you deduced, this means the Debian-specific patches don't apply cleanly against 2.2.8pre2. Have you tried the backported 2.2.7a packages available at http://people.debian.org/~peloy/samba/? Jerry, have there been more printing fixes since then that he'll need in order to get this working? -- Steve Langasek postmodern programmer pgp0.pgp Description: PGP signature
Re: samba + w2k + kerberos + trusted realm
On Sun, Mar 02, 2003 at 01:44:22AM +0100, Love wrote: - Using a keytab file would solve the problem below. Using /etc/krb5.keytab is bad idea, how about a own keytab for samba ? Doing hoops of strace stuff seems, well, strange. Why is using /etc/krb5.keytab a bad idea? The only reason I've ever seen for using separate keytabs is if you want different services to run in separate security contexts. Samba has to run as root, so /etc/krb5.keytab seems appropriate to me (as much as any keytab is appropriate -- there seem to still be some issues with using the keytab at all). What is it that limit samba to root ? When I use samba with afs beeing root will certenly not help samba access files, what else do samba need. While you wouldn't need to be root to gain access to a user's AFS-based files, uid-based access control is at the core of Samba's current implementation. Using an alternative keytab is only a benefit if this changes. This is not what I free is the important part of my mail. And the only reason why I did the comment was that the comment in the samba code that did hoops to store the key in the auth context instead of just using a keytab. Well, it's the part I felt I could comment on, since I don't know the Samba Kerberos code all that well. :) It is my understanding that the key is being stored in the secrets file instead of in a keytab because Samba also needs to have the plaintext password for salting, so until this is addressed, storing the keys in a keytab would only serve to confuse admins familiar with traditional Unix keytab handling. Or has this been addressed when I wasn't looking? -- Steve Langasek postmodern programmer pgp0.pgp Description: PGP signature
[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
Re: REPOST: Meaning of tdb_free: left read failed at ...?
On Tue, Feb 04, 2003 at 10:17:34AM +0100, Ralf G. R. Bergs wrote: On Sun, 02 Feb 2003 15:44:18 +0100, Simo Sorce wrote: The system in question is a Debian i386 stable (3.0) system, kernel is 2.4.20 release (with some patches such as EVMS and XFS, but EVMS is NOT in use for shares exported via Samba!!), Samba is 2.2.7a (a Debian package that I created myself.) I would try again with a standard ext2/3 file system. Ok, now /var/run/samba is an ext3 filesystem -- and the problem is back again. :-( So you could argue, Ok, it's EVMS then which is the culprit, because filesystem is on an EVMS logical volume. But I simply cannot believe this. Why should Samba be the ONLY (apparent) application that doesn't feel happy with XFS over EVMS? I'm running Samba on XFS+EVMS (on Debian ;) with no problems. Even on buggy versions of XFS, I've never seen this error; I don't think the filesystem is the cause. OTOH, I haven't used 2.4.20 yet for this environment. When you say you compiled with large file support, does that mean you made changes to the build scripts? Samba should already build with LFS support on Linux 2.4. -- Steve Langasek postmodern programmer msg05769/pgp0.pgp Description: PGP signature
Re: [Samba] Re: Workstation Trust Accounts
On Fri, Jan 24, 2003 at 05:51:49PM +0100, Nicki Messerschmidt, Linksystem Muenchen GmbH wrote: Steve Langasek wrote: Let me guess. If I do it this way samba acts as a pdc but the clients do not try to update their accounts? Are there any drawbacks using this technique? That makes them act as BDCs instead of all trying to be a PDC. Trying to deploy multiple PDCs in an NT4 domain and syncing between them will introduce nasty race conditions that should be avoided. But we don't have multiple PDCs in _one_ domain. We have five PDCs in _five_ domains plus one master server which acts as administrative Server where all Useraccounts are entered but which has no samba running. Does it still work then, if I let the now PDCs be BDCs? Then I don't understand what problem you're having. What isn't working in this scenario? Are you trying to synchronize the machine accounts between the domains? (If you're doing that, *why* do you have separate domains?) -- Steve Langasek postmodern programmer msg12917/pgp0.pgp Description: PGP signature
Re: [Samba] Re: Workstation Trust Accounts
On Thu, Jan 23, 2003 at 04:45:08PM +0100, Nicki Messerschmidt, Linksystem Muenchen GmbH wrote: Steve Langasek wrote: I have a really ugly problem, which, as I know is partially selfmade. But to the problem: I have five servers running samba-2.2.3a-12 (latest Debian Woody release) which are controlled by one master server. All of the five servers act as pdc for an own nt-domain. Now to keep the administrative work as low as possible I have this one master server. Via this server we/our customer adds/deletes all user accounts. This works as expected and cvs is my friend here. The users can change their passwords via nt, because the scripts for passwd program manage this part. Set 'domain master = no', but 'domain logons = yes', on all of the PDCs except the master. In an NT4-style domain, it's really not feasible to have more than one *primary* domain controller. Let me guess. If I do it this way samba acts as a pdc but the clients do not try to update their accounts? Are there any drawbacks using this technique? That makes them act as BDCs instead of all trying to be a PDC. Trying to deploy multiple PDCs in an NT4 domain and syncing between them will introduce nasty race conditions that should be avoided. -- Steve Langasek postmodern programmer msg12855/pgp0.pgp Description: PGP signature
[Samba] Re: Workstation Trust Accounts
On Thu, Jan 23, 2003 at 03:46:26PM +0100, Nicki Messerschmidt, Linksystem Muenchen GmbH wrote: Hi there, I have a really ugly problem, which, as I know is partially selfmade. But to the problem: I have five servers running samba-2.2.3a-12 (latest Debian Woody release) which are controlled by one master server. All of the five servers act as pdc for an own nt-domain. Now to keep the administrative work as low as possible I have this one master server. Via this server we/our customer adds/deletes all user accounts. This works as expected and cvs is my friend here. The users can change their passwords via nt, because the scripts for passwd program manage this part. Set 'domain master = no', but 'domain logons = yes', on all of the PDCs except the master. In an NT4-style domain, it's really not feasible to have more than one *primary* domain controller. -- Steve Langasek postmodern programmer msg12963/pgp0.pgp Description: PGP signature
Re: changes to passdb backend defaults in 3.0 alpha21
On Mon, Jan 20, 2003 at 12:04:24PM -0600, Gerald (Jerry) Carter wrote: The following code appears in source/params/loadparm.c from 3.0alpha21: #ifdef WITH_LDAP_SAMCONFIG string_set(Globals.szLdapServer, localhost); Globals.ldap_port = 636; Globals.szPassdbBackend = str_list_make(ldapsam unixsam, NULL); #else Globals.szPassdbBackend = str_list_make(smbpasswd unixsam, NULL); #endif /* WITH_LDAP_SAMCONFIG */ Would it be possible to revert this change with respect to the 'passdb backend' default? This is a very awkward default for packagers who wish to enable LDAP support in their binaries, but still need to serve the needs of users who are not (yet) using LDAP. I just checked and this is still in SAMBA_3_0. You really don't need to get LDAP support. It's for a the 2.2 compatible parameters. The intent is to work like Samba 2.2 in the sense that with you enable LDAP support, that what you get. Or am I missing the gist of your question. Yes, sorry, this was clarified for me on IRC after I posted. I misunderstood the --with-ldapsam option to mean enable the LDAP backend, not enable 2.2 ldap compat. The consensus on IRC, as I understood it, was that it would be beneficial to have another option to configure that would enforce the LDAP dependency -- so that a failure to locate LDAP libs would cause the build to error out instead of giving misbuilt binaries. Do you agree? -- Steve Langasek postmodern programmer msg05440/pgp0.pgp Description: PGP signature
Re: More Kerberos-related questions
On Thu, Jan 09, 2003 at 09:03:03AM +1100, Andrew Bartlett wrote: I'm not sure why you would want to do this however, when you could just mount the DFS stuff onto Linux (I assume there is a client...). A quick web search shows me that there are DFS clients available for Linux; but perhaps there's a licensing issue? -- Steve Langasek postmodern programmer msg05272/pgp0.pgp Description: PGP signature
smbclient -M sends NetBIOS session service header to port 445
If Samba is configured to try port 445 first, the 'smbclient -M' command can't send messages to Win2K machines: $ smbclient -M server -p 445 added interface ip=192.168.8.5 bcast=192.168.8.255 nmask=255.255.255.0 Got a positive name query response from 192.168.8.10 ( 192.168.8.10 ) read_socket_with_timeout: timeout read. read error = Connection reset by peer. message start: Read error: Connection reset by peer Ethereal shows that the packets sent by Samba include a 'Netbios Session Service' header. Is this the cause of the failure, or is the Windows messaging service inextricably bound to NetBIOS? In the former case, where would I look in the code to remove the NetBIOS header from the packet? -- Steve Langasek postmodern programmer msg05212/pgp0.pgp Description: PGP signature
Re: smbclient -M sends NetBIOS session service header to port 445
On Mon, Jan 06, 2003 at 11:08:32AM -0600, Christopher R. Hertel wrote: So, smbclient should default to using port 139 for the NetServerEnum2 calls (-L option) unless -p is actually specified. Basically, the same problem as -M. Ok, that was the same conclusion I arrived at. I'll put together a patch to make 'smbclient -M' force a connection to port 139. In your example, though, you specify both -M and -p. Personally, I think that in this case smbclient is doing the right thing. If I enter 'smbclient -M server -p 10973', then I would expect smbclient to try sending the message to that port. The defaults should be 'best normal behavior' but smbclient is much more useful if I can bend it to my will. Well, the -p option was added only for the purpose of being explicit. In 3.0, port 445 is currently the default port for *all* operations, including smbclient -M. So the code does need to change if -M needs port 139. -- Steve Langasek postmodern programmer msg05220/pgp0.pgp Description: PGP signature
Re: smbclient -M sends NetBIOS session service header to port 445
On Mon, Jan 06, 2003 at 11:51:24AM -0600, Christopher R. Hertel wrote:
That would be great. Please also look at the -L option too, as that
should default to 139 as well. (Sort of... it's not necessary for listing
shares.)
Ok. I'll add that to my queue behind getting libsmbclient to use the RPC
call for share enumeration instead of the RAP call. :)
The -p option should override the defaults in any case, though. There are
folks who use port-redirection (for SSH links to the server, etc.).
They'd want -p to be authoritative, rather than just explicit. :)
Done. See attached.
--
Steve Langasek
postmodern programmer
diff -ur samba-3.0alpha21.orig/source/client/client.c
samba-3.0alpha21/source/client/client.c
--- samba-3.0alpha21.orig/source/client/client.c2002-11-26 20:54:18.0
-0600
+++ samba-3.0alpha21/source/client/client.c 2003-01-06 14:08:54.0 -0600
@@ -2995,6 +2995,12 @@
}
}
+ /* If -M is specified and -p is not, make sure we use port 139
+ instead of port 445. srl */
+ if (message port == 0) {
+ port = 139;
+ }
+
init_names();
if(*new_name_resolve_order)
Re: Samba and Kerberos
On Fri, Jan 03, 2003 at 10:05:40AM -0600, Kenneth Stephen wrote: On Thu, 2 Jan 2003, Steve Langasek wrote: On Thu, Jan 02, 2003 at 06:28:48PM -0600, Kenneth Stephen wrote: ADS-style Kerberos support only works when both client and server are Kerberos-aware, so such Kerberos encrypted passwords support would be limited to Win2K and WinXP clients. This is a question of technical feasibility, not of implementation. I missed asking about this point before : why is it a question of technical feasibility? If the Samba team has reverse-engineered (or engineered) a solution to a Win KDC and Win client using Kerberos, why couldnt the same principles be applied to making it work with a non-MS KDC? It can be made to work with a non-MS KDC (with effort), but it can't be made to work with SMB clients which are not Kerberos-enabled. As long as you're only expecting this to work with WinXP and Win2K clients, it's possible. Older versions of Windows can't be made to send Kerberos tickets as their authentication information, so with such clients you have to choose between plaintext auth and the older, non-Kerberized encrypted password auth. Windows *clients* don't need the extra data; it's only Windows *servers* that need the data -- however, note that I'm using server in the sense of anything that provides a service, which would include a workstation providing login services for members of your Kerberos realm. If your Samba server doesn't need to provide domain auth services for workstation logins, you don't need to worry about the Microsoft PAC. AFAIK, Samba-as-a-fileserver doesn't even *support* using the PAC yet; it gets its group information from other, more Unix-y sources. So - if I login to a WinNT/2000 machine with a local id, and map a share with a (Kerberos) userid and password with Samba authenticating against a non-MS KDC, it should work - correct? Yes. The best way to achieve this on a large scale is probably to set up an Active Directory realm for your workstations, create a trust relationship between that realm and your non-MS Kerberos realm, and let Samba map the Active Directory principals to local uids. As for running Samba on a server that understands Kerberos authentication, even that is not required; you can easily run Samba as your only Kerberos-enabled application on a given machine (well, easily assuming you know how to go about setting up Kerberos). I'm not worried about the Kerberos side. I'm not proficient with that, but I can get help for Kerberos configuration. But I dont understand your comment : even that is not required. What is the that you are referring to? It is not required for the server to understand Kerberos authentication -- only Samba itself needs to understand Kerberos. PS. What exactly is a postmodern programmer? One who rejects established, absolutist schools of thought about programming. :) -- Steve Langasek postmodern programmer msg05191/pgp0.pgp Description: PGP signature
Re: smbpasswd and euid detection
On Thu, Jan 02, 2003 at 10:47:32AM -0700, Craig Kelley wrote: For some time now, I've been patching smbpasswd to get rid of the effective UID detection that it does. In 2.2.7a it simply tests if the effective UID differs from the real UID, and if the effective UID is 'root' then it bails: /* Check the effective uid - make sure we are not setuid */ if ((geteuid() == (uid_t)0) (getuid() != (uid_t)0)) This test will bail out if smbpasswd isn't suid 0, but the process that calls it is (eg, a utility agent for changing passwords and such). I've made a preliminary diff to actually stat() the executable to determine if it is suid 0: Why does your suid application not either assume full root privileges, or drop all such privileges, before exec()ing smbpasswd? -- Steve Langasek postmodern programmer msg05154/pgp0.pgp Description: PGP signature
Re: smbpasswd and euid detection
On Thu, Jan 02, 2003 at 01:27:01PM -0700, Craig Kelley wrote: On Thu, 2 Jan 2003, Steve Langasek wrote: On Thu, Jan 02, 2003 at 10:47:32AM -0700, Craig Kelley wrote: For some time now, I've been patching smbpasswd to get rid of the effective UID detection that it does. In 2.2.7a it simply tests if the effective UID differs from the real UID, and if the effective UID is 'root' then it bails: /* Check the effective uid - make sure we are not setuid */ if ((geteuid() == (uid_t)0) (getuid() != (uid_t)0)) This test will bail out if smbpasswd isn't suid 0, but the process that calls it is (eg, a utility agent for changing passwords and such). I've made a preliminary diff to actually stat() the executable to determine if it is suid 0: Why does your suid application not either assume full root privileges, or drop all such privileges, before exec()ing smbpasswd? I've considered that, but thought of it more as treating the symptom instead of the cause. A better question may be, why even check for suid? Why should smbpasswd even care if it's running with effective privileges? The naive may confuse it with the UNIX passwd program, which is suid root on some systems, but those with that much knowledge surely understand the ramifications of giving superuser privileges to an executable. I consider confusing smbpasswd with the Unix passwd command a sign that one doesn't really have that much knowledge, at least where smbpasswd itself is concerned. It's easy to jump to the conclusion that smbpasswd needs root privs to make changes to the smbpasswd file -- it does not -- and the program has *not* been audited for use as an suid program, so it's dangerous to treat it the same as passwd. So if someone can run smbpasswd indirectly from an suid wrapper, there's still a high potential for security problems, the same as if smbpasswd is suid itself. If you need to let users call smbpasswd in an suid root context, your wrapper should do its own vetting of the user input and then assume full root privileges. -- Steve Langasek postmodern programmer msg05159/pgp0.pgp Description: PGP signature
Re: smbpasswd and euid detection
On Thu, Jan 02, 2003 at 02:23:09PM -0700, Craig Kelley wrote: I consider confusing smbpasswd with the Unix passwd command a sign that one doesn't really have that much knowledge, at least where smbpasswd itself is concerned. It's easy to jump to the conclusion that smbpasswd needs root privs to make changes to the smbpasswd file -- it does not -- and the program has *not* been audited for use as an suid program, so it's dangerous to treat it the same as passwd. So if someone can run smbpasswd indirectly from an suid wrapper, there's still a high potential for security problems, the same as if smbpasswd is suid itself. If you need to let users call smbpasswd in an suid root context, your wrapper should do its own vetting of the user input and then assume full root privileges. Then let's add suid checking to every program. Most programs don't have the problem of people assuming they're analogous to other suid programs. They can all be abused, and the same argument should apply. Regardless, the patch I presented actually does what the the warning message claims it's doing. It stat()'s the actual binary of smbpasswd to see if it's suid or not. It doesn't add any dependencies, and it should work on all systems capable of handling geteuid(), which smbpasswd already uses. But if you're going to concede that the check is there for a reason (which you seem to be doing by not asking for the check to be removed altogether), then that reasoning applies whether or not smbpasswd itself is the program carrying the suid bit as explained above. -- Steve Langasek postmodern programmer msg05165/pgp0.pgp Description: PGP signature
Re: Samba and Kerberos
Hi Kenneth, On Thu, Jan 02, 2003 at 03:38:47PM -0600, Kenneth Stephen wrote: I am trying to understand the state of Samba using Kerberos authentication. I see from a search on the web that ADS support is now available in Samba, and presumably this uses an encrypted password communicated over the network rather than the behaviour that was previously available via the --with-krb5 flag. If so, would it not be a matter of implementation (as opposed to it being technically infeasible) to make sure that --with-krb5 now works with encrypted passwords? Can someone clue me in as to this please? ADS-style Kerberos support only works when both client and server are Kerberos-aware, so such Kerberos encrypted passwords support would be limited to Win2K and WinXP clients. This is a question of technical feasibility, not of implementation. It appears that the --with-krb5 option is currently used in connection with exactly this feature, and that the previous plaintext Kerberos support has been dropped in 3.0. -- Steve Langasek postmodern programmer msg05169/pgp0.pgp Description: PGP signature
Re: Samba and Kerberos
On Thu, Jan 02, 2003 at 06:28:48PM -0600, Kenneth Stephen wrote: ADS-style Kerberos support only works when both client and server are Kerberos-aware, so such Kerberos encrypted passwords support would be limited to Win2K and WinXP clients. This is a question of technical feasibility, not of implementation. Not sure what this means. If I run the Samba server on the same machine as a server which understood Kerberos authentication (for example, AIX 5.1 with a DCE based KDC), would that qualify? What about the extra info that Microsoft stuffs into the Kerberos protocol that I've heard Win client _need_? I need Samba working with a non-Microsoft KDC. Windows *clients* don't need the extra data; it's only Windows *servers* that need the data -- however, note that I'm using server in the sense of anything that provides a service, which would include a workstation providing login services for members of your Kerberos realm. If your Samba server doesn't need to provide domain auth services for workstation logins, you don't need to worry about the Microsoft PAC. AFAIK, Samba-as-a-fileserver doesn't even *support* using the PAC yet; it gets its group information from other, more Unix-y sources. As for running Samba on a server that understands Kerberos authentication, even that is not required; you can easily run Samba as your only Kerberos-enabled application on a given machine (well, easily assuming you know how to go about setting up Kerberos). Cheers, -- Steve Langasek postmodern programmer msg05171/pgp0.pgp Description: PGP signature
Re: Patch for unix extensions
On Wed, Jan 01, 2003 at 01:01:19PM +0100, Simo Sorce wrote: My idea was this: let make it so taht if unix extensions are enabled, then we NEVER resolve the links if we permit link creation. If we do not want to have it so rigid, we may also add a proper option, something like wide unix symlinks with all the proper warnings and normally disabled. Then if you do a normal call, the link will be honoured only if inside the exported file system. This way the trick cannot work, and unix applications (or setups) that rely on symlinks to work well are happy. If symlinks will never be resolved outside of the exported share, why do you need to resolve them on the server at all? A Unix client is equally capable of resolving this symlink on the server. -- Steve Langasek postmodern programmer msg05140/pgp0.pgp Description: PGP signature
Re: smbwrapper use of port 139 vs 445... Ok to force to 139?
On Mon, Dec 23, 2002 at 02:51:08PM -0500, [EMAIL PROTECTED] wrote: My last known problem with smbwrapper on Linux is that sometimes hosts in a workgroup, or shares on a host, are not returned by the cli_Net*Enum() functions. On another list (debian.something), there is currently a discussion of the fact that using port 445 can cause this problem, and in fact, when I force the port to 139, the problem goes away. I'm not terribly familiar with the protocol differences between what's sent on port 139 and what's sent on port 445. *Specifically for the purposes of smbwrapper...* 1. Is there a reason not to force the port number to 139? 2. Is there any service provided on port 445, not provided on port 139, that's required for smbwrapper to return the correct data? 3. Are there any servers that don't provide port 139 service at all? 4. If #3 is yes, what about trying 139 and falling back to 445 rather than the current implementation which is the other way around? I understand the reason for using 445 as primary and falling back to 139 is that it's much more efficient (both on setup and during data transfer) than doing it the other way around. For the purposes of getting a browse list, connecting to port 139 is a must. There are ways to get the equivalent of a browse list via AD, but I don't think it's LDAP-only, so port 445 doesn't even do any good in this regard. For the actual enumeration of and connecting to shares, port 445 is likely to give some performance increase due to the lower protocol overhead. You can also configure newer Windows machines (XP at least) to *not* support NetBIOS at all, in which case they'll only be listening on port 445. OTOH, there are also plenty of older machines (NT4 and below) that are 139-only. Theoretically, it might be optimal to use port 139 to collect browse lists, and then use 445-else-139 for everything else. Barring that, I think 139-else-445 would be the best option. -- Steve Langasek postmodern programmer msg05067/pgp0.pgp Description: PGP signature
Re: smbwrapper use of port 139 vs 445... Ok to force to 139?
On Mon, Dec 23, 2002 at 03:53:08PM -0500, [EMAIL PROTECTED] wrote: For the purposes of getting a browse list, connecting to port 139 is a must. There are ways to get the equivalent of a browse list via AD, but I don't think it's LDAP-only, so port 445 doesn't even do any good in this regard. For the actual enumeration of and connecting to shares, port 445 is likely to give some performance increase due to the lower protocol overhead. You can also configure newer Windows machines (XP at least) to *not* support NetBIOS at all, in which case they'll only be listening on port 445. OTOH, there are also plenty of older machines (NT4 and below) that are 139-only. If an XP or other new machine is configured to not support port 139, and it becomes a master browser then how would one get the browse list? If NetBIOS is disabled, the machine won't participate in browse elections, so it will never become the master browser. If NetBIOS is enabled, I believe that AD-aware machines are given a slight edge (in the form of the 'os level' option) in the browse election. Theoretically, it might be optimal to use port 139 to collect browse lists, and then use 445-else-139 for everything else. Barring that, I think 139-else-445 would be the best option. This may be possible to do. The function where cli_initialize() and cli_connect() are called, is passed a server name and a share name. The share name seems to be IPC$ for every call I've seen into here, but is likely a real share name when opening a regular file. I have occasionally seen a server name of IPC$ as well. I suppose I could trace and determine which case is caused by which type of enumeration. Do you know offhand in which case(s) of server and share names I'm looking for a browse list? What if I do 139-else-445 if share is IPC$, and do 445-else-139 otherwise? AFAIK, the share name will always be IPC$ for server enumeration, but I don't know what other side effects this approach might have. Certainly, the IPC$ share name would be used for other things which are not NetBIOS-dependent. -- Steve Langasek postmodern programmer msg05069/pgp0.pgp Description: PGP signature
smbclient -L can't see shares with spaces in the name
It appears that 'smbclient -L' is not able to view shares on an NT server (or above) that are created with a space in the name, although it is possible to access these shares if the name is given explicitly. The reason is that NT, 2K, and XP will not return these shares in response to a NetShareEnum, presumably because (as a warning under NT suggests when creating such a share) DOS clients will be confused by such share names. Windows clients get around this by doing a NetrShareEnum call on \SRVSVC instead. Samba also implements this functionality, but the necessary code is not linked into smbclient. Should it be? It seems easy enough to link it in, but so far smbclient doesn't include any RPC code. Is it better to recommend that people use one of the other RPC-aware tools (e.g., 'net share')? In that case, what should be done for libsmbclient, which also has this problem? -- Steve Langasek postmodern programmer msg05049/pgp0.pgp Description: PGP signature
Re: smbclient -L can't see shares with spaces in the name
On Sat, Dec 21, 2002 at 08:40:45PM -0600, Christopher R. Hertel wrote: Note also that none of the calls appear to work properly on port 445. If the call is made on 445 a Windows server will respond, but the response will be empty. Listing of NBT workgroups, servers, and shares must be done on port 139, it seems. I am not sure whether this is true of the newer NetrShareEnum call. ^ rpcclient -d 3 -S server -W domain -U administrator -c 'netshareenum 1' lp_load: refreshing parameters Initialising global parameters params.c:pm_process() - Processing configuration file /etc/samba/smb.conf Processing section [global] added interface ip=192.168.3.2 bcast=192.168.3.3 nmask=255.255.255.254 resolve_lmhosts: Attempting lmhosts lookup for name server0x20 resolve_hosts: Attempting host lookup for name server0x20 Password: Connecting to host=server share=IPC$ Connecting to 192.168.3.1 at port 445 ^^^ Doing spnego session setup (blob length=118) got OID=1 2 840 48018 1 2 2 got OID=1 2 840 113554 1 2 2 got OID=1 2 840 113554 1 2 2 3 got OID=1 3 6 1 4 1 311 2 2 10 got principal=server$@DOMAIN.FQDN.COM lsa_io_sec_qos: length c does not match size 8 netname: IPC$ remark: Remote IPC snip list of remaining shares Looks like this call works fine on port 445. -- Steve Langasek postmodern programmer msg05052/pgp0.pgp Description: PGP signature
Re: smbclient -L can't see shares with spaces in the name
On Sat, Dec 21, 2002 at 10:41:10PM -0600, Christopher R. Hertel wrote: On Sat, Dec 21, 2002 at 09:29:04PM -0600, Steve Langasek wrote: On Sat, Dec 21, 2002 at 08:40:45PM -0600, Christopher R. Hertel wrote: Note also that none of the calls appear to work properly on port 445. If the call is made on 445 a Windows server will respond, but the response will be empty. Listing of NBT workgroups, servers, and shares must be done on port 139, it seems. I am not sure whether this is true of the newer NetrShareEnum call. Looks like this call works fine on port 445. Interesting. Try the older RAP calls, though. They do work on both ports but don't return any information if the call is made via port 445. At least, that's true of the NetShareEnum2 calls for the workgroup and server lists. Well, a 'net rap share' also gives me a share list when run against the server in question. I'm guessing that Microsoft did the sensible thing in this case, and all RPC calls are available over port 445 except for those which are strictly related to NetBIOS itself. I assume the above was against a W2K server, yes? Yep. -- Steve Langasek postmodern programmer msg05054/pgp0.pgp Description: PGP signature
[Samba] XP slow to print to Samba 3.0 alpha21 server
Hi all, As WinXP begins to loom larger in our environment, we're seeing a consistent pattern that XP machines (mostly XP Professional, possibly others) take an excessively long time to access shared printers: I'm told that it takes up to 5 minutes to initially install the printer on the local machine, and it typically takes around 45 seconds to deliver print jobs to the queue. The print server is running Samba 3.0alpha21. The server is also a DC for an NT domain that these WinXP machines are joined to. We are using spoolss and server-provided print drivers, and I did add the XP printer drivers to the server using the Add Print Wizard in an effort to alleviate the lag (printing is slow both before and after uploading those drivers). Anecdotal evidence suggests that printing was much quicker before upgrading to Samba 3.0, though I haven't had a chance yet to set up a 2.2 test print server to verify. Network traces and log files happily provided to anyone willing to tackle this issue. Thanks, -- Steve Langasek postmodern programmer msg11149/pgp0.pgp Description: PGP signature
[Samba] Re: XP slow to print to Samba 3.0 alpha21 server
One additional bit of information -- On Fri, Dec 20, 2002 at 09:56:21AM -0600, Steve Langasek wrote: As WinXP begins to loom larger in our environment, we're seeing a consistent pattern that XP machines (mostly XP Professional, possibly others) take an excessively long time to access shared printers: I'm told that it takes up to 5 minutes to initially install the printer on the local machine, and it typically takes around 45 seconds to deliver print jobs to the queue. The print server is running Samba 3.0alpha21. The server is also a DC for an NT domain that these WinXP machines are joined to. We are using spoolss and server-provided print drivers, and I did add the XP printer drivers to the server using the Add Print Wizard in an effort to alleviate the lag (printing is slow both before and after uploading those drivers). Anecdotal evidence suggests that printing was much quicker before upgrading to Samba 3.0, though I haven't had a chance yet to set up a 2.2 test print server to verify. If I set 'disable spoolss = yes' in smb.conf, XP machines have no trouble at all when printing. Of course, this requires a bit of per-client reconfiguration, but it'll do the trick here for now. I'll turn spoolss back on some evening when the network's not in use to get some good log traces. Cheers, -- Steve Langasek postmodern programmer msg11155/pgp0.pgp Description: PGP signature
changes to passdb backend defaults in 3.0 alpha21
The following code appears in source/params/loadparm.c from 3.0alpha21: #ifdef WITH_LDAP_SAMCONFIG string_set(Globals.szLdapServer, localhost); Globals.ldap_port = 636; Globals.szPassdbBackend = str_list_make(ldapsam unixsam, NULL); #else Globals.szPassdbBackend = str_list_make(smbpasswd unixsam, NULL); #endif /* WITH_LDAP_SAMCONFIG */ Would it be possible to revert this change with respect to the 'passdb backend' default? This is a very awkward default for packagers who wish to enable LDAP support in their binaries, but still need to serve the needs of users who are not (yet) using LDAP. Thanks, -- Steve Langasek postmodern programmer msg05040/pgp0.pgp Description: PGP signature
Re: XP slow to print to Samba 3.0 alpha21 server
One additional bit of information -- On Fri, Dec 20, 2002 at 09:56:21AM -0600, Steve Langasek wrote: As WinXP begins to loom larger in our environment, we're seeing a consistent pattern that XP machines (mostly XP Professional, possibly others) take an excessively long time to access shared printers: I'm told that it takes up to 5 minutes to initially install the printer on the local machine, and it typically takes around 45 seconds to deliver print jobs to the queue. The print server is running Samba 3.0alpha21. The server is also a DC for an NT domain that these WinXP machines are joined to. We are using spoolss and server-provided print drivers, and I did add the XP printer drivers to the server using the Add Print Wizard in an effort to alleviate the lag (printing is slow both before and after uploading those drivers). Anecdotal evidence suggests that printing was much quicker before upgrading to Samba 3.0, though I haven't had a chance yet to set up a 2.2 test print server to verify. If I set 'disable spoolss = yes' in smb.conf, XP machines have no trouble at all when printing. Of course, this requires a bit of per-client reconfiguration, but it'll do the trick here for now. I'll turn spoolss back on some evening when the network's not in use to get some good log traces. Cheers, -- Steve Langasek postmodern programmer msg05042/pgp0.pgp Description: PGP signature
Re: strange location for printing/*.tdb in latest
On Mon, Dec 16, 2002 at 10:49:02PM -0500, Bradley W. Langhorst wrote: the printing tdbs are ending up in /var/run/samba/printing seems like those should be in cache... its not a problem with the rules file LOCKDIR is getting set to /var/cache/samba PIDDIR is /var/run/samba i don't understand what is happening with tdb files in printing.c so I don't now how to track this down further... Hmm, sounds like this is a Debian-specific problem. I'll hunt this down and let you know. -- Steve Langasek postmodern programmer msg05000/pgp0.pgp Description: PGP signature
Re: Kerberized SMB client? User level SMB client?
On Mon, Dec 16, 2002 at 08:05:36PM -0800, Naomaru Itoi wrote: I am trying to do PKINT from SMB/CIFS client on several UNIX platforms. 1. Is there an open-sourced, Kerberized SMB/CIFS client on UNIX? 2. If not ... I guess I have to Kerberize an SMB/CIFS client. In that case, I would like to avoid doing GSS-API and Kerberos in kernel. Is there an open-sourced, user-level SMB/CIFS client? The smbclient program from Samba 3.0 does have early support for Kerberos. I'm not sure if that code path gets tested regularly, but it's there at lesat. -- Steve Langasek postmodern programmer msg05002/pgp0.pgp Description: PGP signature
Re: ntfs issue
On Thu, Dec 12, 2002 at 04:06:55PM +0800, AndyChu wrote: Does samba support share those files in a ntfs partition ? This is meaningless. Samba does not support NTFS partitions, because Samba does not interface with partitions. If you are asking whether Samba can *serve* shares from NTFS partitions, that's a question of whether the host OS supports the filesystem. If you are asking whether Samba (smbclient) can *access* shares on NTFS partitions, then yes -- though NTFS has little to do with it. -- Steve Langasek postmodern programmer msg04915/pgp0.pgp Description: PGP signature
Re: smbwrapper/smbsh is now working for Linux 2.4
On Tue, Dec 10, 2002 at 01:54:52PM -0500, [EMAIL PROTECTED] wrote: On Tue, Dec 10, 2002 at 01:27:07PM -0500, [EMAIL PROTECTED] wrote: I have smbwrapper and smbsh working on Debian/woody with the Linux 2.4 kernel and the default C library: libc-2.2.5.so. Yes, I'm interested - please post patches. Pressure of other things has made this a low priority but I'm really happy to apply patches that work for people ! Ok. The patch is attached. This became a high priority for me when smbmount used with automount turned out to be way too slow. This seems substantially faster in terms of connection establishment. The problems I have encountered with smbsh so far pertain to something that Debian is doing in their build process. smbsh works well with bash if bash is built from source with nothing other than ./configure;make. Using Debian's build process or their bash binary, however, bash crashes after reading the .bash_history file. (Debian modifies the default build process and I haven't spent the time to determine which change they make causes this.) Similarly, the program hostname crashes using the default binary. (I haven't tried rebuilding that one to see if a simple recompile fixes it.) In both cases, they're getting segmentation violations, and I believe there's a function pointer not getting resolved properly with the various wrappers provided by smbwrapper.so. I'm sure there are other apps which will crash as well, but I did a bunch of stuff today in bash in smbsh and it was generally working well. Hmm -- perhaps that's why I never got anywhere with my own efforts, bash was the only program I ever tested with. :) I suspect the key change in the Debian build is enabling of LFS support; IIRC, it was in an LFS-related call that I saw segfaults happen. LFS is definitely something that smbsh needs to be able to handle cleanly to be a viable option to smbmount: it's one thing to be on a filesystem (such as some version of smbfs) that can't handle large files, and quite another for the application to crash whenever you run one of the growing number of applications that use the LFS userspace calls. I'll scare up some time to try out your patch, and see if I can figure out what's special about the calls that are failing. Cheers, -- Steve Langasek postmodern programmer msg04872/pgp0.pgp Description: PGP signature
Re: [PATCH] allow cross-compiling samba-2.2.7
On Fri, Dec 06, 2002 at 07:29:52AM -0800, Dan Kegel wrote: I needed to cross-compile Samba for ppc linux from x86 linux. Fortunately, samba-2.2.7 is very nearly cross-compile-friendly. The main problem when cross-compiling autoconf'd projects is AC_TRY_RUN in configure.in, which just doesn't work. Sure enough, to get Samba to build in a cross-compilation environment, all I had to do was get rid of one use of AC_TRY_RUN in configure.in, run autoconf2.50 (to generate a configure script that sets SIZEOF_INT without using AC_TRY_RUN), and run configure like this: CC=/opt/cegl-1.4/hardhat/devkit/ppc/405/bin/powerpc-linux-gcc CFLAGS=-mcpu=403 ../samba-2.2.7/source/configure --build=pentium-unknown-linux --host=ppc-unknown-linux Here's a patch that removes the one use of AC_TRY_RUN in configure.in that was causing trouble. (And oddly, this makes the definition of HAVE_GETTIMEOFDAY_TZ better match how this macro is used in the sources, I think.) Please apply if you agree it's benign. Thanks! Are you certain that the runtime check isn't needed on some platforms? There may be some platforms that appear to have a working gettimeofday() until you actually try to *use* it; maybe the AC_TRY_RUN was frivolous, but maybe it was added to deal with a real problem. In the latter case, AC_TRY_RUN should be called with a sane default for cross-compiling. -- Steve Langasek postmodern programmer msg04813/pgp0.pgp Description: PGP signature
Segfault in 3.0alpha20 [woeltgens@physik.rwth-aachen.de: Bug#171823: Segfault in Samba]
Hello, I'm finding that setting a default panic action in smb.conf has been an effective tool for finding out about segfaults that users wouldn't report otherwise. ;) Below, please find the first of several reports of segfaults in Samba 3.0alpha20. If anyone recognizes this (or others) as a bug that was fixed in alpha21, please let me know; otherwise, I'd be obliged if someone was interested in taking a look at these crashes. Cheers, -- Steve Langasek postmodern programmer - Forwarded message from Han-Willem Woltgens [EMAIL PROTECTED] - The Samba 'panic action' script, /usr/share/samba/panic-action, was called for pid 11676 (/usr/sbin/smbd). Below is a backtrace for this process generated with gdb, which shows the state of the program at the time the error occured. You are encouraged to submit this information as a bug report to Debian. For information about the procedure for submitting bug reports , please see http://www.debian.org/Bugs/Reporting or the reportbug(1) manpage. (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... 0x401ec269 in wait4 () from /lib/libc.so.6 #0 0x401ec269 in wait4 () from /lib/libc.so.6 #1 0x4025f3c4 in sys_sigabbrev () from /lib/libc.so.6 #2 0x4018e200 in strtold_l () from /lib/libc.so.6 #3 0x4018e2da in system () from /lib/libc.so.6 #4 0x0816c29c in smb_panic () #5 0x0815db4a in dbgtext () #6 0x0815dba5 in dbgtext () #7 0x40177bd8 in sigaction () from /lib/libc.so.6 #8 0x08092ff4 in reply_getattrE () #9 0x080931f0 in reply_sesssetup_and_X () #10 0x080aa6be in respond_to_all_remaining_local_messages () #11 0x080aa75e in respond_to_all_remaining_local_messages () #12 0x080aa9e3 in process_smb () #13 0x080ab377 in smbd_process () #14 0x08071bef in main () #15 0x40166a5f in __libc_start_main () from /lib/libc.so.6 - - End forwarded message - msg04819/pgp0.pgp Description: PGP signature
Segfault #2 in 3.0alpha20 [Sandor.Sonfeld@knorr-bremse.com: Bug#171071: Segfault in samba]
Hello, Another segfault in 3.0alpha20. More details available at http://bugs.debian.org/171071. Cheers, -- Steve Langasek postmodern programmer - Forwarded message from Sönfeld Sándor [EMAIL PROTECTED] - The Samba 'panic action' script, /usr/share/samba/panic-action, was called for pid 16922 (/usr/sbin/smbd). Below is a backtrace for this process generated with gdb, which shows the state of the program at the time the error occured. You are encouraged to submit this information as a bug report to Debian. For information about the procedure for submitting bug reports , please see http://www.debian.org/Bugs/Reporting http://www.debian.org/Bugs/Reporting or the reportbug(1) manpage. (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...0x401e7269 in wait4 () from /lib/libc.so.6 #0 0x401e7269 in wait4 () from /lib/libc.so.6 #1 0x4025a3c4 in sys_sigabbrev () from /lib/libc.so.6 #2 0x40189200 in strtold_l () from /lib/libc.so.6 #3 0x401892da in system () from /lib/libc.so.6 #4 0x0816c29c in smb_panic () #5 0x0815db4a in dbgtext () #6 0x0815dba5 in dbgtext () #7 0x40172bd8 in sigaction () from /lib/libc.so.6 #8 0x401b6007 in realloc () from /lib/libc.so.6 #9 0x0816b871 in Realloc () #10 0x08196578 in create_nt_token () #11 0x0819710e in make_server_info_info3 () #12 0x08197bf9 in get_info3_from_ndr () #13 0x08190e2e in smb_delete_user_group () #14 0x08092c68 in reply_getattrE () #15 0x08092ff4 in reply_getattrE () #16 0x080931f0 in reply_sesssetup_and_X () #17 0x080aa6be in respond_to_all_remaining_local_messages () #18 0x080aa75e in respond_to_all_remaining_local_messages () #19 0x080aa9e3 in process_smb () #20 0x080ab377 in smbd_process () #21 0x08071bef in main () #22 0x40161a5f in __libc_start_main () from /lib/libc.so.6 - End forwarded message - msg04821/pgp0.pgp Description: PGP signature
Win2K sp3 and Samba 3.0: status?
Hello, When I try to join a Win2K SP3 server to a Samba 3.0alpha21-controlled NT domain, I get the error 'The parameter is incorrect'. I understand that SP3 is known to suffer problems not present with SP2, and the usual suggestion seems to be to set 'use spnego = no' in smb.conf. However, this setting does not appear to have any effect, and attempting to join the domain gives the same error message. Does anyone have any insights into the status of SP3 compatibility in Samba? Would network traces or log files be of use to anyone? -- Steve Langasek postmodern programmer msg04804/pgp0.pgp Description: PGP signature
Re: Win2K sp3 and Samba 3.0: status?
On Thu, Dec 05, 2002 at 02:26:08PM -0800, Richard Sharpe wrote: When I try to join a Win2K SP3 server to a Samba 3.0alpha21-controlled NT domain, I get the error 'The parameter is incorrect'. I understand that SP3 is known to suffer problems not present with SP2, and the usual suggestion seems to be to set 'use spnego = no' in smb.conf. However, this setting does not appear to have any effect, and attempting to join the domain gives the same error message. Does anyone have any insights into the status of SP3 compatibility in Samba? Would network traces or log files be of use to anyone? These will be useful. Network traces, that is. However, you will want to turn off the two signseal registry entries, and reboot the client before joining. Good news: I've gotten the server to join, and even have some idea of the source of the trouble. The server was joined to an AD realm initially, and we were trying to transition directly to the Samba domain. If I parted from the AD realm first and rebooted, I was then able to join the domain. When parting the AD realm, Win2K did give a warning that it failed to delete the machine account, but this was non-fatal. I'm wondering if this was the real cause of the failure before, in which case the network trace I sent you probably wouldn't be particularly useful. Is there any concerted effort to document such issues, where I might forward this hint? -- Steve Langasek postmodern programmer msg04806/pgp0.pgp Description: PGP signature
[Samba] Re: Machine accounts are no longer recognized in SAMBA 3.0-20-4
Irving, On Tue, Dec 03, 2002 at 05:26:42PM -0500, Irving Carrion wrote: After verifying my smb.conf file, the only thing that changed was this panic action command was added. My smb.conf is attached. All our workstations stopped working. If I change the computer name, switch to workgroup, then try to re-join the domain under a different computer name, it works. Do you know what .tdb file machine information is stored in. Also I exported all information from the pdbedit backend using pdbedit -e to an smbpasswd format and everything looked fine. All machine accounts were listed. So I don't think it's the passdb.tdb. This smb.conf snippet looks telling: passdb backend = smbpasswd #passdb backend = smbpasswd unixsam #passdb backend = smbpasswd tdbsam unixsam You said you exported all information [...] to an smbpasswd format, but your comments suggest that you are actually expecting samba to read its passdb from passdb.tdb. The above snippet clearly shows that Samba is configured to look *only* at /etc/samba/smbpasswd, and not at /etc/samba/passdb.tdb. Could this be the source of the trouble? Can you confirm that *this* section of your smb.conf was the same before and after the upgrade to -4 -- in which case, I would suggest that an ill-fated config change took effect when smbd restarted at the time of the upgrade? Cheers, -- Steve Langasek postmodern programmer msg09989/pgp0.pgp Description: PGP signature
[Samba] Re: Machine accounts are no longer recognized in SAMBA 3.0-20-4
On Tue, Dec 03, 2002 at 05:41:05PM -0500, Irving Carrion wrote: Well that's because I started out using the following: passdb backend = tdbsam:/etc/samba/passdb.tdb unixsam Well, shoot -- that was my best guess. :) All our workstations stopped working. If I change the computer name, switch to workgroup, then try to re-join the domain under a different computer name, it works. Do you know what .tdb file machine information is stored in. All the necessary machine information is stored in the passdb -- either in smbpasswd or in passdb.tdb. If you try to rejoin the domain *without* changing the computer name, what happens? If you look at one of these machine accounts using pdbedit -lv -u 'machine$', what do you see for 'account flags'? I believe it should say Account Flags:[W ] If it doesn't, the account is no longer listed as a machine account, and this would explain why the domain trust is failing. I'm not sure if the pdbedit command gives you a way to change this, though obviously you can edit smbpasswd directly to fix it. But it really doesn't matter which backend I use, they both don't work smbpasswd or tdbsam. Plus theoretically they both should have the same information since smbpasswd was generated from an expert I performed on tdbsam using pdbedit -e. Ok. I'm just trying to figure out how something in the maintainer scripts would leave you with a valid, yet broken passdb.tdb file. Was passdb.tdb one of the tdb files that you tried to restore to fix this? Was there any difference between the old passdb.tdb and the one present after upgrading to -4? -- Steve Langasek postmodern programmer msg09993/pgp0.pgp Description: PGP signature
Re: Machine accounts are no longer recognized in SAMBA 3.0-20-4
Hi Irving, On Tue, Dec 03, 2002 at 04:20:45PM -0500, Irving Carrion wrote: Yesterday we upgraded Samba to version 2.999+3.0.alpha20-4 and this morning NO-ONE was able to log in to the Samba PDC. I upgraded from 20-3. Nothing has changed in the smb.conf file. We are using the unstable version of Samba because this is the only version of SAMBA that works with our SNAP server. (Damn SNAP!. We should have built our own fileserver!!! ;( ) The error message on Win2k is something to the effect of Your computer account is invalid or the password is incorrect I verified (using pdbedit -lv) that the computer account is there and that they were not expired. I have a debug 10 log ready for anyone who can help me. Would really APPRECIATE ANY HELP anyone out there can give me! MORE INFORMATION: I reverted back to 20-3 with no success. I also restored all the old .tdb's with no success. Do you also have an old copy of smb.conf you could restore, or are you eyeballing the smb.conf to confirm that nothing has changed? Your experience with switching back to -3 suggests that some change in the packaging caused your smb.conf to be reconfigured incorrectly, but it's not obvious to me what this change might have been. Can you forward your smb.conf file (either to this list or to the Debian BTS) for inspection? How many workstations exhibited the account is invalid error? Are you able to try re-joining the domain from one of these workstations, to see if this corrects the error? If so, there's a question of whether your passdb was somehow overwritten with old information (i.e., old versions of the workstation shared secrets). Is there a way to disable samba looking for valid machine accounts temporarily so that users can log in while I try to fix this problem? No, this is fundamental to domain logins; without a valid machine account, there's no trust relationship between the workstation and the PDC, and no way to securely verify the login credentials. -- Steve Langasek postmodern programmer msg04750/pgp0.pgp Description: PGP signature
Re: Encrypted Passwords Restricting Logon Attempts
On Wed, Nov 27, 2002 at 08:51:44AM -0600, Jim Morris wrote: It would also prevent domain logons, and exposes bugs in other parts of Microsoft's client. The domain in this case is controlled by Samba. Most of the clients are Windows 95/98 clients, and testing with Windows 98 seems to show that it can do a 'domain logon'. For the record, I know that this is not quite the same as the domain logon that Windows 2000 or NT clients will do, and I have yet to test one of those clients. (I spent a LOT of time working through the domain logon stuff a couple of years ago when working on those chapters of 'Special Edition, Using Samba' with Richard Sharpe). Anyway, I would only consider this switch to plaintext passwords a temporary measure while I come up with something better. With Win95/98 it might not be such an issue. If you have any member servers in your domain, it IS an issue, because the only way to get recent versions of Windows to negotiate plaintext auth is for the server to say it does NOT support encrypted passwords, and a server that doesn't support encrypted passwords cannot be a DC. There really is no way to do this with PAM that will work for most people. You'd need some other sort of hook into the Samba authentication system to achieve the effect. PAM is not suitable, because the authentication can't be handed off to PAM, and nothing in PAM will know the result of this authentication unless PAM *performed* the authentication. -- Steve Langasek postmodern programmer msg04651/pgp0.pgp Description: PGP signature
Re: Browsing
On Tue, Nov 26, 2002 at 02:43:19PM +, Neil Hoggarth wrote: On Tue, 26 Nov 2002, Dave Satterthwaite wrote: Trying to use Samba V2.2 on AIX V4.3.3 Set-up without any problems and can use the read only shares that users require. Problem is the UNIX server becomes master browser for our NT domain. Read documentation and have made recommended changes to smb.conf, but still the same. samba-technical is a mailing list for development discussions - please use the [EMAIL PROTECTED] list for general questions. Try something like: [global] domain master = no local master = no preferred master = no os level = 0 It's far better to use the defaults for all of these values, particularly since Win9x wets itself when it's left in charge of a subnet as the LMB. (He probably is using non-default values for at least one of the above options, if Samba is interfering with the NT domain.) -- Steve Langasek postmodern programmer msg04622/pgp0.pgp Description: PGP signature
Re: winbind and NSS
On Tue, Nov 26, 2002 at 01:43:44PM -0800, Arup Biswas wrote: I am interested in using winbind for mapping users and groups across unix and windows domains. To achieve this samba documentation specifies the following entries in the nsswitch.conf passwd: files(nis)winbind groups: files(nis) winbind My understanding of the smbd code is that getpwnam() is the only nss call that is really used in the context of mapping users/groups. My question is what is the basic minimal set of nss calls that I need to support in order to achieve user/group mapping. Here is why I am considering supporting only the minimal set of nss calls: we are using a platform where nss is not supported and the less number of calls we need to nss-enable the less work for us. We can keep the other password/group access calls nss-disabled. getpwnam getpwnam_r getpwuid getpwuid_r getpwent (optional) getgrnam getgrnam_r getgrgid getgrgid_r getgrent (optional) Those are the main calls. Depending on how the system is implemented, you may need to consider other NSS calls for the backend to the initgroups() function, but otherwise, that pretty much covers everything you'd need to do with NSS for users and groups. -- Steve Langasek postmodern programmer msg04629/pgp0.pgp Description: PGP signature
Re: Browsing
On Tue, Nov 26, 2002 at 12:28:58PM -0600, Christopher R. Hertel wrote: On Tue, Nov 26, 2002 at 10:03:08AM -0600, Steve Langasek wrote: It's far better to use the defaults for all of these values, particularly since Win9x wets itself when it's left in charge of a subnet as the LMB. (He probably is using non-default values for at least one of the above options, if Samba is interfering with the NT domain.) I'd love to get some hard data on this. Does anyone have a description of what happens so I can reproduce it and get some traces? Win9x servers are able to successfully collate browse lists for the local segment when acting as the LMB. However, they do not sync their browse list with the DMB, so a segment which has a Win9x machine as LMB can't participate in cross-subnet browsing. If your Samba machine is on the same segment as your DMB, it's not a big deal to tell it to never be an LMB -- the only time it would need to be the LMB is when all other NT servers, including the DMB, are off-line, so syncing becomes a non-issue. Even so, random twiddling of Samba defaults is not the best way to fix a problem, and is more likely to cause issues down the line. -- Steve Langasek postmodern programmer msg04630/pgp0.pgp Description: PGP signature
Re: (fwd from jerry@theashergroup.com) Suggestion: describe (or link to) how to verify your distributions
On Fri, Nov 22, 2002 at 12:56:39PM -0800, Martin Pool wrote: I'll write up a short page describing how to use them, unless Jerry particularly wants to do it. In five words or less, from the gpg manpage: $ gpg --verify samba-2.2.7.tar.gz.asc samba-2.2.7.tar.gz -- Steve Langasek postmodern programmer msg04550/pgp0.pgp Description: PGP signature
Re: (fwd from jerry@theashergroup.com) Suggestion: describe (or link to) how to verify your distributions
On Fri, Nov 22, 2002 at 03:16:09PM -0600, David W. Chapman Jr. wrote: On Fri, Nov 22, 2002 at 01:08:39PM -0800, Martin Pool wrote: Yeah, sure, but: What does this all mean? Why should I care? Where do I get GPG? Where do I get the samba codesigning key? How do I import it? How do I know I got the right one? What do I do if it doesn't verify? I always wondered if someone uploaded a tarball with a trojan, what's preventing them from updating the .asc file as well? It's a cryptographic signature that can only be produced using a specific key. Assuming that the key belongs to the party whose name is on it, and assuming that the key is well-protected from theft, and assuming that the algorithms used by PGP haven't been broken, you can be assured that the signature was made by the person it claims to have come from. Asking about, I've been pointed to http://gnupg.org/gph/en/manual.html as a general intro to GPG. -- Steve Langasek postmodern programmer msg04559/pgp0.pgp Description: PGP signature
Re: (fwd from jerry@theashergroup.com) Suggestion: describe (or link to) how to verify your distributions
On Sat, Nov 23, 2002 at 08:29:57AM +1100, Tim Potter wrote: On Fri, Nov 22, 2002 at 03:16:09PM -0600, David W. Chapman Jr. wrote: Where do I get the samba codesigning key? How do I import it? How do I know I got the right one? What do I do if it doesn't verify? I always wondered if someone uploaded a tarball with a trojan, what's preventing them from updating the .asc file as well? This is why you can't necessarily ignore the message that says: gpg: WARNING: This key is not certified with a trusted signature! The samba team needs to get more people to sign the distribution key so this message becomes less frequent. Hmm. I see nine signatures already, and I have a full trust relationship to the key which traverses multiple paths through the keyring, the shortest of which is only three hops long, despite never having met a member of the Samba Team. All in all, a well-connected key, and I think if there are people who get this error and actually care about it :), the problem is more likely to lie on their end of the web of trust. -- Steve Langasek postmodern programmer msg04561/pgp0.pgp Description: PGP signature
Re: (fwd from jerry@theashergroup.com) Suggestion: describe (or link to) how to verify your distributions
On Fri, Nov 22, 2002 at 02:31:21PM -0800, Martin Pool wrote: According to samba.html, the distribution key is http://us1.samba.org/samba/ftp/samba-pubkey.asc gpg: key 2F87AF6F: public key Samba Distribution Verification Key [EMAIL PROTECTED] Then perhaps this should be refreshed from the copy that's on the public keyservers, which is where I imported it from? mbp@toey ~% gpg --list-sig 2F87AF6F pub 1024D/2F87AF6F 2002-10-15 Samba Distribution Verification Key [EMAIL PROTECTED] sig 3 2F87AF6F 2002-10-15 Samba Distribution Verification Key [EMAIL PROTECTED] sig D83511F6 2002-10-15 Gerald W. Carter [EMAIL PROTECTED] sub 1024g/4A271F85 2002-10-15 [expires: 2004-10-14] sig 2F87AF6F 2002-10-15 Samba Distribution Verification Key [EMAIL PROTECTED] Jerry's key is pretty well signed, but perhaps not strongly connected to the world at large. Ah, well, he at least has good connectivity to other Samba Team members. And to other people from valinux.com that I don't recognize. :) I don't know of any way to get GPG to automatically download signatures for the web of trust, so unless people happen to have Jerry's key and those of the people who certify him it is likely to be untrusted. You write a shell script that walks the signature list and grabs from the keyserver, I suppose. I think it would be good to get other developers to sign the distribution key. Perhaps we might also get organizations like CERT or AusCERT to sign the key (if they will), because administrators are likely to already have their pubkeys. Do you have key IDs for CERT and AusCERT? I'm interested to see how well-connected they are (would hate for people to substitute unfounded faith in one key for a similar faith in another, at least). Debian being what it is, most of my trust paths to the world pass through people, not through organizations... :) -- Steve Langasek postmodern programmer msg04565/pgp0.pgp Description: PGP signature
Re: Samba and the passwd -r nis command
On Mon, Nov 18, 2002 at 06:27:59PM +, [EMAIL PROTECTED] wrote: cheers for that, but I'm not bothered about using windows to change the password, most of the users are unix based and could be cajoled into using smbpasswd, I can always set up another password change system for the windows only users (I seem to remember using http at my last company, to synchronise passwords), having a standard system for changing passwords will make everyone happy. The smbpasswd command looks to do the trick, I give it a plaintext old password and it knows about it. All I want is to be able to pass this onto smbd and the chgpasswd module. thanks for the input though, as I hadn't thought about the windows side of things. Ah, that may give you a few other options. Unfortunately, the preferred password change protocol used by smbpasswd (when not running as root) will still not give Samba the old plaintext password; and even if it did, you could not easily prevent password changes from Windows clients that would muck up your synchronization. However, if password changes are being done exclusively from the commandline, you could make your 'passwd' command a wrapper which passes the old plaintext password to both the real 'passwd' command and to 'smbpasswd' as needed. Depending on the platform, this might also be doable using PAM, though I don't know what module to recommend for PAM-based NIS password changes. HTH, -- Steve Langasek postmodern programmer msg04503/pgp0.pgp Description: PGP signature
Re: Samba and the passwd -r nis command
On Mon, Nov 18, 2002 at 05:31:10PM +, [EMAIL PROTECTED] wrote: I have set up a Samba server as a PDC, but want to be able to set passwords via NIS, for this end (the NIS server could be on any machine, the PDC could be on any machine) I need the passwd -r NIS command to work. I have trolled through the code but have come up against a problem, that being that the code doesn't pass the old unix password through the code, it looks like smbpasswd reads it in and passes it onto smbd to change. Could anybody tell me if a patch has been applied to solve this problem (I know the code says samba PDC must be run on the NIS master, but that isn't practical is our environment). I tracked the piece of code down to this bit in smbd\chgpasswd.c, the second argument should be the old unix password but isn't known in this module. I will keep on looking for a way around this, but any help / pointers to patches that fix this, are appreciated. Er, that's a limitation of the way Windows clients send password changes. You're not going to be able to synchronize a Samba PDC to a remote NIS master, because the Samba server never *has* the plaintext of the old password. If running the Samba PDC on the NIS master is not practical for your environment, then password synchronization between NIS and the PDC is not practical for your environment. -- Steve Langasek postmodern programmer msg04499/pgp0.pgp Description: PGP signature
[patch] add trivial online documentation for 'net join'
Currently in 3.0 CVS, 'net help join' returns the message 'No command: join'.
It should at least be possible to get limited usage information about
the command; below is a patch to do this. This doesn't call
net_common_methods_usage(), because there's no support for domain
joining using RAP.
Cheers,
--
Steve Langasek
postmodern programmer
Index: source/utils/net_help.c
===
RCS file: /cvsroot/samba/source/utils/net_help.c,v
retrieving revision 1.2.2.2
diff -u -w -r1.2.2.2 net_help.c
--- source/utils/net_help.c 25 Sep 2002 15:19:00 - 1.2.2.2
+++ source/utils/net_help.c 9 Nov 2002 10:26:48 -
-94,6 +94,18
return -1;
}
+int net_help_join(int argc, const char **argv)
+{
+ d_printf(\nnet [method] join [misc. options]\n
+\tjoin this server to an NT4 domain or ADS realm\n);
+ d_printf(Valid methods: (auto-detected if not specified)\n);
+ d_printf(\tads\t\t\t\tActive Directory (LDAP/Kerberos)\n);
+ d_printf(\trpc\t\t\t\tDCE-RPC\n);
+ d_printf(\n);
+ net_common_flags_usage(argc, argv);
+ return -1;
+}
+
int net_help_share(int argc, const char **argv)
{
d_printf(
-165,6 +177,7
{PRINTQ, net_rap_printq_usage},
{USER, net_help_user},
{GROUP, net_help_group},
+ {JOIN, net_help_join},
{VALIDATE, net_rap_validate_usage},
{GROUPMEMBER, net_rap_groupmember_usage},
{ADMIN, net_rap_admin_usage},
msg04366/pgp0.pgp
Description: PGP signature
Re: samba-head bug relating to windows special chars (1/2)
On Wed, Nov 06, 2002 at 08:35:23PM +1100, Andrew Bartlett wrote:
On Wed, 2002-11-06 at 19:22, Richard Sharpe wrote:
On Wed, 6 Nov 2002, Richard Sharpe wrote:
On Wed, 6 Nov 2002 [EMAIL PROTECTED] wrote:
Oh. Do you have the unix character set set to iso8859-1 ? I
don't think that character set has a 1/2 character. Try
setting it to utf8 and see if this fixes it.
Hmmm, Under FreeBSD, that character is encoded as 0xC2 0xBD while under
Linux it is encoded as 0xAB ...
So, I think it might be a failure to do with the creation of the file in
the first place ...
OK, problem solved. The file name was created under Samba 2.2.x, and then
the profiles were accessed under Samba-head.
The translation schemes were different.
This is going to bite us badly, as sites upgrade. Is there any way we
can make this more automatic?
The switch from pass-through to Unicode for the default server charset is
an important enhancement for anyone deploying a new Samba service. I
think it would be difficult even to support a backwards compatibility
mode without reintroducing the 'client code page' option, which is better
off dead, IMHO.
This problem particularly arises with sites that have *never configured*
their charset settings in smb.conf, but are nevertheless using non-ASCII
filenames. This is ok in 3.0, but was not in 2.2. Now they switch to
Samba 3.0, which will negotiate Unicode, and suddenly passthrough means
UCS-2 -- there's no way to even guess what codepage they were using
before without some nasty filename heuristics, because nothing ever said!
Instead of providing backwards-compatibility for configurations that were
broken in the first place, I think something like the below script, added
to the upgrade documentation, would be better. The script was written
for Linux (GNU find, GNU bash, GNU iconv :), and probably needs to be
adjusted some for portability -- though something equivalent to iconv is
still required for automatic filename conversion.
Steve Langasek
postmodern programmer
find /path/to/share -type f -exec bash -c 'CP={}; ISO=`echo -n $CP | iconv -f
cp850 \
-t iso8859-15`; if [ $CP != $ISO ]; then mv $CP $ISO; fi' \;
msg04314/pgp0.pgp
Description: PGP signature
Re: samba-head bug relating to windows special chars (1/2)
On Thu, Nov 07, 2002 at 07:15:00AM +1030, Richard Sharpe wrote: On Wed, 6 Nov 2002 [EMAIL PROTECTED] wrote: On Thu, Nov 07, 2002 at 07:01:55AM +1100, Matthew Geier wrote: We had less than expected pain with corrupt file names when I changed the server. Most of the problems seem to be related to '3 1/2' in peoples profiles. But it didn't happen to every body. I can only assume the others never copy files to their floppy drives. :-) This should be ok on 3.0 so long as you set the smb.conf to store all files in utf8 character set on the disk. Actually, I was trawling through the code last night, and the default is UTF-8 if you don't set anything. Yep. This means Samba 3.0 by default has better Unicode support than Windows does -- too bad only Unix clients can take advantage of it. ;) -- Steve Langasek postmodern programmer msg04322/pgp0.pgp Description: PGP signature
Re: make 'ldap trust ids' the default?
On Sat, Nov 02, 2002 at 06:36:47PM +1100, Andrew Bartlett wrote: I've just committed a patch that adds a new 'ldap trust ids' smb.conf option. Currently defaulting to off, this option allows pdb_ldap to use the ldap server directly to determine if a user 'exists' in unix. This gives us a performance boost, particularly on enumerations: (Removes the extra lookup per record). The logic is such that if there are no posixAccount attributes for a user, we try getpwnam(), it's just that we look in LDAP first. As such, do people think we should have this by default? This was a fix to solve some particular problems that metze had, and I'll see if I can get some feedback on exactly how much this helps. This seems terribly kludgy to me. There's a lot that can be done to optimize unix username lookups without violating the abstraction (e.g., nscd). I particularly don't think this should be used for anything that involves *enumerating* users, as the most frequent NSS configuration involving LDAP is to reference both LDAP *and* local files; so enumerating via the Unix calls may give different results than doing so via the LDAP calls. Steve Langasek postmodern programmer msg04254/pgp0.pgp Description: PGP signature
[Samba] Re: Samba PDCs/BDCs and Trusts WAS: auth to two diff PDCs? (succe ss, sort of)
On Tue, Oct 29, 2002 at 09:45:26AM -0500, Collins, Kevin wrote: But, I can also see that I may not *need* the independent PDCs that trust each other, but maybe a PDC and 2 BDCs. I'm looking hard at the latter just so I do not hit any major hurdles when moving to SAMBA. Thinking along those lines I must pose the question: Will a SAMBA BDC function as an NT BDC in that an NT BDC will cache (i.e. store locally) user/group/SID information and only update/sync with the PDC at a specified intervals? Having one PDC and two BDCs also gives you greater fault-tolerance than having three domains with a single PDC each. Samba+LDAP can give you this fault tolerance; it can't give you trust relationships today, without a lot of finagling. Steve Langasek postmodern programmer msg07307/pgp0.pgp Description: PGP signature
Re: [PATCH] security hole in Samba 3.0 start tls handling
On Wed, Oct 30, 2002 at 10:15:46AM +1100, Andrew Bartlett wrote: It appears that in Samba 3.0, the meaning of ldap ssl = start tls is somewhat diluted. First, the start tls command is only ever issued if the given ldapsam URI has a protocol string of ldaps://, which is definitely an issue -- TLS is quite a different protocol from SSL, and the whole point of TLS is to NOT use a separate port for SSL connections. Second, the STARTTLS support is completely disabled if using newer versions of the OpenLDAP client libs, resulting in the ldap ssl option being *silently* ignored to the detriment of SAM security. A workaround for existing systems is to use ldaps instead of tls. The attached patch against SAMBA_3_0 will add support for STARTTLS when using OpenLDAP libs. The muddled interaction between TLS and SSL is not addressed. Hmm - I had hoped that we could specify as much information in that URL as possible... Is there no way to indicate this in the URL? No, no more than you can indicate SASL preferences in a URL. You *could* embed this information in a URI string, but there would be nothing particularly standard about this, and the LDAP libraries are unlikely to understand them -- so Samba will still have to parse these components out of the URL and handle them directly. Steve Langasek postmodern programmer msg04134/pgp0.pgp Description: PGP signature
Re: Samba PDCs/BDCs and Trusts WAS: auth to two diff PDCs? (succe ss, sort of)
On Tue, Oct 29, 2002 at 11:10:22AM -0500, Collins, Kevin wrote: Steven Langasek wrote: Having one PDC and two BDCs also gives you greater fault-tolerance than having three domains with a single PDC each. Samba+LDAP can give you this fault tolerance; it can't give you trust relationships today, without a lot of finagling. Steve Langasek postmodern programmer I understand the role of/need for the BDC, I'm just concerned about flooding the WAN connections with replication traffic and not being able to send things like e-mail or project files. I can control the replication in NT, but I need to know if I can do the same in SAMBA. With all the tweaks god knows there should be. :-) The only pre-packaged BDC implementation for Samba that I know of is based on LDAP. With LDAP, only changes are replicated across the link, so you have no excess traffic associated with keeping the DCs in sync. Samba sorta skipped over the NT4 technology and went straight to an ActiveDirectory approach to management... :) I've thought about the LDAP course too but haven't given it enough serious thought yet. You know of a good HOWTO? There is a Samba-PDC-LDAP HOWTO included with the Samba documentation. You can also find Ignacio Coupeau's step-by-step guide at http://www.unav.es/cti/ldap-smb/ldap-smb-2_2-howto.html. Steve Langasek postmodern programmer msg04148/pgp0.pgp Description: PGP signature
Re: [Samba] Re: How Samba let us down
On Fri, Oct 25, 2002 at 01:44:03PM +1000, Matthew Hannigan wrote: Well, my specific example (which I noticed you avoided :-) was two sambas sharing the same files: You're not alone, everyone is ducking this question :-) Here it is again, just in case: Excellent, so two otherwise separate Sambas, say, with oplocking off and strict locking on would play nicely together if sharing the same files. If oplock support is disabled, yes, you can expect two Samba installations to play nicely with locks on the same set of files. If oplocking is enabled, it might also be possible to make them behave, though this would at least require some symlink magic. Steve Langasek postmodern programmer msg07087/pgp0.pgp Description: PGP signature
Re: [Samba] Re: How Samba let us down
On Fri, Oct 25, 2002 at 11:04:43AM +1000, Matthew Hannigan wrote: On Thu, Oct 24, 2002 at 10:44:28AM -0500, Steve Langasek wrote: On Thu, Oct 24, 2002 at 01:08:10PM +1000, Matthew Hannigan wrote: And Solaris? At least they're autoconfigured to assume kernel oplocks according to testparm, and the docs say this is done only if the support is there. smb.conf(5): kernel oplocks (G) [...] This parameter defaults to on, but is translated to a no-op on systems that no not have the necessary kernel support. You should never need to touch this parameter. Ok, thanks I should have read more closely. May I respectfully suggest that this is forced off for those Unices without kernel support rather than silently ineffective? Ah, but it doesn't really matter *what* the value of kernel oplocks is, if you don't have kernel support for oplocks. :) The only other option would be to have oplocks completely disabled by default if kernel support is absent. I'm not sure this is justified, given that it's only an issue if you have multiple applications competing for a file without knowing anything about one another's locking conventions -- pretty bad situation to be in, no matter what... Steve Langasek postmodern programmer msg07112/pgp0.pgp Description: PGP signature
segfaults in pam_smbpass in SAMBA_3_0 with unixsam backend
Currently, pam_smbpass calls initialize_password_db() with reload == True
on every pass through the module. This is supposedly the Right Thing
for the code to do, but recently the reload option took on actual
meaning, and now pam_smbpass segfaults on the second pass when using
the unixsam backend. :)
The problem is in pdb_interfaces.c:
static void free_pdb_context(struct pdb_context **context)
{
struct pdb_methods *pdb_selected = (*context)-pdb_methods;
while (pdb_selected){
pdb_selected-free_private_data((pdb_selected-private_data));
pdb_selected = pdb_selected-next;
}
talloc_destroy((*context)-mem_ctx);
*context = NULL;
}
The nisplus and unixsam backends do not initialize the free_private_data
method. Do these need to be implemented yet, or should they be stubbed
off and have error checking added to free_pdb_context() to check for a
null pointer?
Steve Langasek
postmodern programmer
msg03927/pgp0.pgp
Description: PGP signature
Re: segfaults in pam_smbpass in SAMBA_3_0 with unixsam backend
On Fri, Oct 25, 2002 at 02:39:16AM +0200, Jelmer Vernooij wrote:
On Thu, Oct 24, 2002 at 06:51:38PM -0500, Steve Langasek wrote about 'segfaults in
pam_smbpass in SAMBA_3_0 with unixsam backend':
Currently, pam_smbpass calls initialize_password_db() with reload == True
on every pass through the module. This is supposedly the Right Thing
for the code to do, but recently the reload option took on actual
meaning, and now pam_smbpass segfaults on the second pass when using
the unixsam backend. :)
The nisplus and unixsam backends do not initialize the free_private_data
method. Do these need to be implemented yet, or should they be stubbed
off and have error checking added to free_pdb_context() to check for a
null pointer?
Fixed. (Needed to check for a null pointer, as happens in all other passdb
functions)
Thanks for reporting!
And thanks for the quick fix. There's still a problem in the nisplus
backend, I believe; a chunk of private_data is allocated but never
freed. Fortunately, this is a mere memory leak, and not a segfault. :)
Steve Langasek
postmodern programmer
Index: pdb_nisplus.c
===
RCS file: /cvsroot/samba/source/passdb/pdb_nisplus.c,v
retrieving revision 1.22.2.4
diff -u -r1.22.2.4 pdb_nisplus.c
--- pdb_nisplus.c 26 Sep 2002 18:58:15 - 1.22.2.4
+++ pdb_nisplus.c 25 Oct 2002 00:07:50 -
-1507,6 +1507,19
return result;
}
+static void free_private_data(void **vp)
+{
+ struct nisplus_private_info **private = (struct nisplus_private_info **)vp;
+
+ if ((*private)-result) {
+ nis_freeresult ((*private)-result);
+ }
+
+ free(*private);
+
+/* No need to free any further, as it is talloc()ed */
+}
+
NTSTATUS pdb_init_nisplussam (PDB_CONTEXT * pdb_context,
PDB_METHODS ** pdb_method, const char *location)
{
-1535,6 +1548,7
(*pdb_method)-add_sam_account = nisplussam_add_sam_account;
(*pdb_method)-update_sam_account = nisplussam_update_sam_account;
(*pdb_method)-delete_sam_account = nisplussam_delete_sam_account;
+ (*pdb_method)-free_private_data = free_private_data;
(*pdb_method)-private_data = private;
return NT_STATUS_OK;
msg03933/pgp0.pgp
Description: PGP signature
Re: segfaults in pam_smbpass in SAMBA_3_0 with unixsam backend
On Fri, Oct 25, 2002 at 04:39:58AM +0200, Jelmer Vernooij wrote: And thanks for the quick fix. There's still a problem in the nisplus backend, I believe; a chunk of private_data is allocated but never freed. Fortunately, this is a mere memory leak, and not a segfault. :) It's in, thanks! If you do have a nisplus server there, could you re-check whether nisplussam works 100% correctly? I converted it to the new passdb interface at CIFS this summer, but I haven't been able to test it since I don't have a nisplus server around. Afraid I don't... was just looking over the code, and noticed that nisplus would have the same problem that unixsam would. Steve Langasek postmodern programmer msg03935/pgp0.pgp Description: PGP signature
Re: [Samba] Re: How Samba let us down
On Thu, Oct 24, 2002 at 01:08:10PM +1000, Matthew Hannigan wrote: On Thu, Oct 24, 2002 at 02:10:14AM +, [EMAIL PROTECTED] wrote: On Wed, Oct 23, 2002 at 09:02:03PM -0500, Steve Langasek wrote: On Thu, Oct 24, 2002 at 11:38:55AM +1000, Matthew Hannigan wrote: I have read in the docs that Samba locks and Unix locks _DO_ notice each other, with the caveats that Unix lock daemons are sometimes buggy and that Unix locks can only lock the first 2^31 bytes of a file. Please tell me that they do in fact notice each other. Oplocks are not part of the traditional lock semantics available on Unix. If you aren't running a kernel (Irix or Linux) that implements And Solaris? At least they're autoconfigured to assume kernel oplocks according to testparm, and the docs say this is done only if the support is there. smb.conf(5): kernel oplocks (G) [...] This parameter defaults to on, but is translated to a no-op on systems that no not have the necessary kernel support. You should never need to touch this parameter. oplocks, you MUST NOT use oplocks if the files will be accessed by applications other than Samba. Don't confure the two. Oplocks are nothing to do with share modes or byte range locks. They're just unfortunately named. I'll try not to confuse the two :-) So 'oplocks' and real locks are or are not noticed by other unix processes? Real locks are always implemented using the available Unix facilities for such, so any Unix app that implements locking properly will see the Samba locks. Note the hedging here: there are many different historical locking mechanisms available on Unix, some of which are invisible to one another; witness the myriad methods available for locking password files and mail spools. So if you have a Unix app that's doing locking *badly*, it can cause problems for Samba connections just as it can cause problems for any other Unix app. OTOH, oplocks (which are not actually locks at all; more like motion detectors) were first implemented on Unix within Samba itself. Given the obvious advantages of having smooth interaction between Samba and other Unix apps when using oplocks, efforts soon began to push oplocks into the kernel -- first with Irix, later Linux, and ISTR that one or more of the BSD kernels had someone working on implementing oplock support. I did have a look at the docs really, but textdocs/UNIX-SMB.txt for instance says that Unix has no simple way of implementing opportunistic locking, and currently Samba has no support for it. Heh... Whoops. :) Replies of the form read the source Luke! are ok; at least I'll know to stop searching elswhere. I don't know anywhere better than the source, but maybe it's covered in one of the many good Samba books currently available? FWIW, everything I know about Samba locking came from the samba-technical mailing list, but reading the archive in its entirety may not serve you better than reading the source. ;) Steve Langasek postmodern programmer msg04056/pgp0.pgp Description: PGP signature
Re: [Samba] Re: How Samba let us down
On Fri, Oct 25, 2002 at 11:04:43AM +1000, Matthew Hannigan wrote: On Thu, Oct 24, 2002 at 10:44:28AM -0500, Steve Langasek wrote: On Thu, Oct 24, 2002 at 01:08:10PM +1000, Matthew Hannigan wrote: And Solaris? At least they're autoconfigured to assume kernel oplocks according to testparm, and the docs say this is done only if the support is there. smb.conf(5): kernel oplocks (G) [...] This parameter defaults to on, but is translated to a no-op on systems that no not have the necessary kernel support. You should never need to touch this parameter. Ok, thanks I should have read more closely. May I respectfully suggest that this is forced off for those Unices without kernel support rather than silently ineffective? Ah, but it doesn't really matter *what* the value of kernel oplocks is, if you don't have kernel support for oplocks. :) The only other option would be to have oplocks completely disabled by default if kernel support is absent. I'm not sure this is justified, given that it's only an issue if you have multiple applications competing for a file without knowing anything about one another's locking conventions -- pretty bad situation to be in, no matter what... Steve Langasek postmodern programmer msg04067/pgp0.pgp Description: PGP signature
[Samba] Re: How Samba let us down
On Wed, Oct 23, 2002 at 05:25:56AM -0700, Jay Ts wrote: kernel oplocks are for synchronizing SMB clients and local Unix processes. If you have no processes on linux accessing the files, then it's probably safe to disable them. But, if you are using Linux, the only way you should have kernel oplocks enabled in the first place is if you have installed the kernel ACL patch, or are running XFS filesystem. Some newer distributions come with the ACL patch installed, I think. What version of Linux are you running? Kernel oplock support is orthogonal to ACL support. Kernel oplocks are supported by the mainline 2.4 Linux kernels. It is true that you only need kernel oplocks if the files will be accessed from both Samba and other Linux apps. It's also the case that some Linux kernels had buggy kernel oplock support (I don't remember which kernels, specifically). It may help to turn kernel oplock support off. I would not turn off oplock support itself without a stronger indicator that it's the source of the trouble, since oplocks normally *improve* performance. Steve Langasek postmodern programmer msg06339/pgp0.pgp Description: PGP signature
Re: [Samba] Re: How Samba let us down
On Thu, Oct 24, 2002 at 11:38:55AM +1000, Matthew Hannigan wrote: On Wed, Oct 23, 2002 at 02:14:41PM -0700, Marc Jacobsen wrote: [ ... ] Similarly, record locks and share mode locks from SMB clients are both ignored by NFS clients/other UNIX processes (with the possible exception of newer Linux systems, they might actually enforce share mode locks). In theory this could also cause corruption, although in practice it is almost never an issue. I have read in the docs that Samba locks and Unix locks _DO_ notice each other, with the caveats that Unix lock daemons are sometimes buggy and that Unix locks can only lock the first 2^31 bytes of a file. Please tell me that they do in fact notice each other. Oplocks are not part of the traditional lock semantics available on Unix. If you aren't running a kernel (Irix or Linux) that implements oplocks, you MUST NOT use oplocks if the files will be accessed by applications other than Samba. Steve Langasek postmodern programmer msg06403/pgp0.pgp Description: PGP signature
Re: How Samba let us down
On Wed, Oct 23, 2002 at 05:52:47AM -0700, Jay Ts wrote: If that is the case, then it's important to let the PDC handle both domain master browser and local master browser tasks, and not ever let any system steal either role away from it (or else bad things can happen). I've heard this claim rather frequently, but can anyone tell me what actually *breaks* when the PDC is not a local master browser? The connection between a PDC and a DMB is obvious at the protocol level, but there is no such connection between the PDC and the LMB; indeed, our Samba PDC is rarely the LMB for its subnet, and it's *never* caused us a problem. Is there actually a limitation in NT that causes brokenness if it doesn't win the browser election, and if so, has anyone documented what happens? Steve Langasek postmodern programmer msg03756/pgp0.pgp Description: PGP signature
Re: [Samba] Re: How Samba let us down
On Thu, Oct 24, 2002 at 11:38:55AM +1000, Matthew Hannigan wrote: On Wed, Oct 23, 2002 at 02:14:41PM -0700, Marc Jacobsen wrote: [ ... ] Similarly, record locks and share mode locks from SMB clients are both ignored by NFS clients/other UNIX processes (with the possible exception of newer Linux systems, they might actually enforce share mode locks). In theory this could also cause corruption, although in practice it is almost never an issue. I have read in the docs that Samba locks and Unix locks _DO_ notice each other, with the caveats that Unix lock daemons are sometimes buggy and that Unix locks can only lock the first 2^31 bytes of a file. Please tell me that they do in fact notice each other. Oplocks are not part of the traditional lock semantics available on Unix. If you aren't running a kernel (Irix or Linux) that implements oplocks, you MUST NOT use oplocks if the files will be accessed by applications other than Samba. Steve Langasek postmodern programmer msg03810/pgp0.pgp Description: PGP signature
Re: Consistency in parameter names?
On Wed, Oct 23, 2002 at 08:22:07PM -0700, Jay Ts wrote: On Thu, Oct 24, 2002 at 11:04:16AM +0930, Richard Sharpe wrote: We have: add user script add group script add machine script ... delete user script logon script magic script and add share command add printer command ? I noticed it too. Ideally, (with the exception of logon script) I think they should all use command rather than script, because AFAIK, they all can work with compiled programs as well as interpreted scripts. Samba doesn't care, it just execs the command with arguments, right? If not, I'd really like to know! The reasoning I've heard for delete user script being called script instead of command is that it's BAD to point this at something like adduser without a certain amount of error checking... doesn't stop some of us, though. :) Steve Langasek postmodern programmer msg03816/pgp0.pgp Description: PGP signature
[PATCH] security hole in Samba 3.0 start tls handling
It appears that in Samba 3.0, the meaning of ldap ssl = start tls is
somewhat diluted. First, the start tls command is only ever issued if
the given ldapsam URI has a protocol string of ldaps://, which is
definitely an issue -- TLS is quite a different protocol from SSL, and
the whole point of TLS is to NOT use a separate port for SSL
connections. Second, the STARTTLS support is completely disabled if
using newer versions of the OpenLDAP client libs, resulting in the
ldap ssl option being *silently* ignored to the detriment of SAM
security.
A workaround for existing systems is to use ldaps instead of tls. The
attached patch against SAMBA_3_0 will add support for STARTTLS when
using OpenLDAP libs. The muddled interaction between TLS and SSL is
not addressed.
Steve Langasek
postmodern programmer
Index: passdb/pdb_ldap.c
===
RCS file: /cvsroot/samba/source/passdb/pdb_ldap.c,v
retrieving revision 1.28.2.5
diff -u -w -r1.28.2.5 pdb_ldap.c
--- passdb/pdb_ldap.c 1 Oct 2002 13:10:57 - 1.28.2.5
+++ passdb/pdb_ldap.c 23 Oct 2002 02:13:41 -
-184,6 +184,17
}
}
+ if (lp_ldap_ssl() == LDAP_SSL_START_TLS) {
+ int rc;
+
+ if ((rc = ldap_start_tls_s (*ldap_struct, NULL, NULL)) != LDAP_SUCCESS)
+ {
+ DEBUG(0,(Failed to issue the StartTLS instruction: %s\n,
+ldap_err2string(rc)));
+ return False;
+ }
+ DEBUG (2, (StartTLS issued: using a TLS connection\n));
+ }
#else
/* Parse the string manually */
msg03889/pgp0.pgp
Description: PGP signature
Re: smbpasswd replication
On Fri, Oct 11, 2002 at 02:18:48PM +1000, richard wrote: my first thoughts too. but to synchronise the data to and from 6 samba servers I need to real careful...example: rsync -au local_file 1.2.3.4:remote_file will sync the entire contents of the file. If another user happens to changing their password on the destination pc at this moment they get overwritten, we have a replicated mess. I think by replicating single user changes only at one time there is much reduced chance of trouble. Hopefully a simple reliable system without the complication of ldap etc.. I don't know if anyone has already tried this? Richard. Such a system would be neither simple, nor reliable; it would still be possible for changes to be made on two machines to one account in the same rsync window, resulting in one set of changes being lost. It is much simpler to designate a master server (a PDC) that all update requests are sent to, then use rsync to propogate the master file out to other servers. Steve Langasek postmodern programmer msg03657/pgp0.pgp Description: PGP signature
Re: PS: smbcacl doesn't work for me
Zoltan, On Sat, Oct 05, 2002 at 05:49:45PM +0200, Zoltan Bogdan wrote: Unfortunately escaping didn't work either - so you're probably right assuming that names are not supported. Do you know where I get the hex code for the NT-ACLs ? I don't know of anywhere to find these other than in the Samba source, sorry. Steve Langasek postmodern programmer msg03539/pgp0.pgp Description: PGP signature
Re: PS: smbcacl doesn't work for me
On Fri, Oct 04, 2002 at 06:48:55PM +0200, Zoltan Bogdan wrote: Am Don, 2002-10-03 um 23.43 schrieb Zoltan Bogdan: Hi, I share an XFS-volume via samba 2.2.4. fetching the acls works like the following for me: hermes:/secrets # smbcacls //hermes/xfs-share test -U TOGO/hzbogdan Password: REVISION:1 OWNER:TOGO\hzbogdan GROUP:TOGO\users ACL:TOGO\hzbogdan:ALLOWED//RW ACL:TOGO\users:ALLOWED//R ACL:\Everyone:ALLOWED//R - When I try to set - or rather modify - the Acl for the group users, I get strange results: - hermes:/secrets # smbcacls //hermes/xfs-share test -U TOGO/hzbogdan -M ACL:TOGO\users:0/0/W Password: Failed to parse ACL ACL:TOGOusers Using various substitutions for type/flags/mask Values didn't get better results. Could someone provide some help? You haven't escaped your strings to make them shell-safe. The shell eats the backslash, and smbcacls only sees 'ACL:TOGOusers' instead of 'ACL:TOGO\users'. I also don't know for sure if names in ACLs are supported by smbcacls in 2.2. If so, you definitely need to handle that backslash: smbcacls //hermes/xfs-share test -U TOGO/hzbogdan -M ACL:TOGO\\users:0/0/W or smbcacls //hermes/xfs-share test -U TOGO/hzbogdan -M 'ACL:TOGO\users:0/0/W' HTH, Steve Langasek postmodern programmer msg03521/pgp0.pgp Description: PGP signature
[jonas@gnu.org: Bug#162956: libsmbclient-dev: libsmbclient.h doesn't work without client.h]
I imagine those who favor the use of libsmbclient might be interested to know that the header files are currently in disarray. I've verified that this is also a problem in 3.0alpha20. Should libsmbclient.h duplicate the functionality of client.h, or does client.h need to be pulled in as a dependency of libsmbclient.h? Steve Langasek postmodern programmer - Forwarded message from Jonas Öberg [EMAIL PROTECTED] - Subject: Bug#162956: libsmbclient-dev: libsmbclient.h doesn't work without client.h Reply-To: Jonas Öberg [EMAIL PROTECTED], [EMAIL PROTECTED] Resent-From: Jonas Öberg [EMAIL PROTECTED] Original-Sender: Jonas Oberg [EMAIL PROTECTED] Resent-To: [EMAIL PROTECTED] Resent-CC: [EMAIL PROTECTED] (Eloy A. Paris), [EMAIL PROTECTED] Resent-Date: Tue, 01 Oct 2002 07:48:01 GMT Resent-Message-Id: [EMAIL PROTECTED] X-Debian-PR-Message: report 162956 X-Debian-PR-Package: libsmbclient-dev X-Debian-PR-Keywords: Received: via spool by [EMAIL PROTECTED] id=B.103345760724642 (code B ref -1); Tue, 01 Oct 2002 07:48:01 GMT From: Jonas Öberg [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Date: Tue, 01 Oct 2002 09:33:23 +0200 Resent-Sender: Debian BTS [EMAIL PROTECTED] X-PTS-Package: samba X-PTS-Keyword: bts X-Unsubscribe: echo 'unsubscribe samba' | mail [EMAIL PROTECTED] X-pstn-levels: (C:75.3595 M:97.0754 P:95.9108 S:26.9476 ) X-pstn-settings: 3 (1.:2.) pmCr X-pstn-addresses: from [EMAIL PROTECTED] forward (good recip) X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Package: libsmbclient-dev Version: 2.999+3.0cvs20020906-1 Severity: grave Justification: renders package unusable When I recently did an upgrade of the system, a new libsmbclient was installed that introduced a problem, namely that libsmbclient.h (line 199) accessed a structure called cli_state. This structure is not defined anywhere, which causes compilation to fail when using libsmbclient.h. When looking around, it appears that this structure is defined in client.h, however, I can not find this file in any other Debian package either. If I use a client.h from the samba source package, this introduces additional requirements, so all in all, I'd think that libsmbclient-dev ought to include several more header files, or the appropriate definitions inserted into libsmbclient.h :-) -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux fiona 2.4.19 #2 SMP Tue Sep 3 08:17:02 CEST 2002 i686 Locale: LANG=C, LC_CTYPE=sv_SE.ISO8859-1 Versions of packages libsmbclient-dev depends on: ii libsmbclient 2.999+3.0cvs20020906-1 Shared library that allows applica -- no debconf information - End forwarded message - msg03500/pgp0.pgp Description: PGP signature
Re: --wuth-tdbsam ?
On Thu, Sep 26, 2002 at 09:20:19PM +0200, Jelmer Vernooij wrote: On Thu, Sep 26, 2002 at 09:14:39PM +0200, Jean Francois Micouleau wrote about 'Re: --wuth-tdbsam ?': On Thu, 26 Sep 2002, Gerald (Jerry) Carter wrote: Anyone? Why do we still have a configure flag for this since it is selectable at run time ? I guees it used to be optional since we didn't want to compile in unstable code. and tdbsam should be the default passdb backend in 3.0. We should remove the smbpasswd file and provide a migration script. 'pdbedit -i smbpasswd -e tdbsam' does exactly that.. now we only need to document it :-) Is pdb importing from smbpasswd going to be fixed first so that everyone's passwords don't expire 12 days after they upgrade? :) Steve Langasek postmodern programmer msg03275/pgp0.pgp Description: PGP signature
Re: --wuth-tdbsam ?
On Thu, Sep 26, 2002 at 11:29:51PM +0200, Jelmer Vernooij wrote: On Thu, Sep 26, 2002 at 03:30:44PM -0500, Steve Langasek wrote about 'Re: --wuth-tdbsam ?': and tdbsam should be the default passdb backend in 3.0. We should remove the smbpasswd file and provide a migration script. 'pdbedit -i smbpasswd -e tdbsam' does exactly that.. now we only need to document it :-) Is pdb importing from smbpasswd going to be fixed first so that everyone's passwords don't expire 12 days after they upgrade? :) PDB importing should work.. Meaning that this bug has already been fixed? I haven't tried it in over a month now; no one tells me when these things are fixed, only when they're broken... :D Steve Langasek postmodern programmer msg03283/pgp0.pgp Description: PGP signature
Re: --with-libsmbclient=no the default ?
On Fri, Sep 27, 2002 at 11:28:38AM +1000, Andrew Bartlett wrote: Gerald (Jerry) Carter wrote: On Thu, 26 Sep 2002, Jelmer Vernooij wrote: On Thu, Sep 26, 2002 at 02:20:06PM -0500, Gerald (Jerry) Carter wrote about '--with-libsmbclient=no the default ?': I thought libsmbclient should be built by default in 3.0 ? When ( why) did this change ? Was it me ? According to configure.in, it is build by default if the OS has support for shared libraries. That's what I though, but it didn't build on my last check. I'll go back and see why not It's not in the 'all' target. I had to move to 'make everything' to get the build farm to do it. When you get to 'make universe', you know it's time to rethink your naming schemes for Makefile targets. ;) Steve Langasek postmodern programmer msg03290/pgp0.pgp Description: PGP signature
Re: --wuth-tdbsam ?
On Fri, Sep 27, 2002 at 11:18:01AM +1000, Andrew Bartlett wrote: On Thu, Sep 26, 2002 at 09:20:19PM +0200, Jelmer Vernooij wrote: On Thu, Sep 26, 2002 at 09:14:39PM +0200, Jean Francois Micouleau wrote about 'Re: --wuth-tdbsam ?': On Thu, 26 Sep 2002, Gerald (Jerry) Carter wrote: Anyone? Why do we still have a configure flag for this since it is selectable at run time ? I guees it used to be optional since we didn't want to compile in unstable code. and tdbsam should be the default passdb backend in 3.0. We should remove the smbpasswd file and provide a migration script. 'pdbedit -i smbpasswd -e tdbsam' does exactly that.. now we only need to document it :-) Is pdb importing from smbpasswd going to be fixed first so that everyone's passwords don't expire 12 days after they upgrade? :) The problem isn't actually tdbsam, it's smbpasswd. Smbpasswd is giving out dodgy made up values. See, we have a policy database that stores the 'max password age' etc, but we don't do 'last change time + max password age = must change time' yet. I was going to do that, but with a default value of 21 days, it would lock a lot of people out (who would certainly not be expecting it). Well, the users aren't going to care /where/ the problem lies if they upgrade and find that the defaults cause them to start being locked out of their accounts... :) The fact is that if tdbsam is going to become the default and preferred backend, users are going to need some way to sanely migrate from smbpasswd to tdbsam. Really, people have been using smbpasswd on the assumption that 'password does not expire' was implicity set. Possibly having an easy tool to set that on every account might be a good idea, but I'm just not sure. So then, doesn't it make sense to treat smbpasswd entries as if password does not expire is set as part of the smbpasswd pdb interface? Why change the semantics of the smbpasswd entry unnecessarily? Steve Langasek postmodern programmer msg03292/pgp0.pgp Description: PGP signature
Re: samba cause kernel panic on my server !
On Wed, Sep 25, 2002 at 11:37:12AM -0500, Eloy A. Paris wrote: We are not aware of any problems in the Debian Samba packages that could cause a kernel Oops. And I don't see how smbd could cause a kernel Oops. Maybe there is a kernel bug here? What kernel version are you running? Maybe Vorlon has some suggestions. Vorlon? Definitely a kernel bug or a hardware bug. I would suggest upgrading to the latest kernel in whichever (2.2,2.4) series you're running, if you haven't already done so, and seeing if that fixes the problem. If it doesn't, you probably need to talk to the Linux kernel developers about this, or perhaps try to test it on a different set of hardware. Steve Langasek postmodern programmer On Wed, Sep 25, 2002 at 02:41:30PM +, Eric Belhomme wrote: hi, I installed and configured on my GNU/linux Debian Woody the official Debian binary package of samba (2.2.3a-6). Its configuration is viewable here : http://www.ricospirit.net/phpsysinfo This server is on a workgroup with Windows 2000 Pro workstations with SP2. My problem is when I copy big files on my stockage share (more than 500Mb per file) from the win2k workstation, smbd causes a kernel panic and my server I completely crashed :( My smb.conf file is here : http://www.ricospirit.net/temp/smb.conf.txt And my system log is here : http://www.ricospirit.net/temp/crash.txt I have no idea about the cause, so I hope someone here will be able to give me some pointer... Best regards, msg00103/pgp0.pgp Description: PGP signature
Re: 'hostname lookups' in Samba HEAD
On Sun, Sep 08, 2002 at 04:21:02PM -0500, Steve Langasek wrote:
After a bit of research, I've uncovered the new 'hostname lookups' option
in Samba HEAD. I understand the value of being able to configure this
setting, and of having it default to 'no' to conserve resources; however,
this setting also (unnecessarily, IMHO) breaks the config of anyone using
hostname-based access lists on upgrade.
Would it be acceptable to add a 'hostname lookups = auto' option as the
default, which checks the 'hosts allow' and 'hosts deny' lists for
hostname tokens, and makes its decision based on these other two config
options? Having hostname lookups unexpectedly turned off can not only
block access from legitimate users, it can also be a security hole.
Discussing this some on IRC, it seems it may be better to decouple hosts
allow/deny from 'hostname lookups' altogether, since an 'auto' value
would cause the value of the %M macro to change depending on the contents
of 'hosts allow' and 'hosts deny'. Attached is a patch which adds a
'force_lookup' option to the get_socket_name() function, permitting
lib/access.c:check_access() to always retrieve the real hostname if
needed.
Steve Langasek
postmodern programmer
Index: lib/access.c
===
RCS file: /cvsroot/samba/source/lib/access.c,v
retrieving revision 1.33
diff -u -w -r1.33 access.c
--- lib/access.c14 Jun 2002 02:06:58 - 1.33
+++ lib/access.c8 Sep 2002 23:39:15 -
-316,20 +316,20
else
{
DEBUG (3, (check_access: hostnames in host allow/deny
list.\n));
- ret = allow_access(deny_list,allow_list, get_socket_name(sock),
+ ret = allow_access(deny_list,allow_list,
+get_socket_name(sock,True),
get_socket_addr(sock));
}
if (ret)
{
DEBUG(2,(Allowed connection from %s (%s)\n,
-only_ip ? : get_socket_name(sock),
+only_ip ? : get_socket_name(sock,True),
get_socket_addr(sock)));
}
else
{
DEBUG(0,(Denied connection from %s (%s)\n,
-only_ip ? : get_socket_name(sock),
+only_ip ? : get_socket_name(sock,True),
get_socket_addr(sock)));
}
}
Index: lib/util_sock.c
===
RCS file: /cvsroot/samba/source/lib/util_sock.c,v
retrieving revision 1.66
diff -u -w -r1.66 util_sock.c
--- lib/util_sock.c 8 Jul 2002 02:14:57 - 1.66
+++ lib/util_sock.c 8 Sep 2002 23:39:15 -
-832,7 +832,7
char *client_name(void)
{
- return get_socket_name(client_fd);
+ return get_socket_name(client_fd,False);
}
char *client_addr(void)
-890,7 +890,7
/***
return the DNS name of the remote end of a socket
**/
-char *get_socket_name(int fd)
+char *get_socket_name(int fd, BOOL force_lookup)
{
static pstring name_buf;
static fstring addr_buf;
-902,7 +902,7
situations won't work because many networks don't link dhcp
with dns. To avoid the delay we avoid the lookup if
possible */
- if (!lp_hostname_lookups()) {
+ if (!lp_hostname_lookups() (force_lookup == False)) {
return get_socket_addr(fd);
}
Index: web/cgi.c
===
RCS file: /cvsroot/samba/source/web/cgi.c,v
retrieving revision 1.59
diff -u -w -r1.59 cgi.c
--- web/cgi.c 25 Jun 2002 02:29:09 - 1.59
+++ web/cgi.c 8 Sep 2002 23:39:16 -
-636,7 +636,7
char *cgi_remote_host(void)
{
if (inetd_server) {
- return get_socket_name(1);
+ return get_socket_name(1,False);
}
return getenv(REMOTE_HOST);
}
msg02957/pgp0.pgp
Description: PGP signature
Re: Variable MACHINE.SID
On Mon, Aug 05, 2002 at 03:31:54AM +0930, Richard Sharpe wrote: On Sun, 4 Aug 2002, Pablo Alcaraz wrote: I wish that a box can run alternatively 2 samba server configuration (smb_a y smb_b). For this I have 2 smb.conf files (smb.conf.a and smb.conf.b). When I need smb_a I rename smb.conf.a = smb.conf and restart samba. The same thing for smb_b. The problem is that my configuration set 'server = domain' and one configuration run ok inside of domain and the other does not run (samba ask for manual login). I suspect that the problem is MACHINE.SID. I think I need 2 different MACHINE.SID files. Is that correct? Can I use samba %L variable to indicate a differente MACHINE.SID? There is no way to control where that goes, I believe ... Does the MACHINE.SID file dependent of the hardware of the server? If Samba finds an existing MACHINE.SID, I believe it uses that. You cannot have two system on the network with the same machine SID. However, I do not believe there is a parameter that allows you to control where Samba will look for this stuff. passdb/machine_sid.c: /* check for an old MACHINE.SID file for backwards compatibility */ asprintf(fname, %s/MACHINE.SID, lp_private_dir()); so adjusting the setting of 'private dir' in smb.conf should do it. (This will also work for versions of Samba that use secrets.tdb, which is also found relative to 'private dir'.) Steve Langasek postmodern programmer msg02398/pgp0.pgp Description: PGP signature
Re: pam_smbpass and LDAP - part two....
On Thu, Aug 01, 2002 at 04:22:17PM +0200, Bartlomiej Solarz-Niesluchowski wrote: Good morning! When I changing openssl library in redhat 7.3 from version 0.9.6b-18 to 0.9.6b-24 module pam_smbpass has problems: Aug 1 13:07:23 portraits sshd[1082]: PAM unable to dlopen(/lib/security/pam_ldap.so) Aug 1 13:07:23 portraits sshd[1082]: PAM [dlerror: /lib/libssl.so.2: undefined symbol: OpenSSLDie] Aug 1 13:07:23 portraits sshd[1082]: PAM adding faulty module: /lib/security/pam_ldap.so Aug 1 13:07:23 portraits sshd[1082]: PAM unable to dlopen(/lib/security/pam_smbpass.so) Aug 1 13:07:23 portraits sshd[1082]: PAM [dlerror: /lib/libssl.so.2: undefined symbol: OpenSSLDie] Aug 1 13:07:23 portraits sshd[1082]: PAM adding faulty module: /lib/security/pam_smbpass.so Aug 1 13:07:23 portraits sshd[1082]: PAM rejected by account configuration[28]: Module is unknown On my system, the 'OpenSSLDie' function is provided by libcrypto, and libssl depends on libcrypto. You probably need to add '-lcrypto' to whatever line has '-lssl' on it. Steve Langasek postmodern programmer msg02338/pgp0.pgp Description: PGP signature
unresolved symbols in pam_smbpass (again)
It appears that pam_smbpass is once again broken in HEAD, due to unresolved symbols. The attached diff attempts a somewhat more permanent solution to the problem. Cheers, Steve Langasek postmodern programmer Index: Makefile.in === RCS file: /cvsroot/samba/source/Makefile.in,v retrieving revision 1.501 diff -u -w -r1.501 Makefile.in --- Makefile.in 29 Jul 2002 09:26:38 - 1.501 +++ Makefile.in 2 Aug 2002 03:43:01 - -454,16 +454,9 PAM_SMBPASS_OBJ_0 = pam_smbpass/pam_smb_auth.o pam_smbpass/pam_smb_passwd.o \ pam_smbpass/pam_smb_acct.o pam_smbpass/support.o \ - lib/debug.o lib/util_sid.o lib/messages.o lib/util_str.o \ - lib/wins_srv.o lib/substitute.o lib/select.o lib/util.o \ - nsswitch/wb_client.o nsswitch/wb_common.o \ - lib/system.o lib/util_file.o \ - lib/genrand.o lib/username.o lib/util_getent.o lib/charcnv.o lib/time.o \ - lib/md4.o lib/util_unistr.o lib/signal.o lib/talloc.o \ - lib/ms_fnmatch.o lib/util_sock.o lib/smbrun.o \ - lib/util_sec.o lib/snprintf.o \ - ubiqx/ubi_sLinkList.o libsmb/smbencrypt.o libsmb/smbdes.o \ - $(PARAM_OBJ) $(TDB_OBJ) $(PASSDB_OBJ) + libsmb/smbencrypt.o libsmb/smbdes.o libsmb/nterr.o \ + $(PARAM_OBJ) $(LIB_OBJ) $(PASSDB_OBJ) $(GROUPDB_OBJ) \ + $(SECRETS_OBJ) $(UBIQX_OBJ) PAM_SMBPASS_PICOOBJ = $(PAM_SMBPASS_OBJ_0:.o=.po)
Re: need some tools for migration
On Mon, Jul 29, 2002 at 09:57:16AM -0600, Sunil Kumar wrote: Hi, Does anyone know about any tool which can migrate user accounts from smbpasswd database to LDAP. 'pdbedit' should do the trick. Steve Langasek postmodern programmer msg02205/pgp0.pgp Description: PGP signature
Re: Patch to do LSA 0x2e rpc - next gen
On Tue, Jul 30, 2002 at 09:43:18AM +1000, Andrew Bartlett wrote: Steven French wrote: How do we get the dns domain name? Maybe invoking dnsdomainname (or equivalently hostname -d which I use on Linux to return the default dns domain name for my local host) is a possibility for populating the field by default in the absence of an smb.conf parm. BTW, the kerberos realm is an smb.conf paramater. (lp_realm()) Really ought to have the default loaded from krb5.conf using the krb5 apis, but eh -- one step at a time. :) Steve Langasek postmodern programmer msg02225/pgp0.pgp Description: PGP signature
Re: pam_smbpass and LDAP....
On Thu, Jul 25, 2002 at 01:50:47PM +0200, Bartlomiej Solarz-Niesluchowski wrote: I have troubles to run pam_smbpass when samba 2.2.5 (RH 73) is compiled with ldapsam ./configure i386-redhat-linux --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --libdir=/etc/samba --with-fhs --with-privatedir=/etc/samba --with-lockdir=/var/cache/samba --with-swatdir=/usr/share/swat --with-codepagedir=/usr/share/samba/codepages --with-automount --with-smbmount --with-pam --with-mmap --with-quotas --without-smbwrapper --with-libsmbclient --with-utmp --with-piddir=/var/run/samba --with-pam_smbpass --with-acl-support --with-profile --disable-static --with-msdfs --with-ldapsam Jul 25 13:13:32 portraits passwd: PAM unable to dlopen(/lib/security/pam_smbpass.so) Jul 25 13:13:32 portraits passwd: PAM [dlerror: /lib/security/pam_smbpass.so: undefined symbol: ldap_value_free] Jul 25 13:13:32 portraits passwd: PAM adding faulty module: /lib/security/pam_smbpass.so Can someone help me? What does 'ldd /lib/security/pam_smbpass.so' show you? I've checked a pam_smbpass binary built from CVS HEAD, and it is correctly linked against libldap; libldap provides the ldap_value_free function. If you're seeing different behavior, either -lldap is not being correctly added to the LIBS line when Samba builds, or your libldap is missing some symbols that pam_smbpass is expecting. Steve Langasek postmodern programmer msg02136/pgp0.pgp Description: PGP signature
cosmetic manpage fixes for HEAD
Hello,
With the recent announcement that the Samba Team is focusing all further
development efforts on 3.0, a push has begun to sort through the niggly
issues that need to be resolved in order to produce packages for Debian
that can be uploaded to the archive. This first patch addresses an
issue I ran into while trying to install manpages: all English-language
manpages ended up in /usr/share/man/lang/man{1,5,7,8} instead of the
expected /usr/share/man/man{1,5,7,8}. The below patch against CVS HEAD
should cause the manpages to install in the correct directories, without
interfering with the ongoing i18n support.
Regards,
Steve Langasek
postmodern programmer
Index: script/installman.sh
===
RCS file: /cvsroot/samba/source/script/installman.sh,v
retrieving revision 1.11
diff -u -w -r1.11 installman.sh
--- script/installman.sh25 Sep 2001 02:01:29 - 1.11
+++ script/installman.sh18 Jul 2002 20:46:57 -
-22,8 +22,8
echo Installing \$lang\ man pages in $MANDIR/lang/$lang
fi
-langdir=$MANDIR/lang/$lang
-for d in $MANDIR $MANDIR/lang $langdir $langdir/man1 $langdir/man5 $langdir/man7
$langdir/man8; do
+langdir=$MANDIR/$lang
+for d in $MANDIR $langdir $langdir/man1 $langdir/man5 $langdir/man7
+$langdir/man8; do
if [ ! -d $d ]; then
mkdir $d
if [ ! -d $d ]; then
