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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
During the restore process, we use make_smbconf() to create a new
smb.conf file with the default paths. The default location for 'state
directory' is 'state', but we currently rename this directory to
'statedir' on backing up, so it will end up pointing to a non-existent
directory. This commit ensures the names are consistent.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
When opening the backed-up SamDB database, open the top-level database
without loading any modules so the backend database files aren't
unnecessarily opened. The domain SID is now fetched from the original
database rather than from the backup.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14676
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Samuel Cabrero <scabrero@samba.org>
The LMDB change "ITS#9278 fix robust mutex cleanup for FreeBSD" released
in version 0.9.26 makes samba-tool domain backup offline to fail with
the following error:
Failed to connect to 'mdb:///tmp/foo/private/sam.ldb.d/CN=CONFIGURATION,DC=FOO,DC=EXAMPLE,DC=COM.ldb' with backend 'mdb': Unable to load ltdb cache records for backend 'ldb_mdb backend'
module samba_dsdb initialization failed : Operations error
Unable to load modules for /tmp/foo/private/sam.ldb.bak-offline: Unable to load ltdb cache records for backend 'ldb_mdb backend'
ERROR(ldb): uncaught exception - Unable to load ltdb cache records for backend 'ldb_mdb backend'
File "/usr/local/samba/lib64/python3.6/site-packages/samba/netcmd/__init__.py", line 186, in _run
return self.run(*args, **kwargs)
File "/usr/local/samba/lib64/python3.6/site-packages/samba/netcmd/domain_backup.py", line 1147, in run
session_info=system_session(), lp=lp)
File "/usr/local/samba/lib64/python3.6/site-packages/samba/samdb.py", line 72, in __init__
options=options)
File "/usr/local/samba/lib64/python3.6/site-packages/samba/__init__.py", line 114, in __init__
self.connect(url, flags, options)
File "/usr/local/samba/lib64/python3.6/site-packages/samba/samdb.py", line 87, in connect
options=options)
The error occurs opening the backed ldb to write the backup date and the
next SID, a call to pthread_mutex_lock in mdb_txn_renew0 (frame 8) returns
EINVAL:
#0 0x00007ff63c2f1bea in wait4 () from /lib64/libc.so.6
#1 0x00007ff63c26f3a3 in do_system () from /lib64/libc.so.6
#2 0x00007ff63bc71e94 in smb_panic_default (why=0x7ffed481b7d0 "Signal 6: Aborted") at ../../lib/util/fault.c:153
#3 0x00007ff63bc72168 in smb_panic (why=0x7ffed481b7d0 "Signal 6: Aborted") at ../../lib/util/fault.c:200
#4 0x00007ff63bc71c82 in fault_report (sig=6) at ../../lib/util/fault.c:81
#5 0x00007ff63bc71c97 in sig_fault (sig=6) at ../../lib/util/fault.c:92
#6 <signal handler called>
#7 0x00007ff63c2178b5 in raise () from /lib64/libpthread.so.0
#8 0x00007ff637602e65 in mdb_txn_renew0 (txn=txn@entry=0x55d6f97fb800) at mdb.c:2710
#9 0x00007ff637603ae8 in mdb_txn_begin (env=0x55d6f85dfa80, parent=0x0, flags=131072, ret=0x55d6f89c0928)
at mdb.c:2912
#10 0x00007ff6376236cc in lmdb_lock_read (module=0x55d6f8c5f4b0) at ../../lib/ldb/ldb_mdb/ldb_mdb.c:585
#11 0x00007ff637641de6 in ldb_kv_cache_load (module=0x55d6f8c5f4b0) at ../../lib/ldb/ldb_key_value/ldb_kv_cache.c:450
#12 0x00007ff637638792 in ldb_kv_init_store (ldb_kv=0x55d6f8af2a80, name=0x7ff637625675 "ldb_mdb backend",
ldb=0x55d6f8cd22b0, options=0x0, _module=0x7ffed481c248) at ../../lib/ldb/ldb_key_value/ldb_kv.c:2166
#13 0x00007ff6376247ba in lmdb_connect (ldb=0x55d6f8cd22b0,
url=0x55d6f85d41f0 "mdb:///tmp/foo/private/sam.ldb.d/CN=CONFIGURATION,DC=FOO,DC=EXAMPLE,DC=COM.ldb", flags=64,
options=0x0, _module=0x7ffed481c248) at ../../lib/ldb/ldb_mdb/ldb_mdb.c:1143
#14 0x00007ff63bd94d2f in ldb_module_connect_backend (ldb=0x55d6f8cd22b0,
url=0x55d6f85d41f0 "mdb:///tmp/foo/private/sam.ldb.d/CN=CONFIGURATION,DC=FOO,DC=EXAMPLE,DC=COM.ldb",
options=0x0, backend_module=0x7ffed481c248) at ../../lib/ldb/common/ldb_modules.c:221
#15 0x00007ff6375a4baf in new_partition_from_dn (ldb=0x55d6f8cd22b0, data=0x55d6f858bed0, mem_ctx=0x55d6f8a03cd0,
dn=0x55d6f9865450, filename=0x55d6f860b6da "sam.ldb.d/CN=CONFIGURATION,DC=FOO,DC=EXAMPLE,DC=COM.ldb",
backend_db_store=0x55d6f9d378e0 "mdb", partition=0x7ffed481c308)
at ../../source4/dsdb/samdb/ldb_modules/partition_init.c:257
#16 0x00007ff6375a57b9 in partition_reload_if_required (module=0x55d6f8972d10, data=0x55d6f858bed0, parent=0x0)
at ../../source4/dsdb/samdb/ldb_modules/partition_init.c:513
#17 0x00007ff6375a3b04 in partition_read_lock (module=0x55d6f8972d10)
at ../../source4/dsdb/samdb/ldb_modules/partition.c:1492
#18 0x00007ff63bd9631e in ldb_next_read_lock (module=0x55d6f8972d10) at ../../lib/ldb/common/ldb_modules.c:662
#19 0x00007ff637484857 in schema_read_lock (module=0x55d6f9377e40)
at ../../source4/dsdb/samdb/ldb_modules/schema_load.c:614
#20 0x00007ff63bd9631e in ldb_next_read_lock (module=0x55d6f9377e40) at ../../lib/ldb/common/ldb_modules.c:662
#21 0x00007ff6374b5402 in samba_dsdb_init (module=0x55d6f91c3cd0)
at ../../source4/dsdb/samdb/ldb_modules/samba_dsdb.c:483
#22 0x00007ff63bd95283 in ldb_module_init_chain (ldb=0x55d6f8cd22b0, module=0x55d6f91c3cd0)
at ../../lib/ldb/common/ldb_modules.c:363
#23 0x00007ff63bd95645 in ldb_load_modules (ldb=0x55d6f8cd22b0, options=0x0)
at ../../lib/ldb/common/ldb_modules.c:445
#24 0x00007ff63bd90663 in ldb_connect (ldb=0x55d6f8cd22b0,
url=0x7ff6377d98f8 "/tmp/foo/private/sam.ldb.bak-offline", flags=64, options=0x0)
at ../../lib/ldb/common/ldb.c:274
#25 0x00007ff63bddb32f in py_ldb_connect (self=0x7ff63778afc0, args=(), Python Exception <class 'gdb.error'> There is no member named ma_keys.:
kwargs=) at ../../lib/ldb/pyldb.c:1235
Deleting the previous samdb instance by setting it to None before opening the
backed ldb workaround the problem until we find the real problem here.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14676
Signed-off-by: Samuel Cabrero <scabrero@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
If backup dirs contain hardlinks, the backup process could previously
attempt to open an LMDB database already opened during the backup,
causing it to be recreated as a new TDB database. This commit ensures
that new database files are not created during this operation, and that
the main SamDB database is not modified.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14027
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz
The old behaviour attempted to check for and remove files with duplicate
names, but did not do so due to a bug, and would have left undetermined
which files were given priority when duplicate filenames were present.
Now when hardlinks are present, only one instance of each file is
chosen, with files in the private directory having priority. If one
backup dir is nested inside another, the files contained in the nested
directory are only added once. Additionally, the BIND DNS database is
omitted from the backup.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14027
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz
This fix ensures that the samba-tool backup temp directory is removed
if an exception occurs (e.g. LDAP_INVALID_CREDENTIALS).
Signed-off-by: Heiko Baumann <heibau@gmail.com>
Reviewed-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Add a better error message (and what to do about it) if the user tries
to back up a DC that hasn't initialized its RID pool yet.
Seems to be a fairly common problem hit by users.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14048
RN: Added more informative error message if the 'samba-tool domain
backup' command fails due to no RID pool being present on the DC.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Wed Jul 24 07:07:01 UTC 2019 on sn-devel-184
I ran this command as non-root by mistake and didn't find the error
message particularly helpful. Tweak the error message so it reminds the
user that they should be root. Also display the path we're looking for
the sam.ldb file in, to give them more clues.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13676
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Noel Power <npower@samba.org>
Autobuild-User(master): Noel Power <npower@samba.org>
Autobuild-Date(master): Mon Jan 21 16:34:06 CET 2019 on sn-devel-144
The replUpToDateVector could be incorrect after an offline backup was
restored. This means replication propagation dampening doesn't work
properly. In the worst case, a singleton DC would have no
replUpToDateVector at all, and so *all* objects created on that DC get
replicated every time a new DRS connection is established between 2 DCs.
This becomes a real problem if you used that singleton DC to create 100K
objects...
This patch flushes the replUpToDateVector when an offline backup gets
restored. We need to do this before we add in the new DC and remove the
old DCs.
Note that this is only a problem for offline backups. The online/rename
backups are received over DRS, and as part of the replication they
receive the latest replUpToDateVector from the DC being backed up.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
It will be easy to forget that the backupType marker doesn't exist on
v4.9. However, this seems like a dumb reason not to support v4.9
backup-files. Add a wrapper function to avoid potential problems
cropping up in future.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
We are starting to hit restore cases that are only applicable to a
particular type of backup. We already had a marker to differentiate
renames, but differentiating offline backups would also be useful.
Note that this raises a slight compatibility issue for backups created
on v4.9, as the marker won't exist. However, it's only offline backups
we will use this marker for (at the moment), and this option doesn't
exist on v4.9, so there's no problem.
Removing the markers has been refactored out into a separate function to
handle the optional presence of the new marker.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Currently the online/rename backup files always use the default backend
(TDB) and there is no way to change this.
This patch adds the backend-store option to the backup commands so that
you can create a backup with an MDB backend, if needed.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Fix attributes that need to be treated as str not bytes
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Normally when a new DC joins a domain, samba-tool works out the new
DC's site automatically. However, it does this by querying the existing
DC using CLDAP. In the restore case, there is no DC running. We could
still query the DB on disk and work out the correct site based on the
new DC's IP, however:
- comparing between the CN=Subnet DNs and an IP-address string seems
like it'd be non-trivial to write, and
- in the lab-domain rename case, chances are the user will want a
completely different subnet to what's already in the DB.
The restore command now has a --site option so the user can specify an
appropriate site for the restored DC. This patch makes the restore
command work by default (i.e. without a --site option) even if the
default Default-First-Site-Name doesn't exist. Basically the solution is
to just check Default-First-Site-Name exists and create it if it
doesn't. As the recommended workflow is to use the restored DC as a
temporary seed that you'll later throw away, this approach seems
acceptable. Subsequent DCs will then be joined to the running restored
DC, so an appropriate site will be determined using CLDAP. The only
side-effect is potentially an extra Site object.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13621
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Restoring a backup only worked if the Default-First-Site-Name site was
still present. When the new restored DC account is created, it was
trying to add the new server's DN under CN=Default-First-Site-Name.
However, if the original domain was setup using a different site, then
the restore would fail because the DN didn't exist.
When running the restore command, you should be able to specify the
site that you want the new/restored DC to be in (same as during a
DC 'join'). Passing the correct --site argument is one way to avoid
this problem. (A subsequent patch will further improve the tool so it
can work around non-default sites automatically).
Note we also need to pass the site through to where the new DNS entries
get registered (in the rename case).
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13621
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Currently a backup-offline test is occasionally flapping in autobuild,
however, the output is truncated so we can't see what the actual problem
is. The output only ever contains the list of backup dirs. I suspect
that the ']' character printed at the end of the python list might be
getting interpretted by subunit as the end of *all* the output.
If so, we should be able to avoid the problem by printing the list items
without the '['/']'s, i.e. join the list into a single string.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
The --kerberos=yes and --no-secrets options didn't work in combination
for domain backups. The problem was creds.get_username() might not
necessarily match the kerberos user (such as in the selftest
environment). If this was the case, then trying to reset the admin
password failed (because the creds.get_username() didn't exist in
the DB).
Because the admin user always has a fixed RID, we can work out the
administrator based on its object SID, instead of relying on the
username in the creds.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13566
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Wed Aug 15 10:19:09 CEST 2018 on sn-devel-144
The online/rename backups only worked if you specified both the username
and password in the actual command itself. If you just entered the
username (expecting to be prompted for the password later), then the
command was rejected.
The problem was the order the code was doing things in. We were checking
credopts.creds.get_password() *before* we'd called
credopts.get_credentials(lp), whereas it should be the other way
around.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13566
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Unlike the existing 'domain backup online' command, this command allows an
admin to back up a local samba installation using the filesystem and the
tdbbackup tool instead of using remote protocols. It replaces samba_backup
as that tool does not handle sam.ldb and secrets.ldb correctly. Those two
databases need to have transactions started on them before their downstream
ldb and tdb files are backed up.
Signed-off-by: Aaron Haslett <aaronhaslett@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
+ Added check that specified targetdir is actually a directory (if it
exists)
+ Deleted a redundant 'Creating targetdir' check that would never be hit
+ Move code into a separate function so we can reuse it for offline
backups (which take a different set of parameters, but still have a
targetdir)
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
We are suggesting to users that it's safe to run a renamed domain in
parallel with the old backed-up domain. However, this would not be the
case if the user (foolishly) "renames" their domain using the exact same
NetBIOS name or DNS realm.
Using the same DNS realm fails later on (updating the dnsRoot values),
but using the same NetBIOS name actually succeeds. While we can't make
samba tools completely idiot-proof, we can protect users from the most
basic of (potentially unintended) errors with some simple sanity-checks.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
There are now several different permutations of backup file that can be
created (i.e. online, rename, with/without secrets). Hopefully the admin
users would organize their backup files sensibly, but it can't hurt to
keep track of what the backup-file actually contains in a simple
human-readable file within the backup tar. E.g. We really don't want
backups with secrets-included and secrets-excluded getting mixed up.
Recording the DC used to make the domain backup may be useful in the
event of a catastrophic failure of the domain, e.g. DC replication may
have been broken for some time prior to the failure.
Recording the samba-tool version string may also be useful if there are
ever any backwards-compatibility issues introduced to the backup files.
The intention is to say we only support restoring a backup with the same
version of samba-tool that actually created the backup, however, it'd be
polite to users to actually record that version somewhere.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
By default we include all the domain's secrets in the backup file. This
patch adds an extra option to exclude these secrets. In particular, this
is for the use case of creating a lab domain (where you might not feel
comfortable with the secrets for all your users being present).
Mostly this just involves passing the correct option to the join/clone.
I've also made sure that a password is also set for the Admin user
(samba does seem to start up without one set, but this behaviour is
closer to what happens during a provision).
The tests have been extended to use the new option, and to assert that
secrets are/aren't included as expected for some of the builtin testenv
users.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
As part of the restore process, we remove all the old DCs from the DB.
However, this introduces some dbcheck errors - there are some DN
attributes and one-way links that reference the deleted objects that
need fixing up. To resolve this, we can run dbcheck as part of the
restore process. This problem affects both renames and plain restores.
The dbcheck.sh test didn't spot this problem because it fixes this type
of DB error first, before it checks the DB.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
When restoring a renamed domain backup, we need to register the new
realm's DNS zone. We do this in the restore step because we don't know
the new server's IP/hostname in the backup step.
Because we may have removed the old realm's DNS entries in the rename
step, the remove_dc() code may fail to find the expected DNS entries for
the DC's domain (the DCs' dnsHostname still maps to the old DNS realm).
We just needed to adjust remove_dns_references() as it was getting a
slightly different error code.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Add a new command that takes a clone of the domain's DB, and renames the
domain as well. (We rename the domain during the clone because it's
easier to implement - the DRS code handles most of the renaming for us,
as it applies the received replication chunks).
The new option is similar to an online backup, except we also do the
following:
- use the new DCCloneAndRenameContext code to clone the DB
- run dbcheck to fix up any residual old DNs (mostly objectCategory
references)
- rename the domain's netBIOSName
- add dnsRoot objects for the new DNS realm
- by default, remove the old realm's DNS objects (optional)
- add an extra backupRename marker to the backed-up DB. In the restore
code, if the backup was renamed, then we need to register the new
domain's DNS zone at that point (we only know the new DC's host IP
at the restore stage).
Note that the backup will contain the old DC entries that still use the
old dnsHostname, but these DC entries will all be removed during the
restore, and a new DC will be added with the correct dnsHostname.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This adds a new testenv for testing that a DC created using the
samba-tool backup/restore can actually be started up. This actually
requires 2 new testenvs:
1. A 'backupfromdc' that solely exists to make a online backup of.
2. A 'restoredc' which takes the backup, and then uses the backup file
to do a restore, which we then start the DC based on.
The backupfromdc is just a plain vanilla AD DC. We use a separate test
env purely for this purpose, because the restoredc will use the same
domain (and so using an existing testenv would potentially interfere
with existing test cases).
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
Add a command option that restores a backup file. This is only intended
for recovering from a catastrophic failure of the domain. The old domain
DCs are removed from the DB and a new DC is added.
Signed-off-by: Aaron Haslett <aaronhaslett@catalyst.net.nz>
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
This adds a samba-tool command that can be run against a remote DC to
produce a backup-file for the current domain. The backup stores similar
info to what a new DC would get if it joined the network.
Signed-off-by: Aaron Haslett <aaronhaslett@catalyst.net.nz>
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
