@HeMaN You're correct that no changes have been published yet.

We were under the impression that we had found an undocumented requirement, but I was reminded that giving each host the same certificate is not the best practice. xcp-ng should be able to handle each host having its own certificate as long as their respective certificate authorities are trusted.

In any case, I need to do some more testing to narrow down the exact cause of the issues that I was seeing. I have been working a systemd service and timer with a few supporting scripts that automatically renew certificates by making ACME requests to my local, private CA, specifically adding support for additional SANs (previous iterations just used the system's FQDN).

Specifically, I want to test each server with SANs that correspond to each of it's IP addresses and FQDNs, deploy them using xe host-server-certificate-install, then perform packet captures as needed to determine why the Xapi#getResource /rrd_updates (on xcp-ng-1) 0% task is getting stuck.

So far, life has gotten a bit in the way, so I haven't dedicated the time to testing this, but I hope to get back to this soon.

@florent the CR job was completed with health checks. The issue appears to be fixed in the fix_cr_healthcheck branch.

@Andrew @Danp - I discovered my boneheaded oversight

I have been developing on a one-shot systemd service with a timer for automatically renewing my short-lived XO certificate daily between a prescribed window of time using my local Step CA instance's ACME provisioner. It has been a fun project and I now have mostly automatic renewal of short-live certificates using what is essentially a private letsencrypt server that uses the CA that I generated.

I just looked at the logs and realized that I completely overlooked the fact that the the step-renewer.service is being run starting at midnight + random number of seconds between 0 and 5 minutes. This service will get a new certificate and then it restarts xo-server.service and that is what has been interrupting my backups.

Facepalm

With mixed feelings, I can confidently report that this issue is entirely self-induced. Thanks for the assistance narrowing down the cause!

@stormi @olivierlambert Please see my submitted PR and please provide feedback.

@irtaza9 happy to help!

@olivierlambert Thank you for bringing this to the attention of other folks

@andriy.sultanov great, thank you for taking that on!

I must have skimmed over that part of the docs too quickly to notice the recommendation to run usb_scan.py.

I think it would be helpful to explain more verbosely how the order and specificity impact the final outcomes as it's not clear to me. It seems that if I make a more specific rule for my Yubikey before a more general rule that would block devices of the same class, it seems to work, but perhaps not in reverse?

I'm reminded of the apache Order directive where it can be AllowDeny or DenyAllow — my dyslexic brain has a hard time keeping track of binaries.

tl;dr - empty line(s) in /etc/xensource/usb-policy.conf crashes /opt/xensource/libexec/usb_scan.py

I did a bit of scanning through the xapi source, in particular https://github.com/xapi-project/xen-api/blob/master/python3/libexec/usb_scan.py

I'm not a python expert, so I could generally follow the flow of things, but I wasn't totally sure what was happening at a detailed level. Then I did some googling and found this xenserver help doc regarding troubleshooting usb passthrough: https://support.citrix.com/external/article/235040/how-to-troubleshoot-xenserver-usb-passth.html

This article suggested running /opt/xensource/libexec/usb_scan.py with the -d parameter for additional details and that lead me to discover that the script fails when it encounters an empty line in usb-policy.conf

[23:46 xcp-ng-4 ~]# /opt/xensource/libexec/usb_scan.py -d
Traceback (most recent call last):
  File "/opt/xensource/libexec/usb_scan.py", line 681, in <module>
    pusbs = make_pusbs_list(devices, interfaces)
  File "/opt/xensource/libexec/usb_scan.py", line 660, in make_pusbs_list
    policy = Policy()
  File "/opt/xensource/libexec/usb_scan.py", line 384, in __init__
    self.parse_line(line)
  File "/opt/xensource/libexec/usb_scan.py", line 444, in parse_line
    if action.lower() == "allow":
UnboundLocalError: local variable 'action' referenced before assignment

After removing all empty lines, usb_scan.py scanned output properly, but it was giving me an empty array

[23:53 xcp-ng-4 ~]# /opt/xensource/libexec/usb_scan.py -d
[]

Since it as no longer crashing, I decided to go back to the default usb-policy.conf then try only adding my single allow rule without any extra lines and then test.

cp /etc/xensource/usb-policy.conf.default /etc/xensource/usb-policy.conf

I inserted a new line at line 10 just above the first rule and added my allow rule:

ALLOW:vid=1050 pid=0407

and that was all that was needed! Now I can see the device after running usb_scan.py

[23:53 xcp-ng-4 ~]# /opt/xensource/libexec/usb_scan.py -d
[{"path": "2-1.1", "version": "2.00", "vendor-id": "1050", "product-id": "0407", "vendor-desc": "Yubico.com", "product-desc": "Yubikey 4 OTP+U2F+CCID", "speed": "12", "serial": "", "description": "Yubico.com_Yubikey 4 OTP+U2F+CCID"}]

I also learned that the last good output of xe usb-scan seems to be cached somewhere and is quietly returned without hesitation when usb_policy.py fails. Maybe it's logged somewhere, but I don't know.

In any case, it was as simple as an empty line -- don't take anything for granted!

Lastly, I did a bit of testing to confirm that for my Yubikey to be detected and allowed, the allow rule must be BEFORE the rule that denies HID Boot Keyboards.

This results in detection:

# When you change this file, run 'xe pusb-scan' to confirm
# the file can be parsed correctly.
#
# Syntax is an ordered list of case insensitive rules where # is line comment
#  and each rule is (ALLOW | DENY) : ( match )*
#  and each match is (class|subclass|prot|vid|pid|rel) = hex-number
# Maximum hex value for class/subclass/prot is FF, and for vid/pid/rel is FFFF
#
# USB Hubs (class 09) are always denied, independently of the rules in this file
DENY: vid=17e9 # All DisplayLink USB displays
DENY: class=02 # Communications and CDC-Control
ALLOW:vid=056a pid=0315 class=03 # Wacom Intuos tablet
ALLOW:vid=056a pid=0314 class=03 # Wacom Intuos tablet
ALLOW:vid=056a pid=00fb class=03 # Wacom DTU tablet
# @jeff - allow passthrough of Yubikey 5 FIPS, "Yubikey 4 OTP+U2F+CCID"
ALLOW:vid=1050 pid=0407
DENY: class=03 subclass=01 prot=01 # HID Boot keyboards
DENY: class=03 subclass=01 prot=02 # HID Boot mice
DENY: class=0a # CDC-Data
DENY: class=0b # Smartcard
DENY: class=e0 # Wireless controller
DENY: class=ef subclass=04 # Miscellaneous network devices
ALLOW: # Otherwise allow everything else

This does not:

# When you change this file, run 'xe pusb-scan' to confirm
# the file can be parsed correctly.
#
# Syntax is an ordered list of case insensitive rules where # is line comment
#  and each rule is (ALLOW | DENY) : ( match )*
#  and each match is (class|subclass|prot|vid|pid|rel) = hex-number
# Maximum hex value for class/subclass/prot is FF, and for vid/pid/rel is FFFF
#
# USB Hubs (class 09) are always denied, independently of the rules in this file
DENY: vid=17e9 # All DisplayLink USB displays
DENY: class=02 # Communications and CDC-Control
ALLOW:vid=056a pid=0315 class=03 # Wacom Intuos tablet
ALLOW:vid=056a pid=0314 class=03 # Wacom Intuos tablet
ALLOW:vid=056a pid=00fb class=03 # Wacom DTU tablet
DENY: class=03 subclass=01 prot=01 # HID Boot keyboards
# @jeff - allow passthrough of Yubikey 5 FIPS, "Yubikey 4 OTP+U2F+CCID"
ALLOW:vid=1050 pid=0407
DENY: class=03 subclass=01 prot=02 # HID Boot mice
DENY: class=0a # CDC-Data
DENY: class=0b # Smartcard
DENY: class=e0 # Wireless controller
DENY: class=ef subclass=04 # Miscellaneous network devices
ALLOW: # Otherwise allow everything else

Thanks to everyone who took a look. Hopefully you don't get caught by this same gotcha!

@olivierlambert Thank you and your team again for your commitment to this fantastic FOSS tool and for allowing me to build it myself!

I very much appreciate the personal touch of my issues being triaged by the CEO and Co-Founder. It's refreshing to see an executive officer stay in touch with their customer base.

@olivierlambert as pointed out by @psafont on my PR #216,

I believe there is no such technical requirement, when following a redirect the
new request should be done against a different IP/host and the TLS connection renegotiated with that host, meaning none of the hosts' certs should have identifying information from the other one.

I think I need to dive deeper and hope to find an a log message related to the lingering Xapi#getResource /rrd_updates tasks.

@olivierlambert @julien-f

As a final confirmation, since my last message, I generated one certificate for each of my 3 hosts. Each certificate only contained the DNS and IP SANs for that specific host. I then deployed each of the 3 certificates to their respective hosts using xe host-server-certificate-install without issue.

Like I mentioned in my previous post, I am not not getting self signed certificate in certificate chain because I have properly configured xo-server to trust my CA cert.

However, I am now back to getting the endless Xapi#getResource /rrd_updates (on xcp-ng-1) 0% tasks every minute that last for ~24 hours (unless I run xe-toolstack-restart to clear the list.)

I then redeployed my "Pool Certificate" (contains all DNS/IP SANs for all hosts) to each host from the master, executed xe-toolstack-restart and now all is working without issue. I must admit, this is much easier to maintain than trying to maintain 1:1 cert:host.

In conclusion, as you mentioned in your previous reply @olivierlambert, it does appear that a person must sign 1 certificate per pool and that certificate must be configured with Subject Alternate Names for each DNS name and IP used by all hosts in the pool.

Thanks again for working with me on this!

@olivierlambert said in Commands in Xen Orchestra Jobs no longer working:

The best solution is to rely on XOA, you know

I agree with @olivierlambert! Personally, I'm using XO from sources in my home lab environment -- nothing is "production" and I'm mostly having fun trying to give back to the open source community.