samba - May 2019 - Upgraded from CentOS 6.X to 7.X, samba not working

On Fri, May 24, 2019 at 03:45:31PM +0200, L.P.H. van Belle via samba (samba at
lists.samba.org) wrote:
> You should have looked before upgrading. ... 
> If its an AD-DC.
> instructions:  https://lists.samba.org/mailman/options/samba
Yes, very true!

I really have "upgrading fatigue", this is my tenths bloody odd
machine I am moving from 6.x to 7.x (all of those quite complicated servers) -
but it is my first samba server. All the samba servers are internal servers
unreachable from the outside, so loosing the updates of the OS was my least
concern.

I briefly researched samba a while back and did not expect a few minor version
number changes make such a big difference. I also "expected" to have a
variety of choices of Samba (as this had been the case for so many years) - e.g.
older versions.

One of the biggest issues I have faced doing my upgrades is not only the OS
upgrade but nearly EVERY software package the OLD servers were using were
upgraded, too, even if the package numbers did not differ that much - this was a
major, major hassle especially making them stick with systemd and the libraries
required to run it.

I am so over this.
It would have been nice to have an OLD version of Samba for CentOS 7.X - then to
change this in a 1/2 year time once I upgraded the rest of the servers - JUST
saying!

thanks for the elaborate reading suggestions!!!!!
Jobst


-- 
Do Lipton Tea employees take coffee breaks?

  | |0| |   Jobst Schmalenbach
  | | |0|   
  |0|0|0|   +61 3 9533 0000, POBox 277, Caulfield South, 3162, Australia

On 24/05/2019 22:07, Jobst Schmalenbach via samba wrote:
> On Fri, May 24, 2019 at 03:45:31PM +0200, L.P.H. van Belle via samba (samba
at lists.samba.org) wrote:
>> You should have looked before upgrading. ...
>> If its an AD-DC.
>> instructions:  https://lists.samba.org/mailman/options/samba
> Yes, very true!
>
> I really have "upgrading fatigue", this is my tenths bloody odd
machine I am moving from 6.x to 7.x (all of those quite complicated servers) -
but it is my first samba server. All the samba servers are internal servers
unreachable from the outside, so loosing the updates of the OS was my least
concern.
>
> I briefly researched samba a while back and did not expect a few minor
version number changes make such a big difference. I also "expected"
to have a variety of choices of Samba (as this had been the case for so many
years) - e.g. older versions.
Ah, I think you are mixing up 'minor' with 'revision'. Samba
uses
'major.minor.revision' , the latest version is 4.10.4. If something 
dramatic changes, then the 'major' version will change, this last 
happened when the ability to provision an AD domain was released i.e 
Samba went from '3.x.x' to '4.x.x'. If minor changes are made,
then the
minor version will change, these changes could be the addition or 
removal of smb.conf options, though removal will mean the deprecation of 
the option at a minor release before being removed at the next minor 
release. The 'revision' releases are for bugfixes and/or security 
problems, nothing major should be changed.

This all means that before you upgrade Samba, you should read the 
release notes for the 'minor' releases, there have been a lot of changes
between the Samba that Centos 6 used and the one that Centos 7 uses.

Rowland
>
> One of the biggest issues I have faced doing my upgrades is not only the OS
upgrade but nearly EVERY software package the OLD servers were using were
upgraded, too, even if the package numbers did not differ that much - this was a
major, major hassle especially making them stick with systemd and the libraries
required to run it.
>
> I am so over this.
> It would have been nice to have an OLD version of Samba for CentOS 7.X -
then to change this in a 1/2 year time once I upgraded the rest of the servers -
JUST saying!
>
> thanks for the elaborate reading suggestions!!!!!
> Jobst
>
>

Am 24.05.19 um 23:07 schrieb Jobst Schmalenbach via
samba:
> On Fri, May 24, 2019 at 03:45:31PM +0200, L.P.H. van Belle via samba (samba
at lists.samba.org) wrote:
>> You should have looked before upgrading. ... 
>> If its an AD-DC.
>> instructions:  https://lists.samba.org/mailman/options/samba
> 
> Yes, very true!
> 
> I really have "upgrading fatigue", this is my tenths bloody odd
machine I am moving from 6.x to 7.x (all of those quite complicated servers) -
but it is my first samba server. All the samba servers are internal servers
unreachable from the outside, so loosing the updates of the OS was my least
concern.
> 
> I briefly researched samba a while back and did not expect a few minor
version number changes make such a big difference. I also "expected"
to have a variety of choices of Samba (as this had been the case for so many
years) - e.g. older versions.
when did you have the choice of older versions ever?

you can downgrade to the version RHEL7 was released with but you never
had a choice keep a package at the version of the previous RHEL major
release
> One of the biggest issues I have faced doing my upgrades is not only the OS
upgrade but nearly EVERY software package the OLD servers were using were
upgraded, too, even if the package numbers did not differ that much - this was a
major, major hassle especially making them stick with systemd and the libraries
required to run it.
> 
> I am so over this.
> It would have been nice to have an OLD version of Samba for CentOS 7.X -
then to change this in a 1/2 year time once I upgraded the rest of the servers -
JUST saying!
honestly upgrading from CentOS6 to CentOS7 won't work, most likely even
not for basic setups, 7 to 8 will be easier because the transition to
systemd is done and mature

-----------------

Red Hat Enterprise Linux 6
2010-11-10
Mix of Fedora 12 Fedora 13 and several modifications

Red Hat Enterprise Linux 7
2014-06-10
Primarily Fedora 19 with several changes from 20 and later

there are so much changes in every single package and their dependencies
that you can't expect any configuration keep working, that's why we use
Fedora, i don't want to re-install 30 VMs every few years and sit on old
crap which has nothing in common with my workstations for years

-----------------

that means two major upgrades per year but that scales far better than
every few years have all the changes of 7-10 releases at once given that
all servers where installed in 2008 with F9 and are now at F29 without
re-install and all dist-upgrades where "yum/dnf distro-sync" with no
downtimes longer than a ordinary kernel update

it's compareable with a rolling release but without breaking changes for
6 months and so you can override specific packages with own builds, for
example PHP/MySQL/Postfix and other business critical packages are
maintained by myself and upgraded *before* the dist-upgrade or even the
older version kept so that i can focus on "now let us see what mariadb
10.3 brings, 10.2 still runs fine on F29, keep it for now"

you have now 7-9 Fedora upgrades at the same time

install from scratch and try to port your configurations, implement
tests, write helper scripts for the migration and prepare yourself for
months of work

On Sat, May 25, 2019 at 9:12 AM Reindl Harald via samba
<samba at lists.samba.org> wrote:
>
> Am 24.05.19 um 23:07 schrieb Jobst Schmalenbach via samba:
> -----------------
>
> Red Hat Enterprise Linux 6
> 2010-11-10
> Mix of Fedora 12 Fedora 13 and several modifications
>
> Red Hat Enterprise Linux 7
> 2014-06-10
> Primarily Fedora 19 with several changes from 20 and later
>
> there are so much changes in every single package and their dependencies
> that you can't expect any configuration keep working, that's why we
use
> Fedora, i don't want to re-install 30 VMs every few years and sit on
old
> crap which has nothing in common with my workstations for years
Well, yes. This is why a heavily customized internal service, such as
can occur for Samba, would ideally be done on a new server environment
rather than upgraded in place. It's a six year difference in release
date, with the change of a lot of the underlying components.
> install from scratch and try to port your configurations, implement
> tests, write helper scripts for the migration and prepare yourself for
> months of work
Months? Unless the environment is really complex, I'd only expect a
few days of work. If you've the resources to set up a small test setup
with a few hosts, do that, then bring the configuration over to a new
server. Trying to do it live, on the same server, upgrading in place,
is kind of begging to trip over some fundamental change in Samba or
even in CIFS.

Jobst? Were you using the default samba-3 from CentOS 6, or the
upgraded samba4-4.2 package before the upgrade to CentOS 7, with
samba-4.8 ?