Good morning/evening guys,
Great, i like what im reading.
This all is exactly why im saying, make a programs that handles these
upgrades independend from the samba version.
Almost all the code you guys need is already there. Having is this way is
really a major advantage.
It makes patching the samba-ad-db must better. To bad is, i cant code it for
you guys :-(
If i may suggest one more options for such a program.
Give it an "patch/import" function, what i mean by that..
For example, i still have some old bug small things going on in my AD-DB.
Think in, like incorrect SPN or missing SPN's, at least nothing i can
handle.
But there are more of these small anonances, these, are for sernet
subscriptions.
This is also where sernet can make some extra $.
It is fair to have the regular upgrade through opensource, but specal
upgrades through supported chanels.
Yes.. Im also thinking in making a buck for sernet, somewhere, someday,
someone needs to make some money..
Sernet could not exist without it, simple.
Now, if we have small AD-DB patches and place these somewhere on the samba
site (ftp), you could
Use that for the samba-upgrade-db program, make a query to the site and list
the
patches, this way you can also apply patches to an database that normaly
only possible while upgrading.
My other arguments on why i would really really like this and why adding a
new AD-DC is in most case just not welkom.
This is also why i'm always upgrading my DB and not setting up a new
servers, it is just to much hassle.
I did have about 40 printers, all connection over ldap to the hostnames of
the ad-dc's.
yeah i know, i should have use aliases here, but i didnt, and most guys dont
do that,
Simply because the dont know who/why, or are missing needed PTR records,
ldap/kerberos its auth is failing etc.
We as samba dev's talk lots of samba but we all know much more is involved.
And because of that you cant not "just replace" an AD-DC, that takes
time,
planning and for smaller networks,
people just cant afford is to have an, 100$ per hour, IT guy coming around
because of samba needs an upgrade.
And that was only about the printers, now think othere devices,, think in a
even larger network.
Adding a new DC is not (alway) the best cost effciant thing todo and not
everyone is haveing spare servers/room todo that.
For me, currently, i dont do anything on my DC's, i trust the current
process that much,
that my complete DC's are running fully unattended upgrades and if needed
with kernels and reboots.
Only if i add/remove packages from samba in my packages then the upgrade
process is stalled and i must manualy verify it.
Which is good, because if things get added or removed i must know that.
This is running almost a year now without any errors.
That shows how important it is to keep track of samba updates, which is a
big part of why i started to build the packages..
So in complete of what i suggested with an upgrade program it should also to
be able to handle.
- test upgrade ( make off/online backups ) upgrade that database, verify it.
- inplace upgrades of ad-dc, only runs after the test is successfull.
! And make testing the upgrade obligated, where its needed.
This will prevent that a full AD-DB gets lots in errors.
- if the test fails, and we needs a patch for it, get the patch list, use a
small patch first before and big inplace upgrade is done.
Get the patches from :
- for example from site.
- from server and show patches from "detected" version of the
provisioning.
- special patch supplied by sernet if you have a sernet
subscription.
We can use the data which already there.
Like : oEMInformation: Provisioned by SAMBA 4.1.17-SerNet-Debian-10.wheezy
So if all we need here is, show database upgrades as of version X.y.x
And apply the upgrades in the correct order.
If upgrade is done, tag/add a new field to the server it own AD record and
add field upgraded-to (X.Y.Z).
I really think this is the best way to keep database upgrades safe and this
allows
and easy fix if you misses the other samba upgrades.
But i love you guys for at least having a look at this, it will help lots of
people.
Im just trowing in more info and ideas so you guys minds gets a spin around
for the best setup.
:-)
Greetz,
Louis
-----Oorspronkelijk bericht-----
Van: samba-team [mailto:samba-team-bounces at lists.samba.org] Namens Bj?rn
Jacke via samba-team
Verzonden: dinsdag 10 september 2019 22:22
Aan: samba-team at lists.samba.org
Onderwerp: Re: upgrading AD DC and rejoin recommendation
On 10.09.19 20:29, Andrew Bartlett via samba-team wrote:> You don't have confidence in the process to re-join a Samba DC and I
> don't have confidence in the in-place upgrade outcomes. I think this
> is a real problem! Ouch!
this should not turn out to become a competition of gut feelings. :)
Let's summarize what we collected here so far: Bj?rn Baumbach wrote here
yesterday how easily he could reproduce problems with the rejoin update
approach. Metze and me also reported about the issues that we observed
with this approach on customer sites in the past and also with very
recent samba releases. The guid indexing problem in the past was
actually a very nasty regression bug and except for that bug, which
slipped in with the guid indexing feature, *all* the Samba 4 AD releases
in the past could be updated successfully by in-plcae updates (yes, even
if not covered by torture tests yet) and this in-place approach is how
almost all people (see Rowland's comment also) always did this for now.
>From previous release notes our users already know that new db
performance features might only come with freshly provisioned databases.
The logical thing to do to get a a fresh provisioned dc db is to add a
new DC. Metze's arguments and concerns in his previous mail are also
very reasonable and I support his and Louis' proposal to add a (for now
experimental) samba_upgrade_db command if we want to allow users to
rebuild new dc databases without having to add a new DC. I also strongly
support the idea that Metze had about writing up those optional
recommendations for advanced admins.
Bj?rn
