monit-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: monit ./gc.c ./monit_http.c ./monitor.h ./p.y ....


From: Jan-Henrik Haukeland
Subject: Re: monit ./gc.c ./monit_http.c ./monitor.h ./p.y ....
Date: Fri, 03 Oct 2003 09:02:50 +0200
User-agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Reasonable Discussion, linux)

Christian Hopp <address@hidden> writes:

> But if monit doesn't have a cleartext password, it can't be sent to
> the server.  The server side to big deal... the client side is the
> problem!

[1] Yes, you are right. This means that we must at least have one
clear text password in monitrc which the monit client can send to the
monit daemon in the same way a browser is sending clear text
passwords.  (Preferably this clear text password should be in monitrc,
since we already have implemented access and user restrictions to this
file).

> But then you have to maintain the passwords by hand... using htpasswd
> you can iuse apache's htpasswd program to do the dirty work
> (encrypting...).

I see the point and it's a good point.

>> What I originally thought this feature meant, (obviously I
>> misunderstood and I must admitt, I didn't think much about it
>> either) was that you could limit access to some pages in monit
>> similar to something like this in apache:
>>
>> AuthUserFile /../.htpasswd
>> <Limit GET POST>
>>         require valid-user
>> ..
>
> Aehm... you mean .htaccess?

Well not exactly .htaccess but the same access functionality, but
written for instance in .monitrc.

> The htaccess stuff is comparably little code.  Just the hook to
> "ALLOW" and a simple parser for "colon separated" username/passwd
> entries.

You mean something ala: ALLOW hauk:password:/path

Yes, it was something like that I had in mind. It could be easy to
implement for passwords in .monitrc but not for passwords in .htpasswd
since this file only has user:passwd.

> As long as it's still cleartext it might be kinda bogus but as soon
> it might contain crypt/md5 passwords it's more handy to have
> htpasswd to maintain the passwords.

Maybe, but it could be a bit confusing for a user, since he cannot use
htpasswd exclusivly but must have at least one clear text password in
.monitrc because of [1] above and you must do some trick in monitrc to
allow path access restrictions for users mentioned in the htpasswd
file (maybe path access restriction is not so important?). Anyway, if
you write a good documentation for this feature, it's probably not
going to be a problem? :)

-- 
Jan-Henrik Haukeland




reply via email to

[Prev in Thread] Current Thread [Next in Thread]