subject:"Default services enabled"

On Tue, 2011-08-23 at 17:28 -0400, Tom Lane wrote:
 Simo Sorce s...@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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-24 Thread Daniel J Walsh

-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-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

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 s...@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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-24 Thread Matthew Garrett

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 | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-24 Thread Reindl Harald



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




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled - there is no problem with mysqld

2011-08-24 Thread Reindl Harald



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



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-24 Thread Kevin Fenzi

FYI, I have placed JB on moderation on this list. 

I'll be happy to let through posts that are not personal attacks. 

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-24 Thread Hans de Goede

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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-24 Thread Tom Lane

Simo Sorce s...@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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

On Wed, 2011-08-24 at 11:08 -0400, Tom Lane wrote:
 Simo Sorce s...@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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-24 Thread Adam Williamson

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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-24 Thread Adam Williamson

On Wed, 2011-08-24 at 11:08 -0400, Tom Lane wrote:
 Simo Sorce s...@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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

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 s...@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


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-24 Thread Alexander Kurtakov

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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-24 Thread Jef Spaleta

On Wed, Aug 24, 2011 at 9:22 AM, Alexander Kurtakov akurt...@redhat.comwrote:

 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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled - there is no problem with mysqld

On Wed, 24.08.11 10:45, Tom Lane (t...@redhat.com) wrote:

 
 Reindl Harald h.rei...@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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-24 Thread Andrew McNabb

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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-24 Thread Jef Spaleta

On Wed, Aug 24, 2011 at 9:31 AM, Jef Spaleta jspal...@gmail.com wrote:



 On Wed, Aug 24, 2011 at 9:22 AM, Alexander Kurtakov 
 akurt...@redhat.comwrote:

 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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

On Wed, 24.08.11 10:56, Simo Sorce (s...@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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

On Wed, 24.08.11 11:40, Andrew McNabb (amcn...@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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

On Wed, 24.08.11 10:05, Adam Williamson (awill...@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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

On Wed, 24.08.11 20:22, Alexander Kurtakov (akurt...@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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

On Wed, 24.08.11 10:10, Jesse Keating (jkeat...@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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

On Wed, 2011-08-24 at 19:44 +0200, Lennart Poettering wrote:
 On Wed, 24.08.11 10:56, Simo Sorce (s...@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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

On Wed, 2011-08-24 at 20:19 +0200, Lennart Poettering wrote:
 On Wed, 24.08.11 10:10, Jesse Keating (jkeat...@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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-24 Thread Adam Williamson

On Wed, 2011-08-24 at 19:59 +0200, Lennart Poettering wrote:
 On Wed, 24.08.11 10:05, Adam Williamson (awill...@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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

On Aug 24, 2011, at 11:19 AM, Lennart Poettering wrote:
 On Wed, 24.08.11 10:10, Jesse Keating (jkeat...@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


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-24 Thread Bill Nottingham

Jesse Keating (jkeat...@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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-24 Thread Lars Seipel

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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

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


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

On Aug 24, 2011, at 12:49 PM, Bill Nottingham wrote:
 Jesse Keating (jkeat...@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


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

On Mon, 22.08.11 21:22, Jef Spaleta (jspal...@gmail.com) wrote:

 On Mon, Aug 22, 2011 at 4:32 PM, Lennart Poettering 
 mzerq...@0pointer.dewrote:
 
  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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-23 Thread Richard Hughes

On 23 August 2011 01:32, Lennart Poettering mzerq...@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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

On Tue, 23.08.11 11:53, Richard Hughes (hughsi...@gmail.com) wrote:

 
 On 23 August 2011 01:32, Lennart Poettering mzerq...@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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-23 Thread drago01

On Mon, Aug 22, 2011 at 6:45 PM, Tom Callaway tcall...@redhat.com wrote:
 On 08/18/2011 06:28 AM, Lennart Poettering wrote:
 On Wed, 17.08.11 16:43, Tim Waugh (twa...@redhat.com) wrote:

 Oh, I just noticed this:

 https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activation
 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).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-23 Thread Richard Hughes

On 23 August 2011 12:01, Lennart Poettering mzerq...@0pointer.de wrote:
 I'll blog about it and use colord as an example. I'll ping you when I
 have done that.

Legend, thanks.

Richard.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-23 Thread Steve Grubb

On Monday, August 22, 2011 08:32:57 PM Lennart Poettering wrote:
 On Mon, 22.08.11 17:19, Adam Williamson (awill...@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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-23 Thread Tom Callaway

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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-23 Thread Przemek Klosowski

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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-23 Thread Toshio Kuratomi

On Tue, Aug 23, 2011 at 01:12:31PM +0200, drago01 wrote:
 On Mon, Aug 22, 2011 at 6:45 PM, Tom Callaway tcall...@redhat.com wrote:
  On 08/18/2011 06:28 AM, Lennart Poettering wrote:
  On Wed, 17.08.11 16:43, Tim Waugh (twa...@redhat.com) wrote:
 
  Oh, I just noticed this:
 
  https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activation
  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


pgpWb2Rn2nQAN.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

On Tue, 23.08.11 07:29, Toshio Kuratomi (a.bad...@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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

On Tue, 2011-08-23 at 16:57 +0200, Lennart Poettering wrote:
 On Tue, 23.08.11 07:29, Toshio Kuratomi (a.bad...@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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

On Tue, 23.08.11 11:10, Simo Sorce (s...@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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

On Tue, 2011-08-23 at 17:44 +0200, Lennart Poettering wrote:
 On Tue, 23.08.11 11:10, Simo Sorce (s...@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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

On Tue, 23.08.11 11:56, Simo Sorce (s...@redhat.com) wrote:

 
 On Tue, 2011-08-23 at 17:44 +0200, Lennart Poettering wrote:
  On Tue, 23.08.11 11:10, Simo Sorce (s...@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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

On Tue, 2011-08-23 at 18:14 +0200, Lennart Poettering wrote:
 On Tue, 23.08.11 11:56, Simo Sorce (s...@redhat.com) wrote:
 
  
  On Tue, 2011-08-23 at 17:44 +0200, Lennart Poettering wrote:
   On Tue, 23.08.11 11:10, Simo Sorce (s...@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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-23 Thread Adam Williamson

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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

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 ?

http://news.icanhascheezburger.com/2010/06/22/political-pictures-make-a-windows-that-doesnt-crash/

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-23 Thread Steve Clark

On 08/23/2011 01:48 PM, JB wrote:

JBjb.1234abcdat gmail.com writes:

...

Here are some more detailed thoughts.

Sockets activation and on-demand services.
--
Here is a description of how it works:
http://0pointer.de/blog/projects/socket-activation.html

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 # 1 of an attack venue.
-
Here is a possible known example:
http://www.securiteam.com/unixfocus/6U00P1PEVQ.html

Can you comment on that ?

http://news.icanhascheezburger.com/2010/06/22/political-pictures-make-a-windows-that-doesnt-crash/

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.cl...@netwolves.com
http://www.netwolves.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

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




-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

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


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

On Tue, 23.08.11 17:48, JB (jb.1234a...@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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-23 Thread Bill Nottingham

Tom Callaway (tcall...@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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-23 Thread Stephen John Smoogen

On Tue, Aug 23, 2011 at 13:37, Bill Nottingham nott...@redhat.com wrote:
 Tom Callaway (tcall...@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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

On Tue, 23.08.11 13:54, Stephen John Smoogen (smo...@gmail.com) wrote:

 
 On Tue, Aug 23, 2011 at 13:37, Bill Nottingham nott...@redhat.com wrote:
  Tom Callaway (tcall...@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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-23 Thread drago01

On Tue, Aug 23, 2011 at 4:29 PM, Toshio Kuratomi a.bad...@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 tcall...@redhat.com wrote:
  On 08/18/2011 06:28 AM, Lennart Poettering wrote:
  On Wed, 17.08.11 16:43, Tim Waugh (twa...@redhat.com) wrote:
 
  Oh, I just noticed this:
 
  https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activation
  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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-23 Thread Bill Nottingham

Stephen John Smoogen (smo...@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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

On Tue, 2011-08-23 at 21:33 +0200, Lennart Poettering wrote:
 On Tue, 23.08.11 17:48, JB (jb.1234a...@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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

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


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-23 Thread Tom Lane

Simo Sorce s...@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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

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


signature.asc
Description: This is a digitally signed message part.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-23 Thread Adam Williamson

On Tue, 2011-08-23 at 17:28 -0400, Tom Lane wrote:
 Simo Sorce s...@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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

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


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-23 Thread Tom Lane

Adam Williamson awill...@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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

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


signature.asc
Description: This is a digitally signed message part.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

On Tue, 23.08.11 18:11, Tom Lane (t...@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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-23 Thread Adam Williamson

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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

On Wed, 24.08.11 00:24, Björn Persson (bjorn@rombobjörn.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

Re: Default services enabled

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


signature.asc
Description: This is a digitally signed message part.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-23 Thread Miloslav Trmač

On Wed, Aug 24, 2011 at 1:03 AM, Lennart Poettering
mzerq...@0pointer.de wrote:
 On Wed, 24.08.11 00:24, Björn Persson (bjorn@rombobjörn.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

Re: Default services enabled

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


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

2011-08-23 Thread Rahul Sundaram

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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled