ncm-systemd: support xinetd services like chkconfig

[stdweird]

much to my surprise, it seems that ncm-chkconfig supports en/disabling xinetd services like regular services.

there is however no such support in ncm-systemd (and i'd rather keep it that way). possible solutions:

• support it (but clueless how to)
• throw error in schema validation
• throw error/warning in component

there is xinetd support in metaconfig

currently, the component fails to start the so-called service and ends with error.

[stdweird]

@wdpypere thx for discovering this gem 😄

[ned21]

chkconfig --list shows xinetd services so it seems a reasonable piece of functionality to have...

The advantage of having xinetd support in chkconfig means that the "disable all startup services which are not explicitly enabled" policy can be implemented. I doubt ncm-metaconfig could support such a policy for xinetd. Does systemd subsume xinetd or is that still around in RH7?

For the moment I suggest the metaconfig templates throw an "unsupported config" error so people don't incorrectly assume things work.

[jrha]

We discussed this at the 21st workshop, concluding that the xinetd support was accidental.
We will not add support to the systemd component or make any effort to throw a more meaningful error than systemd already does.

[bmcann]

Looking at our CASTOR config, not adding this support is unlikely to be problematic for CASTOR on either SL6 or SL7.

[ned21]

If there's no action to be taken, should this be closed?

[ned21]

Discussion at workshop: still a requirement to disable all unknown services in xinetd. This should no be part of ncm-systemd. Proposal is to make a new component, ncm-xinetd, transfer existing ncm-metaconfig files for managing xinetd to it and then add functionality to iterate over all files on disk and remove them.

[stdweird]

@ned21 @jrha we (well, @kwaegema) found something related
https://access.redhat.com/solutions/6988388 and the recommendation of redhat to convert it in a socket activated service
https://access.redhat.com/solutions/1609583

(fyi, looks like we only have 3 xinetd services, we will generate unit files for them, and not investigate in anything structural to convert xinetd configs)