Ulf Wendel a écrit :
Hi,
How do you rate the importance of SSL for the new native MySQL driver
for OpenOffice.org:
- do you think 1%, 5%, 10%, 20% or even more users will want to add
extra security to their remote MySQL?
Only a very small percentage of baseline users IMHO, this is more of a
DBA wishful thinking thing :-)
- does remote MySQL mean "somewhere in the hostile internet" or does
it mean "somewhere in my (secured) intranet"?
both, but in the main via a secured connection to my internal network.
- do you think the SSL configuration is easier than a SSH tunnel?
Well to be honest, I'm more familiar with SSH than SSL, so I can't
really answer that question. In a corresponding postgres solution, we
have a remote client that connects via secure XML-RPC via SSL, but I'm
not familiar with how everything is cobbled together. However, this
particular application has nothing do directly with OOo.
- does your IT forbit non-secure remote connections?
Yes, absolutely. We don't compromise on that. When we were monosite, it
was not a problem, but now we have multiple sites across multiple
networks, which essentially means duplicating the database (and server
configs) across sites. We're looking at synchronisation/replication as
possible solutions, but that's more overhead.
To me it sounds a bit like a goodie. The initial focus should be on
getting out a working driver out at all. Basic query and connect
should work flawless. Once we have achieved that we can have a look at
SSL.
I would tend to agree. Better to have a (nearly) flawless driver than
one with those extra bells and whistles that are only required by a few
people. However, I don't know how corresponding solutions fare, for
example, does the current native postgres-sdbc driver allow this kind of
thing ? I must admit to not having looked into that aspect yet (the fact
that the postgres driver doesn't run on Mac is a problem for me there).
However, I'm new to OOo. I don't know much about the typical usage
scenarios and therefore I could be wrong.
Personally, I don't think you're wrong, but it is an important question
for us DBA's.
I have to administer a variety of mysql databases, most of which are
through secure connections over the internet into secure corporate
networks. Internally, the users are usually validated against the mysql
db via LDAP.
Building OOo forms for these usually requires the following :
Install a local copy of the db to my machine.
Build the form, save and test it locally. I save the form outside of the
ODB document.
Change the form to point to the identity and location of the remote
datasource (different passwords, different entry IDs, etc)
Copy the form to the remote file server.
Adjust the links on the remote workstations to point to the new form.
Register the corresponding ODB file with each workstation, which means
copying it to each workstation, otherwise the forms on the file server
lose their connection to the datasource. There is no way to share an ODB
stored on a file server and allow concurrent access to it. Things get
screwed up if you try that. This means that you have to write protect
the form, otherwise you get users answering "yes", to the OOo question :
"Changes have occurred in your document, do you want to save them ?" For
a user, it is totally illogical not to want to save what they have just
entered on their form and not save it.
Deal with OOo version behaviour mismatches (i.e. bugs). An example,
we've just rolled out Ubuntu Hardy for most of the workstations. It
comes with OOo 2.4 (Ubuntu packaged) - due to a bug (now fixed in either
2.4.1 or upcoming 3.0 I believe) dropdown lists of data obtained via SQL
queries on other tables stoppped working. In other words, a form I have
had for 4 years just stopped working - no kudos to the DBA (i.e. me)
from the users, in fact quite the opposite.
Most of these problems have nothing to do with mysql as such, but with
the way forms work in OOo 2.0, which unfortunately are not very network
aware.
As you can see, it would make my life a lot easier if I could just
connect remotely and securely to my mysql dbs and build my forms against
them.
Of course, there may be things that I should be doing with my forms that
I am not, but most of what has been built so far was by trial and error,
because, err, well, there have always been surprises ;-)
Alex
PS : sorry to all for the rather long winded explanation.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
