Hi all,
Version: 1.16.9
CVS Tag: BRAT-1-16-9
I've updated the database access class
BrMainDb
BrCalibrationsDb
BrRunsDb
BrGeometriesDb
BrPassDb
to use a slightly different scheme when connecting. This was done in
realisation of the need to have the possiblity to disconenct from the
databases once the nessecary information has been retrived. The
problem is, that we may easily run out of avaliable connections to the
MySQL server (pre default max 100 conenctions) when the reconstruction
farm is running on full power (all nodes running 3 reconstruction
jobs), which is more than likely to happen for our second run period.
These changes will also affect existing user code. Before you
probably had something like
BrMainDb* mainDb = new BrMainDb("query", "", "pii3.brahms.bnl.gov",
"BrahmsMain");
mainDb->ConnectToCalib();
The excplicit CTOR is no longer possible, and access the main database
_must_ be done via a static instance of the BrMainDb class. This is
done by
BrMainDb* mainDb = BrMainDb::Instance();
mainDb->SetUserName("query");
mainDb->SetHostName("pii3.brahms.bnl.gov");
mainDb->SetDbName("BrahmsMain");
followed by an explicit request to connect to the databases. Note
that you may check the return value to be non-null so that you may
exit gracefully if database access isn't possible;
if (!mainDb->Connect())
return;
if (!mainDb->ConnectToCalib())
return;
Another imporatant change, is that it's no longer possible to
explicitly specify the password in the user code. This is - ofcourse
- a security consideration. Instead, I urge you to have a file
~/.bratdbrc with protection 0x600 (user read-write, nothing for anyone
else) containing lines like
<host> <db> <user> <password>
The first match on <host>, <db>, and if specified <user> is used to
resolve the password. If no match is found in that file or no such
file is present you'll be prompted for user name (if not given) and
password. To avoid this interactive prompting - which is not what you
want in a full batch environment like the farm - you need to have a
~/.bratdbrc file with the right permissions (0x600). Note that the
permission _must_ be 0x600. A file with other kinds of permissions is
_not_ used since that is liable to cause a security leak.
Ok, so I'm being a bit paranoid, but just consider what would happen
if some malicious young hudlum from the midwest with too much time on
his hands, or some overeager federal agent, likes to check what we
have in the database, and seeing all those encrypted data (yes, our
database is infact encrypted, though in a very VERY simple way) starts
deleting/filling up the databases - whupti, and BRAHMS is instantly
dead. Therefore - no explicit passwords in the code.
On another note:
There seems to be a bit of confussion as to what counts as a release
of BRAT, what corresponds to "pro" and "new" (obviously "old" is the
last "pro" version). Therefore I propose the following scheme:
* "new" alwasy refer to the latest tagged version of BRAT.
* "pro" refers to the latest revision of the previous minor version.
* "old" obviously refer to the last "pro" version.
As an example, suppose we have that the last tagged version of BRAT is
1.17.4, and the last revision of minor version of BRAT was 1.16.9, and
the lastest revision of the minor version 1.15 is 1.15.13, then we'd
have the following history and symbolic names:
CVS Tag | Version | Symbolic name
---------------+----------+----------
BRAT-1-17-4 | 1.17.4 | new
BRAT-1-17-3 | 1.17.3 |
BRAT-1-17-2 | 1.17.2 |
BRAT-1-17-1 | 1.17.1 |
BRAT-1-17-0 | 1.17.0 |
BRAT-1-16-9 | 1.16.9 | pro
BRAT-1-16-8 | 1.16.8 |
... | ... |
BRAT-1-16-0 | 1.16.0 |
BRAT-1-15-13 | 1.15.13 | old
Suppose now that we bump the revision number from 4 to 5, then we'll
have
CVS Tag | Version | Symbolic name
---------------+----------+----------
BRAT-1-17-5 | 1.17.5 | new
BRAT-1-17-4 | 1.17.4 |
... | ... |
BRAT-1-16-9 | 1.16.9 | pro
... | ... |
BRAT-1-15-13 | 1.15.13 | old
Suppose we bump the minor version number from 17 to 18, then we in
effect have said that the previous revision of minor version 1.17 is
stable and should be the new production code, and we start a new
development cycle with version 1.18:
CVS Tag | Version | Symbolic name
---------------+----------+----------
BRAT-1-18-0 | 1.18.0 | new
BRAT-1-17-5 | 1.17.5 | pro
... | ... |
BRAT-1-16-9 | 1.16.9 | old
... | ... |
BRAT-1-15-13 | 1.15.13 |
Ofcourse the CVS head (wether it is tagged or not) is the development
version. This is, by the way, how the ROOT version numbering works.
Yours,
Christian -----------------------------------------------------------
Holm Christensen Phone: (+45) 35 35 96 91
Sankt Hansgade 23, 1. th. Office: (+45) 353 25 305
DK-2200 Copenhagen N Web: www.nbi.dk/~cholm
Denmark Email: cholm@nbi.dk
This archive was generated by hypermail 2b29 : Mon Jun 18 2001 - 07:09:55 EDT