Mailing List Archive

Mark Langkau wrote:

>Hi,
>
>Thanks for the new list!
>

Whoohoo! You scored first post ;)

>Here's a general question about changing connect strings for any
>database adapter. We are using DCOracle2 Beta4 (about to upgrade to Beta
>5).
>
>How would I go about programmatically changing the connect string in a
>database connection object? In our production environment, we change our
>database passwords on a regular basis. It will become a pain to change
>all of the hard coded user/password strings in the connection objects.
>(There may not be a large number to change - but *remembering* to change
>them, and to find all of them will become a maintenance issue ;-)
>
I'd suggest there are two ways to think about the problem:

1) the brute force way you envision -- paw through the ZODB looking for
connections and tweak them

or

2) Contemplate extending the connection object to allow for external
connection parameterization.

Doing (1) isn't actually very hard -- its a matter of firing up python,
importing Zope, and either doing a recursive search (which can take a
while) or going to known locations to adjust objects. The downside of
doing that is that it's highly nonportable. But the gist of it (after
you import Zope) is to get the application as the root object, and then
traverse from the root object -- e.g. if R is the Root, and you want
'/myapp/MyDB' you get R.myapp.MyDB. After getting the object, you
modify it, and usually set its _p_changed flag to 1, then call
get_transaction().commit() to save the changes.

Here's a simple example:

import Zope
app = Zope.app()
oracle = app.sql.baneOracle # folder called "sql" connection
object named "baneOracle"
oracle.connection_string = "scott/tiger"
oracle._p_changed = 1
get_transaction().commit()

However, inasmuch as thats not all that tricky, I'd like to think more
about trying to satisfy authentication externally.
Anybody got a preferred mechanism for this?

>
>It would be great to have an external script that would look for the
>connection object, and if it finds a match for a username (or other
>parameters to ensure we're looking at the right thing), then change the
>password. We could have a script that changes the actual database
>account info, then call the script that would make the same change in
>Zope.
>
>That's the high level concept. Is anyone doing something like this? If
>this sounds like a reasonable idea, I could make a recipe request at
>ZopeLabs.
>
>Thanks,
>Mark
>
>
>
>
>_______________________________________________
>Zope-DB mailing list
>Zope-DB@zope.org
>http://lists.zope.org/mailman/listinfo/zope-db
>

----- Original Message -----
From: "Mark Langkau" <mlangkau@execpc.com>
>
> How would I go about programmatically changing the connect string in a
> database connection object? In our production environment, we change our
> database passwords on a regular basis. It will become a pain to change
> all of the hard coded user/password strings in the connection objects.
> (There may not be a large number to change - but *remembering* to change
> them, and to find all of them will become a maintenance issue ;-)

hm... this might be solvable by using the Z Forwarding Database Adapter

http://www.zope.org/Members/shai/ZForwardingDA

has anyone used it and can share any experinces?

/dario

oh... Thank you for the new list !!! :-)

- --------------------------------------------------------------------
Dario Lopez-Kästen Systems Developer Chalmers Univ. of Technology
dario@ita.chalmers.se ICQ will yield no hits IT Systems & Services

Dario Lopez-Kästen wrote:

>----- Original Message -----
>From: "Mark Langkau" <mlangkau@execpc.com>
>
>>How would I go about programmatically changing the connect string in a
>>database connection object? In our production environment, we change our
>>database passwords on a regular basis. It will become a pain to change
>>all of the hard coded user/password strings in the connection objects.
>>(There may not be a large number to change - but *remembering* to change
>>them, and to find all of them will become a maintenance issue ;-)
>>
>
>hm... this might be solvable by using the Z Forwarding Database Adapter
>
>http://www.zope.org/Members/shai/ZForwardingDA
>
>has anyone used it and can share any experinces?
>
>/dario
>
>oh... Thank you for the new list !!! :-)
>
;)


[.This really ought to go on Zope-dev, since it doesnt relate to DBs
specifically but...]

One of the notions I've considered in the past is how Zope stores
configuration data; right now, there's little fiddly bits all over the
place that are activated/deactivated by various mechanisms, from
environment variables to file system probing, etc.

I tend to like the Netscape/Mozilla "prefs.js" -ish approach, being that
you have in some location a highly specialized 'configuration store'
which has all the tunes & knobs and so on in one place. Ideally, the
file should be easily editble with a text editor, so that leads me to
like formats as follows:

compound.variable = value
compound.variable = value

etc...

The notion is about the same as the Windows registry, etc. If, for
example one established a configuration line like

da.dco2.connectionString.mydb = "scott/tiger"

the adapter might be configured such to acquire that value, perhaps with
the leading prefix being known in advance, e.g. you'd only have to tie
the name "mydb" to the connection object, and "mydb" might implicitly be
the ID (name) of the connection object.

This does NOT address security concerns -- which would probably
complicate matters. If each configuration item required special
security on it to prevent accidental disclosure and/or modification, one
would probably have to envision a system of directives specifying each
branch of the configuration tree and the relevant keys, algorithms, and
other identifiers for a run-time system to be able to use them. For
example, it might require passing a password to Zope on startup so that
it can use that to unlock 'secured' configuration items. And then
there's the zope-ish scripting security concerns like "can I see your
configuration data when I shouldn't" which tend to make me Not Want To
Go There.

There are various internal policy decisions why Zope has no such
facility at this time, but this does not mean a discussion about
implementing such a control store is off-limits.