9:29 a.m.
Hi,
I'm having trouble finding a policy on which systemd units may be
enabled by default.
The case I'm interested in particularly is cups.socket, cups.path,
cups.service.
What's the current policy, and where can I find it on the wiki?
Tim.
*/
9:34 a.m.
On 08/17/2011 07:59 PM, Tim Waugh wrote:
Hi,
I'm having trouble finding a policy on which systemd units may be
enabled by default.
The case I'm interested in particularly is cups.socket, cups.path,
cups.service.
What's the current policy, and where can I find it on the wiki?
https://fedoraproject.org/wiki/Starting_services_by_default
Rahul
10:17 a.m.
On Wed, 2011-08-17 at 20:04 +0530, Rahul Sundaram wrote:
Ah, thanks. So it looks like CUPS can be enabled by default:
"If a service does not require configuration to be functional and is not
network enabled, it may be enabled by default"
(The default CUPS configuration is localhost-only)
In the light of this I'll enable cups.path (to allow printing jobs which
are queued, on boot) and cups.socket (to allow on-demand start).
I'll leave cups.service out because that's only required for
network-enabled configurations -- but perhaps that needs a release note?
Tim.
*/
10:32 a.m.
On 08/17/2011 08:47 PM, Tim Waugh wrote:
I'll leave cups.service out because that's only required for
network-enabled configurations -- but perhaps that needs a release
note? Tim. */
Yes. You can add it here
https://fedoraproject.org/wiki/Documentation_Printing_Beat
Rahul
10:43 a.m.
On Wed, 2011-08-17 at 21:02 +0530, Rahul Sundaram wrote:
On 08/17/2011 08:47 PM, Tim Waugh wrote:
> I'll leave cups.service out because that's only required for
> network-enabled configurations -- but perhaps that needs a release
> note? Tim. */
Yes. You can add it here
https://fedoraproject.org/wiki/Documentation_Printing_Beat
Oh, I just noticed this:
https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activa...
"Since Fedora currently doesn't want any services to do on-demand
loading, all socket activated services must autostart."
So I'll also enable cups.service.
Tim.
*/
10:50 a.m.
On Wed, 2011-08-17 at 10:46 -0500, Michael Cronenworth wrote:
Are you pushing this change into Fedora 16?
Once it's built, yes, to fix:
https://bugzilla.redhat.com/show_bug.cgi?id=731421
Tim.
*/
5:28 a.m.
On Wed, 17.08.11 16:43, Tim Waugh (twaugh(a)redhat.com) wrote:
Oh, I just noticed this:
https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activa...
"Since Fedora currently doesn't want any services to do on-demand
loading, all socket activated services must autostart."
Uh, oh. I think CUPS is definitely something we should lazily socket
activate instead of run it unconditionally.
Spot, Bill, what's the reason for this wording in the guidelines? As
CUPS is something we really should start only when needed, why do we
have this wording in the guidelines? Can we relax this?
Lennart
--
Lennart Poettering - Red Hat, Inc.
11:33 a.m.
Lennart Poettering (mzerqung(a)0pointer.de) said:
> Oh, I just noticed this:
>
> https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activa...
> "Since Fedora currently doesn't want any services to do on-demand
> loading, all socket activated services must autostart."
Uh, oh. I think CUPS is definitely something we should lazily socket
activate instead of run it unconditionally.
Spot, Bill, what's the reason for this wording in the guidelines? As
CUPS is something we really should start only when needed, why do we
have this wording in the guidelines? Can we relax this?
I'm trying to remember. Perhaps it stemmed from the side consequence of
needing to know if a particular service had a socket entry, and therefore
you needed to disable both to disable a service? (I do recall there being
issues with socket-activated NetworkManager for reasons along these
lines.)
For something like cups, would this impose a significant delay in things
such as the GTK or QT print dialog, if opening that dialog causes the
cups daemon to then start?
Bill
5:29 p.m.
On Thu, 18.08.11 12:33, Bill Nottingham (notting(a)redhat.com) wrote:
Lennart Poettering (mzerqung(a)0pointer.de) said:
> > Oh, I just noticed this:
> >
> > https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activa...
> > "Since Fedora currently doesn't want any services to do on-demand
> > loading, all socket activated services must autostart."
>
> Uh, oh. I think CUPS is definitely something we should lazily socket
> activate instead of run it unconditionally.
>
> Spot, Bill, what's the reason for this wording in the guidelines? As
> CUPS is something we really should start only when needed, why do we
> have this wording in the guidelines? Can we relax this?
I'm trying to remember. Perhaps it stemmed from the side consequence of
needing to know if a particular service had a socket entry, and therefore
you needed to disable both to disable a service? (I do recall there being
issues with socket-activated NetworkManager for reasons along these
lines.)
Well, but disabling and enabling doesn't have to list 1:1 the same
units. The disabling-on-uninstall should always disable all units we
installed while the enabling-on-install should only enable the socket
and path units.
For something like cups, would this impose a significant delay in
things
such as the GTK or QT print dialog, if opening that dialog causes the
cups daemon to then start?
Unlikely. CUPS is not that slow. I mean, if the dialog takes a second or
so this would still be completely fine, but in real life CUPS starts
much faster. On my machine it is very hard to see any difference at all
if I run "lpq" on a shell when CUPS is started and when it is not. So, I
don't think this should be any issue at all.
Lennart
--
Lennart Poettering - Red Hat, Inc.
5:35 p.m.
On 08/18/2011 06:29 PM, Lennart Poettering wrote:
On Thu, 18.08.11 12:33, Bill Nottingham (notting(a)redhat.com) wrote:
>
> Lennart Poettering (mzerqung(a)0pointer.de) said:
>>> Oh, I just noticed this:
>>>
>>>
https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activa...
>>> "Since Fedora currently doesn't want any services to do on-demand
>>> loading, all socket activated services must autostart."
>>
>> Uh, oh. I think CUPS is definitely something we should lazily socket
>> activate instead of run it unconditionally.
>>
>> Spot, Bill, what's the reason for this wording in the guidelines? As
>> CUPS is something we really should start only when needed, why do we
>> have this wording in the guidelines? Can we relax this?
>
> I'm trying to remember. Perhaps it stemmed from the side consequence of
> needing to know if a particular service had a socket entry, and therefore
> you needed to disable both to disable a service? (I do recall there being
> issues with socket-activated NetworkManager for reasons along these
> lines.)
Well, but disabling and enabling doesn't have to list 1:1 the same
units. The disabling-on-uninstall should always disable all units we
installed while the enabling-on-install should only enable the socket
and path units.
> For something like cups, would this impose a significant delay in things
> such as the GTK or QT print dialog, if opening that dialog causes the
> cups daemon to then start?
Unlikely. CUPS is not that slow. I mean, if the dialog takes a second or
so this would still be completely fine, but in real life CUPS starts
much faster. On my machine it is very hard to see any difference at all
if I run "lpq" on a shell when CUPS is started and when it is not. So, I
don't think this should be any issue at all.
Lennart
I have noticed that to install a printer on a new F16 instllation that
you first have to manually start cups else the system-config-printer
dialogue refuses to cooperate.
--
Regards,
OldFart
5:52 p.m.
On 08/18/2011 04:29 PM, Lennart Poettering wrote:
On Thu, 18.08.11 12:33, Bill Nottingham (notting(a)redhat.com) wrote:
> For something like cups, would this impose a significant delay in things
> such as the GTK or QT print dialog, if opening that dialog causes the
> cups daemon to then start?
Unlikely. CUPS is not that slow. I mean, if the dialog takes a second or
so this would still be completely fine, but in real life CUPS starts
much faster. On my machine it is very hard to see any difference at all
if I run "lpq" on a shell when CUPS is started and when it is not. So, I
don't think this should be any issue at all.
Lennart
It's not so much cups start up being slow as discovering network printers.
That can take up to a minute I think.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
2:41 a.m.
On Thu, 2011-08-18 at 16:52 -0600, Orion Poplawski wrote:
It's not so much cups start up being slow as discovering network
printers.
That can take up to a minute I think.
This is true... however, discovered printers are cached so this is only
an issue the first time CUPS starts after installation (or after
connection to a new network).
Additionally there are plans afoot to use Avahi for CUPS <-> CUPS
printer discovery, replacing the current "send a broadcast packet every
30s" protocol. This would eliminate the problem entirely.
Tim.
*/
7:35 a.m.
On Friday, August 19, 2011 03:41:33 AM Tim Waugh wrote:
On Thu, 2011-08-18 at 16:52 -0600, Orion Poplawski wrote:
> It's not so much cups start up being slow as discovering network
> printers. That can take up to a minute I think.
This is true... however, discovered printers are cached so this is only
an issue the first time CUPS starts after installation (or after
connection to a new network).
If CUPS is enabled by default, can this be done for runlevel 5 only? It should not be
enabled by default for servers.
Additionally there are plans afoot to use Avahi for CUPS <->
CUPS
printer discovery, replacing the current "send a broadcast packet every
30s" protocol. This would eliminate the problem entirely.
All security guidance says turn off or get rid of avahi. We really don't want to
require it just to print.
-Steve
9 a.m.
On 08/19/2011 12:35 PM, Steve Grubb wrote:
On Friday, August 19, 2011 03:41:33 AM Tim Waugh wrote:
> On Thu, 2011-08-18 at 16:52 -0600, Orion Poplawski wrote:
>> It's not so much cups start up being slow as discovering network
>> printers. That can take up to a minute I think.
> This is true... however, discovered printers are cached so this is only
> an issue the first time CUPS starts after installation (or after
> connection to a new network).
If CUPS is enabled by default, can this be done for runlevel 5 only? It should not be
enabled by default for servers.
There are no such things as run levels in systemd but yeah desktop
related services should just be enabled when booting into the graphical
target.
> Additionally there are plans afoot to use Avahi for CUPS<-> CUPS
> printer discovery, replacing the current "send a broadcast packet every
> 30s" protocol. This would eliminate the problem entirely.
All security guidance says turn off or get rid of avahi. We really don't want to
require it just to print.
-Steve
Arguably sshd and nfs should be disabled by default as well and [1]
mentioned avahi is enabled by default as an specific exceptions FESCO
should update that wiki page with the arguments on why these services
are granted exceptions of being enabled by default.
Personally I'm of the opinion that non essential services should not be
enabled by default.
JBG
1. https://fedoraproject.org/wiki/Starting_services_by_default
9:38 a.m.
On 19. aug. 2011 16:00, "Jóhann B. Guðmundsson" wrote:
On 08/19/2011 12:35 PM, Steve Grubb wrote:
> On Friday, August 19, 2011 03:41:33 AM Tim Waugh wrote:
>> On Thu, 2011-08-18 at 16:52 -0600, Orion Poplawski wrote:
>>> It's not so much cups start up being slow as discovering network
>>> printers. That can take up to a minute I think.
>> This is true... however, discovered printers are cached so this is only
>> an issue the first time CUPS starts after installation (or after
>> connection to a new network).
> If CUPS is enabled by default, can this be done for runlevel 5 only? It should not
be
> enabled by default for servers.
There are no such things as run levels in systemd but yeah desktop
related services should just be enabled when booting into the graphical
target.
Just a thought - would it make sense to create a "server-target" (and/or
"desktop-target") that is independent of graphical-target?
I know I like to have GUI available - also on my servers - as it makes
searching for fixes and bugreports easier when I have to log in on the
console.
Or is that just redundant, and I'll just have to turn off cups (and
other services I don't need) as before?
/Olen
10:07 a.m.
On Friday, August 19, 2011 10:38:59 AM Ola Thoresen wrote:
On 19. aug. 2011 16:00, "Jóhann B. Guðmundsson" wrote:
> On 08/19/2011 12:35 PM, Steve Grubb wrote:
>> On Friday, August 19, 2011 03:41:33 AM Tim Waugh wrote:
>>> On Thu, 2011-08-18 at 16:52 -0600, Orion Poplawski wrote:
>>>> It's not so much cups start up being slow as discovering network
>>>> printers. That can take up to a minute I think.
>>>
>>> This is true... however, discovered printers are cached so this is only
>>> an issue the first time CUPS starts after installation (or after
>>> connection to a new network).
>>
>> If CUPS is enabled by default, can this be done for runlevel 5 only? It
>> should not be enabled by default for servers.
>
> There are no such things as run levels in systemd but yeah desktop
> related services should just be enabled when booting into the graphical
> target.
Just a thought - would it make sense to create a "server-target" (and/or
"desktop-target") that is independent of graphical-target?
I would hope there are pre-canned targets for different crowds. I also hope there is a
secure default configuration for each of them. I also hope there is a way to list all
of these targets and what is enabled for each one, because that will be needed for any
kind of security analysis.
I know I like to have GUI available - also on my servers - as it
makes
searching for fixes and bugreports easier when I have to log in on the
console.
Or is that just redundant, and I'll just have to turn off cups (and
other services I don't need) as before?
I hope not. That would be a step backwards in usability and security.
-Steve
10:12 a.m.
On Fri, Aug 19, 2011 at 11:07:45AM -0400, Steve Grubb wrote:
On Friday, August 19, 2011 10:38:59 AM Ola Thoresen wrote:
> On 19. aug. 2011 16:00, "Jóhann B. Guðmundsson" wrote:
> > On 08/19/2011 12:35 PM, Steve Grubb wrote:
> >> On Friday, August 19, 2011 03:41:33 AM Tim Waugh wrote:
> >>> On Thu, 2011-08-18 at 16:52 -0600, Orion Poplawski wrote:
> >>>> It's not so much cups start up being slow as discovering
network
> >>>> printers. That can take up to a minute I think.
> >>>
> >>> This is true... however, discovered printers are cached so this is
only
> >>> an issue the first time CUPS starts after installation (or after
> >>> connection to a new network).
> >>
> >> If CUPS is enabled by default, can this be done for runlevel 5 only? It
> >> should not be enabled by default for servers.
> >
> > There are no such things as run levels in systemd but yeah desktop
> > related services should just be enabled when booting into the graphical
> > target.
>
> Just a thought - would it make sense to create a "server-target" (and/or
> "desktop-target") that is independent of graphical-target?
I would hope there are pre-canned targets for different crowds. I also hope there is a
secure default configuration for each of them. I also hope there is a way to list all
There was some talk about ”preset” - what should be enabled in various scenarios
(spins).
of these targets and what is enabled for each one, because that will
be needed for any
kind of security analysis.
System settings:
% ls /lib/systemd/system/<name>.target.wants/
Admin settings:
% ls /etc/systemd/system/<name>.target.wants/
--
Tomasz Torcz "God, root, what's the difference?"
xmpp: zdzichubg(a)chrome.pl "God is more forgiving."
10:39 a.m.
On Friday, August 19, 2011 11:12:25 AM Tomasz Torcz wrote:
On Fri, Aug 19, 2011 at 11:07:45AM -0400, Steve Grubb wrote:
> On Friday, August 19, 2011 10:38:59 AM Ola Thoresen wrote:
> > On 19. aug. 2011 16:00, "Jóhann B. Guðmundsson" wrote:
> > > On 08/19/2011 12:35 PM, Steve Grubb wrote:
> > >> On Friday, August 19, 2011 03:41:33 AM Tim Waugh wrote:
> > >>> On Thu, 2011-08-18 at 16:52 -0600, Orion Poplawski wrote:
> > >>>> It's not so much cups start up being slow as discovering
network
> > >>>> printers. That can take up to a minute I think.
> > >>>
> > >>> This is true... however, discovered printers are cached so this
is
> > >>> only an issue the first time CUPS starts after installation (or
> > >>> after connection to a new network).
> > >>
> > >> If CUPS is enabled by default, can this be done for runlevel 5 only?
> > >> It should not be enabled by default for servers.
> > >
> > > There are no such things as run levels in systemd but yeah desktop
> > > related services should just be enabled when booting into the
> > > graphical target.
> >
> > Just a thought - would it make sense to create a "server-target"
> > (and/or "desktop-target") that is independent of graphical-target?
>
> I would hope there are pre-canned targets for different crowds. I also
> hope there is a secure default configuration for each of them. I also
> hope there is a way to list all
There was some talk about ”preset” - what should be enabled in various
scenarios (spins).
So, the main Fedora download is not sufficient? We have to download a server spin to
have the right security settings? If so we should also take way the ability to pick
packages because someone might accidentally create a server at install time.
We need a way to specify in the service init files which targets the service is allowed
to run in by default.
> of these targets and what is enabled for each one, because that
will be
> needed for any kind of security analysis.
System settings:
% ls /lib/systemd/system/<name>.target.wants/
Admin settings:
% ls /etc/systemd/system/<name>.target.wants/
What would be nice is to wrap that up in a program, format it into columns for easy
comparison. Once you have that it might even be nice to use the same tool to make
configuration changes....
-Steve
10:49 a.m.
On 08/19/2011 03:39 PM, Steve Grubb wrote:
We need a way to specify in the service init files which targets the
service is allowed
to run in by default.
You do that in the install section of the unit file
[Install]
WantedBy=$foo.target
So basically all desktop related service should only have...
[Install]
WantedBy=graphical.target
And all server services should have
[Install]
WantedBy=multi-user.target
All systemd critical function services
[Install]
WantedBy=basic.target
etc..
JBG
10:57 a.m.
On Fri, 19.08.11 17:12, Tomasz Torcz (tomek(a)pipebreaker.pl) wrote:
> > Just a thought - would it make sense to create a
"server-target" (and/or
> > "desktop-target") that is independent of graphical-target?
>
> I would hope there are pre-canned targets for different crowds. I also hope there is
a
> secure default configuration for each of them. I also hope there is a way to list
all
There was some talk about ”preset” - what should be enabled in various
scenarios (spins).
This is actually already available in the systemd version in F16, but not used
by Fedora. I plan to make this a feature for F17.
Presets allow the distributor (or administrator) to easily define
policies on which services should be enabled or disabled by default. By
dropping a .conf file with the contents of "disable *" into
/etc/systemd/system.preset the admin can make sure that all services
installed from that point on will be disabled by default. Presets can be
a lot more complex if needed, and I expect that Fedora will ship a
default preset policy that enables the few services which may start by
default, and leaves everything else off.
That said, the code is in systemd in F16 this is not useful yet, since
the %postin scripts of our packages currently invoke "systemctl enable"
instead of "systemctl preset". (The former unconditionally enables, the
latter consults the preset files first) To make these presets work we'll have
to update the packaging guidelines a bit. (Oh, and while doing this we
will introduce rpm macros for enabling services, which can be shared
across distributions.)
Lennart
--
Lennart Poettering - Red Hat, Inc.
10:34 a.m.
On 08/19/2011 10:08 AM, Ola Thoresen wrote:
On 19. aug. 2011 16:00, "Jóhann B. Guðmundsson" wrote:
> On 08/19/2011 12:35 PM, Steve Grubb wrote:
>> On Friday, August 19, 2011 03:41:33 AM Tim Waugh wrote:
>>> On Thu, 2011-08-18 at 16:52 -0600, Orion Poplawski wrote:
>>>> It's not so much cups start up being slow as discovering network
>>>> printers. That can take up to a minute I think.
>>> This is true... however, discovered printers are cached so this is only
>>> an issue the first time CUPS starts after installation (or after
>>> connection to a new network).
>> If CUPS is enabled by default, can this be done for runlevel 5 only? It should
not be
>> enabled by default for servers.
>
> There are no such things as run levels in systemd but yeah desktop
> related services should just be enabled when booting into the graphical
> target.
>
Just a thought - would it make sense to create a "server-target" (and/or
"desktop-target") that is independent of graphical-target?
I know I like to have GUI available - also on my servers - as it makes
searching for fixes and bugreports easier when I have to log in on the
console.
Or is that just redundant, and I'll just have to turn off cups (and
other services I don't need) as before?
IIRC last releases includes an option "Printing support", if this is not
checked in the package selection screen, Cups is not installed
/Olen
9:59 a.m.
Am 19.08.2011 16:50, schrieb Richard Hughes:
On 19 August 2011 13:35, Steve Grubb <sgrubb(a)redhat.com>
wrote:
> All security guidance says turn off or get rid of avahi. We really don't want to
> require it just to print.
Then "security" is flying in the face of usability
this is always so, nearly everything what somebody calls usability
has implications in security - and that is why linux should not go
only the "usability-way" for every piece instead make a secure default
install - if you need avahi you can install/enable it, but do not
force every body out there have it installed only because it makes
it easier for every braindead guy set up a system without thinking
if you need such a system Apple is your favorite because they enable
everything without thinking any second if this could affect security
resulting in having every crap installed and active
especially as long fedora have really usability bugs like
"systemctl start/stop service"
gives no feedback and the dumb wrapper for "/sbin/service" says
OK even if all fails and THIS are usability faux passes without
negative security implications or in worstcase if you start
a service with increases security with "service start" you
are thinking it is running while it has failed
10:03 a.m.
On Friday, August 19, 2011 10:50:51 AM Richard Hughes wrote:
On 19 August 2011 13:35, Steve Grubb <sgrubb(a)redhat.com>
wrote:
> All security guidance says turn off or get rid of avahi. We really don't
> want to require it just to print.
Then "security" is flying in the face of usability.
Generally there is that tension. The main objections is that it makes discovering
system resources easy, which in terms of security is bad. It also used to punch a hole
in the firewall and add routing rules. All of this is bad for security. If you are
catering to a laptop crowd that wants to share music and pictures then avahi is no
concern.
If however you want a secure by default server OS, then avahi needs to default to
disabled. The concern is when its allowed by default, then people might start relying
on it to the extent that its impossible to remove later. For example, cups is used as
part of the LSPP certification. People running in a LSPP configuration would be horrified
to know avahi is now required for printing top secret documents.
-Steve
10:24 a.m.
On Fri, 2011-08-19 at 11:03 -0400, Steve Grubb wrote:
People running in a LSPP configuration would be horrified
to know avahi is now required for printing top secret documents.
Just to clarify: it is not required. Most likely in an LSPP
configuration not even CUPS Browsing is used, but explicit queues are
set up on each client machine.
Tim.
*/
10:32 a.m.
On Friday, August 19, 2011 11:24:39 AM Tim Waugh wrote:
On Fri, 2011-08-19 at 11:03 -0400, Steve Grubb wrote:
> People running in a LSPP configuration would be horrified
> to know avahi is now required for printing top secret documents.
Just to clarify: it is not required. Most likely in an LSPP
configuration not even CUPS Browsing is used, but explicit queues are
set up on each client machine.
Thanks for that information. As long as we never lose that ability and avahi can be
switched off or removed then all is well.
Thanks,
-Steve
10:47 a.m.
On Fri, 19.08.11 11:03, Steve Grubb (sgrubb(a)redhat.com) wrote:
On Friday, August 19, 2011 10:50:51 AM Richard Hughes wrote:
> On 19 August 2011 13:35, Steve Grubb <sgrubb(a)redhat.com> wrote:
> > All security guidance says turn off or get rid of avahi. We really don't
> > want to require it just to print.
>
> Then "security" is flying in the face of usability.
Generally there is that tension. The main objections is that it makes discovering
system resources easy, which in terms of security is bad. It also used to punch a hole
in the firewall and add routing rules. All of this is bad for security. If you are
catering to a laptop crowd that wants to share music and pictures then avahi is no
concern.
If however you want a secure by default server OS, then avahi needs to default to
disabled. The concern is when its allowed by default, then people might start relying
on it to the extent that its impossible to remove later. For example, cups is used as
part of the LSPP certification. People running in a LSPP configuration would be horrified
to know avahi is now required for printing top secret documents.
Well, I think Fedora is more interested in real-life users than
synthetic certifications.
Also, running Avahi is probably a lot safer than CUPS. Don't forget that
Avahi is pretty much the only service in a default Fedora install that
chroot()s by default. On top of that it drops privileges and uses
capabilities and resource limits to minimize what it can do. It has been
doing pretty elaborate privilege separation since shortly after its
inception. It has been doing that since a long long time, much longer
than almost any other standard component of our Linux system. In fact I
am always a bit disapointed that it still is the only default component
that chroot()s. (Oh wait, there's another one now, rtkit, written by the
same smart guy).
CUPS otoh runs with root privileges, no chroot, no dropped
capabilities. If you manage to exploit CUPS you own the system. If you
manage to exploit Avahi you are trapped in an unprivileged chroot
container, with no ability to even create a file.
By disabling the native service discovery protocol in CUPS and moving
that into Avahi you hence get a substantial security benefit, not a loss
of security.
Lennart
--
Lennart Poettering - Red Hat, Inc.
10:51 a.m.
On Fri, 2011-08-19 at 17:47 +0200, Lennart Poettering wrote:
Well, I think Fedora is more interested in real-life users than
synthetic certifications.
I think you are not the arbiter of what fedora is interested in.
If this is a point of conflict it should be discussed with the board and
fesco.
-sv
11:01 a.m.
On Fri, 19.08.11 11:51, seth vidal (skvidal(a)fedoraproject.org) wrote:
On Fri, 2011-08-19 at 17:47 +0200, Lennart Poettering wrote:
> Well, I think Fedora is more interested in real-life users than
> synthetic certifications.
I think you are not the arbiter of what fedora is interested in.
Uh? I wrote "I think". No need to reply so agressively.
If this is a point of conflict it should be discussed with the board
and
fesco.
Avahi is already listed as one of the services which may start by
default, which makes me happy.
Lennart
--
Lennart Poettering - Red Hat, Inc.
11 a.m.
Am 19.08.2011 17:47, schrieb Lennart Poettering:
Well, I think Fedora is more interested in real-life users than
synthetic certifications
well, when will you start to fix the usability-faux-passes you brought
for the normal users? the last systemd update is long ago
* no feedback of systemctl and wrong from /sbin/service-wrapper
* systemctl does not stop .socket if you stop .service
* useless auto-completion for systemctl
* no progress while fs-check on boot
* no green Ok / red FAILED at boot time, only a desert of text
this are only a subset of degraded usability brought only by you
afther that we can discuss in which is fedora interested and even then
you are not in the position to define this!
11:46 a.m.
On Fri, 19.08.11 18:00, Reindl Harald (h.reindl(a)thelounge.net) wrote:
Heya,
* no feedback of systemctl and wrong from /sbin/service-wrapper
Like most Unix commands systemctl will not output anything in case of
success, only on failure. See cp, ln, mv, rm for similar behaviour.
* systemctl does not stop .socket if you stop .service
And it shouldn't. There's an item on the todo list to add a warning if
the user stops a service unit but leaves the socket unit running.
* useless auto-completion for systemctl
Hmm? Bug#?
* no progress while fs-check on boot
The way I'd like to see this fixed is that fsck's -C switch can
optionally take a path like /dev/console to output its progress
bar. Then again, ideally the progress information would be passed on to
Plymouth instead of the console. In both cases systemd should probably
not be involved.
* no green Ok / red FAILED at boot time, only a desert of text
Not really true.
First of all, we will output "Starting ..." and "Started ..."
messages
as the boot proceeds if you remvoe "quiet" from the kernel cmdline. If a
service fails, we will even say that and highlight it in red. What we
won't do however is mark success in green, in order to keep visual
distraction minimal.
On top of that, at any time you can type in "systemctl" and you'll get
colorful output of what services successfully started and which ones
didn't. This is a substantial improvement over classic SysV where the
boot time output scrolled away quickly and only screen-scraping could
help to get a bit of an idea what actually started properly and what
didn't.
Lennart
--
Lennart Poettering - Red Hat, Inc.
5:13 p.m.
Am 19.08.2011 18:46, schrieb Lennart Poettering:
On Fri, 19.08.11 18:00, Reindl Harald (h.reindl(a)thelounge.net)
wrote:
Heya,
> * no feedback of systemctl and wrong from /sbin/service-wrapper
Like most Unix commands systemctl will not output anything in case of
success, only on failure. See cp, ln, mv, rm for similar behaviour.
if you are replacing /sbin/service which gave feedback over all the
years you have to give feedback too and not make the same crap like
apple
and NO it does also not give feedback if service fails
> * systemctl does not stop .socket if you stop .service
And it shouldn't. There's an item on the todo list to add a warning if
the user stops a service unit but leaves the socket unit running.
it should
if you say it shouldn't you have a hughe design-mistake in the whole
software - if i say "service stop anythign" i mean stop and not
that any dumkb software fires it up
if you can give a warning you can also stop the socket
this is what the user expects and if your software-design
is not able to act logically it is broken
> * useless auto-completion for systemctl
Hmm? Bug#?
"service restart htt"
you can type TAb the whole day and will get no auto-completion
if the service is running - shos me you are not really using your
own software and i did not think a bugreport for such basics
is needed
> * no progress while fs-check on boot
The way I'd like to see this fixed is that fsck's -C switch can
optionally take a path like /dev/console to output its progress
bar. Then again, ideally the progress information would be passed on to
Plymouth instead of the console. In both cases systemd should probably
not be involved.
sorry to say but: it does nobody interest what you like
a fs-check on a 4 TB disk without any feedback is unnaccpetable
because inak KVM-Session you see not disk-LED's and do not hear the
drive - so with your behavior in the worst case somebody forces
a hard restart while fsck is running
> D* no green Ok / red FAILED at boot time, only a desert of text
Not really true.
First of all, we will output "Starting ..." and "Started ..."
messages
as the boot proceeds if you remvoe "quiet" from the kernel cmdline. If a
service fails, we will even say that and highlight it in red. What we
won't do however is mark success in green, in order to keep visual
distraction minimal.
i first disable the dumb quite-option on every install
i recommend you take a look at a F14 boot and yours
it is a hughe differene having a red colored FAILED or your text-desert with
no difference and the output of the service-description instead a short name
is simply a design-mistake
On top of that, at any time you can type in "systemctl" and
you'll get
colorful output of what services successfully started and which ones
didn't. This is a substantial improvement over classic SysV where the
boot time output scrolled away quickly and only screen-scraping could
help to get a bit of an idea what actually started properly and what
didn't.
yes it is a improvent to get htis after the boot but if you restart a
server
you nromally watch the boot and have no reason to login as long you see
nothing red - this was broken by the usability-pifall how systemd boots
7:09 a.m.
On Sat, 2011-08-20 at 00:13 +0200, Reindl Harald wrote:
if you can give a warning you can also stop the socket
this is what the user expects and if your software-design
is not able to act logically it is broken
Stopping the service but leaving the possibility for later socket
activation is a valid use case. Warning about that because it also could
be a mistake is a nice service and sufficient.
"service restart htt"
you can type TAb the whole day and will get no auto-completion
Of course not. This is wrong syntax.
systemctl restart htt<tab>
should do what you're trying to accomplish. If you insist on using the
"service" wrapper script, the appropriate syntax would be:
service htt<tab> restart
It does fine in both cases.
yes it is a improvent to get htis after the boot but if you restart a
server
you nromally watch the boot and have no reason to login as long you see
nothing red - this was broken by the usability-pifall how systemd boots
I'm pretty certain that failures are colored red. Are you sure you got
your facts right?
Lars
7:23 a.m.
Am 20.08.2011 14:09, schrieb Lars Seipel:
On Sat, 2011-08-20 at 00:13 +0200, Reindl Harald wrote:
> if you can give a warning you can also stop the socket
> this is what the user expects and if your software-design
> is not able to act logically it is broken
Stopping the service but leaving the possibility for later socket
activation is a valid use case. Warning about that because it also could
be a mistake is a nice service and sufficient.
it is NOT a valid usecase because the service is restarted a moment later
> "service restart htt"
>
> you can type TAb the whole day and will get no auto-completion
Of course not. This is wrong syntax.
systemctl restart htt<tab>
should do what you're trying to accomplish. If you insist on using the
"service" wrapper script, the appropriate syntax would be:
service htt<tab> restart
It does fine in both cases.
this was a typo and IT DOES NOT
and if you look on the systemd-mailing list you will find a patch for this
but damned why does F15 get no updates for systemd over months?
this is reasonable for software which is stable and bugfree, but systemd is
not and targeting bugfixes/optimizing for F16/F17 is unacceptable
it does if the service is NOT running which is useless for "restart"
[root@srv-rhsoft:~]$ systemctl restart htt^C
[root@srv-rhsoft:~]$ systemctl stop httpd.service
[root@srv-rhsoft:~]$ systemctl restart httpd.service
> yes it is a improvent to get htis after the boot but if you
restart a server
> you nromally watch the boot and have no reason to login as long you see
> nothing red - this was broken by the usability-pifall how systemd boots
I'm pretty certain that failures are colored red. Are you sure you got
your facts right?
Lars
they are NOT
i am sure because my self-written "pulsed.service" will fail the first 10 times
compare a F14 boot WITHOUT quiet and a F15 boot and after that
you will not tell me that the whole output is not degraded since
systemd started take over the world
[root@srv-rhsoft:~]$ cat /lib/systemd/system/pulsed.service
[Unit]
Description=Pulseaudio Daemon
After=syslog.target local-fs.target rtkit-daemon.service udev.service dbus.service
prefdm.service
[Service]
Type=forking
ExecStart=-/usr/bin/pulseaudio --daemonize=true --system=true --log-level=0
--log-target=stderr
--disallow-module-loading --disallow-exit --exit-idle-time=0 --disable-shm
--no-cpu-limit=false --use-pid-file=false
Restart=always
RestartSec=30
TimeoutSec=15
Nice=-10
[Install]
WantedBy=multi-user.target
another thing where lennart is responsible that he believes to know
what is good for users and will not probide a systemwide pulsed, where
here he could show that systemd brings any benefit to the users by
packaging "pulseaudio-systemwide.rpm" and fix both (systemd and pulseaudio)
as long they are not working perfectly together as system-instance
again: there are users running music from their machine the whole day
without login or even with login as another user, but this usecase
does not bother Lennart
1:18 p.m.
On 08/20/2011 08:09 AM, Lars Seipel wrote:
On Sat, 2011-08-20 at 00:13 +0200, Reindl Harald wrote:
> if you can give a warning you can also stop the socket
> this is what the user expects and if your software-design
> is not able to act logically it is broken
Stopping the service but leaving the possibility for later socket
activation is a valid use case. Warning about that because it also could
be a mistake is a nice service and sufficient.
How can you say that? I stopped the serivce! I don't expect it to magically
start backup!!!
You are just plain wrong. Any system should be about doing things with the "least
surprise to the user"!
> "service restart htt"
>
> you can type TAb the whole day and will get no auto-completion
Of course not. This is wrong syntax.
systemctl restart htt<tab>
should do what you're trying to accomplish. If you insist on using the
"service" wrapper script, the appropriate syntax would be:
service htt<tab> restart
It does fine in both cases.
> yes it is a improvent to get htis after the boot but if you restart a server
> you nromally watch the boot and have no reason to login as long you see
> nothing red - this was broken by the usability-pifall how systemd boots
I'm pretty certain that failures are colored red. Are you sure you got
your facts right?
Lars
--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark(a)netwolves.com
http://www.netwolves.com
12:32 p.m.
On Fri, 2011-08-19 at 17:47 +0200, Lennart Poettering wrote:
On Fri, 19.08.11 11:03, Steve Grubb (sgrubb(a)redhat.com) wrote:
>
> On Friday, August 19, 2011 10:50:51 AM Richard Hughes wrote:
> > On 19 August 2011 13:35, Steve Grubb <sgrubb(a)redhat.com> wrote:
> > > All security guidance says turn off or get rid of avahi. We really
don't
> > > want to require it just to print.
> >
> > Then "security" is flying in the face of usability.
>
> Generally there is that tension. The main objections is that it makes discovering
> system resources easy, which in terms of security is bad. It also used to punch a
hole
> in the firewall and add routing rules. All of this is bad for security. If you are
> catering to a laptop crowd that wants to share music and pictures then avahi is no
> concern.
>
> If however you want a secure by default server OS, then avahi needs to default to
> disabled. The concern is when its allowed by default, then people might start
relying
> on it to the extent that its impossible to remove later. For example, cups is used
as
> part of the LSPP certification. People running in a LSPP configuration would be
horrified
> to know avahi is now required for printing top secret documents.
Well, I think Fedora is more interested in real-life users than
synthetic certifications.
Well, no, those certifications are used to give guideliness to people
that have to work in security sensitive settings, and I am sure many
Fedora users do care about security, some chose Fedora above other
because it is the only one that has decent SELinux policies beyond RHEL
to date.
Also, running Avahi is probably a lot safer than CUPS. Don't
forget that
Avahi is pretty much the only service in a default Fedora install that
chroot()s by default. On top of that it drops privileges and uses
capabilities and resource limits to minimize what it can do. It has been
doing pretty elaborate privilege separation since shortly after its
inception. It has been doing that since a long long time, much longer
than almost any other standard component of our Linux system. In fact I
am always a bit disapointed that it still is the only default component
that chroot()s. (Oh wait, there's another one now, rtkit, written by the
same smart guy).
Avahi daemon security itself is not being questioned. It's the whole
protocol that is a huge security concern, given there is no verification
that the information you are getting is "true".
Avahi enables hosts to announce themselves with whatever name they want.
Just like netbios used to do. Which has serious implications about name
resolution in the system when stuff like mdns4_minimal is forcibly
installed *and* configured in Fedora. (I just discovered that after the
last few months of upgrades my machine agains has mdns4_minimal for the
hosts database line even though I explicitly commented it out for
example).
CUPS otoh runs with root privileges, no chroot, no dropped
capabilities. If you manage to exploit CUPS you own the system. If you
manage to exploit Avahi you are trapped in an unprivileged chroot
container, with no ability to even create a file.
By disabling the native service discovery protocol in CUPS and moving
that into Avahi you hence get a substantial security benefit, not a loss
of security.
For those that do not care about the security implication of printing on
a "random" printer, this is certainly a better proposition. Nobody is
complaining that cups browsing is being replaced by something better.
The complain is that avahi should not become a system component that is
impossible to deactivate, even better if the package containing the
daemon could be removed without causing issues, so that you can be sure
it will not be activated by mistake.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
9:07 a.m.
On 08/18/2011 06:29 PM, Lennart Poettering wrote:
Unlikely. CUPS is not that slow. I mean, if the dialog takes a second
or
so this would still be completely fine, but in real life CUPS starts
much faster. On my machine it is very hard to see any difference at all
if I run "lpq" on a shell when CUPS is started and when it is not. So, I
don't think this should be any issue at all.
OK, but the important case is not when everything works well but rather
when there are issues, e.g. networking problems, and suddenly the UI
locks up because it's blocked by CUPS. The point being that we want
predictable and responsive UI, and ensuring it is simpler when it
doesn't have far-reaching plumbing dependencies.
I am not arguing against the dynamic CUPS, just saying that it requires
careful thought and some tricky testing.
11:45 a.m.
On 08/18/2011 06:28 AM, Lennart Poettering wrote:
On Wed, 17.08.11 16:43, Tim Waugh (twaugh(a)redhat.com) wrote:
> Oh, I just noticed this:
>
> https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activa...
> "Since Fedora currently doesn't want any services to do on-demand
> loading, all socket activated services must autostart."
Uh, oh. I think CUPS is definitely something we should lazily socket
activate instead of run it unconditionally.
Spot, Bill, what's the reason for this wording in the guidelines? As
CUPS is something we really should start only when needed, why do we
have this wording in the guidelines? Can we relax this?
I think FESCo needs to decide what its policies are wrt on-demand
loading, then we can adjust the Packaging Guidelines appropriately.
~tom
==
Fedora Project
12:29 p.m.
On Mon, Aug 22, 2011 at 12:45:40PM -0400, Tom Callaway wrote:
On 08/18/2011 06:28 AM, Lennart Poettering wrote:
> On Wed, 17.08.11 16:43, Tim Waugh (twaugh(a)redhat.com) wrote:
>
>> Oh, I just noticed this:
>>
>> https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activa...
>> "Since Fedora currently doesn't want any services to do on-demand
>> loading, all socket activated services must autostart."
>
> Uh, oh. I think CUPS is definitely something we should lazily socket
> activate instead of run it unconditionally.
>
> Spot, Bill, what's the reason for this wording in the guidelines? As
> CUPS is something we really should start only when needed, why do we
> have this wording in the guidelines? Can we relax this?
I think FESCo needs to decide what its policies are wrt on-demand
loading, then we can adjust the Packaging Guidelines appropriately.
I'm pretty sure that we kicked this up to FESCo and they decided to treat
them the same (although the latter may not have come to a formal vote and
only been discussed during their IRC meetings on the overall subject.) Going
back to the quote in this message, though, that was a result of discussions
with Lennart rather than FESCo.
-Toshio
2:09 p.m.
On 08/22/2011 01:29 PM, Toshio Kuratomi wrote:
I'm pretty sure that we kicked this up to FESCo and they decided
to treat
them the same (although the latter may not have come to a formal vote and
only been discussed during their IRC meetings on the overall subject.) Going
back to the quote in this message, though, that was a result of discussions
with Lennart rather than FESCo.
Sure. I just want FESCo to either decide that socket-activated services
== the same as default enabled services, or that there is some sort of
separate whitelisting for socket-activated services.
~tom
==
Fedora Project
3:41 p.m.
On Mon, 22.08.11 15:09, Tom Callaway (tcallawa(a)redhat.com) wrote:
On 08/22/2011 01:29 PM, Toshio Kuratomi wrote:
> I'm pretty sure that we kicked this up to FESCo and they decided to treat
> them the same (although the latter may not have come to a formal vote and
> only been discussed during their IRC meetings on the overall subject.) Going
> back to the quote in this message, though, that was a result of discussions
> with Lennart rather than FESCo.
Sure. I just want FESCo to either decide that socket-activated services
== the same as default enabled services, or that there is some sort of
separate whitelisting for socket-activated services.
I'd vote for simply making this an implementation detail of the
package. I.e. if a package gets the permission to enable its service by
default it's up to it whether it wants to be started at boot or via
socket actviation of via any other kind of activation.
Lennart
--
Lennart Poettering - Red Hat, Inc.
4:01 p.m.
On 08/22/2011 04:41 PM, Lennart Poettering wrote:
I'd vote for simply making this an implementation detail of the
package. I.e. if a package gets the permission to enable its service by
default it's up to it whether it wants to be started at boot or via
socket actviation of via any other kind of activation.
Sure, assuming that FESCo agrees that packages starting by default is
the same as socket-enabled start on-demand.
~tom
==
Fedora Project
4:15 p.m.
Am 22.08.2011 23:01, schrieb Tom Callaway:
On 08/22/2011 04:41 PM, Lennart Poettering wrote:
> I'd vote for simply making this an implementation detail of the
> package. I.e. if a package gets the permission to enable its service by
> default it's up to it whether it wants to be started at boot or via
> socket actviation of via any other kind of activation.
Sure, assuming that FESCo agrees that packages starting by default is
the same as socket-enabled start on-demand.
this argumentation is strange and makes no sense
it is uninteresting what is starting per default
the USER decides what servcies he needs for whatever the machine should do
if you setup a nameserver as example it is useless taht avahi maybe
allowed to started as default and named not and because taht named
msut not have socket-activation
if you have a filserver with samba/netatalk NONE auf the current default-servcies
nor named nor avahi nor httpd or anything else is relevant for this machine
so explain me why i should this logic not call stupid?
some of the people taht making decisions about default-services should
start to understand that they are not really in the position to decide
for users waht servcies on what machines are important or not and the
only reason for such decisions have to be waht is the technical best
solution in a maximum of cases without damage user expierience
4:58 p.m.
On Mon, 22 Aug 2011 23:15:38 +0200
Reindl Harald <h.reindl(a)thelounge.net> wrote:
Am 22.08.2011 23:01, schrieb Tom Callaway:
> On 08/22/2011 04:41 PM, Lennart Poettering wrote:
>> I'd vote for simply making this an implementation detail of the
>> package. I.e. if a package gets the permission to enable its
>> service by default it's up to it whether it wants to be started at
>> boot or via socket actviation of via any other kind of activation.
>
> Sure, assuming that FESCo agrees that packages starting by default
> is the same as socket-enabled start on-demand.
this argumentation is strange and makes no sense
I think you are confused as to what 'by default' means.
It means: when you install this package on your Fedora system, will it
start automatically on next boot or not.
Thats all. You as end user can disable it, enable it, or do whatever
you like with it. Thats your choice. This default is simply talking
about what state it's in when first installed.
kevin
5:20 p.m.
Am 22.08.2011 23:58, schrieb Kevin Fenzi:
On Mon, 22 Aug 2011 23:15:38 +0200
Reindl Harald <h.reindl(a)thelounge.net> wrote:
>
>
> Am 22.08.2011 23:01, schrieb Tom Callaway:
>> On 08/22/2011 04:41 PM, Lennart Poettering wrote:
>>> I'd vote for simply making this an implementation detail of the
>>> package. I.e. if a package gets the permission to enable its
>>> service by default it's up to it whether it wants to be started at
>>> boot or via socket actviation of via any other kind of activation.
>>
>> Sure, assuming that FESCo agrees that packages starting by default
>> is the same as socket-enabled start on-demand.
>
> this argumentation is strange and makes no sense
I think you are confused as to what 'by default' means.
It means: when you install this package on your Fedora system, will it
start automatically on next boot or not.
Thats all. You as end user can disable it, enable it, or do whatever
you like with it. Thats your choice. This default is simply talking
about what state it's in when first installed
no i am NOT confused
if the definition it will be aneabled by default is teh decision
if a service can use socket-activation this is foolish because
as said there are many services out there which are not default
but users decide that they are the reason why a machine is running
so i hvae the choice start something at boot but i will never
benefit from socket-activation - if this is the case systemd
is useless as long for services which are NOT default like mysqld
must be done tricks to let systemd wait with the next service
until mysqld is full operational - there exists a patch
for socket-activation which would solve most of my troubles
and after that peopole come out and point at idiotic
decisions which forbid socket-activation for the package
and finally this idiotic discussion should have been
finished BEFORE release F15 wth sytemd and not at a
time where it is defacto too late because no one is gonna
fixing the bugs and wrong decisions for F15 this time
8:40 a.m.
On 08/22/2011 06:20 PM, Reindl Harald wrote:
and finally this idiotic discussion should have been
finished BEFORE release F15 wth sytemd and not at a
time where it is defacto too late because no one is gonna
fixing the bugs and wrong decisions for F15 this time
Mr. Harald,
This sort of tone is unacceptable. Please be civil and respectful, or be
silent.
~tom
==
Fedora Project
2:37 p.m.
Tom Callaway (tcallawa(a)redhat.com) said:
On 08/22/2011 01:29 PM, Toshio Kuratomi wrote:
> I'm pretty sure that we kicked this up to FESCo and they decided to treat
> them the same (although the latter may not have come to a formal vote and
> only been discussed during their IRC meetings on the overall subject.) Going
> back to the quote in this message, though, that was a result of discussions
> with Lennart rather than FESCo.
Sure. I just want FESCo to either decide that socket-activated services
== the same as default enabled services, or that there is some sort of
separate whitelisting for socket-activated services.
Thinking about this some more, I don't see why there should be a huge
distinction here.
A socket-activated service is much the same as a non-socket-activated
service, in that installing the unit won't activate the service unless
something calls for it, or the admin/rpm scripts run 'systemctl enable'. So
I don't think there needs to be any blanket prohibition on socket
activation; they would be packaged like service files, and would have
the same guidelines as to whether they're enabled in %post or not.
Note that if you have both a .socket and a .service file in your package,
you'd want to have Also=<the other one> in your files, such that enabling
or disabling one would enable/disable the other as well. This makes it
much clearer from the administrator's point of view, IMO.
Bill
2:54 p.m.
On Tue, Aug 23, 2011 at 13:37, Bill Nottingham <notting(a)redhat.com> wrote:
Tom Callaway (tcallawa(a)redhat.com) said:
> On 08/22/2011 01:29 PM, Toshio Kuratomi wrote:
> > I'm pretty sure that we kicked this up to FESCo and they decided to treat
> > them the same (although the latter may not have come to a formal vote and
> > only been discussed during their IRC meetings on the overall subject.) Going
> > back to the quote in this message, though, that was a result of discussions
> > with Lennart rather than FESCo.
>
> Sure. I just want FESCo to either decide that socket-activated services
> == the same as default enabled services, or that there is some sort of
> separate whitelisting for socket-activated services.
Thinking about this some more, I don't see why there should be a huge
distinction here.
A socket-activated service is much the same as a non-socket-activated
service, in that installing the unit won't activate the service unless
something calls for it, or the admin/rpm scripts run 'systemctl enable'. So
A couple of questions:
1) Does the above mean that every netscan will start up various
services on systems?
2) Would those services haven been listening before?
3) What is a good example that people can look at so we aren't all
hand-wavy in this discussion about couldas and such. If we have
something that is the "way it should be" we can then measure against
it.
--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
3:02 p.m.
On Tue, 23.08.11 13:54, Stephen John Smoogen (smooge(a)gmail.com) wrote:
On Tue, Aug 23, 2011 at 13:37, Bill Nottingham <notting(a)redhat.com> wrote:
> Tom Callaway (tcallawa(a)redhat.com) said:
>> On 08/22/2011 01:29 PM, Toshio Kuratomi wrote:
>> > I'm pretty sure that we kicked this up to FESCo and they decided to
treat
>> > them the same (although the latter may not have come to a formal vote and
>> > only been discussed during their IRC meetings on the overall subject.)
Going
>> > back to the quote in this message, though, that was a result of
discussions
>> > with Lennart rather than FESCo.
>>
>> Sure. I just want FESCo to either decide that socket-activated services
>> == the same as default enabled services, or that there is some sort of
>> separate whitelisting for socket-activated services.
>
> Thinking about this some more, I don't see why there should be a huge
> distinction here.
>
> A socket-activated service is much the same as a non-socket-activated
> service, in that installing the unit won't activate the service unless
> something calls for it, or the admin/rpm scripts run 'systemctl enable'. So
A couple of questions:
1) Does the above mean that every netscan will start up various
services on systems?
The focus of systemd's socket activation is primarily AF_UNIX, not so
much AF_INET. And besides CUPS and sshd there are probably not too many
services where lazy-loading services really makes sense. You want to
lazy-load only those service which are really seldom used (i.e. 1/h or
less or so). Also note that CUPS does not listen on AF_INET by default,
only AF_UNIX.
Also, cups is using Accept=no which means it would be started exactly
once and then stay around.
Lennart
--
Lennart Poettering - Red Hat, Inc.
3:07 p.m.
Stephen John Smoogen (smooge(a)gmail.com) said:
> A socket-activated service is much the same as a
non-socket-activated
> service, in that installing the unit won't activate the service unless
> something calls for it, or the admin/rpm scripts run 'systemctl enable'. So
A couple of questions:
1) Does the above mean that every netscan will start up various
services on systems?
Note that the most common socket-activated daemons are Unix domain sockets.
But, if you have a socket-activated service that's listening on TCP/UDP,
and have the socket enabled, yes, a connection to the socket would start
the service.
2) Would those services haven been listening before?
If you had enabled the service, sure. So, the rule of thumb would
be to enable the socket in the same situations where you would enable
the service, and disable the socket in the same situations where you'd
disable the service.
3) What is a good example that people can look at so we aren't
all
hand-wavy in this discussion about couldas and such. If we have
something that is the "way it should be" we can then measure against
it.
As an example, we have avahi-daemon.socket now. However, that socket is only
listening on the local socket in /run/avahi-daemon. So, if this socket was
enabled, a local request to avahi would activate the service, but a network
scan would not.
A different example is the current cups.socket. It listens on both the
local socket in /run/cups, and on port 631. So, in this case, a network
scan that hit TCP port 631 would activate cupsd.
In both cases, this behavior would require that the .socket file be enabled.
Bill
6:12 a.m.
On Mon, Aug 22, 2011 at 6:45 PM, Tom Callaway <tcallawa(a)redhat.com> wrote:
On 08/18/2011 06:28 AM, Lennart Poettering wrote:
> On Wed, 17.08.11 16:43, Tim Waugh (twaugh(a)redhat.com) wrote:
>
>> Oh, I just noticed this:
>>
>> https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activa...
>> "Since Fedora currently doesn't want any services to do on-demand
>> loading, all socket activated services must autostart."
>
> Uh, oh. I think CUPS is definitely something we should lazily socket
> activate instead of run it unconditionally.
>
> Spot, Bill, what's the reason for this wording in the guidelines? As
> CUPS is something we really should start only when needed, why do we
> have this wording in the guidelines? Can we relax this?
I think FESCo needs to decide what its policies are wrt on-demand
loading, then we can adjust the Packaging Guidelines appropriately.
This is broken IMO ... there is nothing inherently wrong with on
demand loading ... actually it is the opposite. (i.e should be done
whenever possible).
9:29 a.m.
On Tue, Aug 23, 2011 at 01:12:31PM +0200, drago01 wrote:
On Mon, Aug 22, 2011 at 6:45 PM, Tom Callaway
<tcallawa(a)redhat.com> wrote:
> On 08/18/2011 06:28 AM, Lennart Poettering wrote:
>> On Wed, 17.08.11 16:43, Tim Waugh (twaugh(a)redhat.com) wrote:
>>
>>> Oh, I just noticed this:
>>>
>>>
https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activa...
>>> "Since Fedora currently doesn't want any services to do on-demand
>>> loading, all socket activated services must autostart."
>>
>> Uh, oh. I think CUPS is definitely something we should lazily socket
>> activate instead of run it unconditionally.
>>
>> Spot, Bill, what's the reason for this wording in the guidelines? As
>> CUPS is something we really should start only when needed, why do we
>> have this wording in the guidelines? Can we relax this?
>
> I think FESCo needs to decide what its policies are wrt on-demand
> loading, then we can adjust the Packaging Guidelines appropriately.
This is broken IMO ... there is nothing inherently wrong with on
demand loading ... actually it is the opposite. (i.e should be done
whenever possible).
On demand loading is great. But the system administrator needs to have
control to be able to turn things on and off. So we need Lennart to give us
information on how to do that. Lennart also needs to give us information on
how to write .socket files. With those in hand, guidelines would and fesco
would be able to ship with on-demand-loading that was off by default (does
nt load at all) but the system administrator would be able to enable the
service so that it would start to load on-demand rather than at boot.
-Toshio
9:57 a.m.
On Tue, 23.08.11 07:29, Toshio Kuratomi (a.badger(a)gmail.com) wrote:
> > I think FESCo needs to decide what its policies are wrt
on-demand
> > loading, then we can adjust the Packaging Guidelines appropriately.
>
> This is broken IMO ... there is nothing inherently wrong with on
> demand loading ... actually it is the opposite. (i.e should be done
> whenever possible).
>
On demand loading is great. But the system administrator needs to have
control to be able to turn things on and off. So we need Lennart to give us
information on how to do that.
The same way as for services basically. [Install] sections are used for
all kinds of unit files, not just services.
Lennart also needs to give us information on how to write .socket
files.
This is probably more of an upstream issue. Writing unit files
downstream is probably not really needed, since socket activation needs
some kind of upstream support.
With those in hand, guidelines would and fesco
would be able to ship with on-demand-loading that was off by default (does
nt load at all) but the system administrator would be able to enable the
service so that it would start to load on-demand rather than at boot.
Hmm? Not sure I can parse your paragraph, but I think we really should
be loading seldom used services by default via socket/device activation,
not on boot. Examples for these services are SSH and CUPS.
I am pretty sure that 95% of everybody who has ssd or CUPS installed
will not use it more often than than 1/h, which is really seldom. Hence
I'd make these services socket activated by default (like MacOS does it
too), and for the 5% of machines which use it more often we make it easy
to spawn the daemons on boot. The default should be to make it nice for
95% of people. The 5% who want to run it unconditionally are probably
knowleadgable admins anyway.
Lennart
--
Lennart Poettering - Red Hat, Inc.
10:10 a.m.
On Tue, 2011-08-23 at 16:57 +0200, Lennart Poettering wrote:
On Tue, 23.08.11 07:29, Toshio Kuratomi (a.badger(a)gmail.com) wrote:
> > > I think FESCo needs to decide what its policies are wrt on-demand
> > > loading, then we can adjust the Packaging Guidelines appropriately.
> >
> > This is broken IMO ... there is nothing inherently wrong with on
> > demand loading ... actually it is the opposite. (i.e should be done
> > whenever possible).
> >
> On demand loading is great. But the system administrator needs to have
> control to be able to turn things on and off. So we need Lennart to give us
> information on how to do that.
The same way as for services basically. [Install] sections are used for
all kinds of unit files, not just services.
> Lennart also needs to give us information on how to write .socket
> files.
This is probably more of an upstream issue. Writing unit files
downstream is probably not really needed, since socket activation needs
some kind of upstream support.
> With those in hand, guidelines would and fesco
> would be able to ship with on-demand-loading that was off by default (does
> nt load at all) but the system administrator would be able to enable the
> service so that it would start to load on-demand rather than at boot.
Hmm? Not sure I can parse your paragraph, but I think we really should
be loading seldom used services by default via socket/device activation,
not on boot. Examples for these services are SSH and CUPS.
I am pretty sure that 95% of everybody who has ssd or CUPS installed
will not use it more often than than 1/h, which is really seldom. Hence
I'd make these services socket activated by default (like MacOS does it
too), and for the 5% of machines which use it more often we make it easy
to spawn the daemons on boot. The default should be to make it nice for
95% of people. The 5% who want to run it unconditionally are probably
knowleadgable admins anyway.
Any chance systemd upstream or Fedora at least will provide a
chkconfig-like tool that can give you a very simple intuitive way to
completely disable/enable/enable(forced on at boot)/etc... each service
in the system ?
Systemd unit files are cool and all, but they are also much more
difficult to keep track of for admins. With the previous system
chkconfig --list gave you an immediate *concise* clear view of the
system configuration wrt initialization. Something like that would
really be welcome for systemd. Esp when a service has multiple files
that need to be changed/unliked/linked at the same time. A tool like
that would also show/point out if an action breaks dependencies with a
verbose mode view or something.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
10:44 a.m.
On Tue, 23.08.11 11:10, Simo Sorce (simo(a)redhat.com) wrote:
> I am pretty sure that 95% of everybody who has ssd or CUPS
installed
> will not use it more often than than 1/h, which is really seldom. Hence
> I'd make these services socket activated by default (like MacOS does it
> too), and for the 5% of machines which use it more often we make it easy
> to spawn the daemons on boot. The default should be to make it nice for
> 95% of people. The 5% who want to run it unconditionally are probably
> knowleadgable admins anyway.
Any chance systemd upstream or Fedora at least will provide a
chkconfig-like tool that can give you a very simple intuitive way to
completely disable/enable/enable(forced on at boot)/etc... each service
in the system ?
systemctl enable
systemctl disable
systemctl mask
Systemd unit files are cool and all, but they are also much more
difficult to keep track of for admins. With the previous system
chkconfig --list gave you an immediate *concise* clear view of the
system configuration wrt initialization. Something like that would
really be welcome for systemd. Esp when a service has multiple files
that need to be changed/unliked/linked at the same time. A tool like
that would also show/point out if an action breaks dependencies with a
verbose mode view or something.
systemctl enable/disable will do the right thing for you, if the unit
files use Also= (which correctly written units do). For example,
"systemctl disable avahi-daemon.service" will also disable
"avahi-daemon.socket, since it is listed in Also= in the [Install]
section of it.
On F16 you can use "systemctl list-unit-files" to get a list of all
installed unit files with their status, whether they are enabled,
disabled, statically enabled or otherwise.
Lennart
--
Lennart Poettering - Red Hat, Inc.
10:56 a.m.
On Tue, 2011-08-23 at 17:44 +0200, Lennart Poettering wrote:
On Tue, 23.08.11 11:10, Simo Sorce (simo(a)redhat.com) wrote:
> > I am pretty sure that 95% of everybody who has ssd or CUPS installed
> > will not use it more often than than 1/h, which is really seldom. Hence
> > I'd make these services socket activated by default (like MacOS does it
> > too), and for the 5% of machines which use it more often we make it easy
> > to spawn the daemons on boot. The default should be to make it nice for
> > 95% of people. The 5% who want to run it unconditionally are probably
> > knowleadgable admins anyway.
>
> Any chance systemd upstream or Fedora at least will provide a
> chkconfig-like tool that can give you a very simple intuitive way to
> completely disable/enable/enable(forced on at boot)/etc... each service
> in the system ?
systemctl enable
systemctl disable
systemctl mask
No these do not give any simple and intuitive way to deal with systemd
complexities.
Just running 'systemctl' alone gives a list of a truckload of stuff ...
that is generally not really interesting from the pov of knowing what is
eanbled at startup or when.
It basically spits too much output, formats it strangely and gives
information that should be given in a verbose mode only (the
description) as it steals real estate unnecessarily.
> Systemd unit files are cool and all, but they are also much
more
> difficult to keep track of for admins. With the previous system
> chkconfig --list gave you an immediate *concise* clear view of the
> system configuration wrt initialization. Something like that would
> really be welcome for systemd. Esp when a service has multiple files
> that need to be changed/unliked/linked at the same time. A tool like
> that would also show/point out if an action breaks dependencies with a
> verbose mode view or something.
systemctl enable/disable will do the right thing for you, if the unit
files use Also= (which correctly written units do). For example,
"systemctl disable avahi-daemon.service" will also disable
"avahi-daemon.socket, since it is listed in Also= in the [Install]
section of it.
Yeah the enable/disable subcommands are not a problem, the problem is
getting a comprehensive view without having to parse a lot of details
with a single command like chckonfig --list used to do.
On F16 you can use "systemctl list-unit-files" to get a
list of all
installed unit files with their status, whether they are enabled,
disabled, statically enabled or otherwise.
Ok, I will check it out once I get an F16 install.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
11:14 a.m.
On Tue, 23.08.11 11:56, Simo Sorce (simo(a)redhat.com) wrote:
On Tue, 2011-08-23 at 17:44 +0200, Lennart Poettering wrote:
> On Tue, 23.08.11 11:10, Simo Sorce (simo(a)redhat.com) wrote:
>
> > > I am pretty sure that 95% of everybody who has ssd or CUPS installed
> > > will not use it more often than than 1/h, which is really seldom. Hence
> > > I'd make these services socket activated by default (like MacOS does
it
> > > too), and for the 5% of machines which use it more often we make it easy
> > > to spawn the daemons on boot. The default should be to make it nice for
> > > 95% of people. The 5% who want to run it unconditionally are probably
> > > knowleadgable admins anyway.
> >
> > Any chance systemd upstream or Fedora at least will provide a
> > chkconfig-like tool that can give you a very simple intuitive way to
> > completely disable/enable/enable(forced on at boot)/etc... each service
> > in the system ?
>
> systemctl enable
> systemctl disable
> systemctl mask
No these do not give any simple and intuitive way to deal with systemd
complexities.
Just running 'systemctl' alone gives a list of a truckload of stuff ...
that is generally not really interesting from the pov of knowing what is
eanbled at startup or when.
It basically spits too much output, formats it strangely and gives
information that should be given in a verbose mode only (the
description) as it steals real estate unnecessarily.
Hmm? "systemctl enable" usually spits out very little info at all.
Are you referring to "systemctl" without any arguments? That' list you
runtime information about services that are running, or failed.
> > Systemd unit files are cool and all, but they are also much
more
> > difficult to keep track of for admins. With the previous system
> > chkconfig --list gave you an immediate *concise* clear view of the
> > system configuration wrt initialization. Something like that would
> > really be welcome for systemd. Esp when a service has multiple files
> > that need to be changed/unliked/linked at the same time. A tool like
> > that would also show/point out if an action breaks dependencies with a
> > verbose mode view or something.
>
> systemctl enable/disable will do the right thing for you, if the unit
> files use Also= (which correctly written units do). For example,
> "systemctl disable avahi-daemon.service" will also disable
> "avahi-daemon.socket, since it is listed in Also= in the [Install]
> section of it.
Yeah the enable/disable subcommands are not a problem, the problem is
getting a comprehensive view without having to parse a lot of details
with a single command like chckonfig --list used to do.
systemctl list-unit-files is what you are looking for. It's simpler even
than chkconfig --list.
Lennart
--
Lennart Poettering - Red Hat, Inc.
11:33 a.m.
On Tue, 2011-08-23 at 18:14 +0200, Lennart Poettering wrote:
On Tue, 23.08.11 11:56, Simo Sorce (simo(a)redhat.com) wrote:
>
> On Tue, 2011-08-23 at 17:44 +0200, Lennart Poettering wrote:
> > On Tue, 23.08.11 11:10, Simo Sorce (simo(a)redhat.com) wrote:
> >
> > > > I am pretty sure that 95% of everybody who has ssd or CUPS installed
> > > > will not use it more often than than 1/h, which is really seldom.
Hence
> > > > I'd make these services socket activated by default (like MacOS
does it
> > > > too), and for the 5% of machines which use it more often we make it
easy
> > > > to spawn the daemons on boot. The default should be to make it nice
for
> > > > 95% of people. The 5% who want to run it unconditionally are
probably
> > > > knowleadgable admins anyway.
> > >
> > > Any chance systemd upstream or Fedora at least will provide a
> > > chkconfig-like tool that can give you a very simple intuitive way to
> > > completely disable/enable/enable(forced on at boot)/etc... each service
> > > in the system ?
> >
> > systemctl enable
> > systemctl disable
> > systemctl mask
>
> No these do not give any simple and intuitive way to deal with systemd
> complexities.
> Just running 'systemctl' alone gives a list of a truckload of stuff ...
> that is generally not really interesting from the pov of knowing what is
> eanbled at startup or when.
>
> It basically spits too much output, formats it strangely and gives
> information that should be given in a verbose mode only (the
> description) as it steals real estate unnecessarily.
Hmm? "systemctl enable" usually spits out very little info at all.
Are you referring to "systemctl" without any arguments? That' list you
runtime information about services that are running, or failed.
Yeah read above: "> Just running 'systemctl' alone ..."
> > > Systemd unit files are cool and all, but they are also
much more
> > > difficult to keep track of for admins. With the previous system
> > > chkconfig --list gave you an immediate *concise* clear view of the
> > > system configuration wrt initialization. Something like that would
> > > really be welcome for systemd. Esp when a service has multiple files
> > > that need to be changed/unliked/linked at the same time. A tool like
> > > that would also show/point out if an action breaks dependencies with a
> > > verbose mode view or something.
> >
> > systemctl enable/disable will do the right thing for you, if the unit
> > files use Also= (which correctly written units do). For example,
> > "systemctl disable avahi-daemon.service" will also disable
> > "avahi-daemon.socket, since it is listed in Also= in the [Install]
> > section of it.
>
> Yeah the enable/disable subcommands are not a problem, the problem is
> getting a comprehensive view without having to parse a lot of details
> with a single command like chckonfig --list used to do.
systemctl list-unit-files is what you are looking for. It's simpler even
than chkconfig --list.
Perfect,
thanks!
Simo.
--
Simo Sorce * Red Hat, Inc * New York
12:40 p.m.
On Tue, Aug 23, 2011 at 06:14:34PM +0200, Lennart Poettering wrote:
systemctl list-unit-files is what you are looking for. It's simpler even
than chkconfig --list.
When I run "systemctl list-unit-files", I get a "Unknown operation
list-unit-files" error. Did you mean "systemctl list-units"?
--
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868
12:50 p.m.
On Wed, 24.08.11 11:40, Andrew McNabb (amcnabb(a)mcnabbs.org) wrote:
On Tue, Aug 23, 2011 at 06:14:34PM +0200, Lennart Poettering wrote:
>
> systemctl list-unit-files is what you are looking for. It's simpler even
> than chkconfig --list.
When I run "systemctl list-unit-files", I get a "Unknown operation
list-unit-files" error. Did you mean "systemctl list-units"?
As mentioned in the mail "list-unit-files" is only availablein F16.
Lennart
--
Lennart Poettering - Red Hat, Inc.
11:56 a.m.
On Tue, 2011-08-23 at 07:29 -0700, Toshio Kuratomi wrote:
> This is broken IMO ... there is nothing inherently wrong with
on
> demand loading ... actually it is the opposite. (i.e should be done
> whenever possible).
>
On demand loading is great. But the system administrator needs to have
control to be able to turn things on and off. So we need Lennart to give us
information on how to do that.
I believe this has already been explained several times: if you
*disable* a service, rather than *stopping* it, socket activation won't
happen until you re-enable it. It's only if you just stop a service that
socket activation will happily start it back up again. This is the
'three levels of 'off'' stuff, IIRC.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
1:34 p.m.
Adam Williamson <awilliam <at> redhat.com> writes:
On Tue, 2011-08-23 at 07:29 -0700, Toshio Kuratomi wrote:
> > This is broken IMO ... there is nothing inherently wrong with on
> > demand loading ... actually it is the opposite. (i.e should be done
> > whenever possible).
> >
> On demand loading is great. But the system administrator needs to have
> control to be able to turn things on and off. So we need Lennart to give us
> information on how to do that.
I believe this has already been explained several times: if you
*disable* a service, rather than *stopping* it, socket activation won't
happen until you re-enable it.
It's only if you just stop a service that
socket activation will happily start it back up again. This is the
'three levels of 'off'' stuff, IIRC.
I would say this is not a good idea with how "stop" works.
I usually stop a service for a reason. Perhaps I follow it up with
a reconfiguration or do other related work. I would not want it be started
during that time by systemd's "magic".
JB
3:04 p.m.
On Tue, Aug 23, 2011 at 4:29 PM, Toshio Kuratomi <a.badger(a)gmail.com> wrote:
On Tue, Aug 23, 2011 at 01:12:31PM +0200, drago01 wrote:
> On Mon, Aug 22, 2011 at 6:45 PM, Tom Callaway <tcallawa(a)redhat.com> wrote:
> > On 08/18/2011 06:28 AM, Lennart Poettering wrote:
> >> On Wed, 17.08.11 16:43, Tim Waugh (twaugh(a)redhat.com) wrote:
> >>
> >>> Oh, I just noticed this:
> >>>
> >>>
https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activa...
> >>> "Since Fedora currently doesn't want any services to do
on-demand
> >>> loading, all socket activated services must autostart."
> >>
> >> Uh, oh. I think CUPS is definitely something we should lazily socket
> >> activate instead of run it unconditionally.
> >>
> >> Spot, Bill, what's the reason for this wording in the guidelines? As
> >> CUPS is something we really should start only when needed, why do we
> >> have this wording in the guidelines? Can we relax this?
> >
> > I think FESCo needs to decide what its policies are wrt on-demand
> > loading, then we can adjust the Packaging Guidelines appropriately.
>
> This is broken IMO ... there is nothing inherently wrong with on
> demand loading ... actually it is the opposite. (i.e should be done
> whenever possible).
>
On demand loading is great. But the system administrator needs to have
control to be able to turn things on and off.
Which has nothing to do with on demand loading. (It does not mean
"start random stuff regardless of configuration").
It is just about *when* to start things not *if* they are started at all.
9:50 p.m.
Tim Waugh wrote:
Oh, I just noticed this:
https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activa...
"Since Fedora currently doesn't want any services to do on-demand
loading, all socket activated services must autostart."
What the heck?! We're disabling systemd's main feature there, aren't we?
Wasn't the main design concept behind systemd the observation that
everything can be parallelized most effectively by on-demand activation?
Kevin Kofler
4:06 a.m.
Am 20.08.2011 04:50, schrieb Kevin Kofler:
Tim Waugh wrote:
> Oh, I just noticed this:
>
> https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activa...
> "Since Fedora currently doesn't want any services to do on-demand
> loading, all socket activated services must autostart."
What the heck?! We're disabling systemd's main feature there, aren't we?
Wasn't the main design concept behind systemd the observation that
everything can be parallelized most effectively by on-demand activation?
Kevin Kofler
Mhh - See also here
https://bugzilla.redhat.com/show_bug.cgi?id=714426
The mysqld problems would be solved by socket-activation
whoever dcided that socket-activation is not wanted should recognize
that he ha sno technical qualification to decide anything and si forcong
maintainers to play around with wait-tricks for services like mysqld - IDIOTIC
again:
systemd in F15 has not a single benfit for anybody, is making only troubles
which are MAYBE solved in F16 or F17 or even F18
8:41 a.m.
On Friday, August 19, 2011 10:50:01 PM Kevin Kofler wrote:
Tim Waugh wrote:
> Oh, I just noticed this:
>
> https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activa
> tion "Since Fedora currently doesn't want any services to do on-demand
> loading, all socket activated services must autostart."
What the heck?! We're disabling systemd's main feature there, aren't we?
Wasn't the main design concept behind systemd the observation that
everything can be parallelized most effectively by on-demand activation?
Why is bootup speed so important that init now has become network aware? Process 1
gets special protection from the kernel. You cannot kill it. If there is any mistake
in its code, then you have an unkillable all powerful process that might do rogue
things. It almost sounds like this is reinventing Xinetd - except its not as feature
rich as xinetd.
We had a lot of problems with xinetd over the years. For example, if it listens for a
connection that the service must accept and then the service fails before it can call
accept, xinetd will spin in a tight loop because the the listen socket is readable and
the service is not calling accept.
Then lets look at the accept option. If systemd accepts a connection and passes it to
a child process, do you now support tcp_wrappers so that you deny the connection
before starting the child? That would mean any flaw in tcp_wrappers now is part of
process 1 which has special protection from the kernel. How do you limit the number of
children? Xinetd grew all these features because of security problems. Xinetd had many
bugs because of these features.
I personally think systemd's configure should have an --enable-networking. I think
this
should be turned off. A network aware init could be internet worm material since you
cannot kill process 1.
-Steve
1:17 p.m.
On Sat, 20.08.11 09:41, Steve Grubb (sgrubb(a)redhat.com) wrote:
On Friday, August 19, 2011 10:50:01 PM Kevin Kofler wrote:
> Tim Waugh wrote:
> > Oh, I just noticed this:
> >
> > https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activa
> > tion "Since Fedora currently doesn't want any services to do
on-demand
> > loading, all socket activated services must autostart."
>
> What the heck?! We're disabling systemd's main feature there, aren't
we?
> Wasn't the main design concept behind systemd the observation that
> everything can be parallelized most effectively by on-demand activation?
Why is bootup speed so important that init now has become network aware? Process 1
gets special protection from the kernel. You cannot kill it. If there is any mistake
in its code, then you have an unkillable all powerful process that might do rogue
things. It almost sounds like this is reinventing Xinetd - except its not as feature
rich as xinetd.
systemd never reads a single packet from any of the network sockets it
listens on on behalf of services. It just passes these sockets off to
the services as soon as traffic is seen on them (i.e. when POLLIN is
triggered we pass off the socket, we don't call read() on it.)
We had a lot of problems with xinetd over the years. For example, if
it listens for a
connection that the service must accept and then the service fails before it can call
accept, xinetd will spin in a tight loop because the the listen socket is readable and
the service is not calling accept.
systemd (much like sysvinit) rate limits service start-up. If a service
respawns too often we will refuse starting it again for a while.
Then lets look at the accept option. If systemd accepts a connection
and passes it to
a child process, do you now support tcp_wrappers so that you deny the connection
before starting the child?
We do tcpwrap checks for incoming connections. I do wonder though
whether it might be time to deprecate tcpwrap distribution-wide. I am
pretty sure firewalls are the better approach, more widely supported,
more widely understood and more widely used.
That would mean any flaw in tcp_wrappers now is part of process 1
which has special protection from the kernel.
We are very careful with what we execute in PID 1. For example we make
sure not to do any NSS lookups or use other code that might pull in
arbitrary libraries into PID 1. And following this logic I carefully
made sure that tcpwrap checks are not done in PID 1, but in the forked
off process shortly before we execute the process binary.
And anyway, I wouldn't overestimate the risk here. tcpwrap does not read
from the socket, it just executes syscalls like getsockname() and
getpeername() and suchlike, but does not parse potentially dangerous
network traffic.
How do you limit the number of
children?
There's an option for that: MaxConnections=. It defaults to 64.
I personally think systemd's configure should have an
--enable-networking. I think this
should be turned off. A network aware init could be internet worm material since you
cannot kill process 1.
Please read up on socket activation before making such broad comments.
http://0pointer.de/blog/projects/systemd.html
Read the part about "Parallelizing Socket Services". It explains why
socket actviation is interesting, and why systemd's focus is (much
unlike inetd) on AF_UNIX sockets here, not AF_INET sockets. And why
the parallelization enables us to do is what matters, and not so much the
lazy loading.
And again, systemd never reads from the sockets it listens on on behalf
of services. It just waits for POLLIN and then passes them off. In fact,
the way most modern socket activatable services are written systemd
doesn't even call accept() ever, but passes the listening socket off
(instead of the connection socket). In this common case tcpwrap isn't
invoked by systemd code either. systemd has no network parsing code. And
even NSS code (which might potentially parse network packets) is always
done out-of-process, never from PID 1.
Lennart
--
Lennart Poettering - Red Hat, Inc.
2:31 p.m.
On Saturday, August 20, 2011 02:17:04 PM Lennart Poettering wrote:
On Sat, 20.08.11 09:41, Steve Grubb (sgrubb(a)redhat.com) wrote:
> On Friday, August 19, 2011 10:50:01 PM Kevin Kofler wrote:
> > Tim Waugh wrote:
> > > Oh, I just noticed this:
> > >
> > > https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_ac
> > > tiva tion "Since Fedora currently doesn't want any services to
do
> > > on-demand loading, all socket activated services must autostart."
> >
> > What the heck?! We're disabling systemd's main feature there,
aren't
> > we? Wasn't the main design concept behind systemd the observation that
> > everything can be parallelized most effectively by on-demand
> > activation?
>
> Why is bootup speed so important that init now has become network aware?
> Process 1 gets special protection from the kernel. You cannot kill it.
> If there is any mistake in its code, then you have an unkillable all
> powerful process that might do rogue things. It almost sounds like this
> is reinventing Xinetd - except its not as feature rich as xinetd.
systemd never reads a single packet from any of the network sockets it
listens on on behalf of services. It just passes these sockets off to
the services as soon as traffic is seen on them (i.e. when POLLIN is
triggered we pass off the socket, we don't call read() on it.)
And therein lies one of the big problems that xinetd has. If its listening and passes
the descriptor to a child to accept and the child crashes or aborts before accepting
the socket, the whole mess spins in a circle where the listen descriptor is readable,
but nothing is accepting the connection.
But still, why is speed so important that xinetd capabilities are the answer? Why not
leave init not network aware and let xinetd do the on demand startup? This has the
advantage of being able to kill xinetd whereas init cannot be killed.
> Then lets look at the accept option. If systemd accepts a
connection and
> passes it to a child process, do you now support tcp_wrappers so that
> you deny the connection before starting the child?
We do tcpwrap checks for incoming connections. I do wonder though
whether it might be time to deprecate tcpwrap distribution-wide. I am
pretty sure firewalls are the better approach, more widely supported,
more widely understood and more widely used.
Do you remember the hole in netfilter a while back?
CVE-2001-1572
CVE-2006-4572
Its happened before and it will happen again. I'm sure this list is not complete.
Then some tools that help setup the firewall might accidentally leave you open:
CVE-2003-0080
Belt and suspenders! Must have both.
> That would mean any flaw in tcp_wrappers now is part of process
1
> which has special protection from the kernel.
We are very careful with what we execute in PID 1. For example we make
sure not to do any NSS lookups or use other code that might pull in
arbitrary libraries into PID 1. And following this logic I carefully
made sure that tcpwrap checks are not done in PID 1, but in the forked
off process shortly before we execute the process binary.
And anyway, I wouldn't overestimate the risk here. tcpwrap does not read
from the socket, it just executes syscalls like getsockname() and
getpeername() and suchlike, but does not parse potentially dangerous
network traffic.
I wrote lots of patches for tcp_wrappers, mostly to give it ipv6 capabilities. But
there were bugs fixed. For example, it provides many functions with names that are in
glibc. Which means you might get tcp_wrapper's implementation rather than glibc's.
My
version was called socket_wrappers and it fixed a whole lot of the problems in
tcp_wrapper. So, even if you fork with the intention of not using its code in process
1, you might accidentally be using it.
readelf -s /lib64/libwrap.so.0.7.6 | grep FUNC | grep -v UND
Looks like someone has been doing some cleanining up, but maybe not that way on other
distros.
But anyways, tcp_wrapper does reverse DNS lookups to compare the forward and reverse
paths in case anyone has tampered with the remote DNS to make it look like the
incoming connection is legit. So, may it does not read much off the socket, its does a
recvfrom peek, but it does talk with remote DNS servers to make a decision. Not all
DNS servers are legit and can be malicious. One incoming packet can cause a cascade of
outgoing DNS querries.
> I personally think systemd's configure should have an
> --enable-networking. I think this should be turned off. A network aware
> init could be internet worm material since you cannot kill process 1.
Please read up on socket activation before making such broad comments.
I feel very comfortable in saying that if you increase the attack surface of an
unkillable and all powerful process, someone will notice this and find the hole one day
and it might not even be in your code. You may do everything perfect and there is one
hole in a library that is the undoing of the system. The difference is an IPS system
can reach out and kill a normal inetd daemon...but not if its init.
http://0pointer.de/blog/projects/systemd.html
Read the part about "Parallelizing Socket Services". It explains why
socket actviation is interesting,
I find a secure OS interesting. Bootup speed does not matter much to me.
-Steve
4:09 p.m.
On 08/20/2011 03:31 PM, Steve Grubb wrote:
On Saturday, August 20, 2011 02:17:04 PM Lennart Poettering wrote:
> On Sat, 20.08.11 09:41, Steve Grubb (sgrubb(a)redhat.com) wrote:
>> On Friday, August 19, 2011 10:50:01 PM Kevin Kofler wrote:
>>> Tim Waugh wrote:
>>>> Oh, I just noticed this:
>>>>
>>>> https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_ac
>>>> tiva tion "Since Fedora currently doesn't want any services to
do
>>>> on-demand loading, all socket activated services must autostart."
>>> What the heck?! We're disabling systemd's main feature there,
aren't
>>> we? Wasn't the main design concept behind systemd the observation that
>>> everything can be parallelized most effectively by on-demand
>>> activation?
>> Why is bootup speed so important that init now has become network aware?
>> Process 1 gets special protection from the kernel. You cannot kill it.
>> If there is any mistake in its code, then you have an unkillable all
>> powerful process that might do rogue things. It almost sounds like this
>> is reinventing Xinetd - except its not as feature rich as xinetd.
> systemd never reads a single packet from any of the network sockets it
> listens on on behalf of services. It just passes these sockets off to
> the services as soon as traffic is seen on them (i.e. when POLLIN is
> triggered we pass off the socket, we don't call read() on it.)
And therein lies one of the big problems that xinetd has. If its listening and passes
the descriptor to a child to accept and the child crashes or aborts before accepting
the socket, the whole mess spins in a circle where the listen descriptor is readable,
but nothing is accepting the connection.
But still, why is speed so important that xinetd capabilities are the answer? Why not
leave init not network aware and let xinetd do the on demand startup? This has the
advantage of being able to kill xinetd whereas init cannot be killed.
>> Then lets look at the accept option. If systemd accepts a connection and
>> passes it to a child process, do you now support tcp_wrappers so that
>> you deny the connection before starting the child?
> We do tcpwrap checks for incoming connections. I do wonder though
> whether it might be time to deprecate tcpwrap distribution-wide. I am
> pretty sure firewalls are the better approach, more widely supported,
> more widely understood and more widely used.
Do you remember the hole in netfilter a while back?
CVE-2001-1572
CVE-2006-4572
Its happened before and it will happen again. I'm sure this list is not complete.
Then some tools that help setup the firewall might accidentally leave you open:
CVE-2003-0080
Belt and suspenders! Must have both.
>> That would mean any flaw in tcp_wrappers now is part of process 1
>> which has special protection from the kernel.
> We are very careful with what we execute in PID 1. For example we make
> sure not to do any NSS lookups or use other code that might pull in
> arbitrary libraries into PID 1. And following this logic I carefully
> made sure that tcpwrap checks are not done in PID 1, but in the forked
> off process shortly before we execute the process binary.
>
> And anyway, I wouldn't overestimate the risk here. tcpwrap does not read
> from the socket, it just executes syscalls like getsockname() and
> getpeername() and suchlike, but does not parse potentially dangerous
> network traffic.
I wrote lots of patches for tcp_wrappers, mostly to give it ipv6 capabilities. But
there were bugs fixed. For example, it provides many functions with names that are in
glibc. Which means you might get tcp_wrapper's implementation rather than
glibc's. My
version was called socket_wrappers and it fixed a whole lot of the problems in
tcp_wrapper. So, even if you fork with the intention of not using its code in process
1, you might accidentally be using it.
readelf -s /lib64/libwrap.so.0.7.6 | grep FUNC | grep -v UND
Looks like someone has been doing some cleanining up, but maybe not that way on other
distros.
But anyways, tcp_wrapper does reverse DNS lookups to compare the forward and reverse
paths in case anyone has tampered with the remote DNS to make it look like the
incoming connection is legit. So, may it does not read much off the socket, its does a
recvfrom peek, but it does talk with remote DNS servers to make a decision. Not all
DNS servers are legit and can be malicious. One incoming packet can cause a cascade of
outgoing DNS querries.
>> I personally think systemd's configure should have an
>> --enable-networking. I think this should be turned off. A network aware
>> init could be internet worm material since you cannot kill process 1.
> Please read up on socket activation before making such broad comments.
I feel very comfortable in saying that if you increase the attack surface of an
unkillable and all powerful process, someone will notice this and find the hole one day
and it might not even be in your code. You may do everything perfect and there is one
hole in a library that is the undoing of the system. The difference is an IPS system
can reach out and kill a normal inetd daemon...but not if its init.
> http://0pointer.de/blog/projects/systemd.html
>
> Read the part about "Parallelizing Socket Services". It explains why
> socket actviation is interesting,
I find a secure OS interesting. Bootup speed does not matter much to me.
-Steve
Obviously a lot on this list value boot up speed over security!
--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark(a)netwolves.com
http://www.netwolves.com
4:22 p.m.
On 08/21/2011 05:09 PM, Steve Clark wrote:
>> http://0pointer.de/blog/projects/systemd.html
>>
>> Read the part about "Parallelizing Socket Services". It explains why
>> socket actviation is interesting,
> I find a secure OS interesting. Bootup speed does not matter much to me.
>
> -Steve
Obviously a lot on this list value boot up speed over security!
Obviously, anyone who values security over bootup speed has the right
values.
I share those values as should everyone who is clueful :-)
6:54 p.m.
On Sunday, August 21, 2011 05:22:17 PM Genes MailLists wrote:
On 08/21/2011 05:09 PM, Steve Clark wrote:
>>> http://0pointer.de/blog/projects/systemd.html
>>>
>>> Read the part about "Parallelizing Socket Services". It explains
why
>>> socket actviation is interesting,
>>
>> I find a secure OS interesting. Bootup speed does not matter much to me.
>
> Obviously a lot on this list value boot up speed over security!
Obviously, anyone who values security over bootup speed has the right
values.
I share those values as should everyone who is clueful :-)
The thing I think about is that is if the solution for parallelizing boot is an xinetd
replacement, was there any thought to just patching xinetd? As a former upstream
maintainer (and former because its not actively developed nor passed along to another
caretaker), we would have taken patches that added AF_UNIX or dbus activation if we
understood the need. As proof, Rob added rendezvous support before it went into its
unmaintained state. Imagine an updated xinetd + upstart. Would that not solve the
problems, cause less turmoil, and be more secure?
-Steve
7:01 p.m.
On 08/22/2011 05:24 AM, Steve Grubb wrote:
Imagine an updated xinetd + upstart. Would that not solve the
problems, cause less turmoil, and be more secure? -Steve
How? Fedora has talked about moving to systemd much before the Fedora
14 release. It was postponed to Fedora 15, has become the default in
that release and we have already migrated dozens and dozens of services
and we are nearing the Fedora 16 Alpha release shortly and aiming for
100% conversion by the general release. How is moving *back* now to
upstart going to be less turmoil? I understand that you are busy and
paying attention to this matter only now but I can't consider this as a
serious proposal.
Rahul
7:34 p.m.
On Sunday, August 21, 2011 08:01:33 PM Rahul Sundaram wrote:
On 08/22/2011 05:24 AM, Steve Grubb wrote:
> Imagine an updated xinetd + upstart. Would that not solve the
> problems, cause less turmoil, and be more secure?
How? Fedora has talked about moving to systemd much before the Fedora
14 release.
Sorry, I was very busy at the time. I am just beginning to look to the future and what
might be coming my way for RHEL7 common criteria. I have a hard time with systemd
being network aware. The requirements going into RHEL7 will likely be meeting what was
known as GPOSPP which includes requirements for a minimal Intrusion Prevention System.
Its also a harder protection profile than we have ever met. With init performing an
xinetd role, I can't see how I am to kill it when it goes rogue.
It was postponed to Fedora 15, has become the default in that release
and we have
already migrated dozens and dozens of services and we are nearing the Fedora 16
Alpha release shortly and aiming for 100% conversion by the general release.
I know. I added support in our audit package, but not upstream. I am not convinced yet
this is a sound design. How many major throw away subsystems have we seen over the
years? The code may be perfectly implemented. But do we really want to design systems
with a new, expanded attack surface? This is a design problem that is more secure as
separate processes. (Going from sysvinit to upstart was no problem because the attack
surface change is minimal.)
How is moving *back* now to upstart going to be less turmoil?
You're not seeing the hundreds - no thousands of emails about systemd? You are not
seeing that all the expected facilities of init are not covered? There is well founded
rebellion here. How do I see all targets on a system? List all services
enabled/disabled for each target in one shot? Chkconfig is not perfect, but its a
trusted friend. Also, not preparing for both server/desktop targets at a minimum seems
problematic in my opinion.
I understand that you are busy and paying attention to this matter
only now but I
can't consider this as a serious proposal.
I am wondering if it was ever considered to give xinetd a makeover? I bet the coding
would have been done in 2-3 weeks tops.
-Steve
10:10 p.m.
On 08/22/2011 06:04 AM, Steve Grubb wrote
Sorry, I was very busy at the time. I am just beginning to look to
the future and what
might be coming my way for RHEL7 common criteria.
It is ok to be busy but when you are busy, decisions will be made
without your input. You can't complain about having to do more work now
as a end result when you weren't participating all along for over a year
when you had a chance to be involved. You can't expect to come in at
this late stage and reverse decisions made without very significant
reasons. Common criteria requirements don't drive community decisions
in Fedora otherwise.
You're not seeing the hundreds - no thousands of emails about systemd? You are not
seeing that all the expected facilities of init are not covered? There is well founded
rebellion here. How do I see all targets on a system? List all services
enabled/disabled for each target in one shot? Chkconfig is not perfect, but its a
trusted friend. Also, not preparing for both server/desktop targets at a minimum seems
problematic in my opinion.
I am pretty sure I read more of Fedora discussions than practically
everyone in the Fedora world. I have seen such discussions regarding
every major change in Fedora. SELinux, NetworkManager, PulseAudio,
KDE 4, GNOME 3 - you name it. Decisions on such matters are done via
FESCo which in turn is a elected body representing Fedora contributors
and as contributors, we get to decide what Fedora should be. We must
take feedback into account however and since I am cc'ed on all bug
reports on systemd, I am well aware of how rapidly changes are being
made. Read the documentation on the changes and if you find missing
features, feel free to file them.
> I understand that you are busy and paying attention to this matter only now but I
> can't consider this as a serious proposal.
I am wondering if it was ever considered to give xinetd a makeover? I bet the coding
would have been done in 2-3 weeks tops.
Maybe but Lennart followed the feature process and got the changes in.
If you are serious about your proposal, you are welcome to do the same.
https://fedoraproject.org/wiki/Features/Policy
I don't see how it is going to fly however.
Rahul
11:03 a.m.
Steve Grubb <sgrubb <at> redhat.com> writes:
...
You're not seeing the hundreds - no thousands of emails about systemd?
You are not seeing that all the expected facilities of init are not covered?
There is well founded rebellion here.
...
Yes, you are right. And the people (e-mails, posts) you refer to are too.
Your concerns and those of others point to a questionable (non-UNIX) systemd
design.
Once again I refer everybody to Denys Vlasenko's thread, where this is very
visible; go over it again and you will know why:
http://lists.fedoraproject.org/pipermail/devel/2011-June/152323.html
Sys init was, and should be (as it was expected to be in systemd):
- simple, limited-in-functions, stable, and thus secure in design
- no sys init *and* services manager roles (the last one should be done by
another (child) process and inetd-like server)
- no networking exposure due to security concerns
- no pseudo-roles like handling user sessions, login's, etc
- etc
It is not by chance that people think about a Windows-like approach in concept
and design of systemd, and even Lennart admitted to it:
"I like to see it as a modular platform to build an OS from."
It comes thru, he wants systemd, with its implied "world domination" attitude,
to be a base for some OS-to-be; he even expects it to be some kind of
a standard every distro would adopt.
I can only say I hope not !
I would suggest that Fedora will be first to reject it as it is now.
Fedora is a BETA distro by choice, so it should be easy, prudent, and proper
to stop here and redesign systemd, with community, users and testers input.
A propos, I have here a few links to sources on UNIX philosophy.
I would suggest to everybody to not just read them (skip over them quickly),
but also think for a few minutes about each principle.
It helps clear up one's mind.
http://en.wikipedia.org/wiki/Unix_philosophy
Eric Steven Raymond
The Art of Unix Programming
http://www.catb.org/esr/writings/taoup/
http://www.catb.org/esr/writings/taoup/html/
The Unix Philosophy
http://www.linuxjournal.com/article/2877
Enjoy it.
JB
Vivaldi - Da due venti il mar turbato - Angela Gheorghiu - 1987 (Very Rare!)
http://www.youtube.com/watch?gl=US&v=8_MtYYCuFjk
12:25 p.m.
On 08/22/2011 12:03 PM, JB wrote:
Steve Grubb<sgrubb<at> redhat.com> writes:
> ...
> You're not seeing the hundreds - no thousands of emails about systemd?
> You are not seeing that all the expected facilities of init are not covered?
> There is well founded rebellion here.
> ...
Yes, you are right. And the people (e-mails, posts) you refer to are too.
Your concerns and those of others point to a questionable (non-UNIX) systemd
design.
Once again I refer everybody to Denys Vlasenko's thread, where this is very
visible; go over it again and you will know why:
http://lists.fedoraproject.org/pipermail/devel/2011-June/152323.html
Sys init was, and should be (as it was expected to be in systemd):
- simple, limited-in-functions, stable, and thus secure in design
- no sys init *and* services manager roles (the last one should be done by
another (child) process and inetd-like server)
- no networking exposure due to security concerns
- no pseudo-roles like handling user sessions, login's, etc
- etc
It is not by chance that people think about a Windows-like approach in concept
and design of systemd, and even Lennart admitted to it:
"I like to see it as a modular platform to build an OS from."
It comes thru, he wants systemd, with its implied "world domination" attitude,
to be a base for some OS-to-be; he even expects it to be some kind of
a standard every distro would adopt.
I can only say I hope not !
I would suggest that Fedora will be first to reject it as it is now.
Fedora is a BETA distro by choice, so it should be easy, prudent, and proper
to stop here and redesign systemd, with community, users and testers input.
A propos, I have here a few links to sources on UNIX philosophy.
I would suggest to everybody to not just read them (skip over them quickly),
but also think for a few minutes about each principle.
It helps clear up one's mind.
http://en.wikipedia.org/wiki/Unix_philosophy
Eric Steven Raymond
The Art of Unix Programming
http://www.catb.org/esr/writings/taoup/
http://www.catb.org/esr/writings/taoup/html/
The Unix Philosophy
http://www.linuxjournal.com/article/2877
Enjoy it.
JB
Vivaldi - Da due venti il mar turbato - Angela Gheorghiu - 1987 (Very Rare!)
http://www.youtube.com/watch?gl=US&v=8_MtYYCuFjk
+1000
--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark(a)netwolves.com
http://www.netwolves.com
12:48 p.m.
JB <jb.1234abcd <at> gmail.com> writes:
...
Here are some more detailed thoughts.
Sys init.
---------
Sys init as a process #1 should be "beyond approach" by design, and delegate
all work to other process(es), whether in a permanent or an ad-hoc manner,
that can be operated by sysadmin if needed (e.g. restarted, initialized,
configured, fixed, etc).
We want it to be minimal in its size, minimal in its functions, simple,
stable, secure (no attack venues, direct or indirect) - yes,
"beyond approach".
Sockets activation and on-demand services.
------------------------------------------
Here is a description of how it works:
http://0pointer.de/blog/projects/socket-activation.html
The essense begins here:
"Socket activation makes it possible to start all (...) services completely
simultaneously, without any kind of ordering.
...
That means the scheduling of our services is entirely done by the kernel: ,,,"
Then it continues:
"But it's not just about parallelization. It offers a number of other
benefits:
...
We no longer need to configure dependencies explicitly. Since the sockets
are initialized before all services they are simply available ...
If a service dies its listening socket stays around, not losing a single
message. After a restart of the crashed service it can continue right where
it left off.
..."
Well, it looks like a "wunderwaffe" :-)
Systemd and security - an example # 2 of an attack venue.
---------------------------------------------------------
The above is dangerous as a design idea to achieve "parallelization" of
services.
Let's assume that service A is a dependency for service B (and others).
After A's on-demand socket has been put "on hold" (blocking), the A may die
or lock up for any reason, that is never to come up again by itself as
an active service.
That means there is a system lock-up possibility here while B (and others) are
"on hold" too (waiting for A to be unblocked), and wait ..., and wait ...
Systemd and security - an example # 1 of an attack venue.
---------------------------------------------------------
Here is a possible known example:
http://www.securiteam.com/unixfocus/6U00P1PEVQ.html
We know that systemd owns the service socket-in-waiting (with its buffer).
In case of an attack on socket buffer availability via kernel the systemd is
grounded as well.
This should not be allowed to happen to process #1, the Mother of All
Processes.
One more reason to redesign the systemd to be minimal and "beyond approach",
and instead have other restartable "child" process(es) take over the function
of on-demand socket handling.
Can you comment on that ?
JB
http://news.icanhascheezburger.com/2010/06/22/political-pictures-make-a-w...
1:03 p.m.
On 08/23/2011 01:48 PM, JB wrote:
JB<jb.1234abcd<at> gmail.com> writes:
> ...
Here are some more detailed thoughts.
Sys init.
---------
Sys init as a process #1 should be "beyond approach" by design, and delegate
all work to other process(es), whether in a permanent or an ad-hoc manner,
that can be operated by sysadmin if needed (e.g. restarted, initialized,
configured, fixed, etc).
We want it to be minimal in its size, minimal in its functions, simple,
stable, secure (no attack venues, direct or indirect) - yes,
"beyond approach".
Sockets activation and on-demand services.
------------------------------------------
Here is a description of how it works:
http://0pointer.de/blog/projects/socket-activation.html
The essense begins here:
"Socket activation makes it possible to start all (...) services completely
simultaneously, without any kind of ordering.
...
That means the scheduling of our services is entirely done by the kernel: ,,,"
Then it continues:
"But it's not just about parallelization. It offers a number of other
benefits:
...
We no longer need to configure dependencies explicitly. Since the sockets
are initialized before all services they are simply available ...
If a service dies its listening socket stays around, not losing a single
message. After a restart of the crashed service it can continue right where
it left off.
..."
Well, it looks like a "wunderwaffe" :-)
Systemd and security - an example # 2 of an attack venue.
---------------------------------------------------------
The above is dangerous as a design idea to achieve "parallelization" of
services.
Let's assume that service A is a dependency for service B (and others).
After A's on-demand socket has been put "on hold" (blocking), the A may
die
or lock up for any reason, that is never to come up again by itself as
an active service.
That means there is a system lock-up possibility here while B (and others) are
"on hold" too (waiting for A to be unblocked), and wait ..., and wait ...
Systemd and security - an example # 1 of an attack venue.
---------------------------------------------------------
Here is a possible known example:
http://www.securiteam.com/unixfocus/6U00P1PEVQ.html
We know that systemd owns the service socket-in-waiting (with its buffer).
In case of an attack on socket buffer availability via kernel the systemd is
grounded as well.
This should not be allowed to happen to process #1, the Mother of All
Processes.
One more reason to redesign the systemd to be minimal and "beyond approach",
and instead have other restartable "child" process(es) take over the function
of on-demand socket handling.
Can you comment on that ?
JB
http://news.icanhascheezburger.com/2010/06/22/political-pictures-make-a-w...
JB - do you mean "beyond reproach" ?
Idiom:
beyond reproach
So good as to preclude any possibility of criticism.
--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark(a)netwolves.com
http://www.netwolves.com
2:10 p.m.
Steve Clark <sclark <at> netwolves.com> writes:
...
> Sys init.
> ---------
> Sys init as a process #1 should be "beyond approach" by design, and
delegate
> all work to other process(es), whether in a permanent or an ad-hoc manner,
> that can be operated by sysadmin if needed (e.g. restarted, initialized,
> configured, fixed, etc).
> We want it to be minimal in its size, minimal in its functions, simple,
> stable, secure (no attack venues, direct or indirect) - yes,
> "beyond approach".
...
JB - do you mean "beyond reproach" ?
Idiom:
beyond reproach
So good as to preclude any possibility of criticism.--
Stephen ClarkNetWolves
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark <at> netwolves.comhttp://www.netwolves.com
No, not "reproach".
I used the term "approach".
approach definition:
To come near or nearer, ...
I meant by "beyond approach" to have systemd as a sys init process #1
god-like qualities and to be so developed and have such characteristics as
to not have any venues of attack or influence, directly or indirectly, in
context of its reliability and security.
JB
2:33 p.m.
On Tue, 23.08.11 17:48, JB (jb.1234abcd(a)gmail.com) wrote:
Systemd and security - an example # 2 of an attack venue.
---------------------------------------------------------
The above is dangerous as a design idea to achieve "parallelization" of
services.
Let's assume that service A is a dependency for service B (and others).
After A's on-demand socket has been put "on hold" (blocking), the A may
die
or lock up for any reason, that is never to come up again by itself as
an active service.
That means there is a system lock-up possibility here while B (and others) are
"on hold" too (waiting for A to be unblocked), and wait ..., and wait
...
A dep loop is a dep loop is a dep loop. Whether systemd is used or not
does not change this. Services with ordering loops are borked services
and won't work. If an service A synchronously calls into service B and
the service B synchronously calls into A you'll have a dealock. No news
there...
We know that systemd owns the service socket-in-waiting (with its
buffer).
In case of an attack on socket buffer availability via kernel the systemd is
grounded as well.
This should not be allowed to happen to process #1, the Mother of All
Processes.
One more reason to redesign the systemd to be minimal and "beyond approach",
and instead have other restartable "child" process(es) take over the function
of on-demand socket handling.
Can you comment on that ?
systemd enforces limits on the number of sockets it keeps open. If you
have a socket unit with Accept=yes (i.e. where systemd will accept() the
socket and spawn one service instance per connection) then you can
enforce a limit with MaxConnections= which defaults to 64.
And on socket units with Accept=no (the much nicer way, where systemd
will spawn a single instance and hand over the listening fd), this
problem doesn't exist at all, since we only keep a single fd per unit
open.
Lennart
--
Lennart Poettering - Red Hat, Inc.
3:23 p.m.
On Tue, 2011-08-23 at 21:33 +0200, Lennart Poettering wrote:
On Tue, 23.08.11 17:48, JB (jb.1234abcd(a)gmail.com) wrote:
> Systemd and security - an example # 2 of an attack venue.
> ---------------------------------------------------------
> The above is dangerous as a design idea to achieve "parallelization" of
> services.
> Let's assume that service A is a dependency for service B (and others).
> After A's on-demand socket has been put "on hold" (blocking), the A
may die
> or lock up for any reason, that is never to come up again by itself as
> an active service.
> That means there is a system lock-up possibility here while B (and others) are
> "on hold" too (waiting for A to be unblocked), and wait ..., and wait
> ...
A dep loop is a dep loop is a dep loop. Whether systemd is used or not
does not change this. Services with ordering loops are borked services
and won't work. If an service A synchronously calls into service B and
the service B synchronously calls into A you'll have a dealock. No news
there...
No Lennart, this is not entirely correct.
If you have a daemon that can optionally leverage the services of
another but do not need to fail if the former is not available then even
a synchronous call is not necessarily a deadlock, for the simple reason
that w/o a socket the synchronous call will just return an error
immediately and the process will proceed on its way.
If instead the socket is listening but not really accepting and
processing requests, then yes, you can have a deadlock.
So socket activation is not transparent by any means and needs to be
handled very carefully in terms of circular dependencies as they may
actually introduce deadlocks that weren't there before.
The issue is particularly difficult to handle when connections are made
unbeknown to the application, for example in a pam or nss module (this
is one of the reasons I don't think SSSD should use socket activation,
as the clients are supposed to immediately fail and return nothing
rather then letting application wait for minutes like it happens with
nss_ldap).
Of course this can be handled by changing libraries and daemons so that
they timeout or handle the circular dependency differently, but claiming
there are no potential additional issues in a system so complex as a
modern Linux distribution is not fair.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
4:28 p.m.
Simo Sorce <simo(a)redhat.com> writes:
... If instead the socket is listening but not really accepting and
processing requests, then yes, you can have a deadlock.
So socket activation is not transparent by any means and needs to be
handled very carefully in terms of circular dependencies as they may
actually introduce deadlocks that weren't there before.
Yeah. Another way in which socket activation is not transparent is that
code might try to determine whether the service is running by seeing
whether a connection attempt succeeds. In such a case, having the
service autostart is absolutely *not* the desired outcome. Both mysql
and postgresql suffer from this problem --- there's no other way for
"mysqladmin ping" to work, for example. This issue is currently
preventing both of those databases from being packaged as
socket-activated services. I could try to get the upstreams to think
about inventing non-connection-based protocols for testing database
server status, but I doubt that either one will be receptive.
regards, tom lane
4:37 p.m.
On Tue, 2011-08-23 at 17:28 -0400, Tom Lane wrote:
Simo Sorce <simo(a)redhat.com> writes:
> ... If instead the socket is listening but not really accepting and
> processing requests, then yes, you can have a deadlock.
> So socket activation is not transparent by any means and needs to be
> handled very carefully in terms of circular dependencies as they may
> actually introduce deadlocks that weren't there before.
Yeah. Another way in which socket activation is not transparent is that
code might try to determine whether the service is running by seeing
whether a connection attempt succeeds. In such a case, having the
service autostart is absolutely *not* the desired outcome. Both mysql
Why not?
If the service is enabled but the daemon not currently running, is it so
terrible for a connection test to cause the daemon to start? Remember,
in systemd logic 'service enabled with socket activation, daemon not
currently running' is effectively an 'on' state, not an 'off' state.
If
you wanted the database to be 'off' you should have the service
disabled, and in that case, the ping test wouldn't cause the daemon to
start.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
5:11 p.m.
Adam Williamson <awilliam(a)redhat.com> writes:
On Tue, 2011-08-23 at 17:28 -0400, Tom Lane wrote:
> Yeah. Another way in which socket activation is not transparent is that
> code might try to determine whether the service is running by seeing
> whether a connection attempt succeeds. In such a case, having the
> service autostart is absolutely *not* the desired outcome. Both mysql
Why not?
If the service is enabled but the daemon not currently running, is it
so
terrible for a connection test to cause the daemon to start?
Yes, it is. Tests with side-effects suck.
Remember,
in systemd logic 'service enabled with socket activation, daemon not
currently running' is effectively an 'on' state, not an 'off' state.
I think that one of the worst aspects of systemd is its assumption that
it can force new world-views upon every other piece of software in the
system :-(. But anyway, here's an example of why this is a problem:
when we tried to code up socket activation for mysqld, we found there
was no way to make the service case wait for the daemon to actually be
ready to accept connections --- because the only way to test that was to
try a connection, which confused the heck out of systemd when it was
controlling the socket too. Now maybe what we hit was just a fixable
bug in systemd, but I think it's a fairly fundamental issue.
Another way of saying this is: people are used to being able to check
if a service is up without thereby changing its state. Consider for
example somebody who has a nagios alert set to check database server
availability every few seconds. If that probe results in
auto-restarting the database after it crashed, it won't be producing the
desired results, or at least not all of them: yeah, it'll set the server
runnning again, but you'll have no idea from the nagios status that the
server went south at all. Which is an important part of what people run
that sort of test for.
regards, tom lane
5:26 p.m.
On Tue, 23.08.11 18:11, Tom Lane (tgl(a)redhat.com) wrote:
I think that one of the worst aspects of systemd is its assumption
that
it can force new world-views upon every other piece of software in the
system :-(. But anyway, here's an example of why this is a problem:
when we tried to code up socket activation for mysqld, we found there
was no way to make the service case wait for the daemon to actually be
ready to accept connections --- because the only way to test that was to
try a connection, which confused the heck out of systemd when it was
controlling the socket too. Now maybe what we hit was just a fixable
bug in systemd, but I think it's a fairly fundamental issue.
Hmm? sysv services double fork, and exit in the parent. If the parent
exits this is the notification that the listening sockets are all
established. That's how it was handled in sysvinit, and that's how
systemd supports it too with Type=systemd.
Another way of saying this is: people are used to being able to
check
if a service is up without thereby changing its state. Consider for
example somebody who has a nagios alert set to check database server
availability every few seconds. If that probe results in
auto-restarting the database after it crashed, it won't be producing the
desired results, or at least not all of them: yeah, it'll set the server
runnning again, but you'll have no idea from the nagios status that the
server went south at all. Which is an important part of what people run
that sort of test for.
Checks like this are broken, and have always been broken. They are
insecure (since 3306 is can be bound by everybody).
Lennart
--
Lennart Poettering - Red Hat, Inc.
5:59 p.m.
On Tue, 2011-08-23 at 18:11 -0400, Tom Lane wrote:
Another way of saying this is: people are used to being able to
check
if a service is up without thereby changing its state. Consider for
Well, again, it's arguable that this describes the systemd case. You
have not changed the state of *the service*: it was always 'on'. You
have only changed the state of the daemon that backs the service.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
5:03 a.m.
On Tue, Aug 23, 2011 at 06:11:45PM -0400, Tom Lane wrote:
Another way of saying this is: people are used to being able to
check
if a service is up without thereby changing its state. Consider for
example somebody who has a nagios alert set to check database server
availability every few seconds. If that probe results in
Yes, but I think this kind of monitoring appeared because SysV initscript
is not reliable in determining service status. Even "status" command sometimes
checkes only existence of PID file, not the real status.
In world with systemd, monitoring can just ask systemd if service is running.
Systemd will provide reliable answer, and if service is not running, will
provide information for how long it is stopped and what was the reason
for failure.
--
Tomasz Torcz Only gods can safely risk perfection,
xmpp: zdzichubg(a)chrome.pl it's a dangerous thing for a man. -- Alia
8:06 a.m.
On Tue, 2011-08-23 at 14:37 -0700, Adam Williamson wrote:
On Tue, 2011-08-23 at 17:28 -0400, Tom Lane wrote:
> Simo Sorce <simo(a)redhat.com> writes:
> > ... If instead the socket is listening but not really accepting and
> > processing requests, then yes, you can have a deadlock.
>
> > So socket activation is not transparent by any means and needs to be
> > handled very carefully in terms of circular dependencies as they may
> > actually introduce deadlocks that weren't there before.
>
> Yeah. Another way in which socket activation is not transparent is that
> code might try to determine whether the service is running by seeing
> whether a connection attempt succeeds. In such a case, having the
> service autostart is absolutely *not* the desired outcome. Both mysql
Why not?
If the service is enabled but the daemon not currently running, is it so
terrible for a connection test to cause the daemon to start? Remember,
in systemd logic 'service enabled with socket activation, daemon not
currently running' is effectively an 'on' state, not an 'off' state.
If
you wanted the database to be 'off' you should have the service
disabled, and in that case, the ping test wouldn't cause the daemon to
start.
It generally is a bad idea to automatically restart a database based on
a random connection. There many reasons why you may have stopped the db
(or it may have stopped itself) and requires inspection before
attempting a new restart. Having to battle with socket activation while
in a critical situation is not a good idea.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
9:10 a.m.
On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote:
On Tue, 2011-08-23 at 14:37 -0700, Adam Williamson wrote:
> Why not?
>
> If the service is enabled but the daemon not currently running, is it so
> terrible for a connection test to cause the daemon to start? Remember,
> in systemd logic 'service enabled with socket activation, daemon not
> currently running' is effectively an 'on' state, not an 'off'
state. If
> you wanted the database to be 'off' you should have the service
> disabled, and in that case, the ping test wouldn't cause the daemon to
> start.
It generally is a bad idea to automatically restart a database based on
a random connection. There many reasons why you may have stopped the db
(or it may have stopped itself) and requires inspection before
attempting a new restart. Having to battle with socket activation while
in a critical situation is not a good idea.
You'd have the same problem with any init system that supports automatic
service restarting. You can easily disable the service via systemctl.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
9:56 a.m.
On Wed, 2011-08-24 at 15:10 +0100, Matthew Garrett wrote:
On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote:
> On Tue, 2011-08-23 at 14:37 -0700, Adam Williamson wrote:
> > Why not?
> >
> > If the service is enabled but the daemon not currently running, is it so
> > terrible for a connection test to cause the daemon to start? Remember,
> > in systemd logic 'service enabled with socket activation, daemon not
> > currently running' is effectively an 'on' state, not an
'off' state. If
> > you wanted the database to be 'off' you should have the service
> > disabled, and in that case, the ping test wouldn't cause the daemon to
> > start.
>
> It generally is a bad idea to automatically restart a database based on
> a random connection. There many reasons why you may have stopped the db
> (or it may have stopped itself) and requires inspection before
> attempting a new restart. Having to battle with socket activation while
> in a critical situation is not a good idea.
You'd have the same problem with any init system that supports automatic
service restarting. You can easily disable the service via systemctl.
You can do that if you are doing a planned outage. But not for unplanned
ones.
I am not saying automatic restarts should never be employed, only that
not all software should be automatically restarted. I think databases
shouldn't in most cases. But that's just my opinion on the specific
case. That doesn't mean socket-activation shouldn't be employed in other
cases.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
10:08 a.m.
Simo Sorce <simo(a)redhat.com> writes:
On Wed, 2011-08-24 at 15:10 +0100, Matthew Garrett wrote:
> On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote:
>> It generally is a bad idea to automatically restart a database based on
>> a random connection. There many reasons why you may have stopped the db
>> (or it may have stopped itself) and requires inspection before
>> attempting a new restart. Having to battle with socket activation while
>> in a critical situation is not a good idea.
> You'd have the same problem with any init system that
supports automatic
> service restarting. You can easily disable the service via systemctl.
You can do that if you are doing a planned outage. But not for
unplanned
ones.
I am not saying automatic restarts should never be employed, only
that
not all software should be automatically restarted. I think databases
shouldn't in most cases. But that's just my opinion on the specific
case. That doesn't mean socket-activation shouldn't be employed in other
cases.
FWIW, I do think that there may be use-cases for socket activation of a
database. I'd like to support the option ... the problem is to do so
without breaking existing, expected behaviors.
regards, tom lane
10:18 a.m.
On Wed, 2011-08-24 at 11:08 -0400, Tom Lane wrote:
Simo Sorce <simo(a)redhat.com> writes:
> On Wed, 2011-08-24 at 15:10 +0100, Matthew Garrett wrote:
>> On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote:
>>> It generally is a bad idea to automatically restart a database based on
>>> a random connection. There many reasons why you may have stopped the db
>>> (or it may have stopped itself) and requires inspection before
>>> attempting a new restart. Having to battle with socket activation while
>>> in a critical situation is not a good idea.
>> You'd have the same problem with any init system that supports automatic
>> service restarting. You can easily disable the service via systemctl.
> You can do that if you are doing a planned outage. But not for unplanned
> ones.
> I am not saying automatic restarts should never be employed, only that
> not all software should be automatically restarted. I think databases
> shouldn't in most cases. But that's just my opinion on the specific
> case. That doesn't mean socket-activation shouldn't be employed in other
> cases.
FWIW, I do think that there may be use-cases for socket activation of a
database. I'd like to support the option ... the problem is to do so
without breaking existing, expected behaviors.
I am not sure you can, the only would be to have systemd have some way
to get callbacks from service to know when they are actually ready to
serve. This would make "After" more meaningful. Still wouldn't solve the
problem of a probe ending up causing a database start, I don't think
there is a way to do that if you allow socket-activation.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
12:57 p.m.
On Wed, 24.08.11 11:18, Simo Sorce (simo(a)redhat.com) wrote:
> FWIW, I do think that there may be use-cases for socket
activation of a
> database. I'd like to support the option ... the problem is to do so
> without breaking existing, expected behaviors.
I am not sure you can, the only would be to have systemd have some way
to get callbacks from service to know when they are actually ready to
serve. This would make "After" more meaningful.
Hmm, we have that. The traditional way is Type=forking plus double
forking+exit in the parent. The nicer modern way is Type=notify and
sd_notify("READY=1").
I am not entirely I am sure I follow what you are asking for, but do you
need more thatn this?
Lennart
--
Lennart Poettering - Red Hat, Inc.
1:29 p.m.
On Wed, 2011-08-24 at 19:57 +0200, Lennart Poettering wrote:
On Wed, 24.08.11 11:18, Simo Sorce (simo(a)redhat.com) wrote:
> > FWIW, I do think that there may be use-cases for socket activation of a
> > database. I'd like to support the option ... the problem is to do so
> > without breaking existing, expected behaviors.
>
> I am not sure you can, the only would be to have systemd have some way
> to get callbacks from service to know when they are actually ready to
> serve. This would make "After" more meaningful.
Hmm, we have that. The traditional way is Type=forking plus double
forking+exit in the parent. The nicer modern way is Type=notify and
sd_notify("READY=1").
I am not entirely I am sure I follow what you are asking for, but do you
need more thatn this?
Ah although I have read the systemd header files that are used for
inclusion in apps I completely forgot about sd_notify().
I don't think anything else is really necessary.
Thanks!
Simo.
--
Simo Sorce * Red Hat, Inc * New York
12:05 p.m.
On Wed, 2011-08-24 at 11:08 -0400, Tom Lane wrote:
Simo Sorce <simo(a)redhat.com> writes:
> On Wed, 2011-08-24 at 15:10 +0100, Matthew Garrett wrote:
>> On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote:
>>> It generally is a bad idea to automatically restart a database based on
>>> a random connection. There many reasons why you may have stopped the db
>>> (or it may have stopped itself) and requires inspection before
>>> attempting a new restart. Having to battle with socket activation while
>>> in a critical situation is not a good idea.
>> You'd have the same problem with any init system that supports automatic
>> service restarting. You can easily disable the service via systemctl.
> You can do that if you are doing a planned outage. But not for unplanned
> ones.
> I am not saying automatic restarts should never be employed, only that
> not all software should be automatically restarted. I think databases
> shouldn't in most cases. But that's just my opinion on the specific
> case. That doesn't mean socket-activation shouldn't be employed in other
> cases.
FWIW, I do think that there may be use-cases for socket activation of a
database. I'd like to support the option ... the problem is to do so
without breaking existing, expected behaviors.
It was noted up-thread that systemd can tell you whether the underlying
daemon is running or not, though I guess that doesn't tell you whether
it's entirely in a functional state. You could do a two-stage thing:
check with systemd whether the daemon is running, and ping it if so?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:10 p.m.
On Aug 24, 2011, at 10:05 AM, Adam Williamson wrote:
On Wed, 2011-08-24 at 11:08 -0400, Tom Lane wrote:
> Simo Sorce <simo(a)redhat.com> writes:
>> On Wed, 2011-08-24 at 15:10 +0100, Matthew Garrett wrote:
>>> On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote:
>>>> It generally is a bad idea to automatically restart a database based on
>>>> a random connection. There many reasons why you may have stopped the db
>>>> (or it may have stopped itself) and requires inspection before
>>>> attempting a new restart. Having to battle with socket activation while
>>>> in a critical situation is not a good idea.
>
>>> You'd have the same problem with any init system that supports automatic
>>> service restarting. You can easily disable the service via systemctl.
>
>> You can do that if you are doing a planned outage. But not for unplanned
>> ones.
>
>> I am not saying automatic restarts should never be employed, only that
>> not all software should be automatically restarted. I think databases
>> shouldn't in most cases. But that's just my opinion on the specific
>> case. That doesn't mean socket-activation shouldn't be employed in other
>> cases.
>
> FWIW, I do think that there may be use-cases for socket activation of a
> database. I'd like to support the option ... the problem is to do so
> without breaking existing, expected behaviors.
It was noted up-thread that systemd can tell you whether the underlying
daemon is running or not, though I guess that doesn't tell you whether
it's entirely in a functional state. You could do a two-stage thing:
check with systemd whether the daemon is running, and ping it if so?
Some of the argument here is that it is difficult to do this from a remote host.
You'd have to engage in remote execution of software, e.g. using nagios nrpe to
remotely (from the nagios system) execute commands on the database system to call systemd
to check the status of the db.
This is a shift from previous environments where you could just poke at the network socket
from the nagios system and parse the reply.
- jlk
1:19 p.m.
On Wed, 24.08.11 10:10, Jesse Keating (jkeating(a)j2solutions.net) wrote:
>> FWIW, I do think that there may be use-cases for socket
activation of a
>> database. I'd like to support the option ... the problem is to do so
>> without breaking existing, expected behaviors.
>
> It was noted up-thread that systemd can tell you whether the underlying
> daemon is running or not, though I guess that doesn't tell you whether
> it's entirely in a functional state. You could do a two-stage thing:
> check with systemd whether the daemon is running, and ping it if so?
Some of the argument here is that it is difficult to do this from a
remote host. You'd have to engage in remote execution of software,
e.g. using nagios nrpe to remotely (from the nagios system) execute
commands on the database system to call systemd to check the status of
the db.
systemctl actually knows the -H switch to access remote systems (via
ssh), but this needs a patch to dbus to actually work which I still
haven't found time to ultimately clean up for proper inclusion.
Lennart
--
Lennart Poettering - Red Hat, Inc.
1:31 p.m.
On Wed, 2011-08-24 at 20:19 +0200, Lennart Poettering wrote:
On Wed, 24.08.11 10:10, Jesse Keating (jkeating(a)j2solutions.net)
wrote:
> >> FWIW, I do think that there may be use-cases for socket activation of a
> >> database. I'd like to support the option ... the problem is to do so
> >> without breaking existing, expected behaviors.
> >
> > It was noted up-thread that systemd can tell you whether the underlying
> > daemon is running or not, though I guess that doesn't tell you whether
> > it's entirely in a functional state. You could do a two-stage thing:
> > check with systemd whether the daemon is running, and ping it if so?
>
>
> Some of the argument here is that it is difficult to do this from a
> remote host. You'd have to engage in remote execution of software,
> e.g. using nagios nrpe to remotely (from the nagios system) execute
> commands on the database system to call systemd to check the status of
> the db.
systemctl actually knows the -H switch to access remote systems (via
ssh), but this needs a patch to dbus to actually work which I still
haven't found time to ultimately clean up for proper inclusion.
Monitoring system generally do not have (nor should have) ssh access to
other servers.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
1:52 p.m.
On Aug 24, 2011, at 11:19 AM, Lennart Poettering wrote:
On Wed, 24.08.11 10:10, Jesse Keating (jkeating(a)j2solutions.net)
wrote:
>>> FWIW, I do think that there may be use-cases for socket activation of a
>>> database. I'd like to support the option ... the problem is to do so
>>> without breaking existing, expected behaviors.
>>
>> It was noted up-thread that systemd can tell you whether the underlying
>> daemon is running or not, though I guess that doesn't tell you whether
>> it's entirely in a functional state. You could do a two-stage thing:
>> check with systemd whether the daemon is running, and ping it if so?
>
>
> Some of the argument here is that it is difficult to do this from a
> remote host. You'd have to engage in remote execution of software,
> e.g. using nagios nrpe to remotely (from the nagios system) execute
> commands on the database system to call systemd to check the status of
> the db.
systemctl actually knows the -H switch to access remote systems (via
ssh), but this needs a patch to dbus to actually work which I still
haven't found time to ultimately clean up for proper inclusion.
Lennart
That would require your nagios (or other monitoring) system to be running systemd, which
may not be the case for quite a while :)
- jlk
3:33 p.m.
On Wednesday, August 24, 2011 11:52:23 AM Jesse Keating wrote:
That would require your nagios (or other monitoring) system to be
running
systemd, which may not be the case for quite a while :)
Why? When used to access remote machines systemctl shouldn't require running
systemd locally.
Lars
4:31 p.m.
On Aug 24, 2011, at 1:33 PM, Lars Seipel wrote:
On Wednesday, August 24, 2011 11:52:23 AM Jesse Keating wrote:
> That would require your nagios (or other monitoring) system to be running
> systemd, which may not be the case for quite a while :)
Why? When used to access remote machines systemctl shouldn't require running
systemd locally.
Lars
Sorry, I conflated the two.
- jlk
2:49 p.m.
Jesse Keating (jkeating(a)j2solutions.net) said:
Some of the argument here is that it is difficult to do this from a
remote host. You'd have to engage in remote execution of software, e.g. using nagios
nrpe to remotely (from the nagios system) execute commands on the database system to call
systemd to check the status of the db.
This is a shift from previous environments where you could just poke at the network
socket from the nagios system and parse the reply.
Sure, but there's nothing that says you *have* to set up your
internet-facing services as socket-activated. (In fact, quite the opposite.)
Bill
4:32 p.m.
On Aug 24, 2011, at 12:49 PM, Bill Nottingham wrote:
Jesse Keating (jkeating(a)j2solutions.net) said:
> Some of the argument here is that it is difficult to do this from a remote host.
You'd have to engage in remote execution of software, e.g. using nagios nrpe to
remotely (from the nagios system) execute commands on the database system to call systemd
to check the status of the db.
>
> This is a shift from previous environments where you could just poke at the network
socket from the nagios system and parse the reply.
Sure, but there's nothing that says you *have* to set up your
internet-facing services as socket-activated. (In fact, quite the opposite.)
Bill
oh of course not. I was just trying to shed light on where some of the argument was
coming from.
- jlk
12:59 p.m.
On Wed, 24.08.11 10:05, Adam Williamson (awilliam(a)redhat.com) wrote:
> FWIW, I do think that there may be use-cases for socket
activation of a
> database. I'd like to support the option ... the problem is to do so
> without breaking existing, expected behaviors.
It was noted up-thread that systemd can tell you whether the underlying
daemon is running or not, though I guess that doesn't tell you whether
it's entirely in a functional state. You could do a two-stage thing:
check with systemd whether the daemon is running, and ping it if so?
systemd will put services only in "running" state if they are fully up
and told systemd so. They'll be in "starting" until that time. All we
need for this is that services either use Type=forking and double
fork+exit in parent, or use Type=notify and sd_notify("READY=1") as soon
as they are fully up.
Lennart
--
Lennart Poettering - Red Hat, Inc.
1:40 p.m.
On Wed, 2011-08-24 at 19:59 +0200, Lennart Poettering wrote:
On Wed, 24.08.11 10:05, Adam Williamson (awilliam(a)redhat.com) wrote:
> > FWIW, I do think that there may be use-cases for socket activation of a
> > database. I'd like to support the option ... the problem is to do so
> > without breaking existing, expected behaviors.
>
> It was noted up-thread that systemd can tell you whether the underlying
> daemon is running or not, though I guess that doesn't tell you whether
> it's entirely in a functional state. You could do a two-stage thing:
> check with systemd whether the daemon is running, and ping it if so?
systemd will put services only in "running" state if they are fully up
and told systemd so. They'll be in "starting" until that time. All we
need for this is that services either use Type=forking and double
fork+exit in parent, or use Type=notify and sd_notify("READY=1") as soon
as they are fully up.
Sure, but it would be possibly for mysql to be 'fully up' under
systemd's definition (i.e. the mysqld process has successfully executed
and is running happily) while not actually being properly configured to
serve external requests, right? Bad mysql config, firewall in the way,
whatever...point is that systemd can't really know for sure that the
underlying process is 100% working, only that it's _running_.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
1:57 p.m.
Am 24.08.2011 20:40, schrieb Adam Williamson:
On Wed, 2011-08-24 at 19:59 +0200, Lennart Poettering wrote:
> On Wed, 24.08.11 10:05, Adam Williamson (awilliam(a)redhat.com) wrote:
>
>>> FWIW, I do think that there may be use-cases for socket activation of a
>>> database. I'd like to support the option ... the problem is to do so
>>> without breaking existing, expected behaviors.
>>
>> It was noted up-thread that systemd can tell you whether the underlying
>> daemon is running or not, though I guess that doesn't tell you whether
>> it's entirely in a functional state. You could do a two-stage thing:
>> check with systemd whether the daemon is running, and ping it if so?
>
> systemd will put services only in "running" state if they are fully up
> and told systemd so. They'll be in "starting" until that time. All we
> need for this is that services either use Type=forking and double
> fork+exit in parent, or use Type=notify and sd_notify("READY=1") as soon
> as they are fully up.
Sure, but it would be possibly for mysql to be 'fully up' under
systemd's definition (i.e. the mysqld process has successfully executed
and is running happily) while not actually being properly configured to
serve external requests, right? Bad mysql config, firewall in the way,
whatever...point is that systemd can't really know for sure that the
underlying process is 100% working, only that it's _running_
and that is why you need only socket-activation for the unix-socket
to provide relieable system-boot with activation and you nagios will
check over TCP and so has NOTHING really NOTHING to do with systemd
11:13 a.m.
Actually there is another reason for socket activation to use AF_INET as
well as AF_UNIX: doing so prevents e.g. rpc.statd from port-squatting.
In fact, this is why CUPS no longer ships to ship a portreserve file.
Tim.
*/
10:09 a.m.
Hi,
On 08/24/2011 04:56 PM, Simo Sorce wrote:
On Wed, 2011-08-24 at 15:10 +0100, Matthew Garrett wrote:
> On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote:
>> On Tue, 2011-08-23 at 14:37 -0700, Adam Williamson wrote:
>>> Why not?
>>>
>>> If the service is enabled but the daemon not currently running, is it so
>>> terrible for a connection test to cause the daemon to start? Remember,
>>> in systemd logic 'service enabled with socket activation, daemon not
>>> currently running' is effectively an 'on' state, not an
'off' state. If
>>> you wanted the database to be 'off' you should have the service
>>> disabled, and in that case, the ping test wouldn't cause the daemon to
>>> start.
>>
>> It generally is a bad idea to automatically restart a database based on
>> a random connection. There many reasons why you may have stopped the db
>> (or it may have stopped itself) and requires inspection before
>> attempting a new restart. Having to battle with socket activation while
>> in a critical situation is not a good idea.
>
> You'd have the same problem with any init system that supports automatic
> service restarting. You can easily disable the service via systemctl.
You can do that if you are doing a planned outage. But not for unplanned
ones.
I am not saying automatic restarts should never be employed, only that
not all software should be automatically restarted. I think databases
shouldn't in most cases. But that's just my opinion on the specific
case. That doesn't mean socket-activation shouldn't be employed in other
cases.
So maybe we need a socket-activate-once attribute for .service files,
which makes systemd do the socket activation only once, hmm thinking of
it, doesn't it do that already in the form of handing the listening fd over?
So if a service is set to not auto restart the service I would expect
the order would be:
1) systemd starts
2) systemd creates listening socket
3) connection comes in
4) systemd starts foodb, hands overlistening socket
5) foodb crashes
6) db is dead, no one listening to socket.
Right? I guess that unless auto-restart is set for the service, systemd
won't re-create the listening socket and start listening itself again on
step 6. If it does I'm sure that the systemd authors are very reasonable
people and we can tell them that socket activation should not imply
auto-restart on daemon crash / exit (unless explicitly requested).
Regards,
Hans
1:05 p.m.
On Wed, 24.08.11 17:09, Hans de Goede (hdegoede(a)redhat.com) wrote:
Hi,
On 08/24/2011 04:56 PM, Simo Sorce wrote:
> On Wed, 2011-08-24 at 15:10 +0100, Matthew Garrett wrote:
>> On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote:
>>> On Tue, 2011-08-23 at 14:37 -0700, Adam Williamson wrote:
>>>> Why not?
>>>>
>>>> If the service is enabled but the daemon not currently running, is it
so
>>>> terrible for a connection test to cause the daemon to start? Remember,
>>>> in systemd logic 'service enabled with socket activation, daemon
not
>>>> currently running' is effectively an 'on' state, not an
'off' state. If
>>>> you wanted the database to be 'off' you should have the service
>>>> disabled, and in that case, the ping test wouldn't cause the daemon
to
>>>> start.
>>>
>>> It generally is a bad idea to automatically restart a database based on
>>> a random connection. There many reasons why you may have stopped the db
>>> (or it may have stopped itself) and requires inspection before
>>> attempting a new restart. Having to battle with socket activation while
>>> in a critical situation is not a good idea.
>>
>> You'd have the same problem with any init system that supports automatic
>> service restarting. You can easily disable the service via systemctl.
>
> You can do that if you are doing a planned outage. But not for unplanned
> ones.
>
> I am not saying automatic restarts should never be employed, only that
> not all software should be automatically restarted. I think databases
> shouldn't in most cases. But that's just my opinion on the specific
> case. That doesn't mean socket-activation shouldn't be employed in other
> cases.
So maybe we need a socket-activate-once attribute for .service files,
which makes systemd do the socket activation only once, hmm thinking of
it, doesn't it do that already in the form of handing the listening fd over?
So if a service is set to not auto restart the service I would expect
the order would be:
1) systemd starts
2) systemd creates listening socket
3) connection comes in
4) systemd starts foodb, hands overlistening socket
5) foodb crashes
6) db is dead, no one listening to socket.
Right? I guess that unless auto-restart is set for the service, systemd
won't re-create the listening socket and start listening itself again on
step 6. If it does I'm sure that the systemd authors are very reasonable
people and we can tell them that socket activation should not imply
auto-restart on daemon crash / exit (unless explicitly requested).
I think what you are basically asking for is that we propagate the
failure state from the service unit to the socket unit, right?
As mentioned in another mail I just sent this has been on the todo list
for a while.
Lennart
--
Lennart Poettering - Red Hat, Inc.
12:44 p.m.
On Wed, 24.08.11 10:56, Simo Sorce (simo(a)redhat.com) wrote:
> > a random connection. There many reasons why you may have
stopped the db
> > (or it may have stopped itself) and requires inspection before
> > attempting a new restart. Having to battle with socket activation while
> > in a critical situation is not a good idea.
>
> You'd have the same problem with any init system that supports automatic
> service restarting. You can easily disable the service via systemctl.
You can do that if you are doing a planned outage. But not for unplanned
ones.
I am not saying automatic restarts should never be employed, only that
not all software should be automatically restarted. I think databases
shouldn't in most cases. But that's just my opinion on the specific
case. That doesn't mean socket-activation shouldn't be employed in other
cases.
Restart= defaults to off by default, since only selected services should
be restarted automatically.
What currently is missing is that if a service fails we can (optionally)
automatically propagate this to the triggering .socket, .path, .timer
units. That's what you are asking for right? Because in that case we
would shut down a listening socket as soon as the backing service
fails. This has been on the TODO list for a while I just need to get
around implementing this.
Lennart
--
Lennart Poettering - Red Hat, Inc.
1:28 p.m.
On Wed, 2011-08-24 at 19:44 +0200, Lennart Poettering wrote:
On Wed, 24.08.11 10:56, Simo Sorce (simo(a)redhat.com) wrote:
> > > a random connection. There many reasons why you may have stopped the db
> > > (or it may have stopped itself) and requires inspection before
> > > attempting a new restart. Having to battle with socket activation while
> > > in a critical situation is not a good idea.
> >
> > You'd have the same problem with any init system that supports automatic
> > service restarting. You can easily disable the service via systemctl.
>
> You can do that if you are doing a planned outage. But not for unplanned
> ones.
>
> I am not saying automatic restarts should never be employed, only that
> not all software should be automatically restarted. I think databases
> shouldn't in most cases. But that's just my opinion on the specific
> case. That doesn't mean socket-activation shouldn't be employed in other
> cases.
Restart= defaults to off by default, since only selected services should
be restarted automatically.
What currently is missing is that if a service fails we can (optionally)
automatically propagate this to the triggering .socket, .path, .timer
units. That's what you are asking for right? Because in that case we
would shut down a listening socket as soon as the backing service
fails. This has been on the TODO list for a while I just need to get
around implementing this.
Yes, I think this would neatly solve many issues.
Thanks,
Simo.
--
Simo Sorce * Red Hat, Inc * New York
12:02 p.m.
On Wed, 2011-08-24 at 09:06 -0400, Simo Sorce wrote:
> If the service is enabled but the daemon not currently running,
is it so
> terrible for a connection test to cause the daemon to start? Remember,
> in systemd logic 'service enabled with socket activation, daemon not
> currently running' is effectively an 'on' state, not an 'off'
state. If
> you wanted the database to be 'off' you should have the service
> disabled, and in that case, the ping test wouldn't cause the daemon to
> start.
It generally is a bad idea to automatically restart a database based on
a random connection. There many reasons why you may have stopped the db
(or it may have stopped itself) and requires inspection before
attempting a new restart. Having to battle with socket activation while
in a critical situation is not a good idea.
Sure, and I agree with you that socket activation may not be a great
idea for a constantly-used database. I should've made it clearer that I
was engaging with the generic argument - 'socket activation makes it
tough to check the state of services by pinging them' - not the specific
example - 'socket activation makes it tough to check the state of MySQL
by pinging it'. As far as I was concerned, MySQL was just an arbitrary
example chosen by the OP.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:22 p.m.
On 20:17:14 Wednesday 24 August 2011 Adam Williamson wrote:
On Wed, 2011-08-24 at 09:06 -0400, Simo Sorce wrote:
> > If the service is enabled but the daemon not currently running, is it
> > so terrible for a connection test to cause the daemon to start?
> > Remember, in systemd logic 'service enabled with socket activation,
> > daemon not currently running' is effectively an 'on' state, not an
> > 'off' state. If you wanted the database to be 'off' you should
have
> > the service disabled, and in that case, the ping test wouldn't cause
> > the daemon to start.
>
> It generally is a bad idea to automatically restart a database based on
> a random connection. There many reasons why you may have stopped the db
> (or it may have stopped itself) and requires inspection before
> attempting a new restart. Having to battle with socket activation while
> in a critical situation is not a good idea.
Sure, and I agree with you that socket activation may not be a great
idea for a constantly-used database. I should've made it clearer that I
was engaging with the generic argument - 'socket activation makes it
tough to check the state of services by pinging them' - not the specific
example - 'socket activation makes it tough to check the state of MySQL
by pinging it'. As far as I was concerned, MySQL was just an arbitrary
example chosen by the OP.
I want to add one more POV - not every database is constantly-used. Example
usage is Amarok using mysql database and I really want mysql to not be started
until I start Amarok. Not that this is very common usage scenario but still I
know at least one guy using Amarok with mysql :).
Alexander Kurtakov
12:31 p.m.
On Wed, Aug 24, 2011 at 9:22 AM, Alexander Kurtakov <akurtako(a)redhat.com>wrote:
I want to add one more POV - not every database is constantly-used.
Example
usage is Amarok using mysql database and I really want mysql to not be
started
until I start Amarok. Not that this is very common usage scenario but
still I
know at least one guy using Amarok with mysql :).
You are using a system-wide network exposed mysql for Amarok? Is this
mysql
serving information to multiple clients or multiple users? If its
system-wide and only being used by one application by one user, why is it
being run system-wide?
-jef
12:44 p.m.
On Wed, Aug 24, 2011 at 9:31 AM, Jef Spaleta <jspaleta(a)gmail.com> wrote:
On Wed, Aug 24, 2011 at 9:22 AM, Alexander Kurtakov <akurtako(a)redhat.com>wrote:
> I want to add one more POV - not every database is constantly-used.
> Example
> usage is Amarok using mysql database and I really want mysql to not be
> started
> until I start Amarok. Not that this is very common usage scenario but
> still I
> know at least one guy using Amarok with mysql :).
>
> You are using a system-wide network exposed mysql for Amarok? Is this
mysql serving information to multiple clients or multiple users? If its
system-wide and only being used by one application by one user, why is it
being run system-wide?
And to belabor the point a bit more. We really need to have distinct
discussions about what a system service "default" is and what its okay for
local admins are encourage/discourage/allowed to do.
If you need to run a private instance of mysql on non-standard network ports
to serve a local Amarok application in an on-demand fashion. Then you can do
that as a local admin. In fact working with the mysql packager you might be
able to use systemd's support for multiple instances to make it easier to
set that up without it interfering with the system default mysql.
However, does it make since to write the default init for the system-wide
mysql with this usage case in mind? I'm not sure.
It could very well be that for right now the system wide mysql default init
needs to refrain from socket activation as mysql is primarily aimed at a
server workload and not an on-demand workload. Any service that primarily
services remote systems instead of local applications will probably want to
start up fully at boot and not on demand later.
I guess that's sort of the sane boundary for me with regard to socket
activiation. If a service wants to see the outside world via tcp
sockets...probably should not be on-demand by default. If its unix socket
only..it can probably be a socket activated service. There will be of
course things that break that simple rule..but as I guide I think it will
work as a starting point for service packagers.
-jef
1:17 p.m.
On Wed, 24.08.11 20:22, Alexander Kurtakov (akurtako(a)redhat.com) wrote:
On 20:17:14 Wednesday 24 August 2011 Adam Williamson wrote:
> On Wed, 2011-08-24 at 09:06 -0400, Simo Sorce wrote:
> > > If the service is enabled but the daemon not currently running, is it
> > > so terrible for a connection test to cause the daemon to start?
> > > Remember, in systemd logic 'service enabled with socket activation,
> > > daemon not currently running' is effectively an 'on' state,
not an
> > > 'off' state. If you wanted the database to be 'off' you
should have
> > > the service disabled, and in that case, the ping test wouldn't cause
> > > the daemon to start.
> >
> > It generally is a bad idea to automatically restart a database based on
> > a random connection. There many reasons why you may have stopped the db
> > (or it may have stopped itself) and requires inspection before
> > attempting a new restart. Having to battle with socket activation while
> > in a critical situation is not a good idea.
>
> Sure, and I agree with you that socket activation may not be a great
> idea for a constantly-used database. I should've made it clearer that I
> was engaging with the generic argument - 'socket activation makes it
> tough to check the state of services by pinging them' - not the specific
> example - 'socket activation makes it tough to check the state of MySQL
> by pinging it'. As far as I was concerned, MySQL was just an arbitrary
> example chosen by the OP.
I want to add one more POV - not every database is constantly-used. Example
usage is Amarok using mysql database and I really want mysql to not be started
until I start Amarok. Not that this is very common usage scenario but still I
know at least one guy using Amarok with mysql :).
Please, don't conflate general socket activation with lazy socket
activation. The former is the generic technology that provides us with a
lot of advantages like robustness, parallelization, simplicity because
deps don't need to be configured explicitly anymore. The latter is
something that is useful for very few selected services, like CUPS and
sshd which are used very seldom (i.e. less often than 1/h in 90% of the
cases).
Lennart
--
Lennart Poettering - Red Hat, Inc.
5:09 p.m.
New subject: Default services enabled -> there is no problem with mysqld
Am 23.08.2011 23:28, schrieb Tom Lane:
Yeah. Another way in which socket activation is not transparent is
that
code might try to determine whether the service is running by seeing
whether a connection attempt succeeds.
well if you have enabled the service and a listening socket
it is the definition of RUNNING
In such a case, having the service autostart is absolutely *not* the
desired
outcome.
why not? if you have it enabled you expect that it is there
Both mysql and postgresql suffer from this problem
you see a problem where no problem is
there's no other way for "mysqladmin ping" to work, for
example
and where is the problem?
this is expected
do you not undertsand the fact that if i ENABLE mysqld i expect
that it is listening and if anything checks if mysql is available
it has to get YES at answer if mysqld is enabled from the begin of
the boot process
This issue is currently preventing both of those databases from being
packaged as
socket-activated services.
nothing is preventing anything because you see a problem where
no problem exists and with your view you make problems on
machines where a lot of services are depending on mysql
i tried to explain this thousands of times and getting tired
of your non-understanding that mysqld has to accept connections
as soon as possible and if oyu do not want mysqld started
so do NOT enable mysqld
I could try to get the upstreams to think
about inventing non-connection-based protocols for testing database
server status, but I doubt that either one will be receptive
they will reject you because you are the only person seeing
a problem and not because there is one
9:45 a.m.
New subject: Default services enabled -> there is no problem with mysqld
Reindl Harald <h.reindl(a)thelounge.net> writes:
Am 23.08.2011 23:28, schrieb Tom Lane:
> there's no other way for "mysqladmin ping" to work, for example
and where is the problem?
I'm not planning on repeating myself either, but: a database
*monitoring* tool, as opposed to a vanilla client, needs to know whether
the database is in fact up. Autostarting the DB in response to a
monitoring probe is the wrong behavior for that.
I do not really care whether you believe that that's a problem or not;
it is in my eyes, and as the responsible engineer, I'm not going to
produce a broken database package.
regards, tom lane
12:36 p.m.
New subject: Default services enabled -> there is no problem with mysqld
On Wed, 24.08.11 10:45, Tom Lane (tgl(a)redhat.com) wrote:
Reindl Harald <h.reindl(a)thelounge.net> writes:
> Am 23.08.2011 23:28, schrieb Tom Lane:
>> there's no other way for "mysqladmin ping" to work, for example
> and where is the problem?
I'm not planning on repeating myself either, but: a database
*monitoring* tool, as opposed to a vanilla client, needs to know whether
the database is in fact up. Autostarting the DB in response to a
monitoring probe is the wrong behavior for that.
Are you sure it is? The thing is that when using socket activation it is
merely an implementation detail when a service is actually really
started. If you get a response you get a response and that's what you
probably want to monitor. Whether the backing service has been running
all the time or was just started due to your request shouldn't really
matter -- unless of course you actually really want to monitor the
service itself and not just whether it responds. But in that case it's
probably a good idea to ask systemd for the service's status, since it
will provide you with a lot of interesting data, including timestamps
and so on.
So, my claim would be that if you want to monitor whether a service
responds then the backing implementation of it should be asbtract to you
and it doesn't matter whether a service is started, or already running
for that. And if you want to monitor the service itself then it's a good
idea to make use of the monitoring data systemd keeps and hence you
probably should talk to systemd directly in your monitoring tool.
I think it's really important to know what you actually want to monitor,
and then figure out how to do it best.
I do not really care whether you believe that that's a problem or
not;
it is in my eyes, and as the responsible engineer, I'm not going to
produce a broken database package.
I do believe socket activation is interesting for SQL servers, but lazy
activation of SQL servers makes little sense.
One should not conflate socket activation with lazy socket
activation. The latter is only interesting for a select few of services
which are very seldom used like CUPS or sshd which are usually only
access less than 1/h.
Socket activation brings a lot of advantages, lazy activation is only
one small one. More interesting are the paralellization or the fact that
we can get rid of explicitly configured dependencies and suchlike.
Lennart
--
Lennart Poettering - Red Hat, Inc.
1:23 p.m.
New subject: Default services enabled -> there is no problem with mysqld
Am 24.08.2011 19:36, schrieb Lennart Poettering:
On Wed, 24.08.11 10:45, Tom Lane (tgl(a)redhat.com) wrote:
>
> Reindl Harald <h.reindl(a)thelounge.net> writes:
>> Am 23.08.2011 23:28, schrieb Tom Lane:
>>> there's no other way for "mysqladmin ping" to work, for
example
>
>> and where is the problem?
>
> I'm not planning on repeating myself either, but: a database
> *monitoring* tool, as opposed to a vanilla client, needs to know whether
> the database is in fact up. Autostarting the DB in response to a
> monitoring probe is the wrong behavior for that.
Are you sure it is? The thing is that when using socket activation it is
merely an implementation detail when a service is actually really
started. If you get a response you get a response and that's what you
probably want to monitor.
and what he does not understand is that the socket is only needed LOCAL
nagios as brought example normally runs on a monitoring host and checks
the TCP port, sad enough that we have to explain this the mysql-maintainer
where will a monitoring over the network trigger the socket below?
TCP port is directly mysqld in this case
[root@srv-rhsoft:~]$ cat /lib/systemd/system/mysqld.socket
[Unit]
Description=MySQL Database activation socket
[Socket]
ListenStream=/var/lib/mysql/mysql.sock
[Install]
WantedBy=sockets.target
8:04 a.m.
On Tue, 2011-08-23 at 17:28 -0400, Tom Lane wrote:
Simo Sorce <simo(a)redhat.com> writes:
> ... If instead the socket is listening but not really accepting and
> processing requests, then yes, you can have a deadlock.
> So socket activation is not transparent by any means and needs to be
> handled very carefully in terms of circular dependencies as they may
> actually introduce deadlocks that weren't there before.
Yeah. Another way in which socket activation is not transparent is that
code might try to determine whether the service is running by seeing
whether a connection attempt succeeds. In such a case, having the
service autostart is absolutely *not* the desired outcome. Both mysql
and postgresql suffer from this problem --- there's no other way for
"mysqladmin ping" to work, for example. This issue is currently
preventing both of those databases from being packaged as
socket-activated services. I could try to get the upstreams to think
about inventing non-connection-based protocols for testing database
server status, but I doubt that either one will be receptive.
I fail to see any reason why you would want to socket-activate a
database. Either you need the database, so it should start asap, or
don't.
Using socket-activation as a hammer to throw around as a way to make
implicit dependencies between services is just wrong imho.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
8:26 a.m.
Am 24.08.2011 15:04, schrieb Simo Sorce:
I fail to see any reason why you would want to socket-activate a
database. Either you need the database, so it should start asap, or
don't
because systemd as shipped with F15 CAN NOT make sure that if it
means "i have started mysql" mysqld is ready for connections and
fire up on mysqld depending services independent what you try
to define in Before/After and most of this services will fail
or fail randomly depending on luck how fast mysqld was and at
which time they was started since we have no longer a defined
starting-order
and it makes me simply TIRED explain this thousand times on this
mailing-list and you guys do not try to understand nor rearding
multiple linked bugreports
https://bugzilla.redhat.com/show_bug.cgi?id=714426
3:33 p.m.
Lennart Poettering <mzerqung <at> 0pointer.de> writes:
On Tue, 23.08.11 17:48, JB (jb.1234abcd <at> gmail.com) wrote:
> Systemd and security - an example # 2 of an attack venue.
> ---------------------------------------------------------
> The above is dangerous as a design idea to achieve "parallelization" of
> services.
> Let's assume that service A is a dependency for service B (and others).
> After A's on-demand socket has been put "on hold" (blocking), the A
may
> die or lock up for any reason, that is never to come up again by itself as
> an active service.
> That means there is a system lock-up possibility here while B (and others)
> are "on hold" too (waiting for A to be unblocked), and wait ..., and wait
> ...
A dep loop is a dep loop is a dep loop. Whether systemd is used or not
does not change this. Services with ordering loops are borked services
and won't work. If an service A synchronously calls into service B and
the service B synchronously calls into A you'll have a dealock. No news
there...
Well, let's consider how the lock-up/deadlock would work without socket
activation mechanism.
Concurrent programming provides techniques like process synchronization
constructs with a timeout. That would be the built-in safety mechanism that
would prevent any lock-up.
...
> We know that systemd owns the service socket-in-waiting (with its buffer).
> In case of an attack on socket buffer availability via kernel the systemd
> is grounded as well.
> This should not be allowed to happen to process #1, the Mother of All
> Processes.
> One more reason to redesign the systemd to be minimal and "beyond
> approach", and instead have other restartable "child" process(es)
take
> over the function of on-demand socket handling.
>
> Can you comment on that ?
systemd enforces limits on the number of sockets it keeps open. If you
have a socket unit with Accept=yes (i.e. where systemd will accept() the
socket and spawn one service instance per connection) then you can
enforce a limit with MaxConnections= which defaults to 64.
And on socket units with Accept=no (the much nicer way, where systemd
will spawn a single instance and hand over the listening fd), this
problem doesn't exist at all, since we only keep a single fd per unit
open.
Lennart
This does not help in this case. The attack's effect can happen at any time
and catch systemd with its pants down at any time in the scenarios you
described.
The attack is on socket buffer availability via kernel, it lasts until no
resource is available system-wide. At that point systemd or any other
socket-based communication is brought to a standstill.
The point is, systemd can not be stopped, or restarted/reinitialized/reset
as any other stand-alone service daemon relying on sockets availability
manually.
The process #1, the GOD of all processes, is incapacitated, for good.
JB
4:35 p.m.
JB wrote:
This does not help in this case. The attack's effect can happen
at any time
and catch systemd with its pants down at any time in the scenarios you
described.
The attack is on socket buffer availability via kernel, it lasts until no
resource is available system-wide. At that point systemd or any other
socket-based communication is brought to a standstill.
The point is, systemd can not be stopped, or restarted/reinitialized/reset
as any other stand-alone service daemon relying on sockets availability
manually.
The process #1, the GOD of all processes, is incapacitated, for good.
I searched for "attack" and "socket buffer availability" trying to
find out what
kind of attack you're talking about. Duckduckgo had never heard about it.
Google gave me three hits, and all three were your previous message in this
list. It would help if you could explain how this attack works and how exactly
it would cause SystemD to lock up.
Is it perchance a syn flood you're talking about? If so, we have a good defense
since ages. It's known as syn cookies.
Björn Persson
4:54 p.m.
Björn Persson <bjorn <at> xn--rombobjrn-67a.se> writes:
JB wrote:
> This does not help in this case. The attack's effect can happen at any time
> and catch systemd with its pants down at any time in the scenarios you
> described.
> The attack is on socket buffer availability via kernel, it lasts until no
> resource is available system-wide. At that point systemd or any other
> socket-based communication is brought to a standstill.
> The point is, systemd can not be stopped, or restarted/reinitialized/reset
> as any other stand-alone service daemon relying on sockets availability
> manually.
> The process #1, the GOD of all processes, is incapacitated, for good.
I searched for "attack" and "socket buffer availability" trying to
find out
what kind of attack you're talking about. Duckduckgo had never heard about
it.
Google gave me three hits, and all three were your previous message in this
list. It would help if you could explain how this attack works and how
exactly it would cause SystemD to lock up.
Is it perchance a syn flood you're talking about? If so, we have a good
defense since ages. It's known as syn cookies.
Björn Persson
The link is in one of my posts above, but here it is again:
http://www.securiteam.com/unixfocus/6U00P1PEVQ.html
It contains a detailed description and the original CVE link.
Once again, it is about DOS of a resource in question, that is a socket buffer
memory, with system-wide effect, obviously on any socket-based process.
JB
6:06 p.m.
JB wrote:
Björn Persson <bjorn <at> xn--rombobjrn-67a.se> writes:
> JB wrote:
> > This does not help in this case. The attack's effect can happen at any
> > time and catch systemd with its pants down at any time in the
> > scenarios you described.
> > The attack is on socket buffer availability via kernel, it lasts until
> > no resource is available system-wide. At that point systemd or any
> > other socket-based communication is brought to a standstill.
> > The point is, systemd can not be stopped, or
> > restarted/reinitialized/reset as any other stand-alone service daemon
> > relying on sockets availability manually.
> > The process #1, the GOD of all processes, is incapacitated, for good.
>
> I searched for "attack" and "socket buffer availability" trying
to find
> out what kind of attack you're talking about. Duckduckgo had never heard
> about it.
> Google gave me three hits, and all three were your previous message in
> this list. It would help if you could explain how this attack works and
> how exactly it would cause SystemD to lock up.
The link is in one of my posts above, but here it is again:
http://www.securiteam.com/unixfocus/6U00P1PEVQ.html
It contains a detailed description and the original CVE link.
Once again, it is about DOS of a resource in question, that is a socket
buffer memory, with system-wide effect, obviously on any socket-based
process.
According to that description, the resource in question was physical memory.
Although the attack made use of sockets, it didn't consume any kind of socket-
specific resource, just plain old memory. If the attack was successful it would
cause a kernel panic. A kernel panic halts the entire system. All processes
stop running, regardless of whether they use sockets or not. That particular
attack is therefore irrelevant in a discussion about whether process 1 should
use sockets.
Björn Persson
6:06 p.m.
On Sun, 2011-08-21 at 20:34 -0400, Steve Grubb wrote:
You're not seeing the hundreds - no thousands of emails about
systemd? You are not
Most of which seem to come from you, Reindl, or Steve Clark; a very
active cabal doth not a rebellion make.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4:23 p.m.
Am 21.08.2011 23:09, schrieb Steve Clark:
>> Read the part about "Parallelizing Socket
Services". It explains why
>> socket actviation is interesting,
> I find a secure OS interesting. Bootup speed does not matter much to me.
>
> -Steve
Obviously a lot on this list value boot up speed over security!
some people seems to have nothing to do except watching their machine boot :-)
as long my workstation with KDE and a lot of services (httpd, mysql, named,...) boots
in 50 seconds and all our servers on F14 needs only 30-40 seconds for a complete
reboot-cycle the boot-speed is a little laughable topic when we get more problems
because services are fired up too fast while socket-activation can/should not be
used for most of them resulting in a fast bott but unuseable machine
in the morking i press the power-button of my workstation, go in the kitchen and
take some coffee and late in the afternoon in type "shutdown -h now", al other
machines are runnign 365/24/7 so there is security and be sure all services are
working everytime much more important than win 3 seconds on a boot 5 times a year
6:07 p.m.
On Sun, 2011-08-21 at 17:09 -0400, Steve Clark wrote:
> -Steve
Obviously a lot on this list value boot up speed over security!
You're making a false assumption, which is that socket activation is
only about speed. It's also about resource usage. (There may be other
advantages I haven't considered, this is not to be considered an
exclusive list.)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
7:09 p.m.
On 08/22/2011 07:07 PM, Adam Williamson wrote:
On Sun, 2011-08-21 at 17:09 -0400, Steve Clark wrote:
>> -Steve
> Obviously a lot on this list value boot up speed over security!
You're making a false assumption, which is that socket activation is
only about speed. It's also about resource usage. (There may be other
advantages I haven't considered, this is not to be considered an
exclusive list.)
Mmmm Adam - not sure I'd give up security for a little resource saving
either ... if indeed that is the trade-off ...
gene
7:19 p.m.
On Mon, 2011-08-22 at 20:09 -0400, Genes MailLists wrote:
On 08/22/2011 07:07 PM, Adam Williamson wrote:
> On Sun, 2011-08-21 at 17:09 -0400, Steve Clark wrote:
>
>>> -Steve
>> Obviously a lot on this list value boot up speed over security!
>
> You're making a false assumption, which is that socket activation is
> only about speed. It's also about resource usage. (There may be other
> advantages I haven't considered, this is not to be considered an
> exclusive list.)
Mmmm Adam - not sure I'd give up security for a little resource saving
either ... if indeed that is the trade-off ...
Well, there's a question of whether you're really giving up security.
There's no actual vulnerability at issue here, just the theory that
systemd is more susceptible to vulnerabilities.
(It's also worth noting that, when the question is put baldly, we all
claim to value security over everything else, yet we do silly,
non-optimal-for-security-purposes things like disabling SELinux. Or
saving passwords. Or using the Internet. Or using X...remember,
security's a rabbit hole, and if you dive too far down it, you end up
sitting at a terminal with no network connection, feeling secure yet
ineffably lonely...:>)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
7:32 p.m.
On Mon, 22.08.11 17:19, Adam Williamson (awilliam(a)redhat.com) wrote:
On Mon, 2011-08-22 at 20:09 -0400, Genes MailLists wrote:
> On 08/22/2011 07:07 PM, Adam Williamson wrote:
> > On Sun, 2011-08-21 at 17:09 -0400, Steve Clark wrote:
> >
> >>> -Steve
> >> Obviously a lot on this list value boot up speed over security!
> >
> > You're making a false assumption, which is that socket activation is
> > only about speed. It's also about resource usage. (There may be other
> > advantages I haven't considered, this is not to be considered an
> > exclusive list.)
>
>
> Mmmm Adam - not sure I'd give up security for a little resource saving
> either ... if indeed that is the trade-off ...
Well, there's a question of whether you're really giving up security.
There's no actual vulnerability at issue here, just the theory that
systemd is more susceptible to vulnerabilities.
As mentioned a couple of times systemd does not read a single network
packet, hence I'd claim systemd is no worse than sysvinit+xinetd+a lot
of stuff, yet a lot more powerful. (xinetd processes a lot of crazy
network protocols internally, and one could argue that it hence is
actually much worse here than systemd. Also, since it duplicates service
execution in two daemons the amount of code to audit is doubled.)
In fact, systemd offers quite a number security features to secure your
services wich can be easily used to enhance local security. I'll
probably blog about this soonishly, but there's a lot of nice stuff in
there. For example, set "PrivateNetwork=yes" in a service file and the
service will be entirely cut off from the network, so that no network
interfaces are visible anymore. It will only have access to a private,
isolated instance of the loopback device. This is something we should
set for a number of services which never should get network access, like
upower, dbus, or colord. Another really simple option like this is
"PrivateTmp=yes" which gives the service a private, isolated /tmp
directory, so that it won't see and cannot access other processes'
files. Stuff like this is really easy to use, and brings immediate
security benefits, since it locks services into flexible jails,
minimizing the attack surface and locking in exploiters.
I am sure that in sum systemd is a net benefit for security.
Lennart
--
Lennart Poettering - Red Hat, Inc.
12:22 a.m.
On Mon, Aug 22, 2011 at 4:32 PM, Lennart Poettering <mzerqung(a)0pointer.de>wrote:
In fact, systemd offers quite a number security features to secure
your
services wich can be easily used to enhance local security. I'll
probably blog about this soonishly, but there's a lot of nice stuff in
there. For example, set "PrivateNetwork=yes" in a service file and the
service will be entirely cut off from the network, so that no network
interfaces are visible anymore. It will only have access to a private,
isolated instance of the loopback device. This is something we should
set for a number of services which never should get network access, like
upower, dbus, or colord. Another really simple option like this is
"PrivateTmp=yes" which gives the service a private, isolated /tmp
directory, so that it won't see and cannot access other processes'
files. Stuff like this is really easy to use, and brings immediate
security benefits, since it locks services into flexible jails,
minimizing the attack surface and locking in exploiters.
Fascinating. Very fascinating. For the sake of argument, what would I have
to do on a sysvinit-ish system (say F14) to get dbus on an equivalent
private network?
-jef
5:45 a.m.
On Mon, 22.08.11 21:22, Jef Spaleta (jspaleta(a)gmail.com) wrote:
On Mon, Aug 22, 2011 at 4:32 PM, Lennart Poettering
<mzerqung(a)0pointer.de>wrote:
> In fact, systemd offers quite a number security features to secure your
> services wich can be easily used to enhance local security. I'll
> probably blog about this soonishly, but there's a lot of nice stuff in
> there. For example, set "PrivateNetwork=yes" in a service file and the
> service will be entirely cut off from the network, so that no network
> interfaces are visible anymore. It will only have access to a private,
> isolated instance of the loopback device. This is something we should
> set for a number of services which never should get network access, like
> upower, dbus, or colord. Another really simple option like this is
> "PrivateTmp=yes" which gives the service a private, isolated /tmp
> directory, so that it won't see and cannot access other processes'
> files. Stuff like this is really easy to use, and brings immediate
> security benefits, since it locks services into flexible jails,
> minimizing the attack surface and locking in exploiters.
Fascinating. Very fascinating. For the sake of argument, what would I have
to do on a sysvinit-ish system (say F14) to get dbus on an equivalent
private network?
There isn't really a tool which would provide the equivalent of
PrivateNetwork=yes on sysvinit. At least none I was aware of. You'd have
to write your own service execution tool if you wanted to have something
like that.
Lennart
--
Lennart Poettering - Red Hat, Inc.
5:53 a.m.
On 23 August 2011 01:32, Lennart Poettering <mzerqung(a)0pointer.de> wrote:
This is something we should
set for a number of services which never should get network access, like
upower, dbus, or colord.
As the upstream for two of those, what do I need to do? At the moment
both upower and colord are system activated and thus don't have a unit
file. Cutting off network access seems like a sane thing to do.
Richard.
6:01 a.m.
On Tue, 23.08.11 11:53, Richard Hughes (hughsient(a)gmail.com) wrote:
On 23 August 2011 01:32, Lennart Poettering <mzerqung(a)0pointer.de> wrote:
> This is something we should
> set for a number of services which never should get network access, like
> upower, dbus, or colord.
As the upstream for two of those, what do I need to do? At the moment
both upower and colord are system activated and thus don't have a unit
file. Cutting off network access seems like a sane thing to do.
I'll blog about it and use colord as an example. I'll ping you when I
have done that.
Lennart
--
Lennart Poettering - Red Hat, Inc.
8:30 a.m.
On Monday, August 22, 2011 08:32:57 PM Lennart Poettering wrote:
On Mon, 22.08.11 17:19, Adam Williamson (awilliam(a)redhat.com) wrote:
> On Mon, 2011-08-22 at 20:09 -0400, Genes MailLists wrote:
> > On 08/22/2011 07:07 PM, Adam Williamson wrote:
> > > On Sun, 2011-08-21 at 17:09 -0400, Steve Clark wrote:
> > >>> -Steve
> > >>
> > >> Obviously a lot on this list value boot up speed over security!
> > >
> > > You're making a false assumption, which is that socket activation is
> > > only about speed. It's also about resource usage. (There may be other
> > > advantages I haven't considered, this is not to be considered an
> > > exclusive list.)
I think it was mentioned before that systemd is consuming a lot of memory.
> > Mmmm Adam - not sure I'd give up security for a
little resource
> > saving
> >
> > either ... if indeed that is the trade-off ...
>
> Well, there's a question of whether you're really giving up security.
> There's no actual vulnerability at issue here, just the theory that
> systemd is more susceptible to vulnerabilities.
And that is important. If there is a threat, we have to mitigate the possibility
through good design. Why is postfix composed of several cooperating processes where
sendmail is not? Is there a difference in their security reputations? Why would that
be?
As mentioned a couple of times systemd does not read a single
network
packet, hence I'd claim systemd is no worse than sysvinit+xinetd+a lot
of stuff, yet a lot more powerful. (xinetd processes a lot of crazy
network protocols internally, and one could argue that it hence is
actually much worse here than systemd. Also, since it duplicates service
execution in two daemons the amount of code to audit is doubled.)
Not really. init should be small and not really developed on all the time. Xinetd
would need auditing every upstream release...but there hasn't been any in a long time.
But one of the things that it does is work correctly with MLS. If a network packet
comes in at top secret, it starts the daemon at top secret. I believe that systemd
would start the daemon ranged from system high to low - which is wrong.
-Steve
9:58 p.m.
Steve Grubb wrote:
I think it was mentioned before that systemd is consuming a lot of
memory.
The amount quoted was actually ridiculously small considering both today's
memory sizes and the fact that systemd is a singleton process.
Plus, it can be reduced even further (by something like 90%!) by disabling
SELinux. It's your security stuff which is consuming a lot of memory.
Kevin Kofler
8:05 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/23/2011 10:58 PM, Kevin Kofler wrote:
Steve Grubb wrote:
> I think it was mentioned before that systemd is consuming a lot
> of memory.
The amount quoted was actually ridiculously small considering both
today's memory sizes and the fact that systemd is a singleton
process.
Plus, it can be reduced even further (by something like 90%!) by
disabling SELinux. It's your security stuff which is consuming a
lot of memory.
Kevin Kofler
Well not wanting to get into this war, this is a little bit of the
chicken and the egg. The reason systemd has SELinux memory usage is
because it wants to take on the functions that used to be done by
other processes, like udev labeling of /dev. Impersonating processes
requires SELinux labeling, while listening on sockets. Creating of
content on tmpfs /run requires SELinux Labeling.
So saying systemd has grown because of SELinux is stretching the truth
a little.
With that said, I like some of the features that systemd is bringing
to the table, from a security point of view.
Setting up CGroups properly.
Always starting services with a clean environment, IE the parent of a
service is init rather then some random admin that happened to restart
it.
SELinux has tons of AVC's over the years caused by an admin sitting in
a random directory like /home/dwalsh or /root and starting a service.
Lots of bugs have had to be fixed by services using the environment
of the admin.
Allowing us to potentially eliminate all services from ever talking to
a tty.
I have railed over the years about random root running daemons using
/tmp, and I think systemd using namespacing to change a services view
of /tmp is a good idea.
I think using namespacing to eliminate the network is also a good
idea, especially when combined with SELinux.
One think we need to code up is some additional knowledge into systemd
to say which Types can manage which services. For example we want to
say NetworkManager_t can start/stop ntpd but not start/stop the apache
server. Similarly we want to have a confined admin type webadm_t that
can only start and stop the apache service. In Fedora 14/15 we do
this by labeling the initrc script.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5U9vwACgkQrlYvE4MpobOuzgCgnyx3tceuOGuu5xpZNmMVzjaW
m28An1tXwchUnjdBASir+QwXijPa2eam
=w/w6
-----END PGP SIGNATURE-----
8:38 a.m.
On Wed, 2011-08-24 at 09:05 -0400, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/23/2011 10:58 PM, Kevin Kofler wrote:
> Steve Grubb wrote:
>> I think it was mentioned before that systemd is consuming a lot
>> of memory.
>
> The amount quoted was actually ridiculously small considering both
> today's memory sizes and the fact that systemd is a singleton
> process.
>
> Plus, it can be reduced even further (by something like 90%!) by
> disabling SELinux. It's your security stuff which is consuming a
> lot of memory.
>
> Kevin Kofler
>
Well not wanting to get into this war, this is a little bit of the
chicken and the egg. The reason systemd has SELinux memory usage is
because it wants to take on the functions that used to be done by
other processes, like udev labeling of /dev. Impersonating processes
requires SELinux labeling, while listening on sockets. Creating of
content on tmpfs /run requires SELinux Labeling.
So saying systemd has grown because of SELinux is stretching the truth
a little.
I think you can say it is a plain lie, it's neither fault. Systemd took
over some functions done by other processes so the memory is used by
systemd and not by these other processes. It is a shift in which process
uses what. It is true this memory is then carried around by systemd
forever, but that's not a big deal. It saves a lot of time on process
activation for changes that need to happen on the fly and when not used
the kernel is perfectly capable of swapping out whatever is not needed.
Yay for memory overcommitting kernels!
And before people wonder if I am one of 4/5 try to shot systemd down, I
am not. I think it has very good features, and just need to round some
rough edges in order to make it easier to transition.
And I say this even though systemd is giving my group a headache because
there is a strong disconnect between the way it works and the way we
start services in a sysv environment.
With that said, I like some of the features that systemd is bringing
to the table, from a security point of view.
/me too!
Setting up CGroups properly.
Always starting services with a clean environment, IE the parent of a
service is init rather then some random admin that happened to restart
it.
This is a truly good feature, the amount of pain people go through with
SELinux because old init files carried the admin user context around
instead of setting up the proper context is gone.
Even people that knew what was going on were tricked regularly by this
insanity, and it was all due to a very poor init system.
SELinux has tons of AVC's over the years caused by an admin
sitting in
a random directory like /home/dwalsh or /root and starting a service.
Lots of bugs have had to be fixed by services using the environment
of the admin.
Don't forget mismatching labels on files due to this and then the
service fails to start at boot because at that point it is started with
the right SELinux label and it is prevented access to its own files
(just like it happens with some daemons when they are started as roo by
mistake and then they refuse to work if you start them with their own
users because their files are owned by root and not r/w by the
unprivileged daemon user).
Allowing us to potentially eliminate all services from ever talking
to
a tty.
Another really goos thing!
I have railed over the years about random root running daemons using
/tmp, and I think systemd using namespacing to change a services view
of /tmp is a good idea.
I think using namespacing to eliminate the network is also a good
idea, especially when combined with SELinux.
Yes, we still need some change for stuff that unfortunately relies
on /tmp like kerberos credentials caches. I hope we'll be able to move
them under SSSD control soom so that will be one less problem on the
road to make private, per-user, /tmp dirs.
One think we need to code up is some additional knowledge into
systemd
to say which Types can manage which services. For example we want to
say NetworkManager_t can start/stop ntpd but not start/stop the apache
server. Similarly we want to have a confined admin type webadm_t that
can only start and stop the apache service. In Fedora 14/15 we do
this by labeling the initrc script.
Excellent!
Simo.
--
Simo Sorce * Red Hat, Inc * New York
10:35 p.m.
On Mon, 2011-08-22 at 20:09 -0400, Genes MailLists wrote:
On 08/22/2011 07:07 PM, Adam Williamson wrote:
> On Sun, 2011-08-21 at 17:09 -0400, Steve Clark wrote:
>
>>> -Steve
>> Obviously a lot on this list value boot up speed over security!
>
> You're making a false assumption, which is that socket activation is
> only about speed. It's also about resource usage. (There may be other
> advantages I haven't considered, this is not to be considered an
> exclusive list.)
Mmmm Adam - not sure I'd give up security for a little resource saving
either ... if indeed that is the trade-off ...
Well, socket activation gives you better speed and resource usage as
already mentioned, but it also gives you: (from [1])
- We no longer need to configure dependencies explicitly. Since the
sockets are initialized before all services they are simply available,
and no userspace ordering of service start-up needs to take place
anymore. Socket activation hence drastically simplifies configuration
and development of services.
- If a service dies its listening socket stays around, not losing a
single message. After a restart of the crashed service it can continue
right where it left off.
- If a service is upgraded we can restart the service while keeping
around its sockets, thus ensuring the service is continously responsive.
Not a single connection is lost during the upgrade.
- We can even replace a service during runtime in a way that is
invisible to the client. For example, all systems running systemd start
up with a tiny syslog daemon at boot which passes all log messages
written to /dev/log on to the kernel message buffer. That way we provide
reliable userspace logging starting from the first instant of boot-up.
Then, when the actual rsyslog daemon is ready to start we terminate the
mini daemon and replace it with the real daemon. And all that while
keeping around the original logging socket and sharing it between the
two daemons and not losing a single message. Since rsyslog flushes the
kernel log buffer to disk after start-up all log messages from the
kernel, from early-boot and from runtime end up on disk.
So basically, much improved service availability (which is what matters
to your business, isn't it?), and easier configuration/maintenance
(granted, once you've learnt the new commands/tricks).
Knowing that the security issue is highly exaggerated (as Lennart has
repeatedly stated, systemd doesn't read network packets), does that seem
like a better trade-off?
[1] http://0pointer.de/blog/projects/socket-activation.html
--
Mathieu
5:24 p.m.
Mathieu Bridon wrote:
Well, socket activation gives you better speed and resource usage as
already mentioned, but it also gives you:
[some really nifty features]
So basically, much improved service availability (which is what matters
to your business, isn't it?), and easier configuration/maintenance
(granted, once you've learnt the new commands/tricks).
Knowing that the security issue is highly exaggerated (as Lennart has
repeatedly stated, systemd doesn't read network packets), does that seem
like a better trade-off?
It might be an acceptable trade-off but I'm not yet convinced that such a
trade-off is necessary. Is it really impossible to have both a simple, network-
unaware Init and all the nifty features of SystemD?
Imagine a stripped-down Init that does only two things: First it forks and
executes SystemD, and then it just sits around and reaps orphan zombies.
SystemD would then run as process 2 and do all its socket activation and other
magic from there. Process 1 would then be immune to network-based attacks, and
it would be possible to kill SystemD if desired (although it would surely
leave the system rather handicapped).
The only thing I can think of that would be a problem is if SystemD needs to
be notified when processes die even when those processes aren't children of
SystemD. Is that the case? Is there anything else that only process 1 can do?
Björn Persson
6:03 p.m.
On Wed, 24.08.11 00:24, Björn Persson (bjorn(a)xn--rombobjrn-67a.se) wrote:
Mathieu Bridon wrote:
> Well, socket activation gives you better speed and resource usage as
> already mentioned, but it also gives you:
>
[some really nifty features]
>
> So basically, much improved service availability (which is what matters
> to your business, isn't it?), and easier configuration/maintenance
> (granted, once you've learnt the new commands/tricks).
>
> Knowing that the security issue is highly exaggerated (as Lennart has
> repeatedly stated, systemd doesn't read network packets), does that seem
> like a better trade-off?
It might be an acceptable trade-off but I'm not yet convinced that such a
trade-off is necessary. Is it really impossible to have both a simple, network-
unaware Init and all the nifty features of SystemD?
Imagine a stripped-down Init that does only two things: First it forks and
executes SystemD, and then it just sits around and reaps orphan zombies.
SystemD would then run as process 2 and do all its socket activation and other
magic from there. Process 1 would then be immune to network-based attacks, and
it would be possible to kill SystemD if desired (although it would surely
leave the system rather handicapped).
The only thing I can think of that would be a problem is if SystemD needs to
be notified when processes die even when those processes aren't children of
SystemD. Is that the case? Is there anything else that only process 1 can do?
systemd is actually nicely stripped down. I am not sure what people
think that is so bloated in PID 1? Is this hate for D-Bus, what is it?
I am pretty sure systemd will win any competition in size and resource
usage when you compare a systemd system with one built of a number of
similar components, which offer the same functionality. And why is that
so? Since it's lean C, and since it reuses common code as much as
possible. If you have your bazaar of basic building blocks like we used
to have it on Linux then the simple fact is that a big chunk of that
code is just the same stuff implemented over and over again. You have
the daemonization stuff, you have the process supervision, you have
local IPC systems, for each and every component reimplemented again and
again. And all these reimplementations have in common that they suck and
are limited, and do not even remotely compare to the feature set that
systemd offers you in trivially easy to use settings. (I mean, come on,
PrivateNetwork=yes, you must love that, can't you guys admit that?)
You know, there's a reason why systemd is popular for all kinds of
embedded setups, why it is being used in mobile devices, on MeeGo, in
cars, in children's toys, in household machines and all the other stuff:
because it minimizes the stuff you need to build a system and reduces
duplication, and guarantees robustness that was previously not
available. I mean, seriously, we can run syslog now in a way that it can
crash and can be restarted without losing a single packet, and all that
fully in parallel getting rid of all dependencies and stuff. How awesome
is that? Can you really see no benefit in all of this?
I really honestly wished the troupe of you four or five people who keep
trying to noisily shoot systemd down on fedora-devel would actually try
to understand what is going on. Try to get the bigger picture. Try for
once to see if there might be something good in systemd, because there's
a lot.
People tend to be opposed to change, unless the change happens in there
very own interest area. I can understand that you are not interested in
having the init system change, that you know sysvinit and never felt the
need to change it. But please, you need to to understand that this is a
very limited view of the world. Progress needs to take place, if there
are good reasons for it -- and we have plenty good reasons! If we stay
stuck in 80's Unix then we'll not be able to compete, because nobody
will be waiting for us. Nobody will. The OS market is moving fast, and
so must we.
Seriously guys, embrace progress, and help us getting things right. Just
sitting there on the mailing list, and complaining when it already is
too late anyway and the train already left the station is just not
helpful, and makes the lifes of those who care, who do the improvement
work hard.
It is easy to develop a negative opinion, but I kinda get the feeling
that up to 85% of all criticism I get on this unfriendly place that is
fedora-devel is simply because the people complaining didn't bother to
read the docs, ask around, or even use google.
So guys, be more positive. Everybody can be a complain sometimes, but
complaining all the time will make people not care for you anymore and
will make people just shut off and ignore you. And hell yeah, I am
this > < close to it.
I am sure you can come with a ton of theoretical attacks on systemd, if
you think that calling socket() from PID 1 is indeed the worst thing a
program can do on this world. You'll probably be very much alone (or
well, you'll probably be joined by the rest of your troupe) in your
paranoia however, and if invoking socket() was really that dangerous it
probably should be fixed in the kernel. OTOH, if you tried to be
positive you could also remove your tunnel vision on theoretic (and in
reality non-existing) problems and see the security benefits systemd
gives you. We provide packagers, developers, administrators with very
very easy hooks to make their services secure (I will blog about this),
and we give you all controls to limit resources in almost every possible
way in order to avoid DoS, we allow you to flexible jail your services
in namespaces. We do this making use of capabilities, namespaces,
certain cgroup controllers. We also guarantee execution of all services
in pristine execution contexts whith no leaking execution data, and do a
ton of other stuff to make things easily securable. And that is an
absolute first on Linux, heck even on Unix. I am pretty sure at least
that systemd is the first and still only init system that provides you
with options like CapabilityBoundingSet= or PrivateNetwork= or
ReadOnlyDirectories=. Can you name me even one init system empowering
you with powerful (and simple!) tools like this to secure execution of
services? Upstart doesn't, sysvinit doesn't, SMF doesn't, launchd
doesn't. I am listening!
So, if you guys keep repeating that systemd was bloated or insecure then
I'll just ignore you because the truth lies very differently: a real
systemd system will be smaller and more secure than a sysvinit system.
Thank you,
Lennart
--
Lennart Poettering - Red Hat, Inc.
7:06 p.m.
On Wed, Aug 24, 2011 at 1:03 AM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
On Wed, 24.08.11 00:24, Björn Persson (bjorn(a)xn--rombobjrn-67a.se) wrote:
> Imagine a stripped-down Init that does only two things: First it forks and
> executes SystemD, and then it just sits around and reaps orphan zombies.
> SystemD would then run as process 2 and do all its socket activation and other
> magic from there. Process 1 would then be immune to network-based attacks, and
> it would be possible to kill SystemD if desired (although it would surely
> leave the system rather handicapped).
>
> The only thing I can think of that would be a problem is if SystemD needs to
> be notified when processes die even when those processes aren't children of
> SystemD. Is that the case? Is there anything else that only process 1 can do?
systemd is actually nicely stripped down. I am not sure what people
think that is so bloated in PID 1? Is this hate for D-Bus, what is it?
* From the
UI perspective, systemd _is_ bloated. The "UI surface" of
systemd is really large, and it's getting larger all the time. The
amount of components that the admin now sees in the same place as the
most important httpd server has what, quadrupled?
* From the design perspective, it's, compared to UNIX tradition, a
very extensive single component (even ignoring /lib/systemd/*) that's
difficult to take advantage of in pieces.
* From the attack surface perspective, systemd does increase it.
* As for moving things out of PID 1, that looks plausible from the
outside - although restarting the "PID 2" would likely be difficult
and unreliable, and perhaps not worth it, but some things really don't
have to be in there, see below.
* As for D-Bus... I'm not a fan of having its own implementation of
"glib-lite", but *shrug*
I am pretty sure systemd will win any competition in size and
resource
usage when you compare a systemd system with one built of a number of
similar components, which offer the same functionality.
That's not the relevant
question. Just because systemd provides a
feature doesn't mean that others have to do it as well in order to be
worthy of being included in the comparison.
And why is that
so? Since it's lean C, and since it reuses common code as much as
possible. If you have your bazaar of basic building blocks like we used
to have it on Linux then the simple fact is that a big chunk of that
code is just the same stuff implemented over and over again. You have
the daemonization stuff, you have the process supervision, you have
local IPC systems, for each and every component reimplemented again and
again.
Right, but _all of these implementations in these daemons still exist
after you add systemd_. So the total amount of code, total attack
surface, total complexity of the system is larger with systemd.
And all these reimplementations have in common that they suck and
are limited, and do not even remotely compare to the feature set that
systemd offers you in trivially easy to use settings. (I mean, come on,
PrivateNetwork=yes, you must love that, can't you guys admit that?)
Why? There
already is unshare(1) - or even systemd-nspawn. Why is it
so necessary to provide this functionality
1) in PID 1
2) in the main daemon process of systemd (which, as argued by Björn,
perhaps shouldn't be PID 1)
3) and, ultimately, in the same software package as PID 1?
You know, there's a reason why systemd is
<advertisement>
Can you really see no benefit in all of this?
Can you really
see no cost and complexity in all of this? As one who
has spent a few months trying to get /etc/init.d/* reliable, I'm all
for eliminating PID files and so on, and systemd provides that - only
if I accept the rest, which is not always so appealing.
Progress needs to take place, if there
are good reasons for it -- and we have plenty good reasons! If we stay
stuck in 80's Unix then we'll not be able to compete, because nobody
will be waiting for us.
And if we run away from our users, we'll not be able to
compete
because we won't be on their map :)
Seriously guys, embrace progress, and help us getting things right.
Just
sitting there on the mailing list, and complaining when it already is
too late anyway and the train already left the station is just not
helpful,
*shrug* Apparently complaining 17 months ago was not helpful either...
We provide packagers, developers, administrators with very
very easy hooks to make their services secure (I will blog about this),
and we give you all controls to limit resources in almost every possible
way in order to avoid DoS, we allow you to flexible jail your services
in namespaces. We do this making use of capabilities, namespaces,
certain cgroup controllers. We also guarantee execution of all services
in pristine execution contexts whith no leaking execution data, and do a
ton of other stuff to make things easily securable. And that is an
absolute first on Linux, heck even on Unix. I am pretty sure at least
that systemd is the first and still only init system that provides you
with options like CapabilityBoundingSet= or PrivateNetwork= or
ReadOnlyDirectories=. Can you name me even one init system empowering
you with powerful (and simple!) tools like this to secure execution of
services? Upstart doesn't, sysvinit doesn't, SMF doesn't, launchd
doesn't. I am listening!
This is supposed to be attractive, but it is really
borders on scary.
To use the same kind of exaggerating presentation, systemd is already
more than three times as large as the UNIX v7 kernel! libpam is
included only for PAMName= - and Google can find only two mentions of
PAMName outside of this mailing list, and no distribution or project
using it. I do hope the features advertised above are different.
Why does the focus seem to be on packing as many features into systemd
as possible, instead of any of:
* compatibility in the boring details (such as SysV service ordering)
* completeness of transition (e.g. having packaging ready guidelines
_before_ GA)
* seamlessness of transition (replacing things one at a time, keeping
100% compatibility)
* user friendlines (providing sysadmins an UI that treats a single
"server" as a single unit instead of several), or perhaps
* reusability (making the service execution facility available _to_
things such as cron and PAM)
? At least to me, anything of the above would be more appealing than
the dash to pack as many things into systemd.exec as possible.
So, if you guys keep repeating that systemd was bloated or insecure
then
I'll just ignore you because the truth lies very differently: a real
systemd system will be smaller and more secure than a sysvinit system.
I really
look forward to seeing you prepare, submit upstream _and_ get
accepted patches that remove the existing duplicate implementations,
then. That's the difficult part.
Mirek
7:35 p.m.
Lennart Poettering <mzerqung <at> 0pointer.de> writes:
...
I really honestly wished the troupe of you four or five people who keep
trying to noisily shoot systemd down on fedora-devel would actually try
to understand what is going on. Try to get the bigger picture. Try for
once to see if there might be something good in systemd, because there's
a lot.
...
Lennart,
we are not going to sacrify UNIX/Linux, SysVinit, even systemd (the product
of you, your co-developers, and ... imported ideas from "one song for one USD"
company) for your ego, which is larger than life.
We try to help you understand the principles of UNIX development - you ignore
them and the poeple who were guided by them for 30-40 years in their
professional life.
You even try to belittle them, people who are clearly superior in their
professional experience and understanding of UNIX in general, and are quite
capable of assessing the value of systemd.
It is obvious that you do *not* understand them.
You were once even so silly that you went to FreeBSD people and told them to
abandon it and join Linux world instead.
And you want to offer them what ? Your understanding of (or lack thereof)
this UNIX-like Linux principles we want to be guided by and preserve ?
Grow up, man !
These people here dedicate their time, exchange info and ideas, analyze, point
at problems, offer solutions, share experience and knowledge with you, and
that all to correct more and less obvious defficiencies in systemd project.
All they get in return is "mine is bigger than yours" attitude. As if anything
they said, and documented, and supported was not worth a dime because it is
agains your "worldview".
Do you realise what kind of havoc you caused in Fedora releases, current and
future, not only in SysVinit area, but also in others.
It is even worse, you blame them for problems of your own making, suspecting
us of some kind of conspiracy against you and the goals and quality of your
pet project called systemd.
Grow up, man !
You are offending all these good people who are on this list dealing with you
and your project.
You really do not expect them to accept your sick "world domination" drive
and its product as a viable UNIX/Linux standard to be included in this Fedora,
later Red Hat, and other distros, as you stated you expect it to happen, do
you ?
Grow up, man !
JB
7:47 p.m.
On 08/24/2011 06:05 AM, JB wrote:
Lennart,
we are not going to sacrify UNIX/Linux, SysVinit, even systemd (the product
of you, your co-developers, and ... imported ideas from "one song for one USD"
company) for your ego, which is larger than life.
This type of personal attacks in this list is not acceptable. It is ok
to disagree on technical matters but you have gone well beyond that in
this mail.
Rahul
4:33 a.m.
On 24 August 2011 01:35, JB <jb.1234abcd(a)gmail.com> wrote:
...do not expect them to accept your sick "world
domination" drive
...and this is why some upstream developers have unsubscribed from
fedora-devel list. Ever wonder why people like David Zeuthen
unsubscribed? People like you.
I'm also ---> <--- this close to unsubscribing also.
Richard.
7:18 a.m.
Richard Hughes <hughsient <at> gmail.com> writes:
On 24 August 2011 01:35, JB <jb.1234abcd <at> gmail.com> wrote:
> ...do not expect them to accept your sick "world domination" drive
...and this is why some upstream developers have unsubscribed from
fedora-devel list. Ever wonder why people like David Zeuthen
unsubscribed? People like you.
I'm also ---> <--- this close to unsubscribing also.
Richard.
Richard,
before you do it, read his post again and his insinuations about conspiracies
and other staff !
If this is his state of mind about the project quality and people on this list
who try to help him and themselves, then I propose that he unsubscribes from
this list as well.
Do you know how many people disappeared from Fedora orbit entirely or stopped
with F14 release due to his systemd project alone ?
Do you remember world's reaction on www.osnews.com to his "world
domination"
plans with regard to systemd and GNOME project ?
This guy is a loose cannon, with an outsized ego, but lacking UNIX
understanding and design skills.
There is a video on Youtube (I can not find the link right now, it is on
www.osnews.com article in comments section) from a German Linux sysadmin
presentation in Munich, in 2009 I believe - with Lennart present in
the audience and constantly interrupting the presenter and putting him down.
Read the comments there by people who watched it !
Lennart, if you read this post go back to that video recording and experience
it again. After that come back here and apologize for your attitude !
You do not deserve to be treated so well by us !
It is an embarrassment to watch this list's threads regarding systemd, its
deficiencies, havoc it has caused, and these sysadmin software dev people
trying to straighten things up, and his refusal to do it (or even consider it).
JB
7:40 a.m.
On Wed, Aug 24, 2011 at 12:18:57PM +0000, JB wrote:
Richard Hughes <hughsient <at> gmail.com> writes:
>
> On 24 August 2011 01:35, JB <jb.1234abcd <at> gmail.com> wrote:
> > ...do not expect them to accept your sick "world domination" drive
>
> ...and this is why some upstream developers have unsubscribed from
> fedora-devel list. Ever wonder why people like David Zeuthen
> unsubscribed? People like you.
>
> I'm also ---> <--- this close to unsubscribing also.
>
> Richard.
Richard,
before you do it, read his post again and his insinuations about conspiracies
and other staff !
[...snip...]
This thread really is starting to sound like personal vendetta and not
worthwhile discussion of technical details. Seriously, cut it out.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
7:40 a.m.
JB <jb.1234abcd <at> gmail.com> writes:
...
There is a video on Youtube (I can not find the link right now, it is on
www.osnews.com article in comments section) from a German Linux sysadmin
presentation in Munich, in 2009 I believe - with Lennart present in
the audience and constantly interrupting the presenter and putting him down.
Read the comments there by people who watched it !
Lennart, if you read this post go back to that video recording and
experience it again. After that come back here and apologize for your
attitude !
You do not deserve to be treated so well by us !
...
Here it is.
http://www.osnews.com/comments/24926
I really couldn't just let this occasion pass
by Lennie on Thu 7th Jul 2011 22:12 UTC
OK, this is a presentation by someone who manages many Linux-desktops and is
used to how things used to be in the Unix/Linux world.
Good or bad, things have changed in the last few years in most Linux
distributions.
The presenter is trying to explain what is has become more complicated or
isn't even possible anymore with the new setup.
'luckily' Lennart Poettering was in the audience to 'help' explain why :
http://www.youtube.com/watch?v=_ERAXJj142o
The presentation is funny and sad at the same time. It shows you what he is
like and what he thinks.
Lennart Poettering has vision of what thinks need to be improved for Linux on
the desktop (possible server too). But he seems to always want to do big
changes and not every idea always actually reaches it's full potential.
His intensions are obviously good, but maybe he doesn't work well with others
as he doesn't let others choose what they want. Like with systemd, where he
has basically said: "the Linux API is the new Posix"
I've got a feeling Lennart Poettering will never be loved in the Linux
community because of it.
Especially not by the BSD-community ;-)
Edited 2011-07-07 22:17 UTC
Enjoy it !
JB
9:42 a.m.
FYI, I have placed JB on moderation on this list.
I'll be happy to let through posts that are not personal attacks.
kevin
7:48 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 24/08/11 14:18, JB wrote:
This guy is a loose cannon, with an outsized ego, but lacking UNIX
understanding and design skills.
Ok, it's getting clear, both of you won't become best friends.
Assuming, all arguments were written to this list, please stop
affronts on him. This has nothing to do with systemd's quality,
however do you rate it.
Thanks
- --
Matthias Runge <mrunge(a)matthias-runge.de>
<mrunge(a)fedoraproject.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOVPMeAAoJEOnz8qQwcaIWorQH/0WXPyHcXI7Kra9bQ1qGio6g
DyVd7RIen+ue/7GYwnqPGbVLMWq43QOh6YBCuxO3h6s8xIxULRqsp1GTmJXzysgD
zV4nZXYqkQxrkCeV1brv/8rG9FV1y4djxL6avMRM/VlvZkjF3U918XbfSEq/NRXW
Gk1bvFbKR1KCmt06heDwEMHjf6cevah6VsWZBQbDgMt1sNof3nfJkDupd2FS93vm
qGnnP7ScyUQA1dAbojhgrD6eWv8qsCSDf1Kg2WLDv5G7/KPVwBgndaWDTHjXgvn1
ugZxNNcstj4O8Mu8kS8MPCp5fO8q5iZK98RT5PGIuGf621QZtTM7pWAVnCaePBI=
=d85W
-----END PGP SIGNATURE-----
7:58 p.m.
Lennart, please don't shut off and stop listening just yet.
I realize that your rant was aimed at this whole thread rather than at my post
specifically, but I'd like to make it clear that I'm not one of those who
"keep
trying to noisily shoot systemd down" as you put it. I see a lot of value in
SystemD. I wrote that is has some really nifty features and I meant it. I also
do feel the need to change the init system. I have written a few initscripts
and I'm definitely not satisfied with that way of doing things. Thank you so
much for writing SystemD!
I think SystemD is a really exciting improvement, but I also think Steve Grubb
may have a good point or two. There are some people on this list who are best
ignored in my opinion, but I think Steve Grubb may be worth listening to. He
seems to know what he's talking about when it comes to security. I hardly
think replacing SystemD with XinetD would be a good idea, but if you can find a
way of addressing his concerns without complicating things too much, it just
might be worth doing.
If you read my previous post again when you have calmed down a bit, I think
you'll see that I didn't complain but tried to suggest a way forward. I'll
admit that I know nothing about the internal design of SystemD and can't judge
what is feasible and what isn't. Moving most of the functionality to process 2
may or may not be a good idea, but it was meant as a constructive proposal – a
possible improvement that might help to make security-minded people like Steve
Grubb feel more comfortable about SystemD.
I also want to say that I'm impressed with how you usually manage to stay calm
and keep to the point despite all the abuse you seem to always get for
everything you do. I'm not sure I could do the same if I were in your
situation.
Björn Persson
12:54 p.m.
On Sat, 20.08.11 04:50, Kevin Kofler (kevin.kofler(a)chello.at) wrote:
Tim Waugh wrote:
> Oh, I just noticed this:
>
> https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activa...
> "Since Fedora currently doesn't want any services to do on-demand
> loading, all socket activated services must autostart."
What the heck?! We're disabling systemd's main feature there, aren't we?
Wasn't the main design concept behind systemd the observation that
everything can be parallelized most effectively by on-demand activation?
While it is of course disappointing if we do not use lazy socket
activation of CUPS in Fedora the ability to do lazy socket activation is
only one of the many benefits of socket activation. I'd claim the most
interesting advantage of socket activation is that it drastically
improves parallelization and simplifies the execution ordering logic at
boot-up.
Lennart
--
Lennart Poettering - Red Hat, Inc.
10:33 a.m.
Once upon a time, Tim Waugh <twaugh(a)redhat.com> said:
On Wed, 2011-08-17 at 20:04 +0530, Rahul Sundaram wrote:
> https://fedoraproject.org/wiki/Starting_services_by_default
Ah, thanks. So it looks like CUPS can be enabled by default:
"If a service does not require configuration to be functional and is not
network enabled, it may be enabled by default"
Is CUPS functional without any configuration? How do you print without
configuring a printer?
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
4637
days inactive
4645
days old
157 comments
42 participants
participants (42)
-
Adam Williamson -
Aleksandar Kurtakov -
Andrew McNabb -
Bill Nottingham -
Björn Persson -
Chris Adams -
Clyde E. Kunkel -
Daniel J Walsh -
drago01 -
Genes MailLists -
Hans de Goede -
JB -
Jef Spaleta -
Jesse Keating -
Jóhann B. Guðmundsson -
Kevin Fenzi -
Kevin Kofler -
Lars Seipel -
Lennart Poettering -
Mathieu Bridon -
Matthew Garrett -
Matthias Runge -
Michael Cronenworth -
Miloslav Trmač -
Ola Thoresen -
Orion Poplawski -
Paul W. Frields -
Przemek Klosowski -
Rahul Sundaram -
Reindl Harald -
Richard Hughes -
Robert Marcano -
Seth Vidal -
Simo Sorce -
Stephen John Smoogen -
Steve Clark -
Steve Grubb -
Tim Waugh -
Tom Callaway -
Tom Lane -
Tomasz Torcz -
Toshio Kuratomi