I am using syslog() function for logging information in one of my application.
I am using c code to call syslog() function in Fedora 14 Linux.
Currently when i call syslog function something like this:
syslog(LOG_INFO,"MYLOG");
I am getting logged msg in /var/log/messages file as follows
Oct 7 04:32:53 syslogname MYLOG
Now i want to have custom Priority value (say 137) logged in the beginning of the syslog() message. for eg: log should look some thing like this.
PRI Oct 7 04:32:53 syslogname MYLOG
I want PRI number to appear in the beginning of the logged message. I did Google search but didn't get proper answer. Request you to kindly suggest as to how to do this using syslog() function?
The /var/log/messages file is written by your syslog daemon. Traditionally the PRI value is stripped from it. See this question and my answer there.
You need to set up a special formatter in your syslog deamon to have the severity logged there. Rsyslog has templates for this. With nxlog you can use the $SyslogSeverity field and prepend it to $Message or $raw_message.
You could use rsyslog to write in the format that you require. The template for your requested format should look something like this:
%pri% %timereported% %syslogtag% %msg%
For available parameters you can check http://www.rsyslog.com/doc/property_replacer.html.
Related
When our service fails to deliver an email, the rejection notification returned to the sender contains the stack trace of the code that failed. Is there a way to send the delivery notification, without the attached errors?
We have a postfix server that handles incoming emails in a catchall python script. That script uploads the email to one of our services and throws an exception in case it failed.
This is the template we are using
failure_template = <<EOF
Charset: us-ascii
From: MAILER-DAEMON (Mail Delivery System)
Subject: Undelivered Mail Returned to Sender
Postmaster-Subject: Postmaster Copy: Undelivered Mail
This is the mail system at host $myhostname.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to <postmaster>
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
EOF
Expected result would be just the template notification, without the strack trace of the catch-all script.
The mail server simply includes in the bounce whatever your Python program displays on its standard error. Maybe call the script via a wrapper which saves the standard error to a sane place (or even discards it, if you are sure it never contains anything useful).
#!/bin/sh
python3 /path/to/deliver.py 2>>/var/log/deliver.log
Your mail server obviously needs to have write access to the log, and you'll probably want to set up periodic log rotation for the file.
Probably a better overall approach is for the Python program to not crash.
I'd like to remove the server header from Payara Micro's output.
For example, it reports this:
HTTP/1.1 200 OK
Server: Payara Micro #badassfish
I'd like to get rid of that Server line.
I see that issue 32 provided the capability in theory to disable this. The associated pull request certainly seems to show that there is some sort of property being consulted to disable this. And I can infer from this that I could presumably go into the administration GUI if this were a full-fledged server and click a checkbox somewhere.
But I'm running Payara Micro which needs to be fully configured from the command line at startup.
What I'm lacking is a simple "put this on the command line"-type of instruction and I can't seem to locate that anywhere. Is there a setting in, say, glassfish-web.xml-as-modified-by-Payara I could use? Or a command line switch? Or a specific asadmin attribute I could set in a pre-boot script?
Ideas?
The change that you referenced linked to a pull request which added a boolean server-header property to the http-listener which would disable the header.
There is no native asadmin command to set this property, so you will need to use an asadmin set command with the correct dotted name for the listener you want to modify. To find out what this is, you can use the get command with a wildcard and grep for the value you want, as shown below with Payara Server:
➜ ~ /opt/payara/server/171.1/bin/asadmin get "*" | grep server-header
configs.config.default-config.network-config.protocols.protocol.http-listener-2.http.server-header=true
configs.config.default-config.network-config.protocols.protocol.http-listener-1.http.server-header=true
configs.config.default-config.network-config.protocols.protocol.admin-listener.http.server-header=true
configs.config.server-config.network-config.protocols.protocol.admin-listener.http.server-header=true
configs.config.default-config.network-config.protocols.protocol.sec-admin-listener.http.server-header=true
configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.server-header=true
configs.config.server-config.network-config.protocols.protocol.http-listener-2.http.server-header=true
Since the default-config is just a template and not used, we want the listeners from server-config. http-listener-1 is for HTTP by default and http-listener-2 is for HTTPS by default. To modify the server-header property in Payara Micro, you would need to create a file with the following command in (note that Payara Micro only has a single listener by default called http-listener):
set configs.config.server-config.network-config.protocols.protocol.http-listener.http.server-header=false
You can then apply these with a prebootcommandfile as follows:
java -jar /opt/payara/micro/173/payara-micro.jar --prebootcommandfile myCommands.txt
You may also wish to disable the xpowered-by property via the same method.
I have gone through some tools like nagios, collectd but they din't find best as we need to monitor no_of_req/sec for each virtual host with all response status, with response time also.
I'm Using ELK Stack:
Separate access logs for each server block for better visibility or you can separate charts via URLs.
Then Use ELK stack:
Feed the logs to logstash via filebeat.
Create grok pattern for your log model.
Create charts via kibana and monitor in real time.
For realtime monitoring:
Try netdata, Its amazing. Please note its not a replacement for nagios or zabbix.
After some quick research, I found this: check_nginx_status.pl. I think defining something like:
define command {
command_name check-nginx
command_line $USER1$/check_nginx_status.pl -H $HOSTADDRESS$ -s $ARG1$ -u $ARG2$ $ARG3$ $ARG4$ $ARG5$ $ARG6$
}
is probably just what you're looking for.
The -s flag ($ARG1$) would be the hostname of the virtual host
The -u flag ($ARG2$) would be the specific url (/something/status)
And then the rest of the args would be used if you needed to add any additional flags.
Hope this helps!
When I ssh to my Datapower node like so: ssh user#192.168.0.1 I receive this response:
ssh user#192.168.0.1
(unknown)
Unauthorized access prohibited.
login:
I then enter in the same username, and am also prompted for a password. I type in my credentials and it works! Why didn't it just read my username the first time?
This is hampering my ability to automate a few basic tasks with shell scripts such as fetching logs for processing.
I agree with #Ken and #Stefan that a XML Management is a more appropriate tool for long term automations, howerver, sometimes we need something quick or temporary (or both) ... and for that a CLI automation is easier and faster to develop.
An easy way to push commands to CLI from a shell script is directing the input and output, like this quick sample:
#!/bin/ksh
DPHOST=datapower.device.company.com
DP_USER_ID="myuser"
DP_PASSWORD="mypasword"
TMPFILE=/tmp/tempfile.dp
OUTFILE=/tmp/outfile.dp
TS=`date +%Y%m%d%H%M%S`
cat << EOF > $TMPFILE
DP_USER_ID
DP_PASSWORD
default
echo show cpu
show cpu
echo show memory
show memory
EOF
ssh -T $DPHOST < $TMPFILE > $OUTFILE.$TS
rm $TMPFILE
Note that if you do not have any application domains defined, you may suppress the "default" after the password
And of course, for security reasons you may request the user and password at run time, rather then have it saved on a plain text file, but that is up to you ... the relevant piece here is that you can redirect the file with the commands to an regular ssh session
If you prefer, something like cat $TMPFILE | ssh -T $DPHOST > $OUTFILE.$TS would also works.
That is because DataPower really isn't a SSH server only using the protocol.
What I do in my scripts is that I do the connection, wait for the response and then send the username as the second command and password as third:
ssh [datapower ip]
(unknown)
Unauthorized access prohibited.
login:
your-username
password:
your-password
'#xi52:
DataPower ignores the passed-in username.
Will using the XML Management interface meet your needs? I probably have some scripts laying around.
Ken
I'm trying to set up an email address in qmail such that a unique identifier can be passed as part of the email address.
For example:
reply-123#example.com, reply-345#example.com, reply-99999#example.com would all go to the 'reply' user and be sent to the same shell script. Currently, email sent to reply#example.com goes to the script and I pass the unique id in the subject or message body. Would be grateful for any suggestions. Thanks!
In a default qmail setup, you can do exactly what you suggest... anything following a dash is ignored for delivery purposes, so reply-anything#example.com will be processed by the .qmail-reply file, where you would presumably send the mail to your script and look at the address to obtain the identifier.
We use this for bounce tracking - if the email is to xyz#example.com, and the sender is bounce#sender.com, then the from address is written this way:
bounce-xyz=example.com#sender.com
And a script flags the address as no good.
EDIT:
I screwed this up a bit - I guess I'm rusty on qmail. The alias thing doesn't work by default as I stated above. To support extensions for bounce#sender.com, you need a .qmail-default file in ~bounce.
See the "extension addresses" (section 4.1.5) on LWQ: http://www.lifewithqmail.org/lwq.html