IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
- removed workaround for olcSyncprovConfig - creation (works perfect now
with 2.4.15, release was today)
- added 1 message-helpline, which is displayed when running
provision-backend with olc and/or mmr setup
- corrected 1 wrong slapcommand-helpline
- slapd.conf is removed now in case of olc-setup
- added 1 copyright-line to provision.py and provision-backend
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
These extensions add mmr (multi-master-replication) and olc
(openldap-online-configuration) capabilities to the
provisioning-scripts (provision-backend and provision.py), for use
with the openldap-backend (only versions >=2.4.15!).
Changes / additions made to the provision-backend -script:
added new command-line-options:
--ol-mmr-urls=<list of whitespace separated ldap-urls> for use with mmr
(can be combined with --ol-olc=yes),
--ol-olc=[yes/no] (activate automatic conversion from static slapd.conf
to olc),
--ol-slaptest=<path to slaptest binary> (needed in conjunction with
--ol-olc=yes)
Changes / additions made to the provision.py -script: added
extensions, that will automatically generate the chosen mmr and/or olc
setup for the openldap backend, according to the to chosen parameters
set in the provision-backend script
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
behavior anyway, and given we can only have one transaction active per
ldb context this is the only sane model we can support.
Fix ldb_tdb transactions, we could return back with an error with neither
committing nor canceling the actual tdb transaction in some error paths
within the ltdb commit and cancel transaction paths.
Added also some debugging to trace what was going on.
* This adds a test to check the change notify behavior of the SMB server
when more events have been generated than can be returned in a single
change notify response.
* Second test makes sure the server doesn't return notification events
for changes to the watched directory itself
This tests how streaminfo deals with large buffers
smbclient seems to have problems when the buffer size approaches the
max data size. Also smbclient exposes no way to specify the max data
size that is sent in a trans2 request. Instead it hardcodes in a much
larger max than windows uses. For these reasons this test isn't
actually run, but is more of a reference for how windows handles
streaminfo buffers.
Our packet layer relies on the event system reliably telling us when a
packet is available. When we are using a socket layer like TLS then
things get a bit trickier, as there may be bytes in the encryption
buffer which could be read even if there are no bytes at the socket
level. The GNUTLS library is supposed to prevent this happening by
always leaving some data at the socket level when there is data to be
processed in its buffers, but it seems that this is not always
reliable.
To work around this I have added a new packet option
packet_set_unreliable_select() which tells the packet layer to not
assume that the socket layer has a reliable select, and to instead
keep trying to read from the socket until it gets back no data. This
option is set for the ldap client and server when TLS is negotiated.
This seems to fix the problems with the ldaps tests.
This fixes two things in the TLS support for Samba4. The first is to
use a somewhat more correct hostname instead of 'Samba' when
generating the test certificates. That allows TLS test clients (such
as gnutls-cli) to connect to Samba4 using auto-generated certificates.
The second fix is to add a call to gcry_control() to tell gcrypt to
use /dev/urandom instead of /dev/random (on systems that support
that). That means that test certificate generation is now very fast,
which was previously an impediment to putting the TLS tests on the
build farm.
