Re: [systemd-devel] Vendor default masked service

2015-06-18 Thread Lennart Poettering
On Mon, 01.06.15 08:25, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

   Wouldn't that work?
 
  For dbus activation it would work but other services can still
  activate the service through systemd.
 
  But why is that a problem? If daemons explicitly request another
  service by invoking StartUnit() via the bus, why block this off in
  your usecase?
 
 I think you are right. As long as we can stop the service from being
 bus/socket activated (which we can), we should be good. Really not
 much to do for explicit requests.
 
 Our software has to interpret activation failure messages coming from
 dbus [1] somehow to service shouldn't be started. I am guessing we
 should also be future compatible that these messages will come from
 someone else with kdbus or?
 
 [1] - sender=org.freedesktop.DBus destination=:1.57 object=n/a
 interface=n/a member=n/a cookie=3 reply_cookie=2 error=Unit
 dbus-com.axis.PrioritizedTextOverlay.service failed to load: No such
 file or directory.

Well, with kdbus in the mix the behaviour actually changes quite a
bit. If a .busname unit is active, then sending something to its name
will cause activation of the service for it. However, .busname units
can be started/stopped individually, and thus the busnames don't have
to be activatable all the time. This is quite different from dbus1
where there's only a single list of activatable names, that is in
effect right from the moment dbus-daemon is started to the very end.

Or in other words: if a bus service shall not be activatable using
kdbus/systemd, then you will get a no such service error back,
instead of a failed to actviate error...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Vendor default masked service

2015-06-01 Thread Umut Tezduyar Lindskog
On Thu, May 28, 2015 at 6:25 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Thu, 28.05.15 13:56, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

 On Thu, May 28, 2015 at 1:17 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Wed, 27.05.15 13:05, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:
 
  On Tue, May 26, 2015 at 4:14 PM, Lennart Poettering
  lenn...@poettering.net wrote:
   On Tue, 26.05.15 11:53, Umut Tezduyar Lindskog (u...@tezduyar.com) 
   wrote:
  
   Hi,
  
   I was wondering if we have a way to provide vendor default masked
   service?
  
   Well, so far our thinking was that if the vendor wants to make a unit
   completely unavailable he should simply not ship it in the first
   place.
  
   What's the usecase for a vendor masking a unit, but installing it? Why
   not remove it in the first place entirely?
 
  If we ship a product without the service, we don't have a way of
  installing it again once the product is deployed.
 
  Use case would be: We use one software for a video encoder blade with
  multiple CPUs. Every CPU runs the same software. We have a special
  service which should only run on the first CPU. A generator installs
  the .wants link for the service on first CPU. Another service could
  try to talk to the special service over dbus causing it to be dbus
  activated (where special service is only allowed to be up on first
  CPU). We could install the dbus activation files with generator but it
  gets messy to offload this logic to a generator. Also, special service
  can be activated by using systemd's dbus interface.
 
  My recommendation would be to ship the dbus service file always, but
  make it direct to SystemdService=dbus-com.axis.foobar.waldi.service,
  and then manage dbus-com.axis.foobar.waldi.service as a symlink alias
  to the real bus service. All you do in your generator now is create
  the symlink or not create it...
 
  Wouldn't that work?

 For dbus activation it would work but other services can still
 activate the service through systemd.

 But why is that a problem? If daemons explicitly request another
 service by invoking StartUnit() via the bus, why block this off in
 your usecase?

I think you are right. As long as we can stop the service from being
bus/socket activated (which we can), we should be good. Really not
much to do for explicit requests.

Our software has to interpret activation failure messages coming from
dbus [1] somehow to service shouldn't be started. I am guessing we
should also be future compatible that these messages will come from
someone else with kdbus or?

[1] - sender=org.freedesktop.DBus destination=:1.57 object=n/a
interface=n/a member=n/a cookie=3 reply_cookie=2 error=Unit
dbus-com.axis.PrioritizedTextOverlay.service failed to load: No such
file or directory.

Umut


 I can understand you don't want implicit activation via socket, boot,
 bus but that's all easily managable via systemctl disable and
 systemctl enable. What am I missing?

 Lennart

 --
 Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Vendor default masked service

2015-05-28 Thread Lennart Poettering
On Wed, 27.05.15 13:05, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

 On Tue, May 26, 2015 at 4:14 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Tue, 26.05.15 11:53, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:
 
  Hi,
 
  I was wondering if we have a way to provide vendor default masked
  service?
 
  Well, so far our thinking was that if the vendor wants to make a unit
  completely unavailable he should simply not ship it in the first
  place.
 
  What's the usecase for a vendor masking a unit, but installing it? Why
  not remove it in the first place entirely?
 
 If we ship a product without the service, we don't have a way of
 installing it again once the product is deployed.
 
 Use case would be: We use one software for a video encoder blade with
 multiple CPUs. Every CPU runs the same software. We have a special
 service which should only run on the first CPU. A generator installs
 the .wants link for the service on first CPU. Another service could
 try to talk to the special service over dbus causing it to be dbus
 activated (where special service is only allowed to be up on first
 CPU). We could install the dbus activation files with generator but it
 gets messy to offload this logic to a generator. Also, special service
 can be activated by using systemd's dbus interface.

My recommendation would be to ship the dbus service file always, but
make it direct to SystemdService=dbus-com.axis.foobar.waldi.service,
and then manage dbus-com.axis.foobar.waldi.service as a symlink alias
to the real bus service. All you do in your generator now is create
the symlink or not create it...

Wouldn't that work?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Vendor default masked service

2015-05-28 Thread Umut Tezduyar Lindskog
On Thu, May 28, 2015 at 1:17 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Wed, 27.05.15 13:05, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

 On Tue, May 26, 2015 at 4:14 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Tue, 26.05.15 11:53, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:
 
  Hi,
 
  I was wondering if we have a way to provide vendor default masked
  service?
 
  Well, so far our thinking was that if the vendor wants to make a unit
  completely unavailable he should simply not ship it in the first
  place.
 
  What's the usecase for a vendor masking a unit, but installing it? Why
  not remove it in the first place entirely?

 If we ship a product without the service, we don't have a way of
 installing it again once the product is deployed.

 Use case would be: We use one software for a video encoder blade with
 multiple CPUs. Every CPU runs the same software. We have a special
 service which should only run on the first CPU. A generator installs
 the .wants link for the service on first CPU. Another service could
 try to talk to the special service over dbus causing it to be dbus
 activated (where special service is only allowed to be up on first
 CPU). We could install the dbus activation files with generator but it
 gets messy to offload this logic to a generator. Also, special service
 can be activated by using systemd's dbus interface.

 My recommendation would be to ship the dbus service file always, but
 make it direct to SystemdService=dbus-com.axis.foobar.waldi.service,
 and then manage dbus-com.axis.foobar.waldi.service as a symlink alias
 to the real bus service. All you do in your generator now is create
 the symlink or not create it...

 Wouldn't that work?

For dbus activation it would work but other services can still
activate the service through systemd.

Umut


 Lennart

 --
 Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Vendor default masked service

2015-05-28 Thread Umut Tezduyar Lindskog
On Thu, May 28, 2015 at 2:15 PM, Dimitri John Ledkov
dimitri.j.led...@intel.com wrote:
 On 28 May 2015 at 12:56, Umut Tezduyar Lindskog u...@tezduyar.com wrote:
 On Thu, May 28, 2015 at 1:17 PM, Lennart Poettering
 lenn...@poettering.net wrote:
 On Wed, 27.05.15 13:05, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

 On Tue, May 26, 2015 at 4:14 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Tue, 26.05.15 11:53, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:
 
  Hi,
 
  I was wondering if we have a way to provide vendor default masked
  service?
 
  Well, so far our thinking was that if the vendor wants to make a unit
  completely unavailable he should simply not ship it in the first
  place.
 
  What's the usecase for a vendor masking a unit, but installing it? Why
  not remove it in the first place entirely?

 If we ship a product without the service, we don't have a way of
 installing it again once the product is deployed.

 Use case would be: We use one software for a video encoder blade with
 multiple CPUs. Every CPU runs the same software. We have a special
 service which should only run on the first CPU. A generator installs
 the .wants link for the service on first CPU. Another service could
 try to talk to the special service over dbus causing it to be dbus
 activated (where special service is only allowed to be up on first
 CPU). We could install the dbus activation files with generator but it
 gets messy to offload this logic to a generator. Also, special service
 can be activated by using systemd's dbus interface.

 My recommendation would be to ship the dbus service file always, but
 make it direct to SystemdService=dbus-com.axis.foobar.waldi.service,
 and then manage dbus-com.axis.foobar.waldi.service as a symlink alias
 to the real bus service. All you do in your generator now is create
 the symlink or not create it...

 Wouldn't that work?

 For dbus activation it would work but other services can still
 activate the service through systemd.

 it will attempt to dbus activate non-existing service file since
 there wouldn't be a symlink with a name
 dbus-com.axis.foobar.waldi.service pointing to anything real, and thus
 effectively masked, no?!
Nope. They can call StartUnit (org.freedesktop.systemd1,
/org/freedesktop/systemd1) or systemctl start.
Umut

 --
 Regards,

 Dimitri.
 Pura Vida!

 https://clearlinux.org
 Open Source Technology Center
 Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Vendor default masked service

2015-05-28 Thread Lennart Poettering
On Thu, 28.05.15 13:56, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

 On Thu, May 28, 2015 at 1:17 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Wed, 27.05.15 13:05, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:
 
  On Tue, May 26, 2015 at 4:14 PM, Lennart Poettering
  lenn...@poettering.net wrote:
   On Tue, 26.05.15 11:53, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:
  
   Hi,
  
   I was wondering if we have a way to provide vendor default masked
   service?
  
   Well, so far our thinking was that if the vendor wants to make a unit
   completely unavailable he should simply not ship it in the first
   place.
  
   What's the usecase for a vendor masking a unit, but installing it? Why
   not remove it in the first place entirely?
 
  If we ship a product without the service, we don't have a way of
  installing it again once the product is deployed.
 
  Use case would be: We use one software for a video encoder blade with
  multiple CPUs. Every CPU runs the same software. We have a special
  service which should only run on the first CPU. A generator installs
  the .wants link for the service on first CPU. Another service could
  try to talk to the special service over dbus causing it to be dbus
  activated (where special service is only allowed to be up on first
  CPU). We could install the dbus activation files with generator but it
  gets messy to offload this logic to a generator. Also, special service
  can be activated by using systemd's dbus interface.
 
  My recommendation would be to ship the dbus service file always, but
  make it direct to SystemdService=dbus-com.axis.foobar.waldi.service,
  and then manage dbus-com.axis.foobar.waldi.service as a symlink alias
  to the real bus service. All you do in your generator now is create
  the symlink or not create it...
 
  Wouldn't that work?
 
 For dbus activation it would work but other services can still
 activate the service through systemd.

But why is that a problem? If daemons explicitly request another
service by invoking StartUnit() via the bus, why block this off in
your usecase?

I can understand you don't want implicit activation via socket, boot,
bus but that's all easily managable via systemctl disable and
systemctl enable. What am I missing?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Vendor default masked service

2015-05-27 Thread Umut Tezduyar Lindskog
On Tue, May 26, 2015 at 4:14 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Tue, 26.05.15 11:53, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

 Hi,

 I was wondering if we have a way to provide vendor default masked
 service?

 Well, so far our thinking was that if the vendor wants to make a unit
 completely unavailable he should simply not ship it in the first
 place.

 What's the usecase for a vendor masking a unit, but installing it? Why
 not remove it in the first place entirely?

If we ship a product without the service, we don't have a way of
installing it again once the product is deployed.

Use case would be: We use one software for a video encoder blade with
multiple CPUs. Every CPU runs the same software. We have a special
service which should only run on the first CPU. A generator installs
the .wants link for the service on first CPU. Another service could
try to talk to the special service over dbus causing it to be dbus
activated (where special service is only allowed to be up on first
CPU). We could install the dbus activation files with generator but it
gets messy to offload this logic to a generator. Also, special service
can be activated by using systemd's dbus interface.

Umut

 Lennart

 --
 Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Vendor default masked service

2015-05-26 Thread Umut Tezduyar Lindskog
Hi,

I was wondering if we have a way to provide vendor default masked service?

Vendor default masked service has advantages like:
 - systemctl start won't work
 - dbus activation won't work

It is common that an embedded system doesn't use packages, rather it
ships everything in monolithic image. Enabling, disabling, presetting
is great to prevent a service from starting as part of the target but
it doesn't stop anyone trying to start it with systemd (systemctl
start, or dbus activation).

I have come up with my way but obviously systemctl unmask doesn't
mean anything in this case. I was wondering if there is a way I am not
aware of.

/usr/lib/systemd/system:
aa.service: Service file implementation
a.target.wants/a.service: Start the service with a.target.
a.service: Can either be a link to aa.service (start the service) or
/dev/null (service is masked, won't start).

If the service is masked (a.service - /dev/null), to enable it we
need to create (/etc/systemd/system/a.service -
/usr/lib/systemd/system/aa.service).

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


Re: [systemd-devel] Vendor default masked service

2015-05-26 Thread Lennart Poettering
On Tue, 26.05.15 11:53, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

 Hi,
 
 I was wondering if we have a way to provide vendor default masked
 service?

Well, so far our thinking was that if the vendor wants to make a unit
completely unavailable he should simply not ship it in the first
place.

What's the usecase for a vendor masking a unit, but installing it? Why
not remove it in the first place entirely?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel