2017-02-07

Major update to Nagios in Fedora Rawhide and EPEL-7 [moving to 4.2.4]

After a couple months of work, I have put together an updated package for Fedora Rawhide and EPEL-7 today. I expect it will have some 'problems' and so have moved the needed karma to 4 and am looking for people to test and give it negative karma with feedback for items broken.

I will work on getting those done this week so we can try and have working versions of Nagios for Fedora Server 26 and EPEL. Currently I expect it to need changes to the selinux policies for both and may need some additional work there. I am working through the processes for getting those done.

EPEL-6 will need some more work because the rpmbuild is complaining that it can't make /var/run/nagios for some reason.

Creating a new update for  nagios-4.2.4-2.el7 
================================================================================
     nagios-4.2.4-2.el7
================================================================================
  Update ID: FEDORA-EPEL-2017-0f3297a19b
    Release: Fedora EPEL 7
     Status: pending
       Type: security
      Karma: 0
    Request: testing
       Bugs: 1288989 - None
           : 1289710 - None
           : 1299166 - None
           : 1322666 - None
           : 1329857 - None
           : 1330627 - None
           : 1341683 - None
           : 1405365 - None
           : 1411399 - None
      Notes: Major Update. Fixes various CVE and other issues.
  Submitter: smooge
  Submitted: 2017-02-07 23:46:16
   Comments: bodhi - 2017-02-07 23:46:17 (karma 0)
             This update has been submitted for testing by smooge.

  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-0f3297a19b


Major update to Fedora/EPEL moving to nrpe-3.0.1

The version of nrpe in Fedora has been 2.15 for a very long time while the upstream Nagios group moved to a 3.0 series. With some work and a lot of help from my friends, I have put an updated nrpe into EPEL-testing for EPEL-6 and EPEL-7 and in Fedora Rawhide.

EPEL

I have put the EPEL update karma for this to be 4 versus 3 as I would like some more testing done by people before it gets working. If it gets a lot of negative karma I will pull it and work with upstream to get a working version into EPEL.

Rawhide

This version of nrpe was the 'fun' one. This is due to the fact that the newer OpenSSL does not allow for introspection of various structures which it used to. Working with Tomas Mraz and Patrick Uiterwijk, I believe I have a semi-working version. [A secondary problem was that I had to pull some sslv2 code out because we do not ship with those libraries anymore. I am hoping upstream will come up with a better fix than my hacksaw method.]

Fedora 25

I have not put in an update to Fedora 25 because it is a major update and was not listed as a change request. I am looking through what needs to be done for this, and when I have gotten any approvals needed will publish it to Fedora 25 testing.

2017-02-01

Reminder to self: Using Dennet's principles

These last couple of weeks have been a complete emotional and intellectual mess for me. People are arguing to the right of me, to the left of me and everyone seems to have pulled out their favorite purity test to try and prove if someone is good enough to be in their camp.

In trying to come up with clearer axioms to gauge all the various poop-storms without getting into emotives or purity tests, I ran into this article about Daniel Dennet's tools for trying to be a critical thinker. I will report the paraphrase below:

  1. Accept you make mistakes, and then use them to be a better person.
  2. Respect your opponent. 
  3. Beware of "surely" as it is overused as a rhetorical device to avoid critical thinking by assuming something is sure.
  4. Answer rhetorical questions. As with 'surely', using a rhetorical question is a way to avoid thinking about something by being facetious.
  5. Employ Occam's Razor
  6. Employ Sturgeon's Law. 90% of everything is rubbish... [which cuts both ways.] Don't waste your time defending rubbish and don't waste your time attacking it. Work on the 10-20% which isn't.
  7. Avoid deepities... things which are deep and profound but not well defined. [Another way of looking at it is "If it sounds too good to be true, it probably is".] 
Anyway thanks to Jonathan Corbet of lwn.net for reminding me of the Sturgeon's law wikipedia article which lead me to that piece.

2017-01-17

Mea Culpa: Fedora Elections

As announced here, here , and here, the Fedora Election cycle for the start of the 25 release has been done. Congratulations on the winners. Now if you notice there were less than 250 voters for any of the elections out of multiple thousand of eligible voters.. I am not one of them.

It is not like the elections were announced before, at the start, or right before they ended. Yet somehow.. I missed everyone of these emails. I caught various emails on NFS changing configurations, proposed changes to Fedora 26 and 27, or various retired packages.. but I completely spaced the elections. I was actually sending an email asking when they would be held when someone congratulated Kevin Fenzi on IRC about winning.

So to the winners of this cycle of elections. Congratulations. To all the people who put in the hard work of running elections (and having run several it is a LOT of hard work), my sincere apologies for somehow missing it.

2017-01-07

Fedora/EPEL Mirrormanager problems in Asia Pacific countries.

We have been getting a lot of reports of people unable to get updates for EPEL or Fedora at various times. What people are seeing is that they will do a 'yum update' and it will give a long list of failures and quit. At this moment we seem to have pinpointed that most of the people having this problem are in various Asia Pacific nations (primarily Australia and Japan). The problem for both of these seems to be a lack of cross connects between networks.

In the US, if you are on Comcast in say New Mexico and going to a server on Time Warner in North Carolina, your route is usually pretty direct. You will go from one network to various third party providers who will then send the packets the quickest path to the eventual server. If you use a visual grapher of locations, you even find that the path usually follows a linear path. [You might end up going to say California or Seattle first but that is only when Texas and Colorado cross connects are full.] Similarly in most European countries you also see a similar routing algorithm.

In the various Pacific and Indian Ocean countries, you do not see similar interconnects. You can watch a system in Sydney on one network send packets all the way to San Francisco and back again to a server in Sydney because the two telecoms do not 'talk' with each other. This seems to happen also in Japan for a couple of telecom networks. The result of this is that it is much more expensive to mirror data in those countries than you would think. For users it might be faster to get data from mainland China or the United States than it is to get it from a server only hundreds of miles away.

The problem is that mirrormanager is currently not coded to deal with that. It makes an optimistic assumption that you are in Adele and the nearest server is in Sydney.. you should go to that. The mirror in Sydney though is still catching up with data from pulling things in the mainland US (or if the mirror admin made the assumption that an asia pacific mirror is the one to go to.. may be pulling data from a server 20 miles physically and several tens of thousand miles away by network.) The mirrormanager developers are trying to figure out ways to deal with this without making servers and clients having to send each other network maps with throughput charts to figure out things.. [And no the fastest mirror yum plugin doesn't fix this for all/most people. It uses a very very simple 'works for me' test to figure out what mirrors might be a good match at one point in time. You could end up with using a poor mirror 90% of the time but the one time it set itself up.. it also just uses the "hey ping is fast" dynamic which breaks for people on various networks. Improving the fastest mirror plugin would be useful if someone did it.]

So what to do? For EPEL, the current fix is to edit your /etc/yum.repos.d/epel.repo files by adding a '&country=global'



[epel]
name=Extra Packages for Enterprise Linux 7 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch&country=global
failovermethod=priority
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7


This will cause yum to ask for the global versus 'local' and you will get all the mirrors. This usually will give a few servers which are in sync even if they are 'not' local.

2016-12-10

Why are EPEL python packages getting renamed?

Someone joined the irc.freenode.net #epel channel on early Saturday (2016-12-10) and asked:


[2016-12-10-07:33 UTC]  hi, it seems that python-pip was renamed to python2-pip, is there any documentation available why that choice was made?

By the time I got to IRC (12 hours later), they had left so I am going to try and answer them here. . Python packages in EPEL are made like every other package from Fedora. Currently Fedora is working on finishing making Python3 their default python and moving the older python to python2 naming. In doing so python packages are either being named python2 or python3 depending on which chain they are built against. This is going to have an effect on the names of Python packages in EPEL for EL6 and EL7 as the changes occur. For more information on Fedora Python packaging guidelines please see the following link.

2016-12-01

Puppet not coming back to EPEL EL-6

I made a grievous mistake in my previous blog post about the removal of Puppet Software and would it be coming back to EL-6. At the time, I misread someone's IRC comment and thought it was. However after a couple of days of not seeing any updated builds in Koji, I decided to check and found out I was wrong. The maintainers (and upstream) will not be putting puppet back in EL-6 for a couple of good reasons:

  1. The version that was in EL-6 was actually a very old version no longer maintained or updated by PuppetLabs. 
  2. Puppetlabs maintains a set of packages which will work on EL-6 distributions and focuses their attention there for problems and bug fixes.
So what to do? The upstream recommends that users of puppet use the one available from from Puppetlabs called puppet collections. The documentation on setting up the repository and using it are pretty clear, but for security sakes I will add a couple of steps.

$ sudo -i
# mkdir /root/puppet; cd /root/puppet
# wget https://yum.puppetlabs.com/puppetlabs-release-pc1-el-6.noarch.rpm

if you want to try and check the signature before installing you can add the following steps:

# wget https://yum.puppetlabs.com/RPM-GPG-KEY-puppetlabs
# rpm --import RPM-GPG-KEY-puppetlabs
# rpm -K puppetlabs-release-pc1-el-6.noarch.rpm 
however this does mean altering the rpm database before you check to see if it is ok.

# yum localinstall puppetlabs-release-pc1-el-6.noarch.rpm

if you are wanting a local copy of the repository for other boxes to install from you can use 'reposync'. For more on configuration management, you might also want to look at or join the CentOS Configuration Management Special Interest Group

[UPDATE: The old packages for puppet are still in Fedora Koji at http://koji.fedoraproject.org/koji/buildinfo?buildID=609117 ]
[UPDATE2: For better instructions on how to carefully check GPG headers of packages before you install them willy nilly, try the following:
http://orcorc.blogspot.com/2008/08/gnupg-few-minutes-on-using-detached-and.html ]