Description of problem: When the installation (kickstart-driven or manual) happens in a network environment _different_ from the deployment environment, Anaconda-created ifcfg-ethX files can cause problems downstream. Note that Anaconda writes the ifcfg files even if no configuration has happened. The OLPC School Server build deploys ifcfg-* files as part of a configuration rpm. When this package is installed via anaconda/kickstart, conflicts ensue. (The conflicts are also hard to work around as RPM does not always handle them gracefully.)
Actually, it should never overwrite existing ifcfg-ethX files on disk.
Ping anaconda maintainers?
Chris, Could we add something to pykickstart to allow a network line in a kickstart file to tell anaconda to not write out the configuration data? Seems easy to add.
This would not be hard to do in pykickstart at all, assuming it's something we want to add.
Now that I think about it, I'm not sure if a kickstart directive is the right thing to do here. I propose two solutions: 1) Modify anaconda to not write out ifcfg-DEVICE files if we see that they already exist in /mnt/sysimage, so if someone adds a yum repo that provides an RPM that installs these files, we won't drive over them and the end user still gets the benefit of having RPM manage the config files. 2) Don't change anything and say that this particular use case is best solved with a custom %post script in the kickstart file that removes the anaconda-created ifcfg files and then installs the site package using yum. Thoughts?
Oh, I should say that I would prefer solution #1 because it gives kickstart users the most flexibility and least amount of work. Their %pre or an RPM they make can drop ifcfg files on the system and we will leave them be.
David - #1 seems okay to me, though it's a pretty big change from how anaconda's traditionally worked. We should probably take this to the mailing list and it certainly doesn't seem like something we can do for F10.
(In reply to comment #7) > David - #1 seems okay to me, though it's a pretty big change from how > anaconda's traditionally worked. We should probably take this to the mailing > list and it certainly doesn't seem like something we can do for F10. Taking it to the list is fine. And no, this is not something I wanted to do for F-10. This is F-11 territory, at best.
#1 is great from my POV. I'm a bit puzzled as to why Chris says that it's a big change -- preserving preexisting files looks like a subtle enhancement to me -- but the change as described makes me happy so I won't be complaining much :-) I'll keep my eyes open for a patch or rpm to test.
Created attachment 322810 [details] anaconda-preserve-ifcfg.patch Here's a rough start at what I think we should do. I will take this to anaconda-devel-list after F-10 is out the door. My thought is we should preserve networking config files if you are doing a kickstart installation or an upgrade. Otherwise, anaconda will kick out config files as it does now.
Patch accepted and committed to git repository. The next build of anaconda in rawhide will contain this fix. The new behavior of anaconda when writing out network configuration files will be to skip over any that exist on the target system. This should allow you to provide an RPM with site-specific configuration files or to write configuration files in the kickstart script and not have anaconda overwrite them. When you can, please test this fix in rawhide to see if it works. If it does, move the bug to CLOSED RAWHIDE.
*** Bug 479893 has been marked as a duplicate of this bug. ***
Will it also preserve the ifcfg* files for manual Live install where you cannot use kickstart?
This is a significant improvement -- thanks! -- but having a kickstart option to not write any is _also_ important. The RPMs you install may be creating ifcfg-* config files for those devices, but they may be using different device names (thanks to the wonders of udev). This is _definitely_ the case for OLPC's school server. Without this additional option, it is possible that the RPM will deploy ifcfg files and udev scripts to mange the interfaces, but the ifcfg files will have different names than anaconda's. Anaconda may also be writing udev 'persistent' scripts to retain the NIC mapping. This option should also prevent those scripts from being written.
Need a new kickstart option in pykickstart in order to make a new patch for anaconda.
While looking at this in more detail, I don't think I'm that crazy about the idea of a kickstart option to prevent writing out network configuration files during installation. That opens up the door to having anaconda possibly build an unusable system, which is not a goal of the installer. With the patch that's in anaconda now, we do handle the case where existing configuration files are preserved. I think this is sufficient. For your use case where you deliver config files via a site-specific RPM, things do get trickier. You should be installing that RPM during %post in the kickstart file. Your RPM delivering those configuration files should contain a %pre script that ensures existing configuration files are out of the way before dropping new ones on the system. Additionally, if you do want to install your site-specific RPM during package installation, anaconda should now skip over writing out any ifcfg files that exist on the target system. But, as you said, that only works if the device names you are using match what we're using. If there is a disconnect there, you should just go with installing your site-specific package in %post in the kickstart file and clearing out ifcfg- files then. I really don't want to have an option in anaconda to disable writing out configuration files. I think enough is there in anaconda to accomplish what you want to do, and we don't have to open the door to negative switches in kickstart (e.g., do not write configuration files for network settings).