NuxRef Repository

Introduction

The NuxRef Repository contains packages I maintained which are either original or a fork of the original changed for my own needs. Most RPMs on here are additionally featured in my blog entries.

Note: These repositories only supports 64-bit architectures.

Setup

The following RPMs will get you set up:

Repositories

Content/Repositories are grouped as follows:

  • nuxrefel6/src/rss, el7/src/rss, fc22/src/rss, fc23/src/rss, fc24/src/rss, fc25/src/rss: All custom packages rebuilt reside here.
  • nuxref-testingel6/src/rss, el7/src/rss, fc22/src/rss, fc23/src/rss, fc24/src/rss, fc25/src/rss: This is where I build early releases of projects I took on as my own. It’s also where I build newer versions of code already shared in the nuxref repository above. Once I’m satisfied with something here, it’ll eventually move into the nuxref repository.
  • nuxref-sharedel6/src/rss, el7/src/rss, fc22/src/rss, fc23/src/rss, fc24/src/rss, fc25/src/rss: This is really just a snapshot in time of packages I used from the different external repositories I don’t maintain. It may not always be up to date, but it can be thought of as a baseline I use to support other blog entries I wrote. Anything you intend to install from the nuxref or the nuxref-testing repository may also require dependencies. I try to include those here to ease things for other people so they don’t run into dependency nightmares in the future. It’s also important to note that even though these packages are not mine, I re-write their rpm signature as an act to let you know it’s safe.

Repository Priorities

Most of my packaging is original, but some of it is based on and/or replaces content to which other repositories neglected or had just simply forgotten to maintain. I’ll only repackage something here because I either found a bug, or that I updated it to a more recent version. This process can however introduce conflicts over time when the original source finally gets around to updating their version. As recommended in one of the comments below, it would be advisable to install yum-priorities on your system. This can allow the original’s sources content to always over-ride mine.

# CentOS 6 & 7 users may wish to do this:
yum install yum-plugin-priorities

# DNF (for Fedora users) already has priorities built into it
# The following command will lower the priority for you:
sed -i -e 's/^\(priority\)=.*/\1=2/g' /etc/yum.repos.d/nuxref.repo

Consider that this can also work against you as well. Some of the packages I host add additional enhancements and patches that improve the usability of the product. If you chose to lower the priority of this repository and acquire the one hosted by the original source, you may lose functionality you once had (hence the reason I repackaged it in the first place).

If there are ever conflicts with my repository and another, please feel free to email me and let me know or just leave a comment in comment section below. I have no problem upgrading packages (and/or just simply abandoning them if there is no need to rehost them anymore). My goal is to keep all of the 3rd party repositories out there in working harmony with mine (if I can). My repositories are to just simply offer another (open source) solution for people.

Appreciation

I do all this for free and only when I have time on weekends (and some evenings). This includes system updates, the repository hosting, and all of the research for new packaging that I share. I certainly want to be clear by saying that no one owes me anything at all. But if you want to lend a helping hand by just buying me a cup of coffee (if I was able to help you out), it would certainly be greatly appreciated.

26 thoughts on “NuxRef Repository

        1. Chris

          I finally got around to fulfilling your request. Have a look at the /etc/yum.repos.d/nuxref.conf so you can point it to my CentOS 7 repositories instead (of version 6). Alternatively, I updated this post. You can recreate the .conf file and it should work (using $releasever variable).

          I ported over nzbget v15.0 (which just came out a few days ago). But I have not ported over all of it’s addons yet. If you use them though, you can just download them directly from NZBGet’s Extension Forum and install them into /usr/share/nzbget/scripts and it ‘should’ all work for the time being (depending on who’s script you use).

          Good luck! 🙂

          Reply
  1. hansel

    Been using your repo’s some time on CentOS/ClearOS 6. Now it’s time to play with ClearOS 7 which is based on CentOS 7. When installing NZBGet I get the following dependency issue:
    [pre]Package nzbget.x86_64 0:16.3-1.el7.nuxref will be installed
    –> Processing Dependency: libgnutls.so.28(GNUTLS_1_4)(64bit) for package: nzbget-16.3-1.el7.nuxref.x86_64
    –> Processing Dependency: libgnutls.so.28()(64bit) for package: nzbget-16.3-1.el7.nuxref.x86_64
    –> Finished Dependency Resolution
    Error: Package: nzbget-16.3-1.el7.nuxref.x86_64 (nuxref)
    Requires: libgnutls.so.28(GNUTLS_1_4)(64bit)
    Error: Package: nzbget-16.3-1.el7.nuxref.x86_64 (nuxref)
    Requires: libgnutls.so.28()(64bit)[/pre]
    I cannot find any package called libgnutls in the ClearOS repos. Is this dependecy issue also present in fresh CentOS 7 install?

    Reply
    1. Chris

      you could try adding:
      yum –enablerepo=nuxref-shared –enablerepo=nuxref install nzbget

      I’m pretty sure I already captured all of the missing dependencies and place them in the nuxref-shared repo.

      Reply
  2. hansel

    For all ClearOS users…
    Fixed by first using the following yum command:

    # yum install gnutls --enablerepo=clearos-centos

    It install GnuTLS and a tool called “trousers” for dependecy.

    Reply
    1. l2g Post author

      Sure,

      I just built and packaged it now for you. I don’t have anytime to test it myself (just yet) so I’m just going to drop it in my testing repository for now. You’ll need to add –enable-repo=nuxref-testing to your call to yum.

      Hope that helps!

      Reply
    1. Ryan Dorman

      So i’ve been running this for a couple days with no show stoppers. The only “issue” i’m seeing is that whenever Nagios goes to send an email I get the following error (with changes for the PID and the Job number)

      job 22600 (pid=18350): read() returned error 11

      It still sends the email but that error gets logged. I highly doubt that this is a packaging issue it seems much more like a Nagios issue.

      One other thing to remember when you upgrade is that it resets (as it should) all of the permissions on Nagios config directories and files back to defaults. If you use a web-based configurator (I use Lilac-reloaded) or something else that interacts with the files you’ll have to go back and reset so that your apache user (or whatever user your process runs as) can write to the files and directories.

      Reply
      1. l2g Post author

        Thank you for passing along all your findings! I still have yet to try it out yet myself. Hopefully I’ll eventually get around to doing it soon.

        As per your first issue; it still may be my end (not sure). Do you have SELinux in enforcing mode by chance? I wrote all of the Nagios (SELinux) policies from scratch (originally for v4.1.1) since I couldn’t find any otherwise in the past. I’m just reusing the same ones for v4.2.0. It’s possible there are new features in this release that i need to account for (and update my policies). Would you mind passing along any error messages you see when you run the following and sharing your results; (if there is to much then maybe send it via email instead)?
        cat /var/log/audit/audit.log | egrep -i nagios | egrep -i deny

        As per your second comment; I have no problem adjusting my packaging a bit and altering some default permissions. Perhaps it would be easier if i set the nagios group with rwx permissions on the directories you’re having issues with (if they’re not already)?
        That way whatever user the Lilac-reloaded runs as, you just need to add it to the nagios group and it won’t be bothered by future updates. Alternatively; maybe this will simply fix your problem:
        # grant the lilac user access to all files owned
        # by the nagios group
        usermod -a -G nagios lilac

        Reply
        1. Ryan Dorman

          I’m in permissive mode on SELinux so no dice on the first part. As for the second yes, settings nagios group with rwx permissions on the /etc portions of the package would have solved my issue.

          Reply
          1. l2g Post author

            Thanks for all of your feedback. I finally got around to pushing one more update (still in the testing repo) that adds the (nagios) group permissions as discussed.

  3. feedmebits

    Hello,

    I came across this repo via a forum post somewhere. I usually only trust repos on the Centos 3rd party repos wiki page, this repo is not. So how trustworthy are the maintainers behind this repo? And can this repo be used in combination with epel?

    Reply
    1. l2g Post author

      I am the sole maintainer of every package you see here (except the shared repositories). I do this as a hobby on the side; I usually write a blog to go with it explaining their use (not all though). My packages are very legit; most of them are original too (some of which are even re-hosted on other peoples repositories such as Nux Dextop).

      The only thing I can’t promise you is when a new version of something is released, that it is available for everyone (here) right away. Some updates never get propagated here unless I get a request or find time. I post the source code (src.rpm) for every package I build and share for anyone who’s skeptical to rebuild or review it for themselves if they wish. I also sign my packages to help keep the integrity for those using dnf and yum to access the content.

      My repositories can definitely be used with EPEL or any other alike out there; absolutely. I wasn’t even aware of the ‘CentOS 3rd Party Repos‘ page until you just shared it with me; Thanks! I’ll pass my repo info along to them.

      Reply
  4. Karel

    Hi l2g, can you update NZBGet to 17.1? Current version in your repo is 16.3. I’m using your EL6 repo.
    Like your work! [ThumbsUp]

    Reply
    1. l2g Post author

      Unfortunately NZBGet v17.x was re-coded using a glib library that isn’t supported in CentOS 6.x; See here for more details. But basically that link takes you to a blog i wrote explaining (and sharing) the patch I created just to make NZBGet v17.0 work with CentOS 7.x. At this time, I don’t know what the effort would be to back port all of this code even further.

      Reply
  5. Karel

    Thanks l2g for your quick reply. It seems I can no longer postpone upgrading from CentOS 6 to 7. Will be on my to do list for the spring holidays this year.

    Regards.

    Reply
  6. Håkon

    Hi. You might want to add that installing yum-plugin-priorities is a strong recommendation, since without it there is a risk of conflicts between nuxref and epel repositories. Like for instance

    pkcon search name nagios
    Searching by name [=========================]
    Starting [=========================]
    Querying [=========================]
    Finished [=========================]
    Available nagios-4.2.2-2.el7.nuxref.x86_64 (nuxref) Open Source host, service and network monitoring program
    Available nagios-4.2.2-4.el7.nuxref.x86_64 (nuxref) Open Source host, service and network monitoring program
    Available nagios-4.2.4-2.el7.x86_64 (epel) Host/service/network monitoring program
    Available nagios-4.3.1-1.el7.nuxref.x86_64 (nuxref) Open Source host, service and network monitoring program
    ...
    Available nagios-plugins-1.5-5.el7.nuxref.x86_64 (nuxref) Host/service/network monitoring program plugins for Nagios
    Available nagios-plugins-2.1.3-1.el7.nuxref.x86_64 (nuxref) Host/service/network monitoring program plugins for Nagios
    Available nagios-plugins-2.1.4-2.el7.x86_64 (epel) Host/service/network monitoring program plugins for Nagios

    In this case, without priorities plugin installed, trying to run “yum install nagios nagios-plugins” will fail because the plugins package from epel have a newer version.

    Reply
    1. l2g Post author

      Your advice is welcome! This can honestly be said about any 3rd party repository to which you might prefer one over another. On a side note, I didn’t realize EPEL had finally upgraded their hosting of Nagios AND Nagios Plugins. That’s great news!

      I updated the page to consider your advice; but always consider the downside to priorities as well. On that note, I also updated Nagios plugins on my repository to accommodate what you had observed.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *