I'm new so forgive a dumb question...
Is the resource.cfg on the monitored system or on the Nagios server?
If it is on the Nagios server, will the information be sent in plain text to
the monitored system?
Rich White
Service Manager -- Illinois Compass
University of Illinois at Urbana-Champaign
________________________________
From: Peter Lecki [mailto:ple...@eagency.com]
Sent: Friday, March 06, 2009 11:19 AM
To: shadih rahman; nagios-users@lists.sourceforge.net
Subject: Re: [Nagios-users] encrypting or protecting nagios config files
You can use the resource.cfg file to store credentials, which is a secured
file. Credentials can then be passed as variables to service definitions such
as $PASSWORD1$ and it will pull the actual password string from the secured
resource file.
Peter.
________________________________
From: shadih rahman [mailto:shadhi...@gmail.com]
Sent: Friday, March 06, 2009 8:55 AM
To: nagios-users@lists.sourceforge.net
Subject: [Nagios-users] encrypting or protecting nagios config files
All,
in commands.cfg or in service definition file we have to enter password
community string and such. I was wondering if there is any way to encrypt that
or setup a system where those information relayed to nagios process in the
memory and there is no way to access them? Please advise on this. Thanks
--
Cordially,
Shadhin Rahman
-- ea926h
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting
any issue.
::: Messages without supporting info will risk being sent to /dev/null
