Re: [Freeipa-devel] [PATCH 0173] Throw zonemgr error message before installation proceeds
Hi, Dne 27.11.2014 v 14:20 Martin Basti napsal(a): Ticket: https://fedorahosted.org/freeipa/ticket/4771 Patch attached. I would prefer if you did something like this instead: 1) Add validate_idn_normalized function with the normalized IDN check to ipapython.dnsutil, have it raise ValueError if the check fails. (Also please get rid of the map() call for better readability.) 2) Use validate_idn_normalized in DNSNameParam. 3) Do the following in validate_zonemgr_str: validate_idn_normalized(zonemgr) try: zonemgr = DNSName(zonemgr) except dns.exception.DNSException as e: raise ValueError(e) Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0038] Update default NTP Configuration
On 11/30/2014 02:03 AM, Gabe Alford wrote: Hello, Fix for https://fedorahosted.org/freeipa/ticket/4583 Thanks, Gabe ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Hello! Thanks for patch. I guess that you wanted to add the iburst option only once. Right now it will generate lines like: server server-fqdn iburst iburst Attaching the fixed patch. Are you satisfied with it? -- David Kupka From f571e379b3e7498e5f32092d633bd6219b1b9c5c Mon Sep 17 00:00:00 2001 From: Gabe redhatri...@gmail.com Date: Sat, 29 Nov 2014 17:53:03 -0700 Subject: [PATCH] Update default NTP configuration - Add in missing 4th default ntp server - Add iburst to configuration https://fedorahosted.org/freeipa/ticket/4583 --- ipaserver/install/ntpinstance.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ipaserver/install/ntpinstance.py b/ipaserver/install/ntpinstance.py index c653525d3abf43bef8847f55ef9e22108123c721..f2edf9bc18ec5408d7c17a7f1d90235c1ac164a5 100644 --- a/ipaserver/install/ntpinstance.py +++ b/ipaserver/install/ntpinstance.py @@ -51,6 +51,7 @@ class NTPInstance(service.Service): srv_vals.append(0.%s.pool.ntp.org % os) srv_vals.append(1.%s.pool.ntp.org % os) srv_vals.append(2.%s.pool.ntp.org % os) +srv_vals.append(3.%s.pool.ntp.org % os) srv_vals.append(127.127.1.0) fudge = [fudge, 127.127.1.0, stratum, 10] @@ -92,7 +93,7 @@ class NTPInstance(service.Service): fd.write(\n### Added by IPA Installer ###\n) if len(srv_vals) != 0: for srv in srv_vals: -fd.write(server +srv+\n) +fd.write(server +srv+ iburst\n) if not fudge_present: fd.write(fudge 127.127.1.0 stratum 10\n) fd.close() -- 2.1.0 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile
On 11/30/2014 03:28 AM, Gabe Alford wrote: Ignore the last patch. Updated patch attached. On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford redhatri...@gmail.com wrote: This patch removes the app_PYTHON usage. Thanks, Gabe On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek mko...@redhat.com wrote: Exactly, this was the message from Martin :-) I did not test it myself, but removing all app_PYTHON should be benign given we use Python setup.py packaging. On 11/27/2014 04:27 PM, Gabe Alford wrote: Thanks guys. Sounds like it would be better to submit a patch that removes app_PYTHON if it is considered dead code. Gabe On Thursday, November 27, 2014, Petr Spacek pspa...@redhat.com wrote: On 27.11.2014 11:00, Martin Basti wrote: On 27/11/14 00:50, Gabe Alford wrote: Hello, Wondering if I could get a review. Updated patch attached. Thanks, Gabe On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford redhatri...@gmail.com javascript:; mailto:redhatri...@gmail.com javascript:; wrote: Hello, Fix for https://fedorahosted.org/freeipa/ticket/4700 Thanks, Gabe Hello, sorry for late response. We push this ticket to backlog, as it would be part of build system refactoring. The app_PYTHON statement is not used anymore in IPA, the better solution is remove it, instead of keeping dead code up-to-date. Just to clarify: It can be pushed if it works, there is no need to postpone accepting patch if the patch seems okay and doesn't break anything. Martin, please keep in mind that contributions are welcome at any time. Milestones in Trac reflect our view of priorities but it doesn't prevent us from accepting correct patches from contributions at any time, no matter which priority is stated in Trac (or even if there is no ticket for it ...). -- Petr^2 Spacek Worked in my tests, I did not see any breakage. I guess we can also remove the ipa-client/ipaclient/Makefile.am while we are at it. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 380 Improve validation of --instance and --backend options in ipa-restore
Hi,
the attached patch fixes https://fedorahosted.org/freeipa/ticket/4744.
Honza
--
Jan Cholasta
From 204a065d67a65d9ed43e5eaa22958cd8daf7b15f Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Mon, 1 Dec 2014 12:12:15 +
Subject: [PATCH] Improve validation of --instance and --backend options in
ipa-restore
https://fedorahosted.org/freeipa/ticket/4744
---
ipaplatform/base/paths.py| 2 +-
ipaserver/install/ipa_backup.py | 2 +-
ipaserver/install/ipa_restore.py | 73
3 files changed, 46 insertions(+), 31 deletions(-)
diff --git a/ipaplatform/base/paths.py b/ipaplatform/base/paths.py
index c4cdc58..3389042 100644
--- a/ipaplatform/base/paths.py
+++ b/ipaplatform/base/paths.py
@@ -262,7 +262,7 @@ class BasePathNamespace(object):
VAR_LIB_DIRSRV_INSTANCE_SCRIPTS_TEMPLATE = /var/lib/dirsrv/scripts-%s
VAR_LIB_SLAPD_INSTANCE_DIR_TEMPLATE = /var/lib/dirsrv/slapd-%s
SLAPD_INSTANCE_BACKUP_DIR_TEMPLATE = /var/lib/dirsrv/slapd-%s/bak/%s
-IPACA_DIRSRV_INSTANCE_DB_TEMPLATE = /var/lib/dirsrv/slapd-%s/db/ipaca
+SLAPD_INSTANCE_DB_DIR_TEMPLATE = /var/lib/dirsrv/slapd-%s/db/%s
SLAPD_INSTANCE_LDIF_DIR_TEMPLATE = /var/lib/dirsrv/slapd-%s/ldif
VAR_LIB_SLAPD_PKI_IPA_DIR_TEMPLATE = /var/lib/dirsrv/slapd-PKI-IPA
VAR_LIB_IPA = /var/lib/ipa
diff --git a/ipaserver/install/ipa_backup.py b/ipaserver/install/ipa_backup.py
index 5d583f7..72d1475 100644
--- a/ipaserver/install/ipa_backup.py
+++ b/ipaserver/install/ipa_backup.py
@@ -292,7 +292,7 @@ class Backup(admintool.AdminTool):
for instance in [realm_to_serverid(api.env.realm), 'PKI-IPA']:
if os.path.exists(paths.VAR_LIB_SLAPD_INSTANCE_DIR_TEMPLATE % instance):
-if os.path.exists(paths.IPACA_DIRSRV_INSTANCE_DB_TEMPLATE % instance):
+if os.path.exists(paths.SLAPD_INSTANCE_DB_DIR_TEMPLATE % (instance, 'ipaca')):
self.db2ldif(instance, 'ipaca', online=options.online)
self.db2ldif(instance, 'userRoot', online=options.online)
self.db2bak(instance, online=options.online)
diff --git a/ipaserver/install/ipa_restore.py b/ipaserver/install/ipa_restore.py
index 9cb978a..0977039 100644
--- a/ipaserver/install/ipa_restore.py
+++ b/ipaserver/install/ipa_restore.py
@@ -188,15 +188,35 @@ class Restore(admintool.AdminTool):
self.log.info(Preparing restore from %s on %s,
self.backup_dir, api.env.host)
-if not options.instance:
-instances = []
-for instance in [realm_to_serverid(api.env.realm), 'PKI-IPA']:
-if os.path.exists(paths.VAR_LIB_SLAPD_INSTANCE_DIR_TEMPLATE % instance):
-instances.append(instance)
+if options.instance and options.backend:
+database = (options.instance, options.backend)
+if not os.path.exists(paths.SLAPD_INSTANCE_DB_DIR_TEMPLATE %
+ database):
+raise admintool.ScriptError(
+Instance %s with backend %s does not exist % database)
+
+databases = [database]
else:
-instances = [options.instance]
-if options.data_only and not instances:
-raise admintool.ScriptError('No instances to restore to')
+if options.instance:
+instances = [options.instance]
+else:
+instances = [realm_to_serverid(api.env.realm), 'PKI-IPA']
+
+if options.backend:
+backends = [options.backend]
+else:
+backends = ['userRoot', 'ipaca']
+
+databases = []
+for instance in instances:
+for backend in backends:
+database = (instance, backend)
+if os.path.exists(paths.SLAPD_INSTANCE_DB_DIR_TEMPLATE %
+ database):
+databases.append(database)
+
+if options.data_only and not databases:
+raise admintool.ScriptError('No instances to restore to')
create_ds_user()
pent = pwd.getpwnam(DS_USER)
@@ -223,7 +243,7 @@ class Restore(admintool.AdminTool):
# These two checks would normally be in the validate method but
# we need to know the type of backup we're dealing with.
if (self.backup_type != 'FULL' and not options.data_only and
-not instances):
+not databases):
raise admintool.ScriptError('Cannot restore a data backup into an empty system')
if (self.backup_type == 'FULL' and not options.data_only and
(options.instance or options.backend)):
@@ -244,6 +264,15 @@ class Restore(admintool.AdminTool):
not user_input(Continue to restore?, False)):
raise admintool.ScriptError(Aborted)
+
Re: [Freeipa-devel] [PATCH 0173] Throw zonemgr error message before installation proceeds
Dne 1.12.2014 v 09:10 Jan Cholasta napsal(a): Hi, Dne 27.11.2014 v 14:20 Martin Basti napsal(a): Ticket: https://fedorahosted.org/freeipa/ticket/4771 Patch attached. I would prefer if you did something like this instead: 1) Add validate_idn_normalized function with the normalized IDN check to ipapython.dnsutil, have it raise ValueError if the check fails. (Also please get rid of the map() call for better readability.) 2) Use validate_idn_normalized in DNSNameParam. 3) Do the following in validate_zonemgr_str: validate_idn_normalized(zonemgr) try: zonemgr = DNSName(zonemgr) except dns.exception.DNSException as e: raise ValueError(e) Honza Actually, sratch that, exceptions thrown by python-dns do not have messages. ACK. Pushed to: master: ca25c92ea89661755d7204ac703e8c419c8929fa ipa-4-1: 07e29d250550f238e5706b348d69632fdbb67bda Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 792 add --hosts option to allow/retrieve keytab methods
`--hosts` option added to:
* service-allow-create-keytab
* service-allow-retrieve-keytab
* service-disallow-create-keytab
* service-disallow-retrieve-keytab
* host-allow-create-keytab
* host-allow-retrieve-keytab
* host-disallow-create-keytab
* host-disallow-retrieve-keytab
in order to allow hosts to retrieve keytab of their services or related
hosts as described on http://www.freeipa.org/page/V4/Keytab_Retrieval
design page
https://fedorahosted.org/freeipa/ticket/4777
I'm pondering how to handle Web UI. I'm not font of adding a third pair
of tables to host and service details pages because the amount of space
on the page required for the keytab management is much bigger than its
importance compared to other fields.
--
Petr Vobornik
From 5a7b77d47abd5b0ca5b97b667d1478c5e8f8dc3d Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Mon, 1 Dec 2014 10:15:21 +0100
Subject: [PATCH] add --hosts option to allow/retrieve keytab methods
`--hosts` option added to:
* service-allow-create-keytab
* service-allow-retrieve-keytab
* service-disallow-create-keytab
* service-disallow-retrieve-keytab
* host-allow-create-keytab
* host-allow-retrieve-keytab
* host-disallow-create-keytab
* host-disallow-retrieve-keytab
in order to allow hosts to retrieve keytab of their services or related hosts as described on http://www.freeipa.org/page/V4/Keytab_Retrieval design page
https://fedorahosted.org/freeipa/ticket/4777
---
API.txt | 24
VERSION | 4 +-
ipalib/plugins/host.py | 18 ++---
ipalib/plugins/service.py | 18 ++---
ipatests/test_xmlrpc/test_host_plugin.py| 58 ++---
ipatests/test_xmlrpc/test_service_plugin.py | 42 -
6 files changed, 128 insertions(+), 36 deletions(-)
diff --git a/API.txt b/API.txt
index 2a63f1e2349f0df69433fa7cb742e269cd42d79f..8c0b530cb0b7855594beeb12f891c29e31893ed5 100644
--- a/API.txt
+++ b/API.txt
@@ -1826,10 +1826,11 @@ output: Output('completed', type 'int', None)
output: Output('failed', type 'dict', None)
output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
command: host_allow_create_keytab
-args: 1,6,3
+args: 1,7,3
arg: Str('fqdn', attribute=True, cli_name='hostname', multivalue=False, primary_key=True, query=True, required=True)
option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
option: Str('group*', alwaysask=True, cli_name='groups', csv=True)
+option: Str('host*', alwaysask=True, cli_name='hosts', csv=True)
option: Flag('no_members', autofill=True, default=False, exclude='webui')
option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
option: Str('user*', alwaysask=True, cli_name='users', csv=True)
@@ -1838,10 +1839,11 @@ output: Output('completed', type 'int', None)
output: Output('failed', type 'dict', None)
output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
command: host_allow_retrieve_keytab
-args: 1,6,3
+args: 1,7,3
arg: Str('fqdn', attribute=True, cli_name='hostname', multivalue=False, primary_key=True, query=True, required=True)
option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
option: Str('group*', alwaysask=True, cli_name='groups', csv=True)
+option: Str('host*', alwaysask=True, cli_name='hosts', csv=True)
option: Flag('no_members', autofill=True, default=False, exclude='webui')
option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
option: Str('user*', alwaysask=True, cli_name='users', csv=True)
@@ -1866,10 +1868,11 @@ output: Output('result', type 'bool', None)
output: Output('summary', (type 'unicode', type 'NoneType'), None)
output: PrimaryKey('value', None, None)
command: host_disallow_create_keytab
-args: 1,6,3
+args: 1,7,3
arg: Str('fqdn', attribute=True, cli_name='hostname', multivalue=False, primary_key=True, query=True, required=True)
option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
option: Str('group*', alwaysask=True, cli_name='groups', csv=True)
+option: Str('host*', alwaysask=True, cli_name='hosts', csv=True)
option: Flag('no_members', autofill=True, default=False, exclude='webui')
option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
option: Str('user*', alwaysask=True, cli_name='users', csv=True)
@@ -1878,10 +1881,11 @@ output: Output('completed', type 'int', None)
output: Output('failed', type 'dict', None)
output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
command: host_disallow_retrieve_keytab
-args: 1,6,3
+args: 1,7,3
arg: Str('fqdn', attribute=True, cli_name='hostname', multivalue=False, primary_key=True, query=True, required=True)
option:
[Freeipa-devel] Threat model abuse cases in design documents
Hello, while wondering about design for 'external DNS integration' feature I have realized that I did not see any explicit threat model for FreeIPA. Do we have any? IMHO it would be handy to have it somewhere on wiki so it could be used as 'checklist' while developing design documents for security reviews. Threat model IMHO our assumed attacker should have these powers: 1) Do active man-in-the-middle attack on network: - All network communication can be monitored and altered by attacked. - This includes client-FreeIPA server communication, - and also server-server communication. 2) Compromise normal user account: I think that in in large networks the probability of successful attack against at least one user account is almost 1. So, we should assume that at least one user account was compromised. I.e. our attacker knows user's password or has equivalent of keytab. 3) Compromise a client machine: Again, I think that in in large networks the probability of successful attack against at least one machine is almost 1. So, we should assume that at least one machine account was compromised. I.e. our attacker has equivalent of machine keytab and keytabs for services running on it. What did I miss? Maybe we should explicitly say how replica files and other 'secrets' (DM password ...) should be handled. It would help with discussion about automated FreeIPA deployment too. Also, we should explicitly say that FreeIPA server itself and its LDAP database is the key to everything. If the FreeIPA server and its LDAP database is compromised then the game is over - attacker has access to everything. Abuse cases === IMHO security sensitive design documents (e.g. automated FreeIPA deployment, sub-CAs, Vault, external DNS integration) should explicitly walk through the thread model and state what is going to happen if FreeIPA infrastructure is under attack we assume. E.g. for external DNS integration with symmetric TSIG keys: Proposal in design document: - TSIG keys are distributed all to FreeIPA clients using LDAP GSSAPI and thus are accessible using any host/client.example.com credentials. Design assessment with thread model in mind: - MitM attack will not reveal anything because we trust GSSAPI. - User account compromise will not reveal anything because uses doesn't have access to TSIG keys. - Single compromised client will reveal TSIG keys to attacker so authentication to external DNS will be completely compromised. This will allow attacker to modify any records in external DNS. This could be have very serious consequences if DNSSEC is in place so clients can fully trust the records and use them for e.g. TLS validation. -- This could be a reason to re-think the design and remove this weak point. What do you think? -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 792 add --hosts option to allow/retrieve keytab methods
Hi, Dne 1.12.2014 v 14:17 Petr Vobornik napsal(a): `--hosts` option added to: * service-allow-create-keytab * service-allow-retrieve-keytab * service-disallow-create-keytab * service-disallow-retrieve-keytab * host-allow-create-keytab * host-allow-retrieve-keytab * host-disallow-create-keytab * host-disallow-retrieve-keytab in order to allow hosts to retrieve keytab of their services or related hosts as described on http://www.freeipa.org/page/V4/Keytab_Retrieval design page https://fedorahosted.org/freeipa/ticket/4777 Since groups of users are supported with group members, we should probably also support groups of hosts with hostgroup members, for consistency. I'm pondering how to handle Web UI. I'm not font of adding a third pair of tables to host and service details pages because the amount of space on the page required for the keytab management is much bigger than its importance compared to other fields. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0170] Detect and warn about invalid forwardzone configuration
On 24/11/14 17:24, Petr Spacek wrote: Hello! Thank you for the patch. It is not ready yet but the overall direction seems good. Please see my comments in-line. On 24.11.2014 14:35, Martin Basti wrote: Ticket: https://fedorahosted.org/freeipa/ticket/4721 Patch attached -- Martin Basti freeipa-mbasti-0170-Detect-and-warn-about-invalid-DNS-forward-zone-confi.patch From a5a19137e3ddf2d2d48cfbdb2968b6f68ac8f772 Mon Sep 17 00:00:00 2001 From: Martin Basti mba...@redhat.com Date: Fri, 21 Nov 2014 16:54:09 +0100 Subject: [PATCH] Detect and warn about invalid DNS forward zone configuration Shows warning if forward and parent authoritative zone do not have proper NS record delegation, which can cause the forward zone will be ineffective and forwarding will not work. The chande in the test was required due python changes order of elemnts in dict (python doesnt guarantee an order in dict) Ticket: https://fedorahosted.org/freeipa/ticket/4721 --- ipalib/messages.py | 12 +++ ipalib/plugins/dns.py | 147 +--- ipatests/test_xmlrpc/test_dns_plugin.py | 2 +- 3 files changed, 149 insertions(+), 12 deletions(-) diff --git a/ipalib/messages.py b/ipalib/messages.py index 102e35275dbe37328c84ecb3cd5b2a8d8578056f..cc9bae3d6e5c7d3a7401dab89fafb1b60dc1e15f 100644 --- a/ipalib/messages.py +++ b/ipalib/messages.py @@ -200,6 +200,18 @@ class DNSServerDoesNotSupportDNSSECWarning(PublicMessage): uIf DNSSEC validation is enabled on IPA server(s), uplease disable it.) +class ForwardzoneIsNotEffectiveWarning(PublicMessage): + +**13008** Forwardzone is not effective, forwarding will not work because +there is authoritative parent zone, without proper NS delegation + + +errno = 13008 +type = warning +format = _(uforward zone \%(fwzone)s\ is not effective (missing proper + uNS delegation in authoritative zone \%(authzone)s\). + uForwarding may not work.) I think that the error message could be made mode useful: Forwarding will not work. Please add NS record fwdzone.relativize(authzone) to parent zone %(authzone)s (or something like that). + def iter_messages(variables, base): Return a tuple with all subclasses diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py index c5d96a8c4fcdf101254ecefb60cb83d63bee6310..4f92da645e0faf784c7deb4b8ce386c1440f4229 100644 --- a/ipalib/plugins/dns.py +++ b/ipalib/plugins/dns.py @@ -1725,6 +1725,79 @@ def _normalize_zone(zone): return zone +def _find_zone_which_makes_fw_zone_ineffective(fwzonename): Generally, this method finds an authoritative zone for given fwzonename. What about method name _find_auth_zone_ldap(name) ? + +Check if forward zone is effective. + +If parent zone exists as authoritative zone, forward zone will not +forward queries. It is necessary to delegate authority of forward zone I would clarify it: forward queries by default. +to another server (non IPA DNS server). I would personally omit (non IPA DNS server) because this mechanism is not related to IPA domain at all. +Example: + +Forward zone: sub.example.com +Zone: example.com + +Forwarding will not work, because server thinks it is authoritative +and returns NXDOMAIN + +Adding record: sub.example.com NS nameserver.out.of.ipa.domain. Again, this is not related to IPA domain at all. I propose this text: Adding record: sub.example.com NS ns.sub.example.com. +will delegate authority to another server, and IPA DNS server will +forward DNS queries. + +:param fwzonename: forwardzone +:return: None if effective, name of authoritative zone otherwise + +assert isinstance(fwzonename, DNSName) + +# get all zones +zones = api.Command.dnszone_find(pkey_only=True, +sizelimit=0)['result'] Ooooh, are you serious? :-) I don't like this approach, I would rather chop left-most labels from name and so dnszone_find() one by one. What if you have many DNS zones? This could be thrown away if you iterate only over relevant zones. +zonenames = [zone['idnsname'][0].make_absolute() for zone in zones] +zonenames.sort(reverse=True, key=len) # sort, we need longest match + +# check if is there a zone which can cause the forward zone will +# be ineffective +sub_of_auth_zone = None +for name in zonenames: +if fwzonename.is_subdomain(name): +sub_of_auth_zone = name +break + +if sub_of_auth_zone is None: +return None + +# check if forwardzone is delegated in authoritative zone +# test if exists and get NS record +try: +ns_records = api.Command.dnsrecord_show( +sub_of_auth_zone, fwzonename, raw=True)['result']['nsrecord'] +except (errors.NotFound, KeyError): +return sub_of_auth_zone Note: This function
Re: [Freeipa-devel] [PATCH 0038] Update default NTP Configuration
Thanks, David. You're totally right. I am good with it. thanks, Gabe On Mon, Dec 1, 2014 at 5:20 AM, David Kupka dku...@redhat.com wrote: On 11/30/2014 02:03 AM, Gabe Alford wrote: Hello, Fix for https://fedorahosted.org/freeipa/ticket/4583 Thanks, Gabe ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Hello! Thanks for patch. I guess that you wanted to add the iburst option only once. Right now it will generate lines like: server server-fqdn iburst iburst Attaching the fixed patch. Are you satisfied with it? -- David Kupka ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On 14.11.2014 17:31, Petr Spacek wrote: On 14.11.2014 02:22, Simo Sorce wrote: On Tue, 11 Nov 2014 16:29:51 +0100 Petr Spacek pspa...@redhat.com wrote: Hello, this thread is about RFE IPA servers when installed should register themselves in the external DNS https://fedorahosted.org/freeipa/ticket/4424 It is not a complete design, just a raw idea. Use case FreeIPA installation to a network with existing DNS infrastructure + network administrator who is not willing to add/maintain new DNS servers just for FreeIPA. High-level idea === - Transform dns* commands from FreeIPA framework to equivalent nsupdate commands and send DNS updates to existing DNS servers. - Provide necessary encryption/signing keys to nsupdate. 1) Integration to FreeIPA framework === First of all, we need to decide if external DNS integration can be used at the same time with FreeIPA-integrated DNS or not. Side-question is what to do if a first server is installed with external-DNS but another replica is being installed with integrated-DNS and so on. I think being able to integrate with an external DNS is important, and not just at the server level, being able to distribute TSIG keys to client would be nice too, though a lot less important, than getting server integration.. Using TSIG on many clients is very problematic. Keep in mind that TSIG is basically HMAC computed using symmetric key so: a) Every client would have to use the same key - this is a security nightmare. b) We would have to distribute and maintain many keys for many^2 clients, which is an administrative nightmare. For *clients* I would rather stay with GSS-TSIG which is much more manageable because we can use Kerberos trust and Keytab distribution is already solved by ipa-client-install. Alternative for clients would be to use FreeIPA server as proxy which encapsulates TSIG keys and issues update requests on behalf of clients. This would be FreeIPA-specific but any TSIG-distribution mechanism will be FreeIPA-specific anyway. TSIG standard explicitly says that there is no standardized distribution mechanism. In other words, the question is if current dns.py plugin shipped with FreeIPA framework should be: a) Extended dns.py with dnsexternal-* commands -- Disadvantages: - It complicate FreeIPA DNS interface which is a complex beast even now. - We would have add condition to every DNS API call in installers which would increase horribleness of the installer code even more (or add another layer of abstraction...). I agree having a special command is undesirable. - I don't see a point in using integrated-DNS with external-DNS at the same time. To use integrated-DNS you have to get a proper DNS delegation from parent domain - and if you can get the delegation then there is no point in using external DNS ... I disagree on this point, it makes a lot of sense to have some zones maintained by IPA and ... some not. Advantages: - You can use external integrated DNS at the same time. We can achieve the same w/o a new ipa level command. This needs to be decided by FreeIPA framework experts ... Petr^3 came up with clever 'proxy' idea for IPA-commands. This proxy would provide all ipa dns* commands and dispatch user-issued commands to appropriate FreeIPA-plugin (internal-dns or external-dns). This decision could depend on some values in LDAP. b) Replace dns.py with another implementation of current dnszone-* dnsrecord-* API. - This seems like a cleaner approach to me. It could be shipped as ipa-server-dns-external package (opposed to standard ipa-server-dns package). Advantages: - It could seamlessly work with FreeIPA client installer because the dns*-nsupdate command transformation would be done on FreeIPA server and client doesn't need to know about it. - Does not require re-training/not much new documentation because commands are the same. Disadvantages: - You can't use integrated external DNS at the same time (but I don't think it justifies the added complexity). I disagree. One of the reason to use a mix is to allow smooth migrations where zones are moved into (or out of) IPA one by one. Good point, I agree. I will focus on supporting both (internal and external) DNS at the same time. Petr^3 or anyone else, what do you propose? I think what I'd like to see is to be able to configure a DNS zone in LDAP and mark it external. The zone would held the TSIG keys necessary to perform DNS updates. When the regular ipa dnsrecord-add etc... commands are called, the framework detects that the zone is external, fewttches the TSIG key (if the user has access to it) and spawn an nsupdate command that will perform the update against whatever DNS server is authoritative for the zone. Some
Re: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile
On Mon, Dec 1, 2014 at 6:05 AM, Martin Kosek mko...@redhat.com wrote: On 11/30/2014 03:28 AM, Gabe Alford wrote: Ignore the last patch. Updated patch attached. On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford redhatri...@gmail.com wrote: This patch removes the app_PYTHON usage. Thanks, Gabe On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek mko...@redhat.com wrote: Exactly, this was the message from Martin :-) I did not test it myself, but removing all app_PYTHON should be benign given we use Python setup.py packaging. On 11/27/2014 04:27 PM, Gabe Alford wrote: Thanks guys. Sounds like it would be better to submit a patch that removes app_PYTHON if it is considered dead code. Gabe On Thursday, November 27, 2014, Petr Spacek pspa...@redhat.com wrote: On 27.11.2014 11:00, Martin Basti wrote: On 27/11/14 00:50, Gabe Alford wrote: Hello, Wondering if I could get a review. Updated patch attached. Thanks, Gabe On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford redhatri...@gmail.com javascript:; mailto:redhatri...@gmail.com javascript:; wrote: Hello, Fix for https://fedorahosted.org/freeipa/ticket/4700 Thanks, Gabe Hello, sorry for late response. We push this ticket to backlog, as it would be part of build system refactoring. The app_PYTHON statement is not used anymore in IPA, the better solution is remove it, instead of keeping dead code up-to-date. Just to clarify: It can be pushed if it works, there is no need to postpone accepting patch if the patch seems okay and doesn't break anything. Martin, please keep in mind that contributions are welcome at any time. Milestones in Trac reflect our view of priorities but it doesn't prevent us from accepting correct patches from contributions at any time, no matter which priority is stated in Trac (or even if there is no ticket for it ...). -- Petr^2 Spacek Worked in my tests, I did not see any breakage. I guess we can also remove the ipa-client/ipaclient/Makefile.am while we are at it. Martin It looks like the ipaclient/Makefile.am is still being used. I tried removing it and there were errors in the build, but maybe I am wrong? Gabe ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile
On 12/01/2014 04:25 PM, Rob Crittenden wrote: Gabe Alford wrote: On Mon, Dec 1, 2014 at 6:05 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 11/30/2014 03:28 AM, Gabe Alford wrote: Ignore the last patch. Updated patch attached. On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford redhatri...@gmail.com mailto:redhatri...@gmail.com wrote: This patch removes the app_PYTHON usage. Thanks, Gabe On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: Exactly, this was the message from Martin :-) I did not test it myself, but removing all app_PYTHON should be benign given we use Python setup.py packaging. On 11/27/2014 04:27 PM, Gabe Alford wrote: Thanks guys. Sounds like it would be better to submit a patch that removes app_PYTHON if it is considered dead code. Gabe On Thursday, November 27, 2014, Petr Spacek pspa...@redhat.com mailto:pspa...@redhat.com wrote: On 27.11.2014 11:00, Martin Basti wrote: On 27/11/14 00:50, Gabe Alford wrote: Hello, Wondering if I could get a review. Updated patch attached. Thanks, Gabe On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford redhatri...@gmail.com mailto:redhatri...@gmail.com javascript:; mailto:redhatri...@gmail.com mailto:redhatri...@gmail.com javascript:; wrote: Hello, Fix for https://fedorahosted.org/freeipa/ticket/4700 Thanks, Gabe Hello, sorry for late response. We push this ticket to backlog, as it would be part of build system refactoring. The app_PYTHON statement is not used anymore in IPA, the better solution is remove it, instead of keeping dead code up-to-date. Just to clarify: It can be pushed if it works, there is no need to postpone accepting patch if the patch seems okay and doesn't break anything. Martin, please keep in mind that contributions are welcome at any time. Milestones in Trac reflect our view of priorities but it doesn't prevent us from accepting correct patches from contributions at any time, no matter which priority is stated in Trac (or even if there is no ticket for it ...). -- Petr^2 Spacek Worked in my tests, I did not see any breakage. I guess we can also remove the ipa-client/ipaclient/Makefile.am while we are at it. Martin It looks like the ipaclient/Makefile.am is still being used. I tried removing it and there were errors in the build, but maybe I am wrong? It is needed to build ipa-join, ipa-getkeytab and ipa-rmkeytab. Feel free to rip out the outdated hg ChangeLog stuff though. rob I think Gabe was asking about ipa-client/ipaclient/Makefile.am and not about ipa-client/Makefile.am - we still need this one as Rob correctly said. The failure that Gabe hit in build probably comes from the the SUBDIR reference in ipa-client/Makefile.am file. I assume that if the reference is removed, the removal should work. And yes, you can remove the Changelog too if you are OK with it :) Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0168] Better workaround to get status of CA during upgrade
On 01/12/14 08:46, Jan Cholasta wrote:
Hi,
Dne 27.11.2014 v 14:24 Martin Basti napsal(a):
Ticket: https://fedorahosted.org/freeipa/ticket/4676
Replaces current workaround. Should go to 4.1.3.
Patch attached.
When constructing URLs with host:port, please use
ipautil.format_netloc().
wget should be added as a dependency of freeipa-python in the spec file.
Honza
Updated patch attached.
--
Martin Basti
From daf56e4e4a0126f0dd528876a209f0687ca3ad06 Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Tue, 18 Nov 2014 19:49:15 +0100
Subject: [PATCH] Using wget to get status of CA
This is just workaround
Ticket: https://fedorahosted.org/freeipa/ticket/4676
---
freeipa.spec.in | 1 +
install/tools/ipa-upgradeconfig | 4
ipaplatform/redhat/services.py | 27 ++-
ipapython/dogtag.py | 18 +++---
4 files changed, 38 insertions(+), 12 deletions(-)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 95ec6210a157fd158d81d97efbd46f3d35facbc6..39166057ecd0d5a4bacef4e79bed49135f72fff4 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -292,6 +292,7 @@ Requires: python-qrcode-core = 5.0.0
Requires: python-pyasn1
Requires: python-dateutil
Requires: python-yubico
+Requires: wget
Conflicts: %{alt_name}-python
Obsoletes: %{alt_name}-python %{version}
diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig
index 32fea4d0a42ac7607fffaa17339b23267f2760f6..628fe20d7c7dbdc5aaae5cd60eb357694a3b51a5 100644
--- a/install/tools/ipa-upgradeconfig
+++ b/install/tools/ipa-upgradeconfig
@@ -1486,10 +1486,6 @@ def main():
ca.restart(dogtag.configured_constants().PKI_INSTANCE_NAME)
except ipautil.CalledProcessError, e:
root_logger.error(Failed to restart %s: %s, ca.service_name, e)
-# FIXME https://fedorahosted.org/freeipa/ticket/4676
-# workaround
-except RuntimeError as e:
-root_logger.warning(str(e))
set_sssd_domain_option('ipa_server_mode', 'True')
diff --git a/ipaplatform/redhat/services.py b/ipaplatform/redhat/services.py
index 58ffebc48477193c7203161d2578b3040862b4e6..20d0adec421ecd3285464e2a51b9d5c61a0e3d92 100644
--- a/ipaplatform/redhat/services.py
+++ b/ipaplatform/redhat/services.py
@@ -24,6 +24,7 @@ Contains Red Hat OS family-specific service class implementations.
import os
import time
+import xml.dom.minidom
from ipaplatform.tasks import tasks
from ipaplatform.base import services as base_services
@@ -185,7 +186,31 @@ class RedHatCAService(RedHatService):
op_timeout = time.time() + timeout
while time.time() op_timeout:
try:
-status = dogtag.ca_status(use_proxy=use_proxy)
+# FIXME https://fedorahosted.org/freeipa/ticket/4716
+# workaround
+#
+# status = dogtag.ca_status(use_proxy=use_proxy)
+#
+port = 8443
+if use_proxy:
+port = 443
+
+url = https://%(host_port)s%(path)s % {
+host_port: ipautil.format_netloc(api.env.ca_host, port),
+path: /ca/admin/ca/getStatus
+}
+
+args = [
+paths.BIN_WGET,
+'-S', '-O', '-',
+'--timeout=30',
+url
+]
+
+stdout, stderr, returncode = ipautil.run(args)
+
+status = dogtag._parse_ca_status(stdout)
+# end of workaround
except Exception:
status = 'check interrupted'
root_logger.debug('The CA status is: %s' % status)
diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py
index 0e0aacca798377517244075ed6b07dff63e87358..675d2a77fe30b9109c17089f129b189282ffa57b 100644
--- a/ipapython/dogtag.py
+++ b/ipapython/dogtag.py
@@ -191,6 +191,16 @@ def get_ca_certchain(ca_host=None, dogtag_constants=None):
return chain
+def _parse_ca_status(body):
+doc = xml.dom.minidom.parseString(body)
+try:
+item_node = doc.getElementsByTagName(XMLResponse)[0]
+item_node = item_node.getElementsByTagName(Status)[0]
+return item_node.childNodes[0].data
+except IndexError:
+raise error_from_xml(doc, _(Retrieving CA status failed: %s))
+
+
def ca_status(ca_host=None, use_proxy=True):
Return the status of the CA, and the httpd proxy in front of it
@@ -214,13 +224,7 @@ def ca_status(ca_host=None, use_proxy=True):
elif status != 200:
raise errors.RemoteRetrieveError(
reason=_(Retrieving CA status failed: %s) % reason)
-doc = xml.dom.minidom.parseString(body)
-try:
-item_node = doc.getElementsByTagName(XMLResponse)[0]
-item_node = item_node.getElementsByTagName(Status)[0]
-return item_node.childNodes[0].data
-except IndexError:
-raise
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On Mon, 01 Dec 2014 16:17:54 +0100 Petr Spacek pspa...@redhat.com wrote: On 14.11.2014 17:31, Petr Spacek wrote: On 14.11.2014 02:22, Simo Sorce wrote: On Tue, 11 Nov 2014 16:29:51 +0100 Petr Spacek pspa...@redhat.com wrote: Hello, this thread is about RFE IPA servers when installed should register themselves in the external DNS https://fedorahosted.org/freeipa/ticket/4424 It is not a complete design, just a raw idea. Use case FreeIPA installation to a network with existing DNS infrastructure + network administrator who is not willing to add/maintain new DNS servers just for FreeIPA. High-level idea === - Transform dns* commands from FreeIPA framework to equivalent nsupdate commands and send DNS updates to existing DNS servers. - Provide necessary encryption/signing keys to nsupdate. 1) Integration to FreeIPA framework === First of all, we need to decide if external DNS integration can be used at the same time with FreeIPA-integrated DNS or not. Side-question is what to do if a first server is installed with external-DNS but another replica is being installed with integrated-DNS and so on. I think being able to integrate with an external DNS is important, and not just at the server level, being able to distribute TSIG keys to client would be nice too, though a lot less important, than getting server integration.. Using TSIG on many clients is very problematic. Keep in mind that TSIG is basically HMAC computed using symmetric key so: a) Every client would have to use the same key - this is a security nightmare. b) We would have to distribute and maintain many keys for many^2 clients, which is an administrative nightmare. For *clients* I would rather stay with GSS-TSIG which is much more manageable because we can use Kerberos trust and Keytab distribution is already solved by ipa-client-install. Alternative for clients would be to use FreeIPA server as proxy which encapsulates TSIG keys and issues update requests on behalf of clients. This would be FreeIPA-specific but any TSIG-distribution mechanism will be FreeIPA-specific anyway. TSIG standard explicitly says that there is no standardized distribution mechanism. In other words, the question is if current dns.py plugin shipped with FreeIPA framework should be: a) Extended dns.py with dnsexternal-* commands -- Disadvantages: - It complicate FreeIPA DNS interface which is a complex beast even now. - We would have add condition to every DNS API call in installers which would increase horribleness of the installer code even more (or add another layer of abstraction...). I agree having a special command is undesirable. - I don't see a point in using integrated-DNS with external-DNS at the same time. To use integrated-DNS you have to get a proper DNS delegation from parent domain - and if you can get the delegation then there is no point in using external DNS ... I disagree on this point, it makes a lot of sense to have some zones maintained by IPA and ... some not. Advantages: - You can use external integrated DNS at the same time. We can achieve the same w/o a new ipa level command. This needs to be decided by FreeIPA framework experts ... Petr^3 came up with clever 'proxy' idea for IPA-commands. This proxy would provide all ipa dns* commands and dispatch user-issued commands to appropriate FreeIPA-plugin (internal-dns or external-dns). This decision could depend on some values in LDAP. b) Replace dns.py with another implementation of current dnszone-* dnsrecord-* API. - This seems like a cleaner approach to me. It could be shipped as ipa-server-dns-external package (opposed to standard ipa-server-dns package). Advantages: - It could seamlessly work with FreeIPA client installer because the dns*-nsupdate command transformation would be done on FreeIPA server and client doesn't need to know about it. - Does not require re-training/not much new documentation because commands are the same. Disadvantages: - You can't use integrated external DNS at the same time (but I don't think it justifies the added complexity). I disagree. One of the reason to use a mix is to allow smooth migrations where zones are moved into (or out of) IPA one by one. Good point, I agree. I will focus on supporting both (internal and external) DNS at the same time. Petr^3 or anyone else, what do you propose? I think what I'd like to see is to be able to configure a DNS zone in LDAP and mark it external. The zone would held the TSIG keys necessary to perform DNS updates. When the regular ipa dnsrecord-add etc... commands are called, the framework detects that the zone
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On Mon, 01 Dec 2014, Simo Sorce wrote: On Mon, 01 Dec 2014 16:17:54 +0100 Petr Spacek pspa...@redhat.com wrote: On 14.11.2014 17:31, Petr Spacek wrote: On 14.11.2014 02:22, Simo Sorce wrote: On Tue, 11 Nov 2014 16:29:51 +0100 Petr Spacek pspa...@redhat.com wrote: Hello, this thread is about RFE IPA servers when installed should register themselves in the external DNS https://fedorahosted.org/freeipa/ticket/4424 It is not a complete design, just a raw idea. Use case FreeIPA installation to a network with existing DNS infrastructure + network administrator who is not willing to add/maintain new DNS servers just for FreeIPA. High-level idea === - Transform dns* commands from FreeIPA framework to equivalent nsupdate commands and send DNS updates to existing DNS servers. - Provide necessary encryption/signing keys to nsupdate. 1) Integration to FreeIPA framework === First of all, we need to decide if external DNS integration can be used at the same time with FreeIPA-integrated DNS or not. Side-question is what to do if a first server is installed with external-DNS but another replica is being installed with integrated-DNS and so on. I think being able to integrate with an external DNS is important, and not just at the server level, being able to distribute TSIG keys to client would be nice too, though a lot less important, than getting server integration.. Using TSIG on many clients is very problematic. Keep in mind that TSIG is basically HMAC computed using symmetric key so: a) Every client would have to use the same key - this is a security nightmare. b) We would have to distribute and maintain many keys for many^2 clients, which is an administrative nightmare. For *clients* I would rather stay with GSS-TSIG which is much more manageable because we can use Kerberos trust and Keytab distribution is already solved by ipa-client-install. Alternative for clients would be to use FreeIPA server as proxy which encapsulates TSIG keys and issues update requests on behalf of clients. This would be FreeIPA-specific but any TSIG-distribution mechanism will be FreeIPA-specific anyway. TSIG standard explicitly says that there is no standardized distribution mechanism. In other words, the question is if current dns.py plugin shipped with FreeIPA framework should be: a) Extended dns.py with dnsexternal-* commands -- Disadvantages: - It complicate FreeIPA DNS interface which is a complex beast even now. - We would have add condition to every DNS API call in installers which would increase horribleness of the installer code even more (or add another layer of abstraction...). I agree having a special command is undesirable. - I don't see a point in using integrated-DNS with external-DNS at the same time. To use integrated-DNS you have to get a proper DNS delegation from parent domain - and if you can get the delegation then there is no point in using external DNS ... I disagree on this point, it makes a lot of sense to have some zones maintained by IPA and ... some not. Advantages: - You can use external integrated DNS at the same time. We can achieve the same w/o a new ipa level command. This needs to be decided by FreeIPA framework experts ... Petr^3 came up with clever 'proxy' idea for IPA-commands. This proxy would provide all ipa dns* commands and dispatch user-issued commands to appropriate FreeIPA-plugin (internal-dns or external-dns). This decision could depend on some values in LDAP. b) Replace dns.py with another implementation of current dnszone-* dnsrecord-* API. - This seems like a cleaner approach to me. It could be shipped as ipa-server-dns-external package (opposed to standard ipa-server-dns package). Advantages: - It could seamlessly work with FreeIPA client installer because the dns*-nsupdate command transformation would be done on FreeIPA server and client doesn't need to know about it. - Does not require re-training/not much new documentation because commands are the same. Disadvantages: - You can't use integrated external DNS at the same time (but I don't think it justifies the added complexity). I disagree. One of the reason to use a mix is to allow smooth migrations where zones are moved into (or out of) IPA one by one. Good point, I agree. I will focus on supporting both (internal and external) DNS at the same time. Petr^3 or anyone else, what do you propose? I think what I'd like to see is to be able to configure a DNS zone in LDAP and mark it external. The zone would held the TSIG keys necessary to perform DNS updates. When the regular ipa dnsrecord-add etc... commands are called, the framework detects that the zone is external, fewttches the TSIG key (if the user has access to it) and spawn an nsupdate
Re: [Freeipa-devel] [PATCH 0170] Detect and warn about invalid forwardzone configuration
On 1.12.2014 14:39, Martin Basti wrote: On 24/11/14 17:24, Petr Spacek wrote: Hello! Thank you for the patch. It is not ready yet but the overall direction seems good. Please see my comments in-line. On 24.11.2014 14:35, Martin Basti wrote: Ticket: https://fedorahosted.org/freeipa/ticket/4721 Patch attached -- Martin Basti freeipa-mbasti-0170-Detect-and-warn-about-invalid-DNS-forward-zone-confi.patch From a5a19137e3ddf2d2d48cfbdb2968b6f68ac8f772 Mon Sep 17 00:00:00 2001 From: Martin Basti mba...@redhat.com Date: Fri, 21 Nov 2014 16:54:09 +0100 Subject: [PATCH] Detect and warn about invalid DNS forward zone configuration Shows warning if forward and parent authoritative zone do not have proper NS record delegation, which can cause the forward zone will be ineffective and forwarding will not work. The chande in the test was required due python changes order of elemnts in dict (python doesnt guarantee an order in dict) Ticket: https://fedorahosted.org/freeipa/ticket/4721 --- ipalib/messages.py | 12 +++ ipalib/plugins/dns.py | 147 +--- ipatests/test_xmlrpc/test_dns_plugin.py | 2 +- 3 files changed, 149 insertions(+), 12 deletions(-) diff --git a/ipalib/messages.py b/ipalib/messages.py index 102e35275dbe37328c84ecb3cd5b2a8d8578056f..cc9bae3d6e5c7d3a7401dab89fafb1b60dc1e15f 100644 --- a/ipalib/messages.py +++ b/ipalib/messages.py @@ -200,6 +200,18 @@ class DNSServerDoesNotSupportDNSSECWarning(PublicMessage): uIf DNSSEC validation is enabled on IPA server(s), uplease disable it.) +class ForwardzoneIsNotEffectiveWarning(PublicMessage): + +**13008** Forwardzone is not effective, forwarding will not work because +there is authoritative parent zone, without proper NS delegation + + +errno = 13008 +type = warning +format = _(uforward zone \%(fwzone)s\ is not effective (missing proper + uNS delegation in authoritative zone \%(authzone)s\). + uForwarding may not work.) I think that the error message could be made mode useful: Forwarding will not work. Please add NS record fwdzone.relativize(authzone) to parent zone %(authzone)s (or something like that). + def iter_messages(variables, base): Return a tuple with all subclasses diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py index c5d96a8c4fcdf101254ecefb60cb83d63bee6310..4f92da645e0faf784c7deb4b8ce386c1440f4229 100644 --- a/ipalib/plugins/dns.py +++ b/ipalib/plugins/dns.py @@ -1725,6 +1725,79 @@ def _normalize_zone(zone): return zone +def _find_zone_which_makes_fw_zone_ineffective(fwzonename): Generally, this method finds an authoritative zone for given fwzonename. What about method name _find_auth_zone_ldap(name) ? + +Check if forward zone is effective. + +If parent zone exists as authoritative zone, forward zone will not +forward queries. It is necessary to delegate authority of forward zone I would clarify it: forward queries by default. +to another server (non IPA DNS server). I would personally omit (non IPA DNS server) because this mechanism is not related to IPA domain at all. +Example: + +Forward zone: sub.example.com +Zone: example.com + +Forwarding will not work, because server thinks it is authoritative +and returns NXDOMAIN + +Adding record: sub.example.com NS nameserver.out.of.ipa.domain. Again, this is not related to IPA domain at all. I propose this text: Adding record: sub.example.com NS ns.sub.example.com. +will delegate authority to another server, and IPA DNS server will +forward DNS queries. + +:param fwzonename: forwardzone +:return: None if effective, name of authoritative zone otherwise + +assert isinstance(fwzonename, DNSName) + +# get all zones +zones = api.Command.dnszone_find(pkey_only=True, +sizelimit=0)['result'] Ooooh, are you serious? :-) I don't like this approach, I would rather chop left-most labels from name and so dnszone_find() one by one. What if you have many DNS zones? This could be thrown away if you iterate only over relevant zones. +zonenames = [zone['idnsname'][0].make_absolute() for zone in zones] +zonenames.sort(reverse=True, key=len) # sort, we need longest match + +# check if is there a zone which can cause the forward zone will +# be ineffective +sub_of_auth_zone = None +for name in zonenames: +if fwzonename.is_subdomain(name): +sub_of_auth_zone = name +break + +if sub_of_auth_zone is None: +return None + +# check if forwardzone is delegated in authoritative zone +# test if exists and get NS record +try: +ns_records = api.Command.dnsrecord_show( +sub_of_auth_zone,
Re: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable
On 11/12/2014 11:37 PM, Nathaniel McCallum wrote: On Mon, 2014-11-10 at 08:28 +0100, Martin Kosek wrote: On 11/07/2014 04:44 PM, Petr Vobornik wrote: On 7.11.2014 08:58, Martin Kosek wrote: On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: On 10/29/2014 10:37 AM, Martin Kosek wrote: On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: This patch gives the administrator variables to control the size of the authentication and synchronization windows for OTP tokens. https://fedorahosted.org/freeipa/ticket/4511 NOTE: There is one known issue with this patch which I don't know how to solve. This patch changes the schema in install/share/60ipaconfig.ldif. On an upgrade, all of the new attributeTypes appear correctly. However, the modifications to the pre-existing objectClass do not show up on the server. What am I doing wrong? After modifying ipaGuiConfig manually, everything in this patch works just fine. This new version takes into account the new (proper) OIDs and attribute names. Thanks Nathaniel! The above known issue still remains. Petr3, any idea what could have gone wrong? ObjectClass MAY list extension should work just fine, AFAIK. You added a blank line to the LDIF file. This is an entry separator, so the objectClasses after the blank line don't belong to cn=schema, so they aren't considered in the update. Without the blank line it works fine. Thanks for the catch! Here is a version without the blank line. I forgot to remove the old steps defines. This patch performs this cleanup. I am now wondering, is the global config object really the nest place to add these OTP specific settings? I would prefer not to overload the object and instead: - create new ipaOTPConfig objectclass - add it to cn=otp,$SUFFIX - create otpconfig-mod and otpconfig-show commands to follow an example of dnsconfig-* and trustconfig-* commands IMO, this would allow more flexibility for the OTP settings and would also scale better for the future updates. +1 I will comment the patch as if ^^ would not exist because it will still be needed in the new plugin. Because of ^^ I did not test, just read. 1. Got: install/ui/src/freeipa/serverconfig.js(135): lint warning: extra comma is not recommended in array initializers Please run: jsl -nofilelisting -nosummary -nologo -conf jsl.conf in install/ui directory The goal is no have no warnings and errors. 2. new attrs should be added to 'System: Read Global Configuration' managed permission +1. Though if we go with OTP config, it should be called System: Read OTP Configuration Martin Attached is a new set of patches that replaces this single patch. This now fixes multiple issues. I now create two new entries: * cn=TOTP,cn=Token Config,cn=etc,$SUFFIX * cn=HOTP,cn=Token Config,cn=etc,$SUFFIX There are two corresponding CLI commands: * totpconfig-(show|mod) * hotpconfig-(show|mod) There is no UI support for this yet (pointers welcome). This is designed so that eventually tokens can grow a per-token override, but I have not yet implemented this feature (it should be easy in the future). Additionally, I had to do some shared refactoring to address issues in ipa-otp-lasttoken, which is why all of these are now merged into a single patch set. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Hello Nathaniel, Sorry for this long delay. The patch 0001 is fine for me. Ack I have a question regarding 0002. The function 'otp_config_update' is called in postop in order to 'update' the configuration in case of successful op. In 'update' it can updates 'config_record-value. In case the SLAPI_ENTRY_POST_OP sdn is not the the config_rec-sdn but the SLAPI_TARGET_SDN sdn is the config_rec-sdn , it resets 'config_record'-value to 'config_record-dflt'. Is that the expected effect ? thanks thierry ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 792 add --hosts option to allow/retrieve keytab methods
On 12/01/2014 02:33 PM, Jan Cholasta wrote:
Hi,
Dne 1.12.2014 v 14:17 Petr Vobornik napsal(a):
`--hosts` option added to:
* service-allow-create-keytab
* service-allow-retrieve-keytab
* service-disallow-create-keytab
* service-disallow-retrieve-keytab
* host-allow-create-keytab
* host-allow-retrieve-keytab
* host-disallow-create-keytab
* host-disallow-retrieve-keytab
in order to allow hosts to retrieve keytab of their services or related
hosts as described on http://www.freeipa.org/page/V4/Keytab_Retrieval
design page
https://fedorahosted.org/freeipa/ticket/4777
Since groups of users are supported with group members, we should
probably also support groups of hosts with hostgroup members, for
consistency.
--hostgroup options added.
I'm pondering how to handle Web UI. I'm not font of adding a third pair
of tables to host and service details pages because the amount of space
on the page required for the keytab management is much bigger than its
importance compared to other fields.
Honza
--
Petr Vobornik
From aed7cb6a62ee55a982dcf8aca7da9ac1cd747833 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Mon, 1 Dec 2014 10:15:21 +0100
Subject: [PATCH] add --hosts and --hostgroup options to allow/retrieve keytab
methods
`--hosts` and `--hostgroup` options added to:
* service-allow-create-keytab
* service-allow-retrieve-keytab
* service-disallow-create-keytab
* service-disallow-retrieve-keytab
* host-allow-create-keytab
* host-allow-retrieve-keytab
* host-disallow-create-keytab
* host-disallow-retrieve-keytab
in order to allow hosts to retrieve keytab of their services or related hosts as described on http://www.freeipa.org/page/V4/Keytab_Retrieval design page
https://fedorahosted.org/freeipa/ticket/4777
---
API.txt | 32 ++--
VERSION | 4 +-
ipalib/plugins/host.py | 28 +--
ipalib/plugins/service.py | 28 +--
ipatests/test_xmlrpc/test_host_plugin.py| 109 ++--
ipatests/test_xmlrpc/test_service_plugin.py | 92 ---
6 files changed, 257 insertions(+), 36 deletions(-)
diff --git a/API.txt b/API.txt
index 2a63f1e2349f0df69433fa7cb742e269cd42d79f..e9768bf1e87d6679c439b98ed696b720937099d2 100644
--- a/API.txt
+++ b/API.txt
@@ -1826,10 +1826,12 @@ output: Output('completed', type 'int', None)
output: Output('failed', type 'dict', None)
output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
command: host_allow_create_keytab
-args: 1,6,3
+args: 1,8,3
arg: Str('fqdn', attribute=True, cli_name='hostname', multivalue=False, primary_key=True, query=True, required=True)
option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
option: Str('group*', alwaysask=True, cli_name='groups', csv=True)
+option: Str('host*', alwaysask=True, cli_name='hosts', csv=True)
+option: Str('hostgroup*', alwaysask=True, cli_name='hostgroups', csv=True)
option: Flag('no_members', autofill=True, default=False, exclude='webui')
option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
option: Str('user*', alwaysask=True, cli_name='users', csv=True)
@@ -1838,10 +1840,12 @@ output: Output('completed', type 'int', None)
output: Output('failed', type 'dict', None)
output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
command: host_allow_retrieve_keytab
-args: 1,6,3
+args: 1,8,3
arg: Str('fqdn', attribute=True, cli_name='hostname', multivalue=False, primary_key=True, query=True, required=True)
option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
option: Str('group*', alwaysask=True, cli_name='groups', csv=True)
+option: Str('host*', alwaysask=True, cli_name='hosts', csv=True)
+option: Str('hostgroup*', alwaysask=True, cli_name='hostgroups', csv=True)
option: Flag('no_members', autofill=True, default=False, exclude='webui')
option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
option: Str('user*', alwaysask=True, cli_name='users', csv=True)
@@ -1866,10 +1870,12 @@ output: Output('result', type 'bool', None)
output: Output('summary', (type 'unicode', type 'NoneType'), None)
output: PrimaryKey('value', None, None)
command: host_disallow_create_keytab
-args: 1,6,3
+args: 1,8,3
arg: Str('fqdn', attribute=True, cli_name='hostname', multivalue=False, primary_key=True, query=True, required=True)
option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
option: Str('group*', alwaysask=True, cli_name='groups', csv=True)
+option: Str('host*', alwaysask=True, cli_name='hosts', csv=True)
+option: Str('hostgroup*', alwaysask=True, cli_name='hostgroups', csv=True)
option: Flag('no_members', autofill=True, default=False, exclude='webui')
option: Flag('raw', autofill=True,
