On Sun, Sep 26, 2010 at 3:05 PM, Vadym Chepkov <[email protected]> wrote: > > On Sep 26, 2010, at 1:28 PM, Serge Dubrouski wrote: > >> I've been thinking about changing pgsql RA that way for some time >> already. That's sounds absolutely logically. The problem though is >> that it changes current behavior and can potentially break current >> installations. So before I make any changes I;d like to hear opinion >> of other users of that RA, especially yours,. Hideo. Here is how I see >> it: >> >> 1. Implement OCF_RESKEY_monitor_user parameter. If it's set it'll be >> used for monitoring purposes. If it's not set the script will fall >> back to the current behavior and use pgdba user for monitoring to make >> it backward compatible with current installation. > > That what I would expect > >> >> 2. Implement OCF_RESKEY_monitor_password parameter. If it's script >> will check if OCF_RESKEY_monitor_user is set as well. If >> OCF_RESKEY_monitor_user is null script will fail with >> OCF_ERR_INSTALLED indicating configuration error, otherway password >> will be used for monitoring. > > .ocf-returncodes doesn't have good explanation when each return code should > be used, > why not OCF_ERR_CONFIGURED, just curious?
Don't know. Just want to be consistent. > >> >> 3. Implement OCF_RESKEY_monitor_script parameter. Currently pgsql runs >> generic "select now();" sql to check that PostgreSQL is alive. One >> could want to have more sophisticated monitoring that would include >> select of real data or something else. So if this parameter is set >> pgsql RA will use it for monitoring, otherway it'll use old generic >> "select now();" > > This part should depend on OCF_CHECK_LEVEL, imho. Nope. It's not like "do regular monitoring, but with request of OCF_CHECK_LEVEL=1 do deeper monitoring". It's same level of monitoring all the time but with a configurable SQL request. > > Vadym > >> >> On Sun, Sep 26, 2010 at 6:27 AM, Vadym Chepkov <[email protected]> wrote: >>> Hi, >>> >>> pgsql RA is using pgdba parameter for two different functions: as the owner >>> of the postmaster process and as a database userid for monitor operation. >>> If postmaster is configured to listen on a cluster IP for the later to work >>> I would have to allow remote login for the dba user without a password >>> (password is not one of the RA's parameters) - not a good idea. I think new >>> couple of parameters should be added: test_user and test_passwd (similar to >>> mysql agent) to separate operational and monitoring tasks. >>> >>> Thanks, >>> Vadym >>> _______________________________________________ >>> Linux-HA mailing list >>> [email protected] >>> http://lists.linux-ha.org/mailman/listinfo/linux-ha >>> See also: http://linux-ha.org/ReportingProblems >>> >> >> >> >> -- >> Serge Dubrouski. >> _______________________________________________ >> Linux-HA mailing list >> [email protected] >> http://lists.linux-ha.org/mailman/listinfo/linux-ha >> See also: http://linux-ha.org/ReportingProblems > > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems > -- Serge Dubrouski. _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
