Marking default config files as noreplace in RPMs

[kodemaniak]

Currently, the config files get replaced during an rpm update. However, at least for production deployments it is very likely that the default configs have been modified on disk, so that replacing them with the defaults during an update will actually make the services not run correctly (which might even result in serious problems obviously). For rpms there is the option to mark files as "config(noreplace)" in order to tell rpm not to update the files on disk automatically, but to copy the default config (if it has changed) to a new file called .rpmnew. The RPM plugin already supports this, only the default mappings need to be changed AFAICT.

see also: https://groups.google.com/forum/#!topic/sbt-native-packager/SjdgGI1deZk

[zoosky]

+1

[muuki88]

Please use the github reactions for +1 ones, doesn't clutter the stream that much then ;)

If someone would like to do a pull request, this would be a way to introduce this feature a small configuration plugin.

• LinuxNoReplaceConfig AutoPlugin in linux package
• plugin maps over the linuxPackageMappings and changes everything were config != "false" to config to noreplace

This may look like

import sbt._

object LinuxNoReplaceConfig extends AutoPlugin {
    override def requires = RpmPlugin // only useful for rpm

    override def projectSettings: Seq[Setting[_]] = inConfig(Rpm)(Seq(
        linuxPackageMappings := configWithNoReplace(linuxPackageMappings.value)
    ))

   def configWithNoReplace(mappings: Seq[LinuxPackageMapping]): Seq[LinuxPackageMapping] = {
       mappings.map {
          case mapping if mapping.fileData.config != "false" => mapping.withConfig("noreplace")
          case mapping => mapping
       }
   }
}

With some documentation and a small test, this would be it.

[kodemaniak]

I finally gave this a try. I wrote a LinuxNoReplace plugin that does correctly mark the config files as noreplace in the spec file. However, I realized that config files as, e.g., contributed by the JavaServerApp archetype are not contained in linuxPackageMappings when the plugin is executed. As a result, those are not marked noconfig. I have not figured out yet, how to include them as well.

[muuki88]

You must depend on the JavaServerAppPackaging as well. So the plugin will be enabled afterwards.

[muuki88]

Thanks for giving this a shot :)

[kodemaniak]

Does that mean, the Plugin will stop working without the JavaServerApp? Because, generally, it would also make sense for normal App packages.

Am 13. Oktober 2016 03:01:30 MESZ, schrieb Nepomuk Seiler notifications@github.com:

You must depend on the JavaServerAppPackaging as well. So the plugin
will be enabled afterwards.

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#572 (comment)

Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

[muuki88]

I guess so. You're right that this would be not ideal. The other option would be to provide a helper method ( there is already a LinuxMappingsDSL ) trait that provides some utility methods.

Adding a method there would leave the user with something like the project settings in my suggestion above.

[kodemaniak]

Just to make sure that I get it right: You mean instead of providing a plugin that marks configs as noreplace, one could provide a helper method and the user would manually map over linux package mappings using that helper method from within his own build.sbt? That step would then be performed after all other plugins have run, so that all config files are correctly mapped?

[kodemaniak]

OK, it's the other way around, if I depend on the JavaServerAppPackaging, it seems to be added automatically by sbt.

[muuki88]

That behaviour can be turned off by setting trigger in the auto plugin. However I thought this was not the default behaviour.

Thinking more about this. A helper method in the LinuxMappingsDSL would be a better way. We could even write unit tests for this.

[kodemaniak]

Yep, that's actually the way I started to implement right now. However, I could imagine to keep the Plugin as well, as I think in most cases you want this functionality for server apps. So making config files noreplace for server apps would be possible by using the plugin, for other scenarios you can use the helper method.

[kardapoltsev]

Why not make this behavior a default one? It seems to be reasonable.

[kodemaniak]

In RPMs this seems no to be the default behaviour, so it might be better to require this to be enabled explicitly in builds. I could also set trigger = allRequirements on the plugin. Then one could disable it explicitly instead of enabling it explicitly (at least if understand the sbt docs correctly, haven't tested it).