[PATCH] 57 Added classpath variable for JSS.
by Endi Sukma Dewata
The Eclipse classpath has been modified to use JSS_LIB variable
to avoid hard-coding the path to jss4.jar. The variable needs to
be specified in Preferences -> Java -> Build Path -> Classpath
Variables with this value:
* 32-bit: /usr/lib/jss
* 64-bit: /usr/lib64/jss
Ticket #171
--
Endi S. Dewata
11 years, 11 months
[PATCH] PKI Deployment Framework (20120523)
by Matthew Harmsen
This patch documents continued implementation of the PKI Deployment
Framework based upon the revised filesystem layout documented here:
* http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment#CA_.2F_KRA_.2F_...
The following patch adds/corrects functionality of the existing PKI
Deployment Framework including (but not limited to):
* Integration of Tomcat 7
* Addition of centralized 'pki-tomcatd' systemd functionality to the
PKI Deployment strategy
* Removal of 'pki_flavor' attribute
-- Matt
P. S. - I still need to perform a couple of tests to make certain that
this patch does not disrupt "pkicreate" installation/configuration prior
to checking this in.
11 years, 11 months
[PATCH] PKI Deployment Framework (20120518)
by Matthew Harmsen
This patch documents continued implementation of the PKI Deployment
Framework based upon the revised filesystem layout documented here:
* http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment#CA_.2F_KRA_.2F_...
The following patch adds/corrects functionality of the existing PKI
Deployment Framework including (but not limited to):
* Introduced concept of "admin-domain" originally as a
separate folder, and later incorporated this concept
into an optional instance prefix
* Revised definition of <pki_instance_id> to be identified
as "[<pki_admin_domain_name>-]<pki_instance_name>
* Changed NSS security database model from one shared
database by BOTH a single Tomcat AND single Apache instance
into one per Tomcat instance (shared by CA/KRA/OCSP/TKS) and
one per Apache instance (shared by RA/TPS)
* Altered Configuration 'scriptlet' to invoke Jython for
access to new Java configuration servlet
* Renamed various "scriptlets" to comply with this new layout
* Re-aligned code to account for revised layout documented at
http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment
-- Matt
11 years, 11 months
Request for better Dogtag 10 terminology . . .
by Matthew Harmsen
*PROBLEM:
*
Dogtag 10 is currently being designed with a new filesystem layout
for PKI instances and is currently looking for a more accurate and
descriptive terminology for its *"[instance]"* notation and its
re-definition of the term *"PKI Instance"*. (see
http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment#File_System_Dir...
and below for details)
*BACKGROUND:*
Prior to Dogtag 10, CA, KRA, OCSP, TKS (Tomcat5/Tomcat6), and RA,
TPS (Apache 2.2) subsystems all consisted of an individual "named"
instance of their web server. Each of these instances were often
generically referred to as a*"PKI instance"*. For example, a CA,
KRA, TKS, and TPS might have something similar to the following layout:
* /var/lib/pki-ca
* /var/lib/pki-kra
* /var/lib/pki-tks
* /var/lib/pki-tps
where each *"PKI Instance"* (named pki-ca, pki-kra, pki-tks, and
pki-tps) is a separate process each containing their own
collection of stand-alone NSS security databases.
With the pending release of Dogtag 10, the notion of a single *named
"PKI Instance"* has been introduced which no longer corresponds to a
single PKI subsystem, but rather to the following definition:
* consists of at least one of the following web server instances:
o one Tomcat 7 instance and/or
o one Apache 2.4 instance
* if a Tomcat 7 instance is being utilized, this process may
contain the following PKI subsystem(s):
o one CA, and/or
o one KRA, and/or
o one OCSP, and/or
o one TKS
* similarly, if an Apache 2.4 instance is being utilized, this
process may contain the following PKI subsystem(s):
o one RA, and/or
o one TPS
For example, a CA, KRA, TKS and TPS might have something similar to
the following layout:
* /var/lib/pki/[instance]/tomcat/ca
* /var/lib/pki/[instance]/tomcat/kra
* /var/lib/pki/[instance]/tomcat/tks
* /var/lib/pki/[instance]/apache/tps
where the *[instance]* notation is replaced by a *named "PKI
Instance"* (e.g. - *'default'*):
* /var/lib/pki/default/tomcat/ca
* /var/lib/pki/default/tomcat/kra
* /var/lib/pki/default/tomcat/tks
* /var/lib/pki/default/apache/tps
Within this *"PKI Instance"* named *'default'*, the CA, KRA, and TKS
constitute a single instance of Tomcat, TPS constitutes a single
instance of Apache, and all four PKI subsystems share a single
common collection of NSS security databases on a *named "PKI
Instance"* basis.
Note that this design allows future deployments to be similar to
currently existing deployments, by merely creating more than one
*named "PKI Instance"* on a single system, which in turn allows for
the continued existence of multiple types of the same PKI subsystems
on a single host (e. g. - two CAs and a KRA).
*REQUEST FOR SUGGESTIONS:*
As initially stated, we would like to replace the *"[instance]"*
notation and *"PKI instance"* terminology currently used within
Dogtag 10 with something that is more descriptive and more
accurate. While several alternatives have already been suggested,
none have gained wide-spread acceptance:
* cluster (concerns about other non-PKI uses of this term)
* domain (potential confusion with the notion of PKI security domain)
* realm (potential conflict with the Tomcat concept)
* crypt (a "play" on words which humorously attempts to describe
these PKI subsystems as a collection of cryptographic services)
* collection (concerns about other non-PKI uses of this term)
* group (potentially over-used term)
* bucket
* family
* pod
In any event, whatever this terminology turns out to be, a *"PKI
Instance" *will still need to be implemented as a "named" entity (e.
g. - *'default'*).
11 years, 11 months
Future availability of Jython 2.5 (and/or preferably Jython 2.7) in Fedora?
by Matthew Harmsen
Alexander, David, and John,
I am a developer on the Dogtag project (see
http://pki.fedoraproject.org/wiki/Dogtag) and am currently one of the
engineers that are re-writing the installation/configuration framework
in Python 2.7. Since a large part of Dogtag 10 is written in Java 1.7,
we are currently using the existing "Jython 2.2" that exists in Fedora
16/17 as a bridge to a new Java configuration servlet (Python 2.7 -->
Jython 2.2 --> Java 1.7).
I have recently seen on the web that a project has been funded for the
creation of Jython 2.7 (see http://en.wikipedia.org/wiki/Jython) which
would allow us to potentially run our Python 2.7
installation/configuration code as a single Jython 2.7 process, instead.
I am writing to you regarding the current availability of "Jython 2.2"
in Fedora, and would like to inquire about the potential future
availability of "Jython 2.7" in Fedora (or even "jython 2.5" since it at
least contains the "logging" mechanism).
Are any of you aware of any plans in Fedora to move from Jython 2.2 to
Jython 2.7 once it becomes available?
If so, would any of you be aware of any timeframe for adoption by Fedora?
Thanks in advance,
-- Matt
P. S. - Please include "pki-devel(a)redhat.com" in any replies to this
message.
11 years, 11 months
0001-Provide-CA-EE-Restful-interface-and-test-client.patch
by John Magne
Provide CA EE Restful interface and test client.
Tickets #144 and #145
Providing the following:
1. Simple EE restful interface for certificates, printing, listing and searching.
2. Simple EE restful interface for certificate enrollment requests.
3. Simple EE restful interface for profiles and profile properties.
4. Simple Test client to exercise the functionality.
5. Created restful client base class inherited by CARestClient and DRMRestClient.
6. Provide simple restful implementations of new interfaces added.
ToDO: Need some more refactoring to base classes for some of the new classes which are similar to classes
in the DRM restful area.
ToDO: Actual certificate enrollment code that will be refactored from existing ProfileSubmitServlet.
11 years, 11 months
