Re: starting services in fedora

[John Florian]

On 2018-04-17 16:31, Zbigniew Jędrzejewski-Szmek wrote:

My initial example with gpm
is actually good here: do "sudo dnf install -y gpm", move mouse, voilà.


 unless your a lefty ;-)

OT: Why is why I wish sddm was handedness-agnostic.  It's too simple to 
need anything more than click awareness, the type of click shouldn't 
ever matter.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[Zbigniew Jędrzejewski-Szmek]

On Tue, Apr 17, 2018 at 04:47:14PM -0400, R P Herrold wrote:
> On Tue, 17 Apr 2018, Zbigniew Jędrzejewski-Szmek wrote:
> 
> > The use case is that for simple packages, it's simpler for the user
> > if the service is available immediately. My initial example with gpm
> > is actually good here: do "sudo dnf install -y gpm", move mouse, voilà.
> 
> > Also the case from https://bugzilla.redhat.com/show_bug.cgi?id=1545027:
> > a user installs some daemon for smartcards, and expects it to be
> > functional without rebooting.
> 
> pcsc-lite is an example with a poor history set of interaction 
> with the systemd and itself in a 'no card present' state
> 
> I've been bitten by that Heisenbug before [1], and was 
> basically told to put black tape over the warning light on the 
> dashboard
> 
> -- Russ herrold
> 
> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1046685

That issue is orthogonal to the issue at hand.
If it logs a spurious warning at every boot if installed, one
extra warning after installation doesn't really matter.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[Stephen John Smoogen]

On 17 April 2018 at 19:42, Nico Kadel-Garcia  wrote:
> On Tue, Apr 17, 2018 at 2:53 PM, Zbigniew Jędrzejewski-Szmek
>  wrote:
>> On Tue, Apr 17, 2018 at 11:00:55AM -0500, Ian Pilcher wrote:
>>> On 04/17/2018 12:41 AM, Zbigniew Jędrzejewski-Szmek wrote:
>>> >tl;dr: the proposal is to start services immediately during
>>> >installation (in %post), iff they are enabled in presets and the
>>> >system is live (not a chroot or such).
>>> >
>>> >This would mean that e.g. after 'dnf install gpm' gpm would be running
>>> >when dnf exits.
>>>
>>> What if gpm is pulled in as a dependency?
>>>
>>> (gpm may not be the best example here, but Avahi definitely is pulled in
>>> as a dependency sometimes.)
>>
>> Doesn't matter. Essentially, the thinking is that if it is safe and
>> useful to start something after a reboot, it should be OK to start it
>> immediately after installation too.
>
> It's very application and local configuration specific. The "nginx"
> software, for example, may expect some very real configuration
> dependencies before startup to avoid conflicting with an active
> webserver on the same port. When configuration tools like chef or
> ansible install new configurations, the default configuration may not
> even be compatible with what they have previously set up, and the
> service restart would thus fail.until the rest of the deployment is
> completed. But if the rpm installation reports failure because of the
> failed service start, the configuration software may never be able to
> get past that reported failure.

It seems to me that we are hitting the classic workstation/server
divide here. The workstation user wants gpm and other things to start
up when they install it. They expect it to work out of the box and not
need additional configuration. The server person expects that there is
going to be a LOT of special cases that need configuration or multiple
big use cases which conflict. That means having services started could
be worse than not having them wait until a reboot.

Can we start looking at this from that sake versus trying to come up
with a single solution that meets one sides problems but not the
others. It may be that the workstation needs a "yolo" flag which
enables and starts any service which meets certain needs because that
is what that audience is expecting even if that service would not want
to be started in a server environment. [To use the gpm example, if gpm
is installed and started on certain servers that would be a security
finding which could cause fines to the user... while in a workstation
it would be the opposite :)]

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[Nico Kadel-Garcia]

On Tue, Apr 17, 2018 at 2:53 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Tue, Apr 17, 2018 at 11:00:55AM -0500, Ian Pilcher wrote:
>> On 04/17/2018 12:41 AM, Zbigniew Jędrzejewski-Szmek wrote:
>> >tl;dr: the proposal is to start services immediately during
>> >installation (in %post), iff they are enabled in presets and the
>> >system is live (not a chroot or such).
>> >
>> >This would mean that e.g. after 'dnf install gpm' gpm would be running
>> >when dnf exits.
>>
>> What if gpm is pulled in as a dependency?
>>
>> (gpm may not be the best example here, but Avahi definitely is pulled in
>> as a dependency sometimes.)
>
> Doesn't matter. Essentially, the thinking is that if it is safe and
> useful to start something after a reboot, it should be OK to start it
> immediately after installation too.

It's very application and local configuration specific. The "nginx"
software, for example, may expect some very real configuration
dependencies before startup to avoid conflicting with an active
webserver on the same port. When configuration tools like chef or
ansible install new configurations, the default configuration may not
even be compatible with what they have previously set up, and the
service restart would thus fail.until the rest of the deployment is
completed. But if the rpm installation reports failure because of the
failed service start, the configuration software may never be able to
get past that reported failure.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[Samuel Sieb]

On 04/17/2018 01:12 PM, R P Herrold wrote:

On Tue, 17 Apr 2018, Samuel Sieb wrote:

I would assume that services that require configuration
before being useful would not be enabled by default.


I thing this is a mistaken assumption, and that we are moving
into matters of sysadmin taste

The SSHD is enabled by default, and likely to remain so

We pre-inject a management key for root in a %post stanza of
an install, but we still need to go in and add restrictions to
keyed access only, down in
/etc/sshd/
and IP range lockdowns

The Rsyslogd is enabled by default, but has essentally useless
default settings -- no Mark service, no UDP listener, local
host loggin only


Both of those are also examples of packages that you are unlikely to be 
installing separately.  Those both get installed by default on the 
initial installation so wouldn't be affected by what is being discussed 
in this thread.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[R P Herrold]

On Tue, 17 Apr 2018, Zbigniew Jędrzejewski-Szmek wrote:

> The use case is that for simple packages, it's simpler for the user
> if the service is available immediately. My initial example with gpm
> is actually good here: do "sudo dnf install -y gpm", move mouse, voilà.

> Also the case from https://bugzilla.redhat.com/show_bug.cgi?id=1545027:
> a user installs some daemon for smartcards, and expects it to be
> functional without rebooting.

pcsc-lite is an example with a poor history set of interaction 
with the systemd and itself in a 'no card present' state

I've been bitten by that Heisenbug before [1], and was 
basically told to put black tape over the warning light on the 
dashboard

-- Russ herrold

1. https://bugzilla.redhat.com/show_bug.cgi?id=1046685
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[R P Herrold]

On Tue, 17 Apr 2018, Zbigniew Jędrzejewski-Szmek wrote:

> > i could puke everytime something is pulled as dependency and started
> > without any use
> 
> Can you give an example of such services?

The first is a list of 'sbin' processes running from that 
machine being probed

The second are those not sought to be installed by our design, 
nor to be enabled.  remote iscsi support is not anywhere close 
to the use case for this class of machine, but was included

-- Russ herrold

[root@pl085086017 ~]# ps afx | grep sbin
  257 ?S

Re: starting services in fedora

[Zbigniew Jędrzejewski-Szmek]

On Tue, Apr 17, 2018 at 04:01:04PM -0400, R P Herrold wrote:
> On Tue, 17 Apr 2018, Zbigniew Jędrzejewski-Szmek wrote:
> 
> > On Tue, Apr 17, 2018 at 12:41:15PM -0400, R P Herrold wrote:
>  
> > To make this work, we could either require that maintainers of A add
> > Requires(post): B, or delay the starting of services until the end
> > of the transaction, using a transfiletrigger. This second approach
> > is much more attractive. Actually we already od a delayed 
> > 'systemctl daemon-reload' after the transaction, and we could start
> > the services after that.
> 
> Thank you ... but:
> 
> you trimmed off and did not respond to the harder part of my 
> real-world example

Yep, I did.

> herrold earlier:
> > I know I need to go in and manually create and add files 
> > like:
> >/etc/systemd/system/var-ftp-pub-nfs-mirror2.mount
> >
> > and then link in that file in:
> > /etc/systemd/system/machines.target.wants/
> > 
> > to get NFS working as I want -- I cannot imagine that** any 
> > ** install tool knows how to read my desires as a deploying 
> > owner
> 
> which in this case is a RO NFS mount of a third party SAN 
> device, and which contains site specific matter needed for an 
> install needs to access to be useful
> 
> 
> There are companion files, such as one with a RW:
> /etc/systemd/system/home-nfs.mount
> and more, and the RW case is much 'harder' to solve 
> (rootsquash, NFSv4, restricted IP ranges, more).  This is for 
> a workstation class unit

Yes, I don't think we could deal with arbitrary complexity here.
But all that stuff is not something that would be subject
to being enabled by default anyway. And...

... the guidelines say that
"if a service does not require manual configuration to be functional
and does not listen on a network socket for connections originating on
a separate physical or virtual machine [...] may be enabled by
default" or "Some services which are permitted to be enabled by
default as specific exceptions."

So the default presets are mostly for services which are understood to
be "safe" (for some definition of safe, it's always a judgement call,
e.g. sshd is enabled by default).

Another thing to consider is that after a service has been
enabled, it is in principle always possible for the service to be
started:
- first, a machine might be restarted because of a power failure,
  kernel panic, or a user tripping over a cable, in which case the
  service will be started on reboot
- second, a transaction might be started which pulls in the target
  which pulls in the service in question, and the service might
  be started as a side effect.

So if a service is enabled by default and needs tuning before being
started, this tuning better happen *before* the service is enabled,
i.e. before the package is installed, if it will be enabled in %post.
 
> How is chasing down a rabbit hole of unknowable configuration 
> possibilities, to start things during deployment, and before 
> hardening even vaguely 'solveable' even with unlimited ** 
> packager ** effort?  Augeas sort of tried to do this, and got 
> mired in complexity quicksand.  Trying to enable install time 
> startups is in no way a 'costless' decision and adding new and 
> ill-defined 'requirements' for unclear reasons will tend to 
> reduce packager willingness to participate
> 
> 
> As I pointed out, install order matters, and in testing alone, 
> the big O() complexity testing matrix explodes at a O(N^M) 
> rate.  That is, it is simply untestable in very short order
> 
> And just WHY do we want to start services during deployment, 
> and before hardening?  Why would we WANT to enable services 
> _before_ application of potential security updates recognized 
> and released after a media freeze?

I see two scenarios:
- one, you install from an image, w/o pulling updates from the
  network, restart the machine, and pull in updates.
- two, you install w/ network access, pulling updates for any
  packages for the initial installation.

In the second case, updated packages are installed, and in the first
case, a reboot happens before the update, so any enabled services will
be started. In both scenarios starting them immediately after
installation doesn't change things.

> I do not understand the use case at all

The use case is that for simple packages, it's simpler for the user
if the service is available immediately. My initial example with gpm
is actually good here: do "sudo dnf install -y gpm", move mouse, voilà.
Also the case from https://bugzilla.redhat.com/show_bug.cgi?id=1545027:
a user installs some daemon for smartcards, and expects it to be
functional without rebooting.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[R P Herrold]

On Tue, 17 Apr 2018, Zbigniew Jędrzejewski-Szmek wrote:

> Services which are subject the guidelines allow to be 
> enabled by default should be such that starting them briefly 
> should not cause any permanent effects.


'should not' is not true to fact in the real world

I mentioned we inject a SSH root key for management purposes.  
This is a sample of the 'back-splatter' I get all the time

Starting the ssh service generates several keys, which then 
get 'picked up' off host by our control units.  I have to have 
specil code to address the need to go in and eradicate such 
all the time.  Sample below


Apr 16 19:22:19 secure PMMan[2423]: PMMan (VM Management) 
[system@localhost:vm_34458] -- VM setup sees a listener on port 22/tcp 

Apr 16 19:22:19 secure vm_setup[1331]: ssh: connect to host 
10.85.86.17 port 22: Connection refused

Apr 16 19:22:19 secure last message repeated 3 times

Apr 16 19:22:19 secure vm_setup[1368]: 
@@@

Apr 16 19:22:19 secure vm_setup[1368]: @WARNING: REMOTE 
HOST IDENTIFICATION HAS CHANGED! @

Apr 16 19:22:19 secure vm_setup[1368]: 
@@@

Apr 16 19:22:19 secure vm_setup[1368]: IT IS POSSIBLE THAT 
SOMEONE IS DOING SOMETHING NASTY!

Apr 16 19:22:19 secure vm_setup[1368]: Someone could be 
eavesdropping on you right now (man-in-the-middle attack)!

Apr 16 19:22:19 secure vm_setup[1368]: It is also possible 
that the RSA host key has just been changed.

Apr 16 19:22:19 secure vm_setup[1368]: The fingerprint for the 
RSA key sent by the remote host is

Apr 16 19:22:19 secure vm_setup[1368]: 
28:1c:dc:5e:26:9d:4b:1f:2c:a8:aa:8d:42:4f:5f:ea.

Apr 16 19:22:19 secure vm_setup[1368]: Please contact your 
system administrator.

Apr 16 19:22:19 secure vm_setup[1368]: Add correct host key in 
/root/.ssh/known_hosts to get rid of this message.

Apr 16 19:22:19 secure vm_setup[1368]: Offending key in 
/root/.ssh/known_hosts:325

Apr 16 19:22:19 secure vm_setup[1368]: Password authentication 
is disabled to avoid man-in-the-middle attacks.

Apr 16 19:22:19 secure vm_setup[1368]: Keyboard-interactive 
authentication is disabled to avoid man-in-the-middle attacks.

Apr 16 19:22:19 secure vm_setup[1368]: reverse mapping 
checking getaddrinfo for pl085086228.domain.lan failed - 
POSSIBLE BREAK-IN ATTEMPT!

Apr 16 19:22:20 secure pmmanLog[2432]: pmmanLog ( | _event_id: 
5 | _owner_id: 0 | _vm_id: 846 | _message: VM setup is 
shutting down for initial clean backup | _admin: NULL | 
_thread_id: NULL | _level: I | _viewable: 0 

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[R P Herrold]

On Tue, 17 Apr 2018, Samuel Sieb wrote:

> I would assume that services that require configuration 
> before being useful would not be enabled by default.

I thing this is a mistaken assumption, and that we are moving 
into matters of sysadmin taste

The SSHD is enabled by default, and likely to remain so

We pre-inject a management key for root in a %post stanza of 
an install, but we still need to go in and add restrictions to 
keyed access only, down in
/etc/sshd/ 
and IP range lockdowns

The Rsyslogd is enabled by default, but has essentally useless 
default settings -- no Mark service, no UDP listener, local 
host loggin only

-- Russ herrold
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[Zbigniew Jędrzejewski-Szmek]

On Tue, Apr 17, 2018 at 08:58:06PM +0200, Reindl Harald wrote:
> 
> 
> Am 17.04.2018 um 20:53 schrieb Zbigniew Jędrzejewski-Szmek:
> > On Tue, Apr 17, 2018 at 11:00:55AM -0500, Ian Pilcher wrote:
> >> On 04/17/2018 12:41 AM, Zbigniew Jędrzejewski-Szmek wrote:
> >>> tl;dr: the proposal is to start services immediately during
> >>> installation (in %post), iff they are enabled in presets and the
> >>> system is live (not a chroot or such).
> >>>
> >>> This would mean that e.g. after 'dnf install gpm' gpm would be running
> >>> when dnf exits.
> >>
> >> What if gpm is pulled in as a dependency?
> >>
> >> (gpm may not be the best example here, but Avahi definitely is pulled in
> >> as a dependency sometimes.)
> > 
> > Doesn't matter. Essentially, the thinking is that if it is safe and
> > useful to start something after a reboot, it should be OK to start it
> > immediately after installation too
> 
> who tells you that i would reboot without disable said as dependency
> pulled service before??
> 
> i could puke everytime something is pulled as dependency and started
> without any use

Can you give an example of such services?

I see you would be impacted negatively by the proposed change, but
you could either:
- add a preset to override the enablement of such services,
- or just do 'systemctl disable --now foo' instead of 'systemctl disable foo'.
Services which are subject the guidelines allow to be enabled by
default should be such that starting them briefly should not cause
any permanent effects.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[R P Herrold]

On Tue, 17 Apr 2018, Zbigniew Jędrzejewski-Szmek wrote:

> On Tue, Apr 17, 2018 at 12:41:15PM -0400, R P Herrold wrote:
 
> To make this work, we could either require that maintainers of A add
> Requires(post): B, or delay the starting of services until the end
> of the transaction, using a transfiletrigger. This second approach
> is much more attractive. Actually we already od a delayed 
> 'systemctl daemon-reload' after the transaction, and we could start
> the services after that.

Thank you ... but:

you trimmed off and did not respond to the harder part of my 
real-world example

herrold earlier:

> I know I need to go in and manually create and add files 
> like:
>/etc/systemd/system/var-ftp-pub-nfs-mirror2.mount
>
> and then link in that file in:
> /etc/systemd/system/machines.target.wants/
> 
> to get NFS working as I want -- I cannot imagine that** any 
> ** install tool knows how to read my desires as a deploying 
> owner

which in this case is a RO NFS mount of a third party SAN 
device, and which contains site specific matter needed for an 
install needs to access to be useful


There are companion files, such as one with a RW:
/etc/systemd/system/home-nfs.mount
and more, and the RW case is much 'harder' to solve 
(rootsquash, NFSv4, restricted IP ranges, more).  This is for 
a workstation class unit


How is chasing down a rabbit hole of unknowable configuration 
possibilities, to start things during deployment, and before 
hardening even vaguely 'solveable' even with unlimited ** 
packager ** effort?  Augeas sort of tried to do this, and got 
mired in complexity quicksand.  Trying to enable install time 
startups is in no way a 'costless' decision and adding new and 
ill-defined 'requirements' for unclear reasons will tend to 
reduce packager willingness to participate


As I pointed out, install order matters, and in testing alone, 
the big O() complexity testing matrix explodes at a O(N^M) 
rate.  That is, it is simply untestable in very short order

And just WHY do we want to start services during deployment, 
and before hardening?  Why would we WANT to enable services 
_before_ application of potential security updates recognized 
and released after a media freeze?  Setting up the firewalld, 
particularly with the demise and eradication of host name 
based resolution wrappers, is not an install time task at all, 
other than
'deny all but ssh'

I do not understand the use case at all

-- Russ herrold
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[Samuel Sieb]

On 04/17/2018 12:05 PM, Kevin Fenzi wrote:

b) services that have assumed our current behavior and are not useful,
or are even insecure when started by default.


I would assume that services that require configuration before being 
useful would not be enabled by default.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[Kevin Fenzi]

On 04/16/2018 10:41 PM, Zbigniew Jędrzejewski-Szmek wrote:
> Hi all,
> 
> I'm a bit surprised that there's no reply to this fairly explosive
> idea. Maybe Nikos' text is too long, so let me summarize:

Well, I marked it to reply to, but just hadn't gotten to it yet. ;)
Not everyone can immediately answer list posts. :)

So, as it is mentioned downthread the problems I see with this is:

a) making sure we reliably detect if we are in a live system or not
and
b) services that have assumed our current behavior and are not useful,
or are even insecure when started by default.

I think a is solveable if it already hasn't been...


For b, we will want to have a long ramp (so perhaps make this a 29 or
even a f30 change) and just fix up these things that have problems
starting / being usable / being secure when started right after install.

I can see this being helpfull in some cases for sure.

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[Zbigniew Jędrzejewski-Szmek]

On Tue, Apr 17, 2018 at 12:41:15PM -0400, R P Herrold wrote:
> On Tue, 17 Apr 2018, Zbigniew Jędrzejewski-Szmek wrote:
> 
> > > That said, maybe Fedora's service preset files these days are
> > > carefully enough written and already formalize such deliberation?
> > 
> > Pfff. Yes they are. See 
> > https://fedoraproject.org/wiki/Packaging:DefaultServices.
> 
> Is packager install sequencing aware of all of the 
> various systemd dependency resolution qualifications?  
>   Wants
>   After
>   Conflicts
>   WantedBy
>   (there are a passel more)
That's something that I haven't considered… Indeed, it is possible to
imagine a scenario where package A has Requires: B, and B could be
installed later in the transaction, hence it's not possible to start
A.service in A's %post.

To make this work, we could either require that maintainers of A add
Requires(post): B, or delay the starting of services until the end
of the transaction, using a transfiletrigger. This second approach
is much more attractive. Actually we already od a delayed 
'systemctl daemon-reload' after the transaction, and we could start
the services after that.

Thanks for pointing this out!

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[Zbigniew Jędrzejewski-Szmek]

On Tue, Apr 17, 2018 at 11:00:55AM -0500, Ian Pilcher wrote:
> On 04/17/2018 12:41 AM, Zbigniew Jędrzejewski-Szmek wrote:
> >tl;dr: the proposal is to start services immediately during
> >installation (in %post), iff they are enabled in presets and the
> >system is live (not a chroot or such).
> >
> >This would mean that e.g. after 'dnf install gpm' gpm would be running
> >when dnf exits.
> 
> What if gpm is pulled in as a dependency?
> 
> (gpm may not be the best example here, but Avahi definitely is pulled in
> as a dependency sometimes.)

Doesn't matter. Essentially, the thinking is that if it is safe and
useful to start something after a reboot, it should be OK to start it
immediately after installation too.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[R P Herrold]

On Tue, 17 Apr 2018, Zbigniew Jędrzejewski-Szmek wrote:

> > That said, maybe Fedora's service preset files these days are
> > carefully enough written and already formalize such deliberation?
> 
> Pfff. Yes they are. See 
> https://fedoraproject.org/wiki/Packaging:DefaultServices.

Is packager install sequencing aware of all of the 
various systemd dependency resolution qualifications?  
Wants
After
Conflicts
WantedBy
(there are a passel more)

I know I need to go in and manually create and add files like:
/etc/systemd/system/var-ftp-pub-nfs-mirror2.mount

and then link in that file in:
/etc/systemd/system/machines.target.wants/

to get NFS working as I want -- I cannot imagine that** any ** 
install tool knows how to read my desires as a deploying owner

-- Russ herrold
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[Ian Pilcher]

On 04/17/2018 12:41 AM, Zbigniew Jędrzejewski-Szmek wrote:

tl;dr: the proposal is to start services immediately during
installation (in %post), iff they are enabled in presets and the
system is live (not a chroot or such).

This would mean that e.g. after 'dnf install gpm' gpm would be running
when dnf exits.


What if gpm is pulled in as a dependency?

(gpm may not be the best example here, but Avahi definitely is pulled in
as a dependency sometimes.)

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[Miroslav Suchý]

Dne 17.4.2018 v 09:23 Zbigniew Jędrzejewski-Szmek napsal(a):
> Actually we do. If systemd is running and dnf is installing packages
> into the same root from which it is running, it's a live system.

Hmm, this will work for Mock. Thou I am not sure about others environments.

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[Michal Sekletar]

On Tue, Apr 17, 2018 at 10:52 AM, Petr Pisar  wrote:

> You mean systemctl can talk to a systemd via
> /var/run/dbus/system_bus_socket. Ok.

IIRC, systemctl detects that it is running in chrooted environment
(i.e. system isn't "live") by looking at inode number of /. If the
number that systemctl sees (/proc//root) and one that
PID 1 see are different than systemctl assumes it is chrooted and
refuses to serve service start requests.

Michal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[Zbigniew Jędrzejewski-Szmek]

On Tue, Apr 17, 2018 at 09:44:45AM +0200, Lennart Poettering wrote:
> On Di, 17.04.18 05:41, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> 
> > Hi all,
> > 
> > I'm a bit surprised that there's no reply to this fairly explosive
> > idea. Maybe Nikos' text is too long, so let me summarize:
> > 
> > tl;dr: the proposal is to start services immediately during
> > installation (in %post), iff they are enabled in presets and the
> > system is live (not a chroot or such).
> > 
> > This would mean that e.g. after 'dnf install gpm' gpm would be running
> > when dnf exits.
> 
> Hmm. While many services make a ton of sense to just be started on
> install, for others this doesn't really apply... i.e. starting the
> smartcard stuff or gpm right-away makes sense, since they work
> out-of-the-box in a sensible, comprehensive way. This is very
> different for server stuff like httpd however, which is only vaguely
> useful unless configured by the admin to serve the data it's supposed
> to serve... Hence I am pretty sure there needs to some per-case
> deliberation in place.
> 
> That said, maybe Fedora's service preset files these days are
> carefully enough written and already formalize such deliberation?

Pfff. Yes they are. See 
https://fedoraproject.org/wiki/Packaging:DefaultServices.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[Petr Pisar]

On 2018-04-17, Zbigniew Jędrzejewski-Szmek  wrote:
> On Tue, Apr 17, 2018 at 08:30:59AM +0200, Miroslav Suchý wrote:
>> Dne 17.4.2018 v 07:46 Petr Pisar napsal(a):
>> > Maybe nobody knows how to determine a system is live.
>> 
>> +1
>
> Actually we do. If systemd is running

You mean systemctl can talk to a systemd via
/var/run/dbus/system_bus_socket. Ok.

> and dnf is installing packages into the same root from which it is
> running, it's a live system.  Otherwise, it's not. This is what
> systemctl checks.
>
Does systemctl really check it is an indirect child of dnf and where
that dnf installs to? You cannot get meaningful chroot path by calls
from a chrooted process. Also you can execute "rpm --root /foo -i
foo.rpm" without DNF. I cannot see how this second condition is
meaningfully implemented.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[Lennart Poettering]

On Di, 17.04.18 05:41, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> Hi all,
> 
> I'm a bit surprised that there's no reply to this fairly explosive
> idea. Maybe Nikos' text is too long, so let me summarize:
> 
> tl;dr: the proposal is to start services immediately during
> installation (in %post), iff they are enabled in presets and the
> system is live (not a chroot or such).
> 
> This would mean that e.g. after 'dnf install gpm' gpm would be running
> when dnf exits.

Hmm. While many services make a ton of sense to just be started on
install, for others this doesn't really apply... i.e. starting the
smartcard stuff or gpm right-away makes sense, since they work
out-of-the-box in a sensible, comprehensive way. This is very
different for server stuff like httpd however, which is only vaguely
useful unless configured by the admin to serve the data it's supposed
to serve... Hence I am pretty sure there needs to some per-case
deliberation in place.

That said, maybe Fedora's service preset files these days are
carefully enough written and already formalize such deliberation?

Lennart
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[Zbigniew Jędrzejewski-Szmek]

On Tue, Apr 17, 2018 at 09:23:24AM +0200, Jakub Jelen wrote:
> On Tue, 2018-04-17 at 05:46 +, Petr Pisar wrote:
> > On 2018-04-17, Zbigniew Jędrzejewski-Szmek  wrote:
> > > I'm a bit surprised that there's no reply to this fairly explosive
> > > idea. Maybe Nikos' text is too long, so let me summarize:
> > > 
> > > tl;dr: the proposal is to start services immediately during
> > > installation (in %post), iff they are enabled in presets and the
> > > system is live (not a chroot or such).
> > > 
> > 
> > Maybe nobody knows how to determine a system is live.
> 
> This determination is on systemd and if anyone should know that, it
> should be a init, isn't it?
> 
> From the comment #30 in bug #1545027, there is a reference to snapd
> spec file, that is already doing this (using systemd).
> 
> I would not say this is a problem today, we would not be able to tell
> if we can or can not start a service. systemd is powerful and can
> simplify these things for us.
> 
> The problem is that it does not matter for most of the technical people
> to run one more command "systemctl start foo" after "dnf install". But
> it really does for non-technical ones. They usually have to reboot to
> make things work (hello M$). This is also the reason why the snapd has
> this post script -- it is much more (likely) to be used by non-
> technical people than the smart cards daemon and less likely to be
> installed out of the box.

Yep, usability and all that. One step less is always good.

> If we want to make it simpler to use for *any* user, we should go this
> way and allow starting enabled services after installation, either by
> explicit post scriptlet or automatically inside of existing systemd
> scriptlets.

My idea was to actually make this opt-out: if a service is enabled in
presets, make the default scriptlet start it too, and then provide a
new scriptlet that would give *current* behaviour and to opt-out of
autostarting.

Starting immediately should be OK for those services which satisfy the
criteria for being enabled by default, and making this automatic and
uniform would simplify things for users.

> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1545027#30

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[Jakub Jelen]

On Tue, 2018-04-17 at 05:46 +, Petr Pisar wrote:
> On 2018-04-17, Zbigniew Jędrzejewski-Szmek  wrote:
> > I'm a bit surprised that there's no reply to this fairly explosive
> > idea. Maybe Nikos' text is too long, so let me summarize:
> > 
> > tl;dr: the proposal is to start services immediately during
> > installation (in %post), iff they are enabled in presets and the
> > system is live (not a chroot or such).
> > 
> 
> Maybe nobody knows how to determine a system is live.

This determination is on systemd and if anyone should know that, it
should be a init, isn't it?

From the comment #30 in bug #1545027, there is a reference to snapd
spec file, that is already doing this (using systemd).

I would not say this is a problem today, we would not be able to tell
if we can or can not start a service. systemd is powerful and can
simplify these things for us.

The problem is that it does not matter for most of the technical people
to run one more command "systemctl start foo" after "dnf install". But
it really does for non-technical ones. They usually have to reboot to
make things work (hello M$). This is also the reason why the snapd has
this post script -- it is much more (likely) to be used by non-
technical people than the smart cards daemon and less likely to be
installed out of the box.

If we want to make it simpler to use for *any* user, we should go this
way and allow starting enabled services after installation, either by
explicit post scriptlet or automatically inside of existing systemd
scriptlets.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1545027#30
 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[Zbigniew Jędrzejewski-Szmek]

On Tue, Apr 17, 2018 at 08:30:59AM +0200, Miroslav Suchý wrote:
> Dne 17.4.2018 v 07:46 Petr Pisar napsal(a):
> > Maybe nobody knows how to determine a system is live.
> 
> +1

Actually we do. If systemd is running and dnf is installing packages
into the same root from which it is running, it's a live system.
Otherwise, it's not. This is what systemctl checks.

Are you aware of any circumstances where the existing checks done
before 'systemctl start' are not enough?

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[Miroslav Suchý]

Dne 17.4.2018 v 07:46 Petr Pisar napsal(a):
> Maybe nobody knows how to determine a system is live.

+1

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[Petr Pisar]

On 2018-04-17, Zbigniew Jędrzejewski-Szmek  wrote:
> I'm a bit surprised that there's no reply to this fairly explosive
> idea. Maybe Nikos' text is too long, so let me summarize:
>
> tl;dr: the proposal is to start services immediately during
> installation (in %post), iff they are enabled in presets and the
> system is live (not a chroot or such).
>
Maybe nobody knows how to determine a system is live.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: starting services in fedora

[Zbigniew Jędrzejewski-Szmek]

Hi all,

I'm a bit surprised that there's no reply to this fairly explosive
idea. Maybe Nikos' text is too long, so let me summarize:

tl;dr: the proposal is to start services immediately during
installation (in %post), iff they are enabled in presets and the
system is live (not a chroot or such).

This would mean that e.g. after 'dnf install gpm' gpm would be running
when dnf exits.

Zbyszek

On Mon, Apr 16, 2018 at 04:13:51PM +0200, Nikos Mavrogiannopoulos wrote:
> In [0] it was reported that after installation of pcsc-lite in Fedora,
> no smart cards were functioning at the system. After rebooting Fedora
> everything was functioning as expected.
> 
> The issue is that the pcsc daemon uses a socket-activated unit
> which is installed by dnf, but not started (and hence the windows-
> reminding behavior).
> 
> The text on our default services [1] mentions that a service is
> "enabled by default on package installation" though there is a 
> distinction between 'enable' and 'start'.
> 
> The reason behind that is probably summarized in [2]:
> > Why don't we start the service after installation?
> >Installations can be in changeroots, in an installer context, or 
> > in other situations where you don't want the services started.
> 
> which is understandable, but does not necessarily lead to good user
> experience in Fedora. Zbigniew made a good summary of what needs to be
> done for that to work [3].
> 
> What do you think overall, is that something that makes sense to
> address in general, or in socket activated services only, or not at
> all?
> 
> regards,
> Nikos
> 
> [0]. https://bugzilla.redhat.com/show_bug.cgi?id=1545027
> 
> [1].
> https://fedoraproject.org/wiki/Packaging:DefaultServices
> 
> [2]. https://fedoraproject.org/wiki/EPEL:SysVInitScripts?rd=Packaging:S
> ysVInitScript#Why_don.27t_we
> 
> [3]. https://bugzilla.redhat.com/show_bug.cgi?id=1545027#c29
> 
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org