xref: /samba/
Name Date Size

..27-Apr.-20224 KiB

.bzrignoreH A D11-May-20222.3 KiB

.editorconfigH A D28-Feb.-2022520

.gitattributesH A D17-Aug.-201835

.github/H05-Dec.-20184 KiB

.gitignoreH A D11-May-20222.3 KiB

.gitlab-ci-coverage-runners.ymlH A D13-Apr.-2021253

.gitlab-ci-coverage.ymlH A D13-Apr.-2021311

.gitlab-ci-default-runners.ymlH A D13-Apr.-20211.9 KiB

.gitlab-ci-default.ymlH A D13-Oct.-2021245

.gitlab-ci-main.ymlH A D26-Jun.-202220.1 KiB

.gitlab-ci-private.ymlH A D13-Apr.-2021133

.gitlab-ci.ymlH A D13-Apr.-202137

.testr.confH A D25-Sep.-2017186

.ycm_extra_conf.pyH A D24-Aug.-20189.9 KiB

auth/H26-Jun.-20224 KiB

bootstrap/H26-Jun.-20224 KiB

buildtools/H01-Apr.-20224 KiB

callcatcher-exceptions.grepH A D25-Sep.-2017149

configureH A D30-Mar.-2022392

configure.developerH A D25-Sep.-201766

COPYINGH A D25-Sep.-201734.3 KiB

coverity/H25-Sep.-20174 KiB

ctdb/H03-May-20224 KiB

dfs_server/H28-Aug.-20204 KiB

docs-xml/H22-Jun.-20224 KiB

dynconfig/H01-Apr.-20214 KiB

examples/H13-Jun.-20204 KiB

file_server/H29-Apr.-20214 KiB

GPG_AA99442FB680B620_replaces_6F33915B6568B7EA.txtH A D08-Mar.-20211 KiB

include/H25-Sep.-20174 KiB

lib/H28-Apr.-20214 KiB

libcli/H07-Aug.-20194 KiB

libds/common/H25-Sep.-20174 KiB

libgpo/H27-Jun.-20224 KiB

librpc/H14-Jul.-20214 KiB

MakefileH A D08-Mar.-20212.8 KiB

nsswitch/H19-May-20224 KiB

packaging/H06-Apr.-20224 KiB

PFIF.txtH A D13-Jun.-2020158

pidl/H20-Mar.-20204 KiB

python/H10-May-20224 KiB

README.cifs-utilsH A D25-Sep.-2017270

README.Coding.mdH A D03-Aug.-202012.9 KiB

README.contributingH A D08-Mar.-20215 KiB

README.mdH A D13-Jun.-20204.8 KiB

release-scripts/H03-Mar.-20224 KiB

script/H10-Jun.-20224 KiB

SECURITY.mdH A D03-Jun.-2020637

selftest/H17-Jun.-20224 KiB

setup.cfgH A D08-Mar.-2021233

source3/H24-Jun.-20224 KiB

source4/H19-Jan.-20224 KiB

testdata/H03-Dec.-20214 KiB

testprogs/H25-Sep.-20174 KiB

tests/H18-Feb.-20224 KiB

testsuite/H12-Mar.-20194 KiB

third_party/H04-Apr.-20224 KiB

VERSIONH A D24-Jan.-20226.1 KiB

VFS-License-clarification.txtH A D08-Mar.-20211.4 KiB

WHATSNEW.txtH A D26-Jun.-20227.7 KiB

wintest/H10-May-20224 KiB

wscriptH A D07-Apr.-202222.8 KiB

wscript_buildH A D21-Jun.-20214.8 KiB

wscript_build_embedded_heimdalH A D22-Jan.-2022113

wscript_build_system_heimdalH A D22-Jan.-2022111

wscript_build_system_mitkrb5H A D22-Jan.-2022100

wscript_configure_embedded_heimdalH A D19-Jan.-2022436

wscript_configure_system_gnutlsH A D04-Apr.-20222.7 KiB

wscript_configure_system_heimdalH A D19-Jan.-20224 KiB

wscript_configure_system_mitkrb5H A D04-Mar.-202214.9 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.md

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

README.contributing

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

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
16For the AD DC implementation a full HOWTO is provided at:
17      https://wiki.samba.org/index.php/Samba4/HOWTO
18
19Community guidelines can be read at:
20      https://wiki.samba.org/index.php/How_to_do_Samba:_Nicely
21
22This software is freely distributable under the GNU public license, a
23copy of which you should have received with this software (in a file
24called COPYING).
25
26
27
28CONTRIBUTIONS
29=============
30
31Please see https://wiki.samba.org/index.php/Contribute
32for detailed set-by-step instructions on how to submit a patch
33for Samba via GitLab.
34
35Samba's GitLab mirror is at https://gitlab.com/samba-team/samba
36
37OUR CONTRIBUTORS
38================
39
40See https://www.samba.org/samba/team/ for details of the Samba Team,
41as well as details of all those currently active in Samba development.
42
43If you like a particular feature then look through the git change-log
44(on the web at https://gitweb.samba.org/?p=samba.git;a=summary) and see
45who added it, then send them an email.
46
47Remember that free software of this kind lives or dies by the response
48we get. If no one tells us they like it then we'll probably move onto
49something else.
50
51
52MORE INFO
53=========
54
55DOCUMENTATION
56-------------
57
58There is quite a bit of documentation included with the package,
59including man pages and the wiki at https://wiki.samba.org
60
61If you would like to help with our documentation, please contribute
62that improved content to the wiki, we are moving as much content there
63as possible.
64
65
66MAILING LIST
67------------
68
69Please do NOT send subscription/unsubscription requests to the lists!
70
71There is a mailing list for discussion of Samba.  For details go to
72<https://lists.samba.org/> or send mail to <samba-subscribe@lists.samba.org>
73
74There is also an announcement mailing list where new versions are
75announced.  To subscribe go to <https://lists.samba.org/> or send mail
76to <samba-announce-subscribe@lists.samba.org>.  All announcements also
77go to the samba list, so you only need to be on one.
78
79For details of other Samba mailing lists and for access to archives, see
80<https://lists.samba.org/>
81
82
83MAILING LIST ETIQUETTE
84----------------------
85
86A few tips when submitting to this or any mailing list.
87
881. Make your subject short and descriptive. Avoid the words "help" or
89   "Samba" in the subject. The readers of this list already know that
90   a) you need help, and b) you are writing about samba (of course,
91   you may need to distinguish between Samba PDC and other file
92   sharing software). Avoid phrases such as "what is" and "how do
93   i". Some good subject lines might look like "Slow response with
94   Excel files" or "Migrating from Samba PDC to NT PDC".
95
962. If you include the original message in your reply, trim it so that
97   only the relevant lines, enough to establish context, are
98   included. Chances are (since this is a mailing list) we've already
99   read the original message.
100
1013. Trim irrelevant headers from the original message in your
102   reply. All we need to see is a) From, b) Date, and c) Subject. We
103   don't even really need the Subject, if you haven't changed
104   it. Better yet is to just preface the original message with "On
105   [date] [someone] wrote:".
106
1074. Please don't reply to or argue about spam, spam filters or viruses
108   on any Samba lists. We do have a spam filtering system that is
109   working quite well thank you very much but occasionally unwanted
110   messages slip through. Deal with it.
111
1125. Never say "Me too." It doesn't help anyone solve the
113   problem. Instead, if you ARE having the same problem, give more
114   information. Have you seen something that the other writer hasn't
115   mentioned, which may be helpful?
116
1176. If you ask about a problem, then come up with the solution on your
118   own or through another source, by all means post it. Someone else
119   may have the same problem and is waiting for an answer, but never
120   hears of it.
121
1227. Give as much *relevant* information as possible such as Samba
123   release number, OS, kernel version, etc...
124
1258. RTFM. Google.
126
127
128WEBSITE
129-------
130
131A Samba website has been setup with lots of useful info. Connect to:
132
133https://www.samba.org/
134
135As well as general information and documentation, this also has searchable
136archives of the mailing list and links to other useful resources such as
137the wiki.
138