[Samba] named will not start after upgrade of CentOS

[Reindl Harald]

Am 15.05.2018 um 17:17 schrieb Marco Coli:
> Il 15/05/2018 16:51, Reindl Harald via samba ha scritto:
>> Am 15.05.2018 um 16:47 schrieb Marco Coli via samba:
>>> Ok, thank for your comments, but the problem is not related to this aspects.
>>> If I remove (prior to the upgrade) all 'aliens' zones, after the upgrade
>>> the problem is the same (I tested before, I tried to 'strip out' named.conf)
>>> I will try to remove 'forward first' as well, and I will let you know.
>>>
>>> The problem seems related to some package updated. If I upgrade
>>> sernet-samba alone to sernet-samba-ad-4.8.1-9.el7.x86_64 (and restart
>>> the service, of course), all is ok, but when I update all others
>>> packages, hell on earth (earth=samba)...
>>>
>>> Any clue about wich rpm can be involved? Kernel is out of the picture,
>>> because the problem is present immediately after upgrade, before reboot
>>> in new kernel (but reboot does not help)...
>>>
>>> My configuration started with 7.1 and survived happily until now...
>> CentOS 7.5 updates samba to samba-4.7.1-6.el7.x86_64 which is even newer
>> than on Fedora 26 (4.6.x) - i guess this is a mix of some config files
>> edited (and now .rppnew instead overwritten) and some unchanged which
>> are replaced hence by the upgrade
> 
> samba provided with CentOS is without AD functionality. If you need AD,
> you need to compile samba by yourself or use third party repos (as I
> did, sernet-samba).
> 
> I used successfully this environment on more than 10 server with
> centos/RHEL 6.x and 7.x, until last 7.5 update

that don't change the fact that you likely have a mix of user-changed
configs and untouched ones now overwritten with new distro versions
which are no longer in sync

either stay with defaults or move your whole config to "self
maintained", works here for a dozen of services on a ton of machines
running Fedora which made 18 dist-upgrades where each is more invasive
then all CentOS upgrades together

if you touch a config file shipped with packages that one will never be
overwritten, you end with a .rpmnew - all untouched are overwritten and
when config snippets depend on each other and one piece is no longer in
sync with the other you end wehre you are

just search for .rpmnew files and for the future install "etckeeper" so
that you can compare the whole config state from "now" to yesterday with
a diff