Re: [Exist-open] Securing JMX

[Adam R. <ad...@ex...>]

> The simplest setup would just be a monitoring system with a
> icon for each server, and visual indicators for uptime, locked threads or
> other critical problems. These would make calls to the JMX servlets on the
> servers every 30 seconds or so and could take some type of action, like
> sending a text message, if a server had a critical error.

As JMX is a standard protocol for this kind of operation, rather than
building your own monitoring system I would imagine it should be
pluggable into Zenoss or something similar...

http://community.zenoss.org/index.jspa

http://community.zenoss.org/search.jspa?peopleEnabled=true&userID=&containerType=&container=&spotlight=false&q=jmx

This would allow you to monitor eXist-db alongside all your other
servers and apps and have an icon for each as you describe with alerts
like sending text messages.


>>
>> We are ready to test the jmx over ssl approach but it seems overly complex
>> and maybe fragile.
>
> I am not really familiar with this.
>
>>
>>  I'm also thinking about using the servlet url approach as a backup or
>> alternative.  I'd love to learn more about what you are planning on doing.
>>
>
> I think some of the security problems with the JMX servelet have been solved
> in the latest 1.4.x release, and I think that would a good way to go if you
> didn't need super real time monitoring.
>
> Cheers,
>
> Casey
>
>
>>
>> thanks
>>
>> Eric Palmer
>> Director of Web Services
>> University of Richmond
>> ________________________________________
>> From: Casey Jordan [cas...@jo...]
>> Sent: Monday, July 25, 2011 4:53 PM
>> To: Dannes Wessels
>> Cc: exi...@li... ml
>> Subject: Re: [Exist-open] Securing JMX
>>
>> Yeah, I agree that does not sound ideal.
>>
>> Basically we have a large number of servers that need to be administered
>> from a central point. We are considering using JMX for this but given the
>> security problems I am leaning towards a custom servlet.
>>
>> The function of the servlet would provide both monitoring and
>> administration features:
>>
>>
>>  *   Monitor Memory Usage
>>  *   Monitor and Detect instability (Deadlock situations, runaway
>> processes etc)
>>  *   Monitor connections and traffic
>>  *   Monitor logged in users
>>  *   Provide services to:
>>    *   Backup database
>>    *   Restore database
>>
>> Ideally then we could write a GUI client to connect to this service and
>> provide an administration console.
>>
>> What do you think? Would it be better to do this through XMLRPC?
>>
>> Cheers,
>>
>> Casey
>>
>>
>>
>> On Mon, Jul 25, 2011 at 4:39 PM, Dannes Wessels
>> <da...@ex...<mailto:da...@ex...>> wrote:
>>
>> On 25 Jul 2011, at 20:27 , Casey Jordan wrote:
>>
>> I know that you can force JMX to use authentication however it only seems
>> that this is useful when a client is connecting to the JMX service, and it
>> also makes it hard to rotate passwords etc.
>>
>> Is there any way to have the authentication go through eXist, or require
>> that the admin user be authenticated for the connection to take place? For
>> things like the JMXServlet this would be very helpful, as right now it seems
>> that anyone can query that service by just surfing to the url....
>>
>> I studied the possibilities a few times, but it is kind of hard to get
>> this right…..  with tomcat support in mind it is even more difficult. Yes it
>> should be possible to couple JMX authentication to the DB internal user
>> database. But well, I find the documentation a bit difficult to understand
>> here.
>>
>> >From what I remember we need to arrange things on JVM level, with worst
>> case writing files in the JDK/JRE directory. I do not like that idea….
>>
>> D.
>>
>>
>>
>> --
>> --
>> Casey Jordan
>> easyDITA a product of Jorsek LLC
>> "CaseyDJordan" on LinkedIn, Twitter & Facebook
>> (585) 348 7399
>> easydita.com<http://easydita.com>
>>
>>
>> This message is intended only for the use of the Addressee(s) and may
>> contain information that is privileged, confidential, and/or exempt from
>> disclosure under applicable law.  If you are not the intended recipient,
>> please be advised that any disclosure  copying, distribution, or use of
>> the information contained herein is prohibited.  If you have received
>> this communication in error, please destroy all copies of the message,
>> whether in electronic or hard copy format, as well as attachments, and
>> immediately contact the sender by replying to this e-mail or by phone.
>> Thank you.
>
>
>
> --
> --
> Casey Jordan
> easyDITA a product of Jorsek LLC
> "CaseyDJordan" on LinkedIn, Twitter & Facebook
> (585) 348 7399
> easydita.com
>
>
> This message is intended only for the use of the Addressee(s) and may
> contain information that is privileged, confidential, and/or exempt from
> disclosure under applicable law.  If you are not the intended recipient,
> please be advised that any disclosure  copying, distribution, or use of
> the information contained herein is prohibited.  If you have received
> this communication in error, please destroy all copies of the message,
> whether in electronic or hard copy format, as well as attachments, and
> immediately contact the sender by replying to this e-mail or by phone.
> Thank you.
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>
>



-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb