<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><tt>The attached patch attempts to
address these issues and adds a patch for:<br>
</tt>
<ul>
<li><tt>TRAC Ticket #303 - Dogtag 10: CS.cfg parameters for
Dogtag 9 instance running under Dogtag 10 packages . . .</tt></li>
</ul>
<tt>With the addition of the patch above, I was able to simply
restart the server and it successfully started a Dogtag 9 CA
instance running under the Dogtag 10 packages.</tt><br>
<br>
On 08/24/12 07:54, Ade Lee wrote:<br>
</div>
<blockquote cite="mid:1345820060.2539.63.camel@aleeredhat.laptop"
type="cite">
<pre wrap="">Couple of comments:
1. We need to think about how to handle each of the cases you have
encountered. There are a number of cases where you simply warn and exit
rather than fixing the link. I think these are open for debate, but I
suggest the following:
missing link -> (currently) add the link (suggested) add the link
link pointing to wrong place --> (currently) error (suggested) fix the link
link pointing to non-existent target --> (currently) error (suggested) fix the link
link is actually a file -> (currently) warn (suggested) warn
link is a directory or otherwise -> (currently) error (suggested) error
2. This is perhaps a stylistic comment. You spend a large number of
lines defining variables that specify paths that ultimately only ever
get used within the same function. To me, this just makes the code
harder to read. Its a lot simpler (and has no loss in generality) to
see:
[jaxrs-api.jar]=/usr/share/java/resteasy/jaxrs-api.jar
instead of:
[jaxrs-api.jar]=${resteasy_java_dir}/jaxrs-api.jar
If I need to understand what a particular link is, I can see it directly
rather than having to hunt through figuring out what {resteasy_java_dir}
is, which in turn is defined in terms of {java_dir} ...
The only reason you might want to declare variables here would be for
arch dependent links.
Ade
On Wed, 2012-08-22 at 20:21 -0700, Matthew Harmsen wrote:
</pre>
<blockquote type="cite">
<pre wrap="">This patch addresses the issue listed below for Dogtag 10:
* TRAC Ticket #301 - Need to modify init scripts to verify
needed symlinks in an instance
This patch has been tested and found to work successfully on 64-bit
Fedora 17 with SElinux in "Permissive" mode:
* Built and installed Dogtag 9 Packages on a 64-bit Fedora 17
host
* Installed and configured Dogtag 9 CA instance
* Successfully submitted an enrollment request, approved
enrollment request, issued certificate, and listed
certificates
* Built and installed Dogtag 10 Packages on the same 64-bit
Fedora 17 host
* Restarted Dogtag 9 CA instance (so that it was now running
under Dogtag 10)
* Successfully submitted an enrollment request and listed
certificates
* Successfully approved the enrollment request and issued a
certificate AFTER:
* manually shutting down the CA instance,
* applying the CS.cfg fixes documented in "TRAC Ticket
#303 - Dogtag 10: CS.cfg parameters for Dogtag 9
instance running under Dogtag 10 packages . . .", and
* restarting the CA instance)
_______________________________________________
Pki-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pki-devel@redhat.com">Pki-devel@redhat.com</a>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pki-devel">https://www.redhat.com/mailman/listinfo/pki-devel</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>