[Freeipa-devel] [PATCH] Fix various typos
ACK for typo fixes made by Yuri Chornoivan (patch attached).
Pushed to master, ipa-3-0.
Martin
From c1b421a6bfdf0d0b2eec8aed409b720c6e1ab783 Mon Sep 17 00:00:00 2001
From: Yuri Chornoivan yurc...@ukr.net
Date: Sun, 16 Sep 2012 19:35:56 +0300
Subject: [PATCH] Fix various typos.
https://fedorahosted.org/freeipa/ticket/3089
---
install/tools/man/ipa-adtrust-install.1 |2 +-
install/tools/man/ipa-replica-manage.1 |2 +-
install/ui/test/data/ipa_init.json |2 +-
install/ui/test/data/ipa_init_commands.json |4 ++--
install/ui/test/ipa_tests.js|4 ++--
ipa-client/man/default.conf.5 |2 +-
ipa-client/man/ipa-client-install.1 |2 +-
ipa-client/man/ipa-getkeytab.1 |2 +-
ipa-client/man/ipa-join.1 |2 +-
ipa.1 |2 +-
ipalib/errors.py|2 +-
ipalib/plugins/automember.py|2 +-
ipalib/plugins/dns.py |6 +++---
ipalib/plugins/idrange.py |6 +++---
ipalib/plugins/internal.py |2 +-
ipalib/plugins/sudorule.py |4 ++--
ipalib/plugins/trust.py |4 ++--
ipalib/plugins/user.py |2 +-
ipalib/session.py |4 ++--
ipapython/log_manager.py|2 +-
tests/test_xmlrpc/test_attr.py |2 +-
21 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/install/tools/man/ipa-adtrust-install.1 b/install/tools/man/ipa-adtrust-install.1
index 936e04c..5303ec2 100644
--- a/install/tools/man/ipa-adtrust-install.1
+++ b/install/tools/man/ipa-adtrust-install.1
@@ -22,7 +22,7 @@ ipa\-adtrust\-install \- Prepare an IPA server to be able to establish trust rel
.SH SYNOPSIS
ipa\-adtrust\-install [\fIOPTION\fR]...
.SH DESCRIPTION
-Adds all necesary objects and configuration to allow an IPA server to create a
+Adds all necessary objects and configuration to allow an IPA server to create a
trust to an Active Directory domain. This requires that the IPA server is
already installed and configured.
.SH OPTIONS
diff --git a/install/tools/man/ipa-replica-manage.1 b/install/tools/man/ipa-replica-manage.1
index 98103ff..2767579 100644
--- a/install/tools/man/ipa-replica-manage.1
+++ b/install/tools/man/ipa-replica-manage.1
@@ -120,7 +120,7 @@ A special user entry is created for the PassSync service. The DN of this entry i
The following examples use the AD administrator account as the synchronization user. This is not mandatory but the user must have read\-access to the subtree.
.TP
-1. Transfer the base64\-encoded Windows AD CA Certficate to your IPA Server
+1. Transfer the base64\-encoded Windows AD CA Certificate to your IPA Server
.TP
2. Remove any existing kerberos credentials
# kdestroy
diff --git a/install/ui/test/data/ipa_init.json b/install/ui/test/data/ipa_init.json
index 9c158d5..0d94d9b 100644
--- a/install/ui/test/data/ipa_init.json
+++ b/install/ui/test/data/ipa_init.json
@@ -110,7 +110,7 @@
refresh: Refresh the page.,
reload: Reload the browser.,
main_page: Return to the main page and retry the operation,
-title: An error has occured (${error})
+title: An error has occurred (${error})
},
errors: {
error: Error,
diff --git a/install/ui/test/data/ipa_init_commands.json b/install/ui/test/data/ipa_init_commands.json
index 4237cc8..2c128f7 100644
--- a/install/ui/test/data/ipa_init_commands.json
+++ b/install/ui/test/data/ipa_init_commands.json
@@ -16780,9 +16780,9 @@
},
{
class: Password,
-doc: Active directory domain adminstrator's password,
+doc: Active directory domain administrator's password,
flags: [],
-label: Active directory domain adminstrator's password,
+label: Active directory domain administrator's password,
name: realm_passwd,
noextrawhitespace: true,
type: unicode
diff --git a/install/ui/test/ipa_tests.js b/install/ui/test/ipa_tests.js
index 7a2c18b..478196c 100644
--- a/install/ui/test/ipa_tests.js
+++ b/install/ui/test/ipa_tests.js
@@ -110,7 +110,7 @@ test(Testing successful IPA.command()., function() {
var xhr = {};
var text_status = null;
-var error_thrown = {name:'ERROR', message:'An error has occured'};
+var error_thrown = {name:'ERROR', message:'An error has occurred'};
var ajax_counter = 0;
@@ -186,7 +186,7 @@ test(Testing unsuccessful IPA.command()., function() {
var xhr = {};
var text_status = null;
-
[Freeipa-devel] [PATCH] 310 Properly convert DN in ipa-client-install
Pushed to master, ipa-3-0 as a one-liner. --- ipa-client-install crashed when IPA server anonymous access was disabled and base DN was thus generated via realm_to_suffix function which, however, returns a DN object and not string. DN was converted to string, ipa-client-install no longer crashes in this scenario. https://fedorahosted.org/freeipa/ticket/3088 -- Martin Kosek mko...@redhat.com Senior Software Engineer - Identity Management Team Red Hat Inc. From 8938d8e564ecfec92326a0415ed41d962185d663 Mon Sep 17 00:00:00 2001 From: Martin Kosek mko...@redhat.com Date: Tue, 18 Sep 2012 11:07:45 +0200 Subject: [PATCH] Properly convert DN in ipa-client-install ipa-client-install crashed when IPA server anonymous access was disabled and base DN was thus generated via realm_to_suffix function which, however, returns a DN object and not string. DN was converted to string, ipa-client-install no longer crashes in this scenario. https://fedorahosted.org/freeipa/ticket/3088 --- ipa-client/ipaclient/ipadiscovery.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipa-client/ipaclient/ipadiscovery.py b/ipa-client/ipaclient/ipadiscovery.py index f91d4075aeafc71c3951ae094ddf075c143533f7..234e67e9b0f7102b1ee642fb3279793ff631ff9d 100644 --- a/ipa-client/ipaclient/ipadiscovery.py +++ b/ipa-client/ipaclient/ipadiscovery.py @@ -249,7 +249,7 @@ class IPADiscovery(object): if not ldapaccess and self.basedn is None: # Generate suffix from realm -self.basedn = realm_to_suffix(self.realm) +self.basedn = str(realm_to_suffix(self.realm)) self.basedn_source = 'Generated from Kerberos realm' root_logger.debug(Generated basedn from realm: %s % self.basedn) -- 1.7.11.4 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0006] Improves sssd.conf handling during ipa-client uninstall
On 09/12/2012 05:29 PM, Martin Kosek wrote:
On 08/29/2012 02:54 PM, Tomas Babej wrote:
On 08/27/2012 04:55 PM, Martin Kosek wrote:
On 08/27/2012 03:37 PM, Jakub Hrozek wrote:
On Mon, Aug 27, 2012 at 02:57:44PM +0200, Martin Kosek wrote:
I think that the right behavior of SSSD conf uninstall should be the
following:
* sssd.conf existed before IPA install + non-IPA domains in sssd.conf found:
- move backed conf up sssd.conf.bkp (and inform the user)
- use SSSDConfig delete_domain function to remove ipa domain from sssd.conf
- restart sssd afterwards
I'm confused here, which of the files is the original
pre-ipa-client-install file?
This is the backed up sssd.conf. I thought that it may be useful for user to
still have an access to it after uninstall.
How does the non-ipa domain end up in the sssd.conf file? Does it have
to be configured manually or does ipa-client-install merge the list of
domains on installation?
ipa-client-install merge the list of the domains. It overrides the old
sssd.conf only when we cannot parse the sssd.conf and --preserve-sssd option
was not set.
Martin
Hi,
The sssd.conf file is no longer left behind in case sssd was not
configured before the installation. However, the patch goes behind
the scope of this ticked and improves the handling of sssd.conf
during the ipa-client-install --uninstall in general.
The current behaviour (well documented in source code) is as follows:
- In general, the IPA domain is simply removed from the sssd.conf
file, instead of sssd.conf being rewritten from the backup. This
preserves any domains added after installation.
- If sssd.conf existed before the installation, it is restored to
sssd.conf.bkp. However, any IPA domains from pre-installation
sssd.conf should have been merged during the installation.
- If sssd.conf did not exist before the installation, and no other
domains than IPA domain exist in it, the patch makes sure that
sssd.conf is moved to sssd.conf.deleted so user experiences no
crash during any next installation due to its existence.
https://fedorahosted.org/freeipa/ticket/2740
Tomas
Good job, SSSD uninstall process now looks more consistent and better
documented. I just found the following (mainly minor) issues. Comments in the
patch:
diff --git a/ipa-client/ipa-install/ipa-client-install
b/ipa-client/ipa-install/ipa-client-install
index
2e65921e8de2dfe68443f5b5875954d71dd48ed2..c5cef15e1fb3a3e1d7cfd070f4288d3839accfc8
100755
--- a/ipa-client/ipa-install/ipa-client-install
+++ b/ipa-client/ipa-install/ipa-client-install
@@ -183,6 +183,36 @@ def nssldap_exists():
return (retval, files_found)
+# helper function for uninstall
+# deletes IPA domain from sssd.conf
+def delete_IPA_domain():
Function names should be lowercase - delete_ipa_domain
+sssd = ipaservices.service('sssd')
+try:
+sssdconfig = SSSDConfig.SSSDConfig()
+sssdconfig.import_config()
+domains = sssdconfig.list_active_domains()
+
+IPA_domain_name = None
Variables should be lowercase - ipa_domain_name
+
+for name in domains:
+domain = sssdconfig.get_domain(name)
+try:
+provider = domain.get_option('id_provider')
+if provider == ipa:
+IPA_domain_name = name
+break
+except SSSDConfig.NoOptionError:
+continue
+
+if IPA_domain_name != None:
Do not use != with None, True, False - use is not None.
+sssdconfig.delete_domain(IPA_domain_name)
+sssdconfig.write()
+else:
+root_logger.warning(IPA domain could not be found in +
+sssd.conf and therefore not deleted)
+except IOError:
+root_logger.warning(IPA domain could not be deleted. No access to the
sssd.conf file.)
There should be full path to sssd.conf in this error message. It is very useful
sometimes.
+
def uninstall(options, env):
if not fstore.has_files():
@@ -212,7 +242,12 @@ def uninstall(options, env):
sssdconfig = SSSDConfig.SSSDConfig()
sssdconfig.import_config()
domains = sssdconfig.list_active_domains()
-if len(domains) 1:
+all_domains = sssdconfig.list_domains()
+
+# we consider all the domains, because handling sssd.conf
+# during uninstall is dependant on was_sssd_configured flag
+# so the user does not lose info about inactive domains
+if len(all_domains) 1:
# There was more than IPA domain configured
was_sssd_configured = True
for name in domains:
@@ -349,6 +384,62 @@ def uninstall(options, env):
Failed to remove krb5/LDAP configuration: %s, str(e))
return CLIENT_INSTALL_ERROR
+# Next if-elif-elif construction deals with sssd.conf file.
+# Old pre-IPA domains are preserved due merging the old sssd.conf
+#
Re: [Freeipa-devel] [PATCH] 0073 Add trust verification code
On Mon, Sep 17, 2012 at 06:44:36PM +0300, Alexander Bokovoy wrote: Hi, Following patch adds trust verification sequence to the case when we establish trust with knowledge of AD administrative credentials. As we found out, in order to validate/verify trust, one has to have administrative credentials for the trusted domain, since there are few RPCs that should be performed against trusted domain's DC's LSA and NetLogon pipes and these are protected by administrative credentials. Thus, when we know admin credentials for the remote domain, we can perform the trust validation. https://fedorahosted.org/freeipa/ticket/2763 Just a short feedback. The patch is working as expected, for a newly created trust Windows will send a TGS request to the IPA KDC without explicit validation on the windows side. Currently I have some issues in my test setup so that I can not give a full ACK atm. bye, Sumit -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0077 Check direct/reverse hostname/address resolution in ipa-replica-install
On 09/17/2012 08:10 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
On 09/14/2012 08:46 AM, Martin Kosek wrote:
On 09/13/2012 10:35 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
On 09/11/2012 11:05 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
On 09/04/2012 07:44 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
https://fedorahosted.org/freeipa/ticket/2845
Shouldn't this also call verify_fqdn() on the local hostname and
not
just the master? I think this would eventually fail in the
conncheck
but
what if that was skipped?
rob
A few lines above there is a call to get_host_name, which will call
verify_fqdn.
I double-checked this, it fails in conncheck. Here are my steps:
# ipa-server-install --setup-dns
# ipa-replica-prepare replica.example.com --ip-address=192.168.100.2
# ipa host-del replica.example.com
On replica, set DNS to IPA master, with hostname in /etc/hosts.
# ipa-replica-install ...
The verify_fqdn() passes because the resolver uses /etc/hosts.
The conncheck fails:
Execute check on remote master
Check connection from master to remote replica 'replica.example.com':
Remote master check failed with following error message(s):
Could not chdir to home directory /home/admin: No such file or
directory
Port check failed! Unable to resolve host name 'replica.example.com'
Connection check failed!
Please fix your network settings according to error messages above.
If the check results are not valid it can be skipped with
--skip-conncheck parameter.
The DNS test happens much further after this, and I get why, I just
don't see how useful it is unless the --skip-conncheck is used.
For the record, it's because we need to check if the host has DNS
installed. We need a LDAP connection to check this.
ipa-replica-install ~rcrit/replica-info-replica.example.com.gpg
--skip-conncheck
Directory Manager (existing master) password:
ipa : ERRORCould not resolve hostname replica.example.com
using DNS. Clients may not function properly. Please check your DNS
setup. (Note that this check queries IPA DNS directly and ignores
/etc/hosts.)
Continue? [no]:
So I guess, what are the intentions here? It is certainly better than
before.
rob
If the replica is in the master's /etc/hosts, but not in DNS, the
conncheck will succeed. This check explicitly queries IPA records only
and ignores /etc/hosts so it'll notice this case and warn.
Ok, like I said, this is better than we have. Just one nit then you
get an ack:
+# If remote host has DNS, check forward/reverse resolution
+try:
+entry = conn.find_entries(u'cn=dns',
base_dn=DN(api.env.basedn))
+except errors.NotFound:
u'cn=dns' should be str(constants.container_dns).
rob
This is a search filter, Petr could use the one I already have in
dns.py::get_dns_masters() function:
'((objectClass=ipaConfigObject)(cn=DNS))'
For performance sake, I would also not search in the entire tree, but
limit the
search only to:
DN(('cn', 'masters'), ('cn', 'ipa'), ('cn', 'etc'), api.env.basedn)
Martin
Attaching updated patch with Martin's suggestions.
I think what Martin had in mind was:
if api.Object.dnsrecord.get_dns_masters():
...
I didn't want to do this because api.Object.* use our global ldap2
Backend, which is hardwired to query localhost.
I see now that I can hack around this, and we already do this in
ipa-replica-install.
I've extracted the hack and reused it to get the DNS masters.
--
Petr³
From 5e22359342091c60717f65dae1f2a0be2df8cce8 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Tue, 4 Sep 2012 03:47:43 -0400
Subject: [PATCH] Check direct/reverse hostname/address resolution in
ipa-replica-install
Forward and reverse resolution of the newly created replica is already
checked via get_host_name (which calls verify_fqdn).
Add the same check for the existing master.
Additionally, if DNS is installed on the remote host, check forward
and reverse resolution of both replicas using that DNS only
(ignoring /etc/hosts). These checks give only warnings and, in interactive
installs, a Continue? prompt.
https://fedorahosted.org/freeipa/ticket/2845
---
install/tools/ipa-replica-install | 156 +-
1 file changed, 138 insertions(+), 18 deletions(-)
diff --git a/install/tools/ipa-replica-install b/install/tools/ipa-replica-install
index 267a70d8b60d96de9a9bde83b15c81ae59da1a96..0e338e3d93c2360a46ac23b181eef124e9759808 100755
--- a/install/tools/ipa-replica-install
+++ b/install/tools/ipa-replica-install
@@ -24,6 +24,11 @@ import socket
import os, pwd, shutil
import grp
from optparse import OptionGroup
+from contextlib import contextmanager
+
+import dns.resolver
+import dns.reversename
+import dns.exception
from ipapython import ipautil
@@ -47,6 +52,7 @@ from ipapython.dn import DN
log_file_name = /var/log/ipareplica-install.log
CACERT = /etc/ipa/ca.crt
REPLICA_INFO_TOP_DIR = None
+DIRMAN_DN = DN(('cn', 'directory manager'))
Re: [Freeipa-devel] [PATCH] 212 Fix integer validation when boundary value is empty string
On 09/18/2012 04:45 AM, Endi Sukma Dewata wrote:
On 9/11/2012 10:09 AM, Petr Vobornik wrote:
There was an error in number validation check. If boundary value was an
empty string, validation of a number always failed. This patch fixes the
problem by not performing the check in these cases.
Basic unit tests for IPA.metadata_validator created.
ACK. Some comments:
Updated patch attached.
1. Instead of IPA.not_defined() it might be better to call it
IPA.defined() to avoid double negations like this:
if (!IPA.not_defined(metadata.minvalue, true) ...
Function renamed, logic negated. Unit tests for IPA.defined added.
2. The check_empty_str probably could made optional and the value would
be true by default. It will make the code cleaner.
I wanted the function to be more general - used somewhere else in a
future. In general, I consider empty string as a defined value so for me
'false' is a good default value of the argument. I agree that in this
case it would look cleaner.
--
Petr Vobornik
From e094a7d317a57b841c5454de635df6a01944d100 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Tue, 11 Sep 2012 13:52:10 +0200
Subject: [PATCH] Fix integer validation when boundary value is empty string
There was an error in number validation check. If boundary value was an empty string, validation of a number always failed. This patch fixes the problem by not performing the check in these cases.
---
install/ui/field.js | 4 +-
install/ui/ipa.js| 5 ++
install/ui/test/all_tests.html | 1 +
install/ui/test/index.html | 1 +
install/ui/test/jsl.conf | 3 +-
install/ui/test/utils_tests.html | 24 +++
install/ui/test/utils_tests.js | 136 +++
7 files changed, 171 insertions(+), 3 deletions(-)
create mode 100644 install/ui/test/utils_tests.html
create mode 100644 install/ui/test/utils_tests.js
diff --git a/install/ui/field.js b/install/ui/field.js
index 42da6f92cd102aa665b05b72783de9d04dcdcfb0..c5c999e685500765f09af084531def144bbbd10b 100644
--- a/install/ui/field.js
+++ b/install/ui/field.js
@@ -448,13 +448,13 @@ IPA.metadata_validator = function(spec) {
if (number) {
-if (metadata.minvalue !== undefined Number(value) Number(metadata.minvalue)) {
+if (IPA.defined(metadata.minvalue, true) Number(value) Number(metadata.minvalue)) {
message = IPA.messages.widget.validation.min_value;
message = message.replace('${value}', metadata.minvalue);
return that.false_result(message);
}
-if (metadata.maxvalue !== undefined Number(value) Number(metadata.maxvalue)) {
+if (IPA.defined(metadata.maxvalue, true) Number(value) Number(metadata.maxvalue)) {
message = IPA.messages.widget.validation.max_value;
message = message.replace('${value}', metadata.maxvalue);
return that.false_result(message);
diff --git a/install/ui/ipa.js b/install/ui/ipa.js
index 23c9933dfb97cb39a932f78d235fdaf844e42b7c..9b5c9aacf87804372cac369e44f7f392e16f3a25 100644
--- a/install/ui/ipa.js
+++ b/install/ui/ipa.js
@@ -2021,6 +2021,11 @@ IPA.is_empty = function(value) {
return empty;
};
+IPA.defined = function(value, check_empty_str) {
+return value !== null value !== undefined
+((check_empty_str value !== '') || !check_empty_str);
+};
+
IPA.array_diff = function(a, b) {
if (a === b || (!a !b)) return false;
diff --git a/install/ui/test/all_tests.html b/install/ui/test/all_tests.html
index 5a5eae54b5c6606564fd0e7b2df8ccc606dccef2..e9061b6ca8802b83c8f99c234ad7311606672695 100644
--- a/install/ui/test/all_tests.html
+++ b/install/ui/test/all_tests.html
@@ -32,6 +32,7 @@
script type=text/javascript src=aci_tests.js/script
script type=text/javascript src=widget_tests.js/script
script type=text/javascript src=ip_tests.js/script
+script type=text/javascript src=utils_tests.js/script
/head
body
h1 id=qunit-headerComplete Test Suite/h1
diff --git a/install/ui/test/index.html b/install/ui/test/index.html
index 1b623d40f794b1ffda90f6c3352840acbaeec26a..0a135188e518913aa3f3a191ab340f2f5e820abf 100644
--- a/install/ui/test/index.html
+++ b/install/ui/test/index.html
@@ -34,6 +34,7 @@
lia href=aci_tests.htmlAccess Control Interface Test Suite/a
lia href=widget_tests.htmlWidget Test Suite/a
lia href=ip_tests.htmlIP Addresses Test Suite/a
+lia href=utils_tests.htmlUtils Test Suite/a
/ul
/div
diff --git a/install/ui/test/jsl.conf b/install/ui/test/jsl.conf
index 4654b714f91cb00696043bf3042fccd2b2e394bc..768a295f1ac7c956f588b99c60eecdb2bfb06c67 100644
--- a/install/ui/test/jsl.conf
+++ b/install/ui/test/jsl.conf
@@ -146,4 +146,5 @@
+process ipa_tests.js
+process ordered_map_tests.js
+process widget_tests.js
-+process ip_tests.js
\ No newline at end of
Re: [Freeipa-devel] [PATCH] 214 Fix jquery error when using '??' in a pkey
On 09/18/2012 04:45 AM, Endi Sukma Dewata wrote: On 9/14/2012 8:00 AM, Petr Vobornik wrote: This patch is only for FreeIPA 2.2. It is already fixed in 3.0. If '??' is used in a adder dialog as a pkey it can cause jQuery15208158273949015573_1346241267446 was not called error. Update of jquery library fixes the issue. Update reveals an incorrect handler definition issue in ssh_key_widget, which is also fixed. https://bugzilla.redhat.com/show_bug.cgi?id=855278 https://fedorahosted.org/freeipa/ticket/3073 ACK. Pushed to ipa-2-2 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0079 Update the pot file (translation source)
On 09/17/2012 07:59 PM, Jérôme Fenal wrote: 2012/9/17 Petr Viktorin pvikt...@redhat.com mailto:pvikt...@redhat.com On 09/14/2012 09:36 PM, Jérôme Fenal wrote: 2012/9/14 Petr Viktorin pvikt...@redhat.com mailto:pvikt...@redhat.com mailto:pvikt...@redhat.com mailto:pvikt...@redhat.com I pushed the pot manually. Since we have infrequent explicit string freezes I don't think it's necessary to configure automatic pot updates again. Thanks Petr! Actually, having the strings updated on Transifex on a regular basis makes it (IMHO) more manageable for translators to update the translations even before a string freeze. Translating a dozen strings per week is lighter than a mere 339 strings. A possible problem with this approach is that the translators would see and translate messages that don't make it into the final version. Do you think a more even workload would be worth the occasional extra work? Having some extra work from time to time is OK. Having a huge batch of strings to translate on a deadline is uneasy. Especially with day job ramping up... ;-) I would like to change our i18n workflow/infrastructure. I was planning to (re-)start discussing this after the 3.0 release rush is done. It should be possible to do what you suggest. Cool, thanks. I also don't know if pulls from Transifex or push from your side has an effect of keeping memory (in suggestions) of past or close enough strings from the past for small modifications. Sadly, I don't know much about Transifex itself. Perhaps ask the team there, and request the feature if it's missing. This item is not that important, more a wish. Another comment/request, I don't know given my zero-level Python-fu: would it be possible to break down the huge __doc__ strings in plugins into smaller parts, as a small modification would impact a smaller strings, easing maintenance instead of trying to track the one character modification in a 2000 chars text. Does Python support concatenations of __doc___ strings? That is be possible on the Python side. I'm not sure how Transifex (and other translation tools) would cope with text split between several messages -- sorting and filtering the messages could take things out of context. I'm aware of this issue, translators for others languages may raise their hands. I could also probe trans@fp.o on that matter, to reach all of them. If the answer is not in a FAQ somewhere, that would be nice. I have a feeling that the communication between developers and translators could be better. It seems like many translators think they're given the strings on a silver platter and have to deal with what's there, and the developers don't really know the translators' needs. Thanks for reaching out! We want to help (though changes may be slow, and won't happen during a string freeze), and definitely appreciate these comments so we can better plan for the future. That will nevertheless make changes more atomic, and overall easier to manage on the longer term. In the past, changes were just a matter of adding one paragraph, or adding one more usage example. Or fixing a typo. Which is way harder to spot when you have a 1000 chars strings tagged as changed. Ideally Transifex would show the difference between the old and the new. Unfortunately the data's not there to do this automatically :( For typos, there should be a way to leave the old translations unchanged (since the translations won't have the typo). Gettext has the fuzzy feature for this, but it has problems so it's turned off for IPA. I'll quote John here (apologies for posting private conversation): Never use fuzzy entries. The logic used to select a fuzzy entry is poor, it often picks up entirely wrong translations, they are evil. We've had way too many problems with message catalogs getting corrupted due to the introduction of fuzzy entries. Given that fuzzy entries are so seldom correct and are mostly of value to translators and that translators have a lazy habit of just accepting the incorrect fuzzy suggestion and promoting to a full translation they should not be used at all. I've spent days in the past trying to unwind corrupted files due to the incorrect application of fuzzy translations. I really don't want to do that again :-) Gettext was designed for delayed communication -- the translators would download the file, work for a few weeks, then mail the result back. There could be various versions of POT and PO files floating around. The metadata and logic, including the fuzzy system, was built around that. With Transifex, there's one version of everything, and we have access to the translations as they're written. There might be ways to exploit this
Re: [Freeipa-devel] [PATCH] 0073 Add trust verification code
On Tue, Sep 18, 2012 at 12:42:49PM +0200, Sumit Bose wrote: On Mon, Sep 17, 2012 at 06:44:36PM +0300, Alexander Bokovoy wrote: Hi, Following patch adds trust verification sequence to the case when we establish trust with knowledge of AD administrative credentials. As we found out, in order to validate/verify trust, one has to have administrative credentials for the trusted domain, since there are few RPCs that should be performed against trusted domain's DC's LSA and NetLogon pipes and these are protected by administrative credentials. Thus, when we know admin credentials for the remote domain, we can perform the trust validation. https://fedorahosted.org/freeipa/ticket/2763 Just a short feedback. The patch is working as expected, for a newly created trust Windows will send a TGS request to the IPA KDC without explicit validation on the windows side. Currently I have some issues in my test setup so that I can not give a full ACK atm. ok, ACK. Nevertheless it would be nice if Petr can check for any implications to the web UI with respect to the status of the trust. bye, Sumit bye, Sumit -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0073 Add trust verification code
On 09/18/2012 02:15 PM, Sumit Bose wrote: On Tue, Sep 18, 2012 at 12:42:49PM +0200, Sumit Bose wrote: On Mon, Sep 17, 2012 at 06:44:36PM +0300, Alexander Bokovoy wrote: Hi, Following patch adds trust verification sequence to the case when we establish trust with knowledge of AD administrative credentials. As we found out, in order to validate/verify trust, one has to have administrative credentials for the trusted domain, since there are few RPCs that should be performed against trusted domain's DC's LSA and NetLogon pipes and these are protected by administrative credentials. Thus, when we know admin credentials for the remote domain, we can perform the trust validation. https://fedorahosted.org/freeipa/ticket/2763 Just a short feedback. The patch is working as expected, for a newly created trust Windows will send a TGS request to the IPA KDC without explicit validation on the windows side. Currently I have some issues in my test setup so that I can not give a full ACK atm. ok, ACK. Nevertheless it would be nice if Petr can check for any implications to the web UI with respect to the status of the trust. It shouldn't break Web UI but Web UI won't use it. In add command Web UI uses only the command state (success/error). If the truststatus text would be a part of command summary text, it can be displayed in notification message (which fades after 3s) when comment 8 of https://fedorahosted.org/freeipa/ticket/2977#comment:8 is implemented. It would be nice if it can be saved to ldap and return in show/find commands? That way we can show it in search or details page. Or we can implement trust-status $TRUST --admin $ADMIN --$password $PASSWORD command to check the actual status anytime in a future. bye, Sumit bye, Sumit -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0073 Add trust verification code
On Tue, 18 Sep 2012, Petr Vobornik wrote: On 09/18/2012 02:15 PM, Sumit Bose wrote: On Tue, Sep 18, 2012 at 12:42:49PM +0200, Sumit Bose wrote: On Mon, Sep 17, 2012 at 06:44:36PM +0300, Alexander Bokovoy wrote: Hi, Following patch adds trust verification sequence to the case when we establish trust with knowledge of AD administrative credentials. As we found out, in order to validate/verify trust, one has to have administrative credentials for the trusted domain, since there are few RPCs that should be performed against trusted domain's DC's LSA and NetLogon pipes and these are protected by administrative credentials. Thus, when we know admin credentials for the remote domain, we can perform the trust validation. https://fedorahosted.org/freeipa/ticket/2763 Just a short feedback. The patch is working as expected, for a newly created trust Windows will send a TGS request to the IPA KDC without explicit validation on the windows side. Currently I have some issues in my test setup so that I can not give a full ACK atm. ok, ACK. Nevertheless it would be nice if Petr can check for any implications to the web UI with respect to the status of the trust. It shouldn't break Web UI but Web UI won't use it. In add command Web UI uses only the command state (success/error). If the truststatus text would be a part of command summary text, it can be displayed in notification message (which fades after 3s) when comment 8 of https://fedorahosted.org/freeipa/ticket/2977#comment:8 is implemented. It is displayed as part of the output, truststatus property: # ipa trust-add --type=ad --admin Administrator@ad.local --password ad.local Active directory domain adminstrator's password: - Added Active Directory trust for realm ad.local - Realm name: ad.local Domain NetBIOS name: AD Domain Security Identifier: S-1-5-21-16904141-148189700-2149043814 Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified Would be good if you could take it in use. It would be nice if it can be saved to ldap and return in show/find commands? That way we can show it in search or details page. Or we can implement trust-status $TRUST --admin $ADMIN --$password $PASSWORD command to check the actual status anytime in a future. We don't have an attribute to store the status. Neither it exists in Windows. I'll talk to Simo if we can have one attribute like that but the price of maintaining it up to date might be too much. On the other hand, we can always invalidate value in the attribute when ipasam cannot use shared trust account against trusted domain... Running validation/verification as a separate command is possible but it would be relatively resource-hungry and makes little use on its own. We may couple it together with future multiple suffixes support (tickets #2848, #2593) as fetching additional suffixes depends on validated trust relationship. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0073 Add trust verification code
On 09/18/2012 03:22 PM, Alexander Bokovoy wrote:
On Tue, 18 Sep 2012, Petr Vobornik wrote:
On 09/18/2012 02:15 PM, Sumit Bose wrote:
On Tue, Sep 18, 2012 at 12:42:49PM +0200, Sumit Bose wrote:
On Mon, Sep 17, 2012 at 06:44:36PM +0300, Alexander Bokovoy wrote:
Hi,
Following patch adds trust verification sequence to the case when we
establish trust with knowledge of AD administrative credentials.
As we found out, in order to validate/verify trust, one has to have
administrative credentials for the trusted domain, since there are
few RPCs that should be performed against trusted domain's DC's LSA
and NetLogon pipes and these are protected by administrative
credentials.
Thus, when we know admin credentials for the remote domain, we can
perform the trust validation.
https://fedorahosted.org/freeipa/ticket/2763
Just a short feedback. The patch is working as expected, for a newly
created trust Windows will send a TGS request to the IPA KDC without
explicit validation on the windows side. Currently I have some issues
in my test setup so that I can not give a full ACK atm.
ok, ACK.
Nevertheless it would be nice if Petr can check for any implications to
the web UI with respect to the status of the trust.
It shouldn't break Web UI but Web UI won't use it. In add command Web
UI uses only the command state (success/error). If the truststatus
text would be a part of command summary text, it can be displayed in
notification message (which fades after 3s) when comment 8 of
https://fedorahosted.org/freeipa/ticket/2977#comment:8 is implemented.
It is displayed as part of the output, truststatus property:
# ipa trust-add --type=ad --admin Administrator@ad.local --password
ad.local
Active directory domain adminstrator's password:
-
Added Active Directory trust for realm ad.local
-
Realm name: ad.local
Domain NetBIOS name: AD
Domain Security Identifier: S-1-5-21-16904141-148189700-2149043814
Trust direction: Two-way trust
Trust type: Active Directory domain
Trust status: Established and verified
Would be good if you could take it in use.
I created a patch which uses it. See attached screenshots. It may be
useful but, as I wrote, the message is displayed only for 3s, so some
users might not have time to read it whole - message is too long.
It would be nice if it can be saved to ldap and return in show/find
commands? That way we can show it in search or details page. Or we can
implement trust-status $TRUST --admin $ADMIN --$password $PASSWORD
command to check the actual status anytime in a future.
We don't have an attribute to store the status. Neither it exists in
Windows.
I'll talk to Simo if we can have one attribute like that but the price
of maintaining it up to date might be too much. On the other hand, we
can always invalidate value in the attribute when ipasam cannot use
shared trust account against trusted domain...
Running validation/verification as a separate command is possible but it
would be relatively resource-hungry and makes little use on its own. We
may couple it together with future multiple suffixes support (tickets
#2848, #2593) as fetching additional suffixes depends on validated trust
relationship.
--
Petr Vobornik
From 7835f62bccefe69abc6122d4ddd6aa7c571f59b2 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Tue, 18 Sep 2012 17:12:59 +0200
Subject: [PATCH] Show trust status in add success notification
Web UI notification of 'Add verification step after trust creation'
https://fedorahosted.org/freeipa/ticket/2763
---
install/ui/add.js | 9 +
install/ui/trust.js | 14 ++
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/install/ui/add.js b/install/ui/add.js
index d855879452e5812c8c7fbae7bc9d1ff9035f1a6e..06c9b325a58e31e3366529b552df29109117f847 100644
--- a/install/ui/add.js
+++ b/install/ui/add.js
@@ -52,7 +52,7 @@ IPA.entity_adder_dialog = function(spec) {
var facet = IPA.current_entity.get_facet();
facet.refresh();
that.close();
-IPA.notify_success(that.get_success_message());
+IPA.notify_success(that.get_success_message(data));
},
that.on_error);
}
@@ -66,7 +66,7 @@ IPA.entity_adder_dialog = function(spec) {
that.add(
function(data, text_status, xhr) {
that.added.notify();
-that.show_message(that.get_success_message());
+that.show_message(that.get_success_message(data));
var facet = IPA.current_entity.get_facet();
facet.refresh();
that.reset();
@@ -86,7 +86,7 @@ IPA.entity_adder_dialog = function(spec) {
Re: [Freeipa-devel] [PATCH] 0073 Add trust verification code
On Tue, 18 Sep 2012, Petr Vobornik wrote: On 09/18/2012 03:22 PM, Alexander Bokovoy wrote: On Tue, 18 Sep 2012, Petr Vobornik wrote: On 09/18/2012 02:15 PM, Sumit Bose wrote: On Tue, Sep 18, 2012 at 12:42:49PM +0200, Sumit Bose wrote: On Mon, Sep 17, 2012 at 06:44:36PM +0300, Alexander Bokovoy wrote: Hi, Following patch adds trust verification sequence to the case when we establish trust with knowledge of AD administrative credentials. As we found out, in order to validate/verify trust, one has to have administrative credentials for the trusted domain, since there are few RPCs that should be performed against trusted domain's DC's LSA and NetLogon pipes and these are protected by administrative credentials. Thus, when we know admin credentials for the remote domain, we can perform the trust validation. https://fedorahosted.org/freeipa/ticket/2763 Just a short feedback. The patch is working as expected, for a newly created trust Windows will send a TGS request to the IPA KDC without explicit validation on the windows side. Currently I have some issues in my test setup so that I can not give a full ACK atm. ok, ACK. Nevertheless it would be nice if Petr can check for any implications to the web UI with respect to the status of the trust. It shouldn't break Web UI but Web UI won't use it. In add command Web UI uses only the command state (success/error). If the truststatus text would be a part of command summary text, it can be displayed in notification message (which fades after 3s) when comment 8 of https://fedorahosted.org/freeipa/ticket/2977#comment:8 is implemented. It is displayed as part of the output, truststatus property: # ipa trust-add --type=ad --admin Administrator@ad.local --password ad.local Active directory domain adminstrator's password: - Added Active Directory trust for realm ad.local - Realm name: ad.local Domain NetBIOS name: AD Domain Security Identifier: S-1-5-21-16904141-148189700-2149043814 Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified Would be good if you could take it in use. I created a patch which uses it. See attached screenshots. It may be useful but, as I wrote, the message is displayed only for 3s, so some users might not have time to read it whole - message is too long. Well, as we don't have other means to show this information right now, that's good too. Maybe notification message timer could be possible to tune per instance? Then we could have, say, 5 seconds timeout here and keep 3 seconds as default one... -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0073 Add trust verification code
On 09/18/2012 05:33 PM, Alexander Bokovoy wrote:
On Tue, 18 Sep 2012, Petr Vobornik wrote:
On 09/18/2012 03:22 PM, Alexander Bokovoy wrote:
On Tue, 18 Sep 2012, Petr Vobornik wrote:
On 09/18/2012 02:15 PM, Sumit Bose wrote:
On Tue, Sep 18, 2012 at 12:42:49PM +0200, Sumit Bose wrote:
On Mon, Sep 17, 2012 at 06:44:36PM +0300, Alexander Bokovoy wrote:
Hi,
Following patch adds trust verification sequence to the case when we
establish trust with knowledge of AD administrative credentials.
As we found out, in order to validate/verify trust, one has to have
administrative credentials for the trusted domain, since there are
few RPCs that should be performed against trusted domain's DC's LSA
and NetLogon pipes and these are protected by administrative
credentials.
Thus, when we know admin credentials for the remote domain, we can
perform the trust validation.
https://fedorahosted.org/freeipa/ticket/2763
Just a short feedback. The patch is working as expected, for a newly
created trust Windows will send a TGS request to the IPA KDC without
explicit validation on the windows side. Currently I have some issues
in my test setup so that I can not give a full ACK atm.
ok, ACK.
Nevertheless it would be nice if Petr can check for any
implications to
the web UI with respect to the status of the trust.
It shouldn't break Web UI but Web UI won't use it. In add command Web
UI uses only the command state (success/error). If the truststatus
text would be a part of command summary text, it can be displayed in
notification message (which fades after 3s) when comment 8 of
https://fedorahosted.org/freeipa/ticket/2977#comment:8 is implemented.
It is displayed as part of the output, truststatus property:
# ipa trust-add --type=ad --admin Administrator@ad.local --password
ad.local
Active directory domain adminstrator's password:
-
Added Active Directory trust for realm ad.local
-
Realm name: ad.local
Domain NetBIOS name: AD
Domain Security Identifier: S-1-5-21-16904141-148189700-2149043814
Trust direction: Two-way trust
Trust type: Active Directory domain
Trust status: Established and verified
Would be good if you could take it in use.
I created a patch which uses it. See attached screenshots. It may be
useful but, as I wrote, the message is displayed only for 3s, so some
users might not have time to read it whole - message is too long.
Well, as we don't have other means to show this information right now,
that's good too. Maybe notification message timer could be possible to
tune per instance? Then we could have, say, 5 seconds timeout here and
keep 3 seconds as default one...
I tuned it. Updated patch attached.
--
Petr Vobornik
From 4ec95483604c22119f3fa1405103558176e07784 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Tue, 18 Sep 2012 17:12:59 +0200
Subject: [PATCH] Show trust status in add success notification
Web UI notification of 'Add verification step after trust creation'
https://fedorahosted.org/freeipa/ticket/2763
---
install/ui/add.js | 13 +
install/ui/ipa.js | 4 ++--
install/ui/trust.js | 18 ++
3 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/install/ui/add.js b/install/ui/add.js
index d855879452e5812c8c7fbae7bc9d1ff9035f1a6e..a5e30092f10495266351674b37fc8fa912af0fbe 100644
--- a/install/ui/add.js
+++ b/install/ui/add.js
@@ -52,7 +52,7 @@ IPA.entity_adder_dialog = function(spec) {
var facet = IPA.current_entity.get_facet();
facet.refresh();
that.close();
-IPA.notify_success(that.get_success_message());
+that.notify_success(data);
},
that.on_error);
}
@@ -66,7 +66,7 @@ IPA.entity_adder_dialog = function(spec) {
that.add(
function(data, text_status, xhr) {
that.added.notify();
-that.show_message(that.get_success_message());
+that.show_message(that.get_success_message(data));
var facet = IPA.current_entity.get_facet();
facet.refresh();
that.reset();
@@ -86,7 +86,7 @@ IPA.entity_adder_dialog = function(spec) {
that.close();
var result = data.result.result;
that.show_edit_page(that.entity, result);
-IPA.notify_success(that.get_success_message());
+that.notify_success(data);
},
that.on_error);
}
@@ -102,11 +102,15 @@ IPA.entity_adder_dialog = function(spec) {
});
};
-that.get_success_message = function() {
+that.get_success_message = function(data) {
Re: [Freeipa-devel] [PATCH] 0081 Only stop the main DS instance when upgrading it
Martin Kosek wrote: On 09/14/2012 04:53 PM, Petr Viktorin wrote: On 09/14/2012 04:12 PM, Petr Viktorin wrote: On 09/14/2012 03:12 PM, Simo Sorce wrote: On Fri, 2012-09-14 at 14:53 +0200, Petr Viktorin wrote: This fixes a 2.2→3.0 upgrade bug found while testing the Dogtag 10 work. See commit or ticket for details. https://fedorahosted.org/freeipa/ticket/3083 I also suspect that waiting for ports is not a good way to check if the CMS is fully initialized, but I don't know of a better way. If you know one, please speak up. Such a better way is coming with https://fedorahosted.org/pki/ticket/314. I opened https://fedorahosted.org/freeipa/ticket/3084 so we won't forget to take advantage of it. Won;t we get back to square zero when the work to merge DS and CS instances into one will be completed ? Simo. When they're merged we'll probably need to bring down the CA while upgrading the server. Or just stop all the IPA services to be on the safe side, and of course bring them back up afterwards. Meanwhile, this patch shouldn't hurt things. The patch worked fine for me. It will be useful at least to the point when we use a common DS instance, as Simo suggested. Useful for now, pushed to master and ipa-3-0. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0073 Add trust verification code
On Tue, 18 Sep 2012, Petr Vobornik wrote: On 09/18/2012 05:33 PM, Alexander Bokovoy wrote: On Tue, 18 Sep 2012, Petr Vobornik wrote: On 09/18/2012 03:22 PM, Alexander Bokovoy wrote: On Tue, 18 Sep 2012, Petr Vobornik wrote: On 09/18/2012 02:15 PM, Sumit Bose wrote: On Tue, Sep 18, 2012 at 12:42:49PM +0200, Sumit Bose wrote: On Mon, Sep 17, 2012 at 06:44:36PM +0300, Alexander Bokovoy wrote: Hi, Following patch adds trust verification sequence to the case when we establish trust with knowledge of AD administrative credentials. As we found out, in order to validate/verify trust, one has to have administrative credentials for the trusted domain, since there are few RPCs that should be performed against trusted domain's DC's LSA and NetLogon pipes and these are protected by administrative credentials. Thus, when we know admin credentials for the remote domain, we can perform the trust validation. https://fedorahosted.org/freeipa/ticket/2763 Just a short feedback. The patch is working as expected, for a newly created trust Windows will send a TGS request to the IPA KDC without explicit validation on the windows side. Currently I have some issues in my test setup so that I can not give a full ACK atm. ok, ACK. Nevertheless it would be nice if Petr can check for any implications to the web UI with respect to the status of the trust. It shouldn't break Web UI but Web UI won't use it. In add command Web UI uses only the command state (success/error). If the truststatus text would be a part of command summary text, it can be displayed in notification message (which fades after 3s) when comment 8 of https://fedorahosted.org/freeipa/ticket/2977#comment:8 is implemented. It is displayed as part of the output, truststatus property: # ipa trust-add --type=ad --admin Administrator@ad.local --password ad.local Active directory domain adminstrator's password: - Added Active Directory trust for realm ad.local - Realm name: ad.local Domain NetBIOS name: AD Domain Security Identifier: S-1-5-21-16904141-148189700-2149043814 Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified Would be good if you could take it in use. I created a patch which uses it. See attached screenshots. It may be useful but, as I wrote, the message is displayed only for 3s, so some users might not have time to read it whole - message is too long. Well, as we don't have other means to show this information right now, that's good too. Maybe notification message timer could be possible to tune per instance? Then we could have, say, 5 seconds timeout here and keep 3 seconds as default one... I tuned it. Updated patch attached. ACK. Worked fine for me. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 212 Fix integer validation when boundary value is empty string
On 9/18/2012 6:36 AM, Petr Vobornik wrote: Updated patch attached. ACK. 1. Instead of IPA.not_defined() it might be better to call it IPA.defined() to avoid double negations like this: if (!IPA.not_defined(metadata.minvalue, true) ... Function renamed, logic negated. Unit tests for IPA.defined added. 2. The check_empty_str probably could made optional and the value would be true by default. It will make the code cleaner. I wanted the function to be more general - used somewhere else in a future. In general, I consider empty string as a defined value so for me 'false' is a good default value of the argument. I agree that in this case it would look cleaner. OK. It's also possible to use different methods, e.g. IPA.is_null() and IPA.is_empty(). -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0073 Add trust verification code
Alexander Bokovoy wrote: On Tue, 18 Sep 2012, Petr Vobornik wrote: On 09/18/2012 05:33 PM, Alexander Bokovoy wrote: On Tue, 18 Sep 2012, Petr Vobornik wrote: On 09/18/2012 03:22 PM, Alexander Bokovoy wrote: On Tue, 18 Sep 2012, Petr Vobornik wrote: On 09/18/2012 02:15 PM, Sumit Bose wrote: On Tue, Sep 18, 2012 at 12:42:49PM +0200, Sumit Bose wrote: On Mon, Sep 17, 2012 at 06:44:36PM +0300, Alexander Bokovoy wrote: Hi, Following patch adds trust verification sequence to the case when we establish trust with knowledge of AD administrative credentials. As we found out, in order to validate/verify trust, one has to have administrative credentials for the trusted domain, since there are few RPCs that should be performed against trusted domain's DC's LSA and NetLogon pipes and these are protected by administrative credentials. Thus, when we know admin credentials for the remote domain, we can perform the trust validation. https://fedorahosted.org/freeipa/ticket/2763 Just a short feedback. The patch is working as expected, for a newly created trust Windows will send a TGS request to the IPA KDC without explicit validation on the windows side. Currently I have some issues in my test setup so that I can not give a full ACK atm. ok, ACK. Nevertheless it would be nice if Petr can check for any implications to the web UI with respect to the status of the trust. It shouldn't break Web UI but Web UI won't use it. In add command Web UI uses only the command state (success/error). If the truststatus text would be a part of command summary text, it can be displayed in notification message (which fades after 3s) when comment 8 of https://fedorahosted.org/freeipa/ticket/2977#comment:8 is implemented. It is displayed as part of the output, truststatus property: # ipa trust-add --type=ad --admin Administrator@ad.local --password ad.local Active directory domain adminstrator's password: - Added Active Directory trust for realm ad.local - Realm name: ad.local Domain NetBIOS name: AD Domain Security Identifier: S-1-5-21-16904141-148189700-2149043814 Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified Would be good if you could take it in use. I created a patch which uses it. See attached screenshots. It may be useful but, as I wrote, the message is displayed only for 3s, so some users might not have time to read it whole - message is too long. Well, as we don't have other means to show this information right now, that's good too. Maybe notification message timer could be possible to tune per instance? Then we could have, say, 5 seconds timeout here and keep 3 seconds as default one... I tuned it. Updated patch attached. ACK. Worked fine for me. Pushed 073 and 215.1 to ipa-3-0 and master rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
