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.
--
Chris Murphy