Kamen Mazdrashki | 25 Jan 23:13 2015

Re: Your Tombstone Reanimation branch

On Sun, Jan 25, 2015 at 11:51 PM, Andrew Bartlett <abartlet <at> samba.org>

> This is looking much better.  Can you also do:
> On Sun, 2015-01-25 at 21:41 +0200, Kamen Mazdrashki wrote:
> > +        # assert we have expected attribute names
> > +        actual_names = set(user_obj.keys())
> > +        # Samba does not use 'dSCorePropagationData', so skip it
> > +        actual_names -= set(['dSCorePropagationData'])
> > +        self.assertSetEqual(set(expected_attrs.keys()), actual_names)
> On the reanimation tests?

It should be there already
Actually I think I've copy&pasted from there :)


Kamen Mazdrashki | 25 Jan 20:41 2015

Re: Your Tombstone Reanimation branch

Hi Andrew,

On Fri, Jan 23, 2015 at 6:30 AM, Andrew Bartlett <abartlet <at> samba.org> wrote:

> On Fri, 2015-01-23 at 05:23 +0200, Kamen Mazdrashki wrote:
> > Hi Garming,
> >
> > On Fri, Jan 23, 2015 at 12:53 AM, Garming Sam
> > <garming <at> catalyst.net.nz> wrote:
> >         Hi Kamen,
> >
> >         I've just looked into what caused the issue with the upgrade
> >         provision test. It looks like in the final patch, you managed
> >         to omit logonCount in the table of options.
> >
> > Many thanks for nailing down what the problem was!
> >
> >
> >         That should be a simple fix, but Andrew has suggested, if you
> >         don't mind, that a test should be written to explicity test
> >         the defaults. Preferably in sam.py.
> >
> >         The test needs to not only confirm that the bare minimum 'add'
> >         request works as expected (and asserts on the attributes
> >         added, and that no others are added), but also check that if
> >         each of the attributes is included in the add, that it either
> >         fails, or succeeds and replaces the default value.
> >
> >         A bare minimum add is:
> >
(Continue reading)

Richard Sharpe | 25 Jan 18:40 2015

WIP: A Wireshark dissector for RSVD ...

Hi folks,

People keep doing silly things, like transporting SCSI is weird transports.

Attached is the beginnings of a Wireshark dissector MS-RSVD. It needs
more work but it can display the SCSI CDB (as bytes) and any data in
requests (as bytes).

Ultimately, I want to split this out as a separate RSVD dissector, I think.

The patch should apply to the master branch of a recent git tree. It
goes on top of some stuff I added in October last year.


Richard Sharpe
Richard Sharpe | 25 Jan 00:27 2015

Patch: Fix a couple of misleading DEBUG statements in vfs_default.c

The code came adrift from somewhere else and the DEBUG statements were
misleading, so I removed the misleading function names.

Review and push please.


Richard Sharpe
Milosz Tanski | 24 Jan 21:46 2015

Question(s) about smbd in respect to preadv2

I'm at a bit of a cross roads with testing preadv2 using samba and how
samba could benefit from the syscall. I need to better understand the
samba architecture today and where it's going. I spent a few hours
yesterday and today better to understand samba; I also looked at
Jermey's SambaXP 2014 talk. There's a few clarifications I need.

I did some preliminary testing using preadv2 to perform. The first
tests I ran were using the source3 smbd server. And I compared the
sync, pthreadpool and pthreadpool + preadv2. Just a simple rand read
test with one client with a cached data.

The results were that sync was fastest (no surprise there).
Pthreadpool + preadv2 was about 8% slower then sync. Plain old
pthreadpool 26% slower. So not a bad win there. Additionally, it looks
like the vfs_pread_send and vfs_pread_recv have a bit more overhead
over plain old vfs_pread in the code path so it's possible to get that
8% even closer to the sync case.

So far, so good... but what struct me is that I don't really
understand why samba uses the pthreadpool if forks() for each client
connection? Why bother.

From looking at the code in for source3, source4 and internet readings
(like Jeremy's talk). It looks like there's an ambition to not have a
process per connection model in the future. Am I correct in that

Is the hope to have one process with a main (or few) thread handling
the most of the incoming network IO and then a largish threadpool for
performing most of the accentual disk IO work?
(Continue reading)

Richard Sharpe | 24 Jan 16:39 2015

Is it really done when you call tevent_req_done?

Hi folks,

In my seemingly never ending quest to understand tevent, I noticed the
following in some random smb2 request processing routine, like


        subreq = smbd_smb2_tree_connect_send(req,
        if (subreq == NULL) {
                return smbd_smb2_request_error(req, NT_STATUS_NO_MEMORY);
        tevent_req_set_callback(subreq, smbd_smb2_request_tcon_done, req);

        return smbd_smb2_request_pending_queue(req, subreq, 500);

So, we create a subrequest in smbd_smb2_tree_connect_send and if we
got one, we set a callback (smbd_smb2_request_tcon_done and then call
that routine that will queue it perhaps.

However, when we look at smbd_smb2_tree_connect_send we see:

        status = smbd_smb2_tree_connect(smb2req,
(Continue reading)

Marc Muehlfeld | 24 Jan 16:10 2015

[PATCH] group.py: Fix wrong example option, remove wrong comment line


attached a patch, with two tiny fixes for python/samba/netcmd/group.py.

Please review and push.

Thanks to Rowland, for finding that. I created a bug report, to track
this: https://bugzilla.samba.org/show_bug.cgi?id=11072


Am 24.01.2015 um 13:51 schrieb Rowland Penny:
> The other thing that is puzzling me is '--gid=12345', yet in the
> script there is this:
> Option("--gid-number", help="Group's Unix/RFC2307 GID number",
> type=int),
> ....
> Just one last comment, the first line of group.py is this:
> # Adds a new user to a Samba4 server
> ????
> Rowland
(Continue reading)

Richard Sharpe | 24 Jan 06:20 2015

Clarification of a comment in tevent.h

Hi folks,

I noticed this comment in lib/tevent/tevent.h just before the macro

 * Convenience function for declaring a tevent_fd writable

This suggests that we are making the tevent_fd writable but the usage
suggests that we are marking the fd_event to say that we are now
interested in getting events when the FD becomes writable ...

Have I misunderstood this?


Richard Sharpe

Noel Power | 23 Jan 12:07 2015

A question about use of DEBUG in wb_reqtrans.c

Hi Metz, All

Recently I was looking at a problem where the root cause would have
easily been seen if the DEBUG messages in wb_reqtrans.c were functional.
I missed entirely that the DEBUG macro was disabled at the top of the
file and because of that for a while ended up on a wild goose chase ;-)
Afterwards my first thought was if those DEBUG messages are not
functional then it's better to remove them entirely (rather than cause
confusion). However, it would be nicer of course if they could be enabled.

The commit that seemed to remove that functionality was

I wonder though if the reason disabling the DEBUG macro in this file is
still relevant (perhaps it isn't)

looking at the current usage in master wb_reqtrans.c

wb_reqtrans.c is used in
    a) LIBWBCLIENT_OLD (source4/libcli/wbclient/wscript_build) library
    b) winbindd (source3/wscript_build)
    c) smbtorture (source3/wscript_build)



(Continue reading)

Thomas Hartmann | 22 Jan 18:38 2015

CTDB: shared path on NFS3: successful file lock only with soft mount

Hi all,

I stumbled over a problem, I would like to understand better:

I am running CTDB with the shared fs on NFS3 mounted on all nodes. For
maintenance, I had to move to a different export and, thus, stoped my
services mounted the new export rsync'ed everything, remounted the new
export under the old mount path and restarted everything.

However, after restart (even with only one node alone) the cluster
startup failed. The daemon could create the lock file (checked
permissions, NFS UIDs/GIDs etc.) when manually removed - but was
complaining not to be able to get the recovery lock (although it just
created the file)

2015/01/22 17:38:28.039885 [recoverd:22602]: Taking out recovery lock
from recovery daemon
2015/01/22 17:38:28.039944 [recoverd:22602]: Take the recovery lock
2015/01/22 17:38:34.045139 [recoverd:22602]: ctdb_recovery_lock: Failed
to get recovery lock on '/ctdb/fts3/CTDB_FTS3/lock'
2015/01/22 17:38:34.045189 [recoverd:22602]: Unable to get recovery lock
- aborting recovery and ban ourself for 300 seconds
2015/01/22 17:38:34.045294 [22412]: Banning this node for 300 seconds

after some testing I mounted the pathes manually and was able to startup
CTDB with NFS 'soft'-mounted -- before I had the autofs made to
'hard'-mount the NFS export.

(Continue reading)

David Hasson | 23 Jan 00:56 2015

CTDB question: which repository is authoritative?

Hey guys,

What's the current status of the ctdb branches in SCM?  I've been tracking patches to CTDB on this list,
however they are all applied to, and eventually pushed to the samba.git repository.  I'm interested in
building standalone CTDB - and the ctdb.git repository seems to be the one setup for this.

Are they both official?  The website refers to both in various cases.  My plan unless I get any news from you
guys is to cherry pick commits out of samba.git onto the standalone ctdb.git.  It does seem that a fair
amount of changes were made just to change to the newer build environment.



David Hasson
dph <at> fb.com