Thanks, Stephen, this is good advice, and if I ever deploy Red Hat in an enterprise and not a thug-infested nightmare, I'll take it. For now, I'll wing it and if it goes wrong, send some thugs to deliver a little nightly CI to James. J/k, I guess.
On Fri, Nov 3, 2017 at 6:20 PM, Stephen John Smoogen <smooge@xxxxxxxxx> wrote:
On 3 November 2017 at 17:28, Peter Rex <prex5609@xxxxxxxxx> wrote:
> You seem to be the guy who does the builds. If you could advise, despite the
> grumpiness:
>
> Since updating Ansible playbooks, tasks, libraries and such to work with a
> more current Ansible version isn't practical, on existing servers, we're
> thinking of adding "exclude=ansible1.9 ansible" to the relevant section of
> the "epel.repo" config file to keep it at 1.9, and on new servers, just
> install the old ansible1.9 package via RPM (which I managed to find on a
> mirror that hadn't been updated yet).
>
> However, I'm wondering if we should worry about future changes to
> dependencies. Most are in @base so I doubt they will stop working with an
> older versions of Ansible, but do you think we should "exclude" other @epel
> packages in Ansible 1.9's spec file, or do you think they would they keep
> working with Ansible 1.9 even if they were updated in the future. The only
> other @epel package in use on the control servers is git, which shares no
> common dependencies with ansible1.9.
>
> Writing that down, I think I answered my own question (answer = why not
> "exclude" them from yum update?), but if you have an opinion you're willing
> to share, please do. The other @epel package dependencies are:
>
What I normally do in an enterprise setting is get the packages I am
going to install on the boxes and collect them to their own
repository. I then sign those packages with a rpm key that I control
and then have all the client boxes point to that repository. That way
I have better control of what is available to clients and if someone
decides that weechat should be installed on a server.. they will have
had to convince the change control team that it was needed. If the
systems were really change control or security critical, I make sure I
copy the source code for any auditing purposes or for
rebuilding/patching on my own as needed later.
The steps in setting up such a repository flow control is:
<EPEL> -- reposync --> <Local EPEL mirror> -- copy files I want
installed --> <Local Repo> --> Systems.
The below package list looks correct.
--
> python-crypto2.6
> python-httplib2
> python-jinja2-26
> python-keyczar
> sshpass
>
> # rpm -qp ansible1.9-1.9.6-2.el6.noarch.rpm --requires
> /usr/bin/python
> PyYAML
> config(ansible1.9) = 1.9.6-2.el6
> python(abi) = 2.6
> python-crypto2.6
> python-httplib2
> python-jinja2-26
> python-keyczar
> python-paramiko
> python-setuptools
> python-simplejson
> python-six
> rpmlib(CompressedFileNames) <= 3.0.4-1
> rpmlib(FileDigests) <= 4.6.0-1
> rpmlib(PartialHardlinkSets) <= 4.0.4-1
> rpmlib(PayloadFilesHavePrefix) <= 4.0-1
> rpmlib(VersionedDependencies) <= 3.0.3-1
> sshpass
> rpmlib(PayloadIsXz) <= 5.2-1
>
> # repoquery --requires ansible
> /usr/bin/python2.6
> PyYAML
> python(abi) = 2.6
> python-crypto
> python-crypto2.6
> python-httplib2
> python-jinja2-26
> python-keyczar
> python-paramiko
> python-setuptools
> python-simplejson
> python-six
> python2-jmespath
> sshpass
>
> # yum history info 7
> Loaded plugins: fastestmirror
> Transaction ID : 7
> Begin time : Fri Nov 3 12:13:07 2017
> Begin rpmdb : 218:9695f8cd22db900948a11d2d1346ec 6f4728e54a
> End time : 12:13:22 2017 (15 seconds)
> End rpmdb : 234:5cef426bcb5a193a4595179386f2b1 900998507b
> User : root <root>
> Return-Code : Success
> Command Line : install ansible1.9-1.9.6-2.el6.noarch.rpm
> Transaction performed with:
> Installed rpm-4.8.0-55.el6.i686 @CentOS/6.9
> Installed yum-3.2.29-81.el6.centos.noarch @CentOS/6.9
> Installed yum-plugin-fastestmirror-1.1.30-40.el6.noarch @CentOS/6.9
> Packages Altered:
> Dep-Install PyYAML-3.10-3.1.el6.i686 @base
> Install ansible1.9-1.9.6-2.el6.noarch
> @/ansible1.9-1.9.6-2.el6.noarch
> Dep-Install libyaml-0.1.3-4.el6_6.i686 @base
> Dep-Install python-babel-0.9.4-5.1.el6.noarch @base
> Dep-Install python-crypto-2.0.1-22.el6.i686 @base
> Dep-Install python-crypto2.6-2.6.1-2.el6.i686 @epel
> Dep-Install python-httplib2-0.7.7-1.el6.noarch @epel
> Dep-Install python-jinja2-26-2.6-3.el6.noarch @epel
> Dep-Install python-keyczar-0.71c-1.el6.noarch @epel
> Dep-Install python-markupsafe-0.9.2-4.el6.i686 @base
> Dep-Install python-paramiko-1.7.5-2.1.el6.noarch @base
> Dep-Install python-pyasn1-0.0.12a-1.el6.noarch @base
> Dep-Install python-setuptools-0.6.10-3.el6.noarch @base
> Dep-Install python-simplejson-2.0.9-3.1.el6.i686 @base
> Dep-Install python-six-1.9.0-2.el6.noarch @base
> Dep-Install sshpass-1.06-1.el6.i686 @epel
> history info
>
>
>
>
>
> On Thu, Nov 2, 2017 at 2:48 PM, Kevin Fenzi <kevin@xxxxxxxxx> wrote:
>>
>> On 11/02/2017 11:03 AM, Peter Rex wrote:
>> > Thanks for the info, Ricardo. Hadn't found the retirement notice.
>> > Security,
>> > I guess. I can't resist saying, though, that I regret using Ansible and
>> > my
>> > assumption that one of the Es in EPEL stood for Enterprise. Oh well,
>> > live
>> > and learn.
>>
>> Sorry things didn't work out as you would have liked.
>>
>> ansible1.9 was always intended as a short term 'bridge' to help give
>> folks more time to migrate to 2.0. When upstream stopped supporting it,
>> we retired it in EPEL as well. ansible is very very fast moving and
>> complex and there's no way we could backport even security fixes to an
>> out of date 1.9 version. Sorry.
>>
>> You can of course still use 1.9 if you wish, just realize that it
>> doesn't get any bugfixes or security updates.
>>
>> kevin
>>
>>
>>
>> _______________________________________________
>> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
>> To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org
>>
>
>
> _______________________________________________
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org
>
Stephen J Smoogen.
_______________________________________________
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org
_______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
