the configuration page has an option to save the conversation for failed monitor sessions. Where does this information get written? I checked var/webmin logs and the modules/status files. So far i dont see anything logged that is helpful to explain why the monitor is failing.
I have several HTTPS monitors configured and 1 is failing .. a CURL execution is successful although it is reporting a certificate error
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In general it would nice to have a report of the Remote commands webmin is executing in order to obtain the status.
this is the line on the configuration page i am referring too..
Capture output from programs run when down? Yes No
I have the check box set to yes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When i open the monitor the current status is: HTTP/1.1 401 Unauthorized yielding a red status.
can this return code be added to the config to indicate a good response?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I will turn on email events again and double check. but, i am not getting the current status included in the email. Is there a mail template that might provide this added info? We have no mail templates defined just using the default setting.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In our case the status is 401 unauthorized probably because the the login screen is not getting satisfied. However, it would be nice to see more efficience of the full conversation. In this case a unauthorized does tell us that the websight responded vs say the 404 not available.
So should the 401 return code be included in the "good return list" currently it is not.
Also, when i run the same url through curl and a perl script using HTTP:tiny or LWP:Simple functions the return is complaining about DE cipher levels being to low.
Is there some sample perl code available that duplicates the webmin execution? It appears to be using the Net::SSLeay functions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Jamie -
i found a sample Net:SSLeay script and was able to verify exactly what webmin was getting. It seems to immediately recognize that a user / passwd is required and given those fields are empty it returns the not authorized 401 code.
Webmine http-monitor is not programmed to treat the 401 return as an UP status so in the end i added it to our script. Checking for the login screen is exactly what we want. Will keep an eye on this URL to see if it shows any offline activity.
Perhaps an option to capture the full HTTP response could be added for debugging in the future.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the configuration page has an option to save the conversation for failed monitor sessions. Where does this information get written? I checked var/webmin logs and the modules/status files. So far i dont see anything logged that is helpful to explain why the monitor is failing.
I have several HTTPS monitors configured and 1 is failing .. a CURL execution is successful although it is reporting a certificate error
What type of monitor are you using there - is it "Remote HTTP Server" or "SSL Certificate" ?
Remote HTTP Server
will webmin put the details into its own log or relay on the "syslog" config for direction?
In general it would nice to have a report of the Remote commands webmin is executing in order to obtain the status.
this is the line on the configuration page i am referring too..
Capture output from programs run when down? Yes No
I have the check box set to yes.
Each monitor has an option to set an email address, to deliver reports for the given monitor.
You can access it by clicking on the monitor directly.
getting emails is not the problem --
Monitor on bm062puxascs1 for 'Axway QA - HTTPS Public access' has detected that the service is down at 13/Feb/2019 14:12
what i need to determine is what webmin is seeing in the https response... this web page offers http file transfer and we know it is operational.
When i open the monitor the current status is: HTTP/1.1 401 Unauthorized yielding a red status.
can this return code be added to the config to indicate a good response?
I just tested this, and in the email notification when the website is down I see the line :
Current status: HTTP/1.0 404 Not Foundafter the "is down" line.
I will turn on email events again and double check. but, i am not getting the current status included in the email. Is there a mail template that might provide this added info? We have no mail templates defined just using the default setting.
In our case the status is 401 unauthorized probably because the the login screen is not getting satisfied. However, it would be nice to see more efficience of the full conversation. In this case a unauthorized does tell us that the websight responded vs say the 404 not available.
So should the 401 return code be included in the "good return list" currently it is not.
Also, when i run the same url through curl and a perl script using HTTP:tiny or LWP:Simple functions the return is complaining about DE cipher levels being to low.
Is there some sample perl code available that duplicates the webmin execution? It appears to be using the Net::SSLeay functions.
Jamie -
i found a sample Net:SSLeay script and was able to verify exactly what webmin was getting. It seems to immediately recognize that a user / passwd is required and given those fields are empty it returns the not authorized 401 code.
Webmine http-monitor is not programmed to treat the 401 return as an UP status so in the end i added it to our script. Checking for the login screen is exactly what we want. Will keep an eye on this URL to see if it shows any offline activity.
Perhaps an option to capture the full HTTP response could be added for debugging in the future.
Yeah, the current code treats any 40x response code as an error, either if no login was provided or if the login is wrong.