Re: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool
On 21.6.2013 11:45, Tomas Babej wrote: On 06/21/2013 09:32 AM, Jan Cholasta wrote: On 21.6.2013 09:16, Tomas Babej wrote: I'm also thinking about propagating the --verbose, etc. options provided by default by AdminTool down to plugin level so that plugin authors can make use of them. What do you think? +1 Newly added features: - options propagated to plugins - made plugin content creation more comfortable, now 3 classes of output are available (debug, comment, command) Now pretty much everything that comes into my mind is addressed, so please have a look at the current implementation. Any suggestions welcome. New version: - provides require_root setting for plugins What would happen if require_root = False, UID = 1234 but the plugin requires root access? (I.e. there is an error in the require_root value.) I don't like this boolean, because plugin author has to test the plugin and maintain the boolean after each change in the plugin. From my (naive) point of view it is error prone and unnecessary. Proper error handling seems like 'the right way'™ to me. -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0227-0229 freeipa-tests package Beaker integration plugin
On 06/17/2013 09:10 PM, Dmitri Pal wrote: On 06/17/2013 11:08 AM, Petr Viktorin wrote: ipa-run-tests --with-beakerlib is horribly slow for me, is that expected? Yes. For every logged line, BeakerLib's default logging backend starts up Python, parses a XML file, appends the line, and writes the XML out again. So especially with longer runs it's really slow. Is there any way to solve this problem? For example send the output over the DBUS to a special service that would have the python already loaded and would do the appending to the files and writing the output. Also there can be an optimization that it would not save the file up until the change affects a different file. The logic would be: loop: If do not have an open output file open one and keep it in memory Read a request for update until receive a special message for termination or a signal, then break out of the loop If the request for update for the same file update the file Else save currently open file and start a new one, add data to the newly started file end close currently open file I hope Beaker does something like you described. The slow part is only the XML backend, which gets selected if you run BeakerLib without Beaker. We could write (or find?) a faster logging backend but it's not really necessary. Without Beaker the BeakerLib logging is not of much use anyway. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 421 Fix default value selection in radio widget
On 06/20/2013 06:11 PM, Ana Krivokapic wrote: On 06/18/2013 07:28 PM, Petr Vobornik wrote: Fix default value selection in radio widget https://fedorahosted.org/freeipa/ticket/3718 The web UI now displays 'Forward policy' as 'Forward first' when no policy is active (e.g. in case of empty Global DNS Configuration). Do we really want to have a default value for this particular radio button? Shouldn't it be unselected as default? -- Regards, Ana Krivokapic IMO checking 'Forward first' when value is missing is correct. 'Forward first' is default in BIND so It tells admin what is the effective value and therefore admin doesn't have to remember what are the defaults. There is one case when it would make sense to leave it unchecked. That is when no Global forwarder is set. 'Forward policy' is not used in that case. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0033 Fail when adding a trust with a different range
On 06/19/2013 10:07 AM, Tomas Babej wrote:
On 06/13/2013 12:17 PM, Ana Krivokapic wrote:
On 06/12/2013 12:14 PM, Martin Kosek wrote:
On 06/12/2013 11:40 AM, Tomas Babej wrote:
On 06/12/2013 10:23 AM, Alexander Bokovoy wrote:
On Mon, 10 Jun 2013, Ana Krivokapic wrote:
And once here(added by your patch):
+if not self.validate_range(*keys, **options):
+raise errors.ValidationError(
+name=_('id range'),
+error=_(
+'An id range already exists for this trust. '
+'You should either delete the old range, or '
+'exclude --base-id/--range-size options from the
command.'
I'd suggest we have one common place, say validate_range() function as
we have now,
that contains all the checks (more coming in the future for sure).
That would mean that the whole trust-add command will fail in the case
that ID range
with the same name but different domain SID already exists, since we
now call validate_range()
within execute() method. I checked with Alexander and we agreed that
this is more desired behaviour.
This would also result to reducement of the number of API calls, which
is a nice benefit.
Tomas
This updated patch completely separates validation logic and object
creation logic of the trust_add command. I added two new methods:
* validate_range(), which ensures that the options and environment
related to idrange is valid, and
* validate_options, which takes care of other general validation
One change introduced in this patch is making the
__populate_remote_domain() method of TrustDomainJoins class public, and
calling it from trust_add. This was necessary in order to enable
discovering details of the trusted domain in validation phase.
Looks good overall but I'd suggest to wrap populate_remote_domain()
calls in join_ad_* methods instead of removing them. If remote domain is
not initialized (i.e. not(isinstance(self.remote_domain,TrustedDomainInstance)),
then call populate_remote_domain() as it was before.
Fixed.
I tested the patch and it works fine.
There's a lot of refactoring done, but the changes preserve equal state. Aside
from
Alexander's comment up here, I have but one nitpick.
There are few constructs of the form:
try:
value = dictionary['keyword']
except KeyError:
value = None
or
if 'keyword' in dictionary:
value = dictionary['keyword']
else:
value = None
Can you please substitute these with value = dictionary.get(keyword, None)?
Not everywhere, but there are places where it can improve readability of the
code.
You can even use just value = dictionary.get(keyword) as None is the default
return value:
print {}.get(foo)
Fixed.
None
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Updated patch attached.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
ACK
Tomas
Pushed to master.
--
Petr³
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0037 Do not display traceback to user
On 06/20/2013 02:37 PM, Tomas Babej wrote: On 06/17/2013 03:11 PM, Ana Krivokapic wrote: Hello, Logging tracebacks at the INFO level caused them to be displayed to user on the command line. Change the log level to DEBUG, so that tracebacks are not visible to user. https://fedorahosted.org/freeipa/ticket/3704 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK Tomas Pushed to master, ipa-3-2. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0029 Make sure replication works after DM password is changed
On 06/11/2013 04:42 PM, Ade Lee wrote:
[snip]
Just FYI, we plan to do a new release of pki-core today
(pki-core-10.0.3-2) to address this issue.
--
Regards,
Ana Krivokapic
Associate Software Engineer
FreeIPA team
Red Hat Inc.
Ok, so I tested the patch, since pki-core has the PkiExport command
fixed now.
I'm getting a little bit further now.
[tbabej@vm-127 ~]$ sudo ipa-replica-prepare --ip-address 10.34.47.129
vm-129.idm.lab.eng.brq.redhat.com
Directory Manager (existing master) password:
Preparing replica for vm-129.idm.lab.eng.brq.redhat.com from
vm-127.idm.lab.eng.brq.redhat.com
Constraint violation: Failed to update password
With debug output, I get (snipped out irrelevant parts):
Directory Manager (existing master) password:
ipa.ipaserver.plugins.ldap2.ldap2: DEBUG: Created connection
context.ldap2_57668944
ipa.ipapython.ipaldap.SchemaCache: DEBUG: retrieving schema for
SchemaCache
url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket
conn=ldap.ldapobject.SimpleLDAPObject instance at 0x3700ab8
ipa.ipaserver.plugins.ldap2.ldap2: DEBUG: Destroyed connection
context.ldap2_57668944
ipa: DEBUG: Search DNS for vm-129.idm.lab.eng.brq.redhat.com
ipa: DEBUG: Search failed: [Errno -2] Name or service not known
ipa.ipapython.ipaldap.SchemaCache: DEBUG: flushing
ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket from
SchemaCache
ipa.ipapython.ipaldap.SchemaCache: DEBUG: retrieving schema for
SchemaCache
url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket
conn=ldap.ldapobject.SimpleLDAPObject instance at 0x4c704d0
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: Not
logging to a file
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG:
ipa-replica-prepare was invoked with arguments
['vm-129.idm.lab.eng.brq.redhat.com'] and options: {'log_file': None,
'verbose': True, 'reverse_zone': None, 'setup_pkinit': True, 'http_pin':
None, 'quiet': False, 'http_pkcs12': None, 'pkinit_pkcs12': None,
'ca_file': '/root/cacert.p12', 'no_reverse': False, 'dirsrv_pkcs12':
None, 'password': None, 'ip_address': CheckedIPAddress('10.34.47.129'),
'dirsrv_pin': None, 'pkinit_pin': None}
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: INFO:
Preparing replica for vm-129.idm.lab.eng.brq.redhat.com from
vm-127.idm.lab.eng.brq.redhat.com
ipa.ipapython.ipaldap.SchemaCache: DEBUG: flushing
ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket from
SchemaCache
ipa.ipapython.ipaldap.SchemaCache: DEBUG: retrieving schema for
SchemaCache
url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket
conn=ldap.ldapobject.SimpleLDAPObject instance at 0x3700710
ipa: DEBUG: Starting external process
ipa: DEBUG: args=/usr/bin/PKCS12Export -d /etc/pki/pki-tomcat/alias/ -p
/tmp/tmprgUrso -w /tmp/tmp6SBBXF -o /root/cacert.p12
ipa: DEBUG: Process finished, return code=0
ipa: DEBUG: stdout=
ipa: DEBUG: stderr=
ipa.ipaserver.plugins.ldap2.ldap2: DEBUG: Created connection
context.ldap2_139884970376144
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File
/usr/lib/python2.7/site-packages/ipapython/admintool.py, line 171, in
execute
return_value = self.run()
File
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py,
line 245, in run
self.copy_ds_certificate()
File
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py,
line 281, in copy_ds_certificate
self.update_pki_admin_password()
File
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py,
line 520, in update_pki_admin_password
ldap.modify_password(dn, self.dirman_password)
File /usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py,
line 332, in modify_password
self.conn.passwd_s(dn, old_pass, new_pass)
File /usr/lib64/python2.7/contextlib.py, line 35, in __exit__
self.gen.throw(type, value, traceback)
File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line
919, in error_handler
raise errors.DatabaseError(desc=desc, info=info)
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: The
ipa-replica-prepare command failed, exception: DatabaseError: Constraint
violation: Failed to update password
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR:
Constraint violation: Failed to update password
Tomas
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0030] Require rid-base and secondary-rid-base options in idrange-add when trust exists
On 06/21/2013 03:59 PM, Tomas Babej wrote: On 06/21/2013 03:38 PM, Ana Krivokapic wrote: On 06/21/2013 02:39 PM, Tomas Babej wrote: On 06/12/2013 07:06 PM, Ana Krivokapic wrote: On 06/11/2013 06:44 PM, Alexander Bokovoy wrote: On Tue, 11 Jun 2013, Martin Kosek wrote: 2) Is the used ldapsearch really the best way to find out if Trust is configured on a given master? Isn't a search in cn=masters,cn=ipa,... better? Alexander? What would the search in cn=masters,cn=ipa,.. give? We can have multiple CIFS services per realm. However, only those in 'adtrust agents' group are the ones which are real DCs. And since membership in the group is not handled via framework or UI, it is clear indication that ipa-adtrust-install was run. It would say if there as an appropriate service configured by ipa-adtrust-install. In this case, cn=ADTRUST,cn=FQDN,cn=masters,cn=ipa,cn=etc,SUFFIX. I am asking because this is a standard way in FreeIPA to ask for configured services. If that does not work for Trust, then your alternative way should be OK too. This would work for making sure that ipa-adtrust-install was run on a specific server. It will not work for making sure trusts are enabled but in this case we only need to know that we have configured the host to be a DC so your approach is fine. I'm fine to use this approach, somehow it slipped out of my view when we discussed it with Ana.. I amended the name of the new command to 'adtrust_is_enabled'. I also simplified the LDAP search used in the command, as suggested by Martin and Alexander. Updated patch is attached. Can you please rebase the patch? I think tests - ipatests change is the culprit here. Tomas Sure, rebased patch is attached. ACK Tomas Pushed to master. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool
On 06/24/2013 09:35 AM, Petr Spacek wrote: What would happen if require_root = False, UID = 1234 but the plugin requires root access? (I.e. there is an error in the require_root value.) The calling of particular external command that requires root access for its execution will fail. I don't like this boolean, because plugin author has to test the plugin and maintain the boolean after each change in the plugin. From my (naive) point of view it is error prone and unnecessary. Why? From my point of view, it simplifies the work for the plugin author, since he can set the boolean if he knows that plugin will need root access to require information needed. Without it: - If he wanted to stay user-friendly he would have to implement the check for effective UID in every plugin. - If he did not, he would be having his command fail with (often) cryptic errors. Proper error handling seems like 'the right way'™ to me. What kind of proper error handling? The errors are now properly handled via AdminTool's framework. Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Bug?
Is this a bug for which I should open a bug report? # Configure the Network File Server yum install --assumeyes freeipa-admintools Loaded plugins: langpacks, refresh-packagekit Package freeipa-admintools-3.2.1-1.fc19.x86_64 already installed and latest version Nothing to do echo adminpassword | kinit admin Password for ad...@hunter.org ipa service-add nfs/ipa19.hunter.org --- Added service nfs/ipa19.hunter@hunter.org --- Principal: nfs/ipa19.hunter@hunter.org Managed by: ipa19.hunter.org ipa-getkeytab \\ --keytab /etc/krb5.keytab \\ --principal nfs/ipa19.hunter.org \\ --server ipa19.hunter.org Failed to retrieve encryption type Camellia-128 CTS mode with CMAC (#25) Failed to retrieve encryption type Camellia-256 CTS mode with CMAC (#26) kdestroy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Bug?
Dean Hunter wrote: Is this a bug for which I should open a bug report? # Configure the Network File Server yum install --assumeyes freeipa-admintools Loaded plugins: langpacks, refresh-packagekit Package freeipa-admintools-3.2.1-1.fc19.x86_64 already installed and latest version Nothing to do echo adminpassword | kinit admin Password for ad...@hunter.org mailto:ad...@hunter.org ipa service-add nfs/ipa19.hunter.org --- Added service nfs/ipa19.hunter.org@HUNTER. mailto:ipa19.hunter.org@HUNTERORG --- Principal: nfs/ipa19.hunter@hunter.org Managed by: ipa19.hunter.org ipa-getkeytab \\ --keytab /etc/krb5.keytab \\ --principal nfs/ipa19.hunter.org \\ --server ipa19.hunter.org Failed to retrieve encryption type Camellia-128 CTS mode with CMAC (#25) Failed to retrieve encryption type Camellia-256 CTS mode with CMAC (#26) kdestroy Not really. Camellia was enabled by default in 1.11 (it was added back in 1.9, but disabled by default). IPA does not currently enable the cipher on the KDC. So this is the client requesting all enabled ciphers and the server not returning the Camellia ciphers. It is just a warning. At best this is an RFE to enable Camellia by default on the KDC. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 421 Fix default value selection in radio widget
On 06/24/2013 12:42 PM, Petr Vobornik wrote: On 06/20/2013 06:11 PM, Ana Krivokapic wrote: On 06/18/2013 07:28 PM, Petr Vobornik wrote: Fix default value selection in radio widget https://fedorahosted.org/freeipa/ticket/3718 The web UI now displays 'Forward policy' as 'Forward first' when no policy is active (e.g. in case of empty Global DNS Configuration). Do we really want to have a default value for this particular radio button? Shouldn't it be unselected as default? -- Regards, Ana Krivokapic IMO checking 'Forward first' when value is missing is correct. 'Forward first' is default in BIND so It tells admin what is the effective value and therefore admin doesn't have to remember what are the defaults. OK, that makes sense. There is one case when it would make sense to leave it unchecked. That is when no Global forwarder is set. 'Forward policy' is not used in that case. So in that case 'Forward policy' should be disabled. In other words, it should only be enabled when 'Global forwarders' is not empty. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0067] Add --use-posix option that forces trusted range type
On 06/20/2013 12:56 PM, Tomas Babej wrote: On 06/17/2013 02:34 PM, Ana Krivokapic wrote: On 06/06/2013 11:10 AM, Tomas Babej wrote: Hi, Adds --use-posix option to ipa trust-add command. It takes two allowed values: 'yes' : the 'ipa-ad-trust-posix' range type is enforced 'no' : the 'ipa-ad-trust' range type is enforced When --use-posix option is not specified, the range type should be determined by ID range discovery. https://fedorahosted.org/freeipa/ticket/3650 Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel The patch works nicely, but I have a few comments: 1) You added a new option to the API, but you forgot to bump the IPA_API_VERSION_MINOR in the VERSION file. 2) Typo in commit message: shold instead of should. 3) This construct: +if range_type is not None: +if range_type != old_range_type: can be replaced with a more readable variant which also avoids nested ifs: +if range_type and range_type != old_range_type: All fixed. 4) Some unit tests to cover the behavior of the newly added option would be nice. This is not doable at the moment, we have no unit test framework to test the trust-add command. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Tomas I don't know much about AD trusts, but a command-line/API option that takes a 'yes' or 'no' string raised a tiny warning flag for me. It looks like it's possible that there can be other range types in the future than posix and algorithmic? If that's the case, there should be a --range-type option instead. (If not, I'd still go for --range-type but that would just be bikeshedding.) In any case I think an explicit 'auto' option would be nice. But that's just an outsider's view, maybe --use-posix makes more sense. AFAIK, for CLI changes there should be a a design page; is this covered anywhere? -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0166] Fix minor coding style issue in update_config()
ACK The patch looks good. Regards, Tomas Hozza - Original Message - Hello, Fix minor coding style issue in update_config(). -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 421 Fix default value selection in radio widget
On 06/24/2013 04:01 PM, Ana Krivokapic wrote: On 06/24/2013 12:42 PM, Petr Vobornik wrote: On 06/20/2013 06:11 PM, Ana Krivokapic wrote: On 06/18/2013 07:28 PM, Petr Vobornik wrote: Fix default value selection in radio widget https://fedorahosted.org/freeipa/ticket/3718 The web UI now displays 'Forward policy' as 'Forward first' when no policy is active (e.g. in case of empty Global DNS Configuration). Do we really want to have a default value for this particular radio button? Shouldn't it be unselected as default? -- Regards, Ana Krivokapic IMO checking 'Forward first' when value is missing is correct. 'Forward first' is default in BIND so It tells admin what is the effective value and therefore admin doesn't have to remember what are the defaults. OK, that makes sense. There is one case when it would make sense to leave it unchecked. That is when no Global forwarder is set. 'Forward policy' is not used in that case. So in that case 'Forward policy' should be disabled. In other words, it should only be enabled when 'Global forwarders' is not empty. I've discussed it with Ana in person and we've agreed on that the current approach is sufficient (ACK). Pushed to master, ipa-3-2. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 425 Do not redirect to https in /ipa/ui on non-HTML files
Those resources are needed by page which has to use http(browser config)
prior to acceptance of CA cert.
https://fedorahosted.org/freeipa/ticket/3748
--
Petr Vobornik
From 892ab95f1fe6fe9c186f1bdc84f218fcb1e0c147 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Mon, 24 Jun 2013 17:44:15 +0200
Subject: [PATCH] Do not redirect to https in /ipa/ui on non-HTML files
Those resources are needed by page which has to use http(browser config) prior to acceptance of CA cert.
https://fedorahosted.org/freeipa/ticket/3748
---
install/conf/ipa-rewrite.conf | 1 +
1 file changed, 1 insertion(+)
diff --git a/install/conf/ipa-rewrite.conf b/install/conf/ipa-rewrite.conf
index 552682b05bb8a911c8b735a3e7252cba24288f9b..c473673c765eb3c5bd3639df6a7f3a98b2db57ea 100644
--- a/install/conf/ipa-rewrite.conf
+++ b/install/conf/ipa-rewrite.conf
@@ -15,6 +15,7 @@ RewriteRule ^/ipa/(.*) http://$FQDN/ipa/$$1 [L,R=301]
# configuration.
RewriteCond %{SERVER_PORT} !^443$$
RewriteCond %{REQUEST_URI} !^/ipa/(errors|config|crl)
+RewriteCond %{REQUEST_URI} !^/ipa/[^\?]+(\.js|\.css|\.png|\.gif|\.ico|\.woff|\.svg|\.ttf|\.eot)$$
RewriteRule ^/ipa/(.*) https://$FQDN/ipa/$$1 [L,R=301,NC]
# Rewrite for plugin index, make it like it's a static file
--
1.8.1.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 425 Do not redirect to https in /ipa/ui on non-HTML files
On 06/24/2013 06:13 PM, Petr Vobornik wrote: Those resources are needed by page which has to use http(browser config) prior to acceptance of CA cert. https://fedorahosted.org/freeipa/ticket/3748 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I think you (technically) need to update the version in the first commented line. (Probably would not be an issue for anybody, since we haven't done a release since it was last changed) Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
