[systemd-devel] We are working on Secure Container Applications.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/09/2012 09:38 PM, Lennart Poettering wrote:
> On Mon, 09.01.12 16:42, Daniel J Walsh (dwalsh at redhat.com) wrote:
> 
>> The idea is to run multiple instances of the same application
>> within a container.  For example multiple Apache servers.
>> 
>> I am working on a tool to create these containers, which will
>> create a service unit file.
>> 
>> # virt-sandbox-service create -e /usr/sbin/httpd httpd_sanbox 
>> Created container dir /var/lib/libvirt/filesystems/httpd_sanbox 
>> Created sandbox config /etc/libvirt-sandbox/httpd_sanbox.sandbox 
>> Created unit file /etc/systemd/system/httpd_sanbox.service
>> 
>> One problem we see with this is when the httpd program gets
>> updated, it runs a systemctl reload httpd.service, to cause the
>> httpd service to restart.  We would like to get this reload
>> command from systemd also.
>> 
>> What do you guys think of adding something like the following to
>> the service unit?
>> 
>> ReloadRequest: httpd.service
>> 
>> Then anyone asking to reload the httpd.service would also cause
>> the httpd_sandbox.service to get the reload.
> 
> Hmm, yupp I think this would make sense, after all we already are 
> capable of propagating restart requests between services, along 
> requirement dependency paths. So we probably should provide the
> same for reloading, too (though this needs to be independent of
> requirement deps). So yeah, I think having a new dependency type
> would make a lot of sense, I'd propose a different name though,
> something like "PropagateReload=" where all service which to
> propagate reload to may be listed.
> 
Well I would prefer to have my services request Reloads destined for a
particular service, rather then updating an existing service file to
add my new services.


> If I understand this correctly you are planning to support
> multiple simultaneous instances of these sandboxed services? May I
> suggest using systemd instanced services for that? That way the
> instances would show up as individual services in systemd and can
> be handled like any other service:
> 
> http://0pointer.de/blog/projects/instances.html
> 
I will look into this.
> To make this entirely convincing we'd need a way to allow 
> stopping/restarting/... all instances of a certain kind at once
> though, which currently doesn't exist. (example, let's say you
> have sandboxed-apache at foobar.service,
> sandboxed-apache at waldo.service and so on, and when
> sandboxed-apache.rpm is removed you want to ensure that all these
> instances are stopped, we need a sane way to stop them all at once,
> instead of having to figure out which instances are running and 
> then stop them indivudally). To make this easy I'll extend the
> D-Bus logic a bit so that "systemctl stop quux at .service" (i.e.
> without an instance part in the name) will stop all instances of
> that template.
> 
So if I have a sandboxed version of httpd.server, you would want me to
name them httpd at sandbox1.service?

# virt-sandbox-service create -e /usr/sbin/httpd sandbox1
Created container dir /var/lib/libvirt/filesystems/sanbox1
Created sandbox config /etc/libvirt-sandbox/sandbox1.sandbox
Created unit file /etc/systemd/system/httpd at sanbox1.service
# virt-sandbox-service create -e /usr/sbin/httpd sandbox2
Created container dir /var/lib/libvirt/filesystems/sanbox2
Created sandbox config /etc/libvirt-sandbox/sandbox2.sandbox
Created unit file /etc/systemd/system/httpd at sanbox2.service
Then you could say

systemctl stop httpd at .service

Would stop httpd.service, httpd at sandbox1.service and
httpd at sandbox2.service


> I added this to the TODO list now, both should be available in not
> so long time from now, as they aren't hard to implement.
> 
> Thanks for your suggestions!
> 
> Lennart
> 

Not one of the other comments in this chain was asking about bindto,
which I don't want.  I want to allow an admin to run my services
without running httpd.service for example.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8MVvQACgkQrlYvE4MpobOhwACfeq/+8K48wnYT6nhX69mvZYAX
rHAAn0C7fznj02ri0UqKO1cBKRFDB4fJ
=42KA
-----END PGP SIGNATURE-----