[Samba] compile samba 4.10.2 centos 7.6

[vincent at cojot.name]

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 at gmail.com>
> escreveu:
>
>> On Sun, Apr 21, 2019 at 11:40 AM Igor Sousa <igorvolt at gmail.com> 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
>