Re: [monit-dev] feature

[rory]

In our situation, we have our software on an nfs-repository. My monit 
startup scripts are dynamically generated via a config file that maps 
services to hostnames. Thus my "upgrade" doesn't deal with copying 
binaries, rather it just has to manage the symlinks in my 
/etc/rc.d/init.d space. I already have all the tools to do this, I just 
want a consistent entry point.

m|monit already has the necessary machinery to extend it to be very 
useful in this case. For my test environments, which I actually run and 
develop on, I've exceeded my screen size to window number ratio. I can 
no longer have a window for each machine I have to personally manage fit 
on one desktop and be readable/useful. Thus, it's time to implement a 
solution which no longer requires me to be logged into the machines. 8-)

From a security standpoint, if you don't have the directive, it 
wouldn't be enabled. 8-)

Martin Pala wrote:
> We've been thinking about almost the same functionality for managing 
> monit upgrades from m/monit.
>
> M/Monit can have repository of various monit binaries (various 
> versions and platforms) and it could be easily to centrally manage 
> monit agents from M/Monit this way (upgrade monit with one click).
>
> There is also security aspect of the possibility to replace the binary 
> on server (whether monit or different application) has to be 
> super-safe otherwise it could be security risk. It should be possible 
> to disable it at compile time and it should be disabled by default 
> plus good documentation and explanation of security related issues 
> needs to be added.
>
> If you want to work on this functionality for monit, it could be 
> interesting :)
>
>
> Thanks :)
> Martin
>
>
>
> rory wrote:
> > I'm implementing a feature locally, and was wondering what the 
> > reaction would be for me to implement it in the main source.
> >
> > I'm planning on using m|monit and monit as a service console for our 
> > production service. Besides just stop/start/monitor, I also want to 
> > use it to trigger updates of the running service. To do so, I plan on 
> > adding an action to monit that would let me execute a script. Note 
> > that this is not the same as execute script on alert, this is on the 
> > same level as start/stop/etc.
> >
> > So, is anyone in favor of me putting it into the main source, or 
> > should I just maintain it separately?
> >
> >
> > _______________________________________________
> > monit-dev mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/monit-dev
>
>
> _______________________________________________
> monit-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/monit-dev