Re: Default services enabled
Actually there is another reason for socket activation to use AF_INET as well as AF_UNIX: doing so prevents e.g. rpc.statd from port-squatting. In fact, this is why CUPS no longer ships to ship a portreserve file. Tim. */ 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
Am 24.08.2011 20:40, schrieb Adam Williamson: > On Wed, 2011-08-24 at 19:59 +0200, Lennart Poettering wrote: >> On Wed, 24.08.11 10:05, Adam Williamson (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_ and that is why you need only socket-activation for the unix-socket to provide relieable system-boot with activation and you nagios will check over TCP and so has NOTHING really NOTHING to do with systemd 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
Am 24.08.2011 19:36, schrieb Lennart Poettering: > On Wed, 24.08.11 10:45, Tom Lane (t...@redhat.com) wrote: > >> >> Reindl Harald writes: >>> Am 23.08.2011 23:28, schrieb Tom Lane: there's no other way for "mysqladmin ping" to work, for example >> >>> and where is the problem? >> >> I'm not planning on repeating myself either, but: a database >> *monitoring* tool, as opposed to a vanilla client, needs to know whether >> the database is in fact up. Autostarting the DB in response to a >> monitoring probe is the wrong behavior for that. > > Are you sure it is? The thing is that when using socket activation it is > merely an implementation detail when a service is actually really > started. If you get a response you get a response and that's what you > probably want to monitor. and what he does not understand is that the socket is only needed LOCAL nagios as brought example normally runs on a monitoring host and checks the TCP port, sad enough that we have to explain this the mysql-maintainer where will a monitoring over the network trigger the socket below? TCP port is directly mysqld in this case [root@srv-rhsoft:~]$ cat /lib/systemd/system/mysqld.socket [Unit] Description=MySQL Database activation socket [Socket] ListenStream=/var/lib/mysql/mysql.sock [Install] WantedBy=sockets.target signature.asc Description: OpenPGP digital signature -- 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 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 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
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
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
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 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
On Wed, 2011-08-24 at 19:57 +0200, Lennart Poettering wrote: > On Wed, 24.08.11 11:18, Simo Sorce (s...@redhat.com) wrote: > > > > FWIW, I do think that there may be use-cases for socket activation of a > > > database. I'd like to support the option ... the problem is to do so > > > without breaking existing, expected behaviors. > > > > I am not sure you can, the only would be to have systemd have some way > > to get callbacks from service to know when they are actually ready to > > serve. This would make "After" more meaningful. > > Hmm, we have that. The traditional way is Type=forking plus double > forking+exit in the parent. The nicer modern way is Type=notify and > sd_notify("READY=1"). > > I am not entirely I am sure I follow what you are asking for, but do you > need more thatn this? Ah although I have read the systemd header files that are used for inclusion in apps I completely forgot about sd_notify(). I don't think anything else is really necessary. Thanks! Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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, 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, 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 17:09, Hans de Goede (hdego...@redhat.com) wrote: > > Hi, > > On 08/24/2011 04:56 PM, Simo Sorce wrote: > > On Wed, 2011-08-24 at 15:10 +0100, Matthew Garrett wrote: > >> On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote: > >>> On Tue, 2011-08-23 at 14:37 -0700, Adam Williamson wrote: > Why not? > > If the service is enabled but the daemon not currently running, is it so > terrible for a connection test to cause the daemon to start? Remember, > in systemd logic 'service enabled with socket activation, daemon not > currently running' is effectively an 'on' state, not an 'off' state. If > you wanted the database to be 'off' you should have the service > disabled, and in that case, the ping test wouldn't cause the daemon to > start. > >>> > >>> It generally is a bad idea to automatically restart a database based on > >>> a random connection. There many reasons why you may have stopped the db > >>> (or it may have stopped itself) and requires inspection before > >>> attempting a new restart. Having to battle with socket activation while > >>> in a critical situation is not a good idea. > >> > >> You'd have the same problem with any init system that supports automatic > >> service restarting. You can easily disable the service via systemctl. > > > > You can do that if you are doing a planned outage. But not for unplanned > > ones. > > > > I am not saying automatic restarts should never be employed, only that > > not all software should be automatically restarted. I think databases > > shouldn't in most cases. But that's just my opinion on the specific > > case. That doesn't mean socket-activation shouldn't be employed in other > > cases. > > So maybe we need a socket-activate-once attribute for .service files, > which makes systemd do the socket activation only once, hmm thinking of > it, doesn't it do that already in the form of handing the listening fd over? > > So if a service is set to not auto restart the service I would expect > the order would be: > > 1) systemd starts > 2) systemd creates listening socket > 3) connection comes in > 4) systemd starts foodb, hands overlistening socket > 5) foodb crashes > 6) db is dead, no one listening to socket. > > Right? I guess that unless auto-restart is set for the service, systemd > won't re-create the listening socket and start listening itself again on > step 6. If it does I'm sure that the systemd authors are very reasonable > people and we can tell them that socket activation should not imply > auto-restart on daemon crash / exit (unless explicitly requested). I think what you are basically asking for is that we propagate the failure state from the service unit to the socket unit, right? As mentioned in another mail I just sent this has been on the todo list for a while. Lennart -- Lennart Poettering - Red Hat, Inc. -- 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 11:18, Simo Sorce (s...@redhat.com) wrote: > > FWIW, I do think that there may be use-cases for socket activation of a > > database. I'd like to support the option ... the problem is to do so > > without breaking existing, expected behaviors. > > I am not sure you can, the only would be to have systemd have some way > to get callbacks from service to know when they are actually ready to > serve. This would make "After" more meaningful. Hmm, we have that. The traditional way is Type=forking plus double forking+exit in the parent. The nicer modern way is Type=notify and sd_notify("READY=1"). I am not entirely I am sure I follow what you are asking for, but do you need more thatn this? Lennart -- Lennart Poettering - Red Hat, Inc. -- 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: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, Aug 24, 2011 at 9:31 AM, Jef Spaleta wrote: > > > On Wed, Aug 24, 2011 at 9:22 AM, Alexander Kurtakov > wrote: > >> I want to add one more POV - not every database is constantly-used. >> Example >> usage is Amarok using mysql database and I really want mysql to not be >> started >> until I start Amarok. Not that this is very common usage scenario but >> still I >> know at least one guy using Amarok with mysql :). >> >> You are using a system-wide network exposed mysql for Amarok? Is this > mysql serving information to multiple clients or multiple users? If its > system-wide and only being used by one application by one user, why is it > being run system-wide? > And to belabor the point a bit more. We really need to have distinct discussions about what a system service "default" is and what its okay for local admins are encourage/discourage/allowed to do. If you need to run a private instance of mysql on non-standard network ports to serve a local Amarok application in an on-demand fashion. Then you can do that as a local admin. In fact working with the mysql packager you might be able to use systemd's support for multiple instances to make it easier to set that up without it interfering with the system default mysql. However, does it make since to write the default init for the system-wide mysql with this usage case in mind? I'm not sure. It could very well be that for right now the system wide mysql default init needs to refrain from socket activation as mysql is primarily aimed at a server workload and not an on-demand workload. Any service that primarily services remote systems instead of local applications will probably want to start up fully at boot and not on demand later. I guess that's sort of the sane boundary for me with regard to socket activiation. If a service wants to see the outside world via tcp sockets...probably should not be on-demand by default. If its unix socket only..it can probably be a socket activated service. There will be of course things that break that simple rule..but as I guide I think it will work as a starting point for service packagers. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
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 -> there is no problem with mysqld
On Wed, 24.08.11 10:45, Tom Lane (t...@redhat.com) wrote: > > Reindl Harald 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
On Wed, Aug 24, 2011 at 9:22 AM, Alexander Kurtakov wrote: > I want to add one more POV - not every database is constantly-used. Example > usage is Amarok using mysql database and I really want mysql to not be > started > until I start Amarok. Not that this is very common usage scenario but > still I > know at least one guy using Amarok with mysql :). > > You are using a system-wide network exposed mysql for Amarok? Is this mysql serving information to multiple clients or multiple users? If its system-wide and only being used by one application by one user, why is it being run system-wide? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
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
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 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
On Wed, 2011-08-24 at 11:08 -0400, Tom Lane wrote: > Simo Sorce 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 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
On Wed, 2011-08-24 at 11:08 -0400, Tom Lane wrote: > Simo Sorce 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
Simo Sorce 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
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
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 -> there is no problem with mysqld
Reindl Harald writes: > Am 23.08.2011 23:28, schrieb Tom Lane: >> there's no other way for "mysqladmin ping" to work, for example > and where is the problem? I'm not planning on repeating myself either, but: a database *monitoring* tool, as opposed to a vanilla client, needs to know whether the database is in fact up. Autostarting the DB in response to a monitoring probe is the wrong behavior for that. I do not really care whether you believe that that's a problem or not; it is in my eyes, and as the responsible engineer, I'm not going to produce a broken database package. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
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 -> there is no problem with mysqld
Am 23.08.2011 23:28, schrieb Tom Lane: > Yeah. Another way in which socket activation is not transparent is that > code might try to determine whether the service is running by seeing > whether a connection attempt succeeds. well if you have enabled the service and a listening socket it is the definition of RUNNING > In such a case, having the service autostart is absolutely *not* the desired > outcome. why not? if you have it enabled you expect that it is there > Both mysql and postgresql suffer from this problem you see a problem where no problem is > there's no other way for "mysqladmin ping" to work, for example and where is the problem? this is expected do you not undertsand the fact that if i ENABLE mysqld i expect that it is listening and if anything checks if mysql is available it has to get YES at answer if mysqld is enabled from the begin of the boot process > This issue is currently preventing both of those databases from being > packaged as > socket-activated services. nothing is preventing anything because you see a problem where no problem exists and with your view you make problems on machines where a lot of services are depending on mysql i tried to explain this thousands of times and getting tired of your non-understanding that mysqld has to accept connections as soon as possible and if oyu do not want mysqld started so do NOT enable mysqld > I could try to get the upstreams to think > about inventing non-connection-based protocols for testing database > server status, but I doubt that either one will be receptive they will reject you because you are the only person seeing a problem and not because there is one signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
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
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
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
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 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
-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 17:28 -0400, Tom Lane wrote: > Simo Sorce 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/08/11 14:18, JB wrote: > This guy is a loose cannon, with an outsized ego, but lacking UNIX > understanding and design skills. Ok, it's getting clear, both of you won't become best friends. Assuming, all arguments were written to this list, please stop affronts on him. This has nothing to do with systemd's quality, however do you rate it. Thanks - -- Matthias Runge -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOVPMeAAoJEOnz8qQwcaIWorQH/0WXPyHcXI7Kra9bQ1qGio6g DyVd7RIen+ue/7GYwnqPGbVLMWq43QOh6YBCuxO3h6s8xIxULRqsp1GTmJXzysgD zV4nZXYqkQxrkCeV1brv/8rG9FV1y4djxL6avMRM/VlvZkjF3U918XbfSEq/NRXW Gk1bvFbKR1KCmt06heDwEMHjf6cevah6VsWZBQbDgMt1sNof3nfJkDupd2FS93vm qGnnP7ScyUQA1dAbojhgrD6eWv8qsCSDf1Kg2WLDv5G7/KPVwBgndaWDTHjXgvn1 ugZxNNcstj4O8Mu8kS8MPCp5fO8q5iZK98RT5PGIuGf621QZtTM7pWAVnCaePBI= =d85W -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
JB gmail.com> writes: > ... > There is a video on Youtube (I can not find the link right now, it is on > www.osnews.com article in comments section) from a German Linux sysadmin > presentation in Munich, in 2009 I believe - with Lennart present in > the audience and constantly interrupting the presenter and putting him down. > Read the comments there by people who watched it ! > Lennart, if you read this post go back to that video recording and > experience it again. After that come back here and apologize for your > attitude ! > You do not deserve to be treated so well by us ! > ... Here it is. http://www.osnews.com/comments/24926 I really couldn't just let this occasion pass by Lennie on Thu 7th Jul 2011 22:12 UTC OK, this is a presentation by someone who manages many Linux-desktops and is used to how things used to be in the Unix/Linux world. Good or bad, things have changed in the last few years in most Linux distributions. The presenter is trying to explain what is has become more complicated or isn't even possible anymore with the new setup. 'luckily' Lennart Poettering was in the audience to 'help' explain why : http://www.youtube.com/watch?v=_ERAXJj142o The presentation is funny and sad at the same time. It shows you what he is like and what he thinks. Lennart Poettering has vision of what thinks need to be improved for Linux on the desktop (possible server too). But he seems to always want to do big changes and not every idea always actually reaches it's full potential. His intensions are obviously good, but maybe he doesn't work well with others as he doesn't let others choose what they want. Like with systemd, where he has basically said: "the Linux API is the new Posix" I've got a feeling Lennart Poettering will never be loved in the Linux community because of it. Especially not by the BSD-community ;-) Edited 2011-07-07 22:17 UTC Enjoy it ! JB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Wed, Aug 24, 2011 at 12:18:57PM +, JB wrote: > Richard Hughes gmail.com> writes: > > > > > On 24 August 2011 01:35, JB gmail.com> wrote: > > > ...do not expect them to accept your sick "world domination" drive > > > > ...and this is why some upstream developers have unsubscribed from > > fedora-devel list. Ever wonder why people like David Zeuthen > > unsubscribed? People like you. > > > > I'm also ---> <--- this close to unsubscribing also. > > > > Richard. > > Richard, > > before you do it, read his post again and his insinuations about conspiracies > and other staff ! [...snip...] This thread really is starting to sound like personal vendetta and not worthwhile discussion of technical details. Seriously, cut it out. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
Richard Hughes gmail.com> writes: > > On 24 August 2011 01:35, JB gmail.com> wrote: > > ...do not expect them to accept your sick "world domination" drive > > ...and this is why some upstream developers have unsubscribed from > fedora-devel list. Ever wonder why people like David Zeuthen > unsubscribed? People like you. > > I'm also ---> <--- this close to unsubscribing also. > > Richard. Richard, before you do it, read his post again and his insinuations about conspiracies and other staff ! If this is his state of mind about the project quality and people on this list who try to help him and themselves, then I propose that he unsubscribes from this list as well. Do you know how many people disappeared from Fedora orbit entirely or stopped with F14 release due to his systemd project alone ? Do you remember world's reaction on www.osnews.com to his "world domination" plans with regard to systemd and GNOME project ? This guy is a loose cannon, with an outsized ego, but lacking UNIX understanding and design skills. There is a video on Youtube (I can not find the link right now, it is on www.osnews.com article in comments section) from a German Linux sysadmin presentation in Munich, in 2009 I believe - with Lennart present in the audience and constantly interrupting the presenter and putting him down. Read the comments there by people who watched it ! Lennart, if you read this post go back to that video recording and experience it again. After that come back here and apologize for your attitude ! You do not deserve to be treated so well by us ! It is an embarrassment to watch this list's threads regarding systemd, its deficiencies, havoc it has caused, and these sysadmin software dev people trying to straighten things up, and his refusal to do it (or even consider it). JB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Tue, Aug 23, 2011 at 06:11:45PM -0400, Tom Lane wrote: > Another way of saying this is: people are used to being able to check > if a service is up without thereby changing its state. Consider for > example somebody who has a nagios alert set to check database server > availability every few seconds. If that probe results in Yes, but I think this kind of monitoring appeared because SysV initscript is not reliable in determining service status. Even "status" command sometimes checkes only existence of PID file, not the real status. In world with systemd, monitoring can just ask systemd if service is running. Systemd will provide reliable answer, and if service is not running, will provide information for how long it is stopped and what was the reason for failure. -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On 24 August 2011 01:35, JB wrote: > ...do not expect them to accept your sick "world domination" drive ...and this is why some upstream developers have unsubscribed from fedora-devel list. Ever wonder why people like David Zeuthen unsubscribed? People like you. I'm also ---> <--- this close to unsubscribing also. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
Lennart, please don't shut off and stop listening just yet. I realize that your rant was aimed at this whole thread rather than at my post specifically, but I'd like to make it clear that I'm not one of those who "keep trying to noisily shoot systemd down" as you put it. I see a lot of value in SystemD. I wrote that is has some really nifty features and I meant it. I also do feel the need to change the init system. I have written a few initscripts and I'm definitely not satisfied with that way of doing things. Thank you so much for writing SystemD! I think SystemD is a really exciting improvement, but I also think Steve Grubb may have a good point or two. There are some people on this list who are best ignored in my opinion, but I think Steve Grubb may be worth listening to. He seems to know what he's talking about when it comes to security. I hardly think replacing SystemD with XinetD would be a good idea, but if you can find a way of addressing his concerns without complicating things too much, it just might be worth doing. If you read my previous post again when you have calmed down a bit, I think you'll see that I didn't complain but tried to suggest a way forward. I'll admit that I know nothing about the internal design of SystemD and can't judge what is feasible and what isn't. Moving most of the functionality to process 2 may or may not be a good idea, but it was meant as a constructive proposal – a possible improvement that might help to make security-minded people like Steve Grubb feel more comfortable about SystemD. I also want to say that I'm impressed with how you usually manage to stay calm and keep to the point despite all the abuse you seem to always get for everything you do. I'm not sure I could do the same if I were in your situation. Björn Persson 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 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
Lennart Poettering 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
On Wed, Aug 24, 2011 at 1:03 AM, Lennart Poettering 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 > 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 prett
Re: Default services enabled
JB wrote: > Björn Persson 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
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
Re: Default services enabled
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 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
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
Adam Williamson 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
Björn Persson 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
On Tue, 2011-08-23 at 17:28 -0400, Tom Lane wrote: > Simo Sorce 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
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
Simo Sorce 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
Lennart Poettering 0pointer.de> writes: > > On Tue, 23.08.11 17:48, JB (jb.1234abcd 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
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
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, Aug 23, 2011 at 4:29 PM, Toshio Kuratomi wrote: > On Tue, Aug 23, 2011 at 01:12:31PM +0200, drago01 wrote: >> On Mon, Aug 22, 2011 at 6:45 PM, Tom Callaway 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
On Tue, 23.08.11 13:54, Stephen John Smoogen (smo...@gmail.com) wrote: > > On Tue, Aug 23, 2011 at 13:37, Bill Nottingham 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
On Tue, Aug 23, 2011 at 13:37, Bill Nottingham 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
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= 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
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
Steve Clark 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 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
Adam Williamson 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
On 08/23/2011 01:48 PM, JB wrote: JB gmail.com> writes: ... Here are some more detailed thoughts. Sys init. - Sys init as a process #1 should be "beyond approach" by design, and delegate all work to other process(es), whether in a permanent or an ad-hoc manner, that can be operated by sysadmin if needed (e.g. restarted, initialized, configured, fixed, etc). We want it to be minimal in its size, minimal in its functions, simple, stable, secure (no attack venues, direct or indirect) - yes, "beyond approach". Sockets activation and on-demand services. -- Here is a description of how it works: http://0pointer.de/blog/projects/socket-activation.html The essense begins here: "Socket activation makes it possible to start all (...) services completely simultaneously, without any kind of ordering. ... That means the scheduling of our services is entirely done by the kernel: ,,," Then it continues: "But it's not just about parallelization. It offers a number of other benefits: ... We no longer need to configure dependencies explicitly. Since the sockets are initialized before all services they are simply available ... If a service dies its listening socket stays around, not losing a single message. After a restart of the crashed service it can continue right where it left off. ..." Well, it looks like a "wunderwaffe" :-) Systemd and security - an example # 2 of an attack venue. - The above is dangerous as a design idea to achieve "parallelization" of services. Let's assume that service A is a dependency for service B (and others). After A's on-demand socket has been put "on hold" (blocking), the A may die or lock up for any reason, that is never to come up again by itself as an active service. That means there is a system lock-up possibility here while B (and others) are "on hold" too (waiting for A to be unblocked), and wait ..., and wait ... Systemd and security - an example # 1 of an attack venue. - Here is a possible known example: http://www.securiteam.com/unixfocus/6U00P1PEVQ.html We know that systemd owns the service socket-in-waiting (with its buffer). In case of an attack on socket buffer availability via kernel the systemd is grounded as well. This should not be allowed to happen to process #1, the Mother of All Processes. One more reason to redesign the systemd to be minimal and "beyond approach", and instead have other restartable "child" process(es) take over the function of on-demand socket handling. Can you comment on that ? JB http://news.icanhascheezburger.com/2010/06/22/political-pictures-make-a-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
JB gmail.com> writes: > ... Here are some more detailed thoughts. Sys init. - Sys init as a process #1 should be "beyond approach" by design, and delegate all work to other process(es), whether in a permanent or an ad-hoc manner, that can be operated by sysadmin if needed (e.g. restarted, initialized, configured, fixed, etc). We want it to be minimal in its size, minimal in its functions, simple, stable, secure (no attack venues, direct or indirect) - yes, "beyond approach". Sockets activation and on-demand services. -- Here is a description of how it works: http://0pointer.de/blog/projects/socket-activation.html The essense begins here: "Socket activation makes it possible to start all (...) services completely simultaneously, without any kind of ordering. ... That means the scheduling of our services is entirely done by the kernel: ,,," Then it continues: "But it's not just about parallelization. It offers a number of other benefits: ... We no longer need to configure dependencies explicitly. Since the sockets are initialized before all services they are simply available ... If a service dies its listening socket stays around, not losing a single message. After a restart of the crashed service it can continue right where it left off. ..." Well, it looks like a "wunderwaffe" :-) Systemd and security - an example # 2 of an attack venue. - The above is dangerous as a design idea to achieve "parallelization" of services. Let's assume that service A is a dependency for service B (and others). After A's on-demand socket has been put "on hold" (blocking), the A may die or lock up for any reason, that is never to come up again by itself as an active service. That means there is a system lock-up possibility here while B (and others) are "on hold" too (waiting for A to be unblocked), and wait ..., and wait ... Systemd and security - an example # 1 of an attack venue. - Here is a possible known example: http://www.securiteam.com/unixfocus/6U00P1PEVQ.html We know that systemd owns the service socket-in-waiting (with its buffer). In case of an attack on socket buffer availability via kernel the systemd is grounded as well. This should not be allowed to happen to process #1, the Mother of All Processes. One more reason to redesign the systemd to be minimal and "beyond approach", and instead have other restartable "child" process(es) take over the function of on-demand socket handling. Can you comment on that ? JB http://news.icanhascheezburger.com/2010/06/22/political-pictures-make-a-windows-that-doesnt-crash/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
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
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
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 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: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 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 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, Aug 23, 2011 at 01:12:31PM +0200, drago01 wrote: > On Mon, Aug 22, 2011 at 6:45 PM, Tom Callaway 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 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
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
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
On 23 August 2011 12:01, Lennart Poettering 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
On Mon, Aug 22, 2011 at 6:45 PM, Tom Callaway 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
On Tue, 23.08.11 11:53, Richard Hughes (hughsi...@gmail.com) wrote: > > On 23 August 2011 01:32, Lennart Poettering 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
On 23 August 2011 01:32, Lennart Poettering 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 Mon, 22.08.11 21:22, Jef Spaleta (jspal...@gmail.com) wrote: > On Mon, Aug 22, 2011 at 4:32 PM, Lennart Poettering > wrote: > > > In fact, systemd offers quite a number security features to secure your > > services wich can be easily used to enhance local security. I'll > > probably blog about this soonishly, but there's a lot of nice stuff in > > there. For example, set "PrivateNetwork=yes" in a service file and the > > service will be entirely cut off from the network, so that no network > > interfaces are visible anymore. It will only have access to a private, > > isolated instance of the loopback device. This is something we should > > set for a number of services which never should get network access, like > > upower, dbus, or colord. Another really simple option like this is > > "PrivateTmp=yes" which gives the service a private, isolated /tmp > > directory, so that it won't see and cannot access other processes' > > files. Stuff like this is really easy to use, and brings immediate > > security benefits, since it locks services into flexible jails, > > minimizing the attack surface and locking in exploiters. > > Fascinating. Very fascinating. For the sake of argument, what would I have > to do on a sysvinit-ish system (say F14) to get dbus on an equivalent > private network? There isn't really a tool which would provide the equivalent of PrivateNetwork=yes on sysvinit. At least none I was aware of. You'd have to write your own service execution tool if you wanted to have something like that. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Mon, Aug 22, 2011 at 4:32 PM, Lennart Poettering wrote: > In fact, systemd offers quite a number security features to secure your > services wich can be easily used to enhance local security. I'll > probably blog about this soonishly, but there's a lot of nice stuff in > there. For example, set "PrivateNetwork=yes" in a service file and the > service will be entirely cut off from the network, so that no network > interfaces are visible anymore. It will only have access to a private, > isolated instance of the loopback device. This is something we should > set for a number of services which never should get network access, like > upower, dbus, or colord. Another really simple option like this is > "PrivateTmp=yes" which gives the service a private, isolated /tmp > directory, so that it won't see and cannot access other processes' > files. Stuff like this is really easy to use, and brings immediate > security benefits, since it locks services into flexible jails, > minimizing the attack surface and locking in exploiters. > > Fascinating. Very fascinating. For the sake of argument, what would I have to do on a sysvinit-ish system (say F14) to get dbus on an equivalent private network? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Mon, 2011-08-22 at 20:09 -0400, Genes MailLists wrote: > On 08/22/2011 07:07 PM, Adam Williamson wrote: > > On Sun, 2011-08-21 at 17:09 -0400, Steve Clark wrote: > > > >>> -Steve > >> Obviously a lot on this list value boot up speed over security! > > > > You're making a false assumption, which is that socket activation is > > only about speed. It's also about resource usage. (There may be other > > advantages I haven't considered, this is not to be considered an > > exclusive list.) > > > Mmmm Adam - not sure I'd give up security for a little resource saving > either ... if indeed that is the trade-off ... Well, socket activation gives you better speed and resource usage as already mentioned, but it also gives you: (from [1]) - We no longer need to configure dependencies explicitly. Since the sockets are initialized before all services they are simply available, and no userspace ordering of service start-up needs to take place anymore. Socket activation hence drastically simplifies configuration and development of services. - If a service dies its listening socket stays around, not losing a single message. After a restart of the crashed service it can continue right where it left off. - If a service is upgraded we can restart the service while keeping around its sockets, thus ensuring the service is continously responsive. Not a single connection is lost during the upgrade. - We can even replace a service during runtime in a way that is invisible to the client. For example, all systems running systemd start up with a tiny syslog daemon at boot which passes all log messages written to /dev/log on to the kernel message buffer. That way we provide reliable userspace logging starting from the first instant of boot-up. Then, when the actual rsyslog daemon is ready to start we terminate the mini daemon and replace it with the real daemon. And all that while keeping around the original logging socket and sharing it between the two daemons and not losing a single message. Since rsyslog flushes the kernel log buffer to disk after start-up all log messages from the kernel, from early-boot and from runtime end up on disk. So basically, much improved service availability (which is what matters to your business, isn't it?), and easier configuration/maintenance (granted, once you've learnt the new commands/tricks). Knowing that the security issue is highly exaggerated (as Lennart has repeatedly stated, systemd doesn't read network packets), does that seem like a better trade-off? [1] http://0pointer.de/blog/projects/socket-activation.html -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
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.) > > > > > > Mmmm Adam - not sure I'd give up security for a little resource saving > > either ... if indeed that is the trade-off ... > > Well, there's a question of whether you're really giving up security. > There's no actual vulnerability at issue here, just the theory that > systemd is more susceptible to vulnerabilities. As mentioned a couple of times systemd does not read a single network packet, hence I'd claim systemd is no worse than sysvinit+xinetd+a lot of stuff, yet a lot more powerful. (xinetd processes a lot of crazy network protocols internally, and one could argue that it hence is actually much worse here than systemd. Also, since it duplicates service execution in two daemons the amount of code to audit is doubled.) In fact, systemd offers quite a number security features to secure your services wich can be easily used to enhance local security. I'll probably blog about this soonishly, but there's a lot of nice stuff in there. For example, set "PrivateNetwork=yes" in a service file and the service will be entirely cut off from the network, so that no network interfaces are visible anymore. It will only have access to a private, isolated instance of the loopback device. This is something we should set for a number of services which never should get network access, like upower, dbus, or colord. Another really simple option like this is "PrivateTmp=yes" which gives the service a private, isolated /tmp directory, so that it won't see and cannot access other processes' files. Stuff like this is really easy to use, and brings immediate security benefits, since it locks services into flexible jails, minimizing the attack surface and locking in exploiters. I am sure that in sum systemd is a net benefit for security. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Mon, 2011-08-22 at 20:09 -0400, Genes MailLists wrote: > On 08/22/2011 07:07 PM, Adam Williamson wrote: > > On Sun, 2011-08-21 at 17:09 -0400, Steve Clark wrote: > > > >>> -Steve > >> Obviously a lot on this list value boot up speed over security! > > > > You're making a false assumption, which is that socket activation is > > only about speed. It's also about resource usage. (There may be other > > advantages I haven't considered, this is not to be considered an > > exclusive list.) > > > Mmmm Adam - not sure I'd give up security for a little resource saving > either ... if indeed that is the trade-off ... Well, there's a question of whether you're really giving up security. There's no actual vulnerability at issue here, just the theory that systemd is more susceptible to vulnerabilities. (It's also worth noting that, when the question is put baldly, we all claim to value security over everything else, yet we do silly, non-optimal-for-security-purposes things like disabling SELinux. Or saving passwords. Or using the Internet. Or using X...remember, security's a rabbit hole, and if you dive too far down it, you end up sitting at a terminal with no network connection, feeling secure yet ineffably lonely...:>) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On 08/22/2011 07:07 PM, Adam Williamson wrote: > On Sun, 2011-08-21 at 17:09 -0400, Steve Clark wrote: > >>> -Steve >> Obviously a lot on this list value boot up speed over security! > > You're making a false assumption, which is that socket activation is > only about speed. It's also about resource usage. (There may be other > advantages I haven't considered, this is not to be considered an > exclusive list.) Mmmm Adam - not sure I'd give up security for a little resource saving either ... if indeed that is the trade-off ... gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Sun, 2011-08-21 at 17:09 -0400, Steve Clark wrote: > > -Steve > Obviously a lot on this list value boot up speed over security! You're making a false assumption, which is that socket activation is only about speed. It's also about resource usage. (There may be other advantages I haven't considered, this is not to be considered an exclusive list.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Sun, 2011-08-21 at 20:34 -0400, Steve Grubb wrote: > You're not seeing the hundreds - no thousands of emails about systemd? You > are not Most of which seem to come from you, Reindl, or Steve Clark; a very active cabal doth not a rebellion make. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
Am 22.08.2011 23:58, schrieb Kevin Fenzi: > On Mon, 22 Aug 2011 23:15:38 +0200 > Reindl Harald wrote: > >> >> >> Am 22.08.2011 23:01, schrieb Tom Callaway: >>> On 08/22/2011 04:41 PM, Lennart Poettering wrote: I'd vote for simply making this an implementation detail of the package. I.e. if a package gets the permission to enable its service by default it's up to it whether it wants to be started at boot or via socket actviation of via any other kind of activation. >>> >>> Sure, assuming that FESCo agrees that packages starting by default >>> is the same as socket-enabled start on-demand. >> >> this argumentation is strange and makes no sense > > I think you are confused as to what 'by default' means. > > It means: when you install this package on your Fedora system, will it > start automatically on next boot or not. > > Thats all. You as end user can disable it, enable it, or do whatever > you like with it. Thats your choice. This default is simply talking > about what state it's in when first installed no i am NOT confused if the definition it will be aneabled by default is teh decision if a service can use socket-activation this is foolish because as said there are many services out there which are not default but users decide that they are the reason why a machine is running so i hvae the choice start something at boot but i will never benefit from socket-activation - if this is the case systemd is useless as long for services which are NOT default like mysqld must be done tricks to let systemd wait with the next service until mysqld is full operational - there exists a patch for socket-activation which would solve most of my troubles and after that peopole come out and point at idiotic decisions which forbid socket-activation for the package and finally this idiotic discussion should have been finished BEFORE release F15 wth sytemd and not at a time where it is defacto too late because no one is gonna fixing the bugs and wrong decisions for F15 this time signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On Mon, 22 Aug 2011 23:15:38 +0200 Reindl Harald wrote: > > > Am 22.08.2011 23:01, schrieb Tom Callaway: > > On 08/22/2011 04:41 PM, Lennart Poettering wrote: > >> I'd vote for simply making this an implementation detail of the > >> package. I.e. if a package gets the permission to enable its > >> service by default it's up to it whether it wants to be started at > >> boot or via socket actviation of via any other kind of activation. > > > > Sure, assuming that FESCo agrees that packages starting by default > > is the same as socket-enabled start on-demand. > > this argumentation is strange and makes no sense I think you are confused as to what 'by default' means. It means: when you install this package on your Fedora system, will it start automatically on next boot or not. Thats all. You as end user can disable it, enable it, or do whatever you like with it. Thats your choice. This default is simply talking about what state it's in when first installed. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
Am 22.08.2011 23:01, schrieb Tom Callaway: > On 08/22/2011 04:41 PM, Lennart Poettering wrote: >> I'd vote for simply making this an implementation detail of the >> package. I.e. if a package gets the permission to enable its service by >> default it's up to it whether it wants to be started at boot or via >> socket actviation of via any other kind of activation. > > Sure, assuming that FESCo agrees that packages starting by default is > the same as socket-enabled start on-demand. this argumentation is strange and makes no sense it is uninteresting what is starting per default the USER decides what servcies he needs for whatever the machine should do if you setup a nameserver as example it is useless taht avahi maybe allowed to started as default and named not and because taht named msut not have socket-activation if you have a filserver with samba/netatalk NONE auf the current default-servcies nor named nor avahi nor httpd or anything else is relevant for this machine so explain me why i should this logic not call stupid? some of the people taht making decisions about default-services should start to understand that they are not really in the position to decide for users waht servcies on what machines are important or not and the only reason for such decisions have to be waht is the technical best solution in a maximum of cases without damage user expierience signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On 08/22/2011 04:41 PM, Lennart Poettering wrote: > I'd vote for simply making this an implementation detail of the > package. I.e. if a package gets the permission to enable its service by > default it's up to it whether it wants to be started at boot or via > socket actviation of via any other kind of activation. Sure, assuming that FESCo agrees that packages starting by default is the same as socket-enabled start on-demand. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel