Web lists-archives.com

Re: [Samba] compile samba 4.10.2 centos 7.6





Hi Igor,

Please don't do that (set PYTHON=python3.4 globally in /etc/profile) on centos7/rhel7.

If you must override such environment variables, it is usually better to set them only for the current shell (by sourcing the appropriate env file) or within the systemd unit files (see [1]) for services.

rhel7/centos7 are built with python2.7 embedded in many subsystems and will remain on python2.7 for the life of that distribution.

The proper way to override python on those systems is to set it only for the child processes that require it.

Regards,

Vincent

[1]: https://coreos.com/os/docs/latest/using-environment-variables-in-systemd-units.html


On Sun, 21 Apr 2019, Igor Sousa via samba wrote:

Hi Nico,

I've understood about use export PYTHON=python3.4 in /etc/profile. The host
that I've done it is in my test environment. I have only question about
this: after samba 4.10.2 installed, it ever never need use python3 to do
anything about samba?

PS1: In my environment, the host run only Samba (samba and bind) service.

I disagree about use python 3.6 instead python 3.4, though. In samba 4.10.0
release notes there is a mention this version is compatible with python 3.4
and there isn't mention about python 3.6. I've understood that it is normal
software using python 3.4 run with python 3.x.x grater than 3.4, but python
3.6 was released at the end of 2016 and samba 4.10.0 release notes was
released in March 2019. What are the Samba team's reasons for not
mentioning python 3.6 or the latest in their release notes?

--
Igor Sousa


Em dom, 21 de abr de 2019 às 14:44, Nico Kadel-Garcia <nkadel@xxxxxxxxx>
escreveu:

On Sun, Apr 21, 2019 at 11:40 AM Igor Sousa <igorvolt@xxxxxxxxx> wrote:

Hi Gabriel,

I've compiled Samba 4.10.2 on CentOS 7 successfully. I've read the wiki
that 4.10.2 version is full compatible with python 3, specifically python
3.4. Then I've install, use the yum command, the package python34-devel and
I've added an environment variable at /etc/profile with export
PYTHON=python3.4.

You have just diverged your local system for all users, including the
root user, so far from the upstream RHEL standard that you may find it
very difficult to recover if something entirely unrelated to Samba
breaks. You've turned a stack of default python2.7 tools into using
python3.4, tools htat have nothing to do with Samba. I do *not*
recommend this. If you need to do this kind of step, I'd urge you to
do it in the build environment just for building Samba, not for
general use. It's as dangerous as doing "sudo pip install anything",
and it can really break working software.

Sorry if I seem a bit harsh about this: I'd had too many cases where
developers or new admins did something that worked well in their
personal development environment and broke servers when it was done to
production servers without my knowledge later, and having to clean up
a nasty mess.

Thus, I've run ./configure, make and make install with no problems. If
you have tried to install 4.10.2 version in your test environment, I
recommend to you try the described above.

--
Igor Sousa

Good for you. Frankly, I'd use python36 from EPEL, not python34, just
to be closer to up-to-date Python. Unfortunately, unless you've done
some extra work, it won't include the eatures to provide a full domain
controller because the gnutls won't be recent enough. And it won't
replace any of the compiled RHEL 7 based libraries with the updated
talloc, tdb, tevent, or ldb libraries. Unpredictable hilarity may
ensue if you expect various features to work consistently, especially
if you weren't very careful to segregate your built Samba from the
default samba libraries built into RHEL 7 and CentOS 7.

The URL's I published include all the hooks for integrating your new
Samba services as RPM's, including systemd setups and man pages in
expected places, as did sergiomb2's work at
https://github.com/sergiomb2/SambaAD work. When you're replacing
system utilities, I really recommend replacing the entire system
utility so you get all the documentation and software configuration
control provided by the system's packaging utilities. Doing otherwise
can lead to.... adventures, when doing "yum update" of libraries that
might overwrite your deployment, unless you were *very* careful with
your deployment.

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba