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. 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 Em sáb, 20 de abr de 2019 às 12:22, Nico Kadel-Garcia via samba < samba at lists.samba.org> escreveu:> On Mon, Apr 15, 2019 at 7:29 AM Sérgio Basto <sergio at serjux.com> wrote: > > > > On Sun, 2019-04-14 at 10:38 -0400, Nico Kadel-Garcia via samba wrote: > > > > Interesting. I'd not tried to bundle an upgraded compatibility > > > gnutls. > > > I think I understand how you did that, but I'm unclear on why you > > > selected the "hobbled" tarballs and where you got the > > > "nettle-3.2-hobbled.tar.xz" tarball to work with. > > > > Hi, > > I just copied it from Fedora [1] and [2] , it a long story [3], some > > ECC algorithms have patent issues , so they are discarded on Fedora > > (and so do I). > > Right: It's fortunate for this work that I've been home sick the last > few weeks, recovering from bronchitis and having just finished a > contract, home doing phone screens with a really scratchy voice. > > I've integrated some of your tools to my repos at: > > https://github.com/nkadel/samba4repo > > And brought over copies of your compat-gnutls34 and compat-nettle32 repos > to: > > https://github.com/nkadel/compat-nettle32-3.x-srpm > https://github.com/nkadel/compat-gnutls34-3.x-srpm > > I use git submodules for individual libraries, including libtalloc, > libldb, libtdb, and libtevent, to compile them for replacement on the > underlying RHEL 7 or CentOS 7 system. I've updated all the libraries > to publish both python2 and python3 or python36 modules as > appropriate, using the EPEL hoooks for python_pkg3version I got > pointed to in this thread, thanks! > > I've also tweaked the samba-4.10.x-srpm to build Samba modules and > tools *entirely* with python3. I can't swear i got everything, because > the python2 expected for RHEL 7 environments is pretty ubiquitous. But > I think I got it all. There is a "python3-subunit-test" dependency > I've just excluded, but that didn't look like a high priority. > > Anyone who wants to work with this, or play with it or send me > updates, cool!!! Sergio, especially you, I'd love to agree on layouts > and locations for tools like "compat-nettle32" and "compat-gnutls34", > so they can be handled in a modular fashion and not necessarily built > into the SRPM tool for Samba itself. And you're very welcome to my > Makefiles for scripting builds of the various components for desired > "mock" setups. > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >
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 SousaGood 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.
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. >