-----Original Message-----
From: Kulpinski, Dejan
Sent: Tuesday, October 08, 2002 10:01 AM
To: 'Michael Bell'
Subject: RE: [OpenCA-Devel] Re: [Openca-Users] Mail and import export
counters
As for storing the data outside of the database...
Aside from the temporary files (exports) you should really try to avoid storing data
outside of the database
itself, becuase that makes it much more dificult for day to day operations of the
OpenCA. Having a
database that contains all the data and the state of the OpenCA makes it much easier
to do backups and recovery. It is easier to control access to data as well. Remember I
am talking from the operations point of view here, since we operate an actual
production version of Certification Authority. I have seen and tested products that do
exactly that (such as SSH Certifier for example), where everything is stored and
encrypted in the database including CA Cert and its keys.
As for DBI vs. DB...
Do you plan to support DB in the future? I was very surprised to see somebody using
the Berkley DB in the first place. My suggestion would be to support only DBI. That
way you have much less work to do, and you can streamline your code to work well
efficiently with the relational database. The again, I might be biased...
As for export/import flags...
As I said you only need to track exports, since you can use serial numbers of
certificates/requests to see if they have been imported or not. Therefore you would
only need flags for the exports.
-----Original Message-----
From: Michael Bell [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 08, 2002 5:55 AM
To: [EMAIL PROTECTED]
Subject: Re: [OpenCA-Devel] Re: [Openca-Users] Mail and import export
counters
Kulpinski, Dejan wrote:
> I would just like to ask you that whatever strategy you
> guys come up with should allow me to import the
> certificates from the previous releases of openCA (like it does now).
We will not change the backupmechanism. So if we must change the
databasedesign (means: add a column) then you can use a backup to
restore the old state.
> 1) "Export new", where you would export all the new objects
> (cert, requests...). You can use the flag in the database to
> indicate what objects have already been exported.
The problem is that we cannot add flags without problems to the
databaseinterface of OpenCA. OpenCA::DBI is not a problem but OpenCA::DB
is a problem. Therefore I proposed the concept with the two directories.
If we use a flag then we have to think about the name. The database can
log exports via EXPORT_FLAG and the imports will be logged in a file
because it is not possible to log imports in the database because the
state of an object can change.
> 2) "Export range" where you would export objects in specified
> range (either by date or serial number). This should not be too
> complicated to do (at least GUI wise). Two textboxes where user
> can specify range of objects to export should do it.
This is trivial and not a big problem.
> Whatever you do, try to avoid storing the information about exports outside of the
>database itself.
Any reasons? It is at minimum a big problem for the imports.
> Then on import you have two choices in terms of design:
>
> 1) Reject duplicates
>
> 2) Allow duplicates that would result in updates rather then inserts.
Conflictmanagement later ... :)
Michael
--
-------------------------------------------------------------------
Michael Bell Email (private): [EMAIL PROTECTED]
Rechenzentrum - Datacenter Email: [EMAIL PROTECTED]
Humboldt-University of Berlin Tel.: +49 (0)30-2093 2482
Unter den Linden 6 Fax: +49 (0)30-2093 2959
10099 Berlin
Germany http://www.openca.org
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
OpenCA-Devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/openca-devel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
OpenCA-Devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/openca-devel
