Michael, > after the new log system is now ready and Peter will take a look at the > LDAP stuff in the future I can start the next major step towards 1.0 - > the dataexchange rewrite.
Great stuff ! > We decided to put it in the database so I have two major ideas. First > there should only be one PKI-wide configfile and second the database > tables. One config file is good. So it will be configured on the CA and the dataexchange will pass the XML config file to the nodes (yes ?). > If it is possible then we should make the solution as simple and > robust as possible. Here now my idea: > > 1. dataexchange.xml > > openca ::= tree > tree ::= node+ > node ::= id . tree* . receive* . upload* > id ::= normale module id > download ::= dataexchange objecttype and status (e.g. APPROVED_REQUEST) > upload ::= dataexchange objecttype and status > > The important thing is that we can calculate the datatypes which must be > enrolled or received from the children of a node. This config file > should always be enrolled. This guarantees that all nodes have the > correct behaviour in the infrastructure because every node has the full > overview. That looks good to me. Much the same as the current config, but managed centrally. cool. > 2. database > > I think about the following: > > - key (a simple serial from a generator) > - objecttype > - objectstatus > - objectkey > - received (textkey) > - upload (textkey) > - downloaded (textkey) > - enroll (textkey with length equals number of possible nodes divided by > four) I am confused by the last field, I don't understand the textkey length stuff. > The idea is that the commits are bitstrings which contain the same > information like our todays log files of the dataexchange. Bit 18 > contains a true or false for module id 18. So this bit string says which node has received the object, yes ? > The advantage is that there > is only one row for every object and we can scan the different textkeys > very fast. Cool. So would this table (or set of tables) be updated each time the dataexchange file is received. > If we want a more clean design which is perhaps a little bit slower then > we need one table with the object infos and one table with the fields > key (foreign key to object table) and module. The status or the > direction are not required because there can only be two states between > two nodes and these states can be simulated to be in the database or not > (means successfully synchronized or not in the database). I like the idea of a clean design, even if it means a little sacrifice in performance. I still don't quite understand the full picture... is there any chance of an example in words, i.e. CA enrols, query on CA database, all records extracted to an SQL file (?), file tarred (and compressed) with config file, sent to nodes... Chris... ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ OpenCA-Devel mailing list OpenCA-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openca-devel
