Eclipse Warning Scan of recent patch
by John Magne
CFU:
Attached a patch that has the fixes to clean up some simple warnings in your original patch using Eclipse.
Ignore the modification to .classpath. I did that just to compile on my box.
CFU, the attached patch can be applied on top of yours if you wish to view the results.
Everyone:
I found a warning in one of the files in some code that got moved from one file
to another. The warning was there originally.
The warning is now in file : CryptoUtil.java
if (compare(keys[i].getUniqueID(), id)) {
getUniqueID was listed as deprecated. I wonder if we had dealt with this one before or decided to ignore?
It could be fixed if there is a suitable replacement. I haven not researched this.
11 years
Review of Standalone DRM/OCSP design
by Ade Lee
This is a review of the design at
http://pki.fedoraproject.org/wiki/Stand-alone_PKI_Subsystems
1. We should emphasize that standalone KRA is not expected to
communicate with any other CS subsystems (excepti for its clone).
2. Cloned subsystems (OCSP and DRM) do not generate new admin certs.
They use the one from the master.
3. Standalone DRM slated for 10.1 which is F20+. Standalone OCSP is
undetermined.
4. Changes to default.cfg:
a) you need variables to specify the location of the admin cert
CSR/cert.
b) You are also going to need variables for the external CA cert
and chain, so that you can import and trust it.
pki_external_ca_cert_chain_path=
pki_external_ca_cert_path=
5. As mentioned before, its very likely that not all the servlets listed
in web.xml will be needed. You'll have to look at the access log and
see what is actually called. In general, you want to choose REST
interfaces if available, followed by admin interfaces. Keep in mind
that as standalone systems are brand new, we can expect them to have the
latest interfaces.
Other than that, looks fine.
Ade
11 years
Testing on Fedora 20
by Ade Lee
Hi guys,
Sending to internal because there are some machine names here ...
I have been testing dogtag on fedora 20. There are a number of problems
right now, for which I am in the process of resolving and creating
patches.
In particular, resteasy has been upgraded to version 3.0.3., which
contains support for JAX_RS 2.0. JAX_RS 2.0 has a specification for
client side API as well as interceptors/filters. As a result, a number
of the calls we currently make have been changed or deprecated. I have
a patch to resolve this and allow us to build which I will post shortly.
There are also changes to the tomcat startup scripts. Having the dogtag
instance start up correctly will require changes to pkispawn, the
startup scripts and maybe others. Still working through those ...
In any case, all these changes will need to be checked into 10.1
eventually, and the build in F20 will need to be rebased to 10.1. At
ths point, though, in order to develop on 10.1, you will need to have a
fedora 20 machine.
We do need to do this rebase and make this switch sooner rather than
later so that we can shake out any f20 bugs. On the other hand, f20 is
not yet in alpha phase (should be there soon). To mitigate the
risk/delay in 10.1 development, we could:
1. Just make the switch. As soon as I can build and run pkispawn to
create a CA (and do basic tests) on F20, check in - and have everyone go
to F20.
2. Create a branch off master for continued 10.1 work for those who want
to continue on F18/F19, at least temporarily.
FWIW, I'm for option 1. It did not take too long for me to create an
F20 machine, and I have been able to run eclipse and compile there with
no problems.
Below are instructions on how I did it:
1. Create an F19 machine. In my case, I created a VM in the IDM lab
using the f19-developer-template. If you guys have not used the IDM
lab, I strongly recommend it.
2. Add the following file: /etc/yum.repos.d/rhel20.repo
[fedora20]
name=Fedora 20 - $basearch
failovermethod=priority
baseurl=http://download.fedoraproject.org/pub/fedora/linux/development/20...
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-20&arch...
enabled=1
#metadata_expire=7d
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch
[fedora20-debuginfo]
name=Fedora 20 - $basearch - Debug
failovermethod=priority
baseurl=http://download.fedoraproject.org/pub/fedora/linux/development/20...
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-debug-2...
enabled=0
metadata_expire=7d
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch
[fedora20-source]
name=Fedora 20 - Source
failovermethod=priority
baseurl=http://download.fedoraproject.org/pub/fedora/linux/development/20...
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-source-...
enabled=0
metadata_expire=7d
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch
3. yum install fedup
4. setenforce 0 --> prob not necessary, but thats how I had it. In
fact, I'd do all of this in permissive just to be safe.
5. fedup-cli --network 20 --instrepo fedora20
6. reboot
7. I needed to make sure I had the latest versions of selinux-policy,
selinux-policy-targeted and libsemanage. These are the latest ones in
koji (3.12.1-79) and libsemanage-2.1.10-9.fc20.x86_64. In my case, I
had to actually download them.
Comments?
Ade
11 years
Announcing the release of Dogtag 10.0.5
by Ade Lee
The Dogtag team is proud to announce the fifth errata build for
Dogtag 10.0.
Builds are available for Fedora 18 and Fedora 19 in the updates-testing
repositories. Please try them out and provide karma to move them to the
F18 and F19 stable repositories. Karma can be provided at
https://admin.fedoraproject.org/updates for each package.
== Build Versions ==
pki-core-10.0.5-1
pki-ra-10.0.5-1
pki-tps-10.0.5-1
dogtag-pki-10.0.5-1
dogtag-pki-theme-10.0.5-1
pki-console-10.0.5-1
== Highlights since Dogtag 10.0.4 ==
* Due to changes in systemd, restarting Dogtag 10 instances using
systemctl restart pki-tomcatd.target failed. Changes have been made to
the systemd startup configuration to ensure that this works correctly.
In addition, configuration has been added to require systemd to accept
an exit status of 143 (a correct exit status for the JVM) as valid, so
this exit value will no longer be reported in the system logs.
* Due to changes in the python-requests, a new exception (ProxyError)
was returned when attempting to connect to a server that is not yet
available. This affected pkispawn installation code when we wait for a
server to restart. The code has been modified to handle this (and
other) exceptions.
* In a case following a bad restart, the CS.cfg for an instance
appeared to be cleared or truncated. The code has been changed to not
write server status to the CS.cfg on startup, but rather to use an
in-memory variable.
* Fixed LDAP search filter code to no longer return certificates expired
for both reason 1 and reason 10 when searching only for reason 1.
== Detailed Changes since Dogtag 10.0.4 ==
alee (5):
#712 pki cert-find --revocationReason 1 finds certs expired for
reason 1 and reason 10
#714 CS.cfg cleared
#716 pki-tomcatd(a)pki-tomcat.service does not start when
pki-tomcatd.target is started
#717 Proxy error while getting status when spawning CA
#719 Incorrect value in CS,cfg for manager.ldif location
11 years
Re: [Pki-devel] [PATCH] 152 - catch all exceptions when checking status.
by Ade Lee
Ok - last take. this is better.
On Thu, 2013-09-05 at 23:10 -0400, Ade Lee wrote:
> phooey -- try attached patch.
>
> \On Thu, 2013-09-05 at 22:15 -0400, John Magne wrote:
> > I recompiled with your patch and reinstalled. My TPS install still failed here is the end of the trace:
> >
> >
> > 2013-09-05 19:09:34 pkispawn : INFO ....... executing 'systemctl restart pki-tomcatd(a)pki-tomcat.service'
> > 2013-09-05 19:09:36 pkispawn : DEBUG ........... No connection - server may still be down
> > 2013-09-05 19:09:36 pkispawn : DEBUG ....... Error Type: TypeError
> > 2013-09-05 19:09:36 pkispawn : DEBUG ....... Error Message: cannot concatenate 'str' and 'type' objects
> > 2013-09-05 19:09:36 pkispawn : DEBUG ....... File "/usr/sbin/pkispawn", line 373, in main
> > rv = instance.spawn(deployer)
> > File "/usr/lib/python2.7/site-packages/pki/server/deployment/scriptlets/configuration.py", line 98, in spawn
> > status = deployer.instance.wait_for_startup(60)
> > File "/usr/lib/python2.7/site-packages/pki/server/deployment/pkihelper.py", line 1062, in wait_for_startup
> > status = self.get_instance_status()
> > File "/usr/lib/python2.7/site-packages/pki/server/deployment/pkihelper.py", line 1054, in get_instance_status
> > config.pki_log.debug("No connection - exception thrown: " + sys.exc_info()[0],
> >
> >
> >
> > ----- Original Message -----
> > From: "Ade Lee" <alee(a)redhat.com>
> > To: "John Magne" <jmagne(a)redhat.com>
> > Sent: Thursday, September 5, 2013 6:30:21 PM
> > Subject: Re: Fwd: [Pki-devel] [PATCH] 152 - catch all exceptions when checking status.
> >
> > Looks like pylint 1.0 added some new warnings. I have fixed the
> > relevant code and added it to the patch.
> >
> > Please use this patch instead.
> > Ade
> >
> > On Thu, 2013-09-05 at 18:35 -0400, John Magne wrote:
> > > I forgot to add that I'm on F19.
> > >
> > >
> > > ----- Forwarded Message -----
> > > From: "John Magne" <jmagne(a)redhat.com>
> > > To: alee(a)redhat.com
> > > Sent: Thursday, September 5, 2013 3:20:58 PM
> > > Subject: Re: [Pki-devel] [PATCH] 152 - catch all exceptions when checking status.
> > >
> > > Hey Ade:
> > >
> > > I was working on this . After installing the patch I attempted to do a build of pki-core, but it
> > > rejected me big time. The pylint step was complaining about "Errors or Warning" and pointed me to some very long log file. Looks like there were no errors but some new warnings maybe? Can you take a look? I certainly want to actually compile and install/test this thing before giving it the full thumbs up.
> > >
> > > Attached is my endless pylinst log file.
> > >
> > > ----- Original Message -----
> > > From: "Ade Lee" <alee(a)redhat.com>
> > > To: pki-devel(a)redhat.com
> > > Sent: Thursday, September 5, 2013 2:09:03 PM
> > > Subject: [Pki-devel] [PATCH] 152 - catch all exceptions when checking status.
> > >
> > > Catch all exceptions when checking for status.
> > >
> > > python-requests now throws a ProxyError if the server is not yet up.
> > > Previously only connect exceptions were seen. To ensure that we are
> > > not broken again when python-requests and the underlying libraries are
> > > changed, we will catch and log all exceptions. If the connection
> > > ultimately fails, we will time out in any case.
> > >
> > > Ticket 717
> > >
> > > Please review.
> > >
> > > Thanks,
> > > Ade
> > >
> > > _______________________________________________
> > > Pki-devel mailing list
> > > Pki-devel(a)redhat.com
> > > https://www.redhat.com/mailman/listinfo/pki-devel
> >
>
11 years
[PATCH] 152 - catch all exceptions when checking status.
by Ade Lee
Catch all exceptions when checking for status.
python-requests now throws a ProxyError if the server is not yet up.
Previously only connect exceptions were seen. To ensure that we are
not broken again when python-requests and the underlying libraries are
changed, we will catch and log all exceptions. If the connection
ultimately fails, we will time out in any case.
Ticket 717
Please review.
Thanks,
Ade
11 years
