1:39 a.m.
Hello,
I am trying to make informal review following feature request:
https://bugzilla.redhat.com/show_bug.cgi?id=1244353
One from warnings returned by rpmlint is:
ossim-data.x86_64: W: non-conffile-in-etc /etc/profile.d/ossim.sh
Because ossim.sh is not configuration file but shell script (as usual in
profile.d/) I had a doubt about treating this warning.
So I asked on fedora-review IRC channel and there I received answer that
this warning is acceptable.
In the bugzilla task I received answer that for the ossim.sh file should
be used %config macro.
My question is: what is valid answer for this case?
Thanks in advance for your help.
Best regards.
Marcin Haba
1:54 a.m.
On 08/02/2015 08:39 AM, Marcin Haba wrote:
Hello,
I am trying to make informal review following feature request:
https://bugzilla.redhat.com/show_bug.cgi?id=1244353
One from warnings returned by rpmlint is:
ossim-data.x86_64: W: non-conffile-in-etc /etc/profile.d/ossim.sh
Because ossim.sh is not configuration file but shell script (as usual in
profile.d/) I had a doubt about treating this warning.
Well, I sense a misinterpretation of "%config".
In the context of the /etc file hierarchy "%config" means
"user-customizable", which means rpm/yum/dnf updates must not destroy
any changes a user may have applied and should backup instead.
So I asked on fedora-review IRC channel and there I received answer
that
this warning is acceptable.
Well, it's a minor issue, but it definitely is
arguable.
In the bugzilla task I received answer that for the ossim.sh file
should
be used %config macro.
My question is: what is valid answer for this case?
My recommendation is to use %config.
Ralf
2:53 a.m.
On 02.08.2015 08:54, Ralf Corsepius wrote:
On 08/02/2015 08:39 AM, Marcin Haba wrote:
> Hello,
>
> I am trying to make informal review following feature request:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1244353
>
> One from warnings returned by rpmlint is:
>
> ossim-data.x86_64: W: non-conffile-in-etc /etc/profile.d/ossim.sh
>
> Because ossim.sh is not configuration file but shell script (as usual in
> profile.d/) I had a doubt about treating this warning.
Well, I sense a misinterpretation of "%config".
In the context of the /etc file hierarchy "%config" means
"user-customizable", which means rpm/yum/dnf updates must not destroy
any changes a user may have applied and should backup instead.
> So I asked on fedora-review IRC channel and there I received answer that
> this warning is acceptable.
Well, it's a minor issue, but it definitely is arguable.
> In the bugzilla task I received answer that for the ossim.sh file should
> be used %config macro.
>
> My question is: what is valid answer for this case?
My recommendation is to use %config.
Hello Ralf,
Thanks for your advise.
I added the thread link to bugzilla ticket.
If somebody has a different opinion in this matter, please answer in
this thread.
Best regards.
Marcin Haba
5:34 a.m.
On Sun, 2 Aug 2015 08:39:28 +0200, Marcin Haba wrote:
Hello,
I am trying to make informal review following feature request:
https://bugzilla.redhat.com/show_bug.cgi?id=1244353
One from warnings returned by rpmlint is:
ossim-data.x86_64: W: non-conffile-in-etc /etc/profile.d/ossim.sh
Because ossim.sh is not configuration file but shell script (as usual in
profile.d/) I had a doubt about treating this warning.
So I asked on fedora-review IRC channel and there I received answer that
this warning is acceptable.
Without a rationale, that is a questionable response.
In the bugzilla task I received answer that for the ossim.sh file
should
be used %config macro.
My question is: what is valid answer for this case?
The explanation is given by "rpmlint -i …".
7:24 a.m.
On 02.08.2015 12:34, Michael Schwendt wrote:
> My question is: what is valid answer for this case?
The explanation is given by "rpmlint -i …".
Hello,
Not really. I read output from rpmlint and I am not sure if it is
unambiguous for shell scripts placed in /etc location. Please look:
ossim-data.x86_64: W: non-conffile-in-etc /etc/profile.d/ossim.sh
A non-executable file in your package is being installed in /etc, but is
not a configuration file. All non-executable files in /etc should be
configuration files. Mark the file as %config in the spec file.
Above rpmlint output text can be ambiguous because the 'executable'
meaning may treat at least as:
1) have "execute" file permission
2) have "executable" scripting language code
3) ... others?
In case 2) always can use interpreter to execute script. There is not
need to mark "execute" permission on a file. It looks that exactly this
situation we consider for profile.d/ scripts.
Summary is that there are two meaning issues defined in these questions:
A) if a shell script can be treated as configuration file?
B) does in rpmlint aspect non-executable mean 'without execute
permissions' or 'non-executable at all' (directly and by any interpreter) ?
Since I known answer for this specific profile.d script (use %config
macro), I have no longer doubt. Nevertheless the questions A) and B)
still exist not answered for me, but I guess that it is subject to
longer discussion and not here (off-topic).
Best regards.
Marcin Haba
7:48 a.m.
On Sun, 2 Aug 2015 14:24:00 +0200, Marcin Haba wrote:
> The explanation is given by "rpmlint -i …".
>
Hello,
Not really. I read output from rpmlint and I am not sure if it is
unambiguous for shell scripts placed in /etc location.
Well, it is the contents of the file that matter. The purpose of the
file, not the "type of file". You call them "shell scripts", but all
these files do, if sourced by the shell, is they alter the global
runtime _configuration_ by setting environment variables for a program
that may evaluate those variables.
A) if a shell script can be treated as configuration file?
Certainly. It's a cheap way to set a program's runtime configuration
instead of implementing a full config file loader/parser.
And don't forget, there is a difference between marking files as
%config and %config(noreplace).
B) does in rpmlint aspect non-executable mean 'without execute
permissions' or 'non-executable at all' (directly and by any interpreter) ?
It refers to the exec permission bit. Executables files in /etc being
marked as %config would be another mistake.
It's some sort of white-list to assume that files in /etc meant to be
executed (such as initscripts related files) are not configuration
files in any way. Admin may decide to edit such executables nevertheless
(for reasons unknown), but the next update would overwrite the changes.
Also not forget, rpmlint only warns about it. Not marking them %config
would not be a severe mistake. It's just better to mark them %config
because of the contents of these files.
9:29 a.m.
On 02.08.2015 14:48, Michael Schwendt wrote:
On Sun, 2 Aug 2015 14:24:00 +0200, Marcin Haba wrote:
>> The explanation is given by "rpmlint -i …".
>>
>
> Hello,
>
> Not really. I read output from rpmlint and I am not sure if it is
> unambiguous for shell scripts placed in /etc location.
Well, it is the contents of the file that matter. The purpose of the
file, not the "type of file". You call them "shell scripts", but all
these files do, if sourced by the shell, is they alter the global
runtime _configuration_ by setting environment variables for a program
that may evaluate those variables.
Hello Michael,
Thanks for your comments.
> A) if a shell script can be treated as configuration file?
Certainly. It's a cheap way to set a program's runtime configuration
instead of implementing a full config file loader/parser.
My image of configuration files is that they are files for read/write
purpose by design, because they enables _configure_ something
(application, service, single program, script...whatever). If they are
dedicated only for reading then from my point of view they lose
"configuration" meaning (something like WORM storage ;-) ).
And don't forget, there is a difference between marking files as
%config and %config(noreplace).
Yes, I remember about it. Thanks.
> B) does in rpmlint aspect non-executable mean 'without
execute
> permissions' or 'non-executable at all' (directly and by any interpreter)
?
It refers to the exec permission bit. Executables files in /etc being
marked as %config would be another mistake.
If rpmlint refers 'non-executable' only to the exec permission, what I
believe takes place, and the contents of the file that matter for
determine 'executable/non-executable' type, it means that rpmlint search
'executable' property not there where it should search.
Partially I understand this searching for executable files because it
might be difficult clearly qualify some file to some specific type of
files basing on a file content or just interpreter definition.
However I believe that exist some tools or libraries that can do this
content analyze for rpmlint.
It's some sort of white-list to assume that files in /etc meant
to be
executed (such as initscripts related files) are not configuration
files in any way. Admin may decide to edit such executables nevertheless
(for reasons unknown), but the next update would overwrite the changes.
Good to know that mentioned white-list exists. Could you indicate me
where can I find this white-list?
Also not forget, rpmlint only warns about it. Not marking them
%config
would not be a severe mistake. It's just better to mark them %config
because of the contents of these files.
Yes, right.
Best regards.
Marcin Haba
4:15 p.m.
On Sun, 2 Aug 2015 16:29:06 +0200, Marcin Haba wrote:
>> A) if a shell script can be treated as configuration file?
>
> Certainly. It's a cheap way to set a program's runtime configuration
> instead of implementing a full config file loader/parser.
My image of configuration files is that they are files for read/write
purpose by design, because they enables _configure_ something
(application, service, single program, script...whatever). If they are
dedicated only for reading then from my point of view they lose
"configuration" meaning (something like WORM storage ;-) ).
Why would you say that?
There are read-only config files to set the system-wide default for
everyone. The program reads them first before looking for user's local
config files to override the defaults. The program would never write
the system-wide file file in /etc, but at most the user's local file.
And in general, whether a program can write its own config files is purely
a question of design. Clearly, over the years there have been programs that
only read config files somebody [or some tool] can create.
/etc/bashrc, /etc/profile are examples of %config files where the file
format is shell language code to be interpreted by a shell.
>> B) does in rpmlint aspect non-executable mean 'without
execute
>> permissions' or 'non-executable at all' (directly and by any
interpreter) ?
>
> It refers to the exec permission bit. Executables files in /etc being
> marked as %config would be another mistake.
If rpmlint refers 'non-executable' only to the exec permission, what I
believe takes place, and the contents of the file that matter for
determine 'executable/non-executable' type, it means that rpmlint search
'executable' property not there where it should search.
Partially I understand this searching for executable files because it
might be difficult clearly qualify some file to some specific type of
files basing on a file content or just interpreter definition.
However I believe that exist some tools or libraries that can do this
content analyze for rpmlint.
What would be the benefit? rpmlint cannot get it 100% right
anyway. There could be corner-cases, where a config file gets executed
instead of being "sourced" like a shell include file.
> It's some sort of white-list to assume that files in /etc
meant to be
> executed (such as initscripts related files) are not configuration
> files in any way. Admin may decide to edit such executables nevertheless
> (for reasons unknown), but the next update would overwrite the changes.
Good to know that mentioned white-list exists. Could you indicate me
where can I find this white-list?
With "some sort of white-list" I mean the simplification -- the
simplified assumption -- that files with execute permission are
believed to be executables and not configuration files. And vice
versa. Real configuration files being marked executable are believed
to be mistakes.
2:09 a.m.
On 02.08.2015 23:15, Michael Schwendt wrote:
On Sun, 2 Aug 2015 16:29:06 +0200, Marcin Haba wrote:
>>> A) if a shell script can be treated as configuration file?
>>
>> Certainly. It's a cheap way to set a program's runtime configuration
>> instead of implementing a full config file loader/parser.
>
> My image of configuration files is that they are files for read/write
> purpose by design, because they enables _configure_ something
> (application, service, single program, script...whatever). If they are
> dedicated only for reading then from my point of view they lose
> "configuration" meaning (something like WORM storage ;-) ).
Why would you say that?
Hello Michael,
I trying to express my opinion about my understanding 'configuration
files' meaning.
There are read-only config files to set the system-wide default for
everyone. The program reads them first before looking for user's local
config files to override the defaults. The program would never write
the system-wide file file in /etc, but at most the user's local file.
In my opinion that this type of files can be classified as pre-defined
settings files, not configuration files. In any case, it looks that we
have different understanding configuration files and it causes cross
over our opinions.
I think also that better could be set the environment variables values
in /etc/defaults/ and use these values by shell scripts instead using
hard-coded values in shell scripts.
Coming back to profile.d sample, when somebody try to modify profile.d
file marked as %config [not %config(noreplace)] then after upgrade
package with new profile.d file version, the file will be overwritten
and user will lose introduced changes.
It seems that all this situation uncovers bigger problem :-)
And in general, whether a program can write its own config files is
purely
a question of design. Clearly, over the years there have been programs that
only read config files somebody [or some tool] can create.
/etc/bashrc, /etc/profile are examples of %config files where the file
format is shell language code to be interpreted by a shell.
<cut>
> However I believe that exist some tools or libraries that can do
this
> content analyze for rpmlint.
What would be the benefit? rpmlint cannot get it 100% right
anyway. There could be corner-cases, where a config file gets executed
instead of being "sourced" like a shell include file.
Yes, rpmlint cannot get it 100% right, but it can report potential
executable files more accurate. If something can offload person, that
for example do review request, from manual checking content of files,
why not use it?
>> It's some sort of white-list to assume that files in /etc
meant to be
>> executed (such as initscripts related files) are not configuration
>> files in any way. Admin may decide to edit such executables nevertheless
>> (for reasons unknown), but the next update would overwrite the changes.
>
> Good to know that mentioned white-list exists. Could you indicate me
> where can I find this white-list?
With "some sort of white-list" I mean the simplification -- the
simplified assumption -- that files with execute permission are
believed to be executables and not configuration files. And vice
versa. Real configuration files being marked executable are believed
to be mistakes.
OK. Thanks for clarify.
Best regards.
Marcin Haba
6:09 a.m.
On Mon, 3 Aug 2015 09:09:43 +0200, Marcin Haba wrote:
I trying to express my opinion about my understanding
'configuration
files' meaning.
Of course.
In my opinion that this type of files can be classified as
pre-defined
settings files, not configuration files. In any case, it looks that we
have different understanding configuration files and it causes cross
over our opinions.
So, a configuration file, which contains constants or is not changed for a
very long time, becomes a "settings file"? And a settings file that gets
modified by an admin to customise the defaults becomes a "configuration
file"?
There are more names one could use for such a file, such as "preferences
file, defaults file, initialization file, setup file".
I don't think there is not even a subtle difference. It depends on a
definition of how such a file is supposed to be used. For some sets of
files there is a specific order in which they are read. Instructions on
which file to modify and which file not to touch. Without such specific
instructions, all that matters is whether a change to the file influences
the program's runtime configuration.
I think also that better could be set the environment variables
values
in /etc/defaults/ and use these values by shell scripts instead using
hard-coded values in shell scripts.
Files in /etc/default are configuration files, too, and are to be marked
as such in RPM packages.
Coming back to profile.d sample, when somebody try to modify
profile.d
file marked as %config [not %config(noreplace)] then after upgrade
package with new profile.d file version, the file will be overwritten
and user will lose introduced changes.
It seems that all this situation uncovers bigger problem :-)
Which problem do you see?
If _not_ marked as configuration file, the file will be overwritten by an
update, too. => Any changes are lost and may break runtime configuration
until restoring the modification of the file.
If marked as %config or %config(noreplace), RPM will create .rpmsave or
.rpmnew files the admin/user will need to review.
Where such files are stored, doesn't matter. /etc/default/ is not free of
problems either. Imagine renamed env vars that would be incompatible after
a version upgrade of a package. Migrating config file changes is a basic
system maintenance task.
Yes, rpmlint cannot get it 100% right, but it can report potential
executable files more accurate.
It could only _try to_ and would print even more guesses and false
positives. Such as checking for shebang values in files lacking execute
permission bits. And still it could be intentional that the files are
not executable by default (-> examples, templates, stubs).
If something can offload person, that
for example do review request, from manual checking content of files,
why not use it?
Wishful thinking. A tool like rpmlint will never develop a better
understanding for an RPM package than the person, who created that package
and will maintain it. Reviewing packages is not rocket science. In most
cases a "just do it" mentality during package review phase would be
extremely helpful instead of trying to complicate matters.
12:02 p.m.
Hello Michael,
W dniu 03.08.2015 o 13:09, Michael Schwendt pisze:
> In my opinion that this type of files can be classified as
pre-defined
> settings files, not configuration files. In any case, it looks that we
> have different understanding configuration files and it causes cross
> over our opinions.
So, a configuration file, which contains constants or is not changed for a
very long time, becomes a "settings file"? And a settings file that gets
modified by an admin to customise the defaults becomes a "configuration
file"?
I did not say that.
The only one message that I am trying to say in this point is:
configuration files for me should be designed to configure/modify by
administrator or directly by application.
If some files are designed only for reading values like auto-generated
files or mentioned by you pre-defined variables or just scripts, I do
not treat them in configuration files aspect at all. And better when
they are marked special clause in comment.
As long the types calling is not standardized in a official common
specification and it is used at the discretion, as long we can talk
about it. As I wrote in one from my first mail in this thread:
"I guess that it is subject to longer discussion and not here (off-topic)."
There are more names one could use for such a file, such as
"preferences
file, defaults file, initialization file, setup file".
I don't think there is not even a subtle difference. It depends on a
definition of how such a file is supposed to be used.
Indeed. Unfortunately we do not have any common definition.
> I think also that better could be set the environment variables
values
> in /etc/defaults/ and use these values by shell scripts instead using
> hard-coded values in shell scripts.
Files in /etc/default are configuration files, too, and are to be marked
as such in RPM packages.
> Coming back to profile.d sample, when somebody try to modify profile.d
> file marked as %config [not %config(noreplace)] then after upgrade
> package with new profile.d file version, the file will be overwritten
> and user will lose introduced changes.
>
> It seems that all this situation uncovers bigger problem :-)
Which problem do you see?
I am seeing problem overwriting files if somebody hastily use %config on
script instead %config(noreplace) only because rpmlint returns warning
on package. Then it can result unexpected overwriting this file during
update the package.
If this overrwrite action will cause that for example offline blog
application nothing big is happening. If it will cause move offline
large 24/7 service, it can result troubles.
If marked as %config or %config(noreplace), RPM will create .rpmsave
or
.rpmnew files the admin/user will need to review.
Yes, but for some services triggering offline can be more painful than
configuration lost. On files always can do backup, on services downtime
cannot.
> Yes, rpmlint cannot get it 100% right, but it can report
potential
> executable files more accurate.
It could only _try to_ and would print even more guesses and false
positives. Such as checking for shebang values in files lacking execute
permission bits. And still it could be intentional that the files are
not executable by default (-> examples, templates, stubs).
Yes, I did not think about this cases. You are right.
> If something can offload person, that
> for example do review request, from manual checking content of files,
> why not use it?
Wishful thinking. A tool like rpmlint will never develop a better
understanding for an RPM package than the person, who created that package
and will maintain it. Reviewing packages is not rocket science. In most
cases a "just do it" mentality during package review phase would be
extremely helpful instead of trying to complicate matters.
Thanks for your opinions and valuable discussion.
Best regards.
Marcin Haba
1:15 p.m.
On Mon, 3 Aug 2015 19:02:26 +0200, Marcin Haba wrote:
The only one message that I am trying to say in this point is:
configuration files for me should be designed to configure/modify by
administrator or directly by application.
A moot point, too.
First of all, if not installing prebuilt RPM packages, usually it's the
admin who compiles and installs the software from sources. That involves a
first configuration step already. The admin makes choices where to install
(e.g. /usr vs. /usr/local), which features to enable, and possibly
influences other configuration defaults, too. After installation, the
admin would edit available config file as necessary.
When installing from a distributor's RPM package collection, some of those
steps are handled by the package maintainer. Other steps are postponed.
Again, the admin likely needs to review the prebuilt config files and
apply modifications.
Back to ossim-data:
if [ -z "$OSSIM_INSTALL_PREFIX" ]; then
export OSSIM_INSTALL_PREFIX=/usr
fi
if [ -z "$OSSIM_PREFS_FILE" ]; then
export OSSIM_PREFS_FILE=$OSSIM_INSTALL_PREFIX/share/ossim/ossim_preferences
fi
The program could simply hardcode those paths at compile-time. What's the
benefit of using env vars? Clearly it's the option to reconfigure the
program at runtime. If not via extra command-line options when running the
program, the user or the admin could point the program at different paths
with modifications to these configuration files.
During an update of the packages, the files would be reset to the
distribution default and break the user's/admin's customisation.
The package user will be annoyed, because /etc specifically is for
configuration files. If the packager will not mark the files as configuration
files, the admin will likely override those env vars elsewhere or
abandon using the packages.
If some files are designed only for reading values like
auto-generated
files or mentioned by you pre-defined variables or just scripts, I do
not treat them in configuration files aspect at all. And better when
they are marked special clause in comment.
As long the types calling is not standardized in a official common
specification and it is used at the discretion, as long we can talk
about it. As I wrote in one from my first mail in this thread:
"I guess that it is subject to longer discussion and not here (off-topic)."
The alternative list is packaging@ for Fedora packaging related topics.
I only would like to understand why you would not treat such files as
configuration. That's the only motivation for my replies so far. ;-)
> Which problem do you see?
I am seeing problem overwriting files if somebody hastily use %config on
script instead %config(noreplace) only because rpmlint returns warning
on package. Then it can result unexpected overwriting this file during
update the package.
How would that be different from not marking the same file %config?
If not marking the files below /etc as %config, any update would overwrite
them.
Marking them as %config signals RPM to handle the update more gracefully.
And %config(noreplace) is not guaranteed to be the better choice anyway.
Who guarantees that the updated software still works flawlessly with old
config files and new config files created as .rpmnew? Testing for all such
changes is not a trivial task.
If this overrwrite action will cause that for example offline blog
application nothing big is happening. If it will cause move offline
large 24/7 service, it can result troubles.
As above, not marking them %config bears exactly the same risk. Plus,
you lose the modifications because no backup files are created.
Btw, rpmlint does not override Fedora's packaging guidelines:
https://fedoraproject.org/wiki/Packaging:Guidelines#Configuration_files
1:22 p.m.
Am 03.08.2015 um 20:15 schrieb Michael Schwendt:
And %config(noreplace) is not guaranteed to be the better choice
anyway.
Who guarantees that the updated software still works flawlessly with old
config files and new config files created as .rpmnew? Testing for all such
changes is not a trivial task
well, the point is: you can never know if a future version will work
with the old configs, *but*
* as long the config fiel is untouched it will be overwritten
and in sync with the package due updates
* you have at least the .rpmnew file with the current defaults
so %config(noreplace) is not only he better choice, it's the only one
except ship no config at all but only a config.readme and force the
admin to copy that to the right location (in case of network aware
services i would honestly prefer thex won't start at all without at
least one look at the config from the user)
1:38 p.m.
On Mon, 3 Aug 2015 20:22:43 +0200, Reindl Harald wrote:
Am 03.08.2015 um 20:15 schrieb Michael Schwendt:
> And %config(noreplace) is not guaranteed to be the better choice anyway.
> Who guarantees that the updated software still works flawlessly with old
> config files and new config files created as .rpmnew? Testing for all such
> changes is not a trivial task
well, the point is: you can never know if a future version will work
with the old configs, *but*
* as long the config fiel is untouched it will be overwritten
and in sync with the package due updates
Same when marking as %config. Same for all ordinary files.
* you have at least the .rpmnew file with the current defaults
And the not replaced config file may not survive a reboot or a restart
of the service already due to incompatibilities (as the worst case
scenario)
so %config(noreplace) is not only he better choice, it's the only
one
except ship no config at all but only a config.readme and force the
admin to copy that to the right location (in case of network aware
services i would honestly prefer thex won't start at all without at
least one look at the config from the user)
The thread was about rpmlint warning about files in /etc not being
marked as %config:
W: non-conffile-in-etc /etc/profile.d/ossim.sh
Whether to mark them %config(noreplace) instead (to follow guidelines)
is another question.
1:48 p.m.
Am 03.08.2015 um 20:38 schrieb Michael Schwendt:
On Mon, 3 Aug 2015 20:22:43 +0200, Reindl Harald wrote:
> Am 03.08.2015 um 20:15 schrieb Michael Schwendt:
>> And %config(noreplace) is not guaranteed to be the better choice anyway.
>> Who guarantees that the updated software still works flawlessly with old
>> config files and new config files created as .rpmnew? Testing for all such
>> changes is not a trivial task
>
> well, the point is: you can never know if a future version will work
> with the old configs, *but*
>
> * as long the config fiel is untouched it will be overwritten
> and in sync with the package due updates
Same when marking as %config. Same for all ordinary files.
yes, but not relevant
> * you have at least the .rpmnew file with the current defaults
And the not replaced config file may not survive a reboot or a restart
of the service already due to incompatibilities (as the worst case
scenario)
> so %config(noreplace) is not only he better choice, it's the only one
> except ship no config at all but only a config.readme and force the
> admin to copy that to the right location (in case of network aware
> services i would honestly prefer thex won't start at all without at
> least one look at the config from the user)
The thread was about rpmlint warning about files in /etc not being
marked as %config:
W: non-conffile-in-etc /etc/profile.d/ossim.sh
the question is simply answered:
as sysadmin i expect *anything* below /etc as configuration intended to
be changed local and not overwritten by regular package updates
anything which is not intended to for local changes belongs to /usr
Whether to mark them %config(noreplace) instead (to follow
guidelines)
is another question
yes
2:07 p.m.
On Mon, 3 Aug 2015 20:48:53 +0200, Reindl Harald wrote:
>> * as long the config fiel is untouched it will be
overwritten
>> and in sync with the package due updates
>
> Same when marking as %config. Same for all ordinary files.
yes, but not relevant
Really? Ordinary files in /etc don't meet your expectations (see below).
They could be overwritten any time during an upgrade. Just like files
marked as %config.
Hell could break lose, if /etc/init.d/functions were marked as
%config(noreplace) and an update would only create an .rpmnew copy of the
new file. Marking files as %config(noreplace) is a trade-off. Whether to
mark a file as such is to be decided on a case-by-case basis.
as sysadmin i expect *anything* below /etc as configuration intended
to
be changed local and not overwritten by regular package updates
anything which is not intended to for local changes belongs to /usr
Sure. That may be the future. However, not everything in /etc is marked as
a configuration file yet. Simply claiming that files in /etc/profile.d/
are not configuration files to begin complicates matters too much.
3:16 p.m.
Hello Michael,
On 03.08.2015 20:15, Michael Schwendt wrote:
On Mon, 3 Aug 2015 19:02:26 +0200, Marcin Haba wrote:
> The only one message that I am trying to say in this point is:
> configuration files for me should be designed to configure/modify by
> administrator or directly by application.
A moot point, too.
It is my opinion, so it can seem to be a moot point :-)
First of all, if not installing prebuilt RPM packages, usually
it's the
admin who compiles and installs the software from sources. That involves a
first configuration step already. The admin makes choices where to install
(e.g. /usr vs. /usr/local), which features to enable, and possibly
influences other configuration defaults, too. After installation, the
admin would edit available config file as necessary.
Yes, true. It is normal administrator matter: use binary packages or
compile something self.
When installing from a distributor's RPM package collection, some
of those
steps are handled by the package maintainer. Other steps are postponed.
Again, the admin likely needs to review the prebuilt config files and
apply modifications.
Yes, it is also normal. I am not sure why are you writing about it. If
it is to text about configuration files modification by administrator or
application I this sentence I did not mean neither compilation self nor
binary packages way, but just general using configuration files
independent on installation method.
Very simple examples:
- Modification by administrator a config file:
# vi /etc/httpd/conf.d/my_favourite_website.conf
[save config after modification]
- Modification by application:
# hostname home.lan
Back to ossim-data:
if [ -z "$OSSIM_INSTALL_PREFIX" ]; then
export OSSIM_INSTALL_PREFIX=/usr
fi
if [ -z "$OSSIM_PREFS_FILE" ]; then
export OSSIM_PREFS_FILE=$OSSIM_INSTALL_PREFIX/share/ossim/ossim_preferences
fi
The program could simply hardcode those paths at compile-time. What's the
benefit of using env vars? Clearly it's the option to reconfigure the
program at runtime. If not via extra command-line options when running the
program, the user or the admin could point the program at different paths
with modifications to these configuration files.
During an update of the packages, the files would be reset to the
distribution default and break the user's/admin's customisation.
That is not good.
The package user will be annoyed, because /etc specifically is for
configuration files. If the packager will not mark the files as configuration
files, the admin will likely override those env vars elsewhere or
abandon using the packages.
I would be annoyed either.
> If some files are designed only for reading values like
auto-generated
> files or mentioned by you pre-defined variables or just scripts, I do
> not treat them in configuration files aspect at all. And better when
> they are marked special clause in comment.
>
> As long the types calling is not standardized in a official common
> specification and it is used at the discretion, as long we can talk
> about it. As I wrote in one from my first mail in this thread:
>
> "I guess that it is subject to longer discussion and not here
(off-topic)."
The alternative list is packaging@ for Fedora packaging related topics.
I only would like to understand why you would not treat such files as
configuration. That's the only motivation for my replies so far. ;-)
That is nice :-)
The reason is simple: from my point of view "configuration files" phrase
does not refer its 'configuration' word to action "configure something
by my content" but "configure something by editing my content". The same
way README files do not say "read my name", but "read my
content"...etc. :-)
I am sorry if my explanation is unclear. My English is still on low
level and sometimes I am not able to explain something. Specially this
type of "word game".
>> Which problem do you see?
>
> I am seeing problem overwriting files if somebody hastily use %config on
> script instead %config(noreplace) only because rpmlint returns warning
> on package. Then it can result unexpected overwriting this file during
> update the package.
How would that be different from not marking the same file %config?
I do not claim that not using %config is better solution. Also from this
reason I am here in this thread, because my main question was what can I
do with the rpmlint warning about profile.d script definition in Spec.
Up till know I learned that %config is more suitable for config.d scripts.
If not marking the files below /etc as %config, any update would
overwrite
them.
Marking them as %config signals RPM to handle the update more gracefully.
Yes, true. It will handle the update more gracefully, however it does
not protect from overwrite a file.
And %config(noreplace) is not guaranteed to be the better choice
anyway.
Who guarantees that the updated software still works flawlessly with old
config files and new config files created as .rpmnew? Testing for all such
changes is not a trivial task.
> If this overrwrite action will cause that for example offline blog
> application nothing big is happening. If it will cause move offline
> large 24/7 service, it can result troubles.
As above, not marking them %config bears exactly the same risk. Plus,
you lose the modifications because no backup files are created.
So, maybe better for profile.d to use %config(noreplace)?
Btw, rpmlint does not override Fedora's packaging guidelines:
https://fedoraproject.org/wiki/Packaging:Guidelines#Configuration_files
Not override, but good when rpmlint follows on packaging guidelines as
much as possible and reasonable.
Best regards.
Marcin Haba
12:38 p.m.
On Mon, 3 Aug 2015 22:16:39 +0200, Marcin Haba wrote:
> If not marking the files below /etc as %config, any update would
overwrite
> them.
>
> Marking them as %config signals RPM to handle the update more gracefully.
Yes, true. It will handle the update more gracefully, however it does
not protect from overwrite a file.
That's why the '(noreplace)' bit exists for the %config attribute.
So, maybe better for profile.d to use %config(noreplace)?
Either %config or %config(noreplace) can cause problems during update.
Neither one is completely safe with regard to breaking a program at
runtime. It can be necessary to switch from %config(noreplace) to %config,
or vice versa, in updates.
For example, if a config file changed from INI-style to XML, it would
be a major problem if not replacing it during an update.
Same for profile.d scripts. If those scripts in an update do much more
than the older and modified installed files, the update may not work
anymore when not replacing the old scripts.
Let's not go in circles. Marking files below /etc as configuration files
can be a good thing, but is not without risk in all cases.
> Btw, rpmlint does not override Fedora's packaging
guidelines:
> https://fedoraproject.org/wiki/Packaging:Guidelines#Configuration_files
Not override, but good when rpmlint follows on packaging guidelines as
much as possible and reasonable.
You could open a RFE in rpmlint upstream tracker.
Or try to get Fedora's rpmlint to point at the packaging guidelines
section instead of mentioning %config directly.
11:51 p.m.
On 04.08.2015 19:38, Michael Schwendt wrote:
On Mon, 3 Aug 2015 22:16:39 +0200, Marcin Haba wrote:
>> Btw, rpmlint does not override Fedora's packaging guidelines:
>> https://fedoraproject.org/wiki/Packaging:Guidelines#Configuration_files
>
> Not override, but good when rpmlint follows on packaging guidelines as
> much as possible and reasonable.
You could open a RFE in rpmlint upstream tracker.
Or try to get Fedora's rpmlint to point at the packaging guidelines
section instead of mentioning %config directly.
Thanks for the tip.
Your idea seems OK, however I am not sure if I really want go in this
direction.
Best regards.
Marcin Haba
5:37 a.m.
On Tue, Aug 4, 2015, at 01:38 PM, Michael Schwendt wrote:
Either %config or %config(noreplace) can cause problems during update.
Neither one is completely safe with regard to breaking a program at
runtime. It can be necessary to switch from %config(noreplace) to %config,
or vice versa, in updates.
FWIW rpm-ostree (really ostree) consistently uses the equivalent of
%config(noreplace) always for everything in /etc, regardless of what the
input RPM says.
I think global predictability and consistency here is superior to
per-package choice.
6:23 a.m.
On Wed, 05 Aug 2015 06:37:41 -0400, Colin Walters wrote:
On Tue, Aug 4, 2015, at 01:38 PM, Michael Schwendt wrote:
>
> Either %config or %config(noreplace) can cause problems during update.
> Neither one is completely safe with regard to breaking a program at
> runtime. It can be necessary to switch from %config(noreplace) to %config,
> or vice versa, in updates.
FWIW rpm-ostree (really ostree) consistently uses the equivalent of
%config(noreplace) always for everything in /etc, regardless of what the
input RPM says.
I think global predictability and consistency here is superior to
per-package choice.
MUST: Admin must painstakingly review and handle all .rpmnew/.rpmsave files,
which are created when installing an update.
Aiming for consistency, I agree with that. Predictability? Nah. Both %config
and %config(noreplace) bear risks.
4:57 p.m.
On 2 August 2015 at 15:29, Marcin Haba <marcin.haba(a)bacula.pl> wrote:
My image of configuration files is that they are files for
read/write
purpose by design, because they enables _configure_ something
(application, service, single program, script...whatever). If they are
dedicated only for reading then from my point of view they lose
"configuration" meaning (something like WORM storage ;-) ).
This is probably an argument for having shell configuration fragments
packaged under /usr/lib/bash/profile.d rather than /etc/profile.d.
4:58 p.m.
On 2 August 2015 at 22:57, Jonathan Underwood
<jonathan.underwood(a)gmail.com> wrote:
On 2 August 2015 at 15:29, Marcin Haba <marcin.haba(a)bacula.pl>
wrote:
> My image of configuration files is that they are files for read/write
> purpose by design, because they enables _configure_ something
> (application, service, single program, script...whatever). If they are
> dedicated only for reading then from my point of view they lose
> "configuration" meaning (something like WORM storage ;-) ).
>
This is probably an argument for having shell configuration fragments
packaged under /usr/lib/bash/profile.d rather than /etc/profile.d.
.. or /usr/share/bash/profile.d, perhaps.
2:13 a.m.
On 02.08.2015 23:58, Jonathan Underwood wrote:
On 2 August 2015 at 22:57, Jonathan Underwood
<jonathan.underwood(a)gmail.com> wrote:
> On 2 August 2015 at 15:29, Marcin Haba <marcin.haba(a)bacula.pl> wrote:
>> My image of configuration files is that they are files for read/write
>> purpose by design, because they enables _configure_ something
>> (application, service, single program, script...whatever). If they are
>> dedicated only for reading then from my point of view they lose
>> "configuration" meaning (something like WORM storage ;-) ).
>>
>
> This is probably an argument for having shell configuration fragments
> packaged under /usr/lib/bash/profile.d rather than /etc/profile.d.
.. or /usr/share/bash/profile.d, perhaps.
Hello Jonathan,
That is also good idea, I think.
Thanks.
Best regards.
Marcin Haba
3209
days inactive
3212
days old
23 comments
6 participants
participants (6)
-
Colin Walters -
Jonathan Underwood -
Marcin Haba -
Michael Schwendt -
Ralf Corsepius -
Reindl Harald