[PATCH] PKI TRAC Ticket #899 - RFE - ipa-server should keep backup of CS.cfg
by Matthew Harmsen
Please review the attached patch for:
* PKI TRAC Ticket #899 - RFE - ipa-server should keep backup of CS.cfg
<https://fedorahosted.org/pki/ticket/899>
This patch is based upon a previously reviewed patch for the Dogtag 9
architecture utilized by the IPA_v2_RHEL_6_ERRATA_BRANCH, but was
modified and tested to work with the Dogtag 10.2 architecture.
CAVEAT 1:
Although this patch contains changes to multiple PKI subsystem's
'CS.cfg' configuration files, an upgrade script should not be
specifically required for legacy instances since the parameter that
is added, 'archive.configuration_file=true', is presumed even if the
parameter is missing (as it would be on any legacy instance). In
this case, it would only be necessary to add this parameter to a
legacy instance's CS.cfg, and set the value to 'false' in order to
turn off 'CS.cfg' configuration file archival (explicit instructions
detailing this are found in the 'operations' script). However, if
this is desired for completeness, I don't mind adding it.
CAVEAT 2:
I had originally made the effort to attempt to have specific crucial
WARNING messages echoed to the display as well as to the journal. I
believe that this would be beneficial, as, for example, it would
immediately notify an admin that since an error had occurred,
'CS.cfg' backups would be discontinued until the error was
corrected. My idea was to echo these WARNING messages explicitly to
stderr via redirecting them (>&2), and adding the parameter
'StandardError=journal+console' under the [Service] section of the
'pki-tomcatd(a)pki-tomcat.service' file. Unfortunately, I was never
able to make this work - both stdout and stderr messages were stored
in the journal, but were never displayed to the screen when typing
'systemctl restart pki-tomcatd(a)pki-tomcat.service' (even after a
'systemctl daemon-reload' had been performed).
-- Matt
10 years, 4 months
replication of new/modified profiles
by Fraser Tweedale
Hi all,
A requirement from the FreeIPA side is the ability to add and
customise CA profiles. Dogtag's current profile creation behaviour
writes the new profile to the filesystem beside the standard
profiles (as well as making the appropriate update to the registry,
etc.)
There does not seem to be a mechanism to distribute new/modified
profiles to replicas - though perhaps I have missed something.
Because this behaviour is required, unless I have overlooked
something or there is a better way (in which case please shout out),
I think it makes sense to begin a design proposal for an LDAP-based
profile store.
Finally, a brief mention of some tickets related to profile storage
that could be good to tackle simultaneously should the proposed
change go ahead:
- https://fedorahosted.org/pki/ticket/778
- https://fedorahosted.org/freeipa/ticket/4002
10 years, 4 months
[PATCH] 99 Fixes for trac tickets 1040 and 1041 (Related to refactoring python modules)
by Abhishek Koneru
Please review the attached patch with fixes for tickets 1040 and 1041.
Changes made:
-- Added dictionaries with mapping for python attribute names and
JSON attribute names received from the server.
-- Made changes to from_json methods in data classes to take care of
missing attributes in the JSON string. (#1040 - caused due to missing
attribute in the JSON value of the CertData object when tested by Endi).
-- Renamed kraclient module to kra. (#1041). updated import in
drmtest.py.
-- Removed the usage of properties in the some classes. The reverse
conversion of atribute names from _separated names to camelCase is done
using the name mapping dictionaries in the classes and a static method
added in CustomEncoder in the encoder module.
-- Fixed some issues in drmtest.py.
-- Updated the license string in the files.
Note: The following changes are limited to cert and key modules. Similar
changes will be made to profile module once it is completely checked in.
Tested the code by running cert and drmtest modules.
-- Abhishek
10 years, 4 months
Patch to swap numeric values of debug log levels OBNOXIOUS and INFO
by Matthew Harmsen
Please review the attached patch for:
* PKI TRAC Ticket #898 - Giant /var/log/pki-ca/debug
<https://fedorahosted.org/pki/ticket/898>
It is basically a copy of the patch that was applied to Bugzilla Bug
#1055080 - Giant /var/log/pki-ca/debug
<https://bugzilla.redhat.com/show_bug.cgi?id=1055080> except it
does*not* reset the CS.cfg 'debug.level=0' (log everything) to
'debug.level=10' (log information only) since Fedora platform's primary
usage is for development, and thus debug logs are used far more prevalently.
To test this patch:
* Build a default CA using the patched source
* Install the default CA using 'pkispawn'
* Examine the '/var/log/pki/pki-tomcat/ca/debug' file to reveal that
it contains much content (debug.level=0)
* Shutdown the CA
* Edit '/etc/pki/pki-tomcat/ca/CS.cfg' and change 'debug.level=0' (log
everything) to 'debug.level=10' (log information only)
* Empty the CA 'debug' log by typing 'cat /dev/null >
/var/log/pki/pki-tomcat/ca/debug'
* Restart the CA
* Examine the '/var/log/pki/pki-tomcat/ca/debug' file to reveal that
it contains minimal content (debug.level=10)
10 years, 4 months
[PATCH] 512 Fixed missing TPS activity attributes.
by Endi Sukma Dewata
The ActivityService has been fixed to return the missing TPS activity
attributes including IP, operation, result, and message. The TPS CLI
and UI has been fixed to display the activity date in UTC format.
Ticket #1050
--
Endi S. Dewata
10 years, 4 months
[PATCH] 511 Added ActivityDatabase.log().
by Endi Sukma Dewata
A new method has been added to log TPS activities. The method will
create a new activity record with ID generated from timestamp and
thread ID.
Ticket #1049
--
Endi S. Dewata
10 years, 4 months
[PATCH] 2-3 Copy ExtendedKeyUsage from signing request
by Fraser Tweedale
Hi all,
These patches implement support for copying the ExtendedKeyUsage
extension from a signing request to the certificate, addressing
https://fedorahosted.org/freeipa/ticket/2915.
My email from a few days ago goes into a bit more detail and puts
forward the question of whether this is even a reasonable approach
to solving #2915. Since I haven't yet received any feedback I
figured I'd go ahead and publish the patches.
Patch 0002:
Add appropriate ExtendedKeyUsage constraints to all profiles that
support this extension. To check that none were missed:
$ ag -l extendedKeyUsageExtDefaultImpl \
| xargs ag -L extendedKeyUsageExtConstraintImpl
Patch 0003:
The actual fix: EKU extension is copied from signing request, or the
default is used when the extension does not appear in the request.
10 years, 4 months