XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    [SOLVED] Just FYI: current update seams to break NUT dependancies

    Scheduled Pinned Locked Moved XCP-ng
    29 Posts 11 Posters 1.4k Views 10 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • rzrR Offline
      rzr Vates 🪐 XCP-ng Team @FritzGerald
      last edited by rzr

      @FritzGerald said:

      @rzr: Sorry, first and foremost I totally forgot to say thank you very much. I really appreciate you work and effort for this "non-core" issue.

      You're welcome !

      ⚠ Keep in mind using/enabling ci repo can be dangerous but for this nut update the risk is low.

      Is there maybe anything particular you are interested in for me to test?

      Nothing specific, the regular use case but feel free to share to community your experience with your hardware:

      https://networkupstools.org/ddl/APC/Smart-UPS_750.html

      Then others can compare with other devices supported by N.U.T. :

      https://networkupstools.org/ddl/

      This makes me think, I have scavenged an APC BE400 but it looks like an offline device, unsure I will make anything useful soon.

      F 1 Reply Last reply Reply Quote 0
      • F Offline
        FritzGerald
        last edited by FritzGerald

        Good point.

        Quick install procedure for anyone interested. I use a USB connected APC Smart-UPS 750 (SMT750RMI2U) on a completely patched test "XCP-ng 8.3" server. To install ci packages run:

        yum install nut --enablerepo=xcp-ng-ci

        Most important, check that your USV device is properly connected and found using

        lsusb

        it should show something like:

        ...
Bus 002 Device 002: ID 051d:0003 American Power Conversion UPS
...

        Grab details then by:

        lsusb -s 002:002 -v

        which should give you something like

        [12:53 xcp-test ~]# lsusb -s 002:002 -v

Bus 002 Device 002: ID 051d:0003 American Power Conversion UPS
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x051d American Power Conversion
  idProduct          0x0003 UPS
  bcdDevice            1.06
  iManufacturer           1 American Power Conversion
  iProduct                2 Smart-UPS 750 FW:UPS 15.1 / ID=18
  iSerial                 3 SERIALXXXXXXXX
  bNumConfigurations      1
...
  Remote Wakeup Enabled

        Based upon this data you can add this information to your ups.conf

        nano /etc/ups/ups.conf

        [apc]
        driver = "usbhid-ups"
        port = "auto"
        vendorid = "051D"
        productid = "0003"
        product = "Smart-UPS 750 FW:UPS 15.1 / ID=18"
        serial = "SERIALXXXXXXXX"
        vendor = "American Power Conversion"
        bus = "002"

        Now add users in nano /etc/ups/upsd.users. "upsmon" is for slave connected devices.

        [admin]
      password = PWXXXXXX
      actions = SET FSD
      instcmds = ALL
      upsmon master

[upsmon]
      password = SLAVEPW
      upsmon slave

        Now add/enable via nano /etc/ups/upsd.conf the required lines. If you want other servers to listen, you need to listen to a non-localhost IP of course.

        LISTEN 127.0.0.1 3493

        Now enable in nano /etc/ups/upsmon.conf the relevant line:

        MONITOR apc@localhost 1 admin PWXXXXXX master

        Now restart services:

        upsdrvctl start
systemctl start nut-server.service
systemctl start nut-monitor.service

        and you should be able to see the USV data by calling:

        upsc apc@localhost

        It should show:

        battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.runtime: 3900
battery.runtime.low: 120
battery.type: PbAc
battery.voltage: 27.3
battery.voltage.nominal: 24.0
device.mfr: American Power Conversion
device.model: Smart-UPS 750
device.serial: SERIALXXXXX
device.type: ups
driver.name: usbhid-ups
driver.parameter.bus: 002
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.product: Smart-UPS 750 FW:UPS 15.1 / ID=18
driver.parameter.productid: 0003
driver.parameter.serial: SERIALXXXXX
driver.parameter.synchronous: auto
driver.parameter.vendor: American Power Conversion
driver.parameter.vendorid: 051D
driver.version: 2.8.0
driver.version.data: APC HID 0.98
driver.version.internal: 0.47
driver.version.usb: libusb-0.1 (or compat)
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.firmware: UPS 15.1 / ID=18
ups.mfr: American Power Conversion
ups.mfr.date: 2015/08/14
ups.model: Smart-UPS 750
ups.productid: 0003
ups.serial: SERIALXXXXX
ups.status: OL
ups.timer.reboot: -1
ups.timer.shutdown: -1
ups.vendorid: 051d

        HINT#1: I experienced that the bus id of the usb device sometimes changes after reboot. Watch out if you restart the server and adapt your ups.conf accordingly!!!

        HINT#2: You need to open firewall port 3493 if you want to access it from a monitor!

        1 Reply Last reply Reply Quote 1
        • F Offline
          FritzGerald @rzr
          last edited by

          @rzr Just for curiosity.

          As far as I understand you assess the risk as low for the nut package - and only for that - to use ci-repo. I am fine with that for my personal servers. In terms of staying as close to the stable version in order to avoid potential future upgrade issues, is there a chance to say something about:

          • Would you consider to integrate this into "stable" branch?
          • What would be the next steps on our side to support this?
          • How long would does that roughly take?

          Thank again!

          rzrR 1 Reply Last reply Reply Quote 0
          • rzrR Offline
            rzr Vates 🪐 XCP-ng Team @FritzGerald
            last edited by

            @FritzGerald said:

            @rzr Just for curiosity.

            As far as I understand you assess the risk as low for the nut package - and only for that - to use ci-repo. I am fine with that for my personal servers.

            • Would you consider to integrate this into "stable" branch?

            yes it's the plan, we usually test packages in ci repos for a couple of weeks and once we're happy of the packages set it goes to testing repo, then users can officially test it (and based on feedback (or absence of feedback) then everything lands in update repo after a week or more (it depends on risk or hurry)..

            • What would be the next steps on our side to support this?

            I think nothing should be done your side you did your job before the testing window, early feedback is always appreciated (as long people know what they are doing 😉 )

            But If I were you, just to be safe i would keep trace of packages i have installed from ci or testing repo, in case anything is not going as expected, you can still reinstall those packages from update channel.

            • How long would does that roughly take?

            It depends usually a couple of weeks, but this next batch might be a bit longer because there is a long waited feature planned.

            Check the future announcement in the forum.

            Thank again!

            thank you for the detailed howto, if there is traction for this feature maybe it worth documenting officially, I'll ask product managers.

            F 1 Reply Last reply Reply Quote 1
            • F Offline
              FritzGerald @rzr
              last edited by

              @rzr Great. Thank you!

              rzrR 1 Reply Last reply Reply Quote 1
              • rzrR rzr referenced this topic
              • rzrR Offline
                rzr Vates 🪐 XCP-ng Team @FritzGerald
                last edited by

                Package landed in testing repo please check the related announcement:

                https://xcp-ng.org/forum/topic/9964/xcp-ng-8-3-updates-announcements-and-testing/432

                Then please confirm the issue is gone by editing post topic with "[SOLVED]" prefix

                1 Reply Last reply Reply Quote 1
                • C Offline
                  cobordism
                  last edited by

                  Just for the record, I get the same snmp errors with OpenIPMI instead of nut.

                  # yum update --disablerepo=* --enablerepo=xcp-ng-base,xcp-ng-updates 
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Excluding mirror: updates.xcp-ng.org
 * xcp-ng-base: mirrors.xcp-ng.org
Excluding mirror: updates.xcp-ng.org
 * xcp-ng-updates: mirrors.xcp-ng.org
Resolving Dependencies
--> Running transaction check
---> Package net-snmp.x86_64 1:5.7.2-52.1.xcpng8.3 will be updated
---> Package net-snmp.x86_64 1:5.9.3-8.1.xcpng8.3 will be an update
---> Package net-snmp-agent-libs.x86_64 1:5.7.2-52.1.xcpng8.3 will be updated
---> Package net-snmp-agent-libs.x86_64 1:5.9.3-8.1.xcpng8.3 will be an update
---> Package net-snmp-libs.x86_64 1:5.7.2-52.1.xcpng8.3 will be updated
--> Processing Dependency: libnetsnmp.so.31()(64bit) for package: OpenIPMI-2.0.23-2.el7.x86_64
---> Package net-snmp-libs.x86_64 1:5.9.3-8.1.xcpng8.3 will be an update
--> Finished Dependency Resolution
Error: Package: OpenIPMI-2.0.23-2.el7.x86_64 (@xcp-ng-base)
           Requires: libnetsnmp.so.31()(64bit)
           Removing: 1:net-snmp-libs-5.7.2-52.1.xcpng8.3.x86_64 (@xcp-ng-updates)
               libnetsnmp.so.31()(64bit)
           Updated By: 1:net-snmp-libs-5.9.3-8.1.xcpng8.3.x86_64 (xcp-ng-updates)
              ~libnetsnmp.so.40()(64bit)
           Available: 1:net-snmp-libs-5.7.2-33.el7_5.2.x86_64 (xcp-ng-base)
               libnetsnmp.so.31()(64bit)
           Available: 1:net-snmp-libs-5.7.2-51.1.xcpng8.3.x86_64 (xcp-ng-base)
               libnetsnmp.so.31()(64bit)
           Available: 1:net-snmp-libs-5.7.2-51.2.xcpng8.3.x86_64 (xcp-ng-base)
               libnetsnmp.so.31()(64bit)
           Available: 1:net-snmp-libs-5.7.2-51.3.xcpng8.3.x86_64 (xcp-ng-base)
               libnetsnmp.so.31()(64bit)
                  rzrR 1 Reply Last reply Reply Quote 0
                  • rzrR Offline
                    rzr Vates 🪐 XCP-ng Team @cobordism
                    last edited by rzr

                    @cobordism said:

                    yum update --disablerepo=* --enablerepo=xcp-ng-base,xcp-ng-updates

                    It's currently in testing and will move to updates if everything (not only nut) is ok:

                    yum install --disablerepo=* \
   --enablerepo=xcp-ng-base,xcp-ng-updates,xcp-ng-testing  nut
                    1 Reply Last reply Reply Quote 0
                    • F Offline
                      FritzGerald
                      last edited by

                      Hi, I just wanted to comment that the provided packages work for all my server. Thank you!

                      1 Reply Last reply Reply Quote 0

                      Hello! It looks like you're interested in this conversation, but you don't have an account yet.

                      Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

                      With your input, this post could be even better 💗

                      Register Login
                      • First post
                        Last post