KRA instance import depends on lib389 package, which is not always
installed and that results in failure. Furthermore, test_installation
utilizes krainstance import. This fix moves relevant parts from
krainstance to ipalib constants where those are subsequently imported
from.
Related: https://pagure.io/freeipa/issue/8795
Signed-off-by: Michal Polovka <mpolovka@redhat.com>
Reviewed-By: Michal Polovka <mpolovka@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
Reviewed-By: Tibor Dudlak <tdudlak@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Subordinate ids are now handled by a new plugin class and stored in
separate entries in the cn=subids,cn=accounts subtree.
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
New LDAP object class "ipaUserSubordinate" with four new fields:
- ipasubuidnumber / ipasubuidcount
- ipasubgidnumber / ipasgbuidcount
New self-service permission to add subids.
New command user-auto-subid to auto-assign subid
The code hard-codes counts to 65536, sets subgid equal to subuid, and
does not allow removal of subids. There is also a hack that emulates a
DNA plugin with step interval 65536 for testing.
Work around problem with older SSSD clients that fail with unknown
idrange type "ipa-local-subid", see: https://github.com/SSSD/sssd/issues/5571
Related: https://pagure.io/freeipa/issue/8361
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
The plugin `plugins` iterates over the keys of API instance,
__iter__ of which is a generator of class.__name__ from
(Command, Object, Method, Backend, Updater). So, the allowed type
is str, not bytes.
Fixes: https://pagure.io/freeipa/issue/8898
Signed-off-by: Stanislav Levin <slev@altlinux.org>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Simple version enforcement. A v1 certificate won't have the
extensions that are assumed available later during the validation
process.
https://pagure.io/freeipa/issue/8817
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Previously, `get_credentials` raises either ValueError or re-raises
GSSError. The former makes the handling of this function more difficult
without a good reason.
With this change:
- `get_credentials` no longer handles exceptions by itself, but delegates
this to the callers (which already process GSS errors).
- `get_credentials_if_valid` doesn't raise any expected exceptions, but
return valid credentials (on the moment of calling) or None. This makes
it consistent with docs.
Related: https://pagure.io/freeipa/issue/8873
Signed-off-by: Stanislav Levin <slev@altlinux.org>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
get_credentials() was changed to raise ValueError instead of
gssapi.exceptions.GSSError as part of the sweeper to clean up
expired credentials caches.
For WebUI users, this will prevent a 500 error if their
associated credentials cache is expired or missing.
https://pagure.io/freeipa/issue/8873
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Insert a class before LDAPClient to cache the return value
of get_entry() and certain exceptions (NotFound and
EmptyResult). The cache uses an OrderedDict for the cases
where a large cache might result an LRU model can be used.
The cache be enabled (default) or disabled using
ldap_cache=True/False.
This cache is per-request so is not expected to grow
particularly large except in the case of a large batch
command.
The key to the cache entry is the dn of the object
being requested.
Any write to or referencing a cached dn is evicted from
the cache.
The set of attributes is somewhat taken into consideration.
"*" does not always match everything being asked for by
a plugin so unless the requested set of attributes is a
direct subset of what is cached it will be re-fetched. Err
on the side of safety.
Despite this rather conserative approach to caching 29%
of queries are saved with ipatests/xmlrpc_tests/*
https://pagure.io/freeipa/issue/8798
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
The usage of the existing gssproxy service(`service/ipa-api`) leads
to undesirable for this case side effects such as auto renew of
expired credentials.
Fixes: https://pagure.io/freeipa/issue/8735
Signed-off-by: Stanislav Levin <slev@altlinux.org>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
pylint 2.7.0 now emits inconsistent-return-statements if one of
try/except statement is not returning explicitly while the other do.
Fixes: https://pagure.io/freeipa/issue/8720
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The dns parameter of request_and_wait_for_cert() must be a string of
hostnames.
* Enforce list/tuple type so that API misuse no longer passes silently.
* Add commonNameToSANDefaultImpl to KDCs_PKINIT_Certs profile
* Explicitly pass hostname for service certs
Fixes: https://pagure.io/freeipa/issue/8685
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
In order to simplify the build process between upstream FreeIPA
and downstream builds (such as CentOS Stream) we are changing
some file references from FreeIPA to IPA (and Identity Management).
https://pagure.io/freeipa/issue/8669
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
kwargs is redefined to set the `noextrawhitespace` parameter
from the Str class to `False`.
Fixes: https://pagure.io/freeipa/issue/7599
Signed-off-by: Antonio Torres Moríñigo <atorresm@protonmail.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
MIT Kerberos implements FAST negotiation as specified in RFC 6806
section 11. The implementation relies on the caller to provide a hint
whether FAST armoring must be used.
FAST armor can only be used when both client and KDC have a shared
secret. When KDC is from a trusted domain, there is no way to have a
shared secret between a generic Kerberos client and that KDC.
[MS-KILE] section 3.2.5.4 'Using FAST When the Realm Supports FAST'
allows KILE clients (Kerberos clients) to have local settings that
direct it to enforce use of FAST. This is equal to the current
implementation of 'kinit' utility in MIT Kerberos requiring to use FAST
if armor cache (option '-T') is provided.
[MS-KILE] section 3.3.5.7.4 defines a way for a computer from a
different realm to use compound identity TGS-REQ to create FAST TGS-REQ
explicitly armored with the computer's TGT. However, this method is not
available to IPA framework as we don't have access to the IPA server's
host key. In addition, 'kinit' utility does not support this method.
Active Directory has a policy to force use of FAST when client
advertizes its use. Since we cannot know in advance whether a principal
to obtain initial credentials for belongs to our realm or to a trusted
one due to enterprise principal canonicalization, we have to try to
kinit. Right now we fail unconditionally if FAST couldn't be used and
libkrb5 communication with a KDC from the user realm (e.g. from a
trusted forest) causes enforcement of a FAST.
In the latter case, as we cannot use FAST anyway, try to kinit again
without advertizing FAST. This works even in the situations when FAST
enforcement is enabled on Active Directory side: if client doesn't
advertize FAST capability, it is not required. Additionally, FAST cannot
be used for any practical need for a trusted domain's users yet.
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
ipa_gethostfqdn() now returns a pointer to a statically allocated buffer
or NULL in case of an error. The caller no longer has to supply a
correctly allocated buffer.
Rename IPA_HOST_HOST to_LEN IPA_HOST_FQDN_LEN and use IPA_HOST_FQDN_LEN
wherever code copies a hostname supplied from ipa_gethostfqdn().
Clarify that MAXHOSTNAMELEN and MAXHOSTFQDNLEN are different things.
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
FreeIPA's Python and C code used different approaches to get the FQDN of
the host. Some places assumed that gethostname() returns a FQDN. Other
code paths used glibc's resolver to resolve the current node name to a
FQDN.
Python code now uses the ipalib.constants.FQDN where a fully qualified
domain name is expected. The variable is initialized only once and avoids
potential DNS lookups.
C code uses a new helper function ipa_gethostfqdn() in util package. The
function implements similar logic as gethostfqdn() except it uses more
modern getaddrinfo(). The result is cached as well.
Fixes: https://pagure.io/freeipa/issue/8501
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
wait_for_request() now waits 0.5 instead of 5 seconds. This shoves off
15 to 20 seconds from ipa-server-install while marginally increased
load on the system.
request_and_wait_for_cert() now uses correct certmonger_wait_timeout
instead of http_timeout.
Related: https://pagure.io/freeipa/issue/8521
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
detect_resolve1_resolv_conf() detects if systemd-resolved is enabled and
manages /etc/resolv.conf.
get_resolve1_nameservers() gets upstream DNS servers from
systemd-resolved's D-Bus interface.
get_dnspython_nameservers() gets upstream DNS servers from
/etc/resolv.conf via dns.python.
get_nameservers() gets a list of unique, non-loopback DNS server IP
addresses.
Also fixes setup.py to include D-Bus for ipalib instead of ipapython.
See: https://pagure.io/freeipa/issue/8275
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
New classes for user and group names provide a convenient way to access
the uid and primary gid of a user / gid of a group. The classes also
provide chown() and chgrp() methods to simplify common operations.
The wrappers are subclasses of builtin str type and behave like ordinary
strings with additional features. The pwd and grp structs are retrieved
once and then cached.
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Ensure uniqueuess in attributes and permissions in the ACI class.
A set() is not used because it doesn't guarantee order which ends up
causing cascading and unpredictable test failures. Since all we
really need is de-duplication and not a true mathematical set iterating
through the list is sufficiently fast, particularly since the number
of elements will always be low.
https://pagure.io/freeipa/issue/8443
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
`dnspython` 2.0.0 has many changes and several deprecations like:
```
> dns.resolver.resolve() has been added, allowing control of whether
search lists are used. dns.resolver.query() is retained for backwards
compatibility, but deprecated. The default for search list behavior can
be set at in the resolver object with the use_search_by_default
parameter. The default is False.
> dns.resolver.resolve_address() has been added, allowing easy
address-to-name lookups.
```
The new class `DNSResolver`:
- provides the compatibility layer
- defaults the previous behavior (the search list configured in the
system's resolver configuration is used for relative names)
- defaults lifetime to 15sec (determines the number of seconds
to spend trying to get an answer to the question)
Fixes: https://pagure.io/freeipa/issue/8383
Signed-off-by: Stanislav Levin <slev@altlinux.org>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
If single-option values are combined together with invalid options
an exception would be raised.
For example -verbose was treated as -v -e rbose. Since rbose isn't
a name/value pair things would blow up. This is now caught and
a somewhat more reable error returned. The -v and -e are consumed,
not much we can do about that, but at least a more usable error is
returned.
https://pagure.io/freeipa/issue/6115
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
If there is no installation section the the install pre-dated
this new method of detecting a successful installation, fall back
to that.
https://pagure.io/freeipa/issue/8458
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Stanislav Levin <slev@altlinux.org>
Reviewed-By: Alexander Bokovoy <abbra@users.noreply.github.com>
These were triggered because of the movement of sysrestore.py in
the tree
https://pagure.io/freeipa/issue/8384
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
check_client_configuration differs from is_ipa_client_configured
in that it raises an exception if not configured so is a nice
convenience in AdminTool scripts. Port it to call to
is_ipa_client_configured() instead of determining the install
state on its own.
https://pagure.io/freeipa/issue/8384
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
Use the is_ipa_configure() and is_ipa_client_configured() utilities
instead which are much more robust.
https://pagure.io/freeipa/issue/8384
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
This is common to both client and server. Start with whether the
client or server is configured.
https://pagure.io/freeipa/issue/8384
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
tab completion and dir() now show registered plugins in API name spaces.
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Update ra.get_certificate to use the Dogtag REST API. This change
is being done as part of the Dogtag GSS-API authentication effort
because the servlet-based method expects an internal Dogtag user.
It is less intrusive to just change FreeIPA to call the REST API
instead (which is also part of an existing ticket).
Depends on https://pagure.io/dogtagpki/issue/2601 (which was merged
and released long ago).
Part of: https://pagure.io/freeipa/issue/3473
Part of: https://pagure.io/freeipa/issue/5011
Reviewed-By: Christian Heimes <cheimes@redhat.com>
The errors_by_code mapping could be used in more places. In
particular it will be useful in the Dogtag GSS-API authentication
effort. Move to ipalib.errors.
Part of: https://pagure.io/freeipa/issue/5011
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abbra@users.noreply.github.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
It was found that if an account was created with a name corresponding to
an account local to a system, such as 'root', was created via IPA, such
account could access any enrolled machine with that account, and the local
system privileges. This also bypass the absence of explicit HBAC rules.
root principal alias
-------------------
The principal "root@REALM" is now a Kerberos principal alias for
"admin". This prevent user with "User Administrator" role or
"System: Add User" privilege to create an account with "root" principal
name.
Modified user permissions
-------------------------
Several user permissions no longer apply to admin users and filter on
posixaccount object class. This prevents user managers from modifying admin
acounts.
- System: Manage User Certificates
- System: Manage User Principals
- System: Manage User SSH Public Keys
- System: Modify Users
- System: Remove Users
- System: Unlock user
``System: Unlock User`` is restricted because the permission also allow a
user manager to lock an admin account. ``System: Modify Users`` is restricted
to prevent user managers from changing login shell or notification channels
(mail, mobile) of admin accounts.
New user permission
-------------------
- System: Change Admin User password
The new permission allows manipulation of admin user password fields. By
default only the ``PassSync Service`` privilege is allowed to modify
admin user password fields.
Modified group permissions
--------------------------
Group permissions are now restricted as well. Group admins can no longer
modify the admins group and are limited to groups with object class
``ipausergroup``.
- System: Modify Groups
- System: Remove Groups
The permission ``System: Modify Group Membership`` was already limited.
Notes
-----
Admin users are mostly unaffected by the new restrictions, except for
the fact that admins can no longer change krbPrincipalAlias of another
admin or manipulate password fields directly. Commands like ``ipa passwd
otheradmin`` still work, though. The ACI ``Admin can manage any entry``
allows admins to modify other entries and most attributes.
Managed permissions don't install ``obj.permission_filter_objectclasses``
when ``ipapermtargetfilter`` is set. Group and user objects now have a
``permission_filter_objectclasses_string`` attribute that is used
by new target filters.
Misc changes
------------
Also add new exception AlreadyContainsValueError. BaseLDAPAddAttribute
was raising a generic base class for LDAP execution errors.
Fixes: https://pagure.io/freeipa/issue/8326
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1810160
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
In the migration case of replica installation, if the CA server is
an older version it may not support the ipa-ca.$DOMAIN dnsName in
the HTTP cert (it is a special case in the cert_request command).
Therefore if the request fails, try it again without the
ipa-ca.$DOMAIN dnsName.
Part of: https://pagure.io/freeipa/issue/8186
Reviewed-By: Alexander Bokovoy <abbra@users.noreply.github.com>
The logic to detect in-tree builds was broken and ipatests/conftest.py
had hard-coded in_tree=True.
IPA now considers an environment as in-tree when the parent directory of
the ``ipalib`` package contains ``ipasetup.py.in``. This file is only
present in source and never installed.
API bootstrap() does not use ```self.site_packages in site.getsitepackages()``
because the function call can be expensive and would require path
normalization, too. The function is also missing from venv site module.
Fixes: https://pagure.io/freeipa/issue/8312
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
* use "developer" in Azure
* fix man page: "development" to "developer"
* list known modes in API bootstrap methods
Other values for mode are still supported to avoid breaking existing
installations.
Fixes: https://pagure.io/freeipa/issue/8313
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Sphinx is extensible with plugins that can add new syntax, roles,
directives, domains, and more.
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
W1661(exception-escape), RPCClient.forward]
Using an exception object that was bound by an except handler)
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
BACKGROUND:
We are implementing ACME support in FreeIPA (umbrella ticket:
https://pagure.io/freeipa/issue/4751). ACME is defined in RFC 8555.
HTTPS is REQUIRED (https://tools.ietf.org/html/rfc8555#section-6.1).
Therefore, every FreeIPA server that provides the ACME service
capability must be reachable by HTTPS.
RFC 8555 does not say anything about which port to use for ACME.
The default HTTPS port of 443 is implied. Therefore, the FreeIPA
ACME service will be reached via the Apache httpd server, which will
be the TLS server endpoint.
As a usability affordance for ACME clients, and as a maintainability
consideration i.e. to allow the topology to change without having to
reconfigure ACME clients, there should be a a single DNS name used
to reach the IPA ACME service.
The question then, is which DNS name to use.
REQUIREMENTS:
Each FreeIPA server that is also an ACME server must:
1. Be reachable via a common DNS name
2. Have an HTTP service certificate with that DNS name as a SAN
dNSName value
DESIGN CONSIDERATION - WHAT DNS NAME TO USE?:
Some unrelated FreeIPA ACME design decisions provide important
context for the DNS name decision:
- The ACME service will be automatically and unconditionally
deployed (but not necessarily *enabled*) on all CA servers.
- Enabling or disabling the ACME service will have topology-wide
effect, i.e. the ACME service is either enabled on all CA
servers, or disabled on all CA servers.
In a CA-ful FreeIPA deployment there is already a DNS name that
resolves to all CA servers: ``ipa-ca.$DOMAIN``, e.g.
``ipa-ca.example.com``. It is expected to point to all CA servers
in the deployment, and *only* to CA servers. If internal DNS is
deployed, the DNS records for ``ipa-ca.$DOMAIN`` are created and
updated automatically. If internal DNS is not deployed,
administrators are required to maintain these DNS records
themselves.
The ``ipa-ca.$DOMAIN`` alias is currently used for OCSP and CRL
access. TLS is not required for these applications (and it can
actually be problematic for OCSP). Enabling TLS for this name
presents some risk of confusion for operators. For example, if they
see that TLS is available and alter the certificate profiles to
include an HTTPS OCSP URL in the Authority Information Access (AIA)
extension, OCSP-using clients may fail to validate such
certificates. But it is possible for administrators to make such a
change to the profile, whether or not HTTPS is available.
One big advantage to using the ``ipa-ca.$DOMAIN`` DNS name is that
there are no new DNS records to manage, either in the FreeIPA
implementation or for administrators in external DNS systems.
The alternative approach is to define a new DNS name, e.g.
``ipa-acme.$DOMAIN``, that ACME clients would use. For internal
DNS, this means the FreeIPA implementation must manage the DNS
records. This is straightforward; whenever we add or remove an
``ipa-ca.$DOMAIN`` record, also add/remove the ``ipa-acme.$DOMAIN``
record. But for CA-ful deployments using external DNS, it is
additional work for adminstrators and, unless automated, additional
room for error.
An advantage of using a different DNS name is ``ipa-ca.$DOMAIN`` can
remain inaccessible over HTTPS. This possibly reduces the risk of
administrator confusion or creation of invalid AIA configuration in
certificate profiles.
Weighing up the advantages and disadvantages, I decided to use the
``ipa-ca.$DOMAIN`` DNS name.
DESIGN CONSIDERATION - CA SERVERS, OR ALL SERVERS?:
A separate decision from which name to use is whether to include it
on the HTTP service certificate for ACME servers (i.e. CA servers)
only, or on all IPA servers.
Combined with the assumption that the chosen DNS name points to CA
servers *only*, there does not seem to be any harm in adding it to
the certificates on all IPA servers.
The alternative is to only include the chosen DNS name on the HTTP
service certificates of CA servers. This approach entails some
additional complexity:
- If a non-CA replica gets promoted to CA replica (i.e. via
``ipa-ca-install``), its HTTP certificate must be re-issued with
the relevant name.
- ipa-server-upgrade code must consider whether the server is a CA
replica when validating (and if necessary re-creating) Certmonger
tracking requests
- IPA Health Check must be made aware of this factor when checking
certificates and Certmonger tracking requests.
Weighing up the options, I decided to add the common DNS name to the
HTTP service certificate on all IPA servers. This avoids the
implementation complexity discussed above.
CHANGES IN THIS COMMIT
When (re-)tracking the HTTP certificate, explicitly add the server
FQDN and ipa-ca.$DOMAIN DNS names to the Certmonger tracking request.
Related changes follow in subsequent commits.
Part of: https://pagure.io/freeipa/issue/8186
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
We need to be able to filter Certmonger tracking requests by the DNS
names defined for the request. The goal is to add the
'ipa-ca.$DOMAIN' alias to the HTTP certificate tracking requests, so
we will use that name as a search criterion. Implement support for
this.
As a result of this commit it will be easy to add support for subset
match of other Certmonger request list properties. Just add the
property name to the ARRAY_PROPERTIES list (and update the
'criteria' description in the module docstring!)
Part of: https://pagure.io/freeipa/issue/8186
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
The 'criteria' parameter is used by several subroutines in the
ipalib.install.certmonger module. It has incomplete documentation
spread across several of these subroutines. Move the documentation
to the module docstring and reference it where appropriate.
Part of: https://pagure.io/freeipa/issue/8186
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
certmonger._get_requests has a mutable default argument. Although
at the present time it is never modified, this is an antipattern to
be avoided.
In fact, we don't even need the default argument, because it is
always called with a dict() argument. So just remove it.
Part of: https://pagure.io/freeipa/issue/8186
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
I added a comment in @d0b420f6d, later, on refactoring in
@c6769ad12 I forgot to remove it. So, it is just a clean up.
Related: https://pagure.io/freeipa/issue/8116
Signed-off-by: Stanislav Levin <slev@altlinux.org>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
