Re: [Freeipa-devel] [PATCH] [DOC] Add note about additional nameservers in resolv.conf
On 27.3.2014 00:40, Gabe Alford wrote: All, Please review patch for https://fedorahosted.org/freeipa/ticket/3085 Added note that 'nameserver 127.0.0.1' is added to resolv.conf, that it is recommended to add more replicas to resolv.conf, and the max nameservers allowed in resolv.conf. Thank you for the patch! Conditional ACK, please remove trailing whitespaces before push. -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] [DOC] Add note about additional nameservers in resolv.conf
On 03/27/2014 09:42 AM, Petr Spacek wrote: On 27.3.2014 00:40, Gabe Alford wrote: All, Please review patch for https://fedorahosted.org/freeipa/ticket/3085 Added note that 'nameserver 127.0.0.1' is added to resolv.conf, that it is recommended to add more replicas to resolv.conf, and the max nameservers allowed in resolv.conf. Thank you for the patch! Conditional ACK, please remove trailing whitespaces before push. Thanks! Pushed to docs master: a2f5d7ed8fe49e8ad1cfbf29ddfe563de235e8ac -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] [DOC] Add note about additional nameservers in resolv.conf
On Wed, 2014-03-26 at 17:40 -0600, Gabe Alford wrote: All, Please review patch for https://fedorahosted.org/freeipa/ticket/3085 Added note that 'nameserver 127.0.0.1' is added to resolv.conf, that it is recommended to add more replicas to resolv.conf, and the max nameservers allowed in resolv.conf. Actually, my ipa-server-install puts into /etc/resolv.conf its ip address itself not localhost After fresh install: #cat /etc/resolv.conf search example.com nameserver 10.*.*.* thanks, Gabe ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Martin^2 Basti ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] [DOC] Add note about additional nameservers in resolv.conf
On 27.3.2014 10:23, Martin Basti wrote: On Wed, 2014-03-26 at 17:40 -0600, Gabe Alford wrote: All, Please review patch for https://fedorahosted.org/freeipa/ticket/3085 Added note that 'nameserver 127.0.0.1' is added to resolv.conf, that it is recommended to add more replicas to resolv.conf, and the max nameservers allowed in resolv.conf. Actually, my ipa-server-install puts into /etc/resolv.conf its ip address itself not localhost After fresh install: #cat /etc/resolv.conf search example.com nameserver 10.*.*.* IMHO /etc/resolv.conf was overwritten by DHCPd (when IPA installation was finished). -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] [DOC] Add note about additional nameservers in resolv.conf
On Thu, 2014-03-27 at 10:33 +0100, Petr Spacek wrote: On 27.3.2014 10:23, Martin Basti wrote: On Wed, 2014-03-26 at 17:40 -0600, Gabe Alford wrote: All, Please review patch for https://fedorahosted.org/freeipa/ticket/3085 Added note that 'nameserver 127.0.0.1' is added to resolv.conf, that it is recommended to add more replicas to resolv.conf, and the max nameservers allowed in resolv.conf. Actually, my ipa-server-install puts into /etc/resolv.conf its ip address itself not localhost After fresh install: #cat /etc/resolv.conf search example.com nameserver 10.*.*.* IMHO /etc/resolv.conf was overwritten by DHCPd (when IPA installation was finished). I inspect ipa-server-install source code and installation adds to resolv.conf a real server address. DHCP leave note in resolv.conf when generate it. -- Martin^2 Basti ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] [DOC] Review section on NetworkManager
On Wed, Mar 26, 2014 at 05:30:13PM -0600, Gabe Alford wrote: All, Please review this patch for https://fedorahosted.org/freeipa/ticket/4156 Added links to documentation on configuring NetworkManager. Thank you for the patch. ACK. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] FreeIPA 3.3.5
Hello all! I think we are close to releasing next bugfixing version on FreeIPA 3.3.5. We have a lot of bug fixes to offer, especially in the AD Trust area. I wrote the changelog to our wiki, fixes or suggestions welcome: http://www.freeipa.org/page/Releases/3.3.5 I have just one last concern though, the remaining PKI clone installation issue I found: https://fedorahosted.org/pki/ticket/933 Do we want to release before this ticket is closed or wait? Question is if fixing Dogtag 10 based clone installation is enough to allow us to release or not. Matthew (CCed), do we have any ETA when the fix would be available? -- Martin Kosek mko...@redhat.com Supervisor, Software Engineering - Identity Management Team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 561 webui: make navigation module independent on app module
On 26.3.2014 15:36, Misnyovszki Adam wrote: On Wed, 19 Mar 2014 16:02:19 +0100 Petr Vobornik pvobo...@redhat.com wrote: When some module used 'freeipa/navigation' it pulled the entire Web UI because navigation depended on app. This patch splits the app into two modules: app and app_container. App specifies the entities which are part of final application. app_container module represents the application boot classes. Navigation now depends on app_container. Hi, tests ran as expected, and it works, so ACK. Note: there are two typos in copyright, app.js:5(./), app_container.js:1(space before comment), should be corrected before push. Thanks Adam Typos in comments fixed. Pushed to master: e7bfac1e63360993aea2be91082ca69c478f3cf1 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0158] Extend ipa-range-check DS plugin to handle range types
The updated version handles the ret variable properly. It also makes
sure the memory is properly freed.
On 03/18/2014 04:45 PM, Alexander Bokovoy wrote:
On Tue, 18 Mar 2014, Tomas Babej wrote:
On 03/18/2014 09:19 AM, Alexander Bokovoy wrote:
On Mon, 17 Mar 2014, Tomas Babej wrote:
Hi,
The ipa-range-check plugin used to determine the range type depending
on the value of the attributes such as RID or secondary RID base. This
approached caused variety of issues since the portfolio of ID range
types expanded.
The patch makes sure the following rules are implemented:
* No ID range pair can overlap on base ranges, with exception
of two ipa-ad-trust-posix ranges belonging to the same forest
* For any ID range pair of ranges belonging to the same domain:
* Both ID ranges must be of the same type
* For ranges of ipa-ad-trust type or ipa-local type:
* Primary RID ranges can not overlap
* For ranges of ipa-local type:
* Primary and secondary RID ranges can not overlap
* Secondary RID ranges cannot overlap
For the implementation part, the plugin was extended with a domain ID
to forest root domain ID mapping derivation capabilities.
https://fedorahosted.org/freeipa/ticket/4137
Test coverage coming soon!
I don't really like that you are using a list here. The list is built
and then destroyed in preop callback every time we process the range
object, so it is one-off operation. Now, when you fetch trust domain
objects to build the list, why can't you use an array directly?
Given that all you need the list for is to map domain to a trust (if
any) and trust name is the name of the root level domain, you can
simply
make an array of a struct (name, root) where root is a and index to the
same array or -1 if this is the root domain itself.
I don't see much benefit of using array over linked list in this case.
In both cases, we would need to build the data container, and it would
be one-off operation (once for the ADD/MOD operation).
Additionaly, using linked list, I can only pass around the pointer to
the head of the list, instead of passing around the array and it's
size.
If you make a {NULL, NULL} entry as the last one, no need to pass array
size. But anyway...
I reworked the part of the patch that fetches the data from the LDAP as
we discussed. Instead of performing multiple LDAP searches, we do a
single extra search per operation.
See comments below.
+static struct domain_info* build_domain_to_forest_root_map(struct
domain_info *head,
+ struct
ipa_range_check_ctx *ctx){
+
+Slapi_PBlock *trusted_domain_search_pb = NULL;
+Slapi_Entry **trusted_domain_entries = NULL;
+Slapi_DN *base_dn = NULL;
+Slapi_RDN *rdn = NULL;
+
+int search_result;
+int ret;
+
+/* Set the base DN for the search to cn=ad, cn=trusts, $SUFFIX */
+base_dn = slapi_sdn_new_dn_byref(ctx-base_dn);
+if (base_dn == NULL) {
+LOG_FATAL(Failed to convert base DN.\n);
+ret = LDAP_OPERATIONS_ERROR;
+goto done;
+}
+
+rdn = slapi_rdn_new();
+if (rdn == NULL) {
+LOG_FATAL(Failed to obtain RDN struct.\n);
+ret = LDAP_OPERATIONS_ERROR;
+goto done;
+}
+
+slapi_rdn_add(rdn, cn, trusts);
+slapi_sdn_add_rdn(base_dn, rdn);
+slapi_rdn_done(rdn);
+
+slapi_rdn_add(rdn, cn, ad);
+slapi_sdn_add_rdn(base_dn, rdn);
+slapi_rdn_done(rdn);
given that slapi_search_internal_set_pb() wants 'const char *base', why
not use asprintf() instead?
Here is what we do in ipa-kdb:
ret = asprintf(base, cn=ad,cn=trusts,%s, ipactx-base);
if (ret == -1) {
ret = ENOMEM;
goto done;
}
That's enough, IMHO. 389-ds internally will anyway create new sdn
explicitly from a string you've passed.
+
+/* Allocate a new parameter block */
+trusted_domain_search_pb = slapi_pblock_new();
+if (trusted_domain_search_pb == NULL) {
+LOG_FATAL(Failed to create new pblock.\n);
+ret = LDAP_OPERATIONS_ERROR;
in done: label you don't deal with 'ret' at all. Do you need it?
+//goto done;
is it goto or not?
+}
+
+/* Search for all the root domains, note the LDAP_SCOPE_ONELEVEL */
+slapi_search_internal_set_pb(trusted_domain_search_pb,
+ slapi_sdn_get_dn(base_dn),
here just use 'base_dn'.
+ LDAP_SCOPE_SUBTREE, DOMAIN_ID_FILTER,
+ NULL, 0, NULL, NULL,
ctx-plugin_id, 0);
+
+ret = slapi_search_internal_pb(trusted_domain_search_pb);
+if (ret != 0) {
+LOG_FATAL(Starting internal search failed.\n);
+goto done;
make sure you are consistent with 'ret' -- either handling it or not,
and if overriding with LDAP_OPERATIONS_ERROR, make sure it is overridden
everywhere.
+}
+
[Freeipa-devel] [PATCH 0161] ipa-range-check: Fix memory leaks when freeing range object
Hi,
When cleaning the range_info struct, simple free of the struct
is not enough, we have to free contents of char pointers in the
struct as well.
https://fedorahosted.org/freeipa/ticket/4276
--
Tomas Babej
Associate Software Engineer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org
From 4752dd7cf5470e4da709ce0f31b9f8d408b79737 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Thu, 27 Mar 2014 13:03:33 +0100
Subject: [PATCH] ipa-range-check: Fix memory leaks when freeing range object
When cleaning the range_info struct, simple free of the struct
is not enough, we have to free contents of char pointers in the
struct as well.
https://fedorahosted.org/freeipa/ticket/4276
---
.../ipa-slapi-plugins/ipa-range-check/ipa_range_check.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
index 0ef33e5869bbcb4f721394ce35e2338095bf5d36..c877a7dc445b31b3de085aa66028d7652df6b9cc 100644
--- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
+++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c
@@ -96,6 +96,15 @@ struct domain_info {
struct domain_info *next;
};
+static void free_range_info(struct range_info *range) {
+if (range != NULL) {
+slapi_ch_free_string((range-name));
+slapi_ch_free_string((range-domain_id));
+slapi_ch_free_string((range-forest_root_id));
+slapi_ch_free_string((range-id_range_type));
+free(range);
+}
+}
static void free_domain_info(struct domain_info *info) {
if (info != NULL) {
@@ -323,7 +332,7 @@ static int slapi_entry_to_range_info(struct domain_info *domain_info_head,
done:
if (ret != 0) {
-free(range);
+free_range_info(range);
}
return ret;
@@ -598,7 +607,7 @@ static int ipa_range_check_pre_op(Slapi_PBlock *pb, int modtype)
}
ranges_valid = check_ranges(new_range, old_range);
-free(old_range);
+free_range_info(old_range);
old_range = NULL;
if (ranges_valid != 0) {
ret = LDAP_CONSTRAINT_VIOLATION;
@@ -638,8 +647,8 @@ done:
slapi_free_search_results_internal(search_pb);
slapi_pblock_destroy(search_pb);
slapi_sdn_free(dn);
-free(old_range);
-free(new_range);
+free_range_info(old_range);
+free_range_info(new_range);
if (free_entry) {
slapi_entry_free(entry);
}
--
1.8.5.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0015] Add wait_for_dns option to default.conf
On 02/20/2014 03:56 PM, Martin Basti wrote:
On Thu, 2014-02-20 at 14:36 +0100, Petr Spacek wrote:
On 19.2.2014 17:55, Martin Basti wrote:
On Wed, 2014-02-19 at 17:10 +0100, Petr Spacek wrote:
On 19.2.2014 15:11, Petr Spacek wrote:
On 18.2.2014 17:34, Nathaniel McCallum wrote:
On Tue, 2014-02-18 at 17:06 +0100, Petr Viktorin wrote:
On 02/18/2014 04:45 PM, Petr Spacek wrote:
Hello,
Add wait_for_dns option to default.conf.
This option makes record changes in DNS tree synchronous.
IPA calls will wait until new data are visible over DNS protocol.
It is intended only for testing - it should prevent tests from
failing if there is bigger delay between change in LDAP and DNS.
I would recommend value like 10 seconds.
Here are a few Python nitpicks you requested.
Thank you very much. This new version solves problems you found + adds
proper
handling for real DNS timeouts.
It seems to me like a more general TimeoutError would be useful in a
broader context. DNSTimeout seems overly narrow to me, unless I'm
missing something.
I would like to keep them separate. DNSTimeout shouldn't be handled at all
because it means that your DNS server or database is dead or broken in
some
interesting way.
I assume that generic TimeoutError could be interpreted as 'try it
again'/'failover' or something like that.
Maybe the DNSTimeout is not the best name, I'm open to suggestions.
I have sent the old version with new name, gggrrr.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Tests failed:
test_dns[92]: dnsrecord_add: Add A record to u'ns2' in zone
u'zone3.test' ... ok
File /usr/lib/python2.7/site-packages/nose/case.py, line 197, in
runTest
self.test(*self.arg)
File /root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py, line 291, in
lambda
func = lambda: self.check(nice, **test)
File /root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py, line 309, in
check
self.check_output(nice, cmd, args, options, expected, extra_check)
File /root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py, line 348, in
check_output
got = api.Command[cmd](*args, **options)
File /root/freeipa/ipalib/frontend.py, line 436, in __call__
ret = self.run(*args, **options)
File /root/freeipa/ipalib/frontend.py, line 761, in run
return self.forward(*args, **options)
File /root/freeipa/ipalib/frontend.py, line 782, in forward
return self.Backend.rpcclient.forward(self.name, *args, **kw)
File /root/freeipa/ipalib/rpc.py, line 836, in forward
return self._call_command(command, params)
File /root/freeipa/ipalib/rpc.py, line 813, in _call_command
return command(*params)
File /root/freeipa/ipalib/rpc.py, line 951, in _call
return self.__request(name, args)
File /root/freeipa/ipalib/rpc.py, line 945, in __request
raise error_class(message=error['message'])
DNSTimeout: DNS query timeout: Expected {_kerberos.zone2.test. 86400 IN
TXT IDM.LAB.ENG.BRQ.REDHAT.COM} got {SERVFAIL}
==
ERROR: test_dns[51]: dnsrecord_add: Add NS+DNAME record to u'zone2.test'
zone record using dnsrecord_add
--
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/nose/case.py, line 197, in
runTest
self.test(*self.arg)
File /root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py, line 291, in
lambda
func = lambda: self.check(nice, **test)
File /root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py, line 309, in
check
self.check_output(nice, cmd, args, options, expected, extra_check)
File /root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py, line 348, in
check_output
got = api.Command[cmd](*args, **options)
File /root/freeipa/ipalib/frontend.py, line 436, in __call__
ret = self.run(*args, **options)
File /root/freeipa/ipalib/frontend.py, line 761, in run
return self.forward(*args, **options)
File /root/freeipa/ipalib/frontend.py, line 782, in forward
return self.Backend.rpcclient.forward(self.name, *args, **kw)
File /root/freeipa/ipalib/rpc.py, line 836, in forward
return self._call_command(command, params)
File /root/freeipa/ipalib/rpc.py, line 813, in _call_command
return command(*params)
File /root/freeipa/ipalib/rpc.py, line 951, in _call
return self.__request(name, args)
File /root/freeipa/ipalib/rpc.py, line 945, in __request
raise error_class(message=error['message'])
DNSTimeout: DNS query timeout: Expected {zone2.test. 86400 IN NS
ns1.dnszone.test.
zone2.test. 86400 IN NS ns1.zone2.test.} got {SERVFAIL}
configuration was: wait_for_dns=10
All tests passed without wait_for_dns option.
Sometimes at first run, I get only error and testing is interrupted.
I hope I covered all
Re: [Freeipa-devel] [PATCH] 562-563 webui: move RPC code from IPA module to its own module
On Wed, 19 Mar 2014 16:02:29 +0100 Petr Vobornik pvobo...@redhat.com wrote: depends on path #561(make navigation module independent on app module) [PATCH] 562 webui: move RPC code from IPA module to its own module - moves RPC code from ipa.js to it's own module - part of ongoing effort where the ultimate goal is to get rid of ipa.js and IPA namespace [PATCH] 563 webui: replace IPA.command usage with rpc.command Replace all IPA.command, IPA.batch_command and IPA.concurrent_command usages by equivalents from rpc module. ACK Greets Adam ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0034] Deny LDAP binds for user accounts with expired principal
On 01/07/2014 01:47 PM, Tomas Babej wrote:
On 01/07/2014 07:23 AM, Alexander Bokovoy wrote:
On Mon, 06 Jan 2014, Tomas Babej wrote:
On 01/06/2014 12:16 PM, Tomas Babej wrote:
On 04/15/2013 12:43 PM, Tomas Babej wrote:
On 04/08/2013 03:55 PM, Martin Kosek wrote:
On 04/01/2013 09:52 PM, Rob Crittenden wrote:
Tomas Babej wrote:
On 02/12/2013 06:23 PM, Simo Sorce wrote:
On Tue, 2013-02-12 at 18:03 +0100, Tomas Babej wrote:
On 02/12/2013 05:50 PM, Tomas Babej wrote:
Hi,
This patch adds a check for krbprincipalexpiration attribute to
pre_bind operation
in ipa-pwd-extop dirsrv plugin. If the principal is expired,
auth is
denied and LDAP_INVALID_CREDENTIALS along with the error
message is
sent back to the client. Since krbprincipalexpiration
attribute is
not
mandatory, if there is no value set, the check is passed.
https://fedorahosted.org/freeipa/ticket/3305
Comments inline.
@@ -1166,6 +1173,29 @@ static int ipapwd_pre_bind(Slapi_PBlock
*pb)
goto done;
}
+/* check the krbPrincipalExpiration attribute is present */
+ret = slapi_entry_attr_find(entry, krbPrincipalExpiration,
attr);
+if (!ret) {
ret is not a boolean so probably better ti use (ret != 0)
+/* if it is, check whether the principal has not
expired */
+
+principal_expire = slapi_entry_attr_get_charptr(entry,
+ krbprincipalexpiration);
+memset(expire_tm, 0, sizeof (expire_tm));
+
+if (strptime(principal_expire, %Y%m%d%H%M%SZ,
expire_tm)){
style issue missing space between ) and {
+expire_time = mktime(expire_tm);
+/* this might have overflown on 32-bit system */
This comment does not help to point out what you want to put in
evidence.
if there is an overflow what is the consequence ? Or does it
mean the
next condition is taking that into account ?
Yeah, this was rather ill-worded. Replaced by a rather verbose
comment that hopefully clears things out.
+if (current_time expire_time expire_time 0){
style issue missing space between ) and {
+LOG_FATAL(kerberos principal has expired in
user
entry: %s\n,
+ dn);
I think a better phrasing would be: The kerberos principal on
%s is
expired\n
+errMesg = Kerberos principal has expired.;
s/has/is/
The rest looks good to me.
Simo.
Styling issues fixed and updated patch attached :)
Small nit, the expiration error should probably use 'in' not 'on'.
I'm not sure LDAP_INVALID_CREDENTIALS is the right return code. This
implies
that the password is wrong. I think that LDAP_UNWILLING_TO_PERFORM
is probably
more correct here. It is what we return on other policy failures.
rob
Additional findings:
1) Lets not try to get current_time every time, but only when its
needed (i.e.
krbPrincipalExpiration is set) - AFAIK, it is not so cheap operation:
+/* get current time*/
+current_time = time(NULL);
2) Why using slapi_entry_attr_get_charptr and thus let 389-ds find
the
attribute again when we already have a pointer for the attribute?
Would
slapi_attr_first_value following slapi_entry_attr_find be faster
approach?
+ret = slapi_entry_attr_find(entry, krbPrincipalExpiration,
attr);
+if (ret != 0) {
+/* if it is, check whether the principal has not expired */
+
+principal_expire = slapi_entry_attr_get_charptr(entry,
+ krbprincipalexpiration);
This way, we would not create a copy of this attribute value - we do
not need a
copy, we just do check against it.
3) Shouldn't we return -1 in the end when the auth fails? We do that
in other
pre_callbacks. Otherwise we just return 0 (success):
+if (auth_failed){
+slapi_send_ldap_result(pb, LDAP_INVALID_CREDENTIALS, NULL,
errMesg,
+ 0, NULL);
+}
+
return 0;
Martin
Thank you both for the review. I updated and retested the patch, with
your suggestions incorporated.
Tomas
I rebased the patch on top of current master.
Bumping, since this is planned as part of 3.4 (and there were some
requests for this feature).
Tomas
I updated the commit message to reflect better what the current version
of the patch implements.
Tomas
From a93d1ec3ca8c7b6e8e754b474257695ba9018e07 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Mon, 6 Jan 2014 12:11:24 +0100
Subject: [PATCH] ipa-pwd-extop: Deny LDAP binds for user accounts
with expired
principal
Adds a check for krbprincipalexpiration attribute to pre_bind operation
in ipa-pwd-extop dirsrv plugin. If the principal is expired, auth is
denied and LDAP_UNWILLING_TO_PERFORM along with the error message is
sent back to the client. Since krbprincipalexpiration attribute is not
mandatory, if there is no value set, the check is passed.
https://fedorahosted.org/freeipa/ticket/3305
---
Re: [Freeipa-devel] [PATCH] 562-563 webui: move RPC code from IPA module to its own module
On 27.3.2014 14:38, Misnyovszki Adam wrote: On Wed, 19 Mar 2014 16:02:29 +0100 Petr Vobornik pvobo...@redhat.com wrote: depends on path #561(make navigation module independent on app module) [PATCH] 562 webui: move RPC code from IPA module to its own module - moves RPC code from ipa.js to it's own module - part of ongoing effort where the ultimate goal is to get rid of ipa.js and IPA namespace [PATCH] 563 webui: replace IPA.command usage with rpc.command Replace all IPA.command, IPA.batch_command and IPA.concurrent_command usages by equivalents from rpc module. ACK Greets Adam Pushed to master: * d5cf0b273ad511d6cb99fbcb900eff528fe172df webui: move RPC code from IPA module to its own module * 06a7a1b3cb277284448dd8344940395f0b29cd70 webui: replace IPA.command usage with rpc.command -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0034] Deny LDAP binds for user accounts with expired principal
this need rebasing due to OTP patches, however comments inline.
On Tue, 2014-01-07 at 13:47 +0100, Tomas Babej wrote:
diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c
b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c
index
ef37b5e173359f9404b241c12d8a6dc6e77da128..df74a671c219f9b4aaa407f2ebd68f41669817b4
100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c
@@ -1389,13 +1389,17 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb)
Slapi_Value *value = NULL;
Slapi_Attr *attr = NULL;
struct tm expire_tm;
+time_t current_time;
+time_t expire_time;
char *errMesg = Internal operations error\n; /* error message
*/
char *expire = NULL; /* passwordExpirationTime attribute value */
+char *principal_expire = NULL; /* krbPrincipalExpiration
attribute value */
char *dn = NULL; /* bind DN */
Slapi_Value *objectclass;
int method; /* authentication method */
int ret = 0;
char *principal = NULL;
+bool auth_failed = false;
LOG_TRACE(=\n);
@@ -1422,7 +1426,7 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb)
const char *attrs_list[] = {SLAPI_USERPWD_ATTR,
krbprincipalkey, uid,
krbprincipalname, objectclass,
passwordexpirationtime,
passwordhistory,
-NULL};
+krbprincipalexpiration, NULL};
/* retrieve user entry */
ret = ipapwd_getEntry(dn, entry, (char **) attrs_list);
@@ -1438,6 +1442,39 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb)
goto done;
}
+/* check the krbPrincipalExpiration attribute is present */
+ret = slapi_entry_attr_find(entry, krbPrincipalExpiration,
attr);
+if (ret == 0) {
+ret = slapi_attr_first_value(attr, value);
+
+if (ret == 0) {
+/* if it is, check whether the principal has not expired
*/
+principal_expire = slapi_value_get_string(value);
Why not just use a simpler condition from the start of this very nested
sequence of checks ?
Like:
/* check the krbPrincipalExpiration attribute is present */
principal_expire = slapi_entry_attr_get_charptr(entry,
krbPrincipalExpiration)
if (principal_expire) {
memset(...
I do not see the value of digging through the attr with that many calls.
+memset(expire_tm, 0, sizeof (expire_tm));
+
+if (strptime(principal_expire, %Y%m%d%H%M%SZ,
expire_tm)) {
+expire_time = mktime(expire_tm);
+
+/* get current time */
+current_time = time(NULL);
+
+/* mktime returns -1 if the tm struct cannot be
represented as
+ * as calendar time (seconds since the Epoch). This
might
+ * happen with tm structs that are ill-formated or on
32-bit
+ * platforms with dates that would cause overflow
+ * (year 2038 and later).
+ * In such cases, skip the expiration check. */
+
+if (current_time expire_time expire_time 0) {
+LOG_FATAL(kerberos principal in %s is expired
\n, dn);
+errMesg = Kerberos principal is expired.;
This message is sent back to the client, perhaps we should say: Account
is expired, it seem to me a more understandable error for a casual
user/admin.
+auth_failed = true;
Technically no auth was performed also I am not sure why we need a
boolean ?
Just set rc = LDAP_UNWILLING_TO_PERFORM ?
+goto done;
+}
+}
+}
+}
+
/* we aren't interested in host principals */
objectclass = slapi_value_new_string(ipaHost);
if ((slapi_entry_attr_has_syntax_value(entry,
SLAPI_ATTR_OBJECTCLASS, objectclass)) == 1) {
@@ -1560,6 +1597,12 @@ done:
slapi_entry_free(entry);
free_ipapwd_krbcfg(krbcfg);
+if (auth_failed){
+slapi_send_ldap_result(pb, LDAP_UNWILLING_TO_PERFORM, NULL,
errMesg,
and here:
if (rc != LDAP_SUCCESS) {
slapi_send_ldap_result(pb, rc, NULL, errMesg, 0, NULL);
+ 0, NULL);
+return -1;
+}
+
return 0;
}
HTH,
Simo.
--
Simo Sorce * Red Hat, Inc * New York
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added
On Wed, 26 Mar 2014 13:15:55 +0100
Petr Viktorin pvikt...@redhat.com wrote:
On 03/25/2014 03:36 PM, Misnyovszki Adam wrote:
On Mon, 24 Mar 2014 17:06:41 +0100
Martin Kosek mko...@redhat.com wrote:
On 03/24/2014 11:42 AM, Misnyovszki Adam wrote:
On Fri, 21 Mar 2014 13:06:21 +0100
Petr Viktorin pvikt...@redhat.com wrote:
On 03/21/2014 12:58 PM, Martin Kosek wrote:
On 03/21/2014 12:38 PM, Petr Viktorin wrote:
On 03/21/2014 12:00 PM, Misnyovszki Adam wrote:
On Fri, 21 Mar 2014 10:33:00 +0100
Petr Viktorin pvikt...@redhat.com wrote:
On 03/21/2014 10:29 AM, Petr Viktorin wrote:
On 03/20/2014 04:22 PM, Misnyovszki Adam wrote:
On Thu, 20 Mar 2014 14:19:51 +0100
Misnyovszki Adam amisn...@redhat.com wrote:
On Fri, 14 Mar 2014 13:26:15 -0400
Rob Crittenden rcrit...@redhat.com wrote:
Misnyovszki Adam wrote:
Hi,
automember-rebuild uses asynchronous 389 task, and
returned success even if the task didn't run. This patch
fixes this issue adding a --nowait parameter to 'ipa
automember-rebuild', defaulting to False, thus when the
script runs without it, it waits for the
'nstaskexitcode' attribute, which means the task has
finished, according to
http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP#Implementation.
Old usage can be enabled using --nowait.
https://fedorahosted.org/freeipa/ticket/4239
Request for comments:
- Should I add a parameter to specify the polling time?
(now 1ms)
- Should I add a parameter to specify the maximum
polling number? Now if something fails about creating
the task, it polls forever.
- Obviously, if these parameters should be added, there
should be a reasonable default for them (~
Required=False, Default=X).
I don't think you need a polling time, esp since this is
hidden from the user, but I think that is probably too
short and you may end up hammering the LDAP server.
I also wonder if there should be some maximum wait time.
I don't like loops that can never exit. I'm at a loss for
what that time should be though. And we'd need to spell
out that we gave up waiting, not that the task
necessarily failed. So rather than having a polling time
option, rename nowait into wait_for=20, so wait for 20
seconds. Or something like that.
I'd suggest using get_entry since you already know the
full DN and there is only ever one. It would make this
much more readable.
I wonder if some top-level documentation should be added
to flesh this out some more. This does, for example,
return False in one case. The meaning for that should be
spelled out.
rob
Hi,
personally I would keep --no-wait, with a delay of 1
seconds, and a maximum waiting time for 60 seconds.
Questions is, do we need to parameterize with other
parameters(wait-for to the maximum time, and/or poll-delay
for the delay time, both not required), or it is not a
case which worth to develop? Greets
Adam
Hi,
here are the corrections Petr asked, also the other patch
conatins the plugin registration refactor.
Thanks!
You forgot an alternate summary for the --no-wait case.
(Make sure to output the DN in this case, so it's possible
to poll for it.)
Instead of `task['nstaskexitcode'][0]` please use
`task.single_value['nstaskexitcode']`.
There's one more `task['nstaskexitcode'][0]`. (Perhaps putting
it in a variable would be better?)
Here:
raise errors.DatabaseError(
desc=_(Automember rebuild membership task
failed), info=_(nstaskexitcode = '%s' %
str(task['nstaskexitcode'][0])))
there's no need to call str() on %'s argument.
Also, use natural language (like Task exit code: %s),
otherwise there's no need to mark the message for
translation.
And one more thing: Please bump the minor version in the
VERSION file when API.txt changes.
Hi,
everything is corrected!
Greets
Adam
Sorry for dragging this so long, but:
The DN should not be a part of the summary, because that makes
it hard to parse when using the API. It should be returned as
a part of the result. To do that, you'd need to change the
output type:
has_output = output.standard_entry
has_output_params = (
DNParam(
'dn',
label=_('Task automember'),
doc=_('DN of the started task'),
),
)
and provide a dict in result, instead of True. (And with
--no-wait, add the dn to that dict.)
Do really want to use 'dn' for the DNParam? dn is already used
for standard entry DN when --all is used, right?
automembertaskdn may be better.
Well, I think DN of the added entry is exactly what this is.
Also, Task automember label sounds strange to me, would
Automember task DN be better?
I meant Task DN, sorry for the thinko.
One more thing, which came to my mind after reviewing the code for
myself once again, if
Re: [Freeipa-devel] [PATCH]Extending user plugin with employeenumber field
On Wed, 26 Mar 2014 14:07:50 +0100
Misnyovszki Adam amisn...@redhat.com wrote:
On Tue, 25 Mar 2014 18:26:53 +0100
Misnyovszki Adam amisn...@redhat.com wrote:
On Tue, 25 Mar 2014 14:31:15 +0100
Petr Vobornik pvobo...@redhat.com wrote:
On 21.3.2014 11:00, Misnyovszki Adam wrote:
On Fri, 21 Mar 2014 10:13:55 +0100
Misnyovszki Adam amisn...@redhat.com wrote:
On Fri, 21 Feb 2014 16:06:27 +0100
Petr Vobornik pvobo...@redhat.com wrote:
On 21.2.2014 15:45, Adam Misnyovszki wrote:
Hi,
According to http://tools.ietf.org/html/rfc2798 ipa client
and web ui extended with employeenumber field.
https://fedorahosted.org/freeipa/ticket/4165
Question is, that should we extend user with other fields
which are in the RFC, (carLicense, departmentNumber,
employeeType, etc) if we already touched this code?
Thanks
Adam
+Int('employeenumber?',
+label=_('Employee ID'),
+minvalue=1,
+),
Why Int and different label? IMO it should be Str and
'Employee Number'
2.4. Employee Number
Numeric or alphanumeric identifier assigned to a person,
typically based on order of hire or association with an
organization. Single valued.
( 2.16.840.1.113730.3.1.3
NAME 'employeeNumber'
DESC 'numerically identifies an employee within an
organization' EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
Hi,
fixed, also some other fields added. Note, that according to
the rfc,
licence plate field should be multivalue, should I cange
that(it is an existing field).
yes
Also, should I write test cases(especially for
preferredlanguage)?
Testing new functionality helps.
Greets
Adam
self NACK,
VERSION bump because API change
It requires another rebase.
Greets
Adam
1) Is there a reason to have label 'Employee ID' instead of
'Employee Number' which is in RFC 2798?
+label=_('Employee ID'),
2) Department number seems to be multivalued as well:
( 2.16.840.1.113730.3.1.2
NAME 'departmentNumber'
DESC 'identifies a department within an organization'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
3) The regex for preferredlanguage:
+pattern='^[a-zA-Z]{1,8}[-[a-zA-Z]{1,8}]?$',
doesn't match the expression in RFC 2068. It's only part of it.
Accept-Language = Accept-Language :
1#( language-range [ ; q =
qvalue ] )
language-range = ( ( 1*8ALPHA *( - 1*8ALPHA ) ) |
* )
http://tools.ietf.org/html/rfc2068#section-14.4
RFC 2798 ( http://tools.ietf.org/html/rfc2798#section-2.7 ) says
that you should omit only the `Accept-Language :` sequence.
See the updates in the attached patch.
Greets
Adam
The preferredLanguage regex pattern and error message has been
modified to comply with RFC, according to conversation with Petr.
Thanks
Adam
The regex pattern corrected, unit tests added for preferredlanguage.
Greets
AdamFrom 06c07fa11fe2fbdf92e0d51333a5265de38a0bdb Mon Sep 17 00:00:00 2001
From: Adam Misnyovszki amisn...@redhat.com
Date: Thu, 27 Mar 2014 16:26:08 +0100
Subject: [PATCH] Extending user plugin with inetOrgPerson fields
According to http://tools.ietf.org/html/rfc2798 ipa client
and web ui extended with inetOrgPerson fields:
- employeenumber
- employeetype
- preferredlanguage
- departmentnumber
carlicenseplate is now multivalued
https://fedorahosted.org/freeipa/ticket/4165
---
API.txt | 24 ++---
VERSION | 4 +-
install/ui/src/freeipa/user.js | 10 +++-
ipalib/plugins/user.py | 17 +-
ipatests/test_xmlrpc/test_user_plugin.py | 92
5 files changed, 136 insertions(+), 11 deletions(-)
diff --git a/API.txt b/API.txt
index 326b051e79cb914a2ff2ea603084d7d741f2aa70..14dde56832793f8dd9fa6795a5ba79d0a2431d51 100644
--- a/API.txt
+++ b/API.txt
@@ -3791,13 +3791,16 @@ output: Entry('result', type 'dict', Gettext('A dictionary representing an LDA
output: Output('summary', (type 'unicode', type 'NoneType'), None)
output: Output('value', type 'unicode', None)
command: user_add
-args: 1,39,3
+args: 1,43,3
arg: Str('uid', attribute=True, cli_name='login', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True)
option: Str('addattr*', cli_name='addattr', exclude='webui')
option: Flag('all', autofill=True, cli_name='all', default=False,
Re: [Freeipa-devel] [PATCH 0015] Add wait_for_dns option to default.conf
On 27.3.2014 13:15, Martin Kosek wrote:
On 02/20/2014 03:56 PM, Martin Basti wrote:
On Thu, 2014-02-20 at 14:36 +0100, Petr Spacek wrote:
On 19.2.2014 17:55, Martin Basti wrote:
On Wed, 2014-02-19 at 17:10 +0100, Petr Spacek wrote:
On 19.2.2014 15:11, Petr Spacek wrote:
On 18.2.2014 17:34, Nathaniel McCallum wrote:
On Tue, 2014-02-18 at 17:06 +0100, Petr Viktorin wrote:
On 02/18/2014 04:45 PM, Petr Spacek wrote:
Hello,
Add wait_for_dns option to default.conf.
This option makes record changes in DNS tree synchronous.
IPA calls will wait until new data are visible over DNS protocol.
It is intended only for testing - it should prevent tests from
failing if there is bigger delay between change in LDAP and DNS.
I would recommend value like 10 seconds.
Here are a few Python nitpicks you requested.
Thank you very much. This new version solves problems you found + adds proper
handling for real DNS timeouts.
It seems to me like a more general TimeoutError would be useful in a
broader context. DNSTimeout seems overly narrow to me, unless I'm
missing something.
I would like to keep them separate. DNSTimeout shouldn't be handled at all
because it means that your DNS server or database is dead or broken in some
interesting way.
I assume that generic TimeoutError could be interpreted as 'try it
again'/'failover' or something like that.
Maybe the DNSTimeout is not the best name, I'm open to suggestions.
I have sent the old version with new name, gggrrr.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Tests failed:
test_dns[92]: dnsrecord_add: Add A record to u'ns2' in zone
u'zone3.test' ... ok
File /usr/lib/python2.7/site-packages/nose/case.py, line 197, in
runTest
self.test(*self.arg)
File /root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py, line 291, in
lambda
func = lambda: self.check(nice, **test)
File /root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py, line 309, in
check
self.check_output(nice, cmd, args, options, expected, extra_check)
File /root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py, line 348, in
check_output
got = api.Command[cmd](*args, **options)
File /root/freeipa/ipalib/frontend.py, line 436, in __call__
ret = self.run(*args, **options)
File /root/freeipa/ipalib/frontend.py, line 761, in run
return self.forward(*args, **options)
File /root/freeipa/ipalib/frontend.py, line 782, in forward
return self.Backend.rpcclient.forward(self.name, *args, **kw)
File /root/freeipa/ipalib/rpc.py, line 836, in forward
return self._call_command(command, params)
File /root/freeipa/ipalib/rpc.py, line 813, in _call_command
return command(*params)
File /root/freeipa/ipalib/rpc.py, line 951, in _call
return self.__request(name, args)
File /root/freeipa/ipalib/rpc.py, line 945, in __request
raise error_class(message=error['message'])
DNSTimeout: DNS query timeout: Expected {_kerberos.zone2.test. 86400 IN
TXT IDM.LAB.ENG.BRQ.REDHAT.COM} got {SERVFAIL}
==
ERROR: test_dns[51]: dnsrecord_add: Add NS+DNAME record to u'zone2.test'
zone record using dnsrecord_add
--
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/nose/case.py, line 197, in
runTest
self.test(*self.arg)
File /root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py, line 291, in
lambda
func = lambda: self.check(nice, **test)
File /root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py, line 309, in
check
self.check_output(nice, cmd, args, options, expected, extra_check)
File /root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py, line 348, in
check_output
got = api.Command[cmd](*args, **options)
File /root/freeipa/ipalib/frontend.py, line 436, in __call__
ret = self.run(*args, **options)
File /root/freeipa/ipalib/frontend.py, line 761, in run
return self.forward(*args, **options)
File /root/freeipa/ipalib/frontend.py, line 782, in forward
return self.Backend.rpcclient.forward(self.name, *args, **kw)
File /root/freeipa/ipalib/rpc.py, line 836, in forward
return self._call_command(command, params)
File /root/freeipa/ipalib/rpc.py, line 813, in _call_command
return command(*params)
File /root/freeipa/ipalib/rpc.py, line 951, in _call
return self.__request(name, args)
File /root/freeipa/ipalib/rpc.py, line 945, in __request
raise error_class(message=error['message'])
DNSTimeout: DNS query timeout: Expected {zone2.test. 86400 IN NS
ns1.dnszone.test.
zone2.test. 86400 IN NS ns1.zone2.test.} got {SERVFAIL}
configuration was: wait_for_dns=10
All tests passed without wait_for_dns option.
Sometimes at first run, I get only error and testing is interrupted.
I hope I covered all corner
[Freeipa-devel] Fwd: Re: FreeIPA 3.3.5
Re-sending since I am now subscribed to this list. Original Message Subject:Re: FreeIPA 3.3.5 Date: Thu, 27 Mar 2014 14:27:32 -0700 From: Matthew Harmsen mharm...@redhat.com To: Martin Kosek mko...@redhat.com, freeipa-devel@redhat.com On 03/27/14 04:45, Martin Kosek wrote: Hello all! I think we are close to releasing next bugfixing version on FreeIPA 3.3.5. We have a lot of bug fixes to offer, especially in the AD Trust area. I wrote the changelog to our wiki, fixes or suggestions welcome: http://www.freeipa.org/page/Releases/3.3.5 I have just one last concern though, the remaining PKI clone installation issue I found: https://fedorahosted.org/pki/ticket/933 Do we want to release before this ticket is closed or wait? Question is if fixing Dogtag 10 based clone installation is enough to allow us to release or not. Matthew (CCed), do we have any ETA when the fix would be available? Ticket #933 is next on my list, but I must replicate the issue first, and then come up with a patch. My best guess is that I would not have anything before sometime next week. This issue only involves replicating a FreeIPA system which is using Dogtag 9 (e. g. - RHEL 6, Fedora 17) to a Free IPA system using Dogtag 10.1 (e. g. - Fedora 20 - the change was made in pki-core-10.1.1.fc20). Regardless of your decision, this issue will be the next bug fixed, and it is planned to be included in the next build (e. g. - pki-core-10.1.2.fc20). -- Matt ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] [DOC] Add note about additional nameservers in resolv.conf
I believe that Martin is right about the server installer no longer putting 127.0.0.1 in the resolv.conf. Here is a mod patch to address Martin's concern if the note needs to be changed to show a real IP address. Gabe On Thu, Mar 27, 2014 at 4:14 AM, Martin Basti mba...@redhat.com wrote: On Thu, 2014-03-27 at 10:33 +0100, Petr Spacek wrote: On 27.3.2014 10:23, Martin Basti wrote: On Wed, 2014-03-26 at 17:40 -0600, Gabe Alford wrote: All, Please review patch for https://fedorahosted.org/freeipa/ticket/3085 Added note that 'nameserver 127.0.0.1' is added to resolv.conf, that it is recommended to add more replicas to resolv.conf, and the max nameservers allowed in resolv.conf. Actually, my ipa-server-install puts into /etc/resolv.conf its ip address itself not localhost After fresh install: #cat /etc/resolv.conf search example.com nameserver 10.*.*.* IMHO /etc/resolv.conf was overwritten by DHCPd (when IPA installation was finished). I inspect ipa-server-install source code and installation adds to resolv.conf a real server address. DHCP leave note in resolv.conf when generate it. -- Martin^2 Basti From 7cc26ca67d93532c45757210352ab7b6332c78c7 Mon Sep 17 00:00:00 2001 From: Gabe redhatri...@gmail.com Date: Thu, 27 Mar 2014 18:55:38 -0600 Subject: [PATCH] [DOC] Update resolv.conf nameserver note to reflect real IP address - Added example of real IP address as the installer inserts a real IP address into resolv.conf. --- src/user_guide/en-US/DNS.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/user_guide/en-US/DNS.xml b/src/user_guide/en-US/DNS.xml index ab120e80efcf1ff41e0f774dba8b357818e6cb2a..54663ed806e2ab1db1bf2d30482908acb4618f96 100644 --- a/src/user_guide/en-US/DNS.xml +++ b/src/user_guide/en-US/DNS.xml @@ -69,8 +69,8 @@ When DNS is configured either by the option--setup-dns/option option during the intial IPA; install or the commandipa-dns-install/command command after the intial IPA; setup, the IPA; server installer creates -filename/etc/resolv.conf/filename with the following line: -screennameserver 127.0.0.1/screen +filename/etc/resolv.conf/filename with the IPA; server's IP address. For example: +screennameserver 192.168.1.1/screen /para /listitem listitem -- 1.9.0 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
