[Starlingx-discuss] Creating new packages for Initialization / Configuration files
Brent, et al: There are a number of packages that contain modified configuration files that bring in alternate default files and in some cases modified initialization scripts. Currently there are puppet packages that do some configuration management. We could continue with puppet for these configurations that we want to disengage from the upstream patches, or we can use RPM package. Thoughts? Examples of configuration patches from stx-integ/base are: centos-release (issue files) iptables (iptables rules) dhcp vim (vimrc!) lighttp pam sanlock shadow sudo util-linux Regarding centos-release Issue files: As you saw today, I proposed removing the issue* files from a otherwise unmodified centos-release package, is there a reason that we need to restore those issue files for an Open Source OS Independent project? Those modified issue files contain legalize that seems appropriate for a commercial product, but not sure if makes sense for an Open Source project that a downstream OSV or other company would likely modify for their use anyway. Sau!
For many of these, using puppet templates will be a viable alternative. There may be cases where a change is needed during installation, and we'd have a couple of options there. In some cases, we may be able to package an override file. Alternatively, we could use the kickstarts to make changes during postinstall, if absolutely necessary. We'd need to look at them case by case to decide what the best option would be. -----Original Message----- From: Saul Wold [mailto:sgw@linux.intel.com] Sent: Wednesday, August 08, 2018 9:35 PM To: Rowsell, Brent; starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] Creating new packages for Initialization / Configuration files Brent, et al: There are a number of packages that contain modified configuration files that bring in alternate default files and in some cases modified initialization scripts. Currently there are puppet packages that do some configuration management. We could continue with puppet for these configurations that we want to disengage from the upstream patches, or we can use RPM package. Thoughts? Examples of configuration patches from stx-integ/base are: centos-release (issue files) iptables (iptables rules) dhcp vim (vimrc!) lighttp pam sanlock shadow sudo util-linux Regarding centos-release Issue files: As you saw today, I proposed removing the issue* files from a otherwise unmodified centos-release package, is there a reason that we need to restore those issue files for an Open Source OS Independent project? Those modified issue files contain legalize that seems appropriate for a commercial product, but not sure if makes sense for an Open Source project that a downstream OSV or other company would likely modify for their use anyway. Sau! _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Folks, As I have been scanning through the various patches that are maintained in the stx-integ and other repos, I think we have a couple of classes: Source level changes in the form of patches, these need to be fully understood and upstreamed where possible. Build configuration changes, typically autoconf style of settings. Then there are the System level changes on a per package basis these are the ones that I want move to alternative mechanisms where possible such that it will allow us to reduce building the source rpm. The types of changes here are: User / Group Creation New configuration files New services Updated configuration files Modify services Overwrite default (for example: /etc/issue*) As mentioned below, we can take a couple of different approaches, %post in a new rpm, kickstart files for anaconda, or puppet. I would prefer not to get locked into puppet or even full anaconda kickstart as we start to think about how to handle MultiOS solutions. I believe that most of the above changes need to be applied during the initial installation of the OS and Openstack, in order to ensure first boot proceeds and allows all the middleware to run correct and complete any initialization that's required on first boot. We are continuing with the analysis of patches in the master spreadsheet, focusing on the stx-integ repo to start with. Sau! On 08/08/2018 06:40 PM, Penney, Don wrote:
For many of these, using puppet templates will be a viable alternative. There may be cases where a change is needed during installation, and we'd have a couple of options there. In some cases, we may be able to package an override file. Alternatively, we could use the kickstarts to make changes during postinstall, if absolutely necessary. We'd need to look at them case by case to decide what the best option would be.
-----Original Message----- From: Saul Wold [mailto:sgw@linux.intel.com] Sent: Wednesday, August 08, 2018 9:35 PM To: Rowsell, Brent; starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] Creating new packages for Initialization / Configuration files
Brent, et al:
There are a number of packages that contain modified configuration files that bring in alternate default files and in some cases modified initialization scripts.
Currently there are puppet packages that do some configuration management. We could continue with puppet for these configurations that we want to disengage from the upstream patches, or we can use RPM package.
Thoughts?
Examples of configuration patches from stx-integ/base are: centos-release (issue files) iptables (iptables rules) dhcp vim (vimrc!) lighttp pam sanlock shadow sudo util-linux
Regarding centos-release Issue files:
As you saw today, I proposed removing the issue* files from a otherwise unmodified centos-release package, is there a reason that we need to restore those issue files for an Open Source OS Independent project?
Those modified issue files contain legalize that seems appropriate for a commercial product, but not sure if makes sense for an Open Source project that a downstream OSV or other company would likely modify for their use anyway.
Sau!
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
participants (2)
-
Penney, Don
-
Saul Wold