[isf-wifidog] Re: [wirelesstoronto-discuss] code contribution to
wifidog auth server
max.horvath at maxspot.de
Mar 15 Nov 19:25:43 EST 2005
>> as well, i made intrusive changes to include/schema_validate.php. i
>> wanted to use existing routines to check the status of the database.
>> however, i most emphatically did not want any changes made to the
>> database until the install script was ready. BUT that's just not how
>> schema_validate out of the box works. on a deeper level, i object to
>> running such application intrusive stuff from a user level account.
>> schema_validate assumes that the default postgres account for
>> wifidog is
>> a dba level account. that's a security thing. secondly, i don't
> It should not have any privileges except creating database.
>> the idea that database maintenance tasks show up on user's sessions.
>> these sorts of things should only be done by the "installer person",
>> regular users should not be abused with this kind of stuff on their
>> screens. I am hoping you will find these changes a useful thing.
> Well, I may be missing something, but I find what you propose
> dangerous. When you upgrade a live server, the schema update must
> happen as
> soon as the code is updated, no matter what.
> Otherwise, you have new code running that may or may not work with
> the old
> schema (and may even accidentally corrupt data in a way that will
> break the
> assumptions of the upgrade script). If you instead checkout in a
> (but with your real database) to have your schema update before
> update the
> code on the live server, you have the opposite problem: old code
> that may or may not be compatible with the new schema. That's why
> validate is always called (not just from the install script), and
> why the
> wifidog user must have table creation privileges.
Well, I gotta say, that I don't like the way schema_validate.php
works right now, either.
One big problem is that - as far as I can see - it adds one query per
page impression. Removing this one query could improve the
performance on a busy server very much.
I think we should implement a maintaince mode into WiFiDOG. An
administator could for example decide to upgrade the server at night.
So he disbales the server (users accessing the auth server would only
see a WiFiDOG page saying the server is in maintaince) and upgrades
all files. Then he runs an upgrade script. This upgrade script could
work like schema_valide.php. After the layout changes to the database
the administrator could disable maintaince mode and all operations
would resume without any failures.
What do think?
More information about the WiFiDog