v3.7 cannot be debianized about sfptpd

[neomantra]

Thanks for all the pointers! I said that wrong, I meant specifically Debian-packaging of sfptpd. I've had great success and support on Debian with all your projects. I'll let reps know, but putting here that I've used Ubuntu LTS Precise and through Jammy with onload and sfptpd.

---

And 10 minutes later: I was thinking "oh, with sfptpd on GitHub now, I should make a Docker image for it"... (like I do Onload)... Then I thought "oh, Onload has started distributing Docker images.... hmmmm, does sfptpd also?" AND... 🎉 sfptpd Docker images published recently! ❤️

Why am I mucking with Aliens when I can be cavorting with Nomads?! Thanks!

---

It's not clear that those images exist from the README or CHANGELOG. Found it deeper here and the image names / formats are not specifically called out. Sample has ghcr.io/xilinx-cns/sfptpd:master-dev . Docker Hub has:

• onload/sfptpd:3.7.1.1002
• onload/sfptpd:3.7.1.1007-20240124.git978aca5
• onload/sfptd:stable

Latest GitHub release is v3.7.1.1007, newer than the current xilinix.com website release of 3.7.0.1006. So I understand that and this is a test cluster, etc. Happy with the direction =)

[abower-amd]

Hi @neomantra,

Thanks for sharing your integration! Good to see the containerized sfptpd works for you - let us know how you get on...

Version 3.7.1.1007 with the RPM change is now published on the website so I am closing this issue - although presumably you won't be needing the RPM any more!

In our examples at https://github.com/Xilinx-CNS/kubernetes-onload/tree/master/config/samples/sfptpd we have opted to put the interface selection in the config file rather than specifying a default interface on the command line so that all the user configurables are in one place.

[abower-amd]

Hi @neomantra, thanks for getting in touch!

Debian is supported just as yet only via the tarball package. I agree it would be nice to provide a native Debian package. It is not recommended to use alien to convert the rpm, however I appreciate this is frustrating if you had been successfully doing this for some time!

The particular issue you have found relates to an rpm quirk: if a file is defined in the spec file with the %ghost %config macros then it is treated as a file owned by the package but not removed on uninstallation. This is used for the runtime-generated system clock persistent clock frequency adjustment state. However, alien does not seem to understand this nuance and complains that the file does not exist.

In order to work around this, future RPM release packages will no longer mention this file; after all, the other runtime-generated persistent clock frequency files for NIC clocks are not even known about at this stage. If you wish to preview this change ahead of the next release please feel free to try unsupported test packages from the v3_7 stable branch.

Also please do mention your interest in a proper Debian package to your sales or support representative (also it would be interesting to know which Debian version you use).

I hope this helps!
Andy

[abower-amd]

Hi @neomantra,

Today is our lucky day as v3.7.1.1007 was 'released' minutes after my last reply to you, although the official packages have not yet reached the website! (Check back later...)

Well spotted with the container images! The container images are indeed new and are supported for anyone wishing to deploy sfptpd with KubernetesOnload. Currently we do not support the container images as a standalone product but would be delighted to receive any feedback!

The only official v3.7.1 release is v3.7.1.1007 - v3.7.1.1002 was a preview of the container support to enable KubernetesOnload to launch with a compatible version of sfptpd.

The way the container image tags work is thus:

tag format	meaning
:latest	build of latest commit to master development branch
:stable	build of latest commit to stable branch
:1.2.3.1004	build of an official released version
:1.2.3.1003-202401255.git1234567	test build of git commit 1234567

Similar tags may exist with -dev suffix generated from an internal repository.

When using sfptpd in a container the following considerations apply:

1. Certain capabilities are required (or you can simply run in a privileged container) as per the example.
2. The /dev/ptp* devices need to be mapped into the container. (Optionally also /dev/pps* which can produce better sync for some nic/driver combinations.)
3. If not using the host network namespace you can run sfptpd on, e.g., a MACVLAN, but due to kernel security restrictions you need to have enabled hardware timestamping on the base NICs from within the host network namespace before doing so.
4. sfptpd cannot interact with chronyd so make sure that chronyd is disabled. Integration with ntpd or ntpsec should work fine so long as sfptpd can communicate with the daemon on port 123.

[abower-amd]

FYI, the changelog entry pertaining to your initial bug report is:

• Issue SWPTP-1395
  • Fix missing sfptpmon script in .tar.gz release package
  • Omit unnecessary new reference to system clock frequency correction state file in .rpm packages to avoid confusing alien repackager tool

[neomantra]

Thanks for laying out exactly what is needed!

As I was just solving a similar problem with Onload days ago, it was pretty easy to add pps and ptp as discoverable and injectable devices to my nomad-onload plugin. Adding device "none/ptp/ptp0"{} mounts /dev/ptp0.

I was able to stand that up an example of a ptp_slave.cfg for Nomad users to add as a system job, which are akin to Kubernetes DaemonSet. Any node that meets the constraint will have it installed.

• main.tf
• sfptpd.nomad.tpl

Quick, naive setup, with hard coding, but it works!

$ nomad job status sfptpd | grep runn
Status        = running
d21c8a77  405deff3  sfptpd      11       run      running   43m53s ago  43m52s ago

$ nomad alloc logs -stderr  d21c8a77  | head -2
2024-01-25 19:43:58.390548: info: Solarflare Enhanced PTP Daemon, version 3.7.1.1007
2024-01-25 19:43:58.390820: debug: default interface set to vlan4

# out of sync at start
$ nomad alloc logs -stdout  d21c8a77  | head -2
2024-01-25 19:43:59.699347 [servo0:phc0->system], offset: -12051.438, freq-adj: 5124.486, in-sync: 0
2024-01-25 19:44:00.699341 [ptp1:gm->phc0(eth0)], offset: 0.000, freq-adj: 0.000, in-sync: 0, one-way-delay: 0.000, parent-id: 0c42:a1ff:fe8f:84da, gm-id: 0c42:a1ff:fe8f:84da

# in sync later
~$ nomad alloc logs -stdout  d21c8a77  | tail -2
2024-01-25 20:28:36.687551 [ptp1:gm->phc0(eth0)], offset: 23.000, freq-adj: 940.514, in-sync: 1, one-way-delay: 933.000, parent-id: 0c42:a1ff:fe8f:84da, gm-id: 0c42:a1ff:fe8f:84da
2024-01-25 20:28:36.687581 [servo0:phc0->system], offset: 24.688, freq-adj: 10291.174, in-sync: 1

# devices in the container
$ docker inspect sfptpd-d21c8a77-35ed-140a-6311-db8719076289 | jq '.[].HostConfig.Devices'
[
  {
    "PathOnHost": "/dev/ptp0",
    "PathInContainer": "/dev/ptp0",
    "CgroupPermissions": "mrw"
  }
]

[abower-amd]

First class Debian packaging now added as of the patch series ending with 648b3b2. This has not been ported to the stable branch, however, and is subject to further enhancement. (Likely will change from the dh_sysuser to dh_installsysusers helper and add Conflicts: systemd-timesyncd and any other improvements that seem appropriate.)

This enhancement is obviously no longer required by @neomantra but anyone's feedback on the debian package design would be appreciated.