[Freeipa-devel] [freeipa PR#764][comment] Basic uninstaller for the CA
URL: https://github.com/freeipa/freeipa/pull/764 Title: #764: Basic uninstaller for the CA rcritten commented: """ As far as I can tell it is always recoverable using this. I wasn't able to force a failure of replication, that could be a potential show-stopper. The PR doesn't touch the replication agreements at all except to allow them to already be there, so if things were in some sort of halfway state I couldn't say for sure what would happen. The code is there for examination to determine what steps are done, but in short: - call the existing CA uninstaller which mostly just calls pki-destroy (it also does some state cleanup, removes the CRLs and untracks the CA certs via certmonger) - A side-effect of the uninstaller is to shutdown certmonger. I start that back up - The service is removed from cn=masters - The cached services list is removed so ipactl won't fail starting a non-existent tomcat instance To be idempotent would require changes in dogtag, it is that which blows up on a re-install attempt. I would not be in favor of automatically uninstalling dogtag on another ipa-ca-install call. ipa-ca-install would/should never be run on the original master. It already prints a big fat warning. I'd be ok making it fatter and requiring (no joke) multiple "Are you sure" prompts. There is no CA install for CAless so not a case I'm interested in. If you want to rename options I'm ok with that as well, maybe --try-again or something of that nature (in which case I WOULD be in favor of doing the uninstall automatically). """ See the full comment at https://github.com/freeipa/freeipa/pull/764#issuecomment-300247543 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#764][comment] Basic uninstaller for the CA
URL: https://github.com/freeipa/freeipa/pull/764 Title: #764: Basic uninstaller for the CA rcritten commented: """ What do you mean half-effective? Did you try it? There already IS a unified framework for component uninstallation: each service provides it. There are edge cases when trying to uninstall one particular piece but that is relatively straightforward to handle and as outlined in the PR this is not intended or expected to clean up every last element, just enough to be able to cleanly attempt the installation again. Forcing users to uninstall an entire master just to (try to) re-install the CA is a major pain point. Other services not having uninstall options is not relevant to this case IMHO. """ See the full comment at https://github.com/freeipa/freeipa/pull/764#issuecomment-299524085 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#764][opened] Basic uninstaller for the CA
URL: https://github.com/freeipa/freeipa/pull/764
Author: rcritten
Title: #764: Basic uninstaller for the CA
Action: opened
PR body:
"""
This in response to watching users flounder with repeated failed replica
installations and ipa-ca-install attempts that require a complete uninstall.
Review it with whatever priority you desire.
This is meant ONLY to be able to re-try an installation if the
CA cloning fails for some reason. It is not intended to be used
to remove the CA as a service on a given master.
This is to avoid having to stand up a whole new master just
because the CA installation failed.
https://pagure.io/freeipa/issue/6595
"""
To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/764/head:pr764
git checkout pr764
From da470e73eb3100777e983cc31a3566390e66efc2 Mon Sep 17 00:00:00 2001
From: Rob Crittenden
Date: Thu, 4 May 2017 14:45:49 -0400
Subject: [PATCH] Basic uninstaller for the CA
This is meant ONLY to be able to re-try an installation if the
CA cloning fails for some reason. It is not intended to be used
to remove the CA as a service on a given master.
This is to avoid having to stand up a whole new master just
because the CA installation failed.
https://pagure.io/freeipa/issue/6595
---
install/tools/ipa-ca-install| 72 -
ipaserver/install/cainstance.py | 10 --
2 files changed, 79 insertions(+), 3 deletions(-)
diff --git a/install/tools/ipa-ca-install b/install/tools/ipa-ca-install
index 60261aa..97e9959 100755
--- a/install/tools/ipa-ca-install
+++ b/install/tools/ipa-ca-install
@@ -24,6 +24,7 @@ import shutil
import tempfile
from ipalib.install.kinit import kinit_keytab
+from ipapython.dn import DN
from ipapython import ipautil
from ipaserver.install import installutils
@@ -31,12 +32,14 @@ from ipaserver.install.installutils import create_replica_config
from ipaserver.install.installutils import check_creds, ReplicaConfig
from ipaserver.install import dsinstance, ca
from ipaserver.install import cainstance, service
+from ipaserver.install import krainstance
from ipapython import version
-from ipalib import api
+from ipalib import api, errors
from ipalib.constants import DOMAIN_LEVEL_0
from ipapython.config import IPAOptionParser
from ipapython.ipa_log_manager import root_logger, standard_logging_setup
from ipaplatform.paths import paths
+from ipaplatform import services
log_file_name = paths.IPAREPLICA_CA_INSTALL_LOG
REPLICA_INFO_TOP_DIR = None
@@ -44,6 +47,8 @@ REPLICA_INFO_TOP_DIR = None
def parse_options():
usage = "%prog [options] REPLICA_FILE"
parser = IPAOptionParser(usage=usage, version=version.VERSION)
+parser.add_option("--uninstall", dest="uninstall", action="store_true",
+ default=False, help="uninstall the CA")
parser.add_option("-d", "--debug", dest="debug", action="store_true",
default=False, help="gather extra debugging information")
parser.add_option("-p", "--password", dest="password", sensitive=True,
@@ -254,6 +259,67 @@ def install(safe_options, options, filename):
pass
+def uninstall(options):
+# Uninstaller meant only for blown replica installations.
+
+# Does NOT remove replication agreements or the ipaca backend.
+
+ca_instance = cainstance.CAInstance(api.env.realm)
+
+if not cainstance.is_ca_installed_locally():
+ca_instance.print_msg(
+"CA does not appear to be installed on this host."
+)
+
+kra = krainstance.KRAInstance(api.env.realm)
+if kra.is_installed():
+sys.exit("Cannot deal with KRA at this time.")
+
+if options.unattended:
+ca_instance.print_msg(
+"Ignoring unattended uninstall request.\n"
+)
+ca_instance.print_msg(
+"This is for failed installs only, do not use otherwise."
+)
+if not ipautil.user_input("Are you sure you want to continue with the "
+ "uninstall procedure?", False):
+ca_instance.print_msg("Aborting uninstall operation.")
+sys.exit(0)
+
+# Note that I'm completely ignoring the replication agreement so it
+# doesn't matter what domain level this is. This is based on the
+# (bad) assumption that this is only being executed to fix a blown
+# install and not to remove the CA as a component.
+
+# TODO: Figure out what is going on with serial # ranges
+
+ca_instance.print_msg("Shutting down CA")
+ca_instance.stop_instance()
+
+try:
+ca.uninstall()
+except Exception as e:
+root_logger.debug("CA uninstall failed with %s", e)
+
+# certmonger is stopped as a si
[Freeipa-devel] [freeipa PR#735][comment] automount install: do not wait for sssd restart on uninstallation
URL: https://github.com/freeipa/freeipa/pull/735 Title: #735: automount install: do not wait for sssd restart on uninstallation rcritten commented: """ I guess I have more issues with the commit message than the patch content. What would you suggest ensure that sssd is up? A typical user wouldn't notice until an nss lookup failed which likely means a login was rejected. The wait for restart was there to ensure, in interactive sessions at least, that unconfiguring automount didn't hose the system. To me is another example of how wrong it is to require a ticket to initialize an API. """ See the full comment at https://github.com/freeipa/freeipa/pull/735#issuecomment-297420281 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#590][comment] Validate user input for cert-get-requestdata
URL: https://github.com/freeipa/freeipa/pull/590 Title: #590: Validate user input for cert-get-requestdata rcritten commented: """ You are duplicating the list of helpers. It would have been better to have helper defined as a StrEnum. If it isn't too late to change (e.g. no release has shipped with that in the API) then perhaps a separate patch, then you wouldn't need this enforcement at all. """ See the full comment at https://github.com/freeipa/freeipa/pull/590#issuecomment-286740595 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#546][comment] Store session cookie in a ccache option
URL: https://github.com/freeipa/freeipa/pull/546 Title: #546: Store session cookie in a ccache option rcritten commented: """ Should this patch not also remove the keyring code? Unit tests should be provided. """ See the full comment at https://github.com/freeipa/freeipa/pull/546#issuecomment-284761915 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#531][comment] httpinstance: disable system trust module in /etc/httpd/alias
URL: https://github.com/freeipa/freeipa/pull/531 Title: #531: httpinstance: disable system trust module in /etc/httpd/alias rcritten commented: """ Just FYI I'm opening an upstream discussion with the NSS team on this. It is very strange that there is a conflict like this, particularly between master and replica. """ See the full comment at https://github.com/freeipa/freeipa/pull/531#issuecomment-284414651 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#531][comment] httpinstance: disable system trust module in /etc/httpd/alias
URL: https://github.com/freeipa/freeipa/pull/531 Title: #531: httpinstance: disable system trust module in /etc/httpd/alias rcritten commented: """ IIRC on install all three existing db's get copied to .orig, or something like that right? So uninstall would move those back into place effectively disabling this? """ See the full comment at https://github.com/freeipa/freeipa/pull/531#issuecomment-284403378 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#482][comment] Don't count service/host/user cert md5 fprints in FIPS
URL: https://github.com/freeipa/freeipa/pull/482 Title: #482: Don't count service/host/user cert md5 fprints in FIPS rcritten commented: """ In service.py the error isn't wrapped in _(). You should use the same message in both. Given the different messages I'm surprised this didn't pop up as a test failure. """ See the full comment at https://github.com/freeipa/freeipa/pull/482#issuecomment-281086821 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#468][comment] Remove non-sensical kdestroy on https stop
URL: https://github.com/freeipa/freeipa/pull/468 Title: #468: Remove non-sensical kdestroy on https stop rcritten commented: """ Rudeness is not necessary. You said: "As to why a) we backup Kerberos keys, and b) support restoring into running IPA server that is beyond me." The reason for a) is to restore an exact copy of what was backed up. As for b, the idea of restoring into a running IPA server to replace the existing install with a new one is something I discuss in some detail at http://www.freeipa.org/page/V3/Backup_and_Restore and outline the ton of problems associated with it. It was never intended to be supported due to these issues. """ See the full comment at https://github.com/freeipa/freeipa/pull/468#issuecomment-280049816 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#468][comment] Remove non-sensical kdestroy on https stop
URL: https://github.com/freeipa/freeipa/pull/468 Title: #468: Remove non-sensical kdestroy on https stop rcritten commented: """ If you don't backup the keytab then how do you expect to bring the server back up? Fetch new keys for all services? Full restore is very clearly documented as a recovery from complete failure in which case the restored master is the only one so there should be no mismatch between what was backed-up and what was restored. """ See the full comment at https://github.com/freeipa/freeipa/pull/468#issuecomment-280045062 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#450][comment] Add FIPS-token password of HTTPD NSS database
URL: https://github.com/freeipa/freeipa/pull/450 Title: #450: Add FIPS-token password of HTTPD NSS database rcritten commented: """ I guess this is one approach to fix the problem. Would it be cleaner to pass in, or detect, FIPS mode, and only write out the token that will actually be used? """ See the full comment at https://github.com/freeipa/freeipa/pull/450#issuecomment-278951822 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#453][comment] Cleanup certdb
URL: https://github.com/freeipa/freeipa/pull/453 Title: #453: Cleanup certdb rcritten commented: """ I'm pretty sure the chdir() hack was due to SELinux issues, be sure to test in enforcing mode. It may no longer be required. """ See the full comment at https://github.com/freeipa/freeipa/pull/453#issuecomment-278662888 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#407][comment] New lite-server implementation
URL: https://github.com/freeipa/freeipa/pull/407 Title: #407: New lite-server implementation rcritten commented: """ Right, and IMHO that development process is inefficient and prone to error. Rather than copying bits around and doing full installs over and over you can run the server in-tree and have vastly improved debugging available. Certainly a "final" test of a full server install loop is necessary but for initial development and testing the lite-server is far easier and efficient. At one time the tests were also run almost exclusively in-tree (which was faster at the time). """ See the full comment at https://github.com/freeipa/freeipa/pull/407#issuecomment-274803025 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#407][comment] New lite-server implementation
URL: https://github.com/freeipa/freeipa/pull/407 Title: #407: New lite-server implementation rcritten commented: """ I always found the lite-server to be incredibly helpful for server-side plugin development. If it isn't being used any more then I'd wonder what is being used instead. """ See the full comment at https://github.com/freeipa/freeipa/pull/407#issuecomment-274550653 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#394][comment] Add fix for ipa plugins command
URL: https://github.com/freeipa/freeipa/pull/394 Title: #394: Add fix for ipa plugins command rcritten commented: """ How about a test to prevent future regressions? """ See the full comment at https://github.com/freeipa/freeipa/pull/394#issuecomment-272962038 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#367][comment] Remove nsslib from IPA
URL: https://github.com/freeipa/freeipa/pull/367 Title: #367: Remove nsslib from IPA rcritten commented: """ SSLv2 should not be supported, period. Not that it would work anyway because most SSL libs have completely removed this support, but it is just a terrible idea to even try and allow it. The rest I'm flexible on. """ See the full comment at https://github.com/freeipa/freeipa/pull/367#issuecomment-272205432 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#367][comment] Remove nsslib from IPA
URL: https://github.com/freeipa/freeipa/pull/367 Title: #367: Remove nsslib from IPA rcritten commented: """ Wait, you added support for SSLv2? Please remove it, it isn't needed even for backwards compatibility and would not be considered a regression. """ See the full comment at https://github.com/freeipa/freeipa/pull/367#issuecomment-272174784 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#367][comment] Remove nsslib from IPA
URL: https://github.com/freeipa/freeipa/pull/367 Title: #367: Remove nsslib from IPA rcritten commented: """ Did you open a bug against NSS or python-nss regarding the PIN requirement? """ See the full comment at https://github.com/freeipa/freeipa/pull/367#issuecomment-270382386 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code
URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code rcritten commented: """ You can specify the nickname using -n/--nickname. You'll probably also want to set --cafile=/etc/ipa/ca.crt, --dbdir=/etc/httpd/alias and sslpinfile=/etc/httpd/alias/pwdfile.txt to maintain current behavior. """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-270165993 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#182][comment] Use env var IPA_CONFDIR to get confdir for 'cli' context
URL: https://github.com/freeipa/freeipa/pull/182 Title: #182: Use env var IPA_CONFDIR to get confdir for 'cli' context rcritten commented: """ I don't see this as a convenience method. I'd find it less likely to use directly with the ipa tool (though having to specify -e every time I used a command get old pretty quickly. From a library perspective it is going to call api.bootstrap(options). Sure one can pass the config file location through that but then EVERY SINGLE app using IPA is going to have to create an option to allow that, creating disparate means of doing so, when IPA can more simply accept an environment variable, like many other libraries do. If you want to change the location of krb5.conf what do you do? Right, set an environment variable. In fact, IPA leverages this. Treat ipalib the same way, giving lots of rope, and let people utilize that power (or hang themselves). """ See the full comment at https://github.com/freeipa/freeipa/pull/182#issuecomment-263374646 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#215][comment] Add script to setup krb5 NFS exports
URL: https://github.com/freeipa/freeipa/pull/215 Title: #215: Add script to setup krb5 NFS exports rcritten commented: """ Quite a lot of this code can be eliminated if you use ipalib instead of manually reading configuration files, forking out to ipa, doing a kinit, etc or do you expect/anticipate that this can be executed on non-IPA-enrolled clients? """ See the full comment at https://github.com/freeipa/freeipa/pull/215#issuecomment-259736364 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#195][comment] [WIP] Make ipaclient pip install-able
URL: https://github.com/freeipa/freeipa/pull/195 Title: #195: [WIP] Make ipaclient pip install-able rcritten commented: """ This is an important feature for integration. OpenStack uses pip to install dependencies into virtual environments for doing multi-version python testing. I'll need ipalib to be pip installable for the automatic enrollment feature, novajoin, that I'm working on. """ See the full comment at https://github.com/freeipa/freeipa/pull/195#issuecomment-259184042 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#204][comment] ipautil.run: Remove hardcoded environ PATH value
URL: https://github.com/freeipa/freeipa/pull/204 Title: #204: ipautil.run: Remove hardcoded environ PATH value rcritten commented: """ +1 on using absolute paths. I don't recall any cases where KRB5_TRACE was needed so is this a theoretical use case or an actual one? Yes, LD_PRELOAD or PYTHONPATH can be tweaked but this just proves my point: the environment is untrustworthy. """ See the full comment at https://github.com/freeipa/freeipa/pull/204#issuecomment-257867492 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#204][comment] ipautil.run: Remove hardcoded environ PATH value
URL: https://github.com/freeipa/freeipa/pull/204 Title: #204: ipautil.run: Remove hardcoded environ PATH value rcritten commented: """ This isn't about replacing existing binaries, it's about putting binaries into unexpected places that are in the default PATH (e.g. ~/bin or /usr/local/bin). PATH cannot be overridden by an attacker without making code changes, in which case it's already game over (or it shouldn't, I didn't look for every execution of ipautil.run() where env is passed in. I don't disagree on being platform dependent. As for documentation, it just got missed. It's not an excuse, just the reality. It is generally accepted best-practice to not trust user input, including environment variables. See https://www.securecoding.cert.org/confluence/display/c/ENV03-C.+Sanitize+the+environment+when+invoking+external+programs This isn't followed completely, but at least the environment by default is wiped and PATH is controlled for the most part. Originally the commands were called explicitly, e.g. /usr/kerberos/sbin/kadmin.local, but because of the Fedora 14 issue we had to rely on PATH (see d0ea0bb63891babd1c5778df2e291b527c8e927c). """ See the full comment at https://github.com/freeipa/freeipa/pull/204#issuecomment-257667140 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#204][comment] ipautil.run: Remove hardcoded environ PATH value
URL: https://github.com/freeipa/freeipa/pull/204 Title: #204: ipautil.run: Remove hardcoded environ PATH value rcritten commented: """ PATH is untrustworthy because there is no knowing what is in it, or the order. It could easily have /usr/local/bin first and some rogue version of a program installed there, or it could have something in ~/bin. Calling exec() is dangerous by its very nature so we opted to be paranoid. Your archaeology is right, this wasn't exactly documented. Perhaps it was discussed on IRC in relation to the bug but I remember talking to Simo about this. """ See the full comment at https://github.com/freeipa/freeipa/pull/204#issuecomment-257655506 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#204][comment] ipautil.run: Remove hardcoded environ PATH value
URL: https://github.com/freeipa/freeipa/pull/204 Title: #204: ipautil.run: Remove hardcoded environ PATH value rcritten commented: """ NACK. I'd be fine with changing the PATH to remove cruft but the primary purpose is to prevent an attacker from providing their own PATH with unknown executables. For those few places where one must control PATH then env can be (and is) passed in. No ticket? """ See the full comment at https://github.com/freeipa/freeipa/pull/204#issuecomment-257628641 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#189][comment] Create relative symbol links
URL: https://github.com/freeipa/freeipa/pull/189 Title: #189: Create relative symbol links rcritten commented: """ I think you should add the reasoning for switching the link type to the commit message and if this is related to some higher-level ticket that should be included as well. """ See the full comment at https://github.com/freeipa/freeipa/pull/189#issuecomment-256323936 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#145][comment] Refactoring: LDAP Connection Management
URL: https://github.com/freeipa/freeipa/pull/145 Title: #145: Refactoring: LDAP Connection Management rcritten commented: """ Removing the connection timeout makes me a bit edgy. It is quite unclear why that's there, perhaps python-ldap doesn't provide a timeout and things hung forever, I'm not sure. I'd double-check that there is a timeout if the remote server either isn't there (probably raises a connection error), or is there but doesn't respond. """ See the full comment at https://github.com/freeipa/freeipa/pull/145#issuecomment-255099945 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#84][comment] Fix update_from_dict function testing
URL: https://github.com/freeipa/freeipa/pull/84 Title: #84: Fix update_from_dict function testing rcritten commented: """ The sort of pie-in-the-sky thinking about 3rd party plugins that Jason and I talked about eons ago was users would provide their own update files as part of their installer to be dropped somewhere (perhaps into the IPA-provided directory) and be processed like any other. I'm not sure I'd want a 3rd party plugin poking at ldapupdate internals. """ See the full comment at https://github.com/freeipa/freeipa/pull/84#issuecomment-248617607 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#84] Removed update_from_dict function from ldapupdate (comment)
rcritten commented on a pull request """ For the record this test used to pass. Don't blame the test when the code it is testing was changed. """ See the full comment at https://github.com/freeipa/freeipa/pull/84#issuecomment-247329152 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 1/1] After unininstall see if certmonger is still tracking any of our certs.
From: Rob Crittenden
Rather than providing a list of nicknames I'm going to look at the NSS
databases directly. Anything in there is suspect and this will help
future-proof us.
certmonger may be tracking other certificates but we only care about
a subset of them, so don't complain if there are other tracked certificates.
This reads the certmonger files directly so the service doesn't need
to be started.
https://fedorahosted.org/freeipa/ticket/2702
---
install/tools/ipa-server-install | 10 +-
ipapython/certmonger.py | 33 +
2 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install
index
cc25fb85500b6a97e71c822a882cf6f2aca4f0a0..3b03357185b6f8ff3a13db163a716ce79e7e5bfe
100755
--- a/install/tools/ipa-server-install
+++ b/install/tools/ipa-server-install
@@ -52,6 +52,7 @@ from ipaserver.install import sysupgrade
from ipaserver.install import service, installutils
from ipapython import version
+from ipapython import certmonger
from ipaserver.install.installutils import *
from ipaserver.plugins.ldap2 import ldap2
@@ -527,7 +528,14 @@ def uninstall():
rv = 1
if has_state:
-root_logger.warning('Some installation state has not been
restored.\nThis will cause re-installation to fail.\nIt should be safe to
remove /var/lib/ipa/sysrestore.state but it may\nmean your system hasn\'t be
restored to its pre-installation state.')
+root_logger.error('Some installation state has not been
restored.\nThis may cause re-installation to fail.\nIt should be safe to remove
/var/lib/ipa/sysrestore.state but it may\nmean your system hasn\'t be restored
to its pre-installation state.')
+
+# Note that this name will be wrong after the first uninstall.
+dirname =
dsinstance.config_dirname(dsinstance.realm_to_serverid(api.env.realm))
+dirs = [dirname, dogtag.configured_constants().ALIAS_DIR, certs.NSS_DIR]
+ids = certmonger.check_state(dirs)
+if ids:
+root_logger.error('Some certificates may still be tracked by
certmonger.\nThis will cause re-installation to fail.\nStart the certmonger
service and list the certificates being tracked\n # getcert list\nThese may be
untracked by executing\n # getcert stop-tracking -i \nfor each id
in: %s' % ', '.join(ids))
return rv
diff --git a/ipapython/certmonger.py b/ipapython/certmonger.py
index
9cc4466c61108a863eb76b1ff67bef559a9228d0..f823a6deccbae8dcabc23867bbe90b56fbbb390a
100644
--- a/ipapython/certmonger.py
+++ b/ipapython/certmonger.py
@@ -114,6 +114,24 @@ def get_request_id(criteria):
return reqid
+def get_requests_for_dir(dir):
+"""
+Return a list containing the request ids for a given NSS database
+directory.
+"""
+reqid=[]
+fileList=os.listdir(REQUEST_DIR)
+for file in fileList:
+rv = find_request_value('%s/%s' % (REQUEST_DIR, file),
+'cert_storage_location')
+if rv:
+rv = os.path.abspath(rv)
+if rv.rstrip() == dir:
+reqid.append(find_request_value('%s/%s' % (REQUEST_DIR, file),
'id').rstrip())
+
+return reqid
+
+
def add_request_value(request_id, directive, value):
"""
Add a new directive to a certmonger request file.
@@ -393,6 +411,21 @@ def dogtag_start_tracking(ca, nickname, pin, pinfile,
secdir, command):
(stdout, stderr, returncode) = ipautil.run(args, nolog=[pin])
+def check_state(dirs):
+"""
+Given a set of directories and nicknames verify that we are no longer
+tracking certificates.
+
+dirs is a list of directories to test for. We will return a tuple
+of nicknames for any tracked certificates found.
+
+This can only check for NSS-based certificates.
+"""
+reqids = []
+for dir in dirs:
+reqids.extend(get_requests_for_dir(dir))
+
+return reqids
if __name__ == '__main__':
request_id = request_cert("/etc/httpd/alias", "Test",
"cn=tiger.example.com,O=IPA", "HTTP/tiger.example@example.com")
--
1.7.11.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0/1] Check for leftover certmonger certs
From: Rob Crittenden Rob Crittenden (1): After unininstall see if certmonger is still tracking any of our certs. install/tools/ipa-server-install | 10 +- ipapython/certmonger.py | 33 + 2 files changed, 42 insertions(+), 1 deletion(-) -- 1.7.11.4 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
