summaryrefslogtreecommitdiff
path: root/source3/modules
diff options
context:
space:
mode:
authorMichael Adam <obnox@samba.org>2007-06-15 21:38:10 +0000
committerGerald (Jerry) Carter <jerry@samba.org>2007-10-10 12:23:23 -0500
commitaa4110e6f2432d76926198ce7a2a4adea4e1860a (patch)
tree14a6b2bf3e9e33bf22f2c082576f2d1fb2e42376 /source3/modules
parentcc35d1300d487c65f1dc8a275140701ba276adaf (diff)
downloadsamba-aa4110e6f2432d76926198ce7a2a4adea4e1860a.tar.gz
samba-aa4110e6f2432d76926198ce7a2a4adea4e1860a.tar.bz2
samba-aa4110e6f2432d76926198ce7a2a4adea4e1860a.zip
r23509: This activates the global options from the registry in loadparm.
The global options are stored as values in the subkey "global" of the SMBCONF registry key. The activation is accomplished in smb.conf though a new special semantic of the "include" parameter: "include = registry" triggers the processing of the registry global options exactly at the position of the include statement. Options read from the registry take the same precedence as parameters loaded from a file via include. Need to reload the registry globals is detected by watching the tdb sequence number. Registry shares are automatically activated when the registry globals are processed. So a "registry only" configuration can be realized by an smb.conf that looks as follows: ================================ [global] include = registry ================================ The global options and registry shares can be conveniently edited with the "net conf" utility. Caveat: A possible pitfall consists in using "include = registry" together with the "lock directory" directive in the registry. This problem will be addressed in the next time. Note on the code: Processing of the registry options is accomplished by a function process_registry_globals() in loadparm.c The current version is only an interim solution: It is handcoded instead of using the infrastructure of reg_api.c. The reason for this is that using reg_api still has too large linker dependencies, bloating virtually all targets by PASSDB_OBJ, SMBLDAP_OBJ, GROUPDB_OBJ and LDB stuff. A version of process_registry_globals that uses reg_api is included but commented out. The goal is to eventually refactor and restructure the registry code so that one can use the reg_api to access only the registry tdb and not link all the dynamic backends with all their linking implications. (This used to be commit 24b0cbcb3741dd14b04728448a85cc04a057e7d0)
Diffstat (limited to 'source3/modules')
0 files changed, 0 insertions, 0 deletions