Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Lennart Poettering]

On Fri, 26.11.10 16:18, Michał Piotrowski (mkkp...@gmail.com) wrote:

Sorry for not responding earlier to this, I have been travelling the
last few weeks with little access to the internet.
 
 I tried it
 amtu.service - Abstract Machine Tests
 Loaded: loaded (/lib/systemd/system/amtu.service)
 Active: failed since Fri, 26 Nov 2010 19:12:48 +0100; 11s ago
Process: 2557 (/usr/sbin/amtu $EXTRAOPTIONS, code=exited, status=255)
 CGroup: name=systemd:/system/amtu.service

Your process simply exists with status=255, systemd records that and
give that it is != 0 it will make the service enter failed state. 

Previously the exit code of init scripts did not matter much in
sysvinit, and was usually eaten up. However, in systemd we actually
record if things failed to start up and present them to the user/admin
in systemctl status. This is actually a great advantage of systemd,
even if it sounds trivial enough. It should be a useful tool for admins
to track down services that don't work and why they don't work.

In your specific case it's probably a good idea trying to track down
what exit code 255 means, and maybe look for a message in syslog
explaining what went wrong in the service.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Lennart Poettering]

On Mon, 06.12.10 12:30, Bill Nottingham (nott...@redhat.com) wrote:

 Michał Piotrowski (mkkp...@gmail.com) said: 
   If systemd will allow us to do that, sure.
  
   What's the point here? For example, this doesn't cut down on the number
   of listening ports, obviously, nor on the requirements for root passwords
   and potential root login. And if it's started in parallel, I doubt it's a
   huge drain on resources.
  
  For a fast and efficient boot-up two things are crucial:
  
  * To start less.
  * And to start more in parallel.
  
  http://0pointer.de/blog/projects/systemd.html
  
  IMO start less philosophy is a good thing.
 
 Yes. However, I'm leery of adding too many drastic changes that don't have
 upstream buy-in yet. What's upstream openssh's opinion on socket activation?

There's no need to patch ssh. It can do inetd-style socket activation
just fine, and has been supporting that upstream since basically its
inception. From that I would deduce that upstream is fine with
it. systemd supports inetd-style activation too just fine. MacOS X has
been installing sshd by default with socket activation enabled, and if
they can do that I think we can do that on Fedora, too.


  
(There are cases where socket-activated ssh is not useful, and you want 

  
the real-deal with sshd listening itself, but that shouldn't stop us

  
from installing sshd socket-activated by default, since it is easy to
switch back to the traditional way.) 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Kevin Kofler]

Rahul Sundaram wrote:
 Socket activation is not mandatory or even a benefit in all cases.  Just
 because we have a patch doesn't mean it is the right one.  Upstream might
 have the foresight and the knowledge to see problems with patches we might
 not.  There might be security implications.  It specific cases, we can
 consider overriding upstream decisions but there should be very strong
 reasons to do so.  Just because a license allows it doesn't make it best
 practise.  It is always useful to get more peer reviews from patches with
 the expertise in the codebase.  Upstream is a good place for that.

I believe it is the purpose of a well-integrated distribution to make sure 
distro-wide features are implemented in ALL packages, irrespectively of 
upstream projects' (or even individual package maintainers') personal 
opinions and diverging (from ours) objectives.

Kevin Kofler

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

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Rahul Sundaram]

On Sat, Dec 11, 2010 at 8:11 PM, Kevin Kofler  wrote:

 Rahul Sundaram wrote:
  Socket activation is not mandatory or even a benefit in all cases.  Just
  because we have a patch doesn't mean it is the right one.  Upstream might
  have the foresight and the knowledge to see problems with patches we
 might
  not.  There might be security implications.  It specific cases, we can
  consider overriding upstream decisions but there should be very strong
  reasons to do so.  Just because a license allows it doesn't make it best
  practise.  It is always useful to get more peer reviews from patches with
  the expertise in the codebase.  Upstream is a good place for that.

 I believe it is the purpose of a well-integrated distribution to make sure
 distro-wide features are implemented in ALL packages, irrespectively of
 upstream projects' (or even individual package maintainers') personal
 opinions and diverging (from ours) objectives.


Nothing I said contradicts that however it is not just a question of
personal's opinions.  It is also a question of maintenance (non-upstreamable
patches need to be forwarded ported for updates, might have bugs not in the
upstream codebase.  so your advovacy of abrt reporting bugs upstream is in
contradiction ), expertise in the codebase (upstream is more knowledgeable
typically). Upstream opinions do matter and we need to care even if we
decide on exceptions on some specific cases for good reasons.  We have a
long standing policy of doing so and it is an important part of what Fedora
is.

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

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Kevin Kofler]

Bill Nottingham wrote:
 Right. To do this in systemd implies that you're patching openssh to
 do socket-based activation... hence why I asked about upstream's opinion
 on it.

Why would we care?

It's our goal to have ALL network daemons be socket-activated eventually. 
This is a distribution-wide feature and as such software MUST be patched to 
support it. Doing this kind of integration work is what a distribution is 
for.

We need to stop treating upstream like a sacred cow. It is OUR decision as a 
distribution what we want to ship to our users. The Free licensing of the 
software we ship explicitly allows us to adapt it to any and all of our 
needs.

Kevin Kofler

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

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Kevin Kofler]

Chris Adams wrote:
 The only thing you need a firewall by default for is to prevent services
 that are listening on the network from being accessible.  The better
 solution is to stop having services listen on the network by default.

FWIW, this is what Ubuntu has been doing for ages (they call it zero open 
ports policy), and AFAIK they do not enable iptables by default because of 
this.

That said, zero open ports also got complaints, e.g. because they disabled 
the CUPS web-based configuration interface to close port 631.

Kevin Kofler

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

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Rahul Sundaram]

On Sat, Dec 11, 2010 at 4:57 AM, Kevin Kofler kevin.kof...@chello.atwrote:

 Bill Nottingham wrote:
  Right. To do this in systemd implies that you're patching openssh to
  do socket-based activation... hence why I asked about upstream's opinion
  on it.

 Why would we care?

 It's our goal to have ALL network daemons be socket-activated eventually.
 This is a distribution-wide feature and as such software MUST be patched to
 support it.


Socket activation is not mandatory or even a benefit in all cases.  Just
because we have a patch doesn't mean it is the right one.  Upstream might
have the foresight and the knowledge to see problems with patches we might
not.  There might be security implications.  It specific cases, we can
consider overriding upstream decisions but there should be very strong
reasons to do so.  Just because a license allows it doesn't make it best
practise.  It is always useful to get more peer reviews from patches with
the expertise in the codebase.  Upstream is a good place for that.

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

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Tomas Mraz]

On Mon, 2010-12-06 at 20:08 -0600, Chris Adams wrote: 
 Once upon a time, Adam Williamson awill...@redhat.com said:
  On most laptops, however, which are the most common types of system sold
  today, a firewall is very definitely needed when you're connecting to
  hotel networks, public wifi access points...
 
 The only thing you need a firewall by default for is to prevent services
 that are listening on the network from being accessible.  The better
 solution is to stop having services listen on the network by default.
 
 This was done for sendmail many years ago; why hasn't it been done for
 other things, such as rpcbind (and RPC services), cups, etc.?  These
 daemons should bind to localhost only unless otherwise configured.
In the cups case might be probably reasonable to default to localhost.
However for rpcbind it is clearly not so - what's the point of starting
things that are mostly needed for NFS when you would be able to mount
only NFS provided by the localhost and export it to the localhost only
as well. In that sense it is debatable whether we want to have rpcbind
ON by default but having it on and bind to localhost only does not make
any sense to me.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Chris Adams]

Once upon a time, Tomas Mraz tm...@redhat.com said:
 In the cups case might be probably reasonable to default to localhost.
 However for rpcbind it is clearly not so - what's the point of starting
 things that are mostly needed for NFS when you would be able to mount
 only NFS provided by the localhost and export it to the localhost only
 as well. In that sense it is debatable whether we want to have rpcbind
 ON by default but having it on and bind to localhost only does not make
 any sense to me.

Mounting remote NFS mounts doesn't require allowing the server to query
the local rpcbind, does it?  I think you only need to allow remote
access to rpcbind if you are exporting filesystems, at which point you
are configuring things anyway, so configure rpcbind to listen on the
network.

I don't think this would be a big deal to require, since today you have
to reconfigure the firewall if you are configuring an NFS server.

-- 
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Michał Piotrowski]

2010/12/7 Tomas Mraz tm...@redhat.com:
 On Mon, 2010-12-06 at 20:08 -0600, Chris Adams wrote:
 Once upon a time, Adam Williamson awill...@redhat.com said:
  On most laptops, however, which are the most common types of system sold
  today, a firewall is very definitely needed when you're connecting to
  hotel networks, public wifi access points...

 The only thing you need a firewall by default for is to prevent services
 that are listening on the network from being accessible.  The better
 solution is to stop having services listen on the network by default.

 This was done for sendmail many years ago; why hasn't it been done for
 other things, such as rpcbind (and RPC services), cups, etc.?  These
 daemons should bind to localhost only unless otherwise configured.
 In the cups case might be probably reasonable to default to localhost.
 However for rpcbind it is clearly not so - what's the point of starting
 things that are mostly needed for NFS when you would be able to mount
 only NFS provided by the localhost and export it to the localhost only
 as well. In that sense it is debatable whether we want to have rpcbind
 ON by default but having it on and bind to localhost only does not make
 any sense to me.

How many users use NFS on desktop? This is not even used on all servers.

So the question is - do we want to have NFS by default?

I use samba and I don't want to force all users to install it by default.

 --
 Tomas Mraz
 No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb

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




-- 
Best regards,
Michal

Sent from my iToaster
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Till Maas]

On Mon, Dec 06, 2010 at 08:08:49PM -0600, Chris Adams wrote:
 Once upon a time, Adam Williamson awill...@redhat.com said:
  On most laptops, however, which are the most common types of system sold
  today, a firewall is very definitely needed when you're connecting to
  hotel networks, public wifi access points...
 
 The only thing you need a firewall by default for is to prevent services
 that are listening on the network from being accessible.  The better
 solution is to stop having services listen on the network by default.
 
 This was done for sendmail many years ago; why hasn't it been done for
 other things, such as rpcbind (and RPC services), cups, etc.?  These
 daemons should bind to localhost only unless otherwise configured.

Afaik ntpd, sobby and software written in erlang (e.g. ejabberd) does not
support this (completely).

Regards
Till


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

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Hans de Goede]

Hi,

On 12/06/2010 06:34 AM, Michał Piotrowski wrote:
 Hi,

 W dniu 3 grudnia 2010 09:14 użytkownik Michał Piotrowski
 mkkp...@gmail.com  napisał:
 [..]
 What services are installed by default when installong form Live
 GNOME/KDE/etc and DVD?

 Ok, let's ask the question differently - what services should be run
 by default to provide working system for desktop user?

 IMO ssh can be off by default and should be started only if user tries
 to connect over port 22.

 Do we really need to install iptables/ip6tables by default (it's in core 
 group)?


Do we really need a firewall configured ?

Yes we do because of blinkbSECURITY/b/blink

I'm sorry but asking if we really need iptables by default is just stupid!

Regards,

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

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Michał Piotrowski]

W dniu 6 grudnia 2010 10:43 użytkownik Hans de Goede
hdego...@redhat.com napisał:
 Hi,

 On 12/06/2010 06:34 AM, Michał Piotrowski wrote:
 Hi,

 W dniu 3 grudnia 2010 09:14 użytkownik Michał Piotrowski
 mkkp...@gmail.com  napisał:
 [..]
 What services are installed by default when installong form Live
 GNOME/KDE/etc and DVD?

 Ok, let's ask the question differently - what services should be run
 by default to provide working system for desktop user?

 IMO ssh can be off by default and should be started only if user tries
 to connect over port 22.

 Do we really need to install iptables/ip6tables by default (it's in core 
 group)?


 Do we really need a firewall configured ?

 Yes we do because of blinkbSECURITY/b/blink

 I'm sorry but asking if we really need iptables by default is just stupid!

LOL :)

There are no stupid questions :)

On most desktop systems firewall is not needed. Many users do not even
know how to configure it. In fact I disable it in most of my systems,
because there is no real use for it. So I asked a simple question
whether there is a need to install iptables by default?

Your answer is not satisfactory for me - because not configured
firewall has nothing to do with security. In fact, it can only bring
false sense of security.


 Regards,

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




-- 
Best regards,
Michal

Sent from my iToaster
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Kevin Fenzi]

On Mon, 6 Dec 2010 06:34:45 +0100
Michał Piotrowski mkkp...@gmail.com wrote:

 Hi,
 
 W dniu 3 grudnia 2010 09:14 użytkownik Michał Piotrowski
 mkkp...@gmail.com napisał:
 [..]
  What services are installed by default when installong form Live
  GNOME/KDE/etc and DVD?
 
 Ok, let's ask the question differently - what services should be run
 by default to provide working system for desktop user?

Perhaps we can ask this even more differently: 

What are you trying to do? Whats your high level goal here? 
Boot speed? Number of packages installed? 

 IMO ssh can be off by default and should be started only if user tries
 to connect over port 22.

If systemd will allow us to do that, sure. 

 Do we really need to install iptables/ip6tables by default (it's in
 core group)?

Yes, I think so. Either firewall by default, or we need to make sure
nothing is running that listens externally to reduce security
footprint, IMHO. 

kevin


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

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Bill Nottingham]

Kevin Fenzi (ke...@scrye.com) said: 
  IMO ssh can be off by default and should be started only if user tries
  to connect over port 22.
 
 If systemd will allow us to do that, sure. 

What's the point here? For example, this doesn't cut down on the number
of listening ports, obviously, nor on the requirements for root passwords
and potential root login. And if it's started in parallel, I doubt it's a
huge drain on resources.

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

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Michał Piotrowski]

W dniu 6 grudnia 2010 18:01 użytkownik Kevin Fenzi ke...@scrye.com napisał:
 On Mon, 6 Dec 2010 06:34:45 +0100
 Michał Piotrowski mkkp...@gmail.com wrote:

 Hi,

 W dniu 3 grudnia 2010 09:14 użytkownik Michał Piotrowski
 mkkp...@gmail.com napisał:
 [..]
  What services are installed by default when installong form Live
  GNOME/KDE/etc and DVD?

 Ok, let's ask the question differently - what services should be run
 by default to provide working system for desktop user?

 Perhaps we can ask this even more differently:

 What are you trying to do?

I'm trying to convert sysvinit scripts to systemd services (as many as possible)

 Whats your high level goal here?
 Boot speed? Number of packages installed?

I know it will not be possible to convert all sysvinit scripts for
F15, but at least we can try to provide full systemd experience for
most common configurations.

-- 
Best regards,
Michal

Sent from my iToaster
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Michał Piotrowski]

2010/12/6 Bill Nottingham nott...@redhat.com:
 Kevin Fenzi (ke...@scrye.com) said:
  IMO ssh can be off by default and should be started only if user tries
  to connect over port 22.

 If systemd will allow us to do that, sure.

 What's the point here? For example, this doesn't cut down on the number
 of listening ports, obviously, nor on the requirements for root passwords
 and potential root login. And if it's started in parallel, I doubt it's a
 huge drain on resources.

For a fast and efficient boot-up two things are crucial:

* To start less.
* And to start more in parallel.

http://0pointer.de/blog/projects/systemd.html

IMO start less philosophy is a good thing.


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




-- 
Best regards,
Michal

Sent from my iToaster
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Kevin Fenzi]

On Mon, 6 Dec 2010 18:17:51 +0100
Michał Piotrowski mkkp...@gmail.com wrote:

 W dniu 6 grudnia 2010 18:01 użytkownik Kevin Fenzi ke...@scrye.com
 napisał:

...snip...

  What are you trying to do?
 
 I'm trying to convert sysvinit scripts to systemd services (as many
 as possible)

If you're trying to determine what units should be enabled by default,
please talk to the Fedora Packaging Comittee. 

See also: 
https://fedorahosted.org/fesco/ticket/504

Where fesco decided:

Default is off, exceptions exist to allow proper functioning of the
os. FPC to document exceptions and process exception requests.

FPC was going to work on a exceptions list I think... 

kevin


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

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Michał Piotrowski]

W dniu 6 grudnia 2010 18:43 użytkownik Kevin Fenzi ke...@scrye.com napisał:
 On Mon, 6 Dec 2010 18:17:51 +0100
 Michał Piotrowski mkkp...@gmail.com wrote:

 W dniu 6 grudnia 2010 18:01 użytkownik Kevin Fenzi ke...@scrye.com
 napisał:

 ...snip...

  What are you trying to do?

 I'm trying to convert sysvinit scripts to systemd services (as many
 as possible)

 If you're trying to determine what units should be enabled by default,
 please talk to the Fedora Packaging Comittee.

 See also:
 https://fedorahosted.org/fesco/ticket/504

 Where fesco decided:

 Default is off, exceptions exist to allow proper functioning of the
 os. FPC to document exceptions and process exception requests.

 FPC was going to work on a exceptions list I think...

This list will be useful.

Dear FPC people, could you provide this list in the near future?


 kevin

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




-- 
Best regards,
Michal

Sent from my iToaster
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Bill Nottingham]

Michał Piotrowski (mkkp...@gmail.com) said: 
  If systemd will allow us to do that, sure.
 
  What's the point here? For example, this doesn't cut down on the number
  of listening ports, obviously, nor on the requirements for root passwords
  and potential root login. And if it's started in parallel, I doubt it's a
  huge drain on resources.
 
 For a fast and efficient boot-up two things are crucial:
 
 * To start less.
 * And to start more in parallel.
 
 http://0pointer.de/blog/projects/systemd.html
 
 IMO start less philosophy is a good thing.

Yes. However, I'm leery of adding too many drastic changes that don't have
upstream buy-in yet. What's upstream openssh's opinion on socket activation?

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

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Michał Piotrowski]

2010/12/6 Bill Nottingham nott...@redhat.com:
 Michał Piotrowski (mkkp...@gmail.com) said:
  If systemd will allow us to do that, sure.
 
  What's the point here? For example, this doesn't cut down on the number
  of listening ports, obviously, nor on the requirements for root passwords
  and potential root login. And if it's started in parallel, I doubt it's a
  huge drain on resources.

 For a fast and efficient boot-up two things are crucial:

     * To start less.
     * And to start more in parallel.

 http://0pointer.de/blog/projects/systemd.html

 IMO start less philosophy is a good thing.

 Yes. However, I'm leery of adding too many drastic changes that don't have
 upstream buy-in yet.

I understand your POV.

 What's upstream openssh's opinion on socket activation?

Does openssh stands out something special between other demons?


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



-- 
Best regards,
Michal

Sent from my iToaster
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Miloslav Trmač]

Michał Piotrowski píše v Po 06. 12. 2010 v 20:22 +0100:
 2010/12/6 Bill Nottingham nott...@redhat.com:
 Does openssh stands out something special between other demons?
Actually, it does - for remote installations (sometimes the only option)
ssh needs to be running after installation so that the system
administrator can connect to it and start configuring it.  Other
services are not necessary like this.

(Yes, the system administrator can write a kickstart script that enables
the service after installation.  I'm not sure that something we can ask
a novice sysadmin to do, however.)
Mirek

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

Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Michał Piotrowski]

I wonder why my server rejected my previous email?


-- Wiadomość przekazana dalej --
Od: Michał Piotrowski mkkp...@gmail.com
Data: 6 grudnia 2010 20:46
Temat: Re: Fedora default services (was: Re: F15 Feature - convert as
many service init files as possible to the native SystemD services)
Do: Development discussions related to Fedora devel@lists.fedoraproject.org


2010/12/6 Miloslav Trmač m...@volny.cz:
 Michał Piotrowski píše v Po 06. 12. 2010 v 20:22 +0100:
 2010/12/6 Bill Nottingham nott...@redhat.com:
 Does openssh stands out something special between other demons?
 Actually, it does - for remote installations (sometimes the only option)
 ssh needs to be running after installation so that the system
 administrator can connect to it and start configuring it.  Other
 services are not necessary like this.

 (Yes, the system administrator can write a kickstart script that enables
 the service after installation.  I'm not sure that something we can ask
 a novice sysadmin to do, however.)

We are talking here about the case when ssh server is started when
user connect to 22 port (or other configured). From my POV everything
should work as expected.

        Mirek

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



--
Best regards,
Michal

Sent from my iToaster



-- 
Best regards,
Michal

Sent from my iToaster
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Bill Nottingham]

Michał Piotrowski (mkkp...@gmail.com) said: 
 We are talking here about the case when ssh server is started when
 user connect to 22 port (or other configured). From my POV everything
 should work as expected.

Right. To do this in systemd implies that you're patching openssh to
do socket-based activation... hence why I asked about upstream's opinion
on it.

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

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Michał Piotrowski]

2010/12/6 Bill Nottingham nott...@redhat.com:
 Michał Piotrowski (mkkp...@gmail.com) said:
 We are talking here about the case when ssh server is started when
 user connect to 22 port (or other configured). From my POV everything
 should work as expected.

 Right. To do this in systemd implies that you're patching openssh to
 do socket-based activation... hence why I asked about upstream's opinion
 on it.

I wasn't aware that they don't support it. I saw Lennart's
http://0pointer.de/public/systemd-units/sshd.socket
and I thought that it just works (I didn't tested it yet)


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



-- 
Best regards,
Michal

Sent from my iToaster
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Toshio Kuratomi]

On Mon, Dec 06, 2010 at 06:55:20PM +0100, Michał Piotrowski wrote:
 W dniu 6 grudnia 2010 18:43 użytkownik Kevin Fenzi ke...@scrye.com napisał:
  On Mon, 6 Dec 2010 18:17:51 +0100
  Michał Piotrowski mkkp...@gmail.com wrote:
 
  W dniu 6 grudnia 2010 18:01 użytkownik Kevin Fenzi ke...@scrye.com
  napisał:
 
  ...snip...
 
   What are you trying to do?
 
  I'm trying to convert sysvinit scripts to systemd services (as many
  as possible)
 
  If you're trying to determine what units should be enabled by default,
  please talk to the Fedora Packaging Comittee.
 
  See also:
  https://fedorahosted.org/fesco/ticket/504
 
  Where fesco decided:
 
  Default is off, exceptions exist to allow proper functioning of the
  os. FPC to document exceptions and process exception requests.
 
  FPC was going to work on a exceptions list I think...
 
 This list will be useful.
 
 Dear FPC people, could you provide this list in the near future?
 
Feedback appreciated -- what do you think should be on?  What do you think
should be off?  Right now I think we'd make an exception for ssh (a really
big exception since it's a network facing service, even).  Dbus and
default syslog variant also spring to mind which might be.  Those might be
able to start defining a category of things needed to run a desktop
session or something.

iptables, auditd, restorecond sound like keepers -- maybe a category here
would be things that add to system security in a default install.  For this
category we'd want to be careful, do we also want to allow fail2ban or
denyhosts to run by default if they're installed?

Other categories or specific examples would be good.

-Toshio


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

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Michał Piotrowski]

2010/12/7 Toshio Kuratomi a.bad...@gmail.com:
 On Mon, Dec 06, 2010 at 06:55:20PM +0100, Michał Piotrowski wrote:
 W dniu 6 grudnia 2010 18:43 użytkownik Kevin Fenzi ke...@scrye.com napisał:
  On Mon, 6 Dec 2010 18:17:51 +0100
  Michał Piotrowski mkkp...@gmail.com wrote:
 
  W dniu 6 grudnia 2010 18:01 użytkownik Kevin Fenzi ke...@scrye.com
  napisał:
 
  ...snip...
 
   What are you trying to do?
 
  I'm trying to convert sysvinit scripts to systemd services (as many
  as possible)
 
  If you're trying to determine what units should be enabled by default,
  please talk to the Fedora Packaging Comittee.
 
  See also:
  https://fedorahosted.org/fesco/ticket/504
 
  Where fesco decided:
 
  Default is off, exceptions exist to allow proper functioning of the
  os. FPC to document exceptions and process exception requests.
 
  FPC was going to work on a exceptions list I think...

 This list will be useful.

 Dear FPC people, could you provide this list in the near future?

 Feedback appreciated -- what do you think should be on?  What do you think
 should be off?  Right now I think we'd make an exception for ssh (a really
 big exception since it's a network facing service, even).

Ok

  Dbus and
 default syslog variant also spring to mind which might be.

Ok

  Those might be
 able to start defining a category of things needed to run a desktop
 session or something.

 iptables,

no chance to disable this

I guess ip6tables too?

 auditd, restorecond sound like keepers -- maybe a category here
 would be things that add to system security in a default install.

These are things related to core system security, so should be enabled.

  For this
 category we'd want to be careful, do we also want to allow fail2ban or
 denyhosts to run by default if they're installed?

No, other things not related with SELinux (or something that we could
call core security subsystem) should be IMHO off by default.


 Other categories or specific examples would be good.

Cron - but should be activated only when cron files exist

It seems to me that the list:
- ssh
- Dbus
- syslog
- iptables
- ip6tables
- auditd
- restorecond
is an absolute minimum to get working system.

- udev-post ? - is it needed for F15?
- mdmonitor and lvm2-monitor? - are they needed for proper working MD's/LVM's?
- network/Networkmanager ?

Everything else that is not essential for Fedora security, basic
desktop functionality should be IMO off by default.


 -Toshio

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




-- 
Best regards,
Michal

Sent from my iToaster
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Matt McCutchen]

On Tue, 2010-12-07 at 00:38 +0100, Michał Piotrowski wrote:
 Cron - but should be activated only when cron files exist
 
 It seems to me that the list:
 - ssh
 - Dbus
 - syslog
 - iptables
 - ip6tables
 - auditd
 - restorecond
 is an absolute minimum to get working system.

I don't agree that ssh is required for a working system.  A desktop
user may never ssh to his/her own machine.  (Whether to enable ssh by
default is a different question.)

-- 
Matt

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

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Michał Piotrowski]

2010/12/7 Matt McCutchen m...@mattmccutchen.net:
 On Tue, 2010-12-07 at 00:38 +0100, Michał Piotrowski wrote:
 Cron - but should be activated only when cron files exist

 It seems to me that the list:
 - ssh
 - Dbus
 - syslog
 - iptables
 - ip6tables
 - auditd
 - restorecond
 is an absolute minimum to get working system.

 I don't agree that ssh is required for a working system.

It's required for all systems without display device

  A desktop
 user may never ssh to his/her own machine.

That's why it should be socket activated as soon as possible

  (Whether to enable ssh by
 default is a different question.)

 --
 Matt

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



-- 
Best regards,
Michal

Sent from my iToaster
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Toshio Kuratomi]

On Tue, Dec 07, 2010 at 12:38:07AM +0100, Michał Piotrowski wrote:
 2010/12/7 Toshio Kuratomi a.bad...@gmail.com:
   Those might be
  able to start defining a category of things needed to run a desktop
  session or something.
 
  iptables,
 
 no chance to disable this
 
I'd be more inclined to ask what benefit we have to turning the firewall off
vs having a more permissive set of firewall rules by default.  AFAIK,
turning the firewall on doesn't currently turn on any additional daemon --
it just sets up the defined rules.

 I guess ip6tables too?
 
Yep.

Would you be willing to write up a Packaging Draft and add it to the FPC
tracker?  If not, I'll bring it up in the Packaging Meeting on Wednesday
morning.

-Toshio



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

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Matt McCutchen]

On Tue, 2010-12-07 at 01:07 +0100, Michał Piotrowski wrote:
 2010/12/7 Matt McCutchen m...@mattmccutchen.net:
  On Tue, 2010-12-07 at 00:38 +0100, Michał Piotrowski wrote:
  Cron - but should be activated only when cron files exist
 
  It seems to me that the list:
  - ssh
  - Dbus
  - syslog
  - iptables
  - ip6tables
  - auditd
  - restorecond
  is an absolute minimum to get working system.
 
  I don't agree that ssh is required for a working system.
 
 It's required for all systems without display device

That is, some servers.  It needs to be easy to enable sshd when
installing a server, but I don't see a reason to have it enabled by
default on desktops.

-- 
Matt

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

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Adam Williamson]

On Mon, 2010-12-06 at 10:54 +0100, Michał Piotrowski wrote:

 There are no stupid questions :)
 
 On most desktop systems firewall is not needed. Many users do not even
 know how to configure it. In fact I disable it in most of my systems,
 because there is no real use for it. So I asked a simple question
 whether there is a need to install iptables by default?

On most laptops, however, which are the most common types of system sold
today, a firewall is very definitely needed when you're connecting to
hotel networks, public wifi access points...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Miloslav Trmač]

Adam Williamson píše v Po 06. 12. 2010 v 17:57 -0800:
 On Mon, 2010-12-06 at 10:54 +0100, Michał Piotrowski wrote:
 
  There are no stupid questions :)
  
  On most desktop systems firewall is not needed. Many users do not even
  know how to configure it. In fact I disable it in most of my systems,
  because there is no real use for it. So I asked a simple question
  whether there is a need to install iptables by default?
 
 On most laptops, however, which are the most common types of system sold
 today, a firewall is very definitely needed when you're connecting to
 hotel networks, public wifi access points...
It's not quite as clear as that.  Yes, the networks are dangerous.  But
what specifically is the firewall protecting, and what specifically does
it prevent?
Mirek

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

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Jesse Keating]

On 12/06/2010 05:57 PM, Adam Williamson wrote:
 On most laptops, however, which are the most common types of system sold
 today, a firewall is very definitely needed when you're connecting to
 hotel networks, public wifi access points...


Please explain why.  What actual service is the firewall rendering in
this case?

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Matt McCutchen]

On Mon, 2010-12-06 at 17:57 -0800, Adam Williamson wrote:
 On Mon, 2010-12-06 at 10:54 +0100, Michał Piotrowski wrote:
 
  There are no stupid questions :)
  
  On most desktop systems firewall is not needed. Many users do not even
  know how to configure it. In fact I disable it in most of my systems,
  because there is no real use for it. So I asked a simple question
  whether there is a need to install iptables by default?
 
 On most laptops, however, which are the most common types of system sold
 today, a firewall is very definitely needed when you're connecting to
 hotel networks, public wifi access points...

We're trying to get beyond that conventional wisdom and look at what
services might actually get unintentionally exposed in the absence of a
firewall and whether there is some other solution (e.g., don't enable
them by default, or bind to localhost).

https://lists.fedoraproject.org/pipermail/devel/2010-December/146758.html

-- 
Matt

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

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Chris Adams]

Once upon a time, Adam Williamson awill...@redhat.com said:
 On most laptops, however, which are the most common types of system sold
 today, a firewall is very definitely needed when you're connecting to
 hotel networks, public wifi access points...

The only thing you need a firewall by default for is to prevent services
that are listening on the network from being accessible.  The better
solution is to stop having services listen on the network by default.

This was done for sendmail many years ago; why hasn't it been done for
other things, such as rpcbind (and RPC services), cups, etc.?  These
daemons should bind to localhost only unless otherwise configured.

-- 
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Michał Piotrowski]

2010/12/7 Toshio Kuratomi a.bad...@gmail.com:
 On Tue, Dec 07, 2010 at 12:38:07AM +0100, Michał Piotrowski wrote:
 2010/12/7 Toshio Kuratomi a.bad...@gmail.com:
   Those might be
  able to start defining a category of things needed to run a desktop
  session or something.
 
  iptables,

 no chance to disable this

 I'd be more inclined to ask what benefit we have to turning the firewall off
 vs having a more permissive set of firewall rules by default.  AFAIK,
 turning the firewall on doesn't currently turn on any additional daemon --
 it just sets up the defined rules.

 I guess ip6tables too?

 Yep.

 Would you be willing to write up a Packaging Draft and add it to the FPC
 tracker?  If not, I'll bring it up in the Packaging Meeting on Wednesday
 morning.

I'm not Fedora developer, I just create service files :)


 -Toshio


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




-- 
Best regards,
Michal

Sent from my iToaster
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Toshio Kuratomi]

On Tue, Dec 07, 2010 at 07:14:16AM +0100, Michał Piotrowski wrote:
 2010/12/7 Toshio Kuratomi a.bad...@gmail.com:
  On Tue, Dec 07, 2010 at 12:38:07AM +0100, Michał Piotrowski wrote:
  2010/12/7 Toshio Kuratomi a.bad...@gmail.com:
    Those might be
   able to start defining a category of things needed to run a desktop
   session or something.
  
   iptables,
 
  no chance to disable this
 
  I'd be more inclined to ask what benefit we have to turning the firewall off
  vs having a more permissive set of firewall rules by default.  AFAIK,
  turning the firewall on doesn't currently turn on any additional daemon --
  it just sets up the defined rules.
 
  I guess ip6tables too?
 
  Yep.
 
  Would you be willing to write up a Packaging Draft and add it to the FPC
  tracker?  If not, I'll bring it up in the Packaging Meeting on Wednesday
  morning.
 
 I'm not Fedora developer, I just create service files :)

Okay... I doubt we'll nail this down for a while then  Here's the ticket
I've opened:

https://fedorahosted.org/fpc/ticket/41

I have a feeling those categories don't account for everything yet... For
instance, readahead, abrtd... look in your /etc/init.d/ directory on F14 and
tell me what things that are there could have a justification.

-Toshio


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

Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

[Michał Piotrowski]

Hi,

W dniu 3 grudnia 2010 09:14 użytkownik Michał Piotrowski
mkkp...@gmail.com napisał:
[..]
 What services are installed by default when installong form Live
 GNOME/KDE/etc and DVD?

Ok, let's ask the question differently - what services should be run
by default to provide working system for desktop user?

IMO ssh can be off by default and should be started only if user tries
to connect over port 22.

Do we really need to install iptables/ip6tables by default (it's in core group)?

-- 
Best regards,
Michal

Sent from my iToaster
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Michał Piotrowski]

Hi,

What services are installed by default when installong form Live
GNOME/KDE/etc and DVD?

-- 
Best regards,
Michal

Sent from my iToaster
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Kevin Fenzi]

On Fri, 3 Dec 2010 09:14:26 +0100
Michał Piotrowski mkkp...@gmail.com wrote:

 Hi,
 
 What services are installed by default when installong form Live
 GNOME/KDE/etc and DVD?

Varies? :) 
I don't know that anyone has a list... it should be pretty easy to do
some installs and run 'chkconfig --list | grep 5:on'. Or did you mean
for f15? It's a bit early to tell, especially with systemd changes. 

kevin


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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Michał Piotrowski]

2010/12/4 Kevin Fenzi ke...@scrye.com:
 On Fri, 3 Dec 2010 09:14:26 +0100
 Michał Piotrowski mkkp...@gmail.com wrote:

 Hi,

 What services are installed by default when installong form Live
 GNOME/KDE/etc and DVD?

 Varies? :)
 I don't know that anyone has a list... it should be pretty easy to do
 some installs and run 'chkconfig --list | grep 5:on'.

Yes, but unfortunately I have no way to install OS on VM and check -
my CPU lacks VMX, and I don't want to reinstall OS.

 Or did you mean
 for f15?

Yes, actual nightly builds

 It's a bit early to tell, especially with systemd changes.

It seems to me that conversion of all init scripts to native systemd
scripts might be impossible for F15 - work is not progressing rapidly
enough.

Currently I take the trivial targets. The next targets will be
services that I use in daily work - web apps related things.

Having a list of default services would be useful when choosing the
next conversion targets. Would be nice to have all init scripts for
commonly used things converted to systemd.


 kevin

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




-- 
Best regards,
Michal

Sent from my iToaster
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Tomas Mraz]

On Fri, 2010-11-26 at 02:07 +0100, Miloslav Trmač wrote: 
 Lennart Poettering píše v Pá 26. 11. 2010 v 01:27 +0100:
  On Thu, 25.11.10 17:33, Tomas Mraz (tm...@redhat.com) wrote:
  And also, cron does a couple of really nasty things. For example it
  wakes up in regular intervals to check if a job is ready to run. It does
  so to deal with wallclock time changes/suspends. In systemd we are
  working on a different way to solve this, so that we can actually sleep
  as long as possible, and don't have to wake up in regular
  intervals.
 Great.  You can fix cron then, this does not mean it is necessary to
 integrate the two.
 
  To summarize this: the current logic of cron is not pretty. And it
  duplicates process spawning and babysitting which already exists in way
  too many daemons,
 I think you'll find the execution of processes is a comparatively small
 part of cron.  And anyway, process spawning and babysitting will
 _always_ exist in many different daemons, unless you want to run the
 whole system within a single systemd process.  It would be much much
 better for the ecosystem to extract these parts of systemd into a
 library (perhaps standalone, perhaps interacting with the system-wide
 systemd runtime) that can be used in any other process that needs to run
 a task in a separately tracked daemon group.
+1

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Tomas Mraz]

On Fri, 2010-11-26 at 03:05 +0100, Lennart Poettering wrote: 
 On Fri, 26.11.10 02:07, Miloslav Trmač (m...@volny.cz) wrote:
 
  Lennart Poettering píše v Pá 26. 11. 2010 v 01:27 +0100:
   On Thu, 25.11.10 17:33, Tomas Mraz (tm...@redhat.com) wrote:
   And also, cron does a couple of really nasty things. For example it
   wakes up in regular intervals to check if a job is ready to run. It does
   so to deal with wallclock time changes/suspends. In systemd we are
   working on a different way to solve this, so that we can actually sleep
   as long as possible, and don't have to wake up in regular
   intervals.
  Great.  You can fix cron then, this does not mean it is necessary to
  integrate the two.
 
 Well, I actually believe we should design an OS here, not just a set of
 independent tools. And that means I think closer integration is good and
 only has benefits.

I agree you are trying to design a completely new OS here. I am not so
sure this OS will be better than any other fully integrated monolithic
OS. I originally did not want to write this, but it seems you are really
determined to break some of the basic and proven to be effective Unix
design philosophy rules to make the system from simple parts with
clearly defined interfaces and functionality.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Tomas Mraz]

On Thu, 2010-11-25 at 23:11 -0500, Genes MailLists wrote: 
 On 11/25/2010 11:01 PM, Chris Adams wrote:
  Once upon a time, Lennart Poettering mzerq...@0pointer.de said:
  Well, I actually believe we should design an OS here, not just a set of
  independent tools. And that means I think closer integration is good and
  only has benefits.
  
  But this is a Unix-like OS, where each tool does one (or few) things and
  does them well.  systemd is not the OS, it is just one tool.  Please
  don't try to subsume the entire OS into systemd.
  
 
  Lets get systemd working well and as close to dammit as bug free please
 .. before we start having it take over other parts of the OS ...
+99

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Michał Piotrowski]

Hi,

How to start things that really are not demons?

Amtu seemed to be a simple service to convert

[Unit]
Description=Abstract Machine Tests
After=syslog.target

[Service]
EnvironmentFile=/etc/sysconfig/amtu
ExecStart=/usr/sbin/amtu $EXTRAOPTIONS

[Install]
WantedBy=multi-user.target

sudo systemctl start amtu.service
sudo systemctl status amtu.service
amtu.service - Abstract Machine Tests
  Loaded: loaded (/lib/systemd/system/amtu.service)
  Active: active (running) since Fri, 26 Nov 2010 18:13:47 +0100; 1s ago
Main PID: 2092 (amtu)
  CGroup: name=systemd:/system/amtu.service
  └ 2092 /usr/sbin/amtu
sudo systemctl status amtu.service
amtu.service - Abstract Machine Tests
  Loaded: loaded (/lib/systemd/system/amtu.service)
  Active: failed since Fri, 26 Nov 2010 18:13:50 +0100; 632ms ago
Main PID: 2092 (code=exited, status=255)
  CGroup: name=systemd:/system/amtu.service

It's because it's not really a daemon.
sudo /usr/sbin/amtu
Executing Memory Test...
Memory Test SUCCESS!
Executing Memory Separation Test...
Memory Separation Test SUCCESS!
Executing Network I/O Tests...
Failed to get list of network interfaces to test.
Executing I/O Controller - Disk Test...
I/O Controller - Disk Test SUCCESS!
Executing Supervisor Mode Instructions Test...
Privileged Instruction Test SUCCESS!

This service runs for a few seconds and exit.

How to start it properly?

Best regards,
Michal
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Tomasz Torcz]

On Fri, Nov 26, 2010 at 03:42:33PM +0100, Michał Piotrowski wrote:
 Hi,
 
 How to start things that really are not demons?
 
 Amtu seemed to be a simple service to convert
 
 [Unit]
 Description=Abstract Machine Tests
 After=syslog.target
 
 [Service]
 EnvironmentFile=/etc/sysconfig/amtu
 ExecStart=/usr/sbin/amtu $EXTRAOPTIONS
 
 [Install]
 WantedBy=multi-user.target
 
 This service runs for a few seconds and exit.
 How to start it properly?

  Type=oneshot  (decribed in man systemd.service). Also, RemainAfterExit=
property could be useful.
  But is this really a “service“?  What's the role of AMTU?

-- 
Tomasz Torcz   ,,(...) today's high-end is tomorrow's embedded processor.''
xmpp: zdzich...@chrome.pl  -- Mitchell Blank on LKML

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Michał Piotrowski]

2010/11/26 Tomasz Torcz to...@pipebreaker.pl:
 On Fri, Nov 26, 2010 at 03:42:33PM +0100, Michał Piotrowski wrote:
 Hi,

 How to start things that really are not demons?

 Amtu seemed to be a simple service to convert

 [Unit]
 Description=Abstract Machine Tests
 After=syslog.target

 [Service]
 EnvironmentFile=/etc/sysconfig/amtu
 ExecStart=/usr/sbin/amtu $EXTRAOPTIONS

 [Install]
 WantedBy=multi-user.target

 This service runs for a few seconds and exit.
 How to start it properly?

  Type=oneshot  (decribed in man systemd.service).

I tried it
amtu.service - Abstract Machine Tests
  Loaded: loaded (/lib/systemd/system/amtu.service)
  Active: failed since Fri, 26 Nov 2010 19:12:48 +0100; 11s ago
 Process: 2557 (/usr/sbin/amtu $EXTRAOPTIONS, code=exited, status=255)
  CGroup: name=systemd:/system/amtu.service

 Also, RemainAfterExit=
 property could be useful.

also tried
RemainAfterExit=yes
amtu.service - Abstract Machine Tests
  Loaded: loaded (/lib/systemd/system/amtu.service)
  Active: failed since Fri, 26 Nov 2010 19:14:35 +0100; 2s ago
 Process: 2602 (/usr/sbin/amtu $EXTRAOPTIONS, code=exited, status=255)
  CGroup: name=systemd:/system/amtu.service


  But is this really a service?

It has init script

  What's the role of AMTU?

# description:  This service runs the abstract machine tests to check the \
#   underlying security assumptions. It can be configured to
#   halt the machine in the event of failure. The program does
#   not stay resident, but rather runs once.

Frankly, it's this first time I met with this :)

Best regards,
Michal


 --
 Tomasz Torcz   ,,(...) today's high-end is tomorrow's embedded 
 processor.''
 xmpp: zdzich...@chrome.pl  -- Mitchell Blank on LKML

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Frank Ch. Eigler]

Miloslav =?UTF-8?Q?Trma=C4=8D?= m...@volny.cz writes:

 [...]  If the system integrates everything into one process, the
 only remaining troubleshooting mechanisms are integrated logging
 [...], debugger [...]  and systemtap (only a little better than a
 debugger, and not available for most programs).

To clarify, systemtap is available for most programs on fedora, to
the extent that most C or C++ programs can be probed with systemtap,
including those without sys/sdt.h compiled-in stuff.  For example:

   probe process(a.out).function(foobar) { log($$parms$$) }
   probe process(a.out).statement(*...@file.c:100-200) { log($$vars$$) }

There is also some support for interpreters like java and python too.

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Michał Piotrowski]

2010/11/25 Tomas Mraz tm...@redhat.com:
 On Wed, 2010-11-24 at 21:56 +0100, Lennart Poettering wrote:
 That's the point of the .path unit. i.e. you can list dirs to watch. If
 a user then drop a file into one of those dirs cron gets automatically
 started.

 Basically, in your .path unit you'd write something like this:

 [Path]
 PathExists=/etc/crontab
 DirectoryNotEmpty=/etc/cron.d
 DirectoryNotEmpty=/var/spool/cron

 And the moment where /etc/crontab starts to exist, or somebody drops a
 file into /etc/cron.d or /var/spool/cron crond would be automatically
 started.

 But what is the point of this? The /etc/crontab always exists and there
 always are some files in /etc/cron.d.

Actually it's true, but in the near future all standard cron jobs
might be runned by systemd

http://0pointer.de/public/systemd-man/systemd.timer.html

It's not 100 % cron replacement now, but who knows what the future holds :)

Kind regards,
Michal
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Tomas Mraz]

On Thu, 2010-11-25 at 09:31 +0100, Michał Piotrowski wrote: 
 2010/11/25 Tomas Mraz tm...@redhat.com:
  On Wed, 2010-11-24 at 21:56 +0100, Lennart Poettering wrote:
  That's the point of the .path unit. i.e. you can list dirs to watch. If
  a user then drop a file into one of those dirs cron gets automatically
  started.
 
  Basically, in your .path unit you'd write something like this:
 
  [Path]
  PathExists=/etc/crontab
  DirectoryNotEmpty=/etc/cron.d
  DirectoryNotEmpty=/var/spool/cron
 
  And the moment where /etc/crontab starts to exist, or somebody drops a
  file into /etc/cron.d or /var/spool/cron crond would be automatically
  started.
 
  But what is the point of this? The /etc/crontab always exists and there
  always are some files in /etc/cron.d.
 
 Actually it's true, but in the near future all standard cron jobs
 might be runned by systemd
 
 http://0pointer.de/public/systemd-man/systemd.timer.html
 
 It's not 100 % cron replacement now, but who knows what the future holds :)

I suppose the future holds systemd replacing the whole operating system.
Resistance is futile. You will be assimilated. :)
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Tomas Mraz]

On Thu, 2010-11-25 at 09:31 +0100, Michał Piotrowski wrote: 
 2010/11/25 Tomas Mraz tm...@redhat.com:
  On Wed, 2010-11-24 at 21:56 +0100, Lennart Poettering wrote:
  That's the point of the .path unit. i.e. you can list dirs to watch. If
  a user then drop a file into one of those dirs cron gets automatically
  started.
 
  Basically, in your .path unit you'd write something like this:
 
  [Path]
  PathExists=/etc/crontab
  DirectoryNotEmpty=/etc/cron.d
  DirectoryNotEmpty=/var/spool/cron
 
  And the moment where /etc/crontab starts to exist, or somebody drops a
  file into /etc/cron.d or /var/spool/cron crond would be automatically
  started.
 
  But what is the point of this? The /etc/crontab always exists and there
  always are some files in /etc/cron.d.
 
 Actually it's true, but in the near future all standard cron jobs
 might be runned by systemd
 
 http://0pointer.de/public/systemd-man/systemd.timer.html
 
 It's not 100 % cron replacement now, but who knows what the future holds :)

To add some argument to my previous sarcasm. I do not think that it
makes any sense to replicate cron functionality in systemd. Either you
replicate half of it and then you still need to run crond for the rest
or you replicate it completely. But in that case what is the saving over
the separate daemon? I'm sorry but I do not think that crond is anything
that optimized out by inclusion can improve performance of Linux
desktop/server/whatever. I do not say that cronie code cannot be
improved - it definitely can - but it does not make any sense to
reimplement it from scratch.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Michał Piotrowski]

W dniu 25 listopada 2010 17:33 użytkownik Tomas Mraz tm...@redhat.com napisał:
 On Thu, 2010-11-25 at 09:31 +0100, Michał Piotrowski wrote:
 Actually it's true, but in the near future all standard cron jobs
 might be runned by systemd

 http://0pointer.de/public/systemd-man/systemd.timer.html

 It's not 100 % cron replacement now, but who knows what the future holds :)

 To add some argument to my previous sarcasm. I do not think that it
 makes any sense to replicate cron functionality in systemd.

I do not know if it ever replace crond (I don't know Lennarts goals
here), but having actual systemd.timer functionality in system daemon
is IMHO very useful thing.

 Either you
 replicate half of it and then you still need to run crond for the rest
 or you replicate it completely. But in that case what is the saving over
 the separate daemon? I'm sorry but I do not think that crond is anything
 that optimized out by inclusion can improve performance of Linux
 desktop/server/whatever. I do not say that cronie code cannot be
 improved - it definitely can - but it does not make any sense to
 reimplement it from scratch.
 --
 Tomas Mraz
 No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb

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


Best regards,
Michal
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Lennart Poettering]

On Thu, 25.11.10 08:39, Tomas Mraz (tm...@redhat.com) wrote:

  That's the point of the .path unit. i.e. you can list dirs to watch. If
  a user then drop a file into one of those dirs cron gets automatically
  started.
  
  Basically, in your .path unit you'd write something like this:
  
  [Path]
  PathExists=/etc/crontab
  DirectoryNotEmpty=/etc/cron.d
  DirectoryNotEmpty=/var/spool/cron
  
  And the moment where /etc/crontab starts to exist, or somebody drops a
  file into /etc/cron.d or /var/spool/cron crond would be automatically
  started.
 
 But what is the point of this? The /etc/crontab always exists and there
 always are some files in /etc/cron.d.

The only contents of /etc/crontab and /etc/cron.d is the lines to handle
/etc/cron.daily and friends. As mentioned we can easily run those as
normal timer-triggerd units inside of systemd itself (and get all the
features it offers you for free, nice introspection, logging, IO/CPU
scheduling hooks, yadda yadda). So, if you remove that /etc/crontab is
empty and hence could be removed. And /etc/cron.d is empty too. And
there you go, we can support cron jobs just fine, but won't even start
it on most machines, but the user won't se the difference in the
behaviour.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Lennart Poettering]

On Thu, 25.11.10 17:33, Tomas Mraz (tm...@redhat.com) wrote:

  Actually it's true, but in the near future all standard cron jobs
  might be runned by systemd
  
  http://0pointer.de/public/systemd-man/systemd.timer.html
  
  It's not 100 % cron replacement now, but who knows what the future holds :)
 
 To add some argument to my previous sarcasm. I do not think that it
 makes any sense to replicate cron functionality in systemd. Either you
 replicate half of it and then you still need to run crond for the rest
 or you replicate it completely. But in that case what is the saving over
 the separate daemon? I'm sorry but I do not think that crond is anything
 that optimized out by inclusion can improve performance of Linux
 desktop/server/whatever. I do not say that cronie code cannot be
 improved - it definitely can - but it does not make any sense to
 reimplement it from scratch.

crond is not particularly complex. And providing similar functionality
in systemd is relatively easy as the more complicated stuff cron does is
actually spawning the processes, and systemd is vastly more powerful
with that. i.e. you can set IO/CPU schedulers, get sane logging, get all
the cgroups niftyness, you can pull in extra deps, yadda yadda.

Also, what's particularly interesting is that you can combine various
triggers if you do this in systemd: i.e. have one timer-based trigger,
and one inotify trigger (i.e. .path unit), and they start the same job,
and you don't end up with duplicates and need locking. 

And also, cron does a couple of really nasty things. For example it
wakes up in regular intervals to check if a job is ready to run. It does
so to deal with wallclock time changes/suspends. In systemd we are
working on a different way to solve this, so that we can actually sleep
as long as possible, and don't have to wake up in regular
intervals. Also, this means we can have much more accurate time
specifications, and we don't have to pay a price for it, due to
this. This different design will even allow us to do amazing stuff that
hasn't existed so far, for example, mark cron jobs so that they wake up
the machine from suspend, and similar.

To summarize this: the current logic of cron is not pretty. And it
duplicates process spawning and babysitting which already exists in way
too many daemons, and is actually the more interesting code. systemd
unifies all that code, and the end result will be simpler, more powerful
and less code, since we reuse what already exists anyway. The only thing
we basically add to systemd is a parser for calendar events, and
everything else already exists.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Andrew Clayton]

On Fri, 26 Nov 2010 01:15:04 +0100, Lennart Poettering wrote:

 The only contents of /etc/crontab and /etc/cron.d is the lines to
 handle /etc/cron.daily and friends. As mentioned we can easily run

On RHEL/CentOS (and it's likely only a matter of time before systemd
fillers through to them) various programs install jobs into /etc/cron.d
a quick look on one machine shows; mailman and sysstat related jobs as
well as some others...

 those as normal timer-triggerd units inside of systemd itself (and
 get all the features it offers you for free, nice introspection,
 logging, IO/CPU scheduling hooks, yadda yadda). So, if you remove
 that /etc/crontab is empty and hence could be removed.
 And /etc/cron.d is empty too. And there you go, we can support cron

Although I can't be the only one who puts various cron jobs
under /etc/cron.d that get run at various times.

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Genes MailLists]

 Although I can't be the only one who puts various cron jobs
 under /etc/cron.d that get run at various times.
 
 Andrew

 Almost every administrative cron here is in a cron.d crontab file .. we
need control over exactly what time certain things happen. So please
keep the functionality.


 If systemd is the expert spawner - then perhaps things like cron (or
any reproductive daemon for that matter) could lean on a systemd for
spawn service - but leave the other application specific parts to the
local daemons to do for themselves.

 There is some merit in functional separation too ...


  g

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Miloslav Trmač]

Lennart Poettering píše v Pá 26. 11. 2010 v 01:27 +0100:
 And also, cron does a couple of really nasty things. For example it
 wakes up in regular intervals to check if a job is ready to run. It does
 so to deal with wallclock time changes/suspends. In systemd we are
 working on a different way to solve this, so that we can actually sleep
 as long as possible, and don't have to wake up in regular
 intervals. Also, this means we can have much more accurate time
 specifications, and we don't have to pay a price for it, due to
 this. This different design will even allow us to do amazing stuff that
 hasn't existed so far, for example, mark cron jobs so that they wake up
 the machine from suspend, and similar.
 
 To summarize this: the current logic of cron is not pretty. And it
 duplicates process spawning and babysitting which already exists in way
 too many daemons, and is actually the more interesting code. systemd
 unifies all that code, and the end result will be simpler, more powerful
 and less code, since we reuse what already exists anyway. The only thing
 we basically add to systemd is a parser for calendar events, and
 everything else already exists.
 
 Lennart
 
 -- 
 Lennart Poettering - Red Hat, Inc.


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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Miloslav Trmač]

Lennart Poettering píše v Pá 26. 11. 2010 v 01:27 +0100:
 On Thu, 25.11.10 17:33, Tomas Mraz (tm...@redhat.com) wrote:
 And also, cron does a couple of really nasty things. For example it
 wakes up in regular intervals to check if a job is ready to run. It does
 so to deal with wallclock time changes/suspends. In systemd we are
 working on a different way to solve this, so that we can actually sleep
 as long as possible, and don't have to wake up in regular
 intervals.
Great.  You can fix cron then, this does not mean it is necessary to
integrate the two.

 To summarize this: the current logic of cron is not pretty. And it
 duplicates process spawning and babysitting which already exists in way
 too many daemons,
I think you'll find the execution of processes is a comparatively small
part of cron.  And anyway, process spawning and babysitting will
_always_ exist in many different daemons, unless you want to run the
whole system within a single systemd process.  It would be much much
better for the ecosystem to extract these parts of systemd into a
library (perhaps standalone, perhaps interacting with the system-wide
systemd runtime) that can be used in any other process that needs to run
a task in a separately tracked daemon group.
Mirek

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Lennart Poettering]

On Fri, 26.11.10 02:07, Miloslav Trmač (m...@volny.cz) wrote:

 Lennart Poettering píše v Pá 26. 11. 2010 v 01:27 +0100:
  On Thu, 25.11.10 17:33, Tomas Mraz (tm...@redhat.com) wrote:
  And also, cron does a couple of really nasty things. For example it
  wakes up in regular intervals to check if a job is ready to run. It does
  so to deal with wallclock time changes/suspends. In systemd we are
  working on a different way to solve this, so that we can actually sleep
  as long as possible, and don't have to wake up in regular
  intervals.
 Great.  You can fix cron then, this does not mean it is necessary to
 integrate the two.

Well, I actually believe we should design an OS here, not just a set of
independent tools. And that means I think closer integration is good and
only has benefits.

  To summarize this: the current logic of cron is not pretty. And it
  duplicates process spawning and babysitting which already exists in way
  too many daemons,
 I think you'll find the execution of processes is a comparatively small
 part of cron.  

Well, and that's why it is also very limited.

 And anyway, process spawning and babysitting will
 _always_ exist in many different daemons, unless you want to run the
 whole system within a single systemd process.  

Sure, no doubt about that. But unifying this for system stuff is a good
thing, not a bad thing.

 It would be much much better for the ecosystem to extract these parts
 of systemd into a library (perhaps standalone, perhaps interacting
 with the system-wide systemd runtime) that can be used in any other
 process that needs to run a task in a separately tracked daemon
 group.  Mirek

Well, I don't think that that technically makes any sense. Sorry.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Lennart Poettering]

On Thu, 25.11.10 19:57, Genes MailLists (li...@sapience.com) wrote:

 
 
  Although I can't be the only one who puts various cron jobs
  under /etc/cron.d that get run at various times.
  
  Andrew
 
  Almost every administrative cron here is in a cron.d crontab file .. we
 need control over exactly what time certain things happen. So please
 keep the functionality.

Hey, as I made explcitily clear I have no plans of taking away anything
from you. No need to be defensive...

  If systemd is the expert spawner - then perhaps things like cron (or
 any reproductive daemon for that matter) could lean on a systemd for
 spawn service - but leave the other application specific parts to the
 local daemons to do for themselves.
 
  There is some merit in functional separation too ...

Well, there isn't if the remaining bits simply do some minimal calendar
calculations and do that in a way we shouldn't do things anymore, and
hence needs to be fixed anyway.

As mentioned: i have no plans to take crond away. Just change it to be
started a little bit differently.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Genes MailLists]

On 11/25/2010 09:08 PM, Lennart Poettering wrote:
 On Thu, 25.11.10 19:57, Genes MailLists (li...@sapience.com) wrote:
keep the functionality.
 
 Hey, as I made explcitily clear I have no plans of taking away anything
 from you. No need to be defensive...

  Actually that was after I posted but ok :-) good!

  There is some merit in functional separation too ...
 
 Well, there isn't if the remaining bits simply do some minimal calendar
 calculations and do that in a way we shouldn't do things anymore, and
 hence needs to be fixed anyway.


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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Genes MailLists]

On 11/25/2010 09:19 PM, Genes MailLists wrote:
 On 11/25/2010 09:08 PM, Lennart Poettering wrote:
 On Thu, 25.11.10 19:57, Genes MailLists (li...@sapience.com) wrote:
 keep the functionality.

 Hey, as I made explcitily clear I have no plans of taking away anything
 from you. No need to be defensive...
 

  Also was not being defensive (or aggressive :-) - just politely asking
...

  thanks!


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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Miloslav Trmač]

Lennart Poettering píše v Pá 26. 11. 2010 v 03:05 +0100:
 On Fri, 26.11.10 02:07, Miloslav Trmač (m...@volny.cz) wrote:
  Lennart Poettering píše v Pá 26. 11. 2010 v 01:27 +0100:
   On Thu, 25.11.10 17:33, Tomas Mraz (tm...@redhat.com) wrote:
   And also, cron does a couple of really nasty things. For example it
   wakes up in regular intervals to check if a job is ready to run. It does
   so to deal with wallclock time changes/suspends. In systemd we are
   working on a different way to solve this, so that we can actually sleep
   as long as possible, and don't have to wake up in regular
   intervals.
  Great.  You can fix cron then, this does not mean it is necessary to
  integrate the two.
 
 Well, I actually believe we should design an OS here, not just a set of
 independent tools. And that means I think closer integration is good and
 only has benefits.
At the very least, closer integration makes troubleshooting
significantly more difficult.  Each point where separate tools interact
is a point where it is possible, and in UNIX often easy, to insert
debugging instrumentation.

If the system integrates everything into one process, the only remaining
troubleshooting mechanisms are integrated logging (which is by
definition unsatisfactory - if a problem was foreseen enough to be
logged, it was probably also foreseen enough to be avoided), debugger
(useless for non-programmers, useless for non-expert programmers that
need to fix things in a hurry, practically useless with -O2) and
systemtap (only a little better than a debugger, and not available for
most programs).

Design an OS means that the system _design_ should fit well together,
nothing more.

  It would be much much better for the ecosystem to extract these parts
  of systemd into a library (perhaps standalone, perhaps interacting
  with the system-wide systemd runtime) that can be used in any other
  process that needs to run a task in a separately tracked daemon
  group.  Mirek
 
 Well, I don't think that that technically makes any sense. Sorry.
Care to elaborate?  Look at sshd: it needs to start per-user sessions
from a single daemon.  Wouldn't it make sense to track these as cgroups
recognized by systemd?  Crond is _exactly_ the same thing.  Any other
remote access protocol (POSIX batch facilities, func, X server accepting
remote clients, and anything else that isn't currently a part of the
system and thus can't be rewritten as part of systemd) would benefit
from this facility.

AFAICS it would be clearly useful to be able to delegate the control of
daemon group creation to other processes.  Why doesn't it make sense?
Mirek

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Chris Adams]

Once upon a time, Lennart Poettering mzerq...@0pointer.de said:
 Well, I actually believe we should design an OS here, not just a set of
 independent tools. And that means I think closer integration is good and
 only has benefits.

But this is a Unix-like OS, where each tool does one (or few) things and
does them well.  systemd is not the OS, it is just one tool.  Please
don't try to subsume the entire OS into systemd.

-- 
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Genes MailLists]

On 11/25/2010 11:01 PM, Chris Adams wrote:
 Once upon a time, Lennart Poettering mzerq...@0pointer.de said:
 Well, I actually believe we should design an OS here, not just a set of
 independent tools. And that means I think closer integration is good and
 only has benefits.
 
 But this is a Unix-like OS, where each tool does one (or few) things and
 does them well.  systemd is not the OS, it is just one tool.  Please
 don't try to subsume the entire OS into systemd.
 

 Lets get systemd working well and as close to dammit as bug free please
.. before we start having it take over other parts of the OS ...


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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Marcela Mašláňová]

On 11/26/2010 01:27 AM, Lennart Poettering wrote:
 On Thu, 25.11.10 17:33, Tomas Mraz (tm...@redhat.com) wrote:

 Actually it's true, but in the near future all standard cron jobs
 might be runned by systemd

 http://0pointer.de/public/systemd-man/systemd.timer.html

 It's not 100 % cron replacement now, but who knows what the future holds :)
 To add some argument to my previous sarcasm. I do not think that it
 makes any sense to replicate cron functionality in systemd. Either you
 replicate half of it and then you still need to run crond for the rest
 or you replicate it completely. But in that case what is the saving over
 the separate daemon? I'm sorry but I do not think that crond is anything
 that optimized out by inclusion can improve performance of Linux
 desktop/server/whatever. I do not say that cronie code cannot be
 improved - it definitely can - but it does not make any sense to
 reimplement it from scratch.
 crond is not particularly complex. And providing similar functionality
 in systemd is relatively easy as the more complicated stuff cron does is
 actually spawning the processes, and systemd is vastly more powerful
 with that. i.e. you can set IO/CPU schedulers, get sane logging, get all
 the cgroups niftyness, you can pull in extra deps, yadda yadda.

 Also, what's particularly interesting is that you can combine various
 triggers if you do this in systemd: i.e. have one timer-based trigger,
 and one inotify trigger (i.e. .path unit), and they start the same job,
 and you don't end up with duplicates and need locking. 

 And also, cron does a couple of really nasty things. For example it
 wakes up in regular intervals to check if a job is ready to run. It does
 so to deal with wallclock time changes/suspends. In systemd we are
 working on a different way to solve this, so that we can actually sleep
 as long as possible, and don't have to wake up in regular
 intervals. Also, this means we can have much more accurate time
 specifications, and we don't have to pay a price for it, due to
 this. This different design will even allow us to do amazing stuff that
 hasn't existed so far, for example, mark cron jobs so that they wake up
 the machine from suspend, and similar.

Cronie is using inotify, so it doesn't wake every minute as it used to.

I'm just curious, how many programmes would stay in Fedora after
you finish systemd ;-) /sarcasm.

Marcela

-- 
Marcela Mašláňová
BaseOS team Brno

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Adam Williamson]

On Fri, 2010-11-26 at 07:42 +0100, Marcela Mašláňová wrote:

 I'm just curious, how many programmes would stay in Fedora after
 you finish systemd ;-) /sarcasm.

and do we run systemd in emacs, or emacs from systemd?!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Michał Piotrowski]

2010/11/24 Lennart Poettering mzerq...@0pointer.de:
 On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp...@gmail.com) wrote:

 Hi,

 I would like to help with scripts conversion. IMO the conversion
 action should be coordinated.

 Comments, thoughts?

 I would certainly welcome any work in this direction!

Could you look at the
crond.service https://bugzilla.redhat.com/show_bug.cgi?id=656864
and
atd.service https://bugzilla.redhat.com/show_bug.cgi?id=656869
and see if I did not do any fundamental error?

Seems to me that these are simple enough at the beginning :)

For both I used Type=forking - it works fine, but it seems to me that
Type=simple might be a better choice.

Best regards,
Michal
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Tomasz Torcz]

On Wed, Nov 24, 2010 at 01:41:49PM +0100, Michał Piotrowski wrote:
 2010/11/24 Lennart Poettering mzerq...@0pointer.de:
  On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp...@gmail.com) wrote:
 
  Hi,
 
  I would like to help with scripts conversion. IMO the conversion
  action should be coordinated.
 
  Comments, thoughts?
 
  I would certainly welcome any work in this direction!
 
 Could you look at the
 crond.service https://bugzilla.redhat.com/show_bug.cgi?id=656864
 and
 atd.service https://bugzilla.redhat.com/show_bug.cgi?id=656869
 and see if I did not do any fundamental error?
 
 Seems to me that these are simple enough at the beginning :)
 
 For both I used Type=forking - it works fine, but it seems to me that
 Type=simple might be a better choice.

  For type=simple you would like “-n” switch in crond invocation.
I suggest trimming Description, it is printed during bootup and should be 
short. 

-- 
Tomasz Torcz  ,,If you try to upissue this patchset I shall be 
seeking
xmpp: zdzich...@chrome.pl   an IP-routable hand grenade.'' -- Andrew Morton 
(LKML)

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Marcela Mašláňová]

On 11/24/2010 01:41 PM, Michał Piotrowski wrote:
 2010/11/24 Lennart Poettering mzerq...@0pointer.de:
 On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp...@gmail.com) wrote:

 Hi,

 I would like to help with scripts conversion. IMO the conversion
 action should be coordinated.

 Comments, thoughts?
 I would certainly welcome any work in this direction!
 Could you look at the
 crond.service https://bugzilla.redhat.com/show_bug.cgi?id=656864
 and
 atd.service https://bugzilla.redhat.com/show_bug.cgi?id=656869
 and see if I did not do any fundamental error?

 Seems to me that these are simple enough at the beginning :)

 For both I used Type=forking - it works fine, but it seems to me that
 Type=simple might be a better choice.

 Best regards,
 Michal
Could you explain, what's the difference between
https://bugzilla.redhat.com/show_bug.cgi?id=656864 and
https://bugzilla.redhat.com/show_bug.cgi?id=617324 ?

In the older bug was the correct script at least discussed. Why are you
mass opening new bugs, when the old weren't solved and they could contain
reasonable information as in this case?

Marcela

-- 
Marcela Mašláňová
BaseOS team Brno

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Michał Piotrowski]

2010/11/24 Tomasz Torcz to...@pipebreaker.pl:
 On Wed, Nov 24, 2010 at 01:41:49PM +0100, Michał Piotrowski wrote:
 2010/11/24 Lennart Poettering mzerq...@0pointer.de:
  On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp...@gmail.com) wrote:
 
  Hi,
 
  I would like to help with scripts conversion. IMO the conversion
  action should be coordinated.
 
  Comments, thoughts?
 
  I would certainly welcome any work in this direction!

 Could you look at the
 crond.service https://bugzilla.redhat.com/show_bug.cgi?id=656864
 and
 atd.service https://bugzilla.redhat.com/show_bug.cgi?id=656869
 and see if I did not do any fundamental error?

 Seems to me that these are simple enough at the beginning :)

 For both I used Type=forking - it works fine, but it seems to me that
 Type=simple might be a better choice.

  For type=simple you would like -n switch in crond invocation.

Ah, ok, I'll keep forking.

 I suggest trimming Description, it is printed during bootup and should be 
 short.

I didn't noticed it - I guess quiet kernel param is also interpreted
by SystemD.


 --
 Tomasz Torcz  ,,If you try to upissue this patchset I shall be 
 seeking
 xmpp: zdzich...@chrome.pl   an IP-routable hand grenade.'' -- Andrew Morton 
 (LKML)

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

Kind regards,
Michal
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Michał Piotrowski]

2010/11/24 Marcela Mašláňová mmasl...@redhat.com:
 On 11/24/2010 01:41 PM, Michał Piotrowski wrote:
 2010/11/24 Lennart Poettering mzerq...@0pointer.de:
 On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp...@gmail.com) wrote:

 Hi,

 I would like to help with scripts conversion. IMO the conversion
 action should be coordinated.

 Comments, thoughts?
 I would certainly welcome any work in this direction!
 Could you look at the
 crond.service https://bugzilla.redhat.com/show_bug.cgi?id=656864
 and
 atd.service https://bugzilla.redhat.com/show_bug.cgi?id=656869
 and see if I did not do any fundamental error?

 Seems to me that these are simple enough at the beginning :)

 For both I used Type=forking - it works fine, but it seems to me that
 Type=simple might be a better choice.

 Best regards,
 Michal
 Could you explain, what's the difference between
 https://bugzilla.redhat.com/show_bug.cgi?id=656864 and
 https://bugzilla.redhat.com/show_bug.cgi?id=617324 ?

 In the older bug was the correct script at least discussed. Why are you
 mass opening new bugs, when the old weren't solved and they could contain
 reasonable information as in this case?

Sorry, I was not aware that Jóhann opened bugs for all this scripts.


 Marcela

 --
 Marcela Mašláňová
 BaseOS team Brno

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


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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Lennart Poettering]

On Wed, 24.11.10 13:59, Michał Piotrowski (mkkp...@gmail.com) wrote:

 
 2010/11/24 Tomasz Torcz to...@pipebreaker.pl:
  On Wed, Nov 24, 2010 at 01:41:49PM +0100, Michał Piotrowski wrote:
  2010/11/24 Lennart Poettering mzerq...@0pointer.de:
   On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp...@gmail.com) wrote:
  
   Hi,
  
   I would like to help with scripts conversion. IMO the conversion
   action should be coordinated.
  
   Comments, thoughts?
  
   I would certainly welcome any work in this direction!
 
  Could you look at the
  crond.service https://bugzilla.redhat.com/show_bug.cgi?id=656864
  and
  atd.service https://bugzilla.redhat.com/show_bug.cgi?id=656869
  and see if I did not do any fundamental error?
 
  Seems to me that these are simple enough at the beginning :)
 
  For both I used Type=forking - it works fine, but it seems to me that
  Type=simple might be a better choice.
 
   For type=simple you would like -n switch in crond invocation.
 
 Ah, ok, I'll keep forking.

It's generally nicer to use simple wherever possible, unless you have
a really good reason to assume that your service might be needed to be
up by something else, and that something else might want synchronize to
it. Since at/cron don't really offer any live protocols to other
processes I think Type=simple is a good idea here.

BTW, regarding at and cron: what I was thinking of but never check
ehwther it is feasible is to make cron/at autostart a soon as some job
is scheduled. I.e. use .path trigger to check whether /etc/crontab and
user jobs exist, and start cron only then. Similarly for at. That way we
could support cron and at just fine, and wouldn't even have to run it by
default. I haven't looked into this in detail however, to see if the
file triggers systemd offers in .path units are already sufficient to
make this work.

(And /etc/cron.daily and stuff would then be managed by systemd
natively, in a .timer unit)

  I suggest trimming Description, it is printed during bootup and should be 
  short.
 
 I didn't noticed it - I guess quiet kernel param is also interpreted
 by SystemD.

Yes, systemd honours quiet:

Btw, it's written systemd, not SystemD. I even added a section about
the spelling now to the systemd homepage ;-)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Paul Wouters]

On Wed, 24 Nov 2010, Lennart Poettering wrote:

 BTW, regarding at and cron: what I was thinking of but never check
 ehwther it is feasible is to make cron/at autostart a soon as some job
 is scheduled. I.e. use .path trigger to check whether /etc/crontab and
 user jobs exist, and start cron only then. Similarly for at. That way we
 could support cron and at just fine, and wouldn't even have to run it by
 default. I haven't looked into this in detail however, to see if the
 file triggers systemd offers in .path units are already sufficient to
 make this work.

What if no jobs are there and a non-root user adds a crontab later on? Who
will start cron (as root) ?

 Btw, it's written systemd, not SystemD. I even added a section about
 the spelling now to the systemd homepage ;-)

At Openswan, we never wrote OpenSWAN and we're still telling people every week
to not use that. It's a lost battle :P

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Michał Piotrowski]

2010/11/24 Lennart Poettering mzerq...@0pointer.de:
 On Wed, 24.11.10 13:59, Michał Piotrowski (mkkp...@gmail.com) wrote:


 2010/11/24 Tomasz Torcz to...@pipebreaker.pl:
  On Wed, Nov 24, 2010 at 01:41:49PM +0100, Michał Piotrowski wrote:
  2010/11/24 Lennart Poettering mzerq...@0pointer.de:
   On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp...@gmail.com) wrote:
  
   Hi,
  
   I would like to help with scripts conversion. IMO the conversion
   action should be coordinated.
  
   Comments, thoughts?
  
   I would certainly welcome any work in this direction!
 
  Could you look at the
  crond.service https://bugzilla.redhat.com/show_bug.cgi?id=656864
  and
  atd.service https://bugzilla.redhat.com/show_bug.cgi?id=656869
  and see if I did not do any fundamental error?
 
  Seems to me that these are simple enough at the beginning :)
 
  For both I used Type=forking - it works fine, but it seems to me that
  Type=simple might be a better choice.
 
   For type=simple you would like -n switch in crond invocation.

 Ah, ok, I'll keep forking.

 It's generally nicer to use simple wherever possible, unless you have
 a really good reason to assume that your service might be needed to be
 up by something else, and that something else might want synchronize to
 it. Since at/cron don't really offer any live protocols to other
 processes I think Type=simple is a good idea here.

Ok

I checked your atd.service and crond.service and voted for them in
617320 and 617324


 BTW, regarding at and cron: what I was thinking of but never check
 ehwther it is feasible is to make cron/at autostart a soon as some job
 is scheduled. I.e. use .path trigger to check whether /etc/crontab and
 user jobs exist, and start cron only then. Similarly for at. That way we
 could support cron and at just fine, and wouldn't even have to run it by
 default. I haven't looked into this in detail however, to see if the
 file triggers systemd offers in .path units are already sufficient to
 make this work.

IMHO good idea. It should look something like this
ListenStream=/etc/cron.hourly/*
ListenStream=/etc/cron.daily/*
ListenStream=/etc/cron.weekly/*
ListenStream=/etc/cron.monthly/*
(more or less)


 (And /etc/cron.daily and stuff would then be managed by systemd
 natively, in a .timer unit)

  I suggest trimming Description, it is printed during bootup and should be 
  short.

 I didn't noticed it - I guess quiet kernel param is also interpreted
 by SystemD.

 Yes, systemd honours quiet:

 Btw, it's written systemd, not SystemD. I even added a section about
 the spelling now to the systemd homepage ;-)

I have not read all the documentation yet ;)


 Lennart

 --
 Lennart Poettering - Red Hat, Inc.
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel

Best regards,
Michal
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[James Antill]

On Tue, 2010-11-23 at 10:19 -0600, Bruno Wolff III wrote:
 On Tue, Nov 23, 2010 at 17:18:44 +0100,
   Michał Piotrowski mkkp...@gmail.com wrote:
  W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski
  mkkp...@gmail.com napisał:
   We can create a list of all scripts in wiki and
   maintainers of individual packages would indicate that they want to
   convert scripts themselves.
  
  How can I get information about all packages that provides init scripts?
  
  When I do
  rpm -qf /etc/init.d/*
  I get only information about already installed packages. Any magic
  switch to get informations about all packages from rpm database?
 
 I believe rpm only knows about packages available locally. You either need
 to have the packages installed or a local mirror. (You can use urls to
 refer to remote packages with rpm, but that isn't likely to be workable.)
 If you have a local mirror you can use the p option and name the rpms.
 
 Otherwise yum is probably a better choice for this, since it can use meta
 data to get information. One of the yum utilities may be better than yum
 itself, but I am not sure offhand.

 You can use:

repoquery -qf '/etc/init.d/*' '/etc/rc.d/init.d/*'

...note that unlike rpm -qf you need both of the above paths.

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Michał Piotrowski]

2010/11/24 Paul Wouters p...@xelerance.com:
 On Wed, 24 Nov 2010, Lennart Poettering wrote:

 BTW, regarding at and cron: what I was thinking of but never check
 ehwther it is feasible is to make cron/at autostart a soon as some job
 is scheduled. I.e. use .path trigger to check whether /etc/crontab and
 user jobs exist, and start cron only then. Similarly for at. That way we
 could support cron and at just fine, and wouldn't even have to run it by
 default. I haven't looked into this in detail however, to see if the
 file triggers systemd offers in .path units are already sufficient to
 make this work.

 What if no jobs are there and a non-root user adds a crontab later on? Who
 will start cron (as root) ?

I guess ListenStream=/var/spool/cron/* (if it will work - I'm not sure
how systemd interprets wildcards and multiple ListenStream)


 Btw, it's written systemd, not SystemD. I even added a section about
 the spelling now to the systemd homepage ;-)

 At Openswan, we never wrote OpenSWAN and we're still telling people every week
 to not use that. It's a lost battle :P

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


Kind regards,
Michal
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Tomasz Torcz]

On Wed, Nov 24, 2010 at 09:30:03PM +0100, Michał Piotrowski wrote:
 2010/11/24 Paul Wouters p...@xelerance.com:
  On Wed, 24 Nov 2010, Lennart Poettering wrote:
 
  BTW, regarding at and cron: what I was thinking of but never check
  ehwther it is feasible is to make cron/at autostart a soon as some job
  is scheduled. I.e. use .path trigger to check whether /etc/crontab and
  user jobs exist, and start cron only then. Similarly for at. That way we
  could support cron and at just fine, and wouldn't even have to run it by
  default. I haven't looked into this in detail however, to see if the
  file triggers systemd offers in .path units are already sufficient to
  make this work.
 
  What if no jobs are there and a non-root user adds a crontab later on? Who
  will start cron (as root) ?
 
 I guess ListenStream=/var/spool/cron/* (if it will work - I'm not sure
 how systemd interprets wildcards and multiple ListenStream)
 
  Uhm, you meant path type unit, described in systemd.path surely. Listen* 
directives are for sockets.


 
  Btw, it's written systemd, not SystemD. I even added a section about
  the spelling now to the systemd homepage ;-)
 
  At Openswan, we never wrote OpenSWAN and we're still telling people every 
  week
  to not use that. It's a lost battle :P

  And Paul surely meant OpenS/WAN ;)

-- 
Tomasz Torcz God, root, what's the difference?
xmpp: zdzich...@chrome.pl God is more forgiving.

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Michał Piotrowski]

W dniu 24 listopada 2010 21:34 użytkownik Tomasz Torcz
to...@pipebreaker.pl napisał:
 On Wed, Nov 24, 2010 at 09:30:03PM +0100, Michał Piotrowski wrote:
 2010/11/24 Paul Wouters p...@xelerance.com:
  On Wed, 24 Nov 2010, Lennart Poettering wrote:
 
  BTW, regarding at and cron: what I was thinking of but never check
  ehwther it is feasible is to make cron/at autostart a soon as some job
  is scheduled. I.e. use .path trigger to check whether /etc/crontab and
  user jobs exist, and start cron only then. Similarly for at. That way we
  could support cron and at just fine, and wouldn't even have to run it by
  default. I haven't looked into this in detail however, to see if the
  file triggers systemd offers in .path units are already sufficient to
  make this work.
 
  What if no jobs are there and a non-root user adds a crontab later on? Who
  will start cron (as root) ?

 I guess ListenStream=/var/spool/cron/* (if it will work - I'm not sure
 how systemd interprets wildcards and multiple ListenStream)

  Uhm, you meant path type unit, described in systemd.path surely. Listen*
 directives are for sockets.

Probably yes :)



 
  Btw, it's written systemd, not SystemD. I even added a section about
  the spelling now to the systemd homepage ;-)
 
  At Openswan, we never wrote OpenSWAN and we're still telling people every 
  week
  to not use that. It's a lost battle :P

  And Paul surely meant OpenS/WAN ;)

 --
 Tomasz Torcz                 God, root, what's the difference?
 xmpp: zdzich...@chrome.pl         God is more forgiving.

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

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Lennart Poettering]

On Wed, 24.11.10 15:22, Paul Wouters (p...@xelerance.com) wrote:

 
 On Wed, 24 Nov 2010, Lennart Poettering wrote:
 
  BTW, regarding at and cron: what I was thinking of but never check
  ehwther it is feasible is to make cron/at autostart a soon as some job
  is scheduled. I.e. use .path trigger to check whether /etc/crontab and
  user jobs exist, and start cron only then. Similarly for at. That way we
  could support cron and at just fine, and wouldn't even have to run it by
  default. I haven't looked into this in detail however, to see if the
  file triggers systemd offers in .path units are already sufficient to
  make this work.
 
 What if no jobs are there and a non-root user adds a crontab later on? Who
 will start cron (as root) ?

That's the point of the .path unit. i.e. you can list dirs to watch. If
a user then drop a file into one of those dirs cron gets automatically
started.

Basically, in your .path unit you'd write something like this:

[Path]
PathExists=/etc/crontab
DirectoryNotEmpty=/etc/cron.d
DirectoryNotEmpty=/var/spool/cron

And the moment where /etc/crontab starts to exist, or somebody drops a
file into /etc/cron.d or /var/spool/cron crond would be automatically
started.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Lennart Poettering]

On Wed, 24.11.10 21:30, Michał Piotrowski (mkkp...@gmail.com) wrote:

 
 2010/11/24 Paul Wouters p...@xelerance.com:
  On Wed, 24 Nov 2010, Lennart Poettering wrote:
 
  BTW, regarding at and cron: what I was thinking of but never check
  ehwther it is feasible is to make cron/at autostart a soon as some job
  is scheduled. I.e. use .path trigger to check whether /etc/crontab and
  user jobs exist, and start cron only then. Similarly for at. That way we
  could support cron and at just fine, and wouldn't even have to run it by
  default. I haven't looked into this in detail however, to see if the
  file triggers systemd offers in .path units are already sufficient to
  make this work.
 
  What if no jobs are there and a non-root user adds a crontab later on? Who
  will start cron (as root) ?
 
 I guess ListenStream=/var/spool/cron/* (if it will work - I'm not sure
 how systemd interprets wildcards and multiple ListenStream)

Almost. This is a .path unit, the syntax is:

DirectoryNotEmpty=/var/spool/cron

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Michał Piotrowski]

Someone uses cherokee web server? Please check this service
https://bugzilla.redhat.com/show_bug.cgi?id=657085

Kind regards,
Michal
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Lennart Poettering]

On Wed, 24.11.10 22:08, Michał Piotrowski (mkkp...@gmail.com) wrote:

 
 Someone uses cherokee web server? Please check this service
 https://bugzilla.redhat.com/show_bug.cgi?id=657085

Looks good (haven't tested it though, and don't really know
cherokee). In this case however, I think it would actually make sense to
use Type=forking and pass -d. Why? Because another service might want
to access cherokee over HTTP or so and if you don't use Type=forking
then that other service is using After=cherokee.service it might access
it before the server is actually up.

BTW, is the -C /etc/cherokee/cherokee.conf really necessary?
Independently of systemd i Actually believe we should simplify the
command lines as much as possible, and if /etc/cherokee/cherokee.conf is
the default config file anyway I think it would be nice to drop that
argument.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Michał Piotrowski]

I wanted to convert httpd, and I saw that it's already converted and
it uses socket

httpd.socket
ListenStream=80

What if administrator want to change port to other? Let's say, that
I've got configured three servers:
80 - cherokee
81 - apache
82 - nginx

In this enviroment httpd.socket should trigger cherokee not apache.
Parameter to ListenStream should be taken from server config somehow.
Is it possible tu run magic grep ^Listen /etc/httpd/conf/httpd.conf |
cut -d   -f 2 in ListenStream?

Best regards,
Michal
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Lennart Poettering]

On Wed, 24.11.10 22:32, Michał Piotrowski (mkkp...@gmail.com) wrote:

 I wanted to convert httpd, and I saw that it's already converted and
 it uses socket
 
 httpd.socket
 ListenStream=80

Where do I find this? Its not in the pkg git tree nor in bugzilla?

 What if administrator want to change port to other? Let's say, that
 I've got configured three servers:
 80 - cherokee
 81 - apache
 82 - nginx

The recommended way to modify the default configuration is to copy
/lib/systemd/system/httpd.socket to /etc/systemd/system/httpd.socket and
then edit it there. That way you can easily drop back to the default
setup by deleting this file again. Files in /etc/systemd/system take
precedence over those equally named in /lib/systemd/system.

 In this enviroment httpd.socket should trigger cherokee not apache.
 Parameter to ListenStream should be taken from server config somehow.
 Is it possible tu run magic grep ^Listen /etc/httpd/conf/httpd.conf |
 cut -d   -f 2 in ListenStream?

No, we don't support that really. And I am not convinced we should.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Michał Piotrowski]

2010/11/24 Lennart Poettering mzerq...@0pointer.de:
 On Wed, 24.11.10 22:08, Michał Piotrowski (mkkp...@gmail.com) wrote:


 Someone uses cherokee web server? Please check this service
 https://bugzilla.redhat.com/show_bug.cgi?id=657085

 Looks good (haven't tested it though, and don't really know
 cherokee). In this case however, I think it would actually make sense to
 use Type=forking and pass -d. Why? Because another service might want
 to access cherokee over HTTP or so and if you don't use Type=forking
 then that other service is using After=cherokee.service it might access
 it before the server is actually up.

Ok, I changed it to forking (I tried it before and it didn't worked
after reboot - I think that the httpd.socket had something to do with
that)


 BTW, is the -C /etc/cherokee/cherokee.conf really necessary?
 Independently of systemd i Actually believe we should simplify the
 command lines as much as possible, and if /etc/cherokee/cherokee.conf is
 the default config file anyway I think it would be nice to drop that
 argument.

Ok, agree.

I created second version without -C /path/to/config - let maintainer
choose the right version in his opinion.


 Lennart

 --
 Lennart Poettering - Red Hat, Inc.
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel

Kind regards,
Michal
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Michał Piotrowski]

2010/11/24 Lennart Poettering mzerq...@0pointer.de:
 On Wed, 24.11.10 22:32, Michał Piotrowski (mkkp...@gmail.com) wrote:

 I wanted to convert httpd, and I saw that it's already converted and
 it uses socket

 httpd.socket
 ListenStream=80

 Where do I find this? Its not in the pkg git tree nor in bugzilla?

O LOL sorry for the noise :)
I created it six days ego :)


 What if administrator want to change port to other? Let's say, that
 I've got configured three servers:
 80 - cherokee
 81 - apache
 82 - nginx

 The recommended way to modify the default configuration is to copy
 /lib/systemd/system/httpd.socket to /etc/systemd/system/httpd.socket and
 then edit it there. That way you can easily drop back to the default
 setup by deleting this file again. Files in /etc/systemd/system take
 precedence over those equally named in /lib/systemd/system.

Ok


 In this enviroment httpd.socket should trigger cherokee not apache.
 Parameter to ListenStream should be taken from server config somehow.
 Is it possible tu run magic grep ^Listen /etc/httpd/conf/httpd.conf |
 cut -d   -f 2 in ListenStream?

 No, we don't support that really. And I am not convinced we should.

 Lennart

 --
 Lennart Poettering - Red Hat, Inc.
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel

Best regards,
Michal
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Lennart Poettering]

On Wed, 24.11.10 21:25, Michał Piotrowski (mkkp...@gmail.com) wrote:

  BTW, regarding at and cron: what I was thinking of but never check
  ehwther it is feasible is to make cron/at autostart a soon as some job
  is scheduled. I.e. use .path trigger to check whether /etc/crontab and
  user jobs exist, and start cron only then. Similarly for at. That way we
  could support cron and at just fine, and wouldn't even have to run it by
  default. I haven't looked into this in detail however, to see if the
  file triggers systemd offers in .path units are already sufficient to
  make this work.
 
 IMHO good idea. It should look something like this
 ListenStream=/etc/cron.hourly/*
 ListenStream=/etc/cron.daily/*
 ListenStream=/etc/cron.weekly/*
 ListenStream=/etc/cron.monthly/*
 (more or less)

(As mentioned elsewhere, DirectoryNotEmpty= is the right option here)

I think /etc/cron.{hourly, daily, weelkly, monthtly}/ should be handled
by a systemd timer, instead of a cron job in future. After all they
aren't handle by cron really either these days, but indirectly via run-parts.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Tomas Mraz]

On Wed, 2010-11-24 at 21:56 +0100, Lennart Poettering wrote: 
 On Wed, 24.11.10 15:22, Paul Wouters (p...@xelerance.com) wrote:
 
  
  On Wed, 24 Nov 2010, Lennart Poettering wrote:
  
   BTW, regarding at and cron: what I was thinking of but never check
   ehwther it is feasible is to make cron/at autostart a soon as some job
   is scheduled. I.e. use .path trigger to check whether /etc/crontab and
   user jobs exist, and start cron only then. Similarly for at. That way we
   could support cron and at just fine, and wouldn't even have to run it by
   default. I haven't looked into this in detail however, to see if the
   file triggers systemd offers in .path units are already sufficient to
   make this work.
  
  What if no jobs are there and a non-root user adds a crontab later on? Who
  will start cron (as root) ?
 
 That's the point of the .path unit. i.e. you can list dirs to watch. If
 a user then drop a file into one of those dirs cron gets automatically
 started.
 
 Basically, in your .path unit you'd write something like this:
 
 [Path]
 PathExists=/etc/crontab
 DirectoryNotEmpty=/etc/cron.d
 DirectoryNotEmpty=/var/spool/cron
 
 And the moment where /etc/crontab starts to exist, or somebody drops a
 file into /etc/cron.d or /var/spool/cron crond would be automatically
 started.

But what is the point of this? The /etc/crontab always exists and there
always are some files in /etc/cron.d.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Michał Piotrowski]

W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski
mkkp...@gmail.com napisał:
 We can create a list of all scripts in wiki and
 maintainers of individual packages would indicate that they want to
 convert scripts themselves.

How can I get information about all packages that provides init scripts?

When I do
rpm -qf /etc/init.d/*
I get only information about already installed packages. Any magic
switch to get informations about all packages from rpm database?

Best regards,
Michal
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Jason L Tibbitts III]

 MP == Michał Piotrowski mkkp...@gmail.com writes:

MP How can I get information about all packages that provides init
MP scripts?

repoquery --whatprovides '/etc/init.d/*'

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Rudolf Kastl]

2010/11/23 Michał Piotrowski mkkp...@gmail.com:
 W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski
 mkkp...@gmail.com napisał:
 We can create a list of all scripts in wiki and
 maintainers of individual packages would indicate that they want to
 convert scripts themselves.

 How can I get information about all packages that provides init scripts?

 When I do
 rpm -qf /etc/init.d/*
 I get only information about already installed packages. Any magic
 switch to get informations about all packages from rpm database?

no because only installed packages are part of the rpmdb. you could do
yum install '/etc/init.d/*' then you have all the material to convert
;)

kind regards,
Rudolf Kastl


 Best regards,
 Michal
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Michal Schmidt]

On Tue, 23 Nov 2010 17:18:44 +0100 Michał Piotrowski wrote:
 How can I get information about all packages that provides init
 scripts?
 
 When I do
 rpm -qf /etc/init.d/*
 I get only information about already installed packages. Any magic
 switch to get informations about all packages from rpm database?

repoquery -f /etc{,/rc.d}/init.d/\*
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Bruno Wolff III]

On Tue, Nov 23, 2010 at 17:18:44 +0100,
  Michał Piotrowski mkkp...@gmail.com wrote:
 W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski
 mkkp...@gmail.com napisał:
  We can create a list of all scripts in wiki and
  maintainers of individual packages would indicate that they want to
  convert scripts themselves.
 
 How can I get information about all packages that provides init scripts?
 
 When I do
 rpm -qf /etc/init.d/*
 I get only information about already installed packages. Any magic
 switch to get informations about all packages from rpm database?

I believe rpm only knows about packages available locally. You either need
to have the packages installed or a local mirror. (You can use urls to
refer to remote packages with rpm, but that isn't likely to be workable.)
If you have a local mirror you can use the p option and name the rpms.

Otherwise yum is probably a better choice for this, since it can use meta
data to get information. One of the yum utilities may be better than yum
itself, but I am not sure offhand.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Jóhann B. Guðmundsson]

On 11/20/2010 11:46 PM, Michał Piotrowski wrote:
 Hi,

 I would like to help with scripts conversion. IMO the conversion
 action should be coordinated.

 Comments, thoughts?

 Kind regards,
 Michal

I created this a while back so just take your pick from there fill it 
with a link to the new file when you are done and the corresponding bz 
report or package build

https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability

Thank you.

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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Michał Piotrowski]

2010/11/23 Jason L Tibbitts III ti...@math.uh.edu:
 MP == Michał Piotrowski mkkp...@gmail.com writes:

 MP How can I get information about all packages that provides init
 MP scripts?

 repoquery --whatprovides '/etc/init.d/*'

It seems to me that too little packages was returned


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

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Michał Piotrowski]

2010/11/23 Jóhann B. Guðmundsson johan...@gmail.com:
 On 11/20/2010 11:46 PM, Michał Piotrowski wrote:
 Hi,

 I would like to help with scripts conversion. IMO the conversion
 action should be coordinated.

 Comments, thoughts?

 Kind regards,
 Michal

 I created this a while back so just take your pick from there fill it
 with a link to the new file when you are done and the corresponding bz
 report or package build

This is exactly what I wanted :)


 https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability

 Thank you.

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

Best regards,
Michal
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[philippe makowski]

2010/11/23 Michał Piotrowski mkkp...@gmail.com:
 W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski
 mkkp...@gmail.com napisał:
 We can create a list of all scripts in wiki and
 maintainers of individual packages would indicate that they want to
 convert scripts themselves.
I'll try to do it for Firebird package
can you give me some hints and place I have to read before ?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

[Michał Piotrowski]

W dniu 23 listopada 2010 18:35 użytkownik philippe makowski
makowski.fed...@gmail.com napisał:
 2010/11/23 Michał Piotrowski mkkp...@gmail.com:
 W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski
 mkkp...@gmail.com napisał:
 We can create a list of all scripts in wiki and
 maintainers of individual packages would indicate that they want to
 convert scripts themselves.
 I'll try to do it for Firebird package
 can you give me some hints and place I have to read before ?

This is a good start point
http://0pointer.de/blog/projects/systemd-for-admins-3.html

About services, sockets, targets etc
http://0pointer.de/public/systemd-man/

You may want to read all systemd related things from
http://0pointer.de/blog/
(if you don't know how it works, you should start from begining)

Best regards,
Michal
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel