autoyast_sample: save and restore boot device order

SLES installs have an annoying habit on ppc64 installations of modifying
the boot device order. This leads to (future) failed automated installs
without manual intervention. Work around this by using two shell
snippets to save and restore, respectively, the system's boot device
configuration before and after the installation. Add the shell snippet
invocation to autoyast_sample.xml for documentation purposes, but
I believe this is only useful on power machines (well, and in
particular, nvsetenv only makes sense there).

Tested with SLES11-SP2.

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Fix for issue #17 - Make cobbler import be more squeaky when it doesn't import anything
BUGFIX - instance of Templar() was being created without a config passed in
This caused a stack dump when the manage_in_tftpd module tried to access the config settings
Merge pull request #119 from jimi1283/issue_17

Fix for issue #17 - Make cobbler import be more squeaky when it doesn't import anything
Merge pull request #120 from jimi1283/master

[BUGFIX] instance of Templar() was being created without a config passed in
[BUGFIX] Don't allow Templar classes to be created without a valid config
There are a LOT of places in the templar.py code that use self.settings without checking to make sure a valid config was passed in. This could cause random stack dumps when templating, so it's better to force a config to be passed in. Thankfully, there were only two pieces of code that actually did this, one of which was the tftpd management module which was fixed elsewhere.
Merge pull request #121 from jimi1283/templarconfig

[BUGFIX] Don't allow Templar classes to be created without a valid config
Merge branch 'master' into dynamicsettings
fix infinite netboot cycle with ppc64 systems

I encountered a rather annoying problem with cobbler for ppc64 systems:
after an install succeeded with pxe_just_once set, the DHCP
configuration file/DHCP server process were left alone. The DHCP server
would then respond on the network on the next boot and the target server
never booted from the disk. The netboot is controlled by SMS/yaboot and
if SMS receives a DHCP response for a file to tftpboot (in this case the
file being yaboot), it will stay in an infinite loop within the netboot
code, even if the netboot eventually fails. That code exists in the
field as-is, so fixing it, while worthwhile (if possible), doesn't help
with existing deployments.

I worked around this by only generating the DHCP configuration if a
system does have netboot_enabled set and re-generating the DHCP files
via a new API, sync_dhcp() whenever disable_netboot() is called.

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Merge pull request #122 from nacc/sles_ppc_snippets

autoyast_sample: save and restore boot device order
Merge pull request #123 from nacc/add_sync_dhcp

fix infinite netboot cycle with ppc64 systems and make DHCP config syncs possible without a full sync
Merge branch 'master' into dynamicsettings
sync: move around check for manage_dhcp

Based upon feedback from James Cammarata, rearrange the logic so that
write_dhcp() unconditionally writes the files back, requiring the caller
to check if manage_dhcp is set.

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Merge pull request #124 from nacc/add_sync_dhcp

sync: move around check for manage_dhcp
Merge branch 'master' into dynamicsettings