Win9x, samba 3, user list
Hello! I can't get users list on win 98 with current CVS, it says something like- try later. And I see this in log 2003/01/31 13:41:05, 1] smbd/ipc.c:api_fd_reply(284) api_fd_reply: INVALID PIPE HANDLE: 0 Certanly, I can provide log with level 10 :-)
Will these patches make it into 2.2.8?
Hi Samba team, as 2.2.8 seems to approach now, have the following patches been considered for it? They both don't add functionality, but rather improve robustness, and are platform independent: http://lists.samba.org/pipermail/samba-technical/2002-December/041413.html prevents winbindd from damaging its own idmap TDB on write failures (filesystem full), by rolling back partial changes done by the failed store of mapping. http://lists.samba.org/pipermail/samba-technical/2003-January/041897.html avoids the reconnect delay when DC pipes have died, thus avoids false negatives to be returned to clients, and to be cached. Not a 100%, however. If there is really no DC available at the time of query, it will still happen. But it's an improvement compared to having these false negatives always after a connection died. Cheers! Michael
Solaris fcntl bug - Update
What's about bug Solaris 8 ? where can we download T108528-19 for Solaris 8 ? Thanks for your reply Alain Defrance Ingénieur systèmes et réseaux Service Informatique Université d'Evry Val d'Essonne [EMAIL PROTECTED] 01.69.47.80.69 06.74.09.19.54 www.univ-evry.fr
User with read only access can deny write.
Hello (I'm not subscribed to this list so please Cc: me). I have reported an issue to the Debian bug tracking system but the maintainer thought that it was better to ask upstream. So now I do that. This is the first of three issues. The description is found in: http://bugs.debian.org/178784 The relevant part from the initial mail sent there is pated here: I have got a small problem. The thing is that if one use A open a file in microsoft word without having write access to the file the file become locked. From smbstatus: 19717 DENY_WRITE RDONLY NONE /home/pathtofile The problem is that all other users can not write to the file because it is locked. This is a problem here because some users need to be able to write the file while other just have read access. You could say that it is a bug in word but on the other hand it should really be possible to deny write whily you do not have write permission. I assume that this is a bug, i.e. no check is performed to determine if a user really can deny write to other users. Or is this a design flaw in samba? If you can give me an indication on where to look in the code I'll try to make a patch for you. Regards, // Ola -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Antwort: Solaris fcntl bug - Update
Hello Alain, if you have a service contract with sun and can show them that you really have a problem without this Patch, then they will send you the T-Patch. Else you have until the next Kernel Jumbo Patch is released. The actual KJS for Solaris 8 sparc is 108528-18 and the next will be -19 regards Thomas -- General Logistics Systems Thomas Mieslinger German-Parcel-Str. 1-7 fon: +49 6677 17 463 36286 Neuensteinfax: +49 6677 17 111 Germany eMail: [EMAIL PROTECTED] Alain Defrance [EMAIL PROTECTED] Gesendet von: [EMAIL PROTECTED] 31.01.2003 13:08 An: [EMAIL PROTECTED] Kopie: Thema: Solaris fcntl bug - Update What's about bug Solaris 8 ? where can we download T108528-19 for Solaris 8 ? Thanks for your reply Alain Defrance Ingénieur systèmes et réseaux Service Informatique Université d'Evry Val d'Essonne [EMAIL PROTECTED] 01.69.47.80.69 06.74.09.19.54 www.univ-evry.fr
improved dos attribute handling
Hello again. This is the next issue for which I have created a patch. There is a problem with the current dos filemode option. The problem is that you can only set read only but not remove it again. You can of course not because you do no longer have write permissions to the file. My fix change the behaviour to check the directory and file for permissions. If the user has write permission to the dir and (is owner of file, or member of group or part of group) of the file the read-only can be removed. The code is tested but not for very long time. Right now just a week in a production server. I have not checked if it is possible to bypass something but I do not think so. I think I have catched all cases, but checking is good. For other information, see: http://bugs.debian.org/178801 The patch is located at (against the debian version of 2.2.3a): http://cvs.opal.dhs.org/viewcvs.cgi/samba-fixes/dchmod/samba-dchmod.patch?rev=1.1content-type=text/vnd.viewcvs-markup or just http://cvs.opal.dhs.org/viewcvs.cgi/samba-fixes/dchmod/ if you want to look at the files directly. The patch includes the changes to the smbd makefile and dosmode.c file. I had to write some functions myself because the normal C-functions did not really behave as windows functions... That did not surprise me a lot though. :) Best regards, // Ola -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Move files do not change group as copying does.
Hello (I'm not subscribed to please Cc: me). I have a problem with movement of files: The problem this time is that we have set up a permission structure for files in about the same way as windows do, using groups. The problem is that in windows, the files inherit the group membership from the directory where the files (and subdirs) reside. This works fine now if the user copy the files from one place to the other. The problem is that if the files (and dirs) is moved an ordinary rename(a,b) command is used which means that the group membership is not changed. I use sgid on directorys to emulate windows behaviour but this do not help if moving files. I have looked at the code and see that there is a rename(a,b) emulation function, but that tries to emulate it truely so it gives the same problem. My suggestion is that a recursive chgrp is performed to the destination for all dirs and files that has the same group id as the source file or dir. What do you think about this? The inherit acls = yes option do not seem to help here because, first you need acl kernel support and second the same code for moving files is used (but I can be mistaken). I need to get some feedback where to patch the code and if you are interested in it. You can also see the debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=178800 From IRC (if that can be interesting): debian-opal Is there anyone in here who can explain how the vfs_rename function is supposed to work? Exactly what arguments can you expect that it gets? debian-opal I'm trying to create a emulation of windows group membership inheritance. debian-opal It works ok if copying files but not if moving. *SNIP* abartlet debian-opal: I would be worried about the races with that proposal debian-opal abartlet: Yes that can be a problem. The problem is that our customer needs to emulate that... idra debian-opal: emulate what exactly? abartlet you want to emulate racy windows code? abartlet (I understand much of the ACL stuff races on WinNT too...) debian-opal The problem is that we have set up a permission structure on a customer server. The permissions are based on the directory where things are located. idra inheritance is just yet another demonstration of how good basis are converted in braindamaged implementations at MS ... :-( debian-opal If you copy files the group get inherited because the sgid bit is set on the dir. The problem is with moving files. idra debian-opal: so if you move files they retain the ownership ... idra instead of inheriting the one set in the directory, right? debian-opal Yes. idra uhmmm idra I think this is a bug for jeremy idra have you written on [EMAIL PROTECTED] ? debian-opal Nope. I wanted to ask here if someone knew, so I could patch it nice and quickly. idra then write asap on the list, maube cc to jeremy directly *SNIP* idra debian-opal: you are using the proper smb.conf options for inheritance on that share? debian-opal I think so. Are there any options that cause the rename thing not to be used? debian-opal Do the dos inherit = yes really fix this? debian-opal Sorry. inherit acls = yes. Don't I need acl support in the kernel? idra yes you need ACL idra but any kind of proper inheritance need ACLs idra (Imho) debian-opal Ok. The manual page is talking about creating a file/dir... not about moving. Regards, // Ola -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: improved dos attribute handling
Ola Lundqvist wrote: Hello again. This is the next issue for which I have created a patch. There is a problem with the current dos filemode option. The problem is that you can only set read only but not remove it again. You can of course not because you do no longer have write permissions to the file. My fix change the behaviour to check the directory and file for permissions. If the user has write permission to the dir and (is owner of file, or member of group or part of group) of the file the read-only can be removed. The code is tested but not for very long time. Right now just a week in a production server. I have not checked if it is possible to bypass something but I do not think so. I think I have catched all cases, but checking is good. You are aware that this can introduce a security hole because the way that DOS / Windows handles the Readonly bit is quite different than in a POSIX or UNIX environment. In the Microsoft Windows and DOS environment, the Readonly attribute means that no one has write or delete access to the file, not even the Administrator or root account. If your platform supports ACLs, the Readonly bit is supposed to overide them also. So unless you change the security model of the host platform, it is not possible to have the Readonly attribute behave the way that it does in a Microsoft Windows environment. Now you can determine if the file is Readonly to the client, and use the bit to report this. But it is not possible to for a POSIX host to allow the client to change this attribute and have it have the same effect. The model of simulating a Readonly bit by removing Write and delete access from the Owner, Group, and World bits is ignoring that root or setuid root programs can still write to the file, and does not take into account that ACLs can still grant write access. The problem with this, is that while you can allow the client to remove the write/delete bits from a file that they have permission to change the permission on, it is not good to have the client put the write permissions back on. You simply do not know what the Group and World settings were prior to the Readonly attribute being set. If you have a file that starts out: W:readonly, G:readonly, O:read-write, and the client sets the Readonly bit, then the result is obvious. When the client clears Readonly bit, then if you just add Write and Delete access to the owner, everthing is back to normal. However if the file starts out: W:readonly, G:read-write, and O:read-write, and when the client sets the Readonly bit, write access is removed from the Group, and Owner. But what happens when you just set the O: write+delete settings when the client clears the Readonly bit, the other members of the group still will not have write access to the file. A similar situation will exist in the event that the file started out with W:write+delete access. Now with ACLs implemented on the host platform, even this simulation will not work. The Readonly bit based on solely on the protection mask becomes totally misleading. You can set it or clear it, but it may have no effect on access to the file by either the host programs or to clients. With ACLs, you can create a SAMBA_READONLY entry, and then use that to simulate the READONLY bit. But it must be applied in such a way that gives it priority over all ACEs. Because it is a DENY if present ACE, on OpenVMS, it would require that all user accounts have that identifier granted to them. But because root privilege still overides the ACL, it is still not the same as on an Microsoft server. If you are not concerned about having the Readonly attribute apply to access from the host system, it becomes much easier to implement. But it is almost impossible to implement correctly, and all close simulations have drawbacks. So any hack to improve Readonly for a particular group of users, may not be correct for another group of users, and must be customizable. And as a preemption for the comment that a Microsoft Windows Administrative account can overide the Readonly attribute. It can not. What it can do is turn the attribute off, but it can not write or delete the file until that attribute is removed. -John [EMAIL PROTECTED] Personal Opinion Only
Re: Win9x, samba 3, user list
On Fri, 31 Jan 2003, Dmitry Melekhov wrote: Hello! I can't get users list on win 98 with current CVS, it says something like- try later. And I see this in log 2003/01/31 13:41:05, 1] smbd/ipc.c:api_fd_reply(284) api_fd_reply: INVALID PIPE HANDLE: 0 Certanly, I can provide log with level 10 :-) Would probably be helpful if you provided a trace as well. Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
Re: Will these patches make it into 2.2.8?
On Fri, Jan 31, 2003 at 12:58:45PM +0100, Michael Steffens wrote: Hi Samba team, as 2.2.8 seems to approach now, have the following patches been considered for it? They both don't add functionality, but rather improve robustness, and are platform independent: http://lists.samba.org/pipermail/samba-technical/2002-December/041413.html prevents winbindd from damaging its own idmap TDB on write failures (filesystem full), by rolling back partial changes done by the failed store of mapping. http://lists.samba.org/pipermail/samba-technical/2003-January/041897.html avoids the reconnect delay when DC pipes have died, thus avoids false negatives to be returned to clients, and to be cached. Not a 100%, however. If there is really no DC available at the time of query, it will still happen. But it's an improvement compared to having these false negatives always after a connection died. They are in my inbox queue of things to merge. I have to work on HP printing bugs as my 'day' job priority, but I have not forgotten these and will ensure they get added before 2.2.8. Thanks, Jeremy.
Re: Solaris fcntl CPU/Lock update
On Fri, Jan 31, 2003 at 09:07:23AM -0800, Jeff Mandel wrote: I have followed this fcntl bug closely, and I just applied a T-patch for solaris 8 which brought the kernel 108528-19. This includes the fix for 4735093. This has not fixed the problem of smbd growing to consume all available CPU. Environment is SunOS reiger 5.8 Generic_108528-19 sun4u sparc SUNW,Sun-Fire-280R nss_ldap-203 pam_ldap-137 Here's an excerpt of the truss I've used to diagnose this with sun. 24495/1:*** SUID: ruid/euid/suid = 0 / 3007 / 3007 *** 24495/1:*** SGID: rgid/egid/sgid = 0 / 125 / 125 *** Base time stamp: 1041263328.3198 [ Mon Dec 30 16:48:48 CET 2002 ] 24495/1:psargs: /usr/local/samba/bin/smbd -D -s/usr/local/samba/lib/smb. conf 24495/1: 0.0012 sigprocmask(SIG_SETMASK, 0xFED2AD70, 0xFFBEDF10) = 0 24495/1: set = 0xFFBFFEFF 0x1FFF 0 0 24495/1:oset = 0 0 0 0 24495/1: 0.0016 lwp_kill(1, SIGUSR1)= 0 24495/1: 0.0018 sigprocmask(SIG_SETMASK, 0xFFBEDF10, 0x) = 0 24495/1: set = 0 0 0 0 24495/1: 0.0019 Received signal #16, SIGUSR1 [caught] 24495/1: siginfo: SIGUSR1 pid=24495 uid=0 code=-1 24495/1: 0.0021 setcontext(0xFFBED9C8) 24495/1: 0.0022 sigprocmask(SIG_SETMASK, 0xFED2AD70, 0xFFBEDEB0) = 0 24495/1: set = 0xFFBFFEFF 0x1FFF 0 0 24495/1:oset = 0 0 0 0 24495/1: 0.0025 lwp_kill(1, SIGUSR1)= 0 Please ensure the smbd process is compiled with debug symbols (-g) and then attach to it with gdb and please send in a stack backtrace (bt command in gdb). Thanks, Jeremy. *** Repeats continuously *** Any suggestions?
Re: large file support
On Fri, 31 Jan 2003, Mourad MESSAOUDI wrote: Hi everybody, I'm trying to create a file on a smb share and it stops at 2 Gb. samba release 2.2.7a with this patch --- libsmb/clireadwrite.c 19 Dec 2002 16:12:41 - 1.2.4.9 +++ libsmb/clireadwrite.c 30 Dec 2002 04:04:37 - kernel is 2.4.20 with acl patch. I've checked, the creation of files larger than Gb: it's ok. I have this messages in /var/log/messages of the client machine when I reach the 2Gb : kernel: smb_get_length: recv error = 5 kernel: smb_request: result -5, setting invalid kernel: smb_retry: successful, new pid=18489, generation=2 There have been some changes to support file sizes larger than 2-4GB. They should appear in 2.2.8. Please pull the latest CVS and try. Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
Re: Will these patches make it into 2.2.8?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 31 Jan 2003 [EMAIL PROTECTED] wrote: as 2.2.8 seems to approach now, have the following patches been considered for it? They both don't add functionality, but rather improve robustness, and are platform independent: http://lists.samba.org/pipermail/samba-technical/2002-December/041413.html prevents winbindd from damaging its own idmap TDB on write failures (filesystem full), by rolling back partial changes done by the failed store of mapping. http://lists.samba.org/pipermail/samba-technical/2003-January/041897.html avoids the reconnect delay when DC pipes have died, thus avoids false negatives to be returned to clients, and to be cached. Not a 100%, however. If there is really no DC available at the time of query, it will still happen. But it's an improvement compared to having these false negatives always after a connection died. They are in my inbox queue of things to merge. I have to work on HP printing bugs as my 'day' job priority, but I have not forgotten these and will ensure they get added before 2.2.8 But probably not for 2.2.8pre1. cheers, jerry -- Hewlett-Packard- http://www.hp.com SAMBA Team -- http://www.samba.org GnuPG Key http://www.plainjoe.org/gpg_public.asc You can never go home again, Oatman, but I guess you can shop there. --John Cusack - Grosse Point Blank (1997) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQE+OrpVIR7qMdg1EfYRAu+GAKCpW4P4Pibv8skvszyDYUBLJP8PqgCaA19Y Bypeyi93rn82wacRuxGFzzs= =EKGi -END PGP SIGNATURE-
Patch for samba 2_2 for Stratus VOS
Attached is a patch for the 2_2 branch of samba that makes changes similar to
the ones I recently submitted to the head and 3_0 branches.
I have tested it locally on VOS and it works as expected. I have also tested it
on Solaris 2.8 and it looks ok there too. I ran configure and then make
everything; make wins. Now, for the first time in months, I can build the
stock Samba 2.2.x on VOS.
I tried to make absolutely the minimum changes to get this to work here. Most of
what I did was to back-port ideas from the 3_0 branch.
I had to make one change that will affect other platforms -- but only on the
build farm. Today, the samba_2_2 build farm hook (make everything)
unconditionally builds nsswitch/lib_wins.so. This screws us, because that's a
shared library and we don't do shared libraries. Oddly enough, make
everything on samba_3_0 does not try to unconditionally build shared libraries.
You have to say make wins in 3_0 to get this file built. So that is the way
I implemented it in 2_2. I'm willing to rework this if someone can explain a
better way to achieve the same goal. I'm hoping that since there are a lot of
shared libraries that aren't built by the build farm, adding one more to the
list isn't a big deal. Hmm. Perhaps the thing to do is to get the build farm
shell script to say make everything;make wins, and then I can comment the
make wins out in my copy of the script? Anybody?
I also noticed that 2_2 lets the install script pick where to install shared
libraries, but 3_0 is explicit (see the installlibsmbclient rule). I applied
Occam's razor and stuck with the 2_2 scheme.
Thanks
PG
--
Paul Green, Senior Technical Consultant, Stratus Technologies.
Voice: +1 978-461-7557; FAX: +1 978-461-3610
Speaking from Stratus not for Stratus
diff -urp old/samba_2_2/source/Makefile.in new/samba_2_2/source/Makefile.in
--- old/samba_2_2/source/Makefile.inThu Jan 30 12:29:50 2003
+++ new/samba_2_2/source/Makefile.inThu Jan 30 23:03:29 2003
@@ -24,6 +24,8 @@ TERMLIBS=@TERMLIBS@
LINK=$(CC) $(FLAGS) $(LDFLAGS)
INSTALLCMD=@INSTALL@
+INSTALLCLIENTCMD_SH=@INSTALLCLIENTCMD_SH@
+INSTALLCLIENTCMD_A=@INSTALLCLIENTCMD_A@
VPATH=@srcdir@
srcdir=@srcdir@
@@ -101,7 +103,7 @@ MPROGS = @MPROGS@
LPROGS = $(WINBIND_PAM_PROGS) $(WINBIND_LPROGS)
PROGS = $(PROGS1) $(PROGS2) $(MPROGS) bin/nmblookup
TORTURE_PROGS = bin/smbtorture bin/msgtest bin/masktest bin/locktest bin/locktest2
-SHLIBS = libsmbclient
+SHLIBS = @LIBSMBCLIENT@
SCRIPTS = $(srcdir)/script/smbtar $(srcdir)/script/findsmb
@@ -426,13 +428,13 @@ TDBDUMP_OBJ = tdb/tdbdump.o $(TDBBASE_O
all : CHECK $(SPROGS) $(PROGS) $(WINBIND_PROGS) $(WINBIND_SPROGS) $(LPROGS)
# The following everything is NOT needed except by Samba developers - so do not use
this!
-everything : CHECK $(SPROGS) $(PROGS) $(SHLIBS) nsswitch smbwrapper smbtorture
debug2html smbfilter nsswitch/libnss_wins.so
+everything : CHECK $(SPROGS) $(PROGS) $(SHLIBS) nsswitch smbwrapper smbtorture
+debug2html smbfilter
pam_smbpass : CHECK bin/pam_smbpass.@SHLIBEXT@
smbwrapper : CHECK @WRAPPROG@ @WRAP@ @WRAP32@
-libsmbclient : CHECK bin/libsmbclient.@SHLIBEXT@ bin/libsmbclient.a
+libsmbclient : CHECK bin/libsmbclient.a @LIBSMBCLIENT_SHARED@
torture : CHECK $(TORTURE_PROGS)
@@ -460,6 +462,8 @@ smbfilter : CHECK bin/smbfilter
nsswitch : CHECK $(WINBIND_PROGS) $(WINBIND_SPROGS) $(LPROGS)
+wins : CHECK nsswitch/libnss_wins.@SHLIBEXT@
+
.SUFFIXES:
.SUFFIXES: .c .o .po .po32 .lo
@@ -723,7 +727,8 @@ installswat: installdirs
@$(SHELL) $(srcdir)/script/installswat.sh $(SWATDIR) $(srcdir)
installclientlib:
- -$(INSTALLCMD) bin/libsmbclient.so
+ -$(INSTALLCLIENTCMD_SH) bin/libsmbclient.@SHLIBEXT@
+ -$(INSTALLCLIENTCMD_A) bin/libsmbclient.a
-$(INSTALLCMD) -d ${prefix}/include
-$(INSTALLCMD) include/libsmbclient.h ${prefix}/include
diff -urp old/samba_2_2/source/configure.in new/samba_2_2/source/configure.in
--- old/samba_2_2/source/configure.in Thu Jan 30 15:03:26 2003
+++ new/samba_2_2/source/configure.in Thu Jan 30 23:08:51 2003
@@ -164,6 +164,8 @@ AC_SUBST(PICFLAG)
AC_SUBST(PICSUFFIX)
AC_SUBST(SHLIBEXT)
AC_SUBST(BLDSHARED)
+AC_SUBST(INSTALLCLIENTCMD_SH)
+AC_SUBST(INSTALLCLIENTCMD_A)
AC_SUBST(LIBSMBCLIENT_SHARED)
AC_SUBST(LIBSMBCLIENT)
@@ -315,6 +317,26 @@ case $host_os in
esac
;;
#
+# VOS may need to have POSIX support and System V compatibility enabled.
+#
+*vos*)
+case $CPPFLAGS in
+ *-D_POSIX_C_SOURCE*)
+ ;;
+ *)
+ CPPFLAGS=$CPPFLAGS -D_POSIX_C_SOURCE=199506L
+ AC_DEFINE(_POSIX_C_SOURCE, 199506L, [Whether to enable POSIX support])
+ ;;
+esac
+case $CPPFLAGS in
+ *-D_SYSV*|*-D_SVID_SOURCE*)
+ ;;
+ *)
+ CPPFLAGS=$CPPFLAGS -D_SYSV
+ AC_DEFINE(_SYSV, 1, [Whether to enable System V compatibility])
+esac
+;;
+#
Re: large file support and clitar.c etc
On Fri, 31 Jan 2003, Brian Poole wrote: Quoting Richard Sharpe ([EMAIL PROTECTED]) from 31 January 2003: There have been some changes to support file sizes larger than 2-4GB. They should appear in 2.2.8. Have any luck with the list I sent you ? I saw the tar reply which I appreciate being answered. Hi, Now that we have fixed some problems to do with large file transfer, there remains an issue with clitar.c and its handling of files larger than about 2GB. I am told that some variants write USTAR headers that only use 11 or 12 of the 13 possible OCTAL digits in the length field. To support larger files in the tar archive, we would need to write headers in a portable fashion. This, I believe, means that we would need to cut the file up into chunks, and then write each chunk, one after the other, with two headers. One indicating the file name etc, and the second indicating that the chunk is a continuation of the previous chunk and perhaps an offset. This way, at least the rest of the archive can be processed by archivers that do not understand large files. Does anyone see any problems with this, and does anyone have any time to support this effort? Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
Re: Win9x, samba 3, user list
Hi, On 31 Jan 2003 at 9:42, Dmitry Melekhov wrote: I can't get users list on win 98 with current CVS, it says something like- try later. This message arrives also with a replaced 'mapi32.dll'. -chris
Samba 3.0alpha21, Windows XP SP1 and Kerberos authentication
Hello, I am not sure if you are aware of this, but I wanted to post it just in case. I compiled Samba3.0alpha21 on Linux with ADS, LDAP and Kerberos support and joined it to our Windows domain (with 'net ads join') without problems. I set up Samba to offer a few shares. Right after, I was able to access the shares with smbclient and tickets from the MS KDC without problems. I gather smbclient will try to get a service ticket for the principal servername$@REALM, which is ok. The Windows XP clients will not, however, use Kerberos to authenticate to Samba. I checked with Ethereal to see what was going on. XP clients would attempt to get ticket for the service principal CIFS/server.example.com, which had not been created when joining the domain. I added a servicePrincipalName like this for the computer account and things began to work. It would be nice if Samba created this principal by default? Best regards, Antti Tikkanen -- [EMAIL PROTECTED] Helsinki University of Technology Computing Centre
samr_open_group no supported
Hi All, I need some information from one of you expert Samba developers out there. I wrote a little tool for listing users, groups, and group membership on Windows servers using MSRPC calls. It works against Windows NT and 2000 machines, but not against a Samba server. Here's why: To list global groups, I perform a samrQueryDisplayInfo call, with level 3 (for groups). To get the members of each group I perform a samrOpenGroup followed by a samrQueryGroupMembers call. To list local and built-in groups, I first perform an OpenDomain call with either the special built-in domain sid or the server's domain sid. I follow this up with a samrEnumDomainAliases call to get the groups/aliases. Then for each group I do a samrOpenAlias followed by a samrGetAliasMembers query. The tool works fine against Windows NT and Windows 2000 machines. However, when I try it against my Samba server I get a STATUS_NOT_IMPLEMENTED error as a response to my samrOpenGroup request. Examining the Samba source code revealed that this SAMR request is indeed not implemented. Any reason why not? Is there a better, or more recommended way, of obtaining the global groups? Kind Regards, Yuval _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
Re: Samba 3.0alpha21, Windows XP SP1 and Kerberos authentication
On Sat, 2003-02-01 at 09:00, Antti Tikkanen wrote: Hello, I am not sure if you are aware of this, but I wanted to post it just in case. I compiled Samba3.0alpha21 on Linux with ADS, LDAP and Kerberos support and joined it to our Windows domain (with 'net ads join') without problems. I set up Samba to offer a few shares. Right after, I was able to access the shares with smbclient and tickets from the MS KDC without problems. I gather smbclient will try to get a service ticket for the principal servername$@REALM, which is ok. The Windows XP clients will not, however, use Kerberos to authenticate to Samba. I checked with Ethereal to see what was going on. XP clients would attempt to get ticket for the service principal CIFS/server.example.com, which had not been created when joining the domain. I added a servicePrincipalName like this for the computer account and things began to work. It would be nice if Samba created this principal by default? The interesting thing is this - my Win2k servers don't seem to share this property. I can't even get a CIFS/ ticket, and they don't have those names. So, we need to do some more digging - what is it that makes Samba look different to Win2k in this regard? Do some comparative traces, look at what names your Win2k servers have registered etc. It would be interesting to track this down. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net signature.asc Description: This is a digitally signed message part
NBT length parameter larger than necessary in session request
Hi guys, Ever notice smbclient sends an NBT session request with an NBT length field that is 4 bytes longer than necessary? No harm, but is there a reason for this? I'm using 2.2.1a shipped with RH connecting to the same version of Samba over loopback. Mike -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived.
Re: samr_open_group no supported
On Sat, 2003-02-01 at 09:25, Xyster ! wrote: Hi All, I need some information from one of you expert Samba developers out there. I wrote a little tool for listing users, groups, and group membership on Windows servers using MSRPC calls. It works against Windows NT and 2000 machines, but not against a Samba server. Here's why: To list global groups, I perform a samrQueryDisplayInfo call, with level 3 (for groups). To get the members of each group I perform a samrOpenGroup followed by a samrQueryGroupMembers call. To list local and built-in groups, I first perform an OpenDomain call with either the special built-in domain sid or the server's domain sid. I follow this up with a samrEnumDomainAliases call to get the groups/aliases. Then for each group I do a samrOpenAlias followed by a samrGetAliasMembers query. The tool works fine against Windows NT and Windows 2000 machines. However, when I try it against my Samba server I get a STATUS_NOT_IMPLEMENTED error as a response to my samrOpenGroup request. Examining the Samba source code revealed that this SAMR request is indeed not implemented. Any reason why not? Is there a better, or more recommended way, of obtaining the global groups? Samba's group support only really started to anywhere in Samba 3.0, with the 'group mapping' code being added. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net signature.asc Description: This is a digitally signed message part
RE: Finding group members - fix to winbindd_ads.c
On Fri, 2003-01-24 at 15:08, Ken Cross wrote: Hmm ... the helpful email client wrapped some of the lines. The patch is attached. Ken -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ken Cross Sent: Thursday, January 23, 2003 11:01 PM To: [EMAIL PROTECTED] Subject: Finding group members - fix to winbindd_ads.c Samba-folk: There's a problem in the SAMBA_3_0 finding all members of a group using LDAP (lookup_groupmem in nsswitch/winbindd_ads.c). It currently gets all the member records for a group, but the primary group membership for users don't get included in that set. The primaryGroupID in user records is the RID of the primary group. That should be included in enumerating the members of any group. The patch below fixes this. Ken Cross Network Storage Solutions I didn't see anybody pick this up, so I just figured I would let you know that I've at least seen it. It's interesting that AD allows such a situation to occur at all, with its 'all groups are equal' stuff. I'll see if I can get a test environment for this - but I'm pretty busy at the moment (the patch looks fine, so if somebody else wants to commit it go right ahead). Finally, it's good to see a few more companies in the Samba 3.0 game - feel free to join the #samba-technical IRC channel on irc.freenode.net. A number of the samba team as well as folk from other Samba-3.0 NAS vendors can be found there from time to time. And don't be afraid to repost a patch if it seems to have been ignored. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net signature.asc Description: This is a digitally signed message part
RE: Finding group members - fix to winbindd_ads.c
On Sat, 2003-02-01 at 08:54, Andrew Bartlett wrote: On Fri, 2003-01-24 at 15:08, Ken Cross wrote: Hmm ... the helpful email client wrapped some of the lines. The patch is attached. Ken -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ken Cross Sent: Thursday, January 23, 2003 11:01 PM To: [EMAIL PROTECTED] Subject: Finding group members - fix to winbindd_ads.c Samba-folk: There's a problem in the SAMBA_3_0 finding all members of a group using LDAP (lookup_groupmem in nsswitch/winbindd_ads.c). It currently gets all the member records for a group, but the primary group membership for users don't get included in that set. The primaryGroupID in user records is the RID of the primary group. That should be included in enumerating the members of any group. The patch below fixes this. Ken Cross Network Storage Solutions I didn't see anybody pick this up, so I just figured I would let you know that I've at least seen it. It's interesting that AD allows such a situation to occur at all, with its 'all groups are equal' stuff. I'll see if I can get a test environment for this - but I'm pretty busy at the moment (the patch looks fine, so if somebody else wants to commit it go right ahead). Two issues have been raised on IRC: - firstly, if the destination of this call is the unix group membership, then we don't want 'primary' users added to the sups list, as the unix primary group should show this. - you don't seem to deal with the possibility of duplicates Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net signature.asc Description: This is a digitally signed message part
RE: Finding group members - fix to winbindd_ads.c
Andrew: - firstly, if the destination of this call is the unix group membership, then we don't want 'primary' users added to the sups list, as the unix primary group should show this. The destination is programmatic -- the user does what he wants with the results of a call to WINBINDD_GETGRGID or WINBINDD_GETGRNAM. If there's a need to distinguish between primary and supplemental members of a group, should we have a separate call? Personally, I've always been annoyed that there's no simple way in Unix to find all the members of a group. The output of groupinfo users is pitiful. You have to scan /etc/passwd (and maybe NIS, too) to get them all. - you don't seem to deal with the possibility of duplicates True. It shouldn't happen (it *shouldn't* be possible for a user to be a primary and supplemental member of the same group, but...). A duplicate check wouldn't be difficult, but potentially expensive if it was a Bit group (like Domain Users). Ken
RE: [Samba] RE: Winbind on HPUX11, Totally Stuck, Please Help
Hi, Miles, Actually on HP-UX, you will need to add the word 'debug' at the end of each of the lines in you /etc/pam.conf file, to enable more debugging to go into the /var/adm/syslog/syslog.log file. One thing that I have seen something like this happen on is if the /etc/shells file is corrupt, or if the shell that is defined for the user (since they don't have a /etc/passwd entry, this would be whatever you put in template in the smb.conf) does not exactly match one of the lines in /etc/shells, or the defaults, if this file does not exist. The defaults for 11.0 are: /sbin/sh /usr/bin/sh /usr/bin/rsh /usr/bin/ksh /usr/bin/rksh /usr/bin/csh /usr/bin/keysh Hope this helps, Don -Original Message- From: John H Terpstra [mailto:[EMAIL PROTECTED]] Sent: Friday, January 31, 2003 1:36 To: Miles Roper Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'; Esh, Andrew; Ronan Waide; STEFFENS,MICHAEL (HP-Germany,ex1); 'MCCALL,DON (HP-USA,ex1)'; 'Richard Sharpe' Subject: RE: [Samba] RE: Winbind on HPUX11, Totally Stuck, Please Help On Fri, 31 Jan 2003, Miles Roper wrote: Hi Everyone, I'm forgetting about the password one at the moment, thanks for all your input :o) I still don't have a clue how to solve my main problem. I'm assuming that its not actually winbind related now, as I've recently tried pam_smb and get the same basic problem. Basically, when I log into the UNIX box, the username/password of a NT user is being authenticated, but doesn't actually log in. It doesn't get past the password line. I know it accepts the password. Its almost as if it can't find the shell. But the template variable is set within the smb.conf file. Permissions are fine. I have exactly the same problem with the pam_smb module. So what does PAM report into your /var/log files? Have you tried adding to each line in your /etc/pam.d/login (after the .so file name) the word 'audit' - this will increase the volume of debugging info spit out into /var/log/messages, or wherever PAM send this on your distro. - John T. If there is any further information I can send let me know. Ideas? Thanks Miles -Original Message- From: MCCALL,DON (HP-USA,ex1) [mailto:[EMAIL PROTECTED]] Sent: Friday, 31 January 2003 07:06 a.m. To: STEFFENS,MICHAEL (HP-Germany,ex1); Ronan Waide Cc: '[EMAIL PROTECTED]'; Esh, Andrew; Miles Roper; '[EMAIL PROTECTED]'; 'Richard Sharpe' Subject: RE: [Samba] RE: Winbind on HPUX11, Totally Stuck, Please Help Hi Everyone, This whole problem with the password command not working when winbind is included as a method in the nsswitch.conf can probably be worked around by simply using the -r files (or -r nis or -r nisplus) switch. Take a look at the man page for passwd on HP-UX 11.x and see if this won't help you out. Hope this helps, Don -Original Message- From: Michael Steffens [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 11:52 To: Ronan Waide Cc: '[EMAIL PROTECTED]'; Esh, Andrew; Miles Roper; '[EMAIL PROTECTED]'; 'Richard Sharpe' Subject: Re: [Samba] RE: Winbind on HPUX11, Totally Stuck, Please Help Ronan Waide wrote: On January 28, [EMAIL PROTECTED] said: I don't have HPUX, so I don't know what to suggest for that. I just know getent won't work without winbindd in nsswitch.conf on Linux. I think the point that was being made is that NSS support on HPUX only supports a few known types, of which one is LDAP. The discussion was basically about faking out the system so that what it thinks is LDAP is actually winbind. Yep. It's a HP-UX specific workaround. Please ignore it everywhere else. Michael -- John H Terpstra Email: [EMAIL PROTECTED]
