Bug 239819

Summary: [PATCH] net-mgmt/metronome: add rc script
Product: Ports & Packages Reporter: Leo Vandewoestijne <freebsd>
Component: Individual Port(s)Assignee: Kirill Ponomarev <krion>
Status: New ---    
Severity: Affects Only Me CC: freebsd
Priority: --- Flags: bugzilla: maintainer-feedback? (krion)
Version: Latest   
Hardware: Any   
OS: Any   
Description Flags
metronome add rc script
metronome rc script none

Description Leo Vandewoestijne 2019-08-13 15:33:24 UTC
Created attachment 206487 [details]
metronome add rc script

Dear maintainer,

By these a patch that adds a rc script to the metronome port.
I've tested it, insofar; I currently run this myself now / and it does what I want.
I think it allows for improvement; for example running the daemon as root might be undesired.

Could you please review what I've done?

Comment 1 Leo Vandewoestijne 2019-08-13 15:39:22 UTC
Oh, I just notice too late I copy/pasted 10 lines too much at the top of the patch.
Comment 2 Leo Vandewoestijne 2019-10-28 09:02:20 UTC
Created attachment 208649 [details]
metronome rc script

Same but without the part that was copy/pasted too much.

Can you please apply this, such that my daemons will start?
Comment 3 Kirill Ponomarev freebsd_committer 2019-10-28 10:20:09 UTC
Why are you using IPv6 only?
Comment 4 Leo Vandewoestijne 2019-10-28 14:30:57 UTC
Because the manual says that "::" is the default
Comment 5 Kirill Ponomarev freebsd_committer 2019-10-28 18:48:47 UTC
Leo, could you please elaborate? I don't think we can merely rely on IPv6 in this case.
Comment 6 Leo Vandewoestijne 2019-10-29 12:44:35 UTC
I've double checked, if I don't use those two rc.conf switches, meaning do use the default, thus [::]:2003 and [::]:8000, then it's listening on all IP's, including IPv4.
So with this option you can limit it to a single IP, which I think is more desired.
Comment 7 Leo Vandewoestijne 2019-10-29 12:52:27 UTC
when testing I used a wrong command from history, and mistake that the daemon restarted. So above conclusion is wrong.

I did it over again AND used nmap to see the result.
In deed it's v6 only.
But anyway, I think it better had a value (the default of the vendor) than have no value.
It also could be "", but I don't see much benefit in using that.
Comment 8 Kirill Ponomarev freebsd_committer 2019-10-29 14:58:48 UTC
Leo, I would definitely I accept this rc script if it would work on non-IPv6 systems as well. There are a lot of installations with disabled IPv6 interfaces so this rc won't run on them. Is it possible to change it, could you ping upstream to get to know it?
Comment 9 Leo Vandewoestijne 2019-10-29 15:29:26 UTC
upstream has likely other priorities.
But was the suggested no option as placeholder?
Comment 10 Kirill Ponomarev freebsd_committer 2019-10-29 17:46:10 UTC would work by accessing it from localhost, but what about IPv4 and accessing it from the network?
Comment 11 Leo Vandewoestijne 2019-12-09 11:05:59 UTC
In that case user can define, which in such case (IPv4-only) will be a nessesity anyway.
Comment 12 Leo Vandewoestijne 2020-07-30 13:44:21 UTC
This is open since a while. Let's make resume of evens:

[suggestion]: RC script, having exact the same defaults equal to what the vendor's already had.

[response]: It's IPv6 / would accept if it's IPv4

[problem]: which IPv4 address should -or could...- be default?

[suggestion to the "problem"]:

[question]: but what about IPv4 and accessing it from the network?

Well, if you wish to have it act different, than you have to configure it to act different. This simply would be the case anyway if you wanted it to start.
And that's where the rc.conf switches are meant for; if they would not be there, then it would take the default, which didn't work anyway (in case of your scenario).
So I think a real solution to a hypothetical problem is already included.

However if you insist on listening on a specific IPv4 address, then which one you deem more appropriate as default than
IMHO I/you/we cannot brutally detect something random and select that, it's up to the administrator, I think.

If you don't have a better solution or workaround, then I think having no rc script at all is a bit cruel to users capable of defining a listening address and the desire start the daemon.