doing a test build of samba
mjt at tls.msk.ru
Mon Apr 4 16:56:29 UTC 2022
04.04.2022 13:30, Michael Tokarev via samba-technical wrote:
> I've been told that the --enable-selftest build should not be
> used to install things for production.
So I took a look at what --enable-selftest actually does. Here's the
list, for reference:
two new functions (not used in samba code) now return true:
two new "printers": test and lvp
dns lookups can use file pointed to by $RESOLV_CONF variable if set,
instead of using system-wide /etc/resolv.conf.
2 ipc messages are enabled: sleep and inject (fault injection)
build enables -D WITH_NTVFS_FILESERVER=1.
This one, in turn does this:
source4/ntvfs/posix/posix_eadb.c 4 new functions:
pull_xattr_blob_tdb() push_xattr_blob_tdb() delete_posix_eadb() unlink_posix_eadb()
source4/ntvfs/posix/wscript_build 4 new modules:
pvfs_acl pvfs_acl_xattr pvfs_acl_nfs4 ntvfs_posix
source4/ntvfs/wscript_build 3 new modules:
ntvfs_cifs ntvfs_simple ntvfs_ipc
source4/rpc_server/wscript_build 2 new modules:
source4/smb_server/wscript_build new module:
# Yes, the spoolss_notify test uses the NTVFS file server to run the SMB server expected
# to handle the RPC callback!
ntvfs_specific['source'] += ' rpc/spoolss_notify.c'
ntvfs_specific['deps'] += ' SMB_SERVER dcerpc_server ntvfs'
That's about it.
To me, this does not look like something which should be avoided
in production at all costs.
The two "new" printers are harmless, as are two new ipc messages
(okay, root can inject stuff to your samba daemons and cause delays
with a handy tool instead of using standard system tools for that :) ).
The extra ntvfs modules appears to be optional and can be left out
of the production package build.
Am I missing something or is it actually okay to use build produced
by --enable-selftest configuration?
More information about the samba-technical