Michael DeHaan wrote: > Michael DeHaan wrote: > >> Partha Aji wrote: >> >> >>> Hey Michael, >>> I basically fixed most of the Fix Me, removed some unused stuff... Fixed >>> the cobbler.spec to generate the correct rpms.. Updated the templates to >>> new stuff. I have questions on 3 fix mes that I have to implement >>> >>> # FIXME: missing code to ensure TFTP is enabled >>> # FIXME: missing code to configure firewall (???) >>> # FIXME: missing code to ensure cobblerd, httpd, xinetd is >>> chkconfig on >>> >>> I was wondering if I could simply use the cobbler check logic found in >>> cobbler.cobbler.action_check to do the validation for TFTP enabled and >>> configuring firewall. Secondly are we sure about wanting chkconfig on >>> for those services right (I thought sysadmins were wary of those >>> things).. >>> I was also confused on when to do Subprocess.call( shell=True) vs (shell >>> = False). I currently use Shell = False unless the thing barfed saying >>> can;t execute the child process in which case I 'd go for shell = True >>> . I had to do shell = True for for '/sbin/service cobblerd restart', >>> and "/sbin/service httpd restart" .. I added the logic to check return >>> codes and cease execution if it failed.. Please review the attached >>> patches when you have time and apply them accordingly.. I'll meanwhile >>> work on doing the TFTP enablement checks... >>> >>> PS: >>> I was wondering if you were ok with autogenerating the modules.conf & >>> settings files when they install the cobbler RPM. >>> For example we can have a post script that runs >>> '/usr/bin/cobbler-setup -a >>> /usr/share/cobbler/installer_templates/defaults' >>> This will make the templates the defacto place to add all the new config >>> entries... You can add the default values to installer_templates/defaults >>> That way we don't need keep installer_templates/modules.conf.template in >>> sync with config/modules.conf... Please let me know what you think of >>> the idea... Thanks for the reviews in the last commit.. >>> >>> Partha >>> >>> >>> >> Partha, >> >> I am a bit confused by the first patch as I've already committed the >> changes to remove the dict() based code and so forth. As a result, >> these patches do not apply. I am guessing they were made against the >> copy in the Spacewalk tree, not the copy in the Cobbler tree which >> already had my fixes applied? >> >> --Michael >> >> >> >> >> >> >> >> _______________________________________________ >> cobbler mailing list >> [email protected] >> https://fedorahosted.org/mailman/listinfo/cobbler >> >> > > All so far apply accept Patch 2, which was already committed. > > Testing now... > > > _______________________________________________ > cobbler mailing list > [email protected] > https://fedorahosted.org/mailman/listinfo/cobbler >
Ok, so comments... (A) If using dnsmasq for DHCP, your only choice for DNS management is dnsmasq. If using ISC, your only choice is BIND. So this appears wrong still: Which DNS module do you want to use [isc/dnsmasq] ? (default=isc): dnsmasq Do you want to enable DNS management with BIND [y/n] ? (default=y): (B) On my system (mdehaan.rdu...) it seems the autodetection code for my local system does not work when I press enter for autodetect. If autodetect ever returns 127.0.0.1 the installer should require this value to be entered manually as a server setting of 127.0.0.1 is not going to be usable. (C) I tweaked cobbler check to not fail as some things cobbler check produces are actually warnings. If we want to call this programmatically I think what we really want to do is tweak the code behind cobbler check to have multiple levels of error codes. (D) It would probably be a good idea to ask if folks want to primarily use Xen or KVM for virtualization. If KVM, the default choices should be "virbr0" and "qemu" for bridge & virt type. If xen, "xenbr0" and "xen". This prevents a certain class of questions that frequently comes up on IRC :) (E) If using DHCP management in Cobbler, and the user selects ISC, we should also ask if they want to enable OMAPI for dynamic DHCP updates. Given that omapi support seems a bit newish (anyone out there fully happy with it?) I would recommend the default for this be "N". (F) We talked about (off-list) making the cobbler build process generate config/settings and config/modules.conf using the installer templates and the defaults file, so we can keep less copies of these two in version control, eliminating the dual maintaince problem. I think this is an /outstanding/ idea. (G) Installer should abort if the effective UID is not 0, else we're wasting the users time because we don't have permissions on /etc/cobbler/settings and /etc/cobbler/modules.conf Looks great otherwise, though if you can polish up the above I think it would be even better -- then we can add this to all the cobbler setup instructions in the manpage and the Wiki, which is definitely a better user experience than telling someone to edit the config file and go through the guess-and-check process for starters. Very good, thanks! --Michael _______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
