Re: [Freeipa-devel] [PATCH] 28 One Liner: Typo in host_nis_groups has been creating 2 CN's
JR Aquino wrote: On May 18, 2011, at 2:52 PM, Rob Crittenden wrote: JR Aquino wrote: On May 18, 2011, at 12:46 PM, JR Aquino wrote: This effects Ticket 1222 and Rob's patch 786 Per IRC Conversation with Simo and Rob, take the path of least change. The patch has been modified to correct the CN to match the DN rather than changing both. This looks good. I'm going to wait to push it at the same time as 786. Simo mentioned that I need to create the .update in the patch so that we remove the previous typo laden entry during updates. I added that to my patch. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 158 JavaScript ordered map.
On 05/18/2011 10:21 AM, Endi Sukma Dewata wrote: A utility class has been added to store objects which can be accessed both as an ordered list and as a map. This class is used to store various objects including entities, fields, columns, and dialogs. The class needs to be defined in a new file called util.js to avoid circular dependency problem. A test suite for this class has been added as well. Ticket #1232 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Good. The only thing I don't like about it is the Util namespace. I think this should be a JQuery plugin instead. Adding a Util namespace is just ignoring the problem of namespace pollution. Can you move it to JQuery, and rename the file and class ordered_map? Put some documentation in the file as to the contract: we explicitly don't hide access to the internals, but if you don't use the manipulator functions, you will corrupt the map etc. This is where Javascript would really benefit from a macro language. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 787 Don't load LDAP schema at startup
Do a lazy retrieval of the LDAP schema rather than at module load. Attempt to retrieve the schema the first time it is needed rather than when Apache is started. A global copy is cached for future requests for performance reasons. The schema will be retrieved once per Apache child process. ticket 583 This replaces Jan's patch titled Don't load the LDAP schema during startup rob freeipa-rcrit-787-schema.patch Description: application/mbox ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Don't load the LDAP schema during startup
Jan Zelený wrote: Jan Zelenýjzel...@redhat.com wrote: Jan Zelenyjzel...@redhat.com wrote: Jan Zelenýjzel...@redhat.com wrote: Jan Zelenýjzel...@redhat.com wrote: Rob Crittendenrcrit...@redhat.com wrote: Jan Zelený wrote: Rob Crittendenrcrit...@redhat.com wrote: Jan Zelený wrote: Loading of the schema is now performed in the first request that requires it. https://fedorahosted.org/freeipa/ticket/583 Jan We still need to enforce that we get the schema, some low-level functions depend on it. Also, if the UI doesn't get its aciattrs (which are derived from the schema) then nothing will be editable. I'm getting this backtrace if I force no schema by disabling get_schema: Ok, I'm sending new version, it should handle these exceptions better and the operation should fail if it needs the schema and the schema is not available for some reason. This breaks the XML-RPC server. I fixed one problem: --- a/ipaserver/plugins/ldap2.py +++ b/ipaserver/plugins/ldap2.py @@ -253,9 +253,10 @@ class ldap2(CrudBackend, Encoder): def get_syntax(self, attr, value): if not self.schema: -self.schema = get_schema(self.ldap_uri, self.conn) -if not self.schema: +schema = get_schema(self.ldap_uri, self.conn) +if not schema: return None +object.__setattr__(self, 'schema', schema) obj = self.schema.get_obj(_ldap.schema.AttributeType, attr) if obj is not None: return obj.syntax But simply things like get_entry() return an InternalError now. I'm not sure where you were going by adding this. rob Ok, no problem. It's possible that I simply did a mistake thinking I can do something in Python what is not really possible. About that InternalError: I think raising InternalError when we cannot load the schema to do the decoding is the right thing to do. Do you have a better solution? I thought about returning empty result, but that would mean we have to check the result in every funtction that is calling them and raising InternalError there. I'm sending updated patch. I modified the get_syntax() as you suggested and I slightly modified raising that InternalError - currently it isn't raised when results from get_entry() are not required by calling method. Currently I'm running some tests, preliminary results looked ok. self-nack I discovered some issues discovered by internal test suite, I'm working on them Jan Ok, everything is solved, I'm sending final version of the patch in the attachment. But I still think this should go to 2.1, since it's quite extensive patch in the core of IPA server and it has potential to break many things. Jan Rebased against master Jan I came up with an alternate patch that just does lazy retrieval of the schema rather than getting it at start up. Without the schema we can do very little required enforcement so we shouldn't proceed. See my patch 787 Don't load LDAP schema at startup rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Ticket #1107 - firewall troubles
Hello, I am working on ticket #1107 and I am looking for some ideas hot to deal with it. The problem is that when we are installing a replica and have firewall on, the installation may fail or (even worse) hang. There question is how to deal with this situation since we cannot test if the ports are not blocked locally. It must be done from the remote master. I discussed this with Rob and I see two solutions here: 1) Don't complicate this and limit our user handholding (my favorite) - just tell him what ports he should open before proceeding with the installation. If he doesn't, the installation will fail later. The problem is when the installation hangs - its hard to detect. This is the easy way. 2) Implement and register a mod_wsgi application on a master server and let it test remotely if the ports on the replica are open. We would have to open and listen them in ipa-replica-install as we cannot tell if port is not-yet-opened or firewalled just from the network error code. If the application would report a firewalled port, we would throw an error in the ipa-replica-install. However, as Rob pointed out, it would open a possible security hole as we would basically behave as port scanner. Any opinions, suggestions, ideas on this? Thanks, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Ticket #1107 - firewall troubles
On Thu, 2011-05-19 at 21:54 +0200, Martin Kosek wrote: Hello, I am working on ticket #1107 and I am looking for some ideas hot to deal with it. The problem is that when we are installing a replica and have firewall on, the installation may fail or (even worse) hang. There question is how to deal with this situation since we cannot test if the ports are not blocked locally. It must be done from the remote master. I discussed this with Rob and I see two solutions here: 1) Don't complicate this and limit our user handholding (my favorite) - just tell him what ports he should open before proceeding with the installation. If he doesn't, the installation will fail later. The problem is when the installation hangs - its hard to detect. This is the easy way. 2) Implement and register a mod_wsgi application on a master server and let it test remotely if the ports on the replica are open. We would have to open and listen them in ipa-replica-install as we cannot tell if port is not-yet-opened or firewalled just from the network error code. If the application would report a firewalled port, we would throw an error in the ipa-replica-install. However, as Rob pointed out, it would open a possible security hole as we would basically behave as port scanner. It may also create SELinux issues as I think apache is not allowed to contact random ports normally. Any opinions, suggestions, ideas on this? I think a much better solution is to create a simple program pair one for the master and one for the wannabe replica. The one on the replica opens all relevant ports. The one to be run on the master tries to connect to all these ports. Each side will report port,service name,success/failure Bonus points if we create the replica program so that it can use admin credentials to ssh into the master and run the master side automatically properly merging the output of that side. 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] 786 Configure Managed Entries on replicas.
On May 18, 2011, at 2:52 PM, Rob Crittenden wrote: Rob Crittenden wrote: The Managed Entries plugin configurations weren't being created on replica installs. The templates were there but the cn=config portions were not. This patch adds them as updates. The template portion will be added in the initial replication. ticket 1222 To test: Install a master Install a replica On replica: kinit On replica: ipa user-add --first=timmy --last=test ttest On replica: ipa group-show ttest On master: ipa group-show ttest rob Updated patch attached. This requires jraquino patch 28 to work as expected. rob freeipa-rcrit-786-2-replica.patch NACK This patch is not applying to Master? error: patch failed: install/updates/Makefile.am:8 error: install/updates/Makefile.am: patch does not apply ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Ticket #1107 - firewall troubles
On 05/19/2011 04:41 PM, Simo Sorce wrote: On Thu, 2011-05-19 at 21:54 +0200, Martin Kosek wrote: Hello, I am working on ticket #1107 and I am looking for some ideas hot to deal with it. The problem is that when we are installing a replica and have firewall on, the installation may fail or (even worse) hang. There question is how to deal with this situation since we cannot test if the ports are not blocked locally. It must be done from the remote master. I discussed this with Rob and I see two solutions here: 1) Don't complicate this and limit our user handholding (my favorite) - just tell him what ports he should open before proceeding with the installation. If he doesn't, the installation will fail later. The problem is when the installation hangs - its hard to detect. This is the easy way. 2) Implement and register a mod_wsgi application on a master server and let it test remotely if the ports on the replica are open. We would have to open and listen them in ipa-replica-install as we cannot tell if port is not-yet-opened or firewalled just from the network error code. If the application would report a firewalled port, we would throw an error in the ipa-replica-install. However, as Rob pointed out, it would open a possible security hole as we would basically behave as port scanner. It may also create SELinux issues as I think apache is not allowed to contact random ports normally. Any opinions, suggestions, ideas on this? I think a much better solution is to create a simple program pair one for the master and one for the wannabe replica. The one on the replica opens all relevant ports. The one to be run on the master tries to connect to all these ports. Each side will report port,service name,success/failure Bonus points if we create the replica program so that it can use admin credentials to ssh into the master and run the master side automatically properly merging the output of that side. Simo. I think Simo has a point but it is too much for now. IMO it is Ok to fail and report a meaningful error message on either side. Installation hanging is what we should address here in the scope of 2.1. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
