I've got a C/C++/Objective-C project that send asl logging messages.
The default configuration in asl.conf route all log message with level above notice to system log (see below rule), and I'd like to cancel this rule for my specific facility only.
This means, that all log messages under my facility will be routed to my log file only, and not to system.log.
here's the configuraiton where my facility is defined to com.bla.bla
asl.conf
? [<= Level notice] file system.log
my_asl.conf
? [<= Level notice] [=Facility com.bla.bla] skip / ignore
I've tried both skip and ignore, but i didn't made any change. the only thing that work is to erase the rule from asl.conf, but i don't want to change the behavior of other processes / facilities and to modify some default rules.
is there any rule i can add to ban my messages only from system.log ?
thanks
After re-reading asl.conf man page over and over again, I've found out that i can use 'claim' command to ignore asl.conf base configuration file for my specific rule
claim Messages that match the query associated with a 'claim' action are not processed by the main ASL configuration file /etc/asl.conf. While claimed messages are not pro-cessed processed cessed by /etc/asl.conf, they are not completely private. Other modules may also claim messages, and in some cases two or more modules may have claim actions that match the same messages. This action only blocks processing by /etc/asl.conf.
The `claim' action may be followed by the keyword 'only'. In this case, only those messages that match the 'claim only' query will be processed by subsequent
rules in the module.
I followed the description of the tag 'claim' and added the following configuration to my config file :
? [= com.bla.bla] file /var/log/my-log
? [= com.bla.bla] claim
Related
I added some custom error messages to the APIM according to documentation https://apim.docs.wso2.com/en/4.0.0/troubleshooting/error-handling/ - I created custom file in
<API-M_HOME>/repository/deployment/server/synapse-configs/default/sequences and added references to that file in some of the default files in that directory (so that it is called to transform error message).
Everything seemed to be working just fine until the restart of WSO2 - after that, changes made to default files were present, but the custom file was removed, so that custom error message handling didn't work.
I resolved this by adding non-removable attribute (chattr +i) to the file, but I wonder is there other, more elegant way to prevent the file from being deleted every time restart is being made?
There are 'template' files placed in: <API-M_HOME>/repository/resources/apim-synapse-config. Maybe, those files are overriding files in the ../synapse-configs/default/ location.
Second thing, which came on my mind, is using specific High Avability scenario. Where artifacts are shared files in system as the content synchronization mechanism, it can override local changes.
At the startup gateway removes these files. You can add the following configuration to the deployment.toml and place the file in the sequence directory.
Sample Config:
[apim.sync_runtime_artifacts.gateway.skip_list]
apis = ["api1.xml","api2.xml"]
endpoints = ["endpoint1.xml"]
sequences = ["post_with_nobody.xml"]
local-entries = ["file.xml"]
For your case:
[apim.sync_runtime_artifacts.gateway.skip_list]
sequences = ["name_of_the_file.xml"]
Refer - https://apim.docs.wso2.com/en/latest/install-and-setup/setup/distributed-deployment/deploying-wso2-api-m-in-a-distributed-setup/#configure-the-gateway-nodes
In the notification document (link below) the examples for Notification Configurations, it explains that configurations with overlapping prefix/suffix combinations are invalid.
Notification How To
However, there aren't any details for a way to catch any unspecified prefixes. If I had an S3 bucket with the directories dir1/ and dir2/, with a notification configuration like:
<NotificationConfiguration>
<TopicConfiguration>
<Topic>arn:aws:sns:us-east-1:123412341234:sns-notify-dir1</Topic>
<Event>s3:ObjectCreated:*</Event>
<Filter>
<S3Key>
<FilterRule>
<Name>prefix</Name>
<Value>dir1</Value>
</FilterRule>
</S3Key>
</Filter>
</TopicConfiguration>
<TopicConfiguration>
<Topic>arn:aws:sns:us-east-1:123412341234:sns-notify-dir2</Topic>
<Event>s3:ObjectCreated:*</Event>
<Filter>
<S3Key>
<FilterRule>
<Name>prefix</Name>
<Value>dir2</Value>
</FilterRule>
</S3Key>
</Filter>
</TopicConfiguration>
</NotificationConfiguration>
Is it possible to add a catchall filter? I know that overlapping rules don't work, so I can't just add:
<TopicConfiguration>
<Topic>arn:aws:sns:us-east-1:123412341234:sns-notify-generic</Topic>
<Event>s3:ObjectCreated:*</Event>
</TopicConfiguration>
I'd like to know if I can have a more generic SNS notification in the event that an object is added under a 3rd directory, or in no directory, while still handling the first two cases specifically. Specifically, I'd like a filter that only catches things that haven't already been filtered, though I would also be happy with the ability to send multiple notifications (such as sending sns-notify-dir1 and sns-notify-generic for dir1, but just sns-notify-generic for dir3).
dir1/ -> Handled by sns-notify-dir1
dir2/ -> Handled by sns-notify-dir2
/ -> How can I handle with sns-notify-generic?
dir3/ -> How can I handle with sns-notify-generic?
I realize that alternative solutions will work, such as only writing a generic SNS and having my utilities sort out whether to listen to it, as well as sending everything to a lambda function to sort out which notification to trigger. However, I like the idea of coding this as cleanly as possible, if it is possible.
Please let me know if additional details would help, and thank you!
I am using Jetty-9 in embedded mode and need only one web application. Consequently I would like the root URL to go to the homepage of that application, i.e. something like
http://localhost:4444/
should end up in a servlet. I start out with:
ServletContextHandler scContext =
new ServletContextHandler(ServletContextHandler.SESSIONS);
scContext.setContextPath("/");
None of the following worked, neither
scContext.addServlet(ListsServlet.class, "/");
nor
scContext.setWelcomeFiles(new String[]{"/lists})
where /lists is mapped to the ListsServlet servlet. All I get is a 403 (Forbidden).
I do not use the DefaultServlet, which seems to handle welcome files. But since the ServletContextHandler has setWelcomeFiles I expected it to contain the logic to use them.
Any ideas?
For the 403 Forbidden error, you have some security setup that is not allowing you to access the handlers/servlets.
Eliminate that security (for now), verify that the rest is working, then add security a bit later to lock down specifics.
If you want to see some the suggestions below at work, consider looking at the code example in the answer from another stackoverflow: How to correctly support html5 <video> sources with jetty.
Welcome files are appended to the incoming request path if there is nothing present at that location. For example requesting a directory and then a welcome-file of 'index.html' is appended to the request path.
While this would work ...
scContext.setWelcomeFiles(new String[]{"lists"})
// Add Default Servlet (must be named "default")
ServletHolder holderDefault = new ServletHolder("default",DefaultServlet.class);
holderDefault.setInitParameter("resourceBase",baseDir.getAbsolutePath());
holderDefault.setInitParameter("dirAllowed","true");
holderDefault.setInitParameter("welcomeServlets","true");
holderDefault.setInitParameter("redirectWelcome","true");
scContext.addServlet(holderDefault,"/");
It's likely not what you are aiming for, as you said the root path only.
The above would also make changes to requests like /foo/ to /foo/lists
Instead, it might make more sense to use a Rewrite rule + handler instead of the welcome-files approach.
RewriteHandler rewrite = new RewriteHandler();
rewrite.setHandler(scContext);
RewritePatternRule rootRule = new RewritePatternRule();
rootRule.setPattern("/");
rootRule.setReplacement("/list");
rootRule.setTerminating(true);
rewrite.addRule(rootRule);
server.setHandler(rewrite);
This RewritePatternRule simply changes any request path / to /list and then forwards that request to the wrapped ssContext (if you want to see the /list on the browser, change it to a RedirectPatternRule instead.
I am using mod_security 2.6.3, and I would like to be able to execute a shell script based on a rule-severity level. I am using the core rule set (CRS), which sets the severity level to 2 (for 'critical') when an attack is detected.
I would like to execute my script whenever the severity is high enough.
I tried to use the SecDefaultAction setting, such as:
SecDefaultAction "phase:2,log,deny,status:403,exec:/path/to/my/script"
But since the 'exec' action is a "non-disruptive" one, it always get executed, whether a critical rule or a non-critical rule is trigerred.
I could go through each critical SecRule and add "exec" next to it, but that would be tedious (and repetitive, and ugly).
I thought I could do something like:
SecRule ENV:SEVERITY "#lt 4" "exec:/path/to/my/script"
But somehow it never gets executed, probably because the critical rules have a block or deny statement which stops rule processing (since considered disruptive).
I also tried using the CRS anomaly score feature, like this:
SecRule TX:ANOMALY_SCORE "#ge 4" "exec:/path/to/my/script"
But it still does not get processed.
Any idea on how I could do this?
You could use the HIGHEST_SEVERITY variable to test it, such as:
SecRule HIGHEST_SEVERITY "#le 5" "nolog,pass,exec:/path/to/your/script"
Note the nolog,pass additional parameters that will preserve the original log message from the rule that changed the severity level.
Also, I suggest that you place this condition early in your .conf file (e.g. just after your SecDefaultAction line) to ensure it gets included in all contexts.
Another way of doing it would be to use a custom HTTP response status code in your SecDefaultAction (for instance, 418 "I'm a teapot") and trigger your condition based on it, in the logging phase (once the default action has been processed):
# On error, log then deny request with "418 I'm a teapot":
SecDefaultAction "phase:2,log,deny,status:418"
# On HTTP response status code 418, execute your script:
SecRule RESPONSE_STATUS "^418$" "phase:5,nolog,pass,exec:/path/to/your/script"
I'm trying to set the logging level to DEBUG in an embedded Jetty instance.
The documentation at http://docs.codehaus.org/display/JETTY/Debugging says to -
call SystemProperty.set("DEBUG", "true") before calling new
org.mortbay.jetty.Server().
I'm not sure what the SystemProperty class is, it doesn't seem to be documented anywhere. I tried System.setProperty(), but that didn't do the trick.
My question was answered on the Jetty mailing list by Joakim Erdfelt:
You are looking at the old Jetty 6.x docs at docs.codehaus.org.
DEBUG logging is just a logging level determined by the logging
implementation you choose to use.
If you use slf4j, then use slf4j's docs for configuring logging level. http://slf4j.org/manual.html
If you use java.util.logging, use the JVM docs. http://docs.oracle.com/javase/6/docs/technotes/guides/logging/overview.html
If you use the built-in StdErrLog, then there is a pattern to follow.
-D{classref}.LEVEL={level}
Where {classref} is the class reference you want to set the level on,
and all sub-class refs. and {level} is one of the values ALL, DEBUG,
INFO, WARN
Example:
-Dorg.eclipse.jetty.LEVEL=INFO - this will enable INFO level logging for all jetty packages / classes.
-Dorg.eclipse.jetty.io.LEVEL=DEBUG - this will enable DEBUG level logging for IO classes only
-Dorg.eclipse.jetty.servlet.LEVEL=ALL - this will enable ALL logging (trace events, internally ignored exceptions, etc..) for servlet
packages.
-Dorg.eclipse.jetty.util.thread.QueuedThreadPool.LEVEL=ALL - this will enable level ALL+ on the specific class only.
Add this
-Dorg.eclipse.jetty.util.log.class=org.eclipse.jetty.util.log.StdErrLog
-Dorg.eclipse.jetty.LEVEL=DEBUG
In case you just want to quickly get log messages to stderr add something like this to java command line:
-Dorg.eclipse.jetty.util.log.class=org.eclipse.jetty.util.log.StdErrLog -D{classref}.LEVEL=DEBUG
You can use this snippet to enable logging:
import org.eclipse.jetty.util.log.Log;
import org.eclipse.jetty.util.log.StdErrLog;
.
.
.
StdErrLog logger = new StdErrLog();
logger.setDebugEnabled(true);
Log.setLog(logger);