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
> cobbler(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/cobbler
>
>
All so far apply accept Patch 2, which was already committed.
Testing now...
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
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