Re: [Freeipa-devel] [PATCH] 568 fix mutual exclusive comparison in hbac
On 10/11/2010 10:09 AM, Rob Crittenden wrote: Do better error checking in mutual exclusivity check in hbac plugin. This fixes the acceptance tests. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Initial gettext support for C tools
On Tue, 12 Oct 2010 10:44:29 -0400 John Dennis jden...@redhat.com wrote: On 10/11/2010 06:43 PM, Simo Sorce wrote: Ok, I've filtered out a few other files/directories. I think the list now is correct, but whoever will end up reviewing this patchset *please* explicitly ack if you think the list is correct or not (you can run the new shiny make debug to get the new list of files :) I also decided to split the patch in 3 separate patches. 1. to delete the Makefile that I think was erroneously committed by Adam 2. to add C files and to fix install/po/Makefile.in 3. to update the .pot and .po files after the changes to the makefile The third patch is compressed (now approx 80KiB) as fully uncompressed it is something monstrous like 1.5MiB ... Simo. Patch 1: ACK Patch 2: This is what I came up with as differences in the file list (all were additions from the previous Makefile.in) checks/check-ra.py doc/examples/examples.py doc/examples/python-api.py install/share/wsgi.py ipa-radius-server/plugins/__init__.py ipa-radius-server/plugins/radiusinstance.py ipalib/plugins/hbacsvc.py ipalib/plugins/hbacsvcgroup.py ipalib/plugins/ping.py ipalib/plugins/sudocmd.py ipalib/plugins/sudocmdgroup.py ipalib/plugins/sudorule.py ipalib/plugins/whoami.py ipapython/certmonger.py ipapython/radius_util.py ipaserver/install/upgradeinstance.py daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_common.c daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_encoding.c daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c daemons/ipa-slapi-plugins/ipa-version/ipa_repl_version.c daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h The doc directory should be excluded. We're not shipping radius support so radius files should be excluded too. I think the other additions are O.K., others should review as well. The doc and radius inclusions should be fixed to receive ACK, otherwise patch looks fine. Ok, I'll add the 2 exclusions, although I wonder if we shouldn't just remove the radius code and readd it only once we support it again ? Patch 3: These are the msg stats prior to the patch: ipa.pot has 414 messages. There are 17 po translation files. bn_IN:24/414 5.8% 390 po untranslated,0 missing, 390 untranslated de:0/414 0.0% 414 po untranslated,0 missing, 414 untranslated es: 380/414 91.8% 34 po untranslated,0 missing, 34 untranslated fr:0/414 0.0% 414 po untranslated,0 missing, 414 untranslated id: 121/414 29.2% 293 po untranslated,0 missing, 293 untranslated he:0/414 0.0% 414 po untranslated,0 missing, 414 untranslated it:0/414 0.0% 414 po untranslated,0 missing, 414 untranslated ja:0/414 0.0% 414 po untranslated,0 missing, 414 untranslated kn: 348/414 84.1% 66 po untranslated,0 missing, 66 untranslated ko:0/414 0.0% 414 po untranslated,0 missing, 414 untranslated pl: 377/414 91.1% 37 po untranslated,0 missing, 37 untranslated pt:0/414 0.0% 414 po untranslated,0 missing, 414 untranslated pt_BR: 0/414 0.0% 414 po untranslated,0 missing, 414 untranslated ru: 135/414 32.6% 279 po untranslated,0 missing, 279 untranslated uk: 414/414 100.0%0 po untranslated,0 missing,0 untranslated zh_CN: 185/414 44.7% 229 po untranslated,0 missing, 229 untranslated zh_TW: 0/414 0.0% 414 po untranslated,0 missing, 414 untranslated These are the msg stats after the patch: ipa.pot has 577 messages. There are 17 po translation files. bn_IN:38/577 6.6% 539 po untranslated,0 missing, 539 untranslated de:0/577 0.0% 577 po untranslated,0 missing, 577 untranslated es: 425/577 73.7% 152 po untranslated,0 missing, 152 untranslated fr:0/577 0.0% 577 po untranslated,0 missing, 577 untranslated id: 137/577 23.7% 440 po untranslated,0 missing, 440 untranslated he:0/577 0.0% 577 po untranslated,0 missing, 577 untranslated it:0/577 0.0% 410 po untranslated, 167 missing, 577 untranslated ja:0/577 0.0% 577 po untranslated,0 missing, 577 untranslated kn: 392/577 67.9% 185 po untranslated,0 missing, 185 untranslated ko:0/577 0.0% 577 po untranslated,0 missing, 577 untranslated pl: 422/577 73.1% 155 po untranslated,0 missing, 155 untranslated pt:0/577 0.0% 577 po untranslated,0 missing, 577 untranslated pt_BR: 0/577 0.0% 577 po untranslated,0 missing, 577 untranslated ru: 153/577 26.5% 424 po untranslated,0 missing, 424 untranslated uk: 459/577 79.5% 118 po untranslated,0 missing, 118 untranslated zh_CN: 218/577 37.8% 359 po untranslated,0 missing, 359 untranslated zh_TW: 0/577 0.0% 577 po
Re: [Freeipa-devel] [PATCH] 544 add import to automount
Rob Crittenden wrote: Add ability to import automount files from the command-line. Support is fairly basic right now and will only work on the CLI. All the work is done on the client side. To continue past errors use the --continue option. Fixed a bug where direct mounts weren't always added properly. Added real user documentation to the plugin. rob Updated patch. The local get_args() isn't needed any more. rob freeipa-544-2-automount.patch Description: application/mbox ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Initial gettext support for C tools
On 10/12/2010 12:01 PM, Simo Sorce wrote: On Tue, 12 Oct 2010 10:57:11 -0400 Simo Sorcesso...@redhat.com wrote: I may have inadvertently altered it while investigating the update-po issue. I will make sure I run update-po in a clean tree to regenerate the third patch. Ok, new patches attached that should address all your requests. Thanks! ACK -- John Dennis jden...@redhat.com 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
Re: [Freeipa-devel] [PATCH] admiyo-freeipa-0054-dns-metadata.patch
On 10/06/2010 07:06 PM, Adam Young wrote: In order to generate the metadate, the dns plugin needs to have a __json__ method. Long term, this should be rewritten as a baseldap extension. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACKed in IRC by edewata and pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Initial gettext support for C tools
On Tue, 12 Oct 2010 14:25:42 -0400 John Dennis jden...@redhat.com wrote: On 10/12/2010 12:01 PM, Simo Sorce wrote: On Tue, 12 Oct 2010 10:57:11 -0400 Simo Sorcesso...@redhat.com wrote: I may have inadvertently altered it while investigating the update-po issue. I will make sure I run update-po in a clean tree to regenerate the third patch. Ok, new patches attached that should address all your requests. Thanks! ACK ok, Pushed. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] DNS use cases
Here is what I have so far. Sorry so long. I'll work to get this down to a more usable size, but would like feedback from any brave soul willing to read through this wall of text. DNS administration is like the story of the blindmen and the elephant. Many people find that do a significant amount of DNS administration only perform a subset of activites that map to their companies business use of DNS. Usage patterns include: A Large organization that provides a hostname for each users desktop system. An online service provider that maps subdomains from their clients to small number servers providing cutomized content. A ISP that hosts a large number of domains managed by the ISPs clients, each on a virtual server that runs on a smaller number of physical servers The clients of that ISP that need to create subdomains for specific uses (CMS, web services etc). Software development shops that create subdomains for a small subset of users who need to routinely create and destroy large numbers of host entries. Typically, the usage falls into a small number of use cases: 1. View and edit all of the records associated with a single host 2. Create or edit a Zone based on a template or simple business rules Of the record types we handle, it makes sense to look at their expected cardinality: A: Typically, an A Record is canonical, not just for a public name, but for man y CNAME recordfs pointing to that host. It hast the split identity of being the name that everyone uses to refer to some resources, but also acts as an insulation layer between a large number of CNAME record alias and a IPAddress that may change over time. CNAME: Often these will refer to A records not even in the same domain. While the recommended usage states that a CNAMe should onluy point to an A Record, in practice people can point one CNAME to another CNAME record. This usage is common when the first CNAME is managed by one organization, and the second is managed by the ISP for the first. SRV Records are rare, but require much more information than a A, , CNAME, PTR etx record. Like a CNAME or PTR, part of the SRC record is a pointer to another host, and again, this should be a Canonical target (A Record). It probably makes sense for us to force A records to be HOST entries, and to use those to populate the values for CNAME, SRC, PTR, SRV, etc records. Certain large organizations are going to take a Zone based apporoach to DNS. FOr an ISP, each customer is likely to have a Domain name and will need certain basica records. At a minimum, they need an A or CNAME record for the main host that they manage, even if this host is shared buy other users. Management of those Zones may be delegated to the customers. They are also likely to want MX record for their domain. This is likely to point to a centralized mail server for all customers, where the mail will be sorted based on spam filtering before delivery. Again, it should point to an A record. The RFC is pretty clear on this point, so it is unclear whether people actually have MX records which refer to CNAME records. PTR records typically are used for Reverse DNS lookups. As such, DNS should return only one record for a given hostname, although different hostnames may all map to the same IP address. It may not make sense to force this onto an IPA Host object, as it is likely that the end user will want to move the IP address from one host to another, and have all of the PTR records remain valid. However, without forcing it onto a host object, we have no way to say show me all of the hostnames that map to this IP address. Of the many forms of Key and certificate records, none of them seem to point to other hosts, but are instead associated with a zone. For example, DNSSEC uses the Key record. It is requested based on a Hostname, and returns a key. The IPSEC record is an exception, but we do not currently support that record type. It is unlikely that we will need explicit records for NSEC* records, as they basically say The host you requested does not exist. Since DNS provides a Canonical answer about existence, denying the existence of a host that does exist tends to break things. Instead, I suspect that these records are autogenerated based on the set of hostnames that we *do* provide answers for. SIG records do not refer to hosts. RRSIG records, which we support use this format. Instead, they sign a record set, or collection of recrods of type RR. We don't seem to support type RR records, which leaves me a little confused. an RR record does have a hostname in it. SOA records are 1-to-1 with a zone. As such, the CLI methods dns-add, dns-mod etc modify the SOA for a given zone. The MNAME is a server that Manges the records. In an ideal world, this would be a host in IPA, so we can see all the zones managed by a given DNS server. Really, there are two use cases
Re: [Freeipa-devel] [PATCH] 544 add import to automount
On 10/12/2010 02:20 PM, Rob Crittenden wrote:
Rob Crittenden wrote:
Add ability to import automount files from the command-line.
Support is fairly basic right now and will only work on the CLI. All the
work is done on the client side.
To continue past errors use the --continue option.
Fixed a bug where direct mounts weren't always added properly.
Added real user documentation to the plugin.
rob
Updated patch. The local get_args() isn't needed any more.
rob
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
ACK
This really should have a unit test.
It doesn't fail too cleanly:
[ayo...@ipa freeipa]$ echo BLAH /tmp/automount.garbage
[ayo...@ipa freeipa]$ ipa automountlocation-import /tmp/automount.garbage
Master file:
[ayo...@ipa freeipa]$ ipa automountlocation-import default
/tmp/automount.garbage
ipa: ERROR: non-public: IndexError: list index out of range
Traceback (most recent call last):
File /usr/lib/python2.6/site-packages/ipalib/backend.py, line 125,
in execute
result = self.Command[_name](*args, **options)
File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 401,
in __call__
ret = self.run(*args, **options)
File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 675,
in run
return self.forward(*args, **options)
File /usr/lib/python2.6/site-packages/ipalib/plugins/automount.py,
line 358, in forward
if am[1].startswith('/'):
IndexError: list index out of range
ipa: ERROR: an internal error has occurred
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 544 add import to automount
On 10/12/2010 06:04 PM, Adam Young wrote:
On 10/12/2010 02:20 PM, Rob Crittenden wrote:
Rob Crittenden wrote:
Add ability to import automount files from the command-line.
Support is fairly basic right now and will only work on the CLI. All
the
work is done on the client side.
To continue past errors use the --continue option.
Fixed a bug where direct mounts weren't always added properly.
Added real user documentation to the plugin.
rob
Updated patch. The local get_args() isn't needed any more.
rob
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
ACK
This really should have a unit test.
It doesn't fail too cleanly:
[ayo...@ipa freeipa]$ echo BLAH /tmp/automount.garbage
[ayo...@ipa freeipa]$ ipa automountlocation-import
/tmp/automount.garbage
Master file:
[ayo...@ipa freeipa]$ ipa automountlocation-import default
/tmp/automount.garbage
ipa: ERROR: non-public: IndexError: list index out of range
Traceback (most recent call last):
File /usr/lib/python2.6/site-packages/ipalib/backend.py, line 125,
in execute
result = self.Command[_name](*args, **options)
File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line
401, in __call__
ret = self.run(*args, **options)
File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line
675, in run
return self.forward(*args, **options)
File /usr/lib/python2.6/site-packages/ipalib/plugins/automount.py,
line 358, in forward
if am[1].startswith('/'):
IndexError: list index out of range
ipa: ERROR: an internal error has occurred
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Pushed t0 master
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
