On 03.04.2015 [17:05:30 +0000], Britt Houser (bhouser) wrote:
>
>
> On 4/3/15, 12:30 PM, "Nishanth Aravamudan" <nacc@linux.vnet.ibm.com> wrote:
>
> >On 03.04.2015 [02:17:17 +0000], Britt Houser (bhouser) wrote:
> >> I'm working on a RHEL7 docker container with cobbler in it.  I have
> >>setup
> >> cobbler in this container to manage dhcpd.
> >
> >It seems like you're not configuring the containers correctly. Cobbler
> >should run in one container and dhcpd should run in another, right?
> >
> >Dare I ask why you're doing this? :)
>
> Right - not the container ideal, but I put the "why" further down.
>
> >
> >>  One hurdle with this setup is that a cobbler sync needs to restart
> >>  dhcpd, but a docker container has no systemd.  So what I've done to
> >>  work around this is to edit
> >>
> >>/usr/lib/python2.7/site-packages/cobbler/modules/sync_post_restart_servic
> >>es
> >>  .py and change the dhcp_restart_command to call a simple shell
> >>  script:
> >>
> >> --
> >> #!/bin/sh
> >>
> >> #dhcpd writes its pid to /var/run/dhcpd.pid
> >> #kill the PID in the file, if the file exists
> >> if [ -f "/var/run/dhcpd.pid" ]
> >> then
> >>   kill `cat /var/run/dhcpd.pid`
> >> fi
> >>
> >> #Start again using command line from
> >>/usr/lib/systemd/system/dhcpd.service
> >> /usr/sbin/dhcpd -cf /etc/dhcp/dhcpd.conf -user dhcpd -group dhcpd
> >> --
> >>
> >> I do realize I'm not really supposed to have more than one process in a
> >> container. But if I put dhcpd in its own container, the problem would
> >>just
> >> be even harder b/c now cobbler in its container needs to restart another
> >> container.
> >
> >No, it just needs to restart (reload) that process. Meaning dhcpd needs
> >either graceful reload, or, as you said, you need to be able to restart
> >the DHCP process itself. Containerization isn't free :)
>
> So to my knowledge, ISC-DHCP doesn't have a "reload", you must kill and
> then restart.  If DHCP is in its own container, killing the process means
> killing the container.  Respawning the process means starting a new
> container.  This in and of itself isn't hard, but invoking that from
> within another container I think would be more difficult than keeping both
> processes in the same container.
>
> >
> >>  So I took the easier route and put them in the same container.
> >> So in this implementation, it would be useful if I could specify a
> >>custom
> >> dhcp_restart_command in /etc/cobbler/settings.  Would that be a change
> >>the
> >> community would be interested in accepting?
> >
> >I think the right way is to provide another option to the
> >
> >[dhcp]
> >module = manage_isc
> >
> >section of configuration, which is something like
> >
> >[dhcp]
> >module = manage_local
> >
> >And configure that appropriately? I've done that, for instance, for
> >having a local version of authentication.
> >
> >-Nish
>
> Can you elaborate on what you envision manage_local would do?  I'm not
> quite following how this would work?  I still want cobbler to be
> generating my dhcpd.conf file from template, I just want to change how
> cobbler restarts dhcpd.

Something like this:

diff --git a/cobbler/action_sync.py b/cobbler/action_sync.py
index 7a41ee2..d201ab6 100644
--- a/cobbler/action_sync.py
+++ b/cobbler/action_sync.py
@@ -233,6 +233,14 @@ class CobblerSync:
                         error_msg = "service dnsmasq restart failed"
                         self.logger.error(error_msg)
                         raise CX(error_msg)
+            elif which_dhcp_module == "manage_local":
+                if restart_dhcp != "0":
+                    # call some external process
+                    rc = utils.subprocess_call(self.logger, "your_script", shell=True)
+                    if rc != 0:
+                        error_msg = "script restart failed"
+                        self.logger.error(error_msg)
+                        raise CX(error_msg)

     def clean_link_cache(self):
         for dirtree in [os.path.join(self.bootloc, 'images'), self.settings.webdir]:

It's sort of gross that cobbler has so specific knowledge of dhcpd in
action_sync.py. In the interest of abstraction and cleaning the code,
I'd suggest, pulling sync_dhcp() itself into the dhcp modules code
(manage_isc, manage_dnsmasq). That is, make sync_dhcp() a member of
self.dhcp objects in action_sync.py

Then you'd just inherit in manage_local from manage_isc and override
sync_dhcp.

-Nish

_______________________________________________
cobbler-devel mailing list
cobbler-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/cobbler-devel