Reoccuring Scheduled Maintenance
Hey Adam & Team,
We have a use case for a group of devices to not alert on them outside of 9am-5pm.
Leveraging the API, can we setup a crontab, to achieve a recurring maintenance window for a particular group?
Mark Sanchez // Firewall Engineer II *deepwatch* // *Advancing Security Operations* *Mobile:* 716.418.5420 *Office**:* 855.303.3033 Website https://deepwatch.com // Facebook https://www.facebook.com/deepwatchsec // Instagram https://www.instagram.com/deepwatch_sec/ // LinkedIn https://www.linkedin.com/company/deepwatchsec/ // Twitter https://twitter.com/deepwatch_sec
Disclaimer
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.
I’m not sure what would be a good way to achieve this. Perhaps just manipulating a single maintenance slot directly in SQL with an external script.
We sort of intend this complex stuff to be done with an external service, since we’ve never had resources to properly build the UI elements to do this ourselves.
Just scripting changing the maint slot period every day should suffice though.
Thanks,
Adam.
From: observium observium-bounces@observium.org On Behalf Of Mark Sanchez via observium Sent: 06 May 2020 17:41 To: observium@observium.org Cc: Mark Sanchez mark.sanchez@deepwatch.com Subject: [Observium] Reoccuring Scheduled Maintenance
Hey Adam & Team,
We have a use case for a group of devices to not alert on them outside of 9am-5pm.
Leveraging the API, can we setup a crontab, to achieve a recurring maintenance window for a particular group?
Mark Sanchez // Firewall Engineer II deepwatch // Advancing Security Operations Mobile: 716.418.5420 Office: 855.303.3033 https://deepwatch.com Website // https://www.facebook.com/deepwatchsec Facebook // https://www.instagram.com/deepwatch_sec/ Instagram // https://www.linkedin.com/company/deepwatchsec/ LinkedIn // https://twitter.com/deepwatch_sec Twitter
Confidentiality Notice
This communication constitutes an electronic communication within the meaning of the Electronic Communications Privacy Act, 18 U.S.C. Section 2510, and its disclosure is strictly limited to the recipient intended by the sender of this message. This transmission and any attachments may contain confidential information and work product(s). If you are not the intended recipient, any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. Please contact deepwatch immediately by return e-mail or call (855) 303-3033 and destroy the original transmission and its attachments without reading or saving in any manner.
If we could tweak the severity of an alert checker, that would also solve our issue downstream.
Any ETA for adding other severities, in addition to critical?
Kind Regards, Mark Sanchez
On May 6, 2020, at 2:06 PM, Adam Armstrong via observium observium@observium.org wrote:
I’m not sure what would be a good way to achieve this. Perhaps just manipulating a single maintenance slot directly in SQL with an external script.
We sort of intend this complex stuff to be done with an external service, since we’ve never had resources to properly build the UI elements to do this ourselves.
Just scripting changing the maint slot period every day should suffice though.
Thanks, Adam.
From: observium observium-bounces@observium.org On Behalf Of Mark Sanchez via observium Sent: 06 May 2020 17:41 To: observium@observium.org Cc: Mark Sanchez mark.sanchez@deepwatch.com Subject: [Observium] Reoccuring Scheduled Maintenance
Hey Adam & Team,
We have a use case for a group of devices to not alert on them outside of 9am-5pm.
Leveraging the API, can we setup a crontab, to achieve a recurring maintenance window for a particular group?
Mark Sanchez // Firewall Engineer II deepwatch // Advancing Security Operations Mobile: 716.418.5420 Office: 855.303.3033 Website // Facebook // Instagram // LinkedIn // Twitter
Confidentiality Notice
This communication constitutes an electronic communication within the meaning of the Electronic Communications Privacy Act, 18 U.S.C. Section 2510, and its disclosure is strictly limited to the recipient intended by the sender of this message. This transmission and any attachments may contain confidential information and work product(s). If you are not the intended recipient, any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. Please contact deepwatch immediately by return e-mail or call (855) 303-3033 and destroy the original transmission and its attachments without reading or saving in any manner.
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
If I was to add severities, it’d probably be in the form of multiple tests so an individual checker can return different severity levels.
I’m not sure I understand the need otherwise, except as a manual field you can set in an alert checker and have that passed through in an alert. This can easily be done by just putting some text in the alert checker description.
I suppose there’s some utility to having another bit of data in the UI for sorting and filtering.
Adam.
From: Mark Sanchez mark.sanchez@deepwatch.com Sent: 06 May 2020 19:19 To: Observium observium@observium.org Cc: Adam Armstrong adama@observium.org Subject: Re: [Observium] Reoccuring Scheduled Maintenance
If we could tweak the severity of an alert checker, that would also solve our issue downstream.
Any ETA for adding other severities, in addition to critical?
Kind Regards,
Mark Sanchez
On May 6, 2020, at 2:06 PM, Adam Armstrong via observium <observium@observium.org mailto:observium@observium.org > wrote:
I’m not sure what would be a good way to achieve this. Perhaps just manipulating a single maintenance slot directly in SQL with an external script.
We sort of intend this complex stuff to be done with an external service, since we’ve never had resources to properly build the UI elements to do this ourselves.
Just scripting changing the maint slot period every day should suffice though.
Thanks,
Adam.
From: observium <observium-bounces@observium.org mailto:observium-bounces@observium.org > On Behalf Of Mark Sanchez via observium Sent: 06 May 2020 17:41 To: observium@observium.org mailto:observium@observium.org Cc: Mark Sanchez <mark.sanchez@deepwatch.com mailto:mark.sanchez@deepwatch.com > Subject: [Observium] Reoccuring Scheduled Maintenance
Hey Adam & Team,
We have a use case for a group of devices to not alert on them outside of 9am-5pm.
Leveraging the API, can we setup a crontab, to achieve a recurring maintenance window for a particular group?
Mark Sanchez // Firewall Engineer II deepwatch // Advancing Security Operations Mobile: 716.418.5420 Office: 855.303.3033 https://deepwatch.com Website // https://www.facebook.com/deepwatchsec Facebook // https://www.instagram.com/deepwatch_sec/ Instagram // https://www.linkedin.com/company/deepwatchsec/ LinkedIn // https://twitter.com/deepwatch_sec Twitter
Confidentiality Notice
This communication constitutes an electronic communication within the meaning of the Electronic Communications Privacy Act, 18 U.S.C. Section 2510, and its disclosure is strictly limited to the recipient intended by the sender of this message. This transmission and any attachments may contain confidential information and work product(s). If you are not the intended recipient, any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. Please contact deepwatch immediately by return e-mail or call (855) 303-3033 and destroy the original transmission and its attachments without reading or saving in any manner.
_______________________________________________ observium mailing list observium@observium.org mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
We have setup our ticket platform (ServiceNow) to use the severity sent over, which has been critical for everything.
I like the idea of having it in the UI as a configurable field, which makes scaling this better/easier.
If this is something you plan to do, please let me know an ETA - it might save from bandaid-ing the way you mentioned.
Thanks Adam.
Kind Regards, Mark Sanchez
On May 6, 2020, at 2:21 PM, Adam Armstrong via observium observium@observium.org wrote:
If I was to add severities, it’d probably be in the form of multiple tests so an individual checker can return different severity levels.
I’m not sure I understand the need otherwise, except as a manual field you can set in an alert checker and have that passed through in an alert. This can easily be done by just putting some text in the alert checker description.
Disclaimer
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.
I agree being able to set the priority would be good. Many downstream notification systems can have their own routing logic based on severity, time of day, etc.
From: observium [mailto:observium-bounces@observium.org] On Behalf Of Mark Sanchez via observium Sent: Wednesday, May 6, 2020 2:28 PM To: Observium Cc: Mark Sanchez Subject: Re: [Observium] Reoccuring Scheduled Maintenance
CAUTION EXTERNAL EMAIL: DO NOT open attachments or click links from unknown or unexpected emails.
We have setup our ticket platform (ServiceNow) to use the severity sent over, which has been critical for everything.
I like the idea of having it in the UI as a configurable field, which makes scaling this better/easier.
If this is something you plan to do, please let me know an ETA - it might save from bandaid-ing the way you mentioned.
Thanks Adam.
Kind Regards, Mark Sanchez
On May 6, 2020, at 2:21 PM, Adam Armstrong via observium observium@observium.org wrote: If I was to add severities, it’d probably be in the form of multiple tests so an individual checker can return different severity levels.
I’m not sure I understand the need otherwise, except as a manual field you can set in an alert checker and have that passed through in an alert. This can easily be done by just putting some text in the alert checker description.
Confidentiality Notice
This communication constitutes an electronic communication within the meaning of the Electronic Communications Privacy Act, 18 U.S.C. Section 2510, and its disclosure is strictly limited to the recipient intended by the sender of this message. This transmission and any attachments may contain confidential information and work product(s). If you are not the intended recipient, any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. Please contact deepwatch immediately by return e-mail or call (855) 303-3033 and destroy the original transmission and its attachments without reading or saving in any manner.
Do you mean in so much as just setting an alert checker to be a severity, so you can use that bit of meta data elsewhere?
Like I mentioned earlier, the reason I’d not implemented that already is because that always seemed little simplistic to me, like there was a gotcha scenario just waiting to appear.
Adam.
On 6 May 2020, at 22:08, Ryan, Spencer J. via observium observium@observium.org wrote:
I agree being able to set the priority would be good. Many downstream notification systems can have their own routing logic based on severity, time of day, etc.
From: observium [mailto:observium-bounces@observium.org mailto:observium-bounces@observium.org] On Behalf Of Mark Sanchez via observium Sent: Wednesday, May 6, 2020 2:28 PM To: Observium Cc: Mark Sanchez Subject: Re: [Observium] Reoccuring Scheduled Maintenance
CAUTION EXTERNAL EMAIL: DO NOT open attachments or click links from unknown or unexpected emails.
We have setup our ticket platform (ServiceNow) to use the severity sent over, which has been critical for everything.
I like the idea of having it in the UI as a configurable field, which makes scaling this better/easier.
If this is something you plan to do, please let me know an ETA - it might save from bandaid-ing the way you mentioned.
Thanks Adam.
Kind Regards, Mark Sanchez
On May 6, 2020, at 2:21 PM, Adam Armstrong via observium observium@observium.org wrote:
If I was to add severities, it’d probably be in the form of multiple tests so an individual checker can return different severity levels.
I’m not sure I understand the need otherwise, except as a manual field you can set in an alert checker and have that passed through in an alert. This can easily be done by just putting some text in the alert checker description.
Confidentiality Notice
This communication constitutes an electronic communication within the meaning of the Electronic Communications Privacy Act, 18 U.S.C. Section 2510, and its disclosure is strictly limited to the recipient intended by the sender of this message. This transmission and any attachments may contain confidential information and work product(s). If you are not the intended recipient, any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. Please contact deepwatch immediately by return e-mail or call (855) 303-3033 and destroy the original transmission and its attachments without reading or saving in any manner.
observium mailing list observium@observium.org mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Correct. For example, I have two alert checks set up for Device Offline, one is for ICMP unreachable, and the other is for SNMP unreachable.
At 3am I don’t need to start paging/waking people up for a (likely transient) SNMP issue, but I do need to for devices offline. Lots of alerting systems (Such as pagerduty) allow you to treat alerts differently based on the severity.
From: observium [mailto:observium-bounces@observium.org] On Behalf Of Adam Armstrong via observium Sent: Wednesday, May 6, 2020 11:09 PM To: Observium Cc: Adam Armstrong Subject: Re: [Observium] Reoccuring Scheduled Maintenance
CAUTION EXTERNAL EMAIL: DO NOT open attachments or click links from unknown or unexpected emails.
Do you mean in so much as just setting an alert checker to be a severity, so you can use that bit of meta data elsewhere?
Like I mentioned earlier, the reason I’d not implemented that already is because that always seemed little simplistic to me, like there was a gotcha scenario just waiting to appear.
Adam.
On 6 May 2020, at 22:08, Ryan, Spencer J. via observium <observium@observium.orgmailto:observium@observium.org> wrote:
I agree being able to set the priority would be good. Many downstream notification systems can have their own routing logic based on severity, time of day, etc.
From: observium [mailto:observium-bounces@observium.org] On Behalf Of Mark Sanchez via observium Sent: Wednesday, May 6, 2020 2:28 PM To: Observium Cc: Mark Sanchez Subject: Re: [Observium] Reoccuring Scheduled Maintenance
CAUTION EXTERNAL EMAIL: DO NOT open attachments or click links from unknown or unexpected emails.
We have setup our ticket platform (ServiceNow) to use the severity sent over, which has been critical for everything.
I like the idea of having it in the UI as a configurable field, which makes scaling this better/easier.
If this is something you plan to do, please let me know an ETA - it might save from bandaid-ing the way you mentioned.
Thanks Adam.
Kind Regards, Mark Sanchez
On May 6, 2020, at 2:21 PM, Adam Armstrong via observium <observium@observium.orgmailto:observium@observium.org> wrote: If I was to add severities, it’d probably be in the form of multiple tests so an individual checker can return different severity levels.
I’m not sure I understand the need otherwise, except as a manual field you can set in an alert checker and have that passed through in an alert. This can easily be done by just putting some text in the alert checker description.
Confidentiality Notice This communication constitutes an electronic communication within the meaning of the Electronic Communications Privacy Act, 18 U.S.C. Section 2510, and its disclosure is strictly limited to the recipient intended by the sender of this message. This transmission and any attachments may contain confidential information and work product(s). If you are not the intended recipient, any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. Please contact deepwatch immediately by return e-mail or call (855) 303-3033 and destroy the original transmission and its attachments without reading or saving in any manner. _______________________________________________ observium mailing list observium@observium.orgmailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Yes, as simple as that is - it would greatly help our implementation, keep things straight-forward in the UI, instead of workarounds like looking for tags in the description.
Kind Regards, Mark Sanchez
On May 6, 2020, at 11:09 PM, Adam Armstrong via observium observium@observium.org wrote:
Do you mean in so much as just setting an alert checker to be a severity, so you can use that bit of meta data elsewhere?
Like I mentioned earlier, the reason I’d not implemented that already is because that always seemed little simplistic to me, like there was a gotcha scenario just waiting to appear.
Adam.
On 6 May 2020, at 22:08, Ryan, Spencer J. via observium observium@observium.org wrote:
I agree being able to set the priority would be good. Many downstream notification systems can have their own routing logic based on severity, time of day, etc.
From: observium [mailto:observium-bounces@observium.org] On Behalf Of Mark Sanchez via observium Sent: Wednesday, May 6, 2020 2:28 PM To: Observium Cc: Mark Sanchez Subject: Re: [Observium] Reoccuring Scheduled Maintenance
CAUTION EXTERNAL EMAIL: DO NOT open attachments or click links from unknown or unexpected emails.
We have setup our ticket platform (ServiceNow) to use the severity sent over, which has been critical for everything.
I like the idea of having it in the UI as a configurable field, which makes scaling this better/easier.
If this is something you plan to do, please let me know an ETA - it might save from bandaid-ing the way you mentioned.
Thanks Adam.
Kind Regards, Mark Sanchez
On May 6, 2020, at 2:21 PM, Adam Armstrong via observium observium@observium.org wrote:
If I was to add severities, it’d probably be in the form of multiple tests so an individual checker can return different severity levels.
I’m not sure I understand the need otherwise, except as a manual field you can set in an alert checker and have that passed through in an alert. This can easily be done by just putting some text in the alert checker description.
Confidentiality Notice
This communication constitutes an electronic communication within the meaning of the Electronic Communications Privacy Act, 18 U.S.C. Section 2510, and its disclosure is strictly limited to the recipient intended by the sender of this message. This transmission and any attachments may contain confidential information and work product(s). If you are not the intended recipient, any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. Please contact deepwatch immediately by return e-mail or call (855) 303-3033 and destroy the original transmission and its attachments without reading or saving in any manner.
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Same here. Our alerting process is based on "can wait till morning" and "oh my god GET UP RIGHT NOW". Would be great to be able to have the criticality have some sort of low/medium/high selector in the UI, we can take care of structuring the logic for different thresholds manually by just creating a few additional alert checkers and categorizing them as appropriate.
R
On Thu, May 7, 2020 at 6:52 AM Mark Sanchez via observium < observium@observium.org> wrote:
Yes, as simple as that is - it would greatly help our implementation, keep things straight-forward in the UI, instead of workarounds like looking for tags in the description.
Kind Regards, Mark Sanchez
On May 6, 2020, at 11:09 PM, Adam Armstrong via observium < observium@observium.org> wrote:
Do you mean in so much as just setting an alert checker to be a severity, so you can use that bit of meta data elsewhere?
Like I mentioned earlier, the reason I’d not implemented that already is because that always seemed little simplistic to me, like there was a gotcha scenario just waiting to appear.
Adam.
On 6 May 2020, at 22:08, Ryan, Spencer J. via observium < observium@observium.org> wrote:
I agree being able to set the priority would be good. Many downstream notification systems can have their own routing logic based on severity, time of day, etc.
*From:* observium [mailto:observium-bounces@observium.org observium-bounces@observium.org] *On Behalf Of *Mark Sanchez via observium *Sent:* Wednesday, May 6, 2020 2:28 PM *To:* Observium *Cc:* Mark Sanchez *Subject:* Re: [Observium] Reoccuring Scheduled Maintenance
*CAUTION EXTERNAL EMAIL:* DO NOT open attachments or click links from unknown or unexpected emails.
We have setup our ticket platform (ServiceNow) to use the severity sent over, which has been critical for everything.
I like the idea of having it in the UI as a configurable field, which makes scaling this better/easier.
If this is something you plan to do, please let me know an ETA - it might save from bandaid-ing the way you mentioned.
Thanks Adam.
Kind Regards, Mark Sanchez
On May 6, 2020, at 2:21 PM, Adam Armstrong via observium < observium@observium.org> wrote:
If I was to add severities, it’d probably be in the form of multiple tests so an individual checker can return different severity levels.
I’m not sure I understand the need otherwise, except as a manual field you can set in an alert checker and have that passed through in an alert. This can easily be done by just putting some text in the alert checker description.
*Confidentiality Notice*
This communication constitutes an electronic communication within the meaning of the Electronic Communications Privacy Act, 18 U.S.C. Section 2510, and its disclosure is strictly limited to the recipient intended by the sender of this message. This transmission and any attachments may contain confidential information and work product(s). If you are not the intended recipient, any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is *STRICTLY PROHIBITED*. Please contact deepwatch immediately by return e-mail or call (855) 303-3033 and destroy the original transmission and its attachments without reading or saving in any manner. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Hey Adam,
Curious if there's a configuration file or something I can do on my end to enable Severities other than CRITICAL?
Mark Sanchez // Firewall Engineer II *deepwatch* // *Advancing Security Operations* *Mobile:* 716.418.5420 *Office**:* 855.303.3033 Website https://deepwatch.com // Facebook https://www.facebook.com/deepwatchsec // Instagram https://www.instagram.com/deepwatch_sec/ // LinkedIn https://www.linkedin.com/company/deepwatchsec/ // Twitter https://twitter.com/deepwatch_sec
On Thu, May 7, 2020 at 10:11 AM Rick Heil rheil@mergeworld.com wrote:
Same here. Our alerting process is based on "can wait till morning" and "oh my god GET UP RIGHT NOW". Would be great to be able to have the criticality have some sort of low/medium/high selector in the UI, we can take care of structuring the logic for different thresholds manually by just creating a few additional alert checkers and categorizing them as appropriate.
R
On Thu, May 7, 2020 at 6:52 AM Mark Sanchez via observium < observium@observium.org> wrote:
Yes, as simple as that is - it would greatly help our implementation, keep things straight-forward in the UI, instead of workarounds like looking for tags in the description.
Kind Regards, Mark Sanchez
On May 6, 2020, at 11:09 PM, Adam Armstrong via observium < observium@observium.org> wrote:
Do you mean in so much as just setting an alert checker to be a severity, so you can use that bit of meta data elsewhere?
Like I mentioned earlier, the reason I’d not implemented that already is because that always seemed little simplistic to me, like there was a gotcha scenario just waiting to appear.
Adam.
On 6 May 2020, at 22:08, Ryan, Spencer J. via observium < observium@observium.org> wrote:
I agree being able to set the priority would be good. Many downstream notification systems can have their own routing logic based on severity, time of day, etc.
*From:* observium [mailto:observium-bounces@observium.org observium-bounces@observium.org] *On Behalf Of *Mark Sanchez via observium *Sent:* Wednesday, May 6, 2020 2:28 PM *To:* Observium *Cc:* Mark Sanchez *Subject:* Re: [Observium] Reoccuring Scheduled Maintenance
*CAUTION EXTERNAL EMAIL:* DO NOT open attachments or click links from unknown or unexpected emails.
We have setup our ticket platform (ServiceNow) to use the severity sent over, which has been critical for everything.
I like the idea of having it in the UI as a configurable field, which makes scaling this better/easier.
If this is something you plan to do, please let me know an ETA - it might save from bandaid-ing the way you mentioned.
Thanks Adam.
Kind Regards, Mark Sanchez
On May 6, 2020, at 2:21 PM, Adam Armstrong via observium < observium@observium.org> wrote:
If I was to add severities, it’d probably be in the form of multiple tests so an individual checker can return different severity levels.
I’m not sure I understand the need otherwise, except as a manual field you can set in an alert checker and have that passed through in an alert. This can easily be done by just putting some text in the alert checker description.
*Confidentiality Notice*
This communication constitutes an electronic communication within the meaning of the Electronic Communications Privacy Act, 18 U.S.C. Section 2510, and its disclosure is strictly limited to the recipient intended by the sender of this message. This transmission and any attachments may contain confidential information and work product(s). If you are not the intended recipient, any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is *STRICTLY PROHIBITED*. Please contact deepwatch immediately by return e-mail or call (855) 303-3033 and destroy the original transmission and its attachments without reading or saving in any manner. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
participants (4)
-
Adam Armstrong -
Mark Sanchez -
Rick Heil -
Ryan, Spencer J.