Hi, I recently committed several changes that ease life with OpenXPKI a bit.
Previous to r1567 an incorrect OpenXPKI configuration could lead to a nasty situation: if the configuration contained certain logical errors it was first parsed and persisted to the database. Then the system might detect that there is a problem and bail out during server start. Now, fixing the problem in XML did not really resolve the problem, because the errorneous configuration was already in the database and the system tried to reinstantiate it on every server start, resulting in a failure again. In such a situation the only remedy was to actually delete the incorrect configuration from the database (which involved digging through the log files in order to find out the culprit - and don't make a mistake and delete the wrong config...). Commit 1567 eases things in a way that incorrect configurations are simply ignored during server startup. They get logged in the OpenXPKI logfile to allow the administrator to clean up. Commit 1568 addresses a related problem: the system tries to reinstantiate the configuration that was active when a workflow was created. If a system administrator decides to delete a configuration from the database (for whatever reason) this results in Zombie workflows which cannot even be displayed, nor executed. This commit makes the system ignore this problem and fall back to the current configuration. (If we had a timestamp in the config table, it would possibly make more sense to pick the configuration whose "activation timestamp" is next after creation time of the WF. We don't have that, so we use the current config.) This admittedly introduces debatable side effects: a workflow could be in a state which is no longer contained in the current WF definition, or the WF graph may have changed in a way that would result in unexpected behavior of a WF instance. However, I decided that this is preferable to having a WF that cannot even be viewed. Moreover, having long running Workflows in the database (e. g. Passwordsafe WF) make it impossible to clean up the configuration backlog. Interestingly, falling back to a recent configuration not only bears the problem of possibly leaving a WF stranded, but it also helps resolving a problem with outdated configuration, such as system paths (path to executables), external resources (such as LDAP directory or credentials). We figured there are configuration portions one wants to be versioned, and others which should better be taken from the latest configuration. This issues will be addressed soon in a rather radical approach. Scott is working on this at the moment. Finally, some of my earler commits (r1560 - r1565) introduce better tracking of "custom attributes" as defined in the certificate profile. The commits add metadata entered by the user to the CERTIFICATE_ATTRIBUTES table. In addition it is now possible to search not only for subject and serial number, but for any combination of certificate attributes (primarily subject alternative names, but also these additional information). A combined search can now be entered via the "Search Certificate" menu. Cheers Martin ------------------------------------------------------------------------------ uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ OpenXPKI-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-users
