Jim Klimov
2024-Apr-29 10:39 UTC
[Nut-upsuser] RFE to extend "LISTEN" directive to support host-colon-port (as single token)
Cheers all, A recent discussion in the issue tracker brought up the idea to allow the `LISTEN` keyword to also accept a single "host:port" token (e.g. if there is only one argument, with at least one colon, and the last colon is followed only by numbers, split it into host and port) : https://github.com/networkupstools/nut/issues/2424 I see certain pros to the idea (may be more simple to use and consistent with some other software setup), although I don't think it was an issue ever brought up in discussions before. There are also certain cons, primarily about parsing such stuff reliably and consistently in different code bases (now also with augeas and nutconf to worry about). The actual "production" parsing in NUT data server code should be trivial. On a somewhat related note, should the port part be constrained to numbers, or should it also pass through the naming database (resolve via typically /etc/services on POSIX systems) if it is a non-numeric string, similar to how we resolve host names into IP address numbers? What would the community say, is any of this worth spending time on? Would anyone volunteer to roll up the sleeves for that? :) Jim Klimov -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240429/1e27f34c/attachment.htm>
Greg Troxel
2024-Apr-29 12:31 UTC
[Nut-upsuser] [Nut-upsdev] RFE to extend "LISTEN" directive to support host-colon-port (as single token)
Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> writes:> A recent discussion in the issue tracker brought up the idea to allow the > `LISTEN` keyword to also accept a single "host:port" token (e.g. if there > is only one argument, with at least one colon, and the last colon is > followed only by numbers, split it into host and port) : > https://github.com/networkupstools/nut/issues/2424Is the point that people want to use different ports, and the current situation lets you choose an address but not a port? Assuming so, why would there be a restriction to a single host if there is port, while one could have multiple listen addresses if not? I would think the : scheme should apply to each argument, with lack of : being an implict :[normalport]. For me, the reason to use explicit listen is because you don't like *, and if you are using IP addresses you might well want to listen to v4 and v6. This raises the issue of whether "host" expands to all IP addresses associated with a domain name.> There are also certain cons, primarily about parsing such stuff reliably > and consistently in different code bases (now also with augeas and nutconf > to worry about). The actual "production" parsing in NUT data server code > should be trivial.I find this whole "our config needs to be generally machine readable but we aren't just changing it to a machine-readable format" to be odd. If we want to play in some world where that happens we should just flip to yaml or something :-)> On a somewhat related note, should the port part be constrained to > numbers, or should it also pass through the naming database (resolve via > typically /etc/services on POSIX systems) if it is a non-numeric string, > similar to how we resolve host names into IP address numbers?sure, non-numeric port could go through getservbyname(3) and then fail if not the expected protocol. Don't talk about /etc/services but the posix interface, except it's from 4.2BSD and I'm not sure it's been specified by POSIX :-) On the other hand, if you are using an alternate port, it's because you are not doing the normal thing, and the idea that you specify 'ntp' because you want nut on 123 doesn't really make sense. And if you know some name it's not hard to look it up by name. So all in all, I vote for no, it's a number.> What would the community say, is any of this worth spending time on? > Would anyone volunteer to roll up the sleeves for that? :)No and no, IMHO. What is the problem being solved? Are there actual people who want to use a different port? What are their reasons? I can believe there might be a scenario, but it seems speculative.
Apparently Analagous Threads
- RFE to extend "LISTEN" directive to support host-colon-port (as single token)
- RFE to extend "LISTEN" directive to support host-colon-port (as single token)
- RFE to extend "LISTEN" directive to support host-colon-port (as single token)
- RFE to extend "LISTEN" directive to support host-colon-port (as single token)
- RFE to extend "LISTEN" directive to support host-colon-port (as single token)