3
THIS IS INCOMPLETE! I'M ONLY COMMITING IT IN ORDER TO SOLICIT COMMENTS
4
FROM A FEW PEOPLE. DON'T TAKE THIS AS THE FINAL VERSION YET.
7
Samba4 Programming Guide
8
========================
12
The internals of Samba4 are quite different from previous versions of
13
Samba, so even if you are an experienced Samba developer please take
14
the time to read through this document.
16
This document will explain both the broad structure of Samba4, and
17
some of the common coding elements such as memory management and
24
In past versions of Samba we have basically let each programmer choose
25
their own programming style. Unfortunately the result has often been
26
that code that other members of the team find difficult to read. For
27
Samba version 4 I would like to standardise on a common coding style
28
to make the whole tree more readable. For those of you who are
29
horrified at the idea of having to learn a new style, I can assure you
30
that it isn't as painful as you might think. I was forced to adopt a
31
new style when I started working on the Linux kernel, and after some
32
initial pain found it quite easy.
34
That said, I don't want to invent a new style, instead I would like to
35
adopt the style used by the Linux kernel. It is a widely used style
36
with plenty of support tools available. See Documentation/CodingStyle
37
in the Linux source tree. This is the style that I have used to write
38
all of the core infrastructure for Samba4 and I think that we should
39
continue with that style.
41
I also think that we should most definately *not* adopt an automatic
42
reformatting system in cvs (or whatever other source code system we
43
end up using in the future). Such automatic formatters are, in my
44
experience, incredibly error prone and don't understand the necessary
45
exceptions. I don't mind if people use automated tools to reformat
46
their own code before they commit it, but please do not run such
47
automated tools on large slabs of existing code without being willing
48
to spend a *lot* of time hand checking the results.
50
Finally, I think that for code that is parsing or formatting protocol
51
packets the code layout should strongly reflect the packet
52
format. That means ordring the code so that it parses in the same
53
order as the packet is stored on the wire (where possible) and using
54
white space to align packet offsets so that a reader can immediately
55
map any line of the code to the corresponding place in the packet.
58
Static and Global Data
59
----------------------
61
The basic rule is "avoid static and global data like the plague". What
62
do I mean by static data? The way to tell if you have static data in a
63
file is to use the "size" utility in Linux. For example if we run::
67
in Samba4 then you get the following::
69
text data bss dec hex filename
70
2015 0 0 2015 7df libcli/raw/clikrb5.o
71
202 0 0 202 ca libcli/raw/clioplock.o
72
35 0 0 35 23 libcli/raw/clirewrite.o
73
3891 0 0 3891 f33 libcli/raw/clisession.o
74
869 0 0 869 365 libcli/raw/clisocket.o
75
4962 0 0 4962 1362 libcli/raw/clispnego.o
76
1223 0 0 1223 4c7 libcli/raw/clitransport.o
77
2294 0 0 2294 8f6 libcli/raw/clitree.o
78
1081 0 0 1081 439 libcli/raw/raweas.o
79
6765 0 0 6765 1a6d libcli/raw/rawfile.o
80
6824 0 0 6824 1aa8 libcli/raw/rawfileinfo.o
81
2944 0 0 2944 b80 libcli/raw/rawfsinfo.o
82
541 0 0 541 21d libcli/raw/rawioctl.o
83
1728 0 0 1728 6c0 libcli/raw/rawnegotiate.o
84
723 0 0 723 2d3 libcli/raw/rawnotify.o
85
3779 0 0 3779 ec3 libcli/raw/rawreadwrite.o
86
6597 0 0 6597 19c5 libcli/raw/rawrequest.o
87
5580 0 0 5580 15cc libcli/raw/rawsearch.o
88
3034 0 0 3034 bda libcli/raw/rawsetfileinfo.o
89
5187 0 0 5187 1443 libcli/raw/rawtrans.o
90
2033 0 0 2033 7f1 libcli/raw/smb_signing.o
92
notice that the "data" and "bss" columns are all zero? That is
93
good. If there are any non-zero values in data or bss then that
94
indicates static data and is bad (as a rule of thumb).
96
Lets compare that result to the equivalent in Samba3::
98
text data bss dec hex filename
99
3978 0 0 3978 f8a libsmb/asn1.o
100
18963 0 288 19251 4b33 libsmb/cliconnect.o
101
2815 0 1024 3839 eff libsmb/clidgram.o
102
4038 0 0 4038 fc6 libsmb/clientgen.o
103
3337 664 256 4257 10a1 libsmb/clierror.o
104
10043 0 0 10043 273b libsmb/clifile.o
105
332 0 0 332 14c libsmb/clifsinfo.o
106
166 0 0 166 a6 libsmb/clikrb5.o
107
5212 0 0 5212 145c libsmb/clilist.o
108
1367 0 0 1367 557 libsmb/climessage.o
109
259 0 0 259 103 libsmb/clioplock.o
110
1584 0 0 1584 630 libsmb/cliprint.o
111
7565 0 256 7821 1e8d libsmb/cliquota.o
112
7694 0 0 7694 1e0e libsmb/clirap.o
113
27440 0 0 27440 6b30 libsmb/clirap2.o
114
2905 0 0 2905 b59 libsmb/clireadwrite.o
115
1698 0 0 1698 6a2 libsmb/clisecdesc.o
116
5517 0 0 5517 158d libsmb/clispnego.o
117
485 0 0 485 1e5 libsmb/clistr.o
118
8449 0 0 8449 2101 libsmb/clitrans.o
119
2053 0 4 2057 809 libsmb/conncache.o
120
3041 0 256 3297 ce1 libsmb/credentials.o
121
1261 0 1024 2285 8ed libsmb/doserr.o
122
14560 0 0 14560 38e0 libsmb/errormap.o
123
3645 0 0 3645 e3d libsmb/namecache.o
124
16815 0 8 16823 41b7 libsmb/namequery.o
125
1626 0 0 1626 65a libsmb/namequery_dc.o
126
14301 0 1076 15377 3c11 libsmb/nmblib.o
127
24516 0 2048 26564 67c4 libsmb/nterr.o
128
8661 0 8 8669 21dd libsmb/ntlmssp.o
129
3188 0 0 3188 c74 libsmb/ntlmssp_parse.o
130
4945 0 0 4945 1351 libsmb/ntlmssp_sign.o
131
1303 0 0 1303 517 libsmb/passchange.o
132
1221 0 0 1221 4c5 libsmb/pwd_cache.o
133
2475 0 4 2479 9af libsmb/samlogon_cache.o
134
10768 32 0 10800 2a30 libsmb/smb_signing.o
135
4524 0 16 4540 11bc libsmb/smbdes.o
136
5708 0 0 5708 164c libsmb/smbencrypt.o
137
7049 0 3072 10121 2789 libsmb/smberr.o
138
2995 0 0 2995 bb3 libsmb/spnego.o
139
3186 0 0 3186 c72 libsmb/trustdom_cache.o
140
1742 0 0 1742 6ce libsmb/trusts_util.o
141
918 0 28 946 3b2 libsmb/unexpected.o
143
notice all of the non-zero data and bss elements? Every bit of that
144
data is a bug waiting to happen.
146
Static data is evil as it has the following consequences:
147
- it makes code much less likely to be thread-safe
148
- it makes code much less likely to be recursion-safe
149
- it leads to subtle side effects when the same code is called from multiple places
150
- doesn't play well with shared libraries or plugins
152
Static data is particularly evil in library code (such as our internal
153
smb and rpc libraries). If you can get rid of all static data in
154
libraries then you can make some fairly strong guarantees about the
155
behaviour of functions in that library, which really helps.
157
Of course, it is possible to write code that uses static data and is
158
safe, it's just much harder to do that than just avoid static data in
159
the first place. We have been tripped up countless times by subtle
160
bugs in Samba due to the use of static data, so I think it is time to
161
start avoiding it in new code. Much of the core infrastructure of
162
Samba4 was specifically written to avoid static data, so I'm going to
163
be really annoyed if everyone starts adding lots of static data back
166
So, how do we avoid static data? The basic method is to use context
167
pointers. When reading the Samba4 code you will notice that just about
168
every function takes a pointer to a context structure as its first
169
argument. Any data that the function needs that isn't an explicit
170
argument to the function can be found by traversing that context.
172
Note that this includes all of the little caches that we have lying
173
all over the code in Samba3. I'm referring to the ones that generally
174
have a "static int initialised" and then some static string or integer
175
that remembers the last return value of the function. Get rid of them!
176
If you are *REALLY* absolutely completely certain that your personal
177
favourite mini-cache is needed then you should do it properly by
178
putting it into the appropriate context rather than doing it the lazy
179
way by putting it inside the target function. I would suggest however
180
that the vast majority of those little caches are useless - don't
181
stick it in unless you have really firm benchmarking results that show
182
that it is needed and helps by a significant amount.
184
Note that Samba4 is not yet completely clean of static data like
185
this. I've gotten the smbd/ directory down to 24 bytes of static data,
186
and libcli/raw/ down to zero. I've also gotten the ntvfs layer and all
187
backends down to just 8 bytes in ntvfs_base.c. The rest still needs
190
Also note that truly constant data is OK, and will not in fact show up
191
in the data and bss columns in "size" anyway (it will be included in
192
"text"). So you can have constant tables of protocol data.
198
Please see the separate document, lib/talloc/talloc_guide.txt
199
You _must_ read this if you want to program in Samba4.
205
One of the biggest changes in Samba4 is the universal use of interface
206
structures. Go take a look through include/smb_interfaces.h now to get
207
an idea of what I am talking about.
209
In Samba3 many of the core wire structures in the SMB protocol were
210
never explicitly defined in Samba. Instead, our parse and generation
211
functions just worked directly with wire buffers. The biggest problem
212
with this is that is tied our parse code with our "business logic"
213
much too closely, which meant the code got extremely confusing to
216
In Samba4 we have explicitly defined interface structures for
217
everything in the protocol. When we receive a buffer we always parse
218
it completely into one of these structures, then we pass a pointer to
219
that structure to a backend handler. What we must *not* do is make any
220
decisions about the data inside the parse functions. That is critical
221
as different backends will need different portions of the data. This
222
leads to a golden rule for Samba4:
224
"don't design interfaces that lose information"
226
In Samba3 our backends often received "condensed" versions of the
227
information sent from clients, but this inevitably meant that some
228
backends could not get at the data they needed to do what they wanted,
229
so from now on we should expose the backends to all of the available
230
information and let them choose which bits they want.
232
Ok, so now some of you will be thinking "this sounds just like our
233
msrpc code from Samba3", and while to some extent this is true there
234
are extremely important differences in the approach that are worth
237
In the Samba3 msrpc code we used explicit parse structures for all
238
msrpc functions. The problem is that we didn't just put all of the
239
real variables in these structures, we also put in all the artifacts
240
as well. A good example is the security descriptor strucrure that
241
looks like this in Samba3::
243
typedef struct security_descriptor_info
248
uint32 off_owner_sid;
259
The problem with this structure is all the off_* variables. Those are
260
not part of the interface, and do not appear in any real descriptions
261
of Microsoft security descriptors. They are parsing artifacts
262
generated by the IDL compiler that Microsoft use. That doesn't mean
263
they aren't needed on the wire - indeed they are as they tell the
264
parser where to find the following four variables, but they should
265
*NOT* be in the interface structure.
267
In Samba3 there were unwritten rules about which variables in a
268
structure a high level caller has to fill in and which ones are filled
269
in by the marshalling code. In Samba4 those rules are gone, because
270
the redundent artifact variables are gone. The high level caller just
271
sets up the real variables and the marshalling code worries about
272
generating the right offsets.
274
The same rule applies to strings. In many places in the SMB and MSRPC
275
protocols complex strings are used on the wire, with complex rules
276
about padding, format, alighment, termination etc. None of that
277
information is useful to a high level calling routine or to a backend - its
278
all just so much wire fluff. So, in Samba4 these strings are
279
just "char \*" and are always in our internal multi-byte format (which
280
is usually UTF8). It is up to the parse functions to worry about
281
translating the format and getting the padding right.
283
The one exception to this is the use of the WIRE_STRING type, but that
284
has a very good justification in terms of regression testing. Go and
285
read the comment in smb_interfaces.h about that now.
287
So, here is another rule to code by. When writing an interface
288
structure think carefully about what variables in the structure can be
289
left out as they are redundent. If some length is effectively defined
290
twice on the wire then only put it once in the packet. If a length can
291
be inferred from a null termination then do that and leave the length
292
out of the structure completely. Don't put redundent stuff in
299
Samba4 has an asynchronous design. That affects *lots* of the code,
300
and the implications of the asynchronous design needs to be considered
301
just about everywhere.
303
The first aspect of the async design to look at is the SMB client
304
library. Lets take a look at the following three functions in
305
libcli/raw/rawfile.c::
307
struct cli_request *smb_raw_seek_send(struct cli_tree *tree, struct smb_seek *parms);
308
NTSTATUS smb_raw_seek_recv(struct cli_request *req, struct smb_seek *parms);
309
NTSTATUS smb_raw_seek(struct cli_tree *tree, struct smb_seek *parms);
311
Go and read them now then come back.
313
Ok, first notice there there are 3 separate functions, whereas the
314
equivalent code in Samba3 had just one. Also note that the 3rd
315
function is extremely simple - its just a wrapper around calling the
318
The three separate functions are needed because we need to be able to
319
generate SMB calls asynchronously. The first call, which for smb calls
320
is always called smb_raw_XXXX_send(), constructs and sends a SMB
321
request and returns a "struct cli_request" which acts as a handle for
322
the request. The caller is then free to do lots of other calls if it
323
wants to, then when it is ready it can call the smb_raw_XXX_recv()
324
function to receive the reply.
326
If all you want is a synchronous call then call the 3rd interface, the
327
one called smb_raw_XXXX(). That just calls the first two in order, and
328
blocks waiting for the reply.
330
But what if you want to be called when the reply comes in? Yes, thats
331
possible. You can do things like this::
333
struct cli_request *req;
335
req = smb_raw_XXX_send(tree, params);
337
req->async.fn = my_callback;
338
req->async.private = my_private_data;
340
then in your callback function you can call the smb_raw_XXXX_recv()
341
function to receive the reply. Your callback will receive the "req"
342
pointer, which you can use to retrieve your private data from
345
Then all you need to do is ensure that the main loop in the client
346
library gets called. You can either do that by polling the connection
347
using cli_transport_pending() and cli_request_receive_next() or you
348
can use transport->idle.func to setup an idle function handler to call
349
back to your main code. Either way, you can build a fully async
352
In order to support all of this we have to make sure that when we
353
write a piece of library code (SMB, MSRPC etc) that we build the
354
separate _send() and _recv() functions. It really is worth the effort.
356
Now about async in smbd, a much more complex topic.
358
The SMB protocol is inherently async. Some functions (such as change
359
notify) often don't return for hours, while hundreds of other
360
functions pass through the socket. Take a look at the RAW-MUX test in
361
the Samba4 smbtorture to see some really extreme examples of the sort
362
of async operations that Windows supports. I particularly like the
363
open/open/close sequence where the 2nd open (which conflicts with the
364
first) succeeds because the subsequent close is answered out of order.
366
In Samba3 we handled this stuff very badly. We had awful "pending
367
request" queues that allocated full 128k packet buffers, and even with
368
all that crap we got the semantics wrong. In Samba4 I intend to make
369
sure we get this stuff right.
371
So, how do we do this? We now have an async interface between smbd and
372
the NTVFS backends. Whenever smbd calls into a backend the backend has
373
an option of answer the request in a synchronous fashion if it wants
374
to just like in Samba3, but it also has the option of answering the
375
request asynchronously. The only backend that currently does this is
376
the CIFS backend, but I hope the other backends will soon do this to.
378
To make this work you need to do things like this in the backend::
380
req->control_flags |= REQ_CONTROL_ASYNC;
382
that tells smbd that the backend has elected to reply later rather
383
than replying immediately. The backend must *only* do this if
384
req->async.send_fn is not NULL. If send_fn is NULL then it means that
385
the smbd front end cannot handle this function being replied to in an
388
If the backend does this then it is up to the backend to call
389
req->async.send_fn() when it is ready to reply. It the meantime smbd
390
puts the call on hold and goes back to answering other requests on the
393
Inside smbd you will find that there is code to support this. The most
394
obvious change is that smbd splits each SMB reply function into two
395
parts - just like the client library has a _send() and _recv()
396
function, so smbd has a _send() function and the parse function for
399
As an example go and have a look at reply_getatr_send() and
400
reply_getatr() in smb_server/reply.c. Read them? Good.
402
Notice that reply_getatr() sets up the req->async structure to contain
403
the send function. Thats how the backend gets to do an async reply, it
404
calls this function when it is ready. Also notice that reply_getatr()
405
only does the parsing of the request, and does not do the reply
406
generation. That is done by the _send() function.
408
The only missing piece in the Samba4 right now that prevents it being
409
fully async is that it currently does the low level socket calls (read
410
and write on sockets) in a blocking fashion. It does use select() to
411
make it somewhat async, but if a client were to send a partial packet
412
then delay before sending the rest then smbd would be stuck waiting
413
for the second half of the packet.
415
To fix this I plan on making the socket calls async as well, which
416
luckily will not involve any API changes in the core of smbd or the
417
library. It just involves a little bit of extra code in clitransport.c
418
and smbd/request.c. As a side effect I hope that this will also reduce
419
the average number of system calls required to answer a request, so we
420
may see a performance improvement.
426
One of the most noticeable changes in Samba4 is the introduction of
427
the NTVFS layer. This provided the initial motivation for the design
428
of Samba4 and in many ways lies at the heart of the design.
430
In Samba3 the main file serving process (smbd) combined the handling
431
of the SMB protocol with the mapping to POSIX semantics in the same
432
code. If you look in smbd/reply.c in Samba3 you see numerous places
433
where POSIX assumptions are mixed tightly with SMB parsing code. We
434
did have a VFS layer in Samba3, but it was a POSIX-like VFS layer, so
435
no matter how you wrote a plugin you could not bypass the POSIX
436
mapping decisions that had already been made before the VFS layer was
439
In Samba4 things are quite different. All SMB parsing is performed in
440
the smbd front end, then fully parsed requests are passed to the NTVFS
441
backend. That backend makes any semantic mapping decisions and fills
442
in the 'out' portion of the request. The front end is then responsible
443
for putting those results into wire format and sending them to the
446
Lets have a look at one of those request structures. Go and read the
447
definition of "union smb_write" and "enum write_level" in
448
include/smb_interfaces.h. (no, don't just skip reading it, really go
449
and read it. Yes, that means you!).
451
Notice the union? That's how Samba4 allows a single NTVFS backend
452
interface to handle the several different ways of doing a write
453
operation in the SMB protocol. Now lets look at one section of that
456
/* SMBwriteX interface */
458
enum write_level level;
474
see the "in" and "out" sections? The "in" section is for parameters
475
that the SMB client sends on the wire as part of the request. The smbd
476
front end parse code parses the wire request and fills in all those
477
parameters. It then calls the NTVFS interface which looks like this::
479
NTSTATUS (*write)(struct request_context *req, union smb_write *io);
481
and the NTVFS backend does the write request. The backend then fills
482
in the "out" section of the writex structure and gives the union back
483
to the front end (either by returning, or if done in an async fashion
484
then by calling the async send function. See the async discussion
485
elsewhere in this document).
487
The NTVFS backend knows which particular function is being requested
488
by looking at io->generic.level. Notice that this enum is also
489
repeated inside each of the sub-structures in the union, so the
490
backend could just as easily look at io->writex.level and would get
493
Notice also that some levels (such as splwrite) don't have an "out"
494
section. This happens because there is no return value apart from a
495
status code from those SMB calls.
497
So what about status codes? The status code is returned directly by
498
the backend NTVFS interface when the call is performed
499
synchronously. When performed asynchronously then the status code is
500
put into req->async.status before the req->async.send_fn() callback is
503
Currently the most complete NTVFS backend is the CIFS backend. I don't
504
expect this backend will be used much in production, but it does
505
provide the ideal test case for our NTVFS design. As it offers the
506
full capabilities that are possible with a CIFS server we can be sure
507
that we don't have any gaping holes in our APIs, and that the front
508
end code is flexible enough to handle any advances in the NT style
509
feature sets of Unix filesystems that make come along.
515
In Samba3 we supported just one process model. It just so happens that
516
the process model that Samba3 supported is the "right" one for most
517
users, but there are situations where this model wasn't ideal.
519
In Samba4 you can choose the smbd process model on the smbd command
523
DCERPC binding strings
524
----------------------
526
When connecting to a dcerpc service you need to specify a binding
531
TRANSPORT:host[flags]
533
where TRANSPORT is either ncacn_np for SMB or ncacn_ip_tcp for RPC/TCP
535
"host" is an IP or hostname or netbios name. If the binding string
536
identifies the server side of an endpoint, "host" may be an empty
539
"flags" can include a SMB pipe name if using the ncacn_np transport or
540
a TCP port number if using the ncacn_ip_tcp transport, otherwise they
541
will be auto-determined.
543
other recognised flags are:
545
sign : enable ntlmssp signing
546
seal : enable ntlmssp sealing
547
spnego : use SPNEGO instead of NTLMSSP authentication
548
krb5 : use KRB5 instead of NTLMSSP authentication
549
connect : enable rpc connect level auth (auth, but no sign or seal)
550
validate : enable the NDR validator
551
print : enable debugging of the packets
552
bigendian : use bigendian RPC
553
padcheck : check reply data for non-zero pad bytes
556
Here are some examples:
559
ncacn_np:myserver[samr]
560
ncacn_np:myserver[\pipe\samr]
561
ncacn_np:myserver[/pipe/samr]
562
ncacn_np:myserver[samr,sign,print]
563
ncacn_np:myserver[sign,spnego]
564
ncacn_np:myserver[\pipe\samr,sign,seal,bigendian]
565
ncacn_np:myserver[/pipe/samr,seal,validate]
567
ncacn_np:[/pipe/samr]
568
ncacn_ip_tcp:myserver
569
ncacn_ip_tcp:myserver[1024]
570
ncacn_ip_tcp:myserver[sign,seal]
571
ncacn_ip_tcp:myserver[spnego,seal]
574
IDEA: Maybe extend UNC names like this?
576
smbclient //server/share
577
smbclient //server/share[sign,seal,spnego]
581
The various handles that are used in the RPC servers should be created and
582
fetch using the dcesrv_handle_* functions.
584
Use dcesrv_handle_new(struct dcesrv_connection \*, uint8 handle_type) to obtain
585
a new handle of the specified type. Handle types are unique within each
588
The handle can later be fetched again using::
590
struct dcesrv_handle *dcesrv_handle_fetch(struct dcesrv_connection *dce_conn, struct policy_handle *p, uint8 handle_type)
594
dcesrv_handle_destroy(struct dcesrv_handle *).
596
User data should be stored in the 'data' member of the dcesrv_handle struct.
606
- command line handling
615
don't zero structures! avoid ZERO_STRUCT() and talloc_zero()
618
GMT vs TZ in printout of QFILEINFO timezones
620
put in full UNC path in tconx
622
test timezone handling by using a server in different zone from client
624
do {} while (0) system
626
NT_STATUS_IS_OK() is NOT the opposite of NT_STATUS_IS_ERR()
628
need to implement secondary parts of trans2 and nttrans in server and
631
document access_mask in openx reply
633
check all capabilities and flag1, flag2 fields (eg. EAs)
635
large files -> pass thru levels
637
setpathinfo is very fussy about null termination of the file name
639
the overwrite flag doesn't seem to work on setpathinfo RENAME_INFORMATION
641
END_OF_FILE_INFORMATION and ALLOCATION_INFORMATION don't seem to work
644
on w2k3 setpathinfo DISPOSITION_INFORMATION fails, but does have an
645
effect. It leaves the file with SHARING_VIOLATION.
647
on w2k3 trans2 setpathinfo with any invalid low numbered level causes
648
the file to get into a state where DELETE_PENDING is reported, and the
649
file cannot be deleted until you reboot
651
trans2 qpathinfo doesn't see the delete_pending flag correctly, but
656
add programming documentation note about lp_set_cmdline()
658
need to add a wct checking function in all client parsing code,
659
similar to REQ_CHECK_WCT()
661
need to make sure that NTTIME is a round number of seconds when
662
converted from time_t
664
not using a zero next offset in SMB_FILE_STREAM_INFORMATION for last
665
entry causes explorer exception under win2000
668
if the server sets the session key the same for a second SMB socket as
669
an initial socket then the client will not re-authenticate, it will go
670
straight to a tconx, skipping session setup and will use all the
671
existing parameters! This allows two sockets with the same keys!?
674
removed blocking lock code, we now queue the whole request the same as
675
we queue any other pending request. This allows for things like a
676
close() while a pending blocking lock is being processed to operate
679
disabled change notify code
689
client library and test code
690
----------------------------
692
convert client library to new structure
693
get smbtorture working
694
get smbclient working
695
expand client library for all requests
696
write per-request test suite
697
gentest randomised test suite
698
separate client code as a library for non-Samba use
702
add remaining core SMB requests
706
fix auth models (share, server, rpc)
707
get net command working
708
connect CIFS backend to server level auth
711
reconnect printing code
712
restore removed smbd options
713
add smb.conf macro substitution code
714
add async backend notification
715
add generic timer event mechanism
721
new server models (break 1-1)
722
test clustered models
723
add fulcrum statistics gathering
736
- store all config in config.ldb
738
- load from smb.conf if modtime changes
740
- dump full system config with ldbsearch
742
- will need the ability to form a ldif difference file
744
- advanced web admin via a web ldb editor
746
- normal web admin via web forms -> ldif
748
- config.ldb will replace smb.conf, secrets.tdb, shares.tdb etc
750
- subsystems in smbd will load config parameters for a share
751
using ldbsearch at tconx time
753
- need a loadparm equivalent module that provides parameter defaults
755
- start smbd like this: "smbd -C tdb://etc/samba/config.ldb" or
756
"smbd -C ldapi://var/run/ldapi"
758
- write a tool that generates a template ldap schema from an existing
761
- no need to HUP smbd to reload config
763
- how to handle configuration comments? same problem as SWAT
767
add a test case for last_entry_offset in trans2 find interfaces
770
no 137 resolution not possible
771
should not fallback to anon when pass supplied
772
should check pass-thu cap bit, and skip lots of tests
773
possibly allow the test suite to say "allow oversized replies" for trans2 and other calls
774
handle servers that don't have the setattre call in torture
775
add max file coponent length test and max path len test
776
check for alloc failure in all core reply.c and trans2.c code where allocation size depends on client parameter
778
case-insenstive idea:
779
all filenames on disk lowercase
780
real case in extended attribute
781
keep cache of what dirs are all lowercase
782
when searching for name, don't search if dir is definately all lowercase
783
when creating file, use dnotify to tell if someone else creates at
787
make mangle cache dynamic size
788
fill during a dir scan
790
destroy cache after 30 sec
791
destroy if a 2nd dir scan happens on same dir
added
removed
prog_guide4.txt
