Suggestion: make config or make init targets
Hi,
It would be nice if there was a way to install particularly the init script automatically. For example, on Redhat, one has to (copied and pasted from another page - I did something similar for the version I got from subversion, where I was just compiling and installing the client):
cp -p /usr/local/src/xymon-4.2.3/rpm/hobbit-init.d /etc/rc.d/init.d/xymon
chown root:root /etc/rc.d/init.d/xymon
chmod 755 /etc/rc.d/init.d/xymon
chkconfig xymon on
One has to also edit /etc/rc.d/init.d/xymon change the DAEMON to point to one's actual path (which the configure script already has).
The above steps need to be done for xymon-client too.
Then you need to copy /path/to/source/xymon-client.default to /etc/default/xymon-client. You need to edit it and add the Xymon server IP address, which again, you already entered in the configure script...
There are several steps here which could be automated, and it would make installing the client on machines quicker and less error prone, and many of us have to do this on many machines.
I suggest the above could be accomplished with a "make config" or "make init" target from the source directory, logged in as root.
If you are using e.g. Debian instead of Redhat, this would be automatically detected and the debian init scripts would be installed instead.
Unfortunately, I'm no shell script wizz and can't really do this myself.
Kind regards,
Sebastian A
On Thursday, 24 February 2011 21:35:06 SebA wrote:
Hi,
It would be nice if there was a way to install particularly the init script automatically. For example, on Redhat, one has to (copied and pasted from another page - I did something similar for the version I got from subversion, where I was just compiling and installing the client):
cp -p /usr/local/src/xymon-4.2.3/rpm/hobbit-init.d /etc/rc.d/init.d/xymon
chown root:root /etc/rc.d/init.d/xymon
chmod 755 /etc/rc.d/init.d/xymon
chkconfig xymon on
One has to also edit /etc/rc.d/init.d/xymon change the DAEMON to point to one's actual path (which the configure script already has).
The above steps need to be done for xymon-client too.
Then you need to copy /path/to/source/xymon-client.default to /etc/default/xymon-client. You need to edit it and add the Xymon server IP address, which again, you already entered in the configure script...
There are several steps here which could be automated, and it would make installing the client on machines quicker and less error prone, and many of us have to do this on many machines.
None of these steps are necessary if you use the packages that are already available (e.g. in Mandriva, or for RHEL/CentOS/OEL at http://staff.telkomsa.net/packages/
I suggest the above could be accomplished with a "make config" or "make init" target from the source directory, logged in as root.
If you are using e.g. Debian instead of Redhat, this would be automatically detected and the debian init scripts would be installed instead.
Unfortunately, I'm no shell script wizz and can't really do this myself.
Wouldn't you want a package instead?
I will try and makde 'rpm -ta xymon-4.3.0.tar.gz' work for final 4.3.0 release.
Regards, Buchan
Buchan Milne wrote:
On Thursday, 24 February 2011 21:35:06 SebA wrote: <snip>
Wouldn't you want a package instead?
I will try and makde 'rpm -ta xymon-4.3.0.tar.gz' work for final 4.3.0 release.
Regards, Buchan
Well, (a) I am impatient and wanted the latest features and fixes faster than 4.3.0 was going to be released, let alone waiting for an RPM to be built (although I appreciate your effort here - thanks), but (b) and more critically on this occasion, although this is a redhat derivative I was compiling the client on, it does not use RPMs, it uses Conary instead. This is rPath Linux. So an RPM is not going to help me on these machines. (Although I also do have plenty of servers that do use RPMs, and I would be pleased to use your RPM on those once it becomes available. On those machines I probably used one of your old RPMs a while back.) No package exists for rPath Linux. I spent a while trying to find one. I even looked into writing one. But then I realised that compiling the client was pretty painless these days (it used to fail on some 'dependency' that was not actually required for the client). The only thing that is still annoying is the init script.
Kind regards,
Sebastian A
xymon-bounces at xymon.com wrote:
Buchan Milne wrote:
On Thursday, 24 February 2011 21:35:06 SebA wrote: <snip>
Wouldn't you want a package instead?
I will try and makde 'rpm -ta xymon-4.3.0.tar.gz' work for final 4.3.0 release.
Regards, Buchan
Well, (a) I am impatient and wanted the latest features and fixes faster than 4.3.0 was going to be released, let alone waiting for an RPM to be built
And I was also keen to test the latest svn version at around the RC stage to check for any bugs in production so they could be fixed before the final release.
Kind regards,
Sebastian A
Hi, i'm tryng to use soap to test a web service, using xml file (xymon 4.3.0 rc1 on red-hat 6 es) I have this response : env:Clientorg.xml.sax.SAXParseException: The markup in the document following the root element must be well-formed.
This is entry in my host.cfg:
soap=webtest;http://my.server/MonitoredService/MonitorService;file:/opt/xymon/server/xml/...;
any suggestion ? thanks, Marco
Il 25/02/2011 13.38, SebA ha scritto:
xymon-bounces at xymon.com wrote:
Buchan Milne wrote:
On Thursday, 24 February 2011 21:35:06 SebA wrote:<snip>
Wouldn't you want a package instead?
I will try and makde 'rpm -ta xymon-4.3.0.tar.gz' work for final 4.3.0 release.
Regards, Buchan
Well, (a) I am impatient and wanted the latest features and fixes faster than 4.3.0 was going to be released, let alone waiting for an RPM to be built
And I was also keen to test the latest svn version at around the RC stage to check for any bugs in production so they could be fixed before the final release.
Kind regards,
Sebastian A
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Risolto cambiando le istruzioni nel file xml.
In the response from the server I have 3 alarm levels OK | WARNING | CRITICAL It's possible in 4.3.0 rc1 manage these three states using cont tag ?
thanks for your suggestions,
Marco
Il 26/02/2011 13.02, Marco Avvisano ha scritto:
Hi, i'm tryng to use soap to test a web service, using xml file (xymon 4.3.0 rc1 on red-hat 6 es) I have this response : env:Clientorg.xml.sax.SAXParseException: The markup in the document following the root element must be well-formed.
This is entry in my host.cfg:
soap=webtest;http://my.server/MonitoredService/MonitorService;file:/opt/xymon/server/xml/...;
any suggestion ? thanks, Marco
On Thu, 03 Mar 2011 11:44:35 +0100, Marco Avvisano <marco.avvisano at regione.toscana.it> wrote:
Risolto cambiando le istruzioni nel file xml.
In the response from the server I have 3 alarm levels OK | WARNING | CRITICAL It's possible in 4.3.0 rc1 manage these three states using cont tag ?
if I understand correctly, you would like the status to be green when the response says OK, yellow when it says "warning" and red when it says "critical" ?
It makes sense, but unfortunately the soap (and other content checks) only support a red or yellow status.
Regards, Henrik
Il 03/03/2011 12.20, henrik at hswn.dk ha scritto:
On Thu, 03 Mar 2011 11:44:35 +0100, Marco Avvisano <marco.avvisano at regione.toscana.it> wrote:
Risolto cambiando le istruzioni nel file xml.
In the response from the server I have 3 alarm levels OK | WARNING | CRITICAL It's possible in 4.3.0 rc1 manage these three states using cont tag ?
if I understand correctly, you would like the status to be green when the response says OK, yellow when it says "warning" and red when it says "critical" ?
Correct, it will be great to have 3 status levels ..
It makes sense, but unfortunately the soap (and other content checks) only support a red or yellow status.
The yellow status is when http status is red ? I see in 4.3.0 rc1 is possible to controll the httpstatus code. Also for this tag is possible to have only 2 levels (green/red) ?
Marco
Regards, Henrik
Sorry, write in italian ..
I solved changing xml, but not work if use https:
soap=webtest;https:/cert.pem@/my.server/MonitoredService/MonitorService;file:/opt/xymon/server/xml/MonitoredService.xml;
error message is:
Bad Request
Your browser sent a request that this server could not understand. Reason: You're speaking plain HTTP to an SSL-enabled server port. Instead use the HTTPS scheme to access this URL, please.
In the response from the server I have 3 alarm levels OK | WARNING | CRITICAL It's possible in 4.3.0 rc1 manage these three states using cont tag ?
thanks for your suggestions,
Marco
Il 03/03/2011 11.44, Marco Avvisano ha scritto:
Risolto cambiando le istruzioni nel file xml.
In the response from the server I have 3 alarm levels OK | WARNING | CRITICAL It's possible in 4.3.0 rc1 manage these three states using cont tag ?
thanks for your suggestions,
Marco
Il 26/02/2011 13.02, Marco Avvisano ha scritto:
Hi, i'm tryng to use soap to test a web service, using xml file (xymon 4.3.0 rc1 on red-hat 6 es) I have this response : env:Clientorg.xml.sax.SAXParseException: The markup in the document following the root element must be well-formed.
This is entry in my host.cfg:
soap=webtest;http://my.server/MonitoredService/MonitorService;file:/opt/xymon/server/xml/...;
any suggestion ? thanks, Marco
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Hi,
someone has developed something similar to old deadcat script sla-report.sh?
In xymon 4.3.0 rc1 there are cgi to get similar results ?
Marco
----- "Marco Avvisano" <marco.avvisano at regione.toscana.it> wrote:
Hi,
someone has developed something similar to old deadcat script sla-report.sh?
We have a local version running on Xymon 4.2.3. But, I'm not quite currently happy to make it public, I still need to review some changes and results.
The main use we have for it is to provide a service-based availability. However, since service-based presentation is important for more than just ad-hoc availability reporting, I don't think this is the right strategy in the long run.
I would have considered using combotests to represent services, and just use the built-in availability report, but we don't have 6 months of combotest data for these services.
In xymon 4.3.0 rc1 there are cgi to get similar results ?
Besides the built-in Availability report?
What does it not do for you that you need?
Or, is your need similar to ours?
Regards, Buchan
participants (4)
-
bgmilne＠staff.telkomsa.net
-
henrik＠hswn.dk
-
marco.avvisano＠regione.toscana.it
-
spa＠syntec.co.uk