Re: [systemd-devel] Why does sysv generator translate Required-Start keyword into an After= ordering dep only ?

[Andrei Borzenkov]

07.03.2016 10:04, Francis Moreau пишет:
> Hello,
> 
> Sorry for the long delay.
> 
> On Fri, Feb 26, 2016 at 5:05 AM, Andrei Borzenkov  wrote:
>> 26.02.2016 00:55, Francis Moreau пишет:
>>>
>>> But now I'm wondering how the following case is handled: a sysinit
>>> script "a" has "Required-Start: b". But "b" is a native systemd
>>> service. I don't think the tool that enable/disable sysv services can
>>> enable and order correctly the native service.
>>>
>>
>> What difference does it make?
> 
> The difference is that in my current understanding nothing will pull "b" in.

That was answered in part you trimmed off. sysvinit never actively
pulled "b" in either so nothing really changed here.

> 
> Indeed "a" will have "After=b" ordering dep but that's not sufficient
> to start "b". And since "b" is native it will not have a "SXXb"
> installed by insserv.
> 
> 
> Thanks.
> 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Supporting properties(configurations) system

[Kyungmin Park]

On Mon, Mar 7, 2016 at 9:14 PM, Simon McVittie
 wrote:
> On 07/03/16 02:46, WaLyong Cho wrote:
>> As you may know, Android has properties.
>> http://developer.android.com/reference/java/util/Properties.html
>>
>> In the desktop side, it maybe similar with configuration system such
>> like gconf.
>
> gconf and its more modern replacement dconf are for per-user settings.
> If that's what you want, I would suggest dconf - or preferably a
> framework like GLib's GSettings or Qt's QSettings, which just provides a
> data model and can support multiple backends (dconf, restricted views of
> dconf proxied into an app container, flat file, Windows
> HKEY_CURRENT_USER registry, etc).

The 'per-user' is not fit for our case (mobile environment). our apps
has same UID. IOW. one app can use another app configuration if it
uses it as is. It must be prohibited.

>
> Per-user settings like dconf and HKEY_CURRENT_USER should not be
> confused with per-system settings, like Windows' HKEY_LOCAL_MACHINE
> registry. On Unix systems, per-system settings are usually stored in
> plain files in /etc, like the ones in /etc/systemd/system/ that
> configure systemd.
another consideration is directory policy. /etc is read mostly but in
our case it's read-only at system partition.
IOW it can't be changed. see recent movement for security, verified
boot based on dm-verity. IOW. it can't write anything at /etc if it's
configured at system partition. that's reason to need configuration or
property daemon and control these requirements, DAC & MAC control at
there.



>
>> I hope the configurations are supporting write protected(ro) and
>> writable(rw). To control this, I think new daemon will be needed and the
>> daemon has to be activated before the clients(user of the configuration
>> system).
>
> Depending on your exact requirements, it might be a better fit to use
> plain files, inotify and no daemon. Normal Unix DAC permissions, or
> LSMs' MAC policies, can provide read-only and read/write.

even though it's written read-only. actually it's write-once at boot
time and read-only after that.

probably it's not enough to describe our requirement. but we need both
DAC and MAC controlled configuration for mobile environment. we
checked gconf/dconf but it need small and central configuration
systems for both per-user (exactly each app even though it's same UID)
and system-wide.

Thank you,
Kyungmin Park
>
> --
> Simon McVittie
> Collabora Ltd. 
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Can't make local user.conf work

[Kok, Auke-jan H]

On Mon, Mar 7, 2016 at 7:31 AM, G D'Arezzo  wrote:
> On 29 February 2016 at 19:05, Kok, Auke-jan H  
> wrote:
>> On Sun, Feb 28, 2016 at 8:26 PM, G D'Arezzo  wrote:
>>> "You probably want to use [Service] instead."
>>>
>>> Thanks for the suggestion, Auke.  Unfortunately, Service and
>>> DefaultEnvironment don't go together:
>>>
>>> [/home/temp/.config/systemd/user/test.service.d/user.conf:2] Unknown
>>> lvalue 'DefaultEnvironment' in section 'Service'
>>
>> I just reread the man page for that. DefaultEnvironment is valid only
>> for user.conf, not any conf.d* file associated with a specific unit
>> (obviously, since those are not variants of "user.conf", but instead
>> are variants of unit files).
>>
>> The [Manager] section is only valid in:
>>
>>/etc/systemd/user.conf, /etc/systemd/user.conf.d/*.conf,
>> /run/systemd/user.conf.d/*.conf,
>>/usr/lib/systemd/user.conf.d/*.conf
>>
>> The manual page systemd-user.conf(5) does not mention at all being
>> able to use ~/.config/systemd/. This seems like a shortcoming to me,
>> though.
>>
>> Auke
>
>
> Is this a feature which never happened or should it work?

I'm fairly sure it just never happened.

Auke
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Why does sysv generator translate Required-Start keyword into an After= ordering dep only ?

[Francis Moreau]

On Mon, Mar 7, 2016 at 2:13 PM, Lukáš Nykrýn  wrote:
> Francis Moreau píše v Po 07. 03. 2016 v 08:04 +0100:
>> Hello,
>>
>> Sorry for the long delay.
>>
>> On Fri, Feb 26, 2016 at 5:05 AM, Andrei Borzenkov <
>> arvidj...@gmail.com> wrote:
>> > 26.02.2016 00:55, Francis Moreau пишет:
>> > >
>> > > But now I'm wondering how the following case is handled: a
>> > > sysinit
>> > > script "a" has "Required-Start: b". But "b" is a native systemd
>> > > service. I don't think the tool that enable/disable sysv services
>> > > can
>> > > enable and order correctly the native service.
>> > >
>> >
>> > What difference does it make?
>>
>> The difference is that in my current understanding nothing will pull
>> "b" in.
>>
>> Indeed "a" will have "After=b" ordering dep but that's not sufficient
>> to start "b". And since "b" is native it will not have a "SXXb"
>> installed by insserv.
>
> IIRC the behavior is still the same as it always was. Chkconfig on (at
> least rhel-based systems) did not enable the dependencies for the
> service. It only assured that the services will be started in the
> correct order.

That doesnt seem to match what Lennart said previously:

"""
Well, on SysV the requirement in the "Required-Start:" concept is
actually a request to the tool that enables/disables a service
(i.e. the chkconfig or update-rcd tool, depending on the distro). It
means that it shall enable another service "b" if "a" is to be
enabled.
"""

Thanks.
-- 
Francis
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Can't make local user.conf work

[G D'Arezzo]

On 29 February 2016 at 19:05, Kok, Auke-jan H  wrote:
> On Sun, Feb 28, 2016 at 8:26 PM, G D'Arezzo  wrote:
>> "You probably want to use [Service] instead."
>>
>> Thanks for the suggestion, Auke.  Unfortunately, Service and
>> DefaultEnvironment don't go together:
>>
>> [/home/temp/.config/systemd/user/test.service.d/user.conf:2] Unknown
>> lvalue 'DefaultEnvironment' in section 'Service'
>
> I just reread the man page for that. DefaultEnvironment is valid only
> for user.conf, not any conf.d* file associated with a specific unit
> (obviously, since those are not variants of "user.conf", but instead
> are variants of unit files).
>
> The [Manager] section is only valid in:
>
>/etc/systemd/user.conf, /etc/systemd/user.conf.d/*.conf,
> /run/systemd/user.conf.d/*.conf,
>/usr/lib/systemd/user.conf.d/*.conf
>
> The manual page systemd-user.conf(5) does not mention at all being
> able to use ~/.config/systemd/. This seems like a shortcoming to me,
> though.
>
> Auke


Is this a feature which never happened or should it work?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Why does sysv generator translate Required-Start keyword into an After= ordering dep only ?

[Lukáš Nykrýn]

Francis Moreau píše v Po 07. 03. 2016 v 08:04 +0100:
> Hello,
> 
> Sorry for the long delay.
> 
> On Fri, Feb 26, 2016 at 5:05 AM, Andrei Borzenkov <
> arvidj...@gmail.com> wrote:
> > 26.02.2016 00:55, Francis Moreau пишет:
> > > 
> > > But now I'm wondering how the following case is handled: a
> > > sysinit
> > > script "a" has "Required-Start: b". But "b" is a native systemd
> > > service. I don't think the tool that enable/disable sysv services
> > > can
> > > enable and order correctly the native service.
> > > 
> > 
> > What difference does it make?
> 
> The difference is that in my current understanding nothing will pull
> "b" in.
> 
> Indeed "a" will have "After=b" ordering dep but that's not sufficient
> to start "b". And since "b" is native it will not have a "SXXb"
> installed by insserv.

IIRC the behavior is still the same as it always was. Chkconfig on (at
least rhel-based systems) did not enable the dependencies for the
service. It only assured that the services will be started in the
correct order.

The only script that cared about enabled dependencies was the
install_initd, which refused to install the initscript if its
requirements were not met.

If you want that behavior to change you should file a RFE to your
chkconfig/install_initd/systemd-sysv-install implementation.

Lukas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Supporting properties(configurations) system

[Simon McVittie]

On 07/03/16 02:46, WaLyong Cho wrote:
> As you may know, Android has properties.
> http://developer.android.com/reference/java/util/Properties.html
> 
> In the desktop side, it maybe similar with configuration system such
> like gconf.

gconf and its more modern replacement dconf are for per-user settings.
If that's what you want, I would suggest dconf - or preferably a
framework like GLib's GSettings or Qt's QSettings, which just provides a
data model and can support multiple backends (dconf, restricted views of
dconf proxied into an app container, flat file, Windows
HKEY_CURRENT_USER registry, etc).

Per-user settings like dconf and HKEY_CURRENT_USER should not be
confused with per-system settings, like Windows' HKEY_LOCAL_MACHINE
registry. On Unix systems, per-system settings are usually stored in
plain files in /etc, like the ones in /etc/systemd/system/ that
configure systemd.

> I hope the configurations are supporting write protected(ro) and
> writable(rw). To control this, I think new daemon will be needed and the
> daemon has to be activated before the clients(user of the configuration
> system).

Depending on your exact requirements, it might be a better fit to use
plain files, inotify and no daemon. Normal Unix DAC permissions, or
LSMs' MAC policies, can provide read-only and read/write.

-- 
Simon McVittie
Collabora Ltd. 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel