March 2017 - logback-user - mailman3.qos.ch

Logback => TLS/SSL => Syslog ?
by Otis Gospodnetić 21 Feb '19

21 Feb '19

Hi, Does Logback support sending logs to Syslog servers via TLS/SSL? I have a feeling Logback doesn't have a SyslogAppender that can send data using TLS. I say that because I don't see a mention of "syslog" on http://logback.qos.ch/manual/usingSSL.html and I see http://jira.qos.ch/browse/LOGBACK-890 that mentions TLSSyslogAppender, but it looks like this never ended up in Logback. I've only found it committed here: https://github.com/balabit/logback/commit/e0d89de2536e0925a6c816a50793f6a74… Could anyone please clarify? Thanks, Otis -- Monitoring * Alerting * Anomaly Detection * Centralized Log Management Solr & Elasticsearch Support * http://sematext.com/

2 1

Timeout may frequently occurred on logback.qos.ch [IPv6]
by Takuma Tsutsumi 13 Apr '17

13 Apr '17

Hi, If using a user-agent that prefer IPv6 such as the Squid proxy, a timeout may frequently occur on logback.qos.ch. It seems to me that the IPv6 site does not exist. References: - http://ready.chair6.net/?url=https://logback.qos.ch - http://ipv6-test.com/validate.php In addition, it seems that AAAA records may not be returned depending on DNS query timing. ``` $ date; dig +noall +answer @8.8.8.8 logback.qos.ch aaaa Thu Mar 30 22:34:03 DST 2017 logback.qos.ch. 279 IN CNAME yvo.qos.ch. yvo.qos.ch. 279 IN AAAA 2a02:121e:969:1:201:c0ff: fe1c:5f7c $ date; dig +noall +answer @8.8.8.8 logback.qos.ch aaaa Thu Mar 30 22:34:05 DST 2017 logback.qos.ch. 299 IN CNAME te.qos.ch. ``` Would you please investigate this? Regards, Takuma Tsutsumi

2 6

where to place logback.xml?
by Rolf Schumacher 31 Mar '17

31 Mar '17

Just started with logback, I made to get work for me. I am used to distribute my Java software as one jar file and a folder "lib/" holding all jars the executable jar depends on. The executable jar specifies the classpath to lib/*. Currently the logback configuration file logback.xml is also covered in the executable jar and is recognized by the application. In case of an issue report from a user, I would like to give the user some instructions to switch to DEBUG loglevel and send me the logging output. What would be the best way to do so? Please note that the classpath is determined by the executable jar. I tried to find a way to put a logback-test.xml on the classpath without rebuilding the application. Unfortunately without success. -- Viele Grüße, Best Regards Rolf Schumacher p.s.: Did I understood it right that I cannot change the loglevel - e.g. to DEBUG - programmatically? If so I would just tell the user to supply a commandline parameter specifying the loglevel to run with.

3 5

annoying STDOUT message whenever a worker thread is started by the AsyncAppender
by Nikos Loutas 31 Mar '17

31 Mar '17

Hello, in the latest logback version 1.2.2, the annoying (and useless from the user perspective) message "Worker started" is printed on standard output every time a new worker thread is started by the "ch.qos.logback.classic.AsyncAppender" See: https://logback.qos.ch/xref/ch/qos/logback/core/AsyncAppenderBase.html#L283 Would you please remove it and thereby boost the user satisfaction significantly. Kind regards, Nikos Loutas Senior Software Engineer m: ++49 15732712170 ************************************************************************************************************ Privileged/Confidential Information may be contained in this message. If you are not the recipient addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and notify us immediately. If you or your employer do not consent to internet email messages of this kind, please advise us immediately. Nothing in this e-mail message amounts to a contractual or legal commitment unless it is confirmed by an appropriately signed hard copy.

2 2

MDCInsertingServletFilter and req.remoteHost
by Murray, Thomas - 3 30 Mar '17

30 Mar '17

Hi, I have configured my application with the MDCInsertingServletFilter and added the %X{req.remoteHost} to my logback.xml pattern attribute. The log is showing the fully qualified name of the client that sent the request. However, I would like to log the IP and not the fully qualified host name. The documentation for getRemoteHost() states "If the engine cannot or chooses not to resolve the hostname (to improve performance), this method returns the dotted-string form of the IP address". How do I configure the engine to not resolve fully qualified host name? Thanks in advance for your assistance, Tom. ---------------------------------------------------------------------- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.

2 1

Fwd: Use different Slf4jBinder then the one in logback-classic
by Izek Greenfield 30 Mar '17

30 Mar '17

I need to customize the slf4jBinder hence it part of the logback-classic jar and I need the other class from that jar it is a problem. How can I do that? Thanks Izek

3 2

Please clarify fixing commits for CVE-2017-5929
by Markus Koschany 29 Mar '17

29 Mar '17

Hello, I am currently investigating CVE-2017-5829. According to [1] release 1.2.0 resolved the issue and [2] contains an overview about related commits for this version. In Debian we would like to fix this security vulnerability by backporting the necessary changes only. What are the fixing commits for CVE-2017-5929? To me it looks like "harden serialization", "correct package name", "Harden reading from ObjectInputStream" and "fix test failures" are relevant but it might also be possible that only "harden serialization" is sufficient. Could you clarify this information please? Please also consider to update your news page with this information which would simplify the job for other security researchers and Linux distributions to quickly address this issue. Regards, Markus Koschany [1] https://logback.qos.ch/news.html [2] https://github.com/qos-ch/logback/commits/v_1.2.0

1 0

root level appender config not working
by Thomas Grainger 27 Mar '17

27 Mar '17

I have a config file: <configuration> <conversionRule conversionWord="coloredLevel" converterClass="play.api.Logger$ColoredLevel" /> <contextListener class="com.procensus.backend.logging.LoggerStartupListener"/> <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <file>${application.home}/logs/application.log</file> <encoder> <pattern>%date - [%level] - from %logger in %thread %n%message%n%xException%n</pattern> </encoder> </appender> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%coloredLevel %logger{15} - %message%n%xException{5}</pattern> </encoder> </appender> <appender name="CLOUDWATCH_SYNC" class="ca.pjer.logback.AwsLogsAppender"> <logRegion>eu-west-1</logRegion> <logGroupName>procensus/backend</logGroupName> <logStreamName>${EC2_METADATA_IP_ADDRESS}</logStreamName> <layout class="ch.qos.logback.contrib.json.classic.JsonLayout"> <jsonFormatter class="ch.qos.logback.contrib.jackson.JacksonJsonFormatter"> <prettyPrint>false</prettyPrint> </jsonFormatter> </layout> </appender> <appender name="CLOUDWATCH" class="ch.qos.logback.classic.AsyncAppender"> <appender-ref ref="CLOUDWATCH_SYNC"/> </appender> <appender name="SENTRY" class="com.getsentry.raven.logback.SentryAppender"> <dsn>https://redacted:redacted@sentry.io/redacted</dsn> </appender> <logger name="play" level="INFO" /> <logger name="application" level="DEBUG" />  <logger name="com.avaje.ebean.config.PropertyMapLoader" level="OFF" /> <logger name="com.avaje.ebeaninternal.server.core.XmlConfigLoader" level="OFF" /> <logger name="com.avaje.ebeaninternal.server.lib.BackgroundThread" level="OFF" /> <logger name="com.gargoylesoftware.htmlunit.javascript" level="OFF" /> <logger name="com.amazonaws.request" level="OFF" /> <root level="ERROR"> <appender-ref ref="STDOUT" /> <appender-ref ref="FILE" /> </root> <root level="INFO"> <appender-ref ref="CLOUDWATCH" /> </root> <root level="WARN"> <appender-ref ref="SENTRY" /> </root> </configuration> However, even though I have root level="WARN" for Sentry, I get all logging events (eg INFO level) When I configure a filter, my process doesn't even boot, with no error message at all: <configuration> <conversionRule conversionWord="coloredLevel" converterClass="play.api.Logger$ColoredLevel" /> <contextListener class="com.procensus.backend.logging.LoggerStartupListener"/> <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <file>${application.home}/logs/application.log</file> <encoder> <pattern>%date - [%level] - from %logger in %thread %n%message%n%xException%n</pattern> </encoder> </appender> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%coloredLevel %logger{15} - %message%n%xException{5}</pattern> </encoder> </appender> <appender name="CLOUDWATCH_SYNC" class="ca.pjer.logback.AwsLogsAppender"> <logRegion>eu-west-1</logRegion> <logGroupName>procensus/backend</logGroupName> <logStreamName>${EC2_METADATA_IP_ADDRESS}</logStreamName> <layout class="ch.qos.logback.contrib.json.classic.JsonLayout"> <jsonFormatter class="ch.qos.logback.contrib.jackson.JacksonJsonFormatter"> <prettyPrint>false</prettyPrint> </jsonFormatter> </layout> </appender> <appender name="CLOUDWATCH" class="ch.qos.logback.classic.AsyncAppender"> <appender-ref ref="CLOUDWATCH_SYNC"/> </appender> <appender name="SENTRY" class="com.getsentry.raven.logback.SentryAppender"> <dsn>https://redacted:redacted@sentry.io/redacted</dsn> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>WARN</level> </filter> </appender> <logger name="play" level="INFO" /> <logger name="application" level="DEBUG" />  <logger name="com.avaje.ebean.config.PropertyMapLoader" level="OFF" /> <logger name="com.avaje.ebeaninternal.server.core.XmlConfigLoader" level="OFF" /> <logger name="com.avaje.ebeaninternal.server.lib.BackgroundThread" level="OFF" /> <logger name="com.gargoylesoftware.htmlunit.javascript" level="OFF" /> <logger name="com.amazonaws.request" level="OFF" /> <root level="ERROR"> <appender-ref ref="STDOUT" /> <appender-ref ref="FILE" /> </root> <root level="INFO"> <appender-ref ref="CLOUDWATCH" /> </root> <root level="WARN"> <appender-ref ref="SENTRY" /> </root> </configuration> Thomas Grainger

2 4

Request
by Muli vinod 25 Mar '17

25 Mar '17

Hi Can u send me how to configure logback.xml file in a project to tail the logs -- Regards Vinod Kumar Reddy

1 0

multiple web apps tomcat rolling file appender
by Aleksander Kamenik 24 Mar '17

24 Mar '17

Hi! I'm having trouble with several web apps logging to a single rolling file appender in one JVM (Tomcat 8.0) without prudent mode. I've tried several setups with logback.xml configurations however no matter what I do I get apps overwriting already rolled over files. For testing I've set rollover to each minute and getting apps to overwrite already rolled over files is trivial. Reading the manual though I understand this should work just fine provided all the apps are using the same JVM and therefore the same appender. This does not seem to be the case though. During startup I see each app log "AppenderAction - Naming appender as [COMMON]" for example. I presume this means every app creates their own appender instead of reusing the existing one. The slf4j and logback jar files are located in tomcat's lib directory as is the logback.xml file. I've tried context based log separation too with shared logback.xml as well as per app logback.xml but the result for shared appender is always the same. I have a feeling I'm missing something obvious and important here. Regards, -- Aleksander Kamenik

2 2