#936 Clarify non-persistent service permission grant
Closed None Opened 11 years ago by gholms.

The wiki page that lists services which may be enabled by default [1] grants permission to services that do not persist:

In addition, any service which does not remain persistent on the system (aka, it "runs once then goes away") and does not require configuration to be functional may be enabled by default (but is not required to do so). Examples of "runs once then goes away" services include iptables and udev.

Although this statement does not limit itself to programs that do not contact the network like the one that precedes it does, questions about whether or not that statement allows non-persistent services that contact the network to start by default arose on the devel list, so I am in need of clarification.

Do services like cloud-init, which run once and then go away, but which contact the network while they are running, need specific permission from FESCo to start by default?

[1] https://fedoraproject.org/wiki/Starting_services_by_default


Adding meeting keyword for next weeks meeting.

I guess for cloud-init could be used the rule mentioned in guidelines:
"If a service does not require configuration to be functional and is not network enabled, it may be enabled by default (but is not required to do so)."
Especially, if it dies after doing his work.

+1 for cloud-init as enabled service

+1 for changing guidelines to be comprehensible

Replying to [comment:2 mmaslano]:

I guess for cloud-init could be used the rule mentioned in guidelines:
"If a service does not require configuration to be functional and is not network enabled, it may be enabled by default (but is not required to do so)."
Especially, if it dies after doing his work.

If cloud-init falls in that category then perhaps it would be worth clarifying "network enabled" to say that the term only refers to listening on a socket, not contacting services on the network.

I think limiting the services which listen to network connections was the main reason behind the clause so I think rewording the clause this way would clarify it:

In addition, any service which does not remain persistent on the system (aka, it "runs once then goes away"), does not listen to incoming connections during the initialization, and does not require configuration to be functional may be enabled by default (but is not required to do so). Examples of "runs once then goes away" services include iptables and udev.

Replying to [comment:5 tmraz]:

I think limiting the services which listen to network connections was the main reason behind the clause so I think rewording the clause this way would clarify it:

A service that listens to network but doesn't remain persistent is almost, but not completely, an oxymoron.

This is how cloud-init has been described elsewhere:

Cloud-init is in essence very simple: early during the boot process it
visits a well-known URL and downloads a blob of binary data which is
then interpreted as ssh private keys, hostname, arbitrary user commands, &c.
If cloud-init fulfills the other criteria of the discussed rule, in particular "does not require configuration to be functional", this sounds as something really dangerous to run by default, and therefore something that should be forbidden (or at least not explicitly allowed) by the guideline.

The guideline does not require services that fulfil the criteria to start by default. It should be decided by the package maintainer whether the default start-up is appropriate for the concrete service. I agree that if the cloud-init without a configuration downloads some private keys and other things over internet from a built-in URL that it should not be started by default. But then it probably shouldn't do this even when it is enabled explicitly by admin. This does not look to me as safe thing to do in any way.

Agreed that this should be modified.

Replying to [comment:6 mitr]:

This is how cloud-init has been described elsewhere:

Cloud-init is in essence very simple: early during the boot process it
visits a well-known URL and downloads a blob of binary data which is
then interpreted as ssh private keys, hostname, arbitrary user commands, &c.
If cloud-init fulfills the other criteria of the discussed rule, in particular "does not require configuration to be functional", this sounds as something really dangerous to run by default, and therefore something that should be forbidden (or at least not explicitly allowed) by the guideline.

Cloud-init's primary purpose is to retrieve metadata from Amazon EC2's metadata service and use it to configure the system. For example, a user who runs an EC2 instance supplies an SSH key that he or she will use to log into the instance, and cloud-init fetches it from a well-known instance-specific URL, !http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key, and adds that to /home/ec2-user/.ssh/authorized_keys to make it possible for the user to log in. This is what makes it possible for us to publish a cloud image that everyone can use without pre-installing a public key or password.

I agree that running cloud-init on a system outside of a cloud could be risky, but we don't install it on anything other than the EC2 images we ship, where it is critical for proper functionality.

Thoughts?

I don't think that accidentally installing the cloud-init package should do such things so I'm against allowing cloud-init to be enabled by default on install. Is it a real problem? When you create the EC2 images you can easily explicitly enable (with a systemd preset possibly) the cloud-init service.

A spin preset (or whatever they're called) sounds like a reasonable idea. We seem to have procedures and guidelines for distro-wide defaults now (file bugs against systemd); do we have anything for presets that are local to spins (e.g. what numeric precedence they get, what they're called, etc.)? If not, what needs to happen to create them?

Replying to [comment:11 gholms]:

A spin preset (or whatever they're called) sounds like a reasonable idea.
Good :)

We seem to have procedures and guidelines for distro-wide defaults now (file bugs against systemd); do we have anything for presets that are local to spins (e.g. what numeric precedence they get, what they're called, etc.)? If not, what needs to happen to create them?

I don't think this has been established - Lennart, Kay?

Per 2012-09-05 FESCo meeting, I have adjusted the wording on the wiki.

I will open a new ticket for tracking spin presets.

Log in to comment on this ticket.

Metadata