Re: [Netdisco] netdisco read-only server for pg9 hot standby

[Ingen S. J. v. (ICTS) <j.v...@ut...>]

Hi Ben,

On Sun, 2011-01-09 at 18:27 +1100, Ben Carbery wrote:
> Well I plunged ahead and gave it a go.Hot standby is up and running
> but am unable to log on on the standby server. This is the error in
> the postgres logs - first of many once this is patched no doubt:
> 
> 2011-01-09 18:07:08 ESTERROR:  cannot execute SELECT FOR UPDATE in a
> read-only transaction
> 2011-01-09 18:07:08 ESTSTATEMENT:
>                         SELECT a_session FROM sessions WHERE id = $1
> FOR UPDATE

Looks like the Apache::Session stuff. You could get rid of these by
changing the database config in netdisco_apache.conf. You could store
the session info in your other database, or perhaps use a different
backend for session storage.

> So far I've been unable to figure out what perl subroutine (?) is
> causing this but my general impression is that it may be a bit of a
> minefield trying to turn netdisco into a read-only server. 

It will be a bit of a minefield, but it's an interesting idea. We run a
couple of Netdisco instances and one of them might be better to run
read-only, so I'd be happy to work with you on this quest.

> Can any of the devs confirm whether or not this is worth trying to do?
> If netdisco fundamentally relies on session information being in the
> database and this can't be easily changed, then I am thinking not.. On
> the other hard the documentation seems to be point to session
> information being stored in a perl hash m->session, so is the sessions
> table that important?

Never dove into that, but I'm pretty certain that the session data
doesn't have to be in the same DB as the rest of Netdisco.

Next thing you'll probably hit is that the "users" table should be r/w
because every web logon will update the "last_on" timestamp for a user. 

Then the issue that the "admin" table needs to be r/w if you want to run
jobs via the frontend (eg discover, macsuck etc). On the other hand, a
read-only web interface should never submit jobs or change anything. If
you run it without any users having "port control" or "admin" rights,
this won't be an issue.

> By the way the background for this is that our netdisco users can't
> access the network that is allowed to 'snmp' the network, hence the
> separate servers.

I guess you could run the frontend and backend on different machines; as
long as the frontend can access the same DB that the backend is using
(and the users can access the frontend via HTTP(s)), that could work
too.

Perhaps that's easier to accomplish than to run the frontend against a
read-only copy of the DB... Also, you keep the possibility to submit
jobs through the web interface if you want.


Regards,

Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands