Re: [Freeipa-devel] [PATCH 0045] Add message for skipping NTP configuration during client install
On 02/04/15 17:47, Gabe Alford wrote: On Thu, Apr 2, 2015 at 8:59 AM, Martin Basti mba...@redhat.com mailto:mba...@redhat.com wrote: On 30/03/15 15:25, Gabe Alford wrote: Hello, With the merging of ticket 4842 https://fedorahosted.org/freeipa/ticket/4842, I believe that half of ticket 3092 https://fedorahosted.org/freeipa/ticket/3092 has been done. This patch just adds a message that says that NTP configuration was skipped which I believe should finish 3092 https://fedorahosted.org/freeipa/ticket/3092. Thanks, Gabe Hello, thank you for the patch. 1) IMO there should be: if *not* options.conf_ntp So, if --no-ntp is not specified, print message that the client is skipping NTP sync? Yes, or did I miss something? I though the message should be shown only if --no-ntp option is used. With your current patch: # ipa-client-install --no-ntp no ntp related output no INFO msg: skipping... # ipa-client-install output omitted / Attempting to sync time using ntpd. Will timeout after 15 seconds Unable to sync time with IPA NTP server, assuming the time is in sync. Please check that 123 UDP port is opened. Skipping synchronizing time with IPA NTP server. output omitted / But in this case the client did synchronization with NTP (which failed), IMO the message Skipping ... should not be there. This message is shown even the synchronization with NTP is successful. 2) wouldnt be better to use just else? I actually ran ipa-client-install with no options on a system where I used 'else', and it printed the skipping NTP sync when it should not have. That is why the patch does not use 'else'. Interesting, I expected the messages only on client installed on IPA server, or with using --no-ntp option Martin -- Martin Basti -- Martin Basti -- 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
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
On 12.3.2015 12:21, Petr Spacek wrote: On 11.3.2015 17:02, Martin Kosek wrote: On 03/11/2015 04:55 PM, Petr Spacek wrote: On 11.3.2015 15:45, Martin Kosek wrote: On 03/11/2015 03:38 PM, Petr Spacek wrote: On 11.3.2015 15:28, Martin Kosek wrote: On 03/11/2015 12:43 PM, Petr Spacek wrote: On 11.3.2015 11:34, Jan Cholasta wrote: Dne 11.3.2015 v 11:12 Petr Spacek napsal(a): On 10.3.2015 20:04, Simo Sorce wrote: On Tue, 2015-03-10 at 19:24 +0100, Petr Spacek wrote: On 10.3.2015 18:36, Simo Sorce wrote: On Tue, 2015-03-10 at 18:26 +0100, Petr Spacek wrote: On 10.3.2015 17:35, Simo Sorce wrote: On Tue, 2015-03-10 at 16:19 +0100, Petr Spacek wrote: On 10.3.2015 15:53, Simo Sorce wrote: On Tue, 2015-03-10 at 15:32 +0100, Petr Spacek wrote: Hello, I would like to discuss Generic support for unknown DNS RR types (RFC 3597 [0]). Here is the proposal: LDAP schema === - 1 new attribute: ( OID NAME 'GenericRecord' DESC 'unknown DNS record, RFC 3597' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) The attribute should be added to existing idnsRecord object class as MAY. This new attribute should contain data encoded according to RFC 3597 section 5 [5]: The RDATA section of an RR of unknown type is represented as a sequence of white space separated words as follows: The special token \# (a backslash immediately followed by a hash sign), which identifies the RDATA as having the generic encoding defined herein rather than a traditional type-specific encoding. An unsigned decimal integer specifying the RDATA length in octets. Zero or more words of hexadecimal data encoding the actual RDATA field, each containing an even number of hexadecimal digits. If the RDATA is of zero length, the text representation contains only the \# token and the single zero representing the length. Examples from RFC: a.example. CLASS32 TYPE731 \# 6 abcd ( ef 01 23 45 ) b.example. HS TYPE62347 \# 0 e.example. IN A \# 4 0A01 e.example. CLASS1 TYPE1 10.0.0.2 Open questions about LDAP format Should we include \# constant? We know that the attribute contains record in RFC 3597 syntax so it is not strictly necessary. I think it would be better to follow RFC 3597 format. It allows blind copypasting from other tools, including direct calls to python-dns. It also eases writing conversion tools between DNS and LDAP format because they do not need to change record values. Another question is if we should explicitly include length of data represented in hexadecimal notation as a decimal number. I'm very strongly inclined to let it there because it is very good sanity check and again, it allows us to re-use existing tools including parsers. I will ask Uninett.no for standardization after we sort this out (they own the OID arc we use for DNS records). Attribute usage === Every DNS RR type has assigned a number [1] which is used on wire. RR types which are unknown to the server cannot be named by their mnemonic/type name because server would not be able to do name-number conversion and to generate DNS wire format. As a result, we have to encode the RR type number somehow. Let's use attribute sub-types. E.g. a record with type 65280 and hex value 0A01 will be represented as: GenericRecord;TYPE65280: \# 4 0A01 CLI === $ ipa dnsrecord-add zone.example owner \ --generic-type=65280 --generic-data='\# 4 0A01' $ ipa dnsrecord-show zone.example owner Record name: owner TYPE65280 Record: \# 4 0A01 ACK? :-) Almost. We should refrain from using subtypes when not necessary, and in this case it is not necessary. Use: GenericRecord: 65280 \# 4 0A01 I was considering that too but I can see two main drawbacks: 1) It does not work very well with DS ACI (targetattrfilter, anyone?). Adding generic write access to GenericRecord == ability to add TLSA records too, which you may not want. IMHO it is perfectly reasonable to limit write access to certain types (e.g. to one from private range). 2) We would need a separate substring index for emulating filters like (type==65280). AFAIK GenericRecord;TYPE65280 should work with presence index which will be handy one day when we decide to handle upgrades like GenericRecord;TYPE256-UriRecord. Another (less important) annoyance is that conversion tools would have to mangle record data instead of just converting attribute name-record type. I can be convinced that subtypes are not necessary but I do not see clear advantage of avoiding them. What is the problem with subtypes? Poor support by most clients, so it is generally discouraged.
Re: [Freeipa-devel] [PATCH 0045] Add message for skipping NTP configuration during client install
Stupid me. I realized that chronyd was running which messed up my testing
and such (sorry about that). New patch attached that implements 'else'
On Tue, Apr 7, 2015 at 2:32 AM, Martin Basti mba...@redhat.com wrote:
On 02/04/15 17:47, Gabe Alford wrote:
On Thu, Apr 2, 2015 at 8:59 AM, Martin Basti mba...@redhat.com wrote:
On 30/03/15 15:25, Gabe Alford wrote:
Hello,
With the merging of ticket 4842
https://fedorahosted.org/freeipa/ticket/4842, I believe that half of
ticket 3092 https://fedorahosted.org/freeipa/ticket/3092 has been
done. This patch just adds a message that says that NTP configuration was
skipped which I believe should finish 3092
https://fedorahosted.org/freeipa/ticket/3092.
Thanks,
Gabe
Hello, thank you for the patch.
1)
IMO there should be:
if *not* options.conf_ntp
So, if --no-ntp is not specified, print message that the client is
skipping NTP sync?
Yes, or did I miss something? I though the message should be shown only if
--no-ntp option is used.
With your current patch:
# ipa-client-install --no-ntp
no ntp related output
no INFO msg: skipping...
# ipa-client-install
output omitted /
Attempting to sync time using ntpd. Will timeout after 15 seconds
Unable to sync time with IPA NTP server, assuming the time is in sync.
Please check that 123 UDP port is opened.
Skipping synchronizing time with IPA NTP server.
output omitted /
But in this case the client did synchronization with NTP (which failed),
IMO the message Skipping ... should not be there.
This message is shown even the synchronization with NTP is successful.
2)
wouldnt be better to use just else?
I actually ran ipa-client-install with no options on a system where I
used 'else', and it printed the skipping NTP sync when it should not have.
That is why the patch does not use 'else'.
Interesting, I expected the messages only on client installed on IPA
server, or with using --no-ntp option
Martin
--
Martin Basti
--
Martin Basti
From 4422cab165a648d8657be70d1deea1b0a834f183 Mon Sep 17 00:00:00 2001
From: Gabe redhatri...@gmail.com
Date: Tue, 7 Apr 2015 08:54:30 -0600
Subject: [PATCH] Add message for skipping NTP configuration during client
install
https://fedorahosted.org/freeipa/ticket/3092
---
ipa-client/ipa-install/ipa-client-install | 2 ++
1 file changed, 2 insertions(+)
diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install
index e31d83dc98d411d281c9913af6cd45b41e2b51a1..1590a08600bbb1b2fd7f4c3338b5060156d7dc38 100755
--- a/ipa-client/ipa-install/ipa-client-install
+++ b/ipa-client/ipa-install/ipa-client-install
@@ -2343,6 +2343,8 @@ def install(options, env, fstore, statestore):
root_logger.warning(Unable to sync time with IPA NTP +
server, assuming the time is in sync. Please check +
that 123 UDP port is opened.)
+else:
+root_logger.info('Skipping synchronizing time with IPA NTP server.')
if not options.unattended:
if (options.principal is None and options.password is None and
--
1.8.3.1
--
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
Re: [Freeipa-devel] [PATCH 0210] DNSSEC: CI test
On 03/23/2015 03:54 PM, Martin Basti wrote: Hello, a patch with DNSSEC CI tests attached. * Two types of installation tested * Tests check if zones are signed on both replica and master * The root zone test also checks chain of trust Can somebody very familiar with pytest do review? I'm not sure If I used pytest friendly constructions. PS: test may failure occasionally due a bug in DNSSEC code, but CI test itself should be OK Useful information: http://www.freeipa.org/page/Howto/DNSSEC Hello, the patch looks good to me. Fix the pep8 complaints please (unused imports and long lines). Thanks, Milan -- 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
Re: [Freeipa-devel] New installer PoC
On 23/03/15 09:03, Jan Cholasta wrote: Hi, the attached patch contains a new PoC installer for httpd. Design goals: 1) Make code related to any particular configuration change co-located, be it install/uninstall/upgrade. 2) Get rid of code duplicates. 3) Use the same code path for install and upgrade. 4) Provide metadata for parameters from which option parsers etc. can be generated. 5) Make installers plugable. This is not really apparent from the patch, since it only implements installer for a single component, but I plan to make the whole thing extensible by plugins. Honza Looks good to me, after personal discussion with Honza. Martin^2 -- Martin Basti -- 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
Re: [Freeipa-devel] [PATCH 0045] Add message for skipping NTP configuration during client install
On 07/04/15 17:06, Gabe Alford wrote: Stupid me. I realized that chronyd was running which messed up my testing and such (sorry about that). New patch attached that implements 'else' On Tue, Apr 7, 2015 at 2:32 AM, Martin Basti mba...@redhat.com mailto:mba...@redhat.com wrote: On 02/04/15 17:47, Gabe Alford wrote: On Thu, Apr 2, 2015 at 8:59 AM, Martin Basti mba...@redhat.com mailto:mba...@redhat.com wrote: On 30/03/15 15:25, Gabe Alford wrote: Hello, With the merging of ticket 4842 https://fedorahosted.org/freeipa/ticket/4842, I believe that half of ticket 3092 https://fedorahosted.org/freeipa/ticket/3092 has been done. This patch just adds a message that says that NTP configuration was skipped which I believe should finish 3092 https://fedorahosted.org/freeipa/ticket/3092. Thanks, Gabe Hello, thank you for the patch. 1) IMO there should be: if *not* options.conf_ntp So, if --no-ntp is not specified, print message that the client is skipping NTP sync? Yes, or did I miss something? I though the message should be shown only if --no-ntp option is used. With your current patch: # ipa-client-install --no-ntp no ntp related output no INFO msg: skipping... # ipa-client-install output omitted / Attempting to sync time using ntpd. Will timeout after 15 seconds Unable to sync time with IPA NTP server, assuming the time is in sync. Please check that 123 UDP port is opened. Skipping synchronizing time with IPA NTP server. output omitted / But in this case the client did synchronization with NTP (which failed), IMO the message Skipping ... should not be there. This message is shown even the synchronization with NTP is successful. 2) wouldnt be better to use just else? I actually ran ipa-client-install with no options on a system where I used 'else', and it printed the skipping NTP sync when it should not have. That is why the patch does not use 'else'. Interesting, I expected the messages only on client installed on IPA server, or with using --no-ntp option Martin -- Martin Basti -- Martin Basti Thank you! ACK -- Martin Basti -- 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
