mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2024-12-23 07:33:27 -06:00
8c241869dd
I can only guess to the original purpose of this override. I believe it was because this is called in the installer prior to Apache being set up. The expectation was that this would only be called locally. It predates the RestClient class. RestClient will attempt to find an available service. In this case, during a CA installation, the local server is not considered available because it lacks an entry in cn=masters. So it will never be returned as an option. So by overriding the port to 8443 the remote connection will likely fail because we don't require that the port be open. So instead, instantiate a RestClient and see what happens. There are several use-cases: 1. Installing an initial server. The RestClient connection should fail, so we will fall back to the override port and use the local server. If Apache happens to be running with a globally-issued certificate then the RestClient will succeed. In this case if the connected host and the local hostname are the same, override in that case as well. 2. Installing as a replica. In this case the local server should be ignored in all cases and a remote CA will be picked with no override done. 3. Switching from CA-less to CA-ful. The web server will be trusted but the RestClient login will fail with a 404. Fall back to the override port in this case. The motivation for this is trying to install an EL 8.x replica against an EL 7.9 server. 8.5+ includes the ACME service and a new profile is needed which doesn't exist in 7. This was failing because the RestClient determined that the local server wasn't running a CA so tried the remote one (7.9) on the override port 8443. Since this port isn't open: failure. Chances are that adding the profile is still going to fail because again, 7.9 lacks ACME capabilities, but it will fail in a way that allows the installation to continue. I suspect that all of the overrides can similarly handled, or handled directly within the RestClient class, but for the sake of "do no harm" I'm only changing this instance for now. https://pagure.io/freeipa/issue/9100 Signed-off-by: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com> |
||
|---|---|---|
| .copr | ||
| .github | ||
| asn1 | ||
| client | ||
| contrib | ||
| daemons | ||
| doc | ||
| init | ||
| install | ||
| ipaclient | ||
| ipalib | ||
| ipaplatform | ||
| ipapython | ||
| ipaserver | ||
| ipasphinx | ||
| ipatests | ||
| po | ||
| pypi | ||
| selinux | ||
| util | ||
| .freeipa-pr-ci.yaml | ||
| .git-commit-template | ||
| .gitignore | ||
| .lgtm.yml | ||
| .mailmap | ||
| .tox-install.sh | ||
| .wheelconstraints.in | ||
| ACI.txt | ||
| API.txt | ||
| autogen.sh | ||
| BUILD.txt | ||
| CODE_OF_CONDUCT.md | ||
| configure.ac | ||
| Contributors.txt | ||
| COPYING | ||
| COPYING.openssl | ||
| freeipa.doap.rdf | ||
| freeipa.spec.in | ||
| ipa.in | ||
| ipasetup.py.in | ||
| make-doc | ||
| make-test | ||
| makeaci.in | ||
| makeapi.in | ||
| Makefile.am | ||
| Makefile.python.am | ||
| Makefile.pythonscripts.am | ||
| makerpms.sh | ||
| pylint_plugins.py | ||
| pylintrc | ||
| README.md | ||
| server.m4 | ||
| tox.ini | ||
| VERSION.m4 | ||
FreeIPA Server
FreeIPA allows Linux administrators to centrally manage identity, authentication and access control aspects of Linux and UNIX systems by providing simple to install and use command line and web based management tools.
FreeIPA is built on top of well known Open Source components and standard protocols with a very strong focus on ease of management and automation of installation and configuration tasks.
FreeIPA can seamlessly integrate into an Active Directory environment via cross-realm Kerberos trust or user synchronization.
Benefits
FreeIPA:
- Allows all your users to access all the machines with the same credentials and security settings
- Allows users to access personal files transparently from any machine in an authenticated and secure way
- Uses an advanced grouping mechanism to restrict network access to services and files only to specific users
- Allows central management of security mechanisms like passwords, SSH Public Keys, SUDO rules, Keytabs, Access Control Rules
- Enables delegation of selected administrative tasks to other power users
- Integrates into Active Directory environments
Components
The FreeIPA project provides unified installation and management tools for the following components:
- LDAP Server - based on the 389 project
- KDC - based on MIT Kerberos implementation
- PKI based on Dogtag project
- Samba libraries for Active Directory integration
- DNS Server based on BIND and the Bind-DynDB-LDAP plugin
Project Website
Releases, announcements and other information can be found on the IPA server project page at http://www.freeipa.org/ .
Documentation
The most up-to-date documentation can be found at http://freeipa.org/page/Documentation .
Quick Start
To get started quickly, start here: http://www.freeipa.org/page/Quick_Start_Guide
For developers
- Building FreeIPA from source
- http://www.freeipa.org/page/Build
- See the BUILD.txt file in the source root directory
Licensing
Please see the file called COPYING.
Contacts
- If you want to be informed about new code releases, bug fixes, security fixes, general news and information about the IPA server subscribe to the freeipa-announce mailing list at https://www.redhat.com/mailman/listinfo/freeipa-interest/ .
- If you have a bug report please submit it at: https://pagure.io/freeipa/issues
- If you want to participate in actively developing IPA please subscribe to the freeipa-devel mailing list at https://lists.fedoraproject.org/archives/list/freeipa-devel@lists.fedorahosted.org/ or join us in IRC at irc://irc.libera.chat/freeipa