PKI-Silent can't tell if this is success or failure
by Adam Young
I've been crafting a PKI Silent call from the command line, and reading
the various responses to see what I got wrong. Below is the end of the
output from my last call. Is this "Success"?
#############################################
Attempting to connect to: ayoung.boston.devel.redhat.com:8443
Connected.
Posting Query =
https://ayoung.boston.devel.redhat.com:8443//ca/admin/console/config/wiza...
RESPONSE STATUS: HTTP/1.1 200 OK
RESPONSE HEADER: Server: Apache-Coyote/1.1
RESPONSE HEADER: Content-Type: application/xml;charset=UTF-8
RESPONSE HEADER: Date: Wed, 30 Nov 2011 03:41:18 GMT
RESPONSE HEADER: Connection: close
<?xml version="1.0" encoding="UTF-8"?>
<!-- BEGIN COPYRIGHT BLOCK
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; version 2 of the License.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along
with this program; if not, write to the Free Software Foundation,
Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
Copyright (C) 2007 Red Hat, Inc.
All rights reserved.
END COPYRIGHT BLOCK -->
<response>
<panel>admin/console/config/savepkcs12panel.vm</panel>
<res/>
<subsystemtype>ca</subsystemtype>
<showApplyButton/>
<updateStatus>success</updateStatus>
<errorString/>
<size>19</size>
<title>Save Keys and Certificates</title>
<panels>
<Vector>
<Panel>
<Id>welcome</Id>
<Name>Welcome</Name>
</Panel>
<Panel>
<Id>module</Id>
<Name>Key Store</Name>
</Panel>
<Panel>
<Id>confighsmlogin</Id>
<Name>ConfigHSMLogin</Name>
</Panel>
<Panel>
<Id>securitydomain</Id>
<Name>Security Domain</Name>
</Panel>
<Panel>
<Id>securitydomain</Id>
<Name>Display Certificate Chain</Name>
</Panel>
<Panel>
<Id>subsystem</Id>
<Name>Subsystem Type</Name>
</Panel>
<Panel>
<Id>clone</Id>
<Name>Display Certificate Chain</Name>
</Panel>
<Panel>
<Id>restorekeys</Id>
<Name>Import Keys and Certificates</Name>
</Panel>
<Panel>
<Id>cahierarchy</Id>
<Name>PKI Hierarchy</Name>
</Panel>
<Panel>
<Id>database</Id>
<Name>Internal Database</Name>
</Panel>
<Panel>
<Id>size</Id>
<Name>Key Pairs</Name>
</Panel>
<Panel>
<Id>subjectname</Id>
<Name>Subject Names</Name>
</Panel>
<Panel>
<Id>certrequest</Id>
<Name>Requests and Certificates</Name>
</Panel>
<Panel>
<Id>backupkeys</Id>
<Name>Export Keys and Certificates</Name>
</Panel>
<Panel>
<Id>savepk12</Id>
<Name>Save Keys and Certificates</Name>
</Panel>
<Panel>
<Id>importcachain</Id>
<Name>Import CA's Certificate Chain</Name>
</Panel>
<Panel>
<Id>admin</Id>
<Name>Administrator</Name>
</Panel>
<Panel>
<Id>importadmincert</Id>
<Name>Import Administrator's Certificate</Name>
</Panel>
<Panel>
<Id>done</Id>
<Name>Done</Name>
</Panel>
</Vector>
</panels>
<name>CA Setup Wizard</name>
<p>14</p>
<req/>
<panelname>savepk12</panelname>
</response>
#############################################
Attempting to connect to: ayoung.boston.devel.redhat.com:8443
Connected.
Posting Query =
https://ayoung.boston.devel.redhat.com:8443//ca/admin/console/config/save...
RESPONSE STATUS: HTTP/1.1 200 OK
RESPONSE HEADER: Server: Apache-Coyote/1.1
RESPONSE HEADER: Content-Type: application/x-pkcs12
RESPONSE HEADER: Date: Wed, 30 Nov 2011 03:41:19 GMT
RESPONSE HEADER: Connection: close
ERROR: ConfigureCA: BackupPanel() failure
ERROR: unable to create CA
#######################################################################
12 years, 5 months
PKI 'svn' tags and branches to be exposed in 'git' . . .
by Matthew Harmsen
Please expose the following 'svn' branches in the 'git' repository:
remotes/svn/trunk
remotes/svn/DOGTAG_9_BRANCH
remotes/svn/IPA_v2_RHEL_6_ERRATA_BRANCH
Due to a concern that the RHCS 8.x 'svn' repositories use an
*ant/autoconf* build system that relies
on the 'overlay' of a separate 'svn' repository as well as making heavy
use of the 'svn' externals properties,
it may be best if the RHCS 8.x series of branches remain primarily
located in their 'svn' repositories.
However, for experimental purposes, please also currently expose the
following 'svn' branches in the 'git' repository as discussed:
remotes/svn/PKI_8_0_ERRATA_BRANCH
remotes/svn/PKI_8_1_ERRATA_BRANCH
remotes/svn/PKI_8_BRANCH
Finally, when the final 'git' repository is created, please also expose
the following 'svn' tags:
remotes/svn/tags/DOGTAG_9_0_FEDORA_15_16_17_20111028
remotes/svn/tags/IPA_v2_RHEL_6_2_20111003
and, depending upon the success of the experiment alluded to above, the
following 'svn' tags:
remotes/svn/tags/PKI_8_0_RTM_20090720
remotes/svn/tags/PKI_8_1_RC_1_20111103
12 years, 5 months
Automatic reformatting and code style
by Ade Lee
Hi all,
It has been decided that the code should go through an automatic
reformatting on the trunk to ensure that everything matches the
project's coding standards.
Prior to this, we need to review the coding standards and confirm that
they are what we want to use.
The current coding standards for the project are referenced here:
http://pki.fedoraproject.org/wiki/PKI_C_Coding_Style
http://pki.fedoraproject.org/wiki/PKI_Java_Coding_Style
Some alternative styles:
http://freeipa.org/page/Coding_Style (C)
http://www.oracle.com/technetwork/java/codeconvtoc-136057.html (java,
sun conventions)
We should focus on the java coding style first, followed by C. Most of
the Perl code is mostly going away most likely, so no need to focus on
that.
IPA has a style guide for python, which, unless we have another
compelling reason, we should probably use that:
http://freeipa.org/page/Python_Coding_Style
We'd like to get this resolved soon - so as not to obscure any future
changes as we do new development. So, please devote some attention to
this soon.
Thanks,
Ade
12 years, 5 months
Git repo in testing mode
by Adam Young
We have a Git Repo up on Fedorahosted. We are still testing it out,
but we've imported the Git tree into it.
As of now there are only two remote branches exposed. The others are
there, but due to the way SVN m,aps to git, we are concerned that
exposing more will significantly bloat the git checkouts.
http://git.fedorahosted.org/git/?p=pki.git;a=summary
If you are a member of the gitpki group, you can checkout out using
ssh, and should be able to commit:
git clone ssh://$USERNAME@git.fedorahosted.org/git/pki.git
Read only access is available via the git protocol or the http protocol
from the links on the page above.
Question: do we want to move the 8 Series work into this repository as
well?
12 years, 5 months
Fwd: Re: [freeipa] #1353: Explore how to use authentiucation tokens instead of a DM password saved into a file for connecting to CS instances
by Adam Young
This ticket is/was assigned to me. It is something that we should solve
for PKI in general.
Insteado of binding to the DS using UID/password, we should use a
certificate stored in the local NSS database inside the Tomcat instance.
-------- Original Message --------
Subject: Re: [freeipa] #1353: Explore how to use authentiucation tokens
instead of a DM password saved into a file for connecting to CS instances
Date: Tue, 22 Nov 2011 16:05:12 -0000
From: freeipa <freeipa(a)fedorahosted.org>
Reply-To: nobody(a)fedoraproject.org
To: undisclosed-recipients:;
#1353: Explore how to use authentiucation tokens instead of a DM password saved
into a file for connecting to CS instances
----------------------+-----------------------------------------------------
Reporter: simo | Owner: admiyo
Type: defect | Status: new
Priority: major | Milestone: 3.1 Backlog
Component: IPA | Version:
Resolution: | Keywords:
Tests: 0 | Testsupdated: 0
Affects_cli: 0 | Candidate_to_defer: 0
Affects_doc: 0 | Estimate:
On_review: 0 |
----------------------+-----------------------------------------------------
Changes (by dpal):
* priority: critical => major
--
Ticket URL:<https://fedorahosted.org/freeipa/ticket/1353#comment:8>
freeipa<http://freeipa.org>
FreeIPA
12 years, 5 months
Is clone method broken on /PropConfigStore?
by Adam Young
I've come across a piece of code resistant to the Type safety cleanup,
and I suspectthat it is broken, and we are lucky that it is never blown up.
CMS.init calls DBSubsystem.init() which calls PropConfigStore.clone().
So this code path is executed.
In the file:
http://svn.fedorahosted.org/svn/pki/trunk/pki/base/common/src/com/netscap...
the clone method calls
Enumeration subs = getSubStoreNames();
while (subs.hasMoreElements()) {
IConfigStore sub = (IConfigStore)
subs.nextElement();
So the collection returned is expected to be filled with instances that
implement IConfigStore. However, looking at getSubStoreNames:
String pname = (String) e.nextElement();
int i = pname.indexOf('.'); // substores have "."
if (i != -1) {
String n = pname.substring(0, i);
if (!v.contains(n)) {
v.addElement(n);
}
}
}
return v.elements();
It is definitely filling the collection with Strings. My only guess is
that the collection used does not have any of the paths joined with a
dot, so the returned collection is empty.
SVN shows this code was checked in this way during the initial import.
I'm guessing noone here has touched it.
I'm planning on changing it like this:
- Enumeration subs = getSubStoreNames();
+ Enumeration<String> subs = getSubStoreNames();
while (subs.hasMoreElements()) {
- IConfigStore sub = (IConfigStore)
- subs.nextElement();
+ String subName = subs.nextElement();
+
+ IConfigStore sub = (IConfigStore)getSubStore(subName);
If anyone objects, speak up now.
12 years, 5 months
POM deps for Jersey
by Adam Young
I first ran the maven Archtype for a Jersey web app and then compiled
it. Both before starting and In between the two steps I wiped out my
local Maven repository to be able to distinguish waht was necessary.
Here are the list of jars pulled down in the second stage.
javax/ws/rs/jsr311-api/0.8/jsr311-api-0.8.jar
junit/junit/3.8.1/junit-3.8.1.jar
commons-cli/commons-cli/1.0/commons-cli-1.0.jar
org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.jar
org/codehaus/mojo/tomcat-maven-plugin/1.1/tomcat-maven-plugin-1.1.jar
org/codehaus/plexus/plexus-interpolation/1.13/plexus-interpolation-1.13.jar
org/codehaus/plexus/plexus-utils/2.0.5/plexus-utils-2.0.5.jar
org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar
org/codehaus/plexus/plexus-compiler-api/1.8.1/plexus-compiler-api-1.8.1.jar
org/codehaus/plexus/plexus-compiler-javac/1.8.1/plexus-compiler-javac-1.8.1.jar
org/codehaus/plexus/plexus-compiler-manager/1.8.1/plexus-compiler-manager-1.8.1.jar
org/apache/maven/doxia/doxia-sink-api/1.0-alpha-7/doxia-sink-api-1.0-alpha-7.jar
org/apache/maven/shared/maven-filtering/1.0-beta-4/maven-filtering-1.0-beta-4.jar
org/apache/maven/plugins/maven-compiler-plugin/2.3.2/maven-compiler-plugin-2.3.2.jar
org/apache/maven/plugins/maven-resources-plugin/2.4.3/maven-resources-plugin-2.4.3.jar
org/apache/maven/reporting/maven-reporting-api/2.0.6/maven-reporting-api-2.0.6.jar
asm/asm/3.1/asm-3.1.jar
com/sun/jersey/jersey/0.8-ea-SNAPSHOT/jersey-0.8-ea-SNAPSHOT.jar
I'm guessing these fall into two groups: those needed for building any
web app and those specific to Jersey. Maven is fairly well covered by
Fedora, so I don't think w'll have too much trouble there.
JUnit is in Fedora.
commons-cli is in fedora
jsr311 is probably just a small set of source file, but it is not in
Fedora.
Specific to Jersey are these: edited out of the Jersey POM
javax.ws.rs.jsr311-api version 0.8
javax.annotation.jsr250-api version 1.0
javax.persistence.persistence-api version 1.0.2
javax.servlet.servlet-api version 2.5
asm.asm version 3.1
NOte that does not indicated what is needed to build Jersey, merely
what it requires to build another project.
Pulling the Jersey source into Eclipse without and jars to fill in
dependencies is more interesting.
To build, it refers to a bunch of the Sun classes in the JREs rt.jar,
which have access prohibited. we can work around this with a symlink.
Other jars I started pulling in
<classpathentry kind="lib" path="/usr/share/java/javamail/mail.jar"/>
<classpathentry kind="lib" path="/usr/share/java/geronimo-annotation.jar"/>
<classpathentry kind="lib" path="/usr/share/java/objectweb-asm/asm.jar"/>
<classpathentry kind="lib" path="/usr/share/java/felix/org.osgi.core.jar"/>
<classpathentry kind="lib" path="rt.jar"/>
<classpathentry kind="lib" path="/usr/share/java/ant.jar"/>
<classpathentry kind="lib" path="/usr/share/java/jsp.jar"/>
<classpathentry kind="lib"
path="/usr/share/java/tomcat6/annotations-api.jar"/>
<classpathentry kind="lib" path="/usr/share/java/geronimo-ejb.jar"/>
<classpathentry kind="lib" path="/usr/share/java/atinject.jar"/>
<classpathentry kind="lib" path="/usr/share/java/geronimo-jpa.jar"/>
<classpathentry kind="lib"
path="/usr/share/java/tomcat-servlet-3.0-api.jar"/>
<classpathentry kind="lib" path="/usr/share/java/geronimo-interceptor.jar"/>
The only one I haven't found so far is
<classpathentry kind="lib"
path="/home/ayoung/.m2/repository/javax/enterprise/cdi-api/1.1.EDR1.1/cdi-api-1.1.EDR1.1.jar"/>
Which appears to be Weld, or the reference implementation of JSR-299.
This looks interesting in its own right.
12 years, 5 months
