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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
