Once upon a time, Reindl Harald <h.reindl@xxxxxxxxxxxxx> said: > Am 16.02.2018 um 15:35 schrieb Chris Adams: > >The imapproxy package config defaults to user "nobody", which should be > >changed (probably should have been done a while back, but whatever). > >The user is set in the config though, and the config has to be edited > >for the package to work (to at least set the upstream IMAP server), so > >changing the packaged config will only result in a .rpmnew file. > > > >What's the proper way to fix this? I can update the package to create a > >user and use it in the default config, but is it correct to have a %post > >that changes the existing config (something like a "sed -i")? > > > >I'd also like to switch it from running in daemon mode to foreground > >mode (and change the systemd unit to match), but again, that requires > >editing the config; there's no command-line option for either of these. > > > >I'm not sure of the "best practice" here... as a system admin, it feels > >wrong to have RPM scriptlets editing config, but I don't see another way > >forward, short of modifying the program to accept command-line overrides > >for these options (which has its own "fun") > > don't touch configs - Apache 2.2 and Apache 2.4 configs also where > widely incompatible and within a distr-upgrade as admin you are > supposed to handle such changes but when you touch my configs for > whatever package i get terrible angry because you can't know if it > even works as you expect combined with other non.default options > which are the point of configfiles This is nothing like the Apache change - in this case, the config is exactly the same, but a couple of options need to be changed to continue to work. The user change won't hurt, it's just something that should have been changed from the start. The daemon/foreground change though has to match the systemd unit. I plan to change the unit to expect/use a foreground process, which means if the config is not changed to match, the service won't work right. Is it "okay" to break and require manual configuration intervention on a Fedora version upgrade? -- Chris Adams <linux@xxxxxxxxxxx> _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
