[Samba] compile samba 4.10.2 centos 7.6
igorvolt at gmail.com
Sun Apr 21 19:41:32 UTC 2019
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?
Em dom, 21 de abr de 2019 às 14:44, Nico Kadel-Garcia <nkadel at gmail.com>
> 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
> 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.
More information about the samba