xref: /samba/
Name Date Size

..29-Nov-20194 KiB

.bzrignoreH A D26-Nov-20192.2 KiB

.gitattributesH A D17-Aug-201835

.github/H05-Dec-20184 KiB

.gitignoreH A D26-Nov-20192.2 KiB

.gitlab-ci-private.ymlH A D18-Feb-201931

.gitlab-ci.ymlH A D11-Dec-20199.7 KiB

.testr.confH A D25-Sep-2017186

.ycm_extra_conf.pyH A D24-Aug-20189.9 KiB

auth/H06-Jan-20204 KiB

bootstrap/H10-Dec-20194 KiB

BUILD_SYSTEMS.txtH A D25-Sep-20173.5 KiB

buildtools/H25-Sep-20174 KiB

callcatcher-exceptions.grepH A D25-Sep-2017149

configureH A D14-Dec-2018318

configure.developerH A D25-Sep-201766

COPYINGH A D25-Sep-201734.3 KiB

coverity/H25-Sep-20174 KiB

ctdb/H13-Nov-20194 KiB

dfs_server/H04-May-20184 KiB

docs-xml/H09-Oct-20194 KiB

dynconfig/H13-Nov-20194 KiB

examples/H31-Aug-20184 KiB

file_server/H02-Nov-20184 KiB

include/H25-Sep-20174 KiB

install_with_python.shH A D25-Sep-20171.5 KiB

lib/H07-Aug-20194 KiB

libcli/H07-Aug-20194 KiB

libds/common/H25-Sep-20174 KiB

libgpo/H13-Jan-20204 KiB

librpc/H18-Dec-20194 KiB

MakefileH A D02-Sep-20192.7 KiB

nsswitch/H22-Nov-20194 KiB

packaging/H05-Sep-20184 KiB

PFIF.txtH A D25-Sep-2017188

pidl/H10-Dec-20194 KiB

python/H24-Jun-20194 KiB

README.cifs-utilsH A D25-Sep-2017270

README.CodingH A D22-Nov-201813 KiB

README.contributingH A D25-Sep-20175 KiB

README.mdH A D21-Jun-20196.2 KiB

release-scripts/H25-Sep-20174 KiB

script/H21-Jan-20204 KiB

SECURITY.mdH A D09-Sep-2019516

selftest/H21-Jan-20204 KiB

setup.cfgH A D06-Sep-2018525

source3/H11-Jan-20204 KiB

source4/H07-Mar-20194 KiB

testdata/H09-Jan-20194 KiB

testprogs/H25-Sep-20174 KiB

tests/H17-Feb-20194 KiB

testsuite/H12-Mar-20194 KiB

third_party/H17-Aug-20194 KiB

VERSIONH A D21-Jan-20206.1 KiB

WHATSNEW.txtH A D21-Jan-20201.5 KiB

wintest/H02-Jul-20194 KiB

wscriptH A D25-Sep-201919.5 KiB

wscript_buildH A D10-Dec-20194.8 KiB

wscript_build_embedded_heimdalH A D05-Sep-2018109

wscript_build_system_heimdalH A D05-Sep-2018107

wscript_build_system_mitkrb5H A D05-Sep-2018138

wscript_configure_embedded_heimdalH A D30-Jan-201938

wscript_configure_system_gnutlsH A D08-Oct-20191 KiB

wscript_configure_system_heimdalH A D13-Nov-20194.3 KiB

wscript_configure_system_mitkrb5H A D06-Dec-201813 KiB

README.cifs-utils

1As of Sunday March 7th, 2010, the Linux CIFS utilities are no longer
2part of the samba suite of tools and have been split off into their own
3project. Please see this webpage for information on how to acquire and
4build them:
5
6    http://linux-cifs.samba.org/cifs-utils/
7
8

README.Coding

1Coding conventions in the Samba tree
2~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3
4.. contents::
5
6===========
7Quick Start
8===========
9
10Coding style guidelines are about reducing the number of unnecessary
11reformatting patches and making things easier for developers to work
12together.
13You don't have to like them or even agree with them, but once put in place
14we all have to abide by them (or vote to change them).  However, coding
15style should never outweigh coding itself and so the guidelines
16described here are hopefully easy enough to follow as they are very
17common and supported by tools and editors.
18
19The basic style for C code is the Linux kernel coding style (See
20Documentation/CodingStyle in the kernel source tree). This closely matches
21what most Samba developers use already anyways, with a few exceptions as
22mentioned below.
23
24The coding style for Python code is documented in PEP8,
25https://www.python.org/dev/peps/pep-0008/. New Python code should be compatible
26with Python 2.6, 2.7, and Python 3.4 onwards. This means using Python 3 syntax
27with the appropriate 'from __future__' imports.
28
29But to save you the trouble of reading the Linux kernel style guide, here
30are the highlights.
31
32* Maximum Line Width is 80 Characters
33  The reason is not about people with low-res screens but rather sticking
34  to 80 columns prevents you from easily nesting more than one level of
35  if statements or other code blocks.  Use source3/script/count_80_col.pl
36  to check your changes.
37
38* Use 8 Space Tabs to Indent
39  No whitespace fillers.
40
41* No Trailing Whitespace
42  Use source3/script/strip_trail_ws.pl to clean up your files before
43  committing.
44
45* Follow the K&R guidelines.  We won't go through all of them here. Do you
46  have a copy of "The C Programming Language" anyways right? You can also use
47  the format_indent.sh script found in source3/script/ if all else fails.
48
49
50
51============
52Editor Hints
53============
54
55Emacs
56-----
57Add the follow to your $HOME/.emacs file:
58
59  (add-hook 'c-mode-hook
60	(lambda ()
61		(c-set-style "linux")
62		(c-toggle-auto-state)))
63
64
65Vi
66--
67(Thanks to SATOH Fumiyasu <fumiyas@osstech.jp> for these hints):
68
69For the basic vi editor included with all variants of \*nix, add the
70following to $HOME/.exrc:
71
72  set tabstop=8
73  set shiftwidth=8
74
75For Vim, the following settings in $HOME/.vimrc will also deal with
76displaying trailing whitespace:
77
78  if has("syntax") && (&t_Co > 2 || has("gui_running"))
79	syntax on
80	function! ActivateInvisibleCharIndicator()
81		syntax match TrailingSpace "[ \t]\+$" display containedin=ALL
82		highlight TrailingSpace ctermbg=Red
83	endf
84	autocmd BufNewFile,BufRead * call ActivateInvisibleCharIndicator()
85  endif
86  " Show tabs, trailing whitespace, and continued lines visually
87  set list listchars=tab:»·,trail:·,extends:…
88
89  " highlight overly long lines same as TODOs.
90  set textwidth=80
91  autocmd BufNewFile,BufRead *.c,*.h exec 'match Todo /\%>' . &textwidth . 'v.\+/'
92
93clang-format
94------------
95BasedOnStyle: LLVM
96IndentWidth: 8
97UseTab: true
98BreakBeforeBraces: Linux
99AllowShortIfStatementsOnASingleLine: false
100IndentCaseLabels: false
101BinPackParameters: false
102BinPackArguments: false
103SortIncludes: false
104
105
106=========================
107FAQ & Statement Reference
108=========================
109
110Comments
111--------
112
113Comments should always use the standard C syntax.  C++
114style comments are not currently allowed.
115
116The lines before a comment should be empty. If the comment directly
117belongs to the following code, there should be no empty line
118after the comment, except if the comment contains a summary
119of multiple following code blocks.
120
121This is good:
122
123	...
124	int i;
125
126	/*
127	 * This is a multi line comment,
128	 * which explains the logical steps we have to do:
129	 *
130	 * 1. We need to set i=5, because...
131	 * 2. We need to call complex_fn1
132	 */
133
134	/* This is a one line comment about i = 5. */
135	i = 5;
136
137	/*
138	 * This is a multi line comment,
139	 * explaining the call to complex_fn1()
140	 */
141	ret = complex_fn1();
142	if (ret != 0) {
143	...
144
145	/**
146	 * @brief This is a doxygen comment.
147	 *
148	 * This is a more detailed explanation of
149	 * this simple function.
150	 *
151	 * @param[in]   param1     The parameter value of the function.
152	 *
153	 * @param[out]  result1    The result value of the function.
154	 *
155	 * @return              0 on success and -1 on error.
156	 */
157	int example(int param1, int *result1);
158
159This is bad:
160
161	...
162	int i;
163	/*
164	 * This is a multi line comment,
165	 * which explains the logical steps we have to do:
166	 *
167	 * 1. We need to set i=5, because...
168	 * 2. We need to call complex_fn1
169	 */
170	/* This is a one line comment about i = 5. */
171	i = 5;
172	/*
173	 * This is a multi line comment,
174	 * explaining the call to complex_fn1()
175	 */
176	ret = complex_fn1();
177	if (ret != 0) {
178	...
179
180	/*This is a one line comment.*/
181
182	/* This is a multi line comment,
183	   with some more words...*/
184
185	/*
186	 * This is a multi line comment,
187	 * with some more words...*/
188
189Indention & Whitespace & 80 columns
190-----------------------------------
191
192To avoid confusion, indentations have to be tabs with length 8 (not 8
193' ' characters).  When wrapping parameters for function calls,
194align the parameter list with the first parameter on the previous line.
195Use tabs to get as close as possible and then fill in the final 7
196characters or less with whitespace.  For example,
197
198	var1 = foo(arg1, arg2,
199		   arg3);
200
201The previous example is intended to illustrate alignment of function
202parameters across lines and not as encourage for gratuitous line
203splitting.  Never split a line before columns 70 - 79 unless you
204have a really good reason. Be smart about formatting.
205
206One exception to the previous rule is function calls, declarations, and
207definitions. In function calls, declarations, and definitions, either the
208declaration is a one-liner, or each parameter is listed on its own
209line. The rationale is that if there are many parameters, each one
210should be on its own line to make tracking interface changes easier.
211
212
213If, switch, & Code blocks
214-------------------------
215
216Always follow an 'if' keyword with a space but don't include additional
217spaces following or preceding the parentheses in the conditional.
218This is good:
219
220	if (x == 1)
221
222This is bad:
223
224	if ( x == 1 )
225
226Yes we have a lot of code that uses the second form and we are trying
227to clean it up without being overly intrusive.
228
229Note that this is a rule about parentheses following keywords and not
230functions.  Don't insert a space between the name and left parentheses when
231invoking functions.
232
233Braces for code blocks used by for, if, switch, while, do..while, etc.
234should begin on the same line as the statement keyword and end on a line
235of their own. You should always include braces, even if the block only
236contains one statement.  NOTE: Functions are different and the beginning left
237brace should be located in the first column on the next line.
238
239If the beginning statement has to be broken across lines due to length,
240the beginning brace should be on a line of its own.
241
242The exception to the ending rule is when the closing brace is followed by
243another language keyword such as else or the closing while in a do..while
244loop.
245
246Good examples:
247
248	if (x == 1) {
249		printf("good\n");
250	}
251
252	for (x=1; x<10; x++) {
253		print("%d\n", x);
254	}
255
256	for (really_really_really_really_long_var_name=0;
257	     really_really_really_really_long_var_name<10;
258	     really_really_really_really_long_var_name++)
259	{
260		print("%d\n", really_really_really_really_long_var_name);
261	}
262
263	do {
264		printf("also good\n");
265	} while (1);
266
267Bad examples:
268
269	while (1)
270	{
271		print("I'm in a loop!\n"); }
272
273	for (x=1;
274	     x<10;
275	     x++)
276	{
277		print("no good\n");
278	}
279
280	if (i < 10)
281		print("I should be in braces.\n");
282
283
284Goto
285----
286
287While many people have been academically taught that "goto"s are
288fundamentally evil, they can greatly enhance readability and reduce memory
289leaks when used as the single exit point from a function. But in no Samba
290world what so ever is a goto outside of a function or block of code a good
291idea.
292
293Good Examples:
294
295	int function foo(int y)
296	{
297		int *z = NULL;
298		int ret = 0;
299
300		if (y < 10) {
301			z = malloc(sizeof(int) * y);
302			if (z == NULL) {
303				ret = 1;
304				goto done;
305			}
306		}
307
308		print("Allocated %d elements.\n", y);
309
310	 done:
311		if (z != NULL) {
312			free(z);
313		}
314
315		return ret;
316	}
317
318
319Primitive Data Types
320--------------------
321
322Samba has large amounts of historical code which makes use of data types
323commonly supported by the C99 standard. However, at the time such types
324as boolean and exact width integers did not exist and Samba developers
325were forced to provide their own.  Now that these types are guaranteed to
326be available either as part of the compiler C99 support or from
327lib/replace/, new code should adhere to the following conventions:
328
329  * Booleans are of type "bool" (not BOOL)
330  * Boolean values are "true" and "false" (not True or False)
331  * Exact width integers are of type [u]int[8|16|32|64]_t
332
333Most of the time a good name for a boolean variable is 'ok'. Here is an
334example we often use:
335
336	bool ok;
337
338	ok = foo();
339	if (!ok) {
340		/* do something */
341	}
342
343It makes the code more readable and is easy to debug.
344
345Typedefs
346--------
347
348Samba tries to avoid "typedef struct { .. } x_t;" so we do always try to use
349"struct x { .. };". We know there are still such typedefs in the code,
350but for new code, please don't do that anymore.
351
352Initialize pointers
353-------------------
354
355All pointer variables MUST be initialized to NULL. History has
356demonstrated that uninitialized pointer variables have lead to various
357bugs and security issues.
358
359Pointers MUST be initialized even if the assignment directly follows
360the declaration, like pointer2 in the example below, because the
361instructions sequence may change over time.
362
363Good Example:
364
365	char *pointer1 = NULL;
366	char *pointer2 = NULL;
367
368	pointer2 = some_func2();
369
370	...
371
372	pointer1 = some_func1();
373
374Bad Example:
375
376	char *pointer1;
377	char *pointer2;
378
379	pointer2 = some_func2();
380
381	...
382
383	pointer1 = some_func1();
384
385Make use of helper variables
386----------------------------
387
388Please try to avoid passing function calls as function parameters
389in new code. This makes the code much easier to read and
390it's also easier to use the "step" command within gdb.
391
392Good Example:
393
394	char *name = NULL;
395	int ret;
396
397	name = get_some_name();
398	if (name == NULL) {
399		...
400	}
401
402	ret = some_function_my_name(name);
403	...
404
405
406Bad Example:
407
408	ret = some_function_my_name(get_some_name());
409	...
410
411Please try to avoid passing function return values to if- or
412while-conditions. The reason for this is better handling of code under a
413debugger.
414
415Good example:
416
417	x = malloc(sizeof(short)*10);
418	if (x == NULL) {
419		fprintf(stderr, "Unable to alloc memory!\n");
420	}
421
422Bad example:
423
424	if ((x = malloc(sizeof(short)*10)) == NULL ) {
425		fprintf(stderr, "Unable to alloc memory!\n");
426	}
427
428There are exceptions to this rule. One example is walking a data structure in
429an iterator style:
430
431	while ((opt = poptGetNextOpt(pc)) != -1) {
432		   ... do something with opt ...
433	}
434
435Another exception: DBG messages for example printing a SID or a GUID:
436Here we don't expect any surprise from the printing functions, and the
437main reason of this guideline is to make debugging easier. That reason
438rarely exists for this particular use case, and we gain some
439efficiency because the DBG_ macros don't evaluate their arguments if
440the debuglevel is not high enough.
441
442	if (!NT_STATUS_IS_OK(status)) {
443		struct dom_sid_buf sid_buf;
444		struct GUID_txt_buf guid_buf;
445		DBG_WARNING(
446		    "objectSID [%s] for GUID [%s] invalid\n",
447		    dom_sid_str_buf(objectsid, &sid_buf),
448		    GUID_buf_string(&cache->entries[idx], &guid_buf));
449	}
450
451But in general, please try to avoid this pattern.
452
453
454Control-Flow changing macros
455----------------------------
456
457Macros like NT_STATUS_NOT_OK_RETURN that change control flow
458(return/goto/etc) from within the macro are considered bad, because
459they look like function calls that never change control flow. Please
460do not use them in new code.
461
462The only exception is the test code that depends repeated use of calls
463like CHECK_STATUS, CHECK_VAL and others.
464
465
466Error and out logic
467-------------------
468
469Don't do this:
470
471	frame = talloc_stackframe();
472
473	if (ret == LDB_SUCCESS) {
474		if (result->count == 0) {
475			ret = LDB_ERR_NO_SUCH_OBJECT;
476		} else {
477			struct ldb_message *match =
478				get_best_match(dn, result);
479			if (match == NULL) {
480				TALLOC_FREE(frame);
481				return LDB_ERR_OPERATIONS_ERROR;
482			}
483			*msg = talloc_move(mem_ctx, &match);
484		}
485	}
486
487	TALLOC_FREE(frame);
488	return ret;
489
490It should be:
491
492	frame = talloc_stackframe();
493
494	if (ret != LDB_SUCCESS) {
495		TALLOC_FREE(frame);
496		return ret;
497	}
498
499	if (result->count == 0) {
500		TALLOC_FREE(frame);
501		return LDB_ERR_NO_SUCH_OBJECT;
502	}
503
504	match = get_best_match(dn, result);
505	if (match == NULL) {
506		TALLOC_FREE(frame);
507		return LDB_ERR_OPERATIONS_ERROR;
508	}
509
510	*msg = talloc_move(mem_ctx, &match);
511	TALLOC_FREE(frame);
512	return LDB_SUCCESS;
513
514
515DEBUG statements
516----------------
517
518Use these following macros instead of DEBUG:
519
520DBG_ERR	log level 0		error conditions
521DBG_WARNING	log level 1		warning conditions
522DBG_NOTICE	log level 3		normal, but significant, condition
523DBG_INFO	log level 5		informational message
524DBG_DEBUG	log level 10		debug-level message
525
526Example usage:
527
528DBG_ERR("Memory allocation failed\n");
529DBG_DEBUG("Received %d bytes\n", count);
530
531The messages from these macros are automatically prefixed with the
532function name.
533

README.contributing

1How to contribute a patch to Samba
2----------------------------------
3
4Simple, just make the code change, and email it as either a "diff -u"
5change, or as a "git format-patch" change against the original source
6code to samba-technical@lists.samba.org, or attach it to a bug report at
7http://bugzilla.samba.org
8
9For larger code changes, breaking the changes up into a set of simple
10patches, each of which does a single thing, are much easier to review.
11Patch sets like that will most likely have an easier time being merged
12into the Samba code than large single patches that make lots of
13changes in one large diff.
14
15Ownership of the contributed code
16---------------------------------
17
18Samba is a project with distributed copyright ownership, which means
19we prefer the copyright on parts of Samba to be held by individuals
20rather than corporations if possible. There are historical legal
21reasons for this, but one of the best ways to explain it is that it's
22much easier to work with individuals who have ownership than corporate
23legal departments if we ever need to make reasonable compromises with
24people using and working with Samba.
25
26We track the ownership of every part of Samba via git, our source code
27control system, so we know the provenance of every piece of code that
28is committed to Samba.
29
30So if possible, if you're doing Samba changes on behalf of a company
31who normally owns all the work you do please get them to assign
32personal copyright ownership of your changes to you as an individual,
33that makes things very easy for us to work with and avoids bringing
34corporate legal departments into the picture.
35
36If you can't do this we can still accept patches from you owned by
37your employer under a standard employment contract with corporate
38copyright ownership. It just requires a simple set-up process first.
39
40We use a process very similar to the way things are done in the Linux
41kernel community, so it should be very easy to get a sign off from
42your corporate legal department. The only changes we've made are to
43accommodate the licenses we use, which are GPLv3 and LGPLv3 (or later)
44whereas the Linux kernel uses GPLv2.
45
46The process is called signing.
47
48How to sign your work
49---------------------
50
51Once you have permission to contribute to Samba from
52your employer, simply email a copy of the following text
53from your corporate email address to contributing@samba.org
54
55------------------------------------------------------------
56Samba Developer's Certificate of Origin. Version 1.0
57
58By making a contribution to this project, I certify that:
59
60(a) The contribution was created in whole or in part by me and I
61    have the right to submit it under the appropriate
62    version of the GNU General Public License; or
63
64(b) The contribution is based upon previous work that, to the best
65    of my knowledge, is covered under an appropriate open source
66    license and I have the right under that license to submit that
67    work with modifications, whether created in whole or in part
68    by me, under the GNU General Public License, in the
69    appropriate version; or
70
71(c) The contribution was provided directly to me by some other
72    person who certified (a) or (b) and I have not modified
73    it.
74
75(d) I understand and agree that this project and the
76    contribution are public and that a record of the
77    contribution (including all metadata and personal
78    information I submit with it, including my sign-off) is
79    maintained indefinitely and may be redistributed
80    consistent with the Samba Team's policies and the
81    requirements of the GNU GPL where they are relevant.
82
83(e) I am granting this work to this project under the terms of both
84    the GNU General Public License and the GNU Lesser General Public
85    License as published by the Free Software Foundation; either version
86    3 of these Licenses, or (at the option of the project) any later
87    version.
88
89    http://www.gnu.org/licenses/gpl-3.0.html
90    http://www.gnu.org/licenses/lgpl-3.0.html
91------------------------------------------------------------
92
93We will maintain a copy of that email as a record that you have the
94rights to contribute code to Samba under the required licenses whilst
95working for the company where the email came from.
96
97Then when sending in a patch via the normal mechanisms described
98above, add a line that states:
99
100Signed-off-by: Random J Developer <random@developer.example.org>
101
102using your real name and the email address you sent the original email
103you used to send the Samba Developer's Certificate of Origin to us
104(sorry, no pseudonyms or anonymous contributions.)
105
106That's it ! Such code can then quite happily contain changes that have
107copyright messages such as :
108
109        (C) Example Corporation.
110
111and can be merged into the Samba codebase in the same way as patches
112from any other individual. You don't need to send in a copy of the
113Samba Developer's Certificate of Origin for each patch, or inside each
114patch. Just the sign-off message is all that is required once we've
115received the initial email.
116
117Have fun and happy Samba hacking !
118
119The Samba Team.
120
121

README.md

1About Samba
2===========
3
4Samba is the standard Windows interoperability suite of
5programs for Linux and Unix.
6Samba is Free Software licensed under the GNU General Public License and
7the Samba project is a member of the Software Freedom Conservancy.
8Since 1992, Samba has provided secure, stable and fast file and print services
9for all clients using the SMB/CIFS protocol, such as all versions of DOS
10and Windows, OS/2, Linux and many others.
11Samba is an important component to seamlessly integrate Linux/Unix Servers and
12Desktops into Active Directory environments. It can function both as a
13domain controller or as a regular domain member.
14
15
16NOTE: Installation instructions may be found
17      for the file/print server and domain member in:
18      docs/htmldocs/Samba3-HOWTO/install.html
19
20For the AD DC implementation a full HOWTO is provided at:
21      https://wiki.samba.org/index.php/Samba4/HOWTO
22
23Community guidelines can be read at:
24      https://wiki.samba.org/index.php/How_to_do_Samba:_Nicely
25
26This software is freely distributable under the GNU public license, a
27copy of which you should have received with this software (in a file
28called COPYING).
29
30
31
32CONTRIBUTIONS
33=============
34
351. To contribute via GitLab
36  - fork the official Samba team repository on GitLab
37      * see https://gitlab.com/samba-team/samba
38  - become familiar with the coding standards as described in README.Coding
39  - make sure you read the Samba copyright policy
40      * see https://www.samba.org/samba/devel/copyright-policy.html
41  - create a feature branch
42  - make changes
43  - when committing, be sure to add signed-off-by tags
44      * see https://wiki.samba.org/index.php/CodeReview#commit_message_tags
45  - send a merge request for your branch through GitLab
46  - this will send an email to everyone registered on GitLab
47  - discussion happens on the samba-technical mailing list as described below
48  - more info on using Git for Samba development can be found on the Samba Wiki
49      * see https://wiki.samba.org/index.php/Using_Git_for_Samba_Development
50
512. If you want to contribute to the development of the software then
52please join the mailing list. The Samba team accepts patches
53(preferably in "diff -u" format, see https://www.samba.org/samba/devel/
54for more details) and are always glad to receive feedback or
55suggestions to the address samba@lists.samba.org.  More information
56on the various Samba mailing lists can be found at https://lists.samba.org/.
57
58You can also get the Samba sourcecode straight from the git repository - see
59https://wiki.samba.org/index.php/Using_Git_for_Samba_Development.
60
61If you like a particular feature then look through the git change-log
62(on the web at https://gitweb.samba.org/?p=samba.git;a=summary) and see
63who added it, then send them an email.
64
65Remember that free software of this kind lives or dies by the response
66we get. If no one tells us they like it then we'll probably move onto
67something else.
68
69
70MORE INFO
71=========
72
73DOCUMENTATION
74-------------
75
76There is quite a bit of documentation included with the package,
77including man pages, and lots of .html files with hints and useful
78info. This is also available from the webpage. There is a growing
79collection of information under docs/.
80
81A list of Samba documentation in languages other than English is
82available on the webpage.
83
84If you would like to help with the documentation, please coordinate
85on the samba@lists.samba.org mailing list.  See the next section for details
86on subscribing to samba mailing lists.
87
88
89MAILING LIST
90------------
91
92Please do NOT send subscription/unsubscription requests to the lists!
93
94There is a mailing list for discussion of Samba.  For details go to
95<https://lists.samba.org/> or send mail to <samba-subscribe@lists.samba.org>
96
97There is also an announcement mailing list where new versions are
98announced.  To subscribe go to <https://lists.samba.org/> or send mail
99to <samba-announce-subscribe@lists.samba.org>.  All announcements also
100go to the samba list, so you only need to be on one.
101
102For details of other Samba mailing lists and for access to archives, see
103<https://lists.samba.org/>
104
105
106MAILING LIST ETIQUETTE
107----------------------
108
109A few tips when submitting to this or any mailing list.
110
1111. Make your subject short and descriptive. Avoid the words "help" or
112   "Samba" in the subject. The readers of this list already know that
113   a) you need help, and b) you are writing about samba (of course,
114   you may need to distinguish between Samba PDC and other file
115   sharing software). Avoid phrases such as "what is" and "how do
116   i". Some good subject lines might look like "Slow response with
117   Excel files" or "Migrating from Samba PDC to NT PDC".
118
1192. If you include the original message in your reply, trim it so that
120   only the relevant lines, enough to establish context, are
121   included. Chances are (since this is a mailing list) we've already
122   read the original message.
123
1243. Trim irrelevant headers from the original message in your
125   reply. All we need to see is a) From, b) Date, and c) Subject. We
126   don't even really need the Subject, if you haven't changed
127   it. Better yet is to just preface the original message with "On
128   [date] [someone] wrote:".
129
1304. Please don't reply to or argue about spam, spam filters or viruses
131   on any Samba lists. We do have a spam filtering system that is
132   working quite well thank you very much but occasionally unwanted
133   messages slip through. Deal with it.
134
1355. Never say "Me too." It doesn't help anyone solve the
136   problem. Instead, if you ARE having the same problem, give more
137   information. Have you seen something that the other writer hasn't
138   mentioned, which may be helpful?
139
1406. If you ask about a problem, then come up with the solution on your
141   own or through another source, by all means post it. Someone else
142   may have the same problem and is waiting for an answer, but never
143   hears of it.
144
1457. Give as much *relevant* information as possible such as Samba
146   release number, OS, kernel version, etc...
147
1488. RTFM. Google.
149
150
151WEBSITE
152-------
153
154A Samba website has been setup with lots of useful info. Connect to:
155
156https://www.samba.org/
157
158As well as general information and documentation, this also has searchable
159archives of the mailing list and links to other useful resources such as
160the wiki.
161