On 10/05/2016 10:43 AM, Chris Murphy wrote:
On Wed, Oct 5, 2016 at 8:00 AM, Stephen Gallagher
<sgallagh(a)redhat.com> wrote:
> On 10/05/2016 09:37 AM, Michael R. Davis wrote:
>>> An alternative might be disabling sshd out of the box
>>
>> I have never understood why every daemon does not have it's own
"-on" RPM. So,
>> the RPM has all of the logic to do the right thing on how to enable it
correctly.
>>
>> So, to enable sshd the user would install 'openssh-server-on' and be
done. We
>> would not be making a decision for the user. We would be enabling the user to
>> make the decision for themselves.
>>
>
> How is this any better than just logging in to Cockpit and flipping the
"enable"
> switch (or running `systemctl enable foo.service`)? Seems like having extra RPMs
> running around would be more trouble than it was worth.
I agree.
> Also, some RPMs provide more than one service, so now we have to have an extra
> -on RPM for every individual service in the packages? That starts growing the
> RPM metadata unreasonably and slows down updates-processing for everyone,
> particularly those on metered connections.
>
>> Also any service that required sshd to be on and running would simply require
>> openssh-server-on in their RPM.
>>
>
> We already have that functionality built into systemd unit files, which is how
> we do it today. The RPM-based solution would just make everything *harder*,
> because now you'd have two different mechanisms for enablement interacting that
> you'd have to resolve.
Right. 'systemctl enable' just creates symlinks, so why not have a
toggle in the installer that creates or destroys the symlink? You can
decide whether it should default on or off, but still have a user
facing choice that at the very least informs them there's this service
that'll be running.
Right, and we already have this. They're called "presets" and we have
custom
ones for each Fedora Edition.