[HEADS-UP] systemd for F14 - the next steps

Daniel J Walsh dwalsh at redhat.com
Wed Jul 14 17:47:24 UTC 2010


On 07/14/2010 01:01 PM, Bill Nottingham wrote:
> Lennart Poettering (mzerqung at 0pointer.de) said: 
>> Well, I don't think we want to support both. I believe F14 should be
>> systemd and only systemd, but we want the option to revert to upstart
>> should that not work out.
>>
>> I am very much interested to get upgraded systems to use systemd as
>> well, which is why I'd really like to go the Obsoletes way, and use a
>> versioned Obsoletes, so that we can switch back to upstart if we want to
>> by another versioned Obsoletes, but this time from upstart. (which is
>> exactly what James Antill proposed in his mail)
>>
>> Or in other words: I'd like to make this switch for the whole distro,
>> not leave it to the individual machines.
>>
>> So, unless there is really strong opposition to the Obsoletes approach
>> I'd go on and do the switch?
> 
> If we're at the... 95% coverage case, I guess. What I don't want is that
> machines suddenly stop booting with no recourse other than init=/bin/bash
> and manual recovery. There are some side cases that would be nice to either
> have working, or documenting that they're not done yet (serial consoles,
> assorted other things.)
> 
>>> I suspect the biggest issue here is confined daemons, as they may
>>> not have permissions to create their own directories in /var/run or
>>> /var/lock once they've been started. Unfortunately, it's the sort of
>>> flag day that we really can't do unless everything in our tree is fixed.
>>
>> Well, a temporary and kind of ugly fix could be to add lines like the
>> following into the systemd service files for these services.
>>
>>  ExecStartPre=-/bin/mkdir -p -Z foo_t /var/run/foo
>>
>> Or something like that. And for service which continue to use SysV
>> scripts something similar is easily thinkable in the init scripts. 
> 
> Hardcoding foo_t is bad if they ever switch policy (MLS, etc.). But
> it is an option.
> 
> Bill
Not sure this works, but this would be preferable.
ExecStartPre=-"/bin/mkdir -p /var/run/foo; restorecon /var/run/foo"

But I can write policy to make the tools do apps do the right think and
label the directory correctly, with no hard coding.

myapp_t creating a directory in var_run_t will be labeled
myapp_var_run_t.  I would just need to go through all the policy that
uses var_run_t directories and make sure it has this rule.


More information about the devel mailing list