On Wed, 2013-07-17 at 14:06 +0200, Jan Pazdziora wrote:
> On Mon, Jul 08, 2013 at 09:09:24AM -0400, Simo Sorce wrote:
> > On Thu, 2013-06-20 at 17:13 +0200, Ana Krivokapic wrote:
> > > -After=network.target
> > > +After=network.target dirsrv.target
> > > pki-tomcatd@pki-tomcat.service pki-cad.target certmonger.service
> > > httpd.service krb5kdc.service messagebus.service nslcd.service
> > > nscd.service ntpd.service portmap.service rpcbind.service
> > > kadmin.service sshd.service autofs.service rpcgssd.service
> > > rpcidmapd.service chronyd.service
> > >
> > Won't this cause ipa.service to try to restart things twice ?
> > Also this will unconditionally try to start the CA even if not
> > installed.
> >
> > NACK, please let ipa.service handle starting and stopping daemons.
>
> Hello, I'm coming late to this thread but: Should ipa really be
> a service under systemd? Wouldn't making it a target make things a bit
> more pure from systemd's point of view?
IPA is a multi-server system, we want to keep configuration in LDAP so
that an admin can see and potentially control services for the whole
domain at once from an admin workstation, w/o having to log on any
specific server and change local files.
That is why we read the startup list from LDAP in ipactl (called by
ipa.service) and do not store it as targets in systemd.
ipactl supports both systemd and sysv systems.
Once we definitively abandon sysv we could kill ipactl and in it's stead
dynamically change the list of targets in the ipa.service file directly.
and enable/disable the scripts in the systemd units directory. However
we would still need some sort of plugin/helper system that monitors the
LDAP tree and applies the appropriate changes to the system when
something is changed in LDAP.
We have expressed the need for acting on the system upon changes in LDAP
for other reasons too (rotating some keytabs, and manipulating other
configuration files), I think we opened a ticket to handle monitoring
the configuration subtree with the ability to cause changes in the local
cn=config based on plugin configuration but I can't find the ticket
right now.
We could add the ability to launch a helper (via dbus or similar).
Once we have that we could move to a native systemd configuration, until
then ...
Simo.
--
Simo Sorce * Red Hat, Inc * New York
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
