Unified configuration of services

[Roger Wilco]

Hi,

this is not a real feature request, it's more like a discussion request about a new feature...

FreeNAS uses/announces quite a lot of services whose configuration is scattered over the whole UI:
* Nameservers are configured under network
* Timeservers are hard coded and not configurable at all
* ssh, sftp, http(s) are announced via bonjour which is not configurable at all
* CIFS announcement is configured under services

From a user's point of view this is IMO not logical - why can I configure the bonjour announcement of samba, and why is ssh always announced w/o an option to change it?
(From the architecture's point of view it's quite simple - Samba has the Zeroconf announcement implemented as a configuration option, while ssh does not. The UI configuration structure is built on the service feature set).

In my "ideal" world there would be a separate menu where I could:
* Configure the announcement of provided services (http(s), ssh, sftp, smb, afp (dunno, can afp exist w/o bonjour?) via a checkbox
* Configure the announcement of services FreeNAS does not offer - e.g. AirPrint for a cups service in a jail (this is not silly, explanation below)

For provided services this could be done on the existing "services" menu via a new checkbox.

For not offered services there would be need for a new mask, where we would need to define a generic set of attributes.

Another aspect would be if I wanted to announce the services not via bonjour (which defaults to the .local domain) but to my "real" domain instead.

It's quite straightforward to do it via a dns service (bind, dnsmasq). This would probably require a different set of attributes (pet-record, src-host, txt-record,...).

So probably this post might be summarised in:
* Should there be an announcement UI-mask for services?
* Should it be possible to configure the announcement type (bonjour, dns-sd)?
* Should it be possible to add (external) services?


Cups/AirPrint info:
* Cups does NOT support AirPrint out of the box, as it does not provide the universal sub, and the URF textfield. This can be easily patched in the sources, but this is suboptimal.
* AirPrint can be configured via dnsmasq (for the real domain, not for .local).

 

[dlavigne]

The entire design is being redesigned for 10... It might be worthwhile putting in a feature request at bugs.freenas.org to see which bits are already in the design and if any bits won't make it into it. If you do, post the issue number here.

 

[cyberjock]

Honestly, some services are dependent on others for simplicity of user access. If you give users too much control they'll hang themselves without even knowing it. So I'd expect some of what you are asking for to be flat out rejected (such as the option to not announce a service). I'm not sure what your level of knowledge is with FreeBSD and the services in question but I'd bet if you submitted code to add the features the devs would probably implement it.

 

[NorwegianRockCat]

Actually, I think this was sort of the same thing that I was asking for (but for jails). I've already made the bug report, though it was maybe a bit more specific:

https://bugs.freenas.org/issues/7753

I do think having some sort of knobs to turn off service advertising would be nice in general. One could make some (like FreeNAS's itself) not killlable from the GUI. But I guess one could configure a firewall to deny all the multicast packets.

Regardless, I'm glad that one doesn't really need to find that IP address and can instead point to freenas.local after the first install.

 

[Roger Wilco]

Honestly, some services are dependent on others for simplicity of user access. If you give users too much control they'll hang themselves without even knowing it. So I'd expect some of what you are asking for to be flat out rejected (such as the option to not announce a service). I'm not sure what your level of knowledge is with FreeBSD and the services in question but I'd bet if you submitted code to add the features the devs would probably implement it.

Hi,

I thought about what I wrote a little bit more, and think the actual coding work wouldn't be too excessive - it's more a question of the architecture.
I would suggest to create a new service entry under "Services" called Zeroconf:
OFF - no advertising at all (default would be ON)
ON - the configured services would be advertised

Service Configuration:
* Sort of a table, where each line represents the configuration of a service to be advertised, with the first column being a checkbox to enable/disable the advertisement of the particular service. On the bottom would be an ADD RECORD and REMOVE RECORD button (and OK/Cancel).
* The currently advertised services would be preconfigured (as currently hardcoded in
/usr/local/libexec/nas/register_mdns.py
without the option to remove or edit these records, only their checkbox would be enabled, so that one could enable or disable them but not modify or delete.
* The ADD RECORD button would create a new empty record, where the user could create their own advertisements (e.g. AirPrint pointing to a CUPS installation in a jail, or to an intranet start page).

The code behind would be quite similar to the existing one in the mentioned Python file - loop over all the configured records and start a new thread for each enabled (via the checkbox) one.

With a little bit glue code it should be quite straight forward to start advertisement only for services which are currently running (this too is already implemented in the mentioned Python file).

Why do you think this proposal would be rejected?

 

[Roger Wilco]

<snip>

Regardless, I'm glad that one doesn't really need to find that IP address and can instead point to freenas.local after the first install.

Well, how often does one do that? :)
Why not plugging in an LCD and configuríng the network through the console menu?

 

[Roger Wilco]

Created a feature request ticket #8017