[R-sig-DB] RMySQL release candidate 0-7.0
Paul Gilbert
pg||bert @end|ng |rom b@nk-b@nque-c@n@d@@c@
Tue Nov 18 23:36:05 CET 2008
Uwe Ligges wrote:
>
>
> Paul Gilbert wrote:
>
>>
>>
>> Prof Brian Ripley wrote:
>>
>>> On Mon, 17 Nov 2008, Paul Gilbert wrote:
>>>
>>>>
>>>>
>>>> Prof Brian Ripley wrote:
>>>>
>>>>> On Mon, 17 Nov 2008, Paul Gilbert wrote:
>>>>>
>>>>>> Dirk Eddelbuettel wrote:
>>>>>>
>>>>>>> On 16 November 2008 at 11:26, Prof Brian Ripley wrote:
>>>>>>> | 5) Uwe Ligges and I and Dirk Edelbuettel (as maintainer) have
>>>>>>> worked out a [ Almost: s/Edel/Eddel/ ]
>>>>>>>
>>>>>>> | way to have RPostgreSQL built on the main Windows package
>>>>>>> builder. We | could try to do the same here, but none of us are
>>>>>>> happy with distributing | a binary build that has no tests at all
>>>>>>> (as RMySQL runs no actual | examples). So can we please have a
>>>>>>> test suite? You will need to allow | the DBMS account, password
>>>>>>> and database name to be set via environment | variables, as for
>>>>>>> RPostgreSQL.
>>>>>>>
>>>>>>> That was a leftover of me trying to get the Summer of Code whom I
>>>>>>> mentored
>>>>>>> for RPostgreSQL student to write 'test-driven' code. Which didn't
>>>>>>> work so
>>>>>>> well as he wrote code but few tests, but I ended up writing some
>>>>>>> tests for
>>>>>>> him. Kurt then had an issue with these tests running
>>>>>>> _un_conditionally and
>>>>>>> hence upsettting CRAN tests (that have no backend) so between
>>>>>>> Uwe, Brian and
>>>>>>> myself we came up with code where each file in tests/ starts as
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----------------------------------------------------------------------------
>>>>>>> if ((Sys.getenv("POSTGRES_USER") != "") &
>>>>>>> (Sys.getenv("POSTGRES_HOST") != "") &
>>>>>>> (Sys.getenv("POSTGRES_DATABASE") != "")) {
>>>>>>
>>>>>>
>>>>>> I've been setting this information in ~.pgpass (~/.my.cnf for
>>>>>> MySQL) in Linux and understood it could be set in Windows
>>>>>> %APPDATA%\postgresql\pgpass.conf and C:\my.cnf, although it may be
>>>>>> machine specific rather than user specific in Windows. I believe
>>>>>> setting this way is considered more secure, although security may
>>>>>> not be the concern for package tests. I assume this option was
>>>>>> considered. Is there a complication that makes it difficult?
>>>>>
>>>>>
>>>>> Yes, the DBMS account used for testing is not my own working account.
>>>>>
>>>>> I really don't see giving that having the settings in your file is
>>>>> any more secure: they are even in a known place. Note that I at
>>>>> least do not set a password this way.
>>>>
>>>>
>>>> I guess the important security question is about the password, so
>>>> how do you set the password for tests?
>>>
>>>
>>> Answering that is a security risk!
>>
>>
>> Just to be clear, I meant what method do you use for setting it, not,
>> what do you set it to. Is that considered a security risk in Windows?
>
>
>
> Folks, on the CRAN-Windows-Builder machine, the databases are just for
> the checks, no other data is stored and only connections from localhost
> are permitted, hence don't worry about passwords.
Ok, but the problem is that we also need to check packages on our own
systems, where passwords may be in force and the server may not be
localhost, so the mechanism in the tests/ files needs to allow different
possibilities. I can specify things with environment variables, in fact
I used that as the mechanism originally, but switched to the config
files because it seemed both easier and more secure, at least for MySQL
and PostgreSQL. (SQLite does not seem to bother with these details, and
I have not used Oracle yet.)
In either case it seems both approaches imply some setup on the testing
machine if tests are to be run rather than just be skipped. I think you
will agree we would prefer to avoid special setup, and I hope you agree
it would be better to run tests rather than skip them.
One way to avoid special setup is if some defaults work on the testing
machines. Then nothing special needs to be set. It would be especial
nice if the same defaults worked on different test platforms and for
different database back ends. Can defaults like
Sys.info()[["nodename"]]/"test"/Sys.info()[["user"]]/"" be used for
the host/db/user/passwd on the CRAN-Windows-Builder machine, and
other CRAN testing platforms? Another possibility for the default host
is "localhost", which is probably more secure since network access to
the db needs to be allowed if nodename is used.
However, there is still a problem of potential conflicts on database
"test" if parallel testing occurs. (I've had this problem already.) It
would be better if "test" were replaced by a pid specific db, but this
requires the userid to have database create rights. (And it is possible
this kind of mechanism will work better with environment varibles than
with the config files.)
To summarize:
1/ Are we trying to define a mechanism that usually runs the tests or
usually skips them? I don't like
if ((Sys.getenv("POSTGRES_USER") != "") &
(Sys.getenv("POSTGRES_HOST") != "") &
(Sys.getenv("POSTGRES_DATABASE") != "")) { tests }
because it will skip tests unless there is special setup done correctly,
so it does not catch mistakes well. My mechanism using the database
config files is not better, since it fails if the config file is not
set, so I would need to wrap the connection with try() and skip tests if
it fails. I think a mechanism like
if ((Sys.getenv("SKIP_POSTGRES") == "")) { tests }
would be better in this regard. It would also clearly separate the
mechanism for deciding if the tests should be run from the mechanism for
determining details like the userid.
2/ It would be nice if a similar mechanism worked for most database
backends and most packages. This suggest trying to use some standard
defaults with accounts enabled on the test machine databases (or at
least standard mechanisms for determining this information).
3/ It seems fairly important that tests/ files can run easily with the
same mechanism on package developers own systems, and that suggests a
preference for a fairly secure mechanism (especial for passwords).
4/ It would be nice if tests did not collide.
Best,
Paul
>
> Best,
> Uwe Ligges
>
>
>
>
>
>
>> Paul
>>
>>>
>>>>
>>>> Paul
>>>>
>>>>>
>>>>>>
>>>>>> Paul
>>>>>>
>>>>>>>
>>>>>>> ## try to load our module and abort if this fails
>>>>>>> stopifnot(require(RPostgreSQL))
>>>>>>>
>>>>>>> ## load the PostgresSQL driver
>>>>>>> drv <- dbDriver("PostgreSQL")
>>>>>>> ## can't print result as it contains process id which changes
>>>>>>> print(summary(drv))
>>>>>>>
>>>>>>> ## connect to the default db
>>>>>>> con <- dbConnect(drv,
>>>>>>> user=Sys.getenv("POSTGRES_USER"),
>>>>>>> password=Sys.getenv("POSTGRES_PASSWD"),
>>>>>>> host=Sys.getenv("POSTGRES_HOST"),
>>>>>>> dbname=Sys.getenv("POSTGRES_DATABASE"))
>>>>>>>
>>>>>>>
>>>>>>> # tests follow below ...
>>>>>>>
>>>>>>>
>>>>>>> -----------------------------------------------------------------------------
>>>>>>>
>>>>>>> which allowed Brian and Uwe to test on their end as well. The
>>>>>>> actual tests
>>>>>>> are creating (and the removing) tables and ensuring things come
>>>>>>> out as
>>>>>>> identical() and/or same class() as the input. I still need to
>>>>>>> add one for
>>>>>>> transaction management.
>>>>>>> | 6) I've put a version of the revised sources I used to test on
>>>>>>> Windows | (and with updated documentation and unused files
>>>>>>> removed) at
>>>>>>> | | http://www.stats.ox.ac.uk/pub/R/RMySQL_0.7-1.tar.gz
>>>>>>> | | I tested MySQL 5.0.67 on Windows and 5.0.45 on Linux, and I
>>>>>>> think these | days we should only support MySQL 5.
>>>>>>>
>>>>>>> As Debian maintainer for r-cran-rmysql I'd also be happy to test
>>>>>>> there.
>>>>>>>
>>>>>>> Dirk
>>>>>>>
>>>>>> ====================================================================================
>>>>>>
>>>>>> La version française suit le texte anglais.
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------------
>>>>>>
>>>>>> This email may contain privileged and/or confidential information,
>>>>>> and the Bank of
>>>>>> Canada does not waive any related rights. Any distribution, use,
>>>>>> or copying of this
>>>>>> email or the information it contains by other than the intended
>>>>>> recipient is
>>>>>> unauthorized. If you received this email in error please delete it
>>>>>> immediately from
>>>>>> your system and notify the sender promptly by email that you have
>>>>>> done so.
>>>>>> ------------------------------------------------------------------------------------
>>>>>>
>>>>>> Le présent courriel peut contenir de l'information privilégiée ou
>>>>>> confidentielle.
>>>>>> La Banque du Canada ne renonce pas aux droits qui s'y rapportent.
>>>>>> Toute diffusion,
>>>>>> utilisation ou copie de ce courriel ou des renseignements qu'il
>>>>>> contient par une
>>>>>> personne autre que le ou les destinataires désignés est interdite.
>>>>>> Si vous recevez
>>>>>> ce courriel par erreur, veuillez le supprimer immédiatement et
>>>>>> envoyer sans délai à
>>>>>> l'expéditeur un message électronique pour l'aviser que vous avez
>>>>>> éliminé de votre
>>>>>> ordinateur toute copie du courriel reçu.
>>>>>>
>>>>>
>>>> ====================================================================================
>>>>
>>>>
>>>> La version française suit le texte anglais.
>>>>
>>>> ------------------------------------------------------------------------------------
>>>>
>>>>
>>>> This email may contain privileged and/or confidential information,
>>>> and the Bank of
>>>> Canada does not waive any related rights. Any distribution, use, or
>>>> copying of this
>>>> email or the information it contains by other than the intended
>>>> recipient is
>>>> unauthorized. If you received this email in error please delete it
>>>> immediately from
>>>> your system and notify the sender promptly by email that you have
>>>> done so.
>>>> ------------------------------------------------------------------------------------
>>>>
>>>>
>>>> Le présent courriel peut contenir de l'information privilégiée ou
>>>> confidentielle.
>>>> La Banque du Canada ne renonce pas aux droits qui s'y rapportent.
>>>> Toute diffusion,
>>>> utilisation ou copie de ce courriel ou des renseignements qu'il
>>>> contient par une
>>>> personne autre que le ou les destinataires désignés est interdite.
>>>> Si vous recevez
>>>> ce courriel par erreur, veuillez le supprimer immédiatement et
>>>> envoyer sans délai à
>>>> l'expéditeur un message électronique pour l'aviser que vous avez
>>>> éliminé de votre
>>>> ordinateur toute copie du courriel reçu.
>>>>
>>>
>> ====================================================================================
>>
>>
>> La version française suit le texte anglais.
>>
>> ------------------------------------------------------------------------------------
>>
>>
>> This email may contain privileged and/or confidential information, and
>> the Bank of
>> Canada does not waive any related rights. Any distribution, use, or
>> copying of this
>> email or the information it contains by other than the intended
>> recipient is
>> unauthorized. If you received this email in error please delete it
>> immediately from
>> your system and notify the sender promptly by email that you have done
>> so.
>> ------------------------------------------------------------------------------------
>>
>>
>> Le présent courriel peut contenir de l'information privilégiée ou
>> confidentielle.
>> La Banque du Canada ne renonce pas aux droits qui s'y rapportent.
>> Toute diffusion,
>> utilisation ou copie de ce courriel ou des renseignements qu'il
>> contient par une
>> personne autre que le ou les destinataires désignés est interdite. Si
>> vous recevez
>> ce courriel par erreur, veuillez le supprimer immédiatement et envoyer
>> sans délai à
>> l'expéditeur un message électronique pour l'aviser que vous avez
>> éliminé de votre
>> ordinateur toute copie du courriel reçu.
>>
====================================================================================
La version française suit le texte anglais.
------------------------------------------------------------------------------------
This email may contain privileged and/or confidential in...{{dropped:26}}
More information about the R-sig-DB
mailing list