Project

General

Profile

Actions

Bug #8418

open

Configuration files do not get updated when user has modified the stock ones

Added by Janos Mattyasovszky almost 5 years ago. Updated over 3 years ago.

Status:
New
Priority:
N/A
Assignee:
-
Category:
System integration
Target version:
-
Severity:
Minor - inconvenience | misleading | easy workaround
User visibility:
Operational - other Techniques | Technique editor | Rudder settings
Effort required:
Priority:
27

Description

Edit: the logrotate problem is linked to a configuration file not correctly updated during upgrade. That's why the title does not match the description.

Please have some kind of log-rotation enabled for non-compliant-reports.log, otherwise it might get veeery big:

ruddersrv:/var/log/rudder/compliance # ll -h non-compliant-reports.log
-rw-r----- 1 root root 7.4G May 30 11:56 non-compliant-reports.log

Our for example currently holds the logs since [2015-10-16 04:39:20+0200].


Related issues

Related to Rudder - Bug #6381: File /var/log/rudder/{compliance/non-compliant-reports.log, core/rudder-webapp.log} are not correctly rotatedReleasedNicolas CHARLES2015-03-11Actions
Related to Rudder - Bug #8172: Upgrade from 2.11 to 3.1 on sles does not preserve the rudder-jetty java parametersReleasedBenoît PECCATTE2016-07-07Actions
Related to Rudder - Bug #8643: Rudder apache config should be replaced on updateNewAlexis MOUSSETActions
Actions #1

Updated by Nicolas CHARLES almost 5 years ago

  • Category set to System integration
  • Status changed from New to Discussion
  • Assignee changed from Nicolas CHARLES to Janos Mattyasovszky

Hi Janos,

This file is already rotated, over 365 days, and compressed (configuration is in /opt/rudder/etc/logback.xml)
You should have the following entry in /opt/rudder/etc/logback.xml

    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
      <fileNamePattern>${REPORT_DIR}/non-compliant-reports-%d{yyyy-MM-dd}.log.gz</fileNamePattern>
      <maxHistory>365</maxHistory>
    </rollingPolicy>

Could you confirm you do have this entry - or not ?

Actions #2

Updated by Nicolas CHARLES almost 5 years ago

  • Related to Bug #6381: File /var/log/rudder/{compliance/non-compliant-reports.log, core/rudder-webapp.log} are not correctly rotated added
Actions #3

Updated by Janos Mattyasovszky almost 5 years ago

Hi

No, it is not in there (having rudder-webapp-3.0.13 on SLES11):

rudderserver:/var/rudder/configuration-repository # grep on-compliant-reports -C3 /opt/rudder/etc/logback.xml
    A file log appender for exploitation logs about failure reports.
  -->
    <appender name="REPORTLOG" class="ch.qos.logback.core.FileAppender">
    <file>${REPORT_DIR}/non-compliant-reports.log</file>
    <append>true</append>
        <encoder>
      <pattern>%msg%n</pattern>
--

   <!-- Here come non compliant reports logger -->

   <logger name="non-compliant-reports" level="info" additivity="false">
     <appender-ref ref="REPORTLOG" />
   </logger>

Also having a 1yr-rotation is not well suited for bigger installations, it would make more sense to rotate it depending on the size, not on the age...

Actions #4

Updated by Nicolas CHARLES almost 5 years ago

It definitively should be there - did you refuse the update of this file during an upgrade ?

As for the rotation, it is rotated every day, gzipped, and each gzip are keep for one year.
Obviously, you can change it in the log config file

Actions #5

Updated by Janos Mattyasovszky almost 5 years ago

Nicolas CHARLES wrote:

It definitively should be there - did you refuse the update of this file during an upgrade ?

Where do I get the chance to refuse something like this? :-)

NB: Our updates are not user-interactive.

Actions #6

Updated by Janos Mattyasovszky almost 5 years ago

This is related to the fact, that the spec file is:

%config(noreplace) %{rudderdir}/etc/logback.xml

Causing the logback.xml not to be modified if there is any modification done on the file.

Actions #7

Updated by Nicolas CHARLES almost 5 years ago

  • Status changed from Discussion to New
  • Assignee changed from Janos Mattyasovszky to Benoît PECCATTE

Janos Mattyasovszky wrote:

Nicolas CHARLES wrote:

It definitively should be there - did you refuse the update of this file during an upgrade ?

Where do I get the chance to refuse something like this? :-)

NB: Our updates are not user-interactive.

Ha - on .deb systems, question is asked, and default is to take maintainer version.
So this sounds like a packaging issue, redirecting it to Benoît for proper investigation on why the file is not updated at update

Actions #8

Updated by Benoît PECCATTE almost 5 years ago

  • Assignee changed from Benoît PECCATTE to Nicolas CHARLES

On RPM systems, all our (pseudo-)configuration files are %config(noreplace) which mean we don't replace them, but a .rpmnew file is created instead.

Janos Matya you should have a logback.xml.rpmnew that contains the expected configuration file

@Nicolas we should talk about this with everyone on a file by file basis, since either we have a %config and we always override user configuration or a %config(noreplace) and we never override it

Actions #9

Updated by Janos Mattyasovszky almost 5 years ago

Yes, I missed the .rpmnew file, silly me.

Now I have to modify my rudder-customization script to always look for .rpmnew files, move them to overwrite the original and apply my modifications on the updated ones... yaay.

Actions #10

Updated by Benoît PECCATTE almost 5 years ago

And do you think we should change this behaviour for some files that are seldom modified by the user ? like logback or the apache configuration ?

Actions #11

Updated by Janos Mattyasovszky almost 5 years ago

  • Subject changed from No logrotate for non-compliant-reports.log to Configuration files do not get updated when user has modified the stock ones
  • Assignee changed from Nicolas CHARLES to Janos Mattyasovszky

Changed the topic since it is there in the .rpmnew file, so the actual question is if this is a desired outcome or not.

Actions #12

Updated by Janos Mattyasovszky almost 5 years ago

  • Assignee changed from Janos Mattyasovszky to Nicolas CHARLES
Actions #13

Updated by François ARMAND almost 5 years ago

  • Related to Bug #8172: Upgrade from 2.11 to 3.1 on sles does not preserve the rudder-jetty java parameters added
Actions #14

Updated by François ARMAND almost 5 years ago

Adding the link to #8172 because it seems to be in the same topic and a generic solution must work for both.

Actions #15

Updated by Nicolas CHARLES over 4 years ago

  • Assignee changed from Nicolas CHARLES to Benoît PECCATTE

Changing the assignee to a person who knows packaging, and understand the impact of the possible changes

Actions #16

Updated by Benoît PECCATTE about 4 years ago

  • Severity set to Minor - inconvenience | misleading | easy workaround
  • User visibility set to Operational - other Techniques | Technique editor | Rudder settings
Actions #17

Updated by François ARMAND about 4 years ago

  • Description updated (diff)
Actions #18

Updated by Benoît PECCATTE about 4 years ago

  • Priority set to 14
Actions #19

Updated by Jonathan CLARKE almost 4 years ago

  • Assignee deleted (Benoît PECCATTE)
Actions #20

Updated by Benoît PECCATTE almost 4 years ago

  • Priority changed from 14 to 27
Actions #21

Updated by François ARMAND over 1 year ago

  • Related to Bug #8643: Rudder apache config should be replaced on update added
Actions

Also available in: Atom PDF