How to control log file with daily rolling and max file size by log4j

log4jrollingfileappender

I would like to create log file that can be rolled at the beginning of the next day or if it's reached to specified file size and log file must be contained inside date folder.
Format of folder is YYYYMMDD (/20111103/mylogfile.log)

Is it possible to do this by Log4j without implementing custom class?

Now I am using log4j and log4j-extra,
I set FileNamePattern attribute as defined in log4j API to rolling my file everyday
and set max file size to 50 MB.

My log4j.xml is:

<appender name="MYAPPENDER" class="org.apache.log4j.rolling.RollingFileAppender">
    <param name="encoding" value="UTF-8" />
    <param name="append" value="true" />
    <rollingPolicy class="org.apache.log4j.rolling.TimeBasedRollingPolicy">
        <param name="FileNamePattern" value="${catalina.home}/logs/MY-APP/%d{yyyyMMdd}/MY-APP_%d{yyyyMMddHHmmss}.log" />
    </rollingPolicy>
    <triggeringPolicy class="org.apache.log4j.rolling.SizeBasedTriggeringPolicy">
        <param name="maxFileSize" value="50000000" />
    </triggeringPolicy>
    <layout class="org.apache.log4j.PatternLayout">
        <param name="ConversionPattern" value="[%d{dd/MM/yyyy HH\:mm\:ss}] %-5p [%c.%M(),%4L] - %m%n" />
    </layout>
</appender>

Result of above setting is that log file is not rolled at the beginning of next days but if file's size reached to 50 MB, log file will be rolled.

Please help to advise me. m(_ _)m

Best Answer

Daily works for me with xml in question only transformed into log4j.properties equivalent to roll over after 100KB (for testing purposes):

# Root logger option
log4j.rootLogger=INFO, file

# Direct log messages to a file
log4j.appender.file=org.apache.log4j.rolling.RollingFileAppender
log4j.appender.file.RollingPolicy=org.apache.log4j.rolling.TimeBasedRollingPolicy
log4j.appender.file.RollingPolicy.FileNamePattern=/path/to/logs/%d{yyyyMMdd}/myLog_%d{yyyyMMddHH}.log
log4j.appender.file.TriggeringPolicy=org.apache.log4j.rolling.SizeBasedTriggeringPolicy
log4j.appender.file.TriggeringPolicy.maxFileSize=100000
log4j.appender.file.layout=org.apache.log4j.PatternLayout
log4j.appender.file.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
log4j.appender.file.Append=true

This will create a timestamped directory (one directory per day - optional) with logs with the following format (one per hour for testing purposes - change FileNamePattern to suit your needs):

myCompanyLog_201602031030.log

myCompanyLog_201602031130.log

Related Solutions

Java – log4j configurations with daily rolling, gzip and max backup files

log4j 1.2 does not have an appender that supports all features required by you. You have to use your own implementation.

log4j2 seems to support your requirements. Please have a look at the log4j2 documentation:

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="warn" name="MyApp" packages="">
  <Appenders>
    <RollingFile name="RollingFile" fileName="logs/app.log"
       filePattern="logs/$${date:yyyy-MM}/app-%d{MM-dd-yyyy}-%i.log.gz">
      <PatternLayout>
        <Pattern>%d %p %c{1.} [%t] %m%n</Pattern>
      </PatternLayout>
      <Policies>
        <TimeBasedTriggeringPolicy />
        <SizeBasedTriggeringPolicy size="250 MB"/>
      </Policies>
      <DefaultRolloverStrategy max="20"/>
    </RollingFile>
  </Appenders>
  <Loggers>
    <Root level="error">
      <AppenderRef ref="RollingFile"/>
    </Root>
  </Loggers>
</Configuration>

Php – How to secure phpMyAdmin

The biggest threat is that an attacker could leverage a vulnerability such as; directory traversal, or using SQL Injection to call load_file() to read the plain text username/password in the configuration file and then Login using phpmyadmin or over tcp port 3306. As a pentester I have used this attack pattern to compromise a system.

Here is a great way to lock down phpmyadmin:

PhpMyAdmin lacks strong bruteforce protection, so you must use a long randomly generated password.
DO NOT ALLOW REMOTE ROOT LOGINS! Instead phpmyadmin can be configured to use "Cookie Auth" to limit what user can access the system. If you need some root privileges, create a custom account that can add/drop/create but doesn't have grant or file_priv.
Remove file_priv permissions from every account. file_priv is one of the most dangerous privileges in MySQL because it allows an attacker to read files or upload a backdoor.
Whitelist IP address who have access to the phpmyadmin interface. Here is an example .htaccess reulset:

Order deny,allow
Deny from all
allow from 199.166.210.1

Do not have a predictable file location like: http://127.0.0.1/phpmyadmin. Vulnerability scanners like Nessus/Nikto/Acunetix/w3af will scan for this.
Firewall off tcp port 3306 so that it cannot be accessed by an attacker.
Use HTTPS, otherwise data and passwords can be leaked to an attacker. If you don't want to fork out the $30 for a cert, then use a self-signed. You'll accept it once, and even if it was changed due to a MITM you'll be notified.

Best Answer

Related Solutions

Java – log4j configurations with daily rolling, gzip and max backup files

Php – How to secure phpMyAdmin

Related Topic