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, fc26/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, fc26/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, fc26/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.

37 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
  7. JC

    Hi Nuxref,

    Can I request that the sabnzbd package be updated? Current version is 2.2, and the version in your repo is stuck at 1.x

    Reply
  8. orn

    yum install sonarr

    Error: Package: nodejs-error-ex-1.3.0-2.el7.nuxref.noarch (nuxref)
    Requires: npm(is-arrayish)
    Error: Package: nodejs-error-ex-1.3.0-2.el7.nuxref.noarch (nuxref)
    Requires: npm(is-arrayish) <= 0.3.0
    You could try using –skip-broken to work around the problem
    You could try running: rpm -Va –nofiles –nodigest

    Reply
    1. l2g Post author

      Good find! Thank you for pointing that out. I had the RPM built but not available on my repository. It is now though! ๐Ÿ™‚ Giver another go!

      Reply
    1. l2g Post author

      Good catch; python-sabyenc has been added now.

      Your system (via dnf) may have already cached what I had hosted (missing the package), so you might have to do the following first in order to haul it in:

      # Just clear out repository cache for nuxref content
      dnf clean all --disablerepo=* --enablerepo=nuxref*

      # now SABnzbd should install:
      dnf install sabnzbd

      That will allow your local side to resync with mine (but not touch any other repositories you may already have set up such as epel, etc).

      Not sure if you’ve used my packages before, but I have a write-up on how I set SABnzbd up if it helps.

      Reply
  9. steve schooler

    Thanks for the reply; my sabnzbd installation went smoothly, following your instructions. I then followed the instructions at http://nuxref.com/2016/10/20/sabnzbd-installation-centos-7/:

    login as steve
    usermod -a -G sabnzbd steve
    logout
    login as steve
    systemctl start sabnzbd.service
    firefox : http://localhost:8090

    firefox result : problem loading page – unable to connect

    I request any advice. I have no firewall. Using fedora 26 because 10 days ago my fedora 22 boot disk died. About two years ago, under fedora 22 cinnamon, the sabnzbd install went okay, providing a f22-cinnamon menu item. Apparently, that install took me to http://127.0.0.1:8080/sabnzbd/. Experimenting, I tried various combinations to see if the problem was http://localhost:8090 : no joy. Below is the tail of /var/log/sabnzbd/sabnzbd.log

    ———— start of tail of log —————–

    2017-09-11 12:50:04,376::INFO::[postproc:82] Saving postproc queue
    2017-09-11 12:50:04,376::INFO::[__init__:941] Saving data for postproc2.sab in /var/lib/sabnzbd/admin/postproc2.sab
    2017-09-11 12:54:18,722::INFO::[SABnzbd:1147] ——————————–
    2017-09-11 12:54:18,734::INFO::[SABnzbd:1148] SABnzbd.py-2.2.1 (rev=bcc4dd75cfeab41a4b56308709c04fd568859d1f)
    2017-09-11 12:54:18,734::INFO::[SABnzbd:1149] Full executable path = /usr/share/sabnzbd/SABnzbd.py
    2017-09-11 12:54:18,735::INFO::[SABnzbd:1161] Platform = posix
    2017-09-11 12:54:18,735::INFO::[SABnzbd:1162] Python-version = 2.7.13 (default, Sep 5 2017, 08:53:59)
    [GCC 7.1.1 20170622 (Red Hat 7.1.1-3)]
    2017-09-11 12:54:18,735::INFO::[SABnzbd:1163] Arguments = /usr/share/sabnzbd/SABnzbd.py –logging=1 –browser=0 –config-file=/etc/sabnzbd/sabnzbd.conf
    2017-09-11 12:54:18,735::INFO::[SABnzbd:1168] Preferred encoding = UTF-8
    2017-09-11 12:54:18,735::INFO::[SABnzbd:1209] Read INI file /etc/sabnzbd/sabnzbd.conf
    2017-09-11 12:54:18,760::INFO::[__init__:964] Loading data for rss_data.sab from /var/lib/sabnzbd/admin/rss_data.sab
    2017-09-11 12:54:18,766::INFO::[__init__:964] Loading data for totals10.sab from /var/lib/sabnzbd/admin/totals10.sab
    2017-09-11 12:54:18,767::INFO::[postproc:88] Loading postproc queue
    2017-09-11 12:54:18,767::INFO::[__init__:964] Loading data for postproc2.sab from /var/lib/sabnzbd/admin/postproc2.sab
    2017-09-11 12:54:18,768::INFO::[__init__:964] Loading data for queue10.sab from /var/lib/sabnzbd/admin/queue10.sab
    2017-09-11 12:54:18,769::INFO::[__init__:964] Loading data for watched_data2.sab from /var/lib/sabnzbd/admin/watched_data2.sab
    2017-09-11 12:54:18,770::INFO::[__init__:964] Loading data for Rating.sab from /var/lib/sabnzbd/admin/Rating.sab
    2017-09-11 12:54:18,771::INFO::[__init__:967] /var/lib/sabnzbd/admin/Rating.sab missing
    2017-09-11 12:54:18,772::INFO::[scheduler:201] Setting schedule for midnight BPS reset
    2017-09-11 12:54:18,772::INFO::[__init__:343] All processes started
    2017-09-11 12:54:18,772::INFO::[SABnzbd:281] Web dir is /usr/share/sabnzbd
    2017-09-11 12:54:18,773::WARNING::[SABnzbd:285] Cannot find web template: /usr/share/sabnzbd/templates/main.tmpl, trying standard template
    2017-09-11 12:54:18,784::INFO::[SABnzbd:281] Web dir is /usr/share/sabnzbd/interfaces/Config
    2017-09-11 12:54:18,801::INFO::[config:855] Writing settings to INI file /etc/sabnzbd/sabnzbd.conf
    2017-09-11 12:54:18,837::INFO::[SABnzbd:405] SABYenc module (v3.0.2)… found!
    2017-09-11 12:54:18,837::INFO::[SABnzbd:424] Cryptography module… NOT found!
    2017-09-11 12:54:18,837::INFO::[SABnzbd:427] par2 binary… found (/usr/bin/par2)
    2017-09-11 12:54:18,837::INFO::[SABnzbd:435] UNRAR binary… found (/usr/bin/unrar)
    2017-09-11 12:54:18,837::INFO::[SABnzbd:448] unzip binary… found (/usr/bin/unzip)
    2017-09-11 12:54:18,837::INFO::[SABnzbd:453] 7za binary… found (/usr/bin/7za)
    2017-09-11 12:54:18,837::INFO::[SABnzbd:459] nice binary… found (/usr/bin/nice)
    2017-09-11 12:54:18,837::INFO::[SABnzbd:463] ionice binary… found (/usr/bin/ionice)
    2017-09-11 12:54:18,837::INFO::[SABnzbd:1254] SSL version OpenSSL 1.1.0f-fips 25 May 2017
    2017-09-11 12:54:18,838::INFO::[SABnzbd:1255] SSL supported protocols [‘TLS v1.2’, ‘TLS v1.1’, ‘TLS v1’, ‘SSL v3’]
    2017-09-11 12:54:18,839::INFO::[SABnzbd:1365] Starting web-interface on 127.0.0.1:8080
    2017-09-11 12:54:18,839::INFO::[_cplogging:219] [11/Sep/2017:12:54:18] ENGINE Bus STARTING
    2017-09-11 12:54:18,848::INFO::[_cplogging:219] [11/Sep/2017:12:54:18] ENGINE Started monitor thread ‘_TimeoutMonitor’.
    2017-09-11 12:54:19,097::INFO::[_cplogging:219] [11/Sep/2017:12:54:19] ENGINE Serving on http://127.0.0.1:8080
    2017-09-11 12:54:19,099::INFO::[_cplogging:219] [11/Sep/2017:12:54:19] ENGINE Bus STARTED
    2017-09-11 12:54:19,106::INFO::[zconfig:64] No Bonjour/ZeroConfig support installed
    2017-09-11 12:54:19,106::INFO::[SABnzbd:1410] Starting SABnzbd.py-2.2.1
    2017-09-11 12:54:19,111::INFO::[dirscanner:327] Dirscanner starting up
    2017-09-11 12:54:19,112::INFO::[urlgrabber:72] URLGrabber starting up
    2017-09-11 12:54:19,141::INFO::[postproc:169] Completed Download Folder /var/lib/sabnzbd/complete is not on FAT
    2017-09-11 12:54:29,904::WARNING::[__init__:181] Signal 15 caught, saving and exiting…
    2017-09-11 12:54:29,904::INFO::[nzbqueue:274] Saving queue
    2017-09-11 12:54:29,904::INFO::[__init__:941] Saving data for queue10.sab in /var/lib/sabnzbd/admin/queue10.sab
    2017-09-11 12:54:29,904::INFO::[__init__:941] Saving data for totals10.sab in /var/lib/sabnzbd/admin/totals10.sab
    2017-09-11 12:54:29,905::INFO::[__init__:941] Saving data for rss_data.sab in /var/lib/sabnzbd/admin/rss_data.sab
    2017-09-11 12:54:29,905::INFO::[__init__:941] Saving data for watched_data2.sab in /var/lib/sabnzbd/admin/watched_data2.sab
    2017-09-11 12:54:29,905::INFO::[postproc:82] Saving postproc queue
    2017-09-11 12:54:29,905::INFO::[__init__:941] Saving data for postproc2.sab in /var/lib/sabnzbd/admin/postproc2.sab

    ———— end of tail of log —————–

    Reply
    1. l2g Post author

      It could very well just be a typo in my blog. Your configuration file will be in /etc/sabnzbd/sabnzbd.conf.

      You can see what port is defined there. If you can access http://localhost:8080 after you install it then you’re in great shape! You can do any future configuring from within the SABnzb website when it comes up.

      You could also try doing the follow after you’ve started it up:

      # list all of the ports your system is listening on that match
      # the regular expression 80.0 (8080 would match, so would 8090)
      netstat -nat | egrep -i listen | egrep :80.0

      At least that will give you some insight on what to try next.

      Feel free to message me again if you have problems. I’m slow responding because I’m out of town right now. Good luck!

      Reply
  10. steve schooler

    Total success, thanks again for your responses. In my previous query, I provided an excerpt from the log just in case my sabnzbd was malfunctioning, which it was not. Based on the results of your suggested netstat command, it appeared that http://127.0.0.1:8080/sabnzbd/ would work for me. In fact, this url does work. Interesting that the install of two years ago actually created a menu app (in fedora 22 – cinnamon); launching this app placed an icon in the system tray and simultaneously invoked http://127.0.0.1:8080/sabnzbd/ in the web browser.

    Your latest sabnzbd has streamlined this to eliminate the app, the user merely ensures that the sabnzbd service is started and then manually launches http://127.0.0.1:8080/sabnzbd/ (et al) in his web browser. BTW
    1. I found that “systemctl enable sabnzbd.service” does work across reboots, but after executing this bash command, I had to do a cold boot (rather than mere logout) to “initiate” the service.
    2. Selecting the “shutdown sabnzbd” command from the upper right portion of the http://127.0.0.1:8080/sabnzbd/ webpage is apparently equivalent to “systemctl stop sabnzbd.service”.

    Reply
    1. l2g Post author

      Just to address the first of your 2 points (for future reference).
      1. systemctl enable <service.name> does just that.. it just enables the service so that it can start on system boot (as you already know). systemctl start <service.name> is all the magic that happens at boot; so you can run this yourself (and save yourself from rebooting your server in the future).

      Otherwise, I’m glad hear you got everything going and thanks for your feedback. I updated the blog to reference 8080 instead of 8090.

      Reply

Leave a Reply

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