I have an issue on the script, basically I don't use any log4net or whatever and im not planning, but some resource which i access during my script i suppose has some references to this log4net, so i get this messages:
log4net:ERROR XmlConfigurator: Failed to find configuration section
'log4net' in the application's .config file. Check your .config file
for the and elements. The configuration
section should look like:
I don't really care about this, as this is also not a real error, i would prefere to somehow hide this messages from the propmpt window, is this possible?
How can I ignore this information, without too much hassle?
This message comes from the log4net internal debugging, and means that not log4net configuration information is found in the config file. What I find strange is that this kind of info is usually opt-in:
There are 2 different ways to enable internal debugging in log4net.
These are listed below. The preferred method is to specify the
log4net.Internal.Debug option in the application's config file.
Internal debugging can also be enabled by setting a value in the application's configuration file (not the log4net configuration file,
unless the log4net config data is embedded in the application's config
file). The log4net.Internal.Debug application setting must be set to
the value true. For example:
This setting is read immediately on startup an will cause all internal debugging messages to be emitted.
To enable log4net's internal debug programmatically you need to set the log4net.Util.LogLog.InternalDebugging property to true.
Obviously the sooner this is set the more debug will be produced.
So either the code of one component uses the code approach, or there is a configuration value set to true. Your options are:
look through the configuration files for a reference to the log4net.Internal.Debug config key; if you find one set to true, set it to false.
add an empty log4net section in the configuration file to satisfy the configurator and prevent it from complaining
if the internal debugging is set through code, you may be able to redirect console out and the trace appenders (see link for where the internal debugging writes to) but this really depends on your environment so you'll need to dig a bit more to find how to catch all outputs. Not really simple
Related
ESAPI: WARNING: System property org.owasp.esapi.opsteam is not set
ESAPI: WARNING: System property org.owasp.esapi.devteam is not set
ESAPI: Attempting to load ESAPI.properties via file I/O.
ESAPI: Attempting to load ESAPI.properties as resource file via file I/O.
ESAPI: Not found in org.owasp.esapi.resources directory or file not readable:
ESAPI.properties
ESAPI: Loading validation.properties via file I/O failed.
ESAPI: Attempting to load validation.properties via the classpath.
ESAPI: validation.properties could not be loaded by any means. fail.. Caught java.lang.IllegalArgumentException; exception message was: java.lang.IllegalArgumentException: Failed to load ESAPI.properties as a classloader resource.
ESAPI: SecurityConfiguration for ESAPI.printProperties not found in ESAPI.properties. Using default: false
ESAPI: SecurityConfiguration for Encoder.DefaultCodecList not found in ESAPI.properties. Using default: [org.owasp.esapi.codecs.HTMLEntityCodec, org.owasp.esapi.codecs.PercentCodec, org.owasp.esapi.codecs.JavaScriptCodec]
org.owasp.esapi.errors.ConfigurationException: java.lang.reflect.InvocationTargetException Encoder class (org.owasp.esapi.reference.DefaultEncoder) CTOR threw exception
You can safely ignore those warning messages. It's a red herring. That's referring to a more secure configuration option that you can use (although most people don't) when deploying an application that uses ESAPI.
[Aside:
The idea is that it allows you to split the ESAPI.properties file into two files, one controlled by the dev team and the other controlled by the operations (ops) team. Any property found in the one controlled by the ops team overrides and identical property in the dev version.
This feature was developed in the days before DevOps became as prevalent as it is today (and long before things like HashiCorp Vault), so perhaps it doesn't make as much sense now, but the intent was to allow the devs to have there own ESAPI.properties file with properties like Encryptor.MasterKey that all the developers can safely share, but that the operations team can set a separate version for QA and production deployments. (It of course applied to other properties as well, but I think that was the properties that drove it.)
So that explains the warnings part.]
But your actual problem is that ESAPI cannot find your ESAPI.properties file anywhere. Looks at this for an explanation of how ESAPI tries to locate your configuration files:
https://www.javadoc.io/static/org.owasp.esapi/esapi/2.5.1.0/org/owasp/esapi/reference/DefaultSecurityConfiguration.html
If you are still having trouble, what I generally recommend is setting the system property 'org.owasp.esapi.resources' on the 'java' command line.
If for some reason that you don't want to do that, you will have to provide us with more details, like ALL the messages, including the complete exception stack trace.
Hope that helps.
This is more or less the same problem I had here with the log file, with a bit of more information and a different configuration
With this configuration file (in the root directory):
port: 31415
content_type: "application/json"
engines:
logger:
File:
log_level: core
file_name: "p5hitos.log"
logger: "File"
and this main program (hitos.psgi, same directory):
use v5.14;
use lib qw(lib);
use My::Hitos;
use Dancer2 appname => 'My::Hitos';
dance;
Routes are included into another file, I'm not sure it's really necessary here, but all code is here)
the program fails to read the configuration. Funny thing is, if I put the last line first, it fails to log in any way. Putting "logger" as the last line in the file it logs to the console, not to the place I configured. It's also failing to set the port, or the default content_type. The manual seems to imply there's some setting that says the configuration file we'll be using. Not totally clear what that setting would be, or how to set it, or what's actually the default configuration file extension. Any idea?
Update: I have copied config.yml to lib/My... and well, it looks like it's reading it, because runner actually has those features in the configuration, and it does says a message. It's also logging... something, and to console:
We are logging Entering hook core.error.afterWe are logging
We are logging looking for get /statusWe are logging
We are logging Entering hook core.app.before_requestWe are logging
(after setting the export DANCER_CONFIG_VERBOSE=1). Still not doing it to the configured place.
Hi I'm spinning out Pantheon's Localdev for testing and I'm getting this warning message on the logs
You have a lot of keys!
Any ideas what is causing this warning?
I think this is related to lando. This thread on Github suggests:
To disable the warning you can run lando config you will see a maxKeyWarning setting. This value can be overridden in a lando global config file, i.e. set the value that matches your number of used keys..
As documented in the SSH keys config page, the keys key is meant to be used in combination with a user-space Lando override file. This file is .gitignored and is meant to provide user-specific overrides, eg you would not put ALL the keys of ALL the users here, just yours.
The Play framework requires (by default) that you configure logging through a logback.xml file. I'd like to build my log appenders through code so I can fetch parameters at runtime (e.g. the graylog destination for the logs is fetched from the deployment environment, rather than baking it in statically through an XML file).
This sort of thing is fairly easy to achieve in Java (by overriding logging factories and the like), I wondered if the same were possible in Play.
Yes, you can configure logback programmatically, see: https://akhikhl.wordpress.com/2013/07/11/programmatic-configuration-of-slf4jlogback/
But I wouldn't recommend it. For starters it's a verbose API that isn't pleasant to work with. Beyond that, it generally nice for configuration to be declarative (even if it is in XML in this case).
For your usecase, Logback's XML does support variables which can come from System properties or Environment variables: https://logback.qos.ch/manual/configuration.html#definingProps
However, you probably want a different config across environments (no greylog locally). I think many projects do that by specifying the logback XML location as a system property at startup: https://logback.qos.ch/manual/configuration.html#configFileProperty
Alternatively, I suspect greylog has some method of watching a file to pickup your logging. That's what we do for picking up logs in Splunk in my team. We don't want to make a change to our code when someone reconfigures Splunk/Greylog.
The solution I used in the end was to use a logback contextlistener to populate the context with the parameters pulled from the environment. The listener can be added as follows to the logback.xml:
<contextListener class="LoggerStartup"/>
The LoggerStartup can then populate the context, which I achieved through AWS SSM (see the simplified code below).
class LoggerStartup extends ContextAwareBase with LoggerContextListener with LifeCycle {
override def start() = {
val context = getContext()
val graylogUrl = ... // Go get value from remote store
context.putProperty("GRAYLOG_URL", graylogUrl)
}
}
And then referenced this context variable in the logback file:
<appender name="GELF UDP APPENDER" class="me.moocar.logbackgelf.GelfUDPAppender">
<remoteHost>${GRAYLOG_URL}</remoteHost>
...
</appender>
I am using the Remote System software on Eclipse. I can successfully log in to my FTP account but when I try to view the directories, I get the following message:
Message: Operation failed due to network I/O error
'java.net.SocketException: Connection reset by peer: socket write
error'
Any ideas are welcome.
Looks like there could be some negotiation issue.
Try following solution:
I've got the same exception and in my case the problem was in a
renegotiation procecess. In fact my client closed a connection when
the server tried to change a cipher suite. After digging it appears
that in the jdk 1.6 update 22 renegotiation process is disabled by
default. If your security constraints can effort this, try to enable
the unsecure renegotiation by setting the
sun.security.ssl.allowUnsafeRenegotiation system property to true.
http://www.oracle.com/technetwork/java/javase/overview/tlsreadme2-176330.html
Setting the System Properties/Mode Configuration The various modes are
set using the corresponding system properties, which must be set
before the SunJSSE library is initialized. There are several ways to
set these properties:
From the command line:
% java -Dsun.security.ssl.allowUnsafeRenegotiation=true Main Within
the application:
java.lang.System.setProperty("sun.security.ssl.allowUnsafeRenegotiation",
true); In the Java Deployment environment (Plug-In/Web Start), there
are several ways to set the system properties. (See Java Web App and
Next Generation Web Browser Plugin for more information.)
Use the Java Control Panel to set the Runtime Environment Property on
a local/per-VM basis. This creates a local deployment.properties file.
Deployers can also distribute a enterprise-wide deployment.properties
file by using the deployment.config mechanism. (See Deployment
Configuration File and Properties.)
To set a property for a specific applet, use the HTML subtag
"java_arguments" within the tag. (See Java Arguments.)
To set the property in a specific Java Web Start application or applet
using the new Plugin2 (6u10+), use the JNLP "property" sub-element of
the "resources" element. (See Resources Element.)