Re: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API

[Martin Kosek]

On Wed, 2011-12-14 at 15:31 -0500, Dmitri Pal wrote:
> 
> The whole point of this work to decompose things and make them simpler.
> One command with dozens of options is much harder to use.
> I stand on my own point but we should ask community.

Lets see what the community would say about the API based on new options
instead of new commands. I proposed an API based on the discussion with
Rob and Endi in a new thread sent both to freeipa-devel and
freeipa-users.

This new way would require more changes to our framework which is not
ready for such interface yet but if the interface is accepted it should
be doable.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] Optionistic approach for new DNS API

[Martin Kosek]

Hello all,

we just had a good discussion with Rob and Endi about different approach
to the new DNS API. Current DNS API proposal (patches 174-176)
introduced new API based on different commands, e.g. for MX RR type:

ipa dnsrecord-mx-add ZONE NAME --preference=0 --exchanger=server1.example.com.
ipa dnsrecord-mx-mod ZONE NAME "0 server1.example.com." --preference=1
ipa dnsrecord-mx-show ZONE NAME

As a side effect, this would introduce many new commands
(dnsrecord-mx-add/mod/show, dnsrecord-loc-add/mod/show, ...) which may
of course be confusing.

Endi proposed an different approach to use rather per-type options
instead of commands, which I think is really interesting to think about.
I will summarize how the API may look like.

Changes to DNS module commands:
~~~
- no new DNS command would be implemented, we would just enhance current
dns record commands:
  * dnsrecord-add, dnsrecord-mod, dnsrecord-del and dnsrecord-find
- all changes must be compatible with 2.x clients, changes to output
shall be triggered by 3.x option

Command Structure:
~~
- we would introduce --type option which would trigger the command to
use the new structured DNS options, i.e.:

ipa dnsrecord-add ZONE NAME --type=mx --preference=0 
--exchanger=server1.example.com.

or

ipa dnsrecord-mod ZONE NAME VALUE? --type=mx --preference=0

or

ipa dnsrecord-del ZONE NAME --type=mx --preference=0 
--exchanger=server1.example.com.

- SHOW and FIND commands do not need this new --type parameter


Command Output:
~~~
- we would introduce a new --structured option which would switch
command output to "structured way" and present rather parsed DNS records
instead of raw DNS values (this is also needed for 2.x compatibility).

For JSON output we may get:

{
 idnsname: 'foo',
 records: [
 {
 type: 'a',
 data: '10.10.10.10',
 ip_address: '10.10.10.10'
 },
 {
 type: 'cname',
 data: 'bar.example.com.',
 hostname: 'bar.example.com.'
 },
 {
 type: 'cname',
 data: 'bar2.example.com.',
 hostname: 'bar2.example.com.'
 },
 ]
}

instead of

{
 idnsname: 'foo',
 arecord: [
 '10.10.10.10'
 ],
 cnamerecord: [
 'bar.example.com.',
 'bar2.example.com.'
 ]
}

In CLI it may look like this:
# ipa dnsrecordmx-show example.com @ --structured
  Record name: @
Record type: MX
Data: 0 server1.example.com
Preference: 0
Exchanger: server1.example.com

Record type: NS
Data: vm-068.idm.lab.bos.redhat.com.
Hostname: vm-068.idm.lab.bos.redhat.com.

instead of:

# ipa dnsrecord-show example.com @
  Record name: @
  MX record: 0 server1.example.com
  NS record: vm-068.idm.lab.bos.redhat.com.

Command help:
~
- since dnsrecord-add would accept all options from all DNS RR types,
its list would be overwhelming and not very helpful
- we can take advantage of OptionParser option groups. The help may look
like this:

$ ipa dnsrecord-add --help
Usage: ipa [global-options] dnsrecord-add DNSZONE NAME [options]

Options:
  -h, --help  show this help message and exit

SRV Options:
 --priority   Priority
 --weight Weight
 --port   Port
 --target Target

MX Options:
 --priority   Priority
 --exchanger  A host willing to act as a mail exchanger
...

Interactive mode in CLI:

- ADD command:
  - when no option is passed to dnsrecord-add command, it may ask for
--type and then for the options specific for the particular type
- MOD command:
  - when no option is passed to dnsrecord-mod command, it may provide a
list of current DNS record values and ask for specific DNS record parts
to be changed for chosen value
- DEL command:
  - when no option is passed to dnsrecord-del command, it may provide a
list of current DNS record values remove the chosen value

Any comments, suggestions? Do you think that introducing these new
options in current dnsrecord-add/mod/show/del commands would be better
and more usable that introducing these capabilities in separate
commands?

Thanks,
Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH 60] Implement session support in server, Manage sessions in WSGI

[John Dennis]

This patch adds the ipalib/session.py file which implements a cookie 
based session cache using memcached.


It also invokes the session cookie support when a HTTP request is 
received and stores the session data in the per-thread context object.


--
John Dennis 

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
>From 342039e65fa4f085e7800a01d569603e99c0e9d7 Mon Sep 17 00:00:00 2001
From: John Dennis 
Date: Wed, 14 Dec 2011 15:21:25 -0500
Subject: [PATCH 60] Implement session support in server Manage sessions in
 WSGI
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

---
 ipalib/session.py  |  309 
 ipaserver/rpcserver.py |   13 ++
 make-lint  |2 +
 3 files changed, 324 insertions(+), 0 deletions(-)
 create mode 100644 ipalib/session.py

diff --git a/ipalib/session.py b/ipalib/session.py
new file mode 100644
index 000..69dc636
--- /dev/null
+++ b/ipalib/session.py
@@ -0,0 +1,309 @@
+# Authors: John Dennis 
+#
+# Copyright (C) 2011  Red Hat
+# see file 'COPYING' for use and warranty information
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+
+import memcache
+import Cookie
+import random
+import errors
+import re
+from text import _
+from ipapython.ipa_log_manager import *
+
+class SessionManager(object):
+def __init__(self):
+log_mgr.get_logger(self, True)
+self.generated_session_ids = set()
+
+def generate_session_id(self, n_bits=48):
+'''
+Return a random string to be used as a session id.
+
+This implementation creates a string of hexadecimal digits.
+There is no guarantee of uniqueness, it is the caller's
+responsibility to validate the returned id is not currently in
+use.
+
+:parameters:
+  n_bits
+number of bits of random data, will be rounded to next
+highest multiple of 4 
+:returns:
+  string of random hexadecimal digits
+'''
+# round up to multiple of 4
+n_bits = (n_bits + 3) & ~3
+session_id = '%0*x' % (n_bits >> 2, random.getrandbits(n_bits))
+return session_id
+
+def new_session_id(self, max_retries=5):
+'''
+Returns a new *unique* session id. See `generate_session_id()`
+for how the session id's are formulated.
+
+The scope of the uniqueness of the id is limited to id's
+generated by this instance of the `SessionManager`.
+
+:parameters:
+  max_retries
+Maximum number of attempts to produce a unique id.
+:returns:
+  Unique session id as a string.
+'''
+n_retries = 0
+while n_retries < max_retries:
+session_id = self.generate_session_id()
+if not session_id in self.generated_session_ids:
+break
+n_retries += 1
+if n_retries >= max_retries:
+self.error('could not allocate unique new session_id, %d retries exhausted', n_retries)
+raise errors.ExecutionError(message=_('could not allocate unique new session_id'))
+self.generated_session_ids.add(session_id)
+return session_id
+
+
+class MemcacheSessionManager(SessionManager):
+memcached_socket_path = '/var/run/ipa_memcached/ipa_memcached'
+session_cookie_name = 'ipa_session'
+mc_server_stat_name_re = re.compile(r'(.+)\s+\((\d+)\)')
+
+def __init__(self):
+super(MemcacheSessionManager, self).__init__()
+self.servers = ['unix:%s' % self.memcached_socket_path]
+self.mc = memcache.Client(self.servers, debug=0)
+
+if not self.servers_running():
+self.warning("session memcached servers not running")
+
+def get_server_statistics(self):
+'''
+Return memcached server statistics.
+
+Return value is a dict whose keys are server names and whose
+value is a dict of key/value statistics as returned by the
+memcached server.
+
+:returns:
+  dict of server names, each value is dict of key/value server
+  statistics.
+
+'''
+result = {} 
+stats = self.mc.get_stats() 
+for server in stats: 

[Freeipa-devel] [PATCH 59] Modify spec file to add ipa_memcached service Install &, control ipa_memcached instance

[John Dennis]

This patch adds an ipa memcached service, it does the following:

* adds SysV initscript for ipa_memcached

* adds systemd service file for ipa_memcached

* adds tmpfiles.d configuration file for /var/run/ipa_memcached

* adds configuration file for ipa_memcached

* adds memcacheinstance.py file to create service instance during server 
install


* invokes installation of ipa_memcached during ipa-server-install

* adds dependencies to spec file

* adds ipa_memcached to ipactl service control

--
John Dennis 

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
>From c782c67086c6873329625000d988322df497fab1 Mon Sep 17 00:00:00 2001
From: John Dennis 
Date: Wed, 14 Dec 2011 15:19:56 -0500
Subject: [PATCH 59] Modify spec file to add ipa_memcached service Install &
 control ipa_memcached instance
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

---
 freeipa.spec.in   |   21 ++
 init/SystemV/ipa_memcached.init   |  120 +
 init/ipa_memcached.conf   |5 ++
 init/systemd/ipa.conf.tmpfiles|1 +
 init/systemd/ipa_memcached.service|   13 
 install/tools/ipa-server-install  |7 ++
 ipaserver/install/memcacheinstance.py |   26 +++
 ipaserver/install/service.py  |1 +
 8 files changed, 194 insertions(+), 0 deletions(-)
 create mode 100755 init/SystemV/ipa_memcached.init
 create mode 100644 init/ipa_memcached.conf
 create mode 100644 init/systemd/ipa.conf.tmpfiles
 create mode 100644 init/systemd/ipa_memcached.service
 create mode 100644 ipaserver/install/memcacheinstance.py

diff --git a/freeipa.spec.in b/freeipa.spec.in
index c14da8b..1ab71e9 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -109,6 +109,8 @@ Requires: python-ldap
 Requires: python-krbV
 Requires: acl
 Requires: python-pyasn1 >= 0.0.9a
+Requires: memcached
+Requires: python-memcached
 %if 0%{?fedora} >= 16
 Requires: systemd-units >= 36-3
 Requires(pre): systemd-units
@@ -348,12 +350,25 @@ mkdir -p %{buildroot}%{_sysconfdir}/httpd/conf.d/
 /bin/touch %{buildroot}%{_sysconfdir}/httpd/conf.d/ipa-pki-proxy.conf
 /bin/touch %{buildroot}%{_sysconfdir}/httpd/conf.d/ipa-rewrite.conf
 mkdir -p %{buildroot}%{_initrddir}
+mkdir %{buildroot}%{_sysconfdir}/sysconfig/
+install -m 644 init/ipa_memcached.conf %{buildroot}%{_sysconfdir}/sysconfig/ipa_memcached
+
+%if 0%{?fedora} >= 15
+mkdir -p %{buildroot}%{_sysconfdir}/tmpfiles.d/
+install -m 0644 init/systemd/ipa.conf.tmpfiles %{buildroot}%{_sysconfdir}/tmpfiles.d/ipa.conf
+%endif
+
+mkdir -p %{buildroot}%{_localstatedir}/run/
+install -d -m 0700 %{buildroot}%{_localstatedir}/run/ipa_memcached/
+
 %if 0%{?fedora} >= 16
 # Default to systemd initscripts for F16 and above
 mkdir -p %{buildroot}%{_unitdir}
 install -m 644 init/systemd/ipa.service %{buildroot}%{_unitdir}/ipa.service
+install -m 644 init/systemd/ipa_memcached.service %{buildroot}%{_unitdir}/ipa_memcached.service
 %else
 install -m755 init/SystemV/ipa.init %{buildroot}%{_initrddir}/ipa
+install -m755 init/SystemV/ipa_memcached.init %{buildroot}%{_initrddir}/ipa_memcached
 %endif
 %endif
 
@@ -482,9 +497,15 @@ fi
 %{_sbindir}/ipa-upgradeconfig
 %{_sbindir}/ipa-compliance
 %{_sysconfdir}/cron.d/ipa-compliance
+%config(noreplace) %{_sysconfdir}/sysconfig/ipa_memcached
+%dir %attr(0700,apache,apache) %{_localstatedir}/run/ipa_memcached/
+%if 0%{?fedora} >= 15
+%config %{_sysconfdir}/tmpfiles.d/ipa.conf
+%endif
 %if 0%{?fedora} >= 16
 # Use systemd scheme
 %attr(644,root,root) %{_unitdir}/ipa.service
+%attr(644,root,root) %{_unitdir}/ipa_memcached.service
 %else
 # Use SystemV scheme only before F16
 %attr(755,root,root) %{_initrddir}/ipa
diff --git a/init/SystemV/ipa_memcached.init b/init/SystemV/ipa_memcached.init
new file mode 100755
index 000..a4101d9
--- /dev/null
+++ b/init/SystemV/ipa_memcached.init
@@ -0,0 +1,120 @@
+#! /bin/sh
+#
+# chkconfig: - 55 45
+# description:	The ipa_memcached daemon is a memory cache service for IPA
+# processname: memcached
+# config: /etc/sysconfig/ipa_memcached
+# pidfile: /var/run/ipa_memcached/ipa_memcached.pid
+
+# Standard LSB functions
+#. /lib/lsb/init-functions
+
+# Source function library.
+. /etc/init.d/functions
+
+SOCKET_PATH=/var/run/ipa_memcached/ipa_memcached
+USER=apache
+PIDFILE=/var/run/ipa_memcached/ipa_memcached.pid
+MAXCONN=1024
+CACHESIZE=64
+OPTIONS=""
+
+if [ -f /etc/sysconfig/ipa_memcached ];then 
+. /etc/sysconfig/ipa_memcached
+fi
+
+# Check that networking is up.
+. /etc/sysconfig/network
+
+if [ "$NETWORKING" = "no" ]
+then
+exit 0
+fi
+
+prog="ipa_memcached"
+pidfile=${PIDFILE-/var/run/ipa_memcached/ipa_memcached.pid}
+lockfile=${LOCKFILE-/var/lock/subsys/ipa_memcached}
+
+start () {
+echo -n $"Starting $prog: "
+# Ensure that $pidfile directory has proper permissions and exists
+piddir=`dirname $pidfile`
+if [ ! -d $piddir ]; then
+	mkdir $piddir
+fi
+if [ "`stat -c %U $piddir`" != "$USER" ]; then
+	chown

Re: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API

[Martin Kosek]

On Wed, 2011-12-14 at 12:43 -0600, Endi Sukma Dewata wrote:
> On 12/14/2011 12:53 AM, Martin Kosek wrote:
> >> I found this works ok and adding records is definitely clearer but it
> >> seems odd to add with one command and delete/find with another. I could
> >> get used to it I suppose.
> >
> > Hm, we could add dnsrecord--del ZONE RECORD VALUE command, but this
> > would increase the already high number of DNS commands.
> 
> As suggested in the meeting, instead of having a separate command for 
> each type:
> 
>dnsrecordsrv-add ZONE NAME [srv-specific parameters...]
>dnsrecordmx-add ZONE NAME [mx-specific parameters...]
> 
> we could use the same command but we specify the type as a parameter:
> 
>dnsrecord-add ZONE NAME --rec-type=srv [srv-specific parameters...]
>dnsrecord-add ZONE NAME --rec-type=mx [mx-specific parameters...]
> 
> This will keep the number of commands low regardless of the number of 
> rrtypes we support now or in the future. Same thing for mod and del.
> 
> All type-specific options can be made optional, or we can require some 
> options depending on the type specified. The doc needs to specify which 
> options are needed for each type.
> 
> The interactive mode should still work too based on the type specified. 
> If the user doesn't specify a type the command can even ask for it.
> 
> > Endi and Petr had an idea to add a new --structured option for
> > dnsrecord-find/dnsrecord-show which would show structured DNS records
> > instead of raw DNS records. But I think our current framework is not
> > ready for this. While a raw DNS record is basically one entry item
> > (label : value), structured DNS record is an entry on its own
> > ({label1:value1, label2:value2, ...}):
> >   - dnsrecord-find's output is ListOfEntries, but with use of
> > --structured option it would have to be changed to something like
> > ListOfListsOfEntries
> >   - dnsrecord-show's output would have to be changed with a use of
> > --structured option from Entry to ListOfEntries
> 
> I think we're mixing up several alternatives in the discussion. Never 
> mind about dnsrecord-find/show returning record data in separate 
> entries. I don't think right now it will be a good idea since they are 
> actually attributes (no filter for certain param in the type, no primary 
> key).
> 
> What we're suggesting is the find command should always return a 
> ListOfEntries and the show command should always return an Entry, which 
> will be consistent with other commands. So when you call dnsrecord-show 
> ZONE NAME without --structured, it will return a single Entry like before:
> 
> {
>  idnsname: 'foo',
>  arecord: [
>  '10.10.10.10'
>  ],
>  cnamerecord: [
>  'bar.example.com.',
>  'bar2.example.com.'
>  ]
> }
> 
> But when you specify --structured, it still returns a single Entry 'foo' 
> but the structure of the attributes will change like this (or like the 
> one suggested by Petr):
> 
> {
>  idnsname: 'foo',
>  records: [
>  {
>  type: 'a',
>  data: '10.10.10.10',
>  ip_address: '10.10.10.10'
>  },
>  {
>  type: 'cname',
>  data: 'bar.example.com.',
>  hostname: 'bar.example.com.'
>  },
>  {
>  type: 'cname',
>  data: 'bar2.example.com.',
>  hostname: 'bar2.example.com.'
>  },
>  ]
> }
> 
> If you call dnsrecord-find ZONE --structured the output will be a 
> ListOfEntries like before, but each Entry will have a structure like above.
> 
> > Another problem I see is that different RR types have parts with the
> > same name (e.g. "preference" is both in MX, KX and NAPTR records). If
> > any record could appear in an output entry, we would break current rule
> > that every output parameter in an entry is uniquely defined. Though this
> > issue could be solved with a prefix for every structured DNS record
> > part, i.e. KX record would have "kxpreference" and "kxechanger" parts.
> 
> Since the 'records' attribute is an array in an Entry, there shouldn't 
> be any issue about uniqueness.
> 
> Also as suggested in my previous email, we can also add a --rec-types 
> parameter to the find/show command to select which rrtypes we want to 
> see in the result. If not specified it should return all types.
> 

I think this all are valid points, I will summarize the proposad
approach to DNS API based on options instead of commands to separate
mail. It is too important to get lost in this long thread :-)

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API

[Dmitri Pal]

On 12/14/2011 03:02 PM, Simo Sorce wrote:
>
> - Original Message -
>> On 12/14/2011 01:43 PM, Endi Sukma Dewata wrote:
>>> On 12/14/2011 12:53 AM, Martin Kosek wrote:
> I found this works ok and adding records is definitely clearer
> but it
> seems odd to add with one command and delete/find with another. I
> could
> get used to it I suppose.
 Hm, we could add dnsrecord--del ZONE RECORD VALUE command, but
 this
 would increase the already high number of DNS commands.
>>> As suggested in the meeting, instead of having a separate command
>>> for
>>> each type:
>>>
>>>   dnsrecordsrv-add ZONE NAME [srv-specific parameters...]
>>>   dnsrecordmx-add ZONE NAME [mx-specific parameters...]
>>>
>>> we could use the same command but we specify the type as a
>>> parameter:
>>>
>>>   dnsrecord-add ZONE NAME --rec-type=srv [srv-specific
>>>   parameters...]
>>>   dnsrecord-add ZONE NAME --rec-type=mx [mx-specific parameters...]
>>>
>>> This will keep the number of commands low regardless of the number
>>> of
>>> rrtypes we support now or in the future. Same thing for mod and
>>> del.
>>>
>>> All type-specific options can be made optional, or we can require
>>> some
>>> options depending on the type specified. The doc needs to specify
>>> which options are needed for each type.
>>>
>>> The interactive mode should still work too based on the type
>>> specified. If the user doesn't specify a type the command can even
>>> ask
>>> for it.
>>>
 Endi and Petr had an idea to add a new --structured option for
 dnsrecord-find/dnsrecord-show which would show structured DNS
 records
 instead of raw DNS records. But I think our current framework is
 not
 ready for this. While a raw DNS record is basically one entry item
 (label : value), structured DNS record is an entry on its own
 ({label1:value1, label2:value2, ...}):
   - dnsrecord-find's output is ListOfEntries, but with use of
 --structured option it would have to be changed to something like
 ListOfListsOfEntries
   - dnsrecord-show's output would have to be changed with a use of
 --structured option from Entry to ListOfEntries
>>> I think we're mixing up several alternatives in the discussion.
>>> Never
>>> mind about dnsrecord-find/show returning record data in
>>> separate entries. I don't think right now it will be a good idea
>>> since
>>> they are actually attributes (no filter for certain param in the
>>> type,
>>> no primary key).
>>>
>>> What we're suggesting is the find command should always return a
>>> ListOfEntries and the show command should always return an Entry,
>>> which will be consistent with other commands. So when you call
>>> dnsrecord-show ZONE NAME without --structured, it will return a
>>> single
>>> Entry like before:
>>>
>>> {
>>> idnsname: 'foo',
>>> arecord: [
>>> '10.10.10.10'
>>> ],
>>> cnamerecord: [
>>> 'bar.example.com.',
>>> 'bar2.example.com.'
>>> ]
>>> }
>>>
>>> But when you specify --structured, it still returns a single Entry
>>> 'foo' but the structure of the attributes will change like this (or
>>> like the one suggested by Petr):
>>>
>>> {
>>> idnsname: 'foo',
>>> records: [
>>> {
>>> type: 'a',
>>> data: '10.10.10.10',
>>> ip_address: '10.10.10.10'
>>> },
>>> {
>>> type: 'cname',
>>> data: 'bar.example.com.',
>>> hostname: 'bar.example.com.'
>>> },
>>> {
>>> type: 'cname',
>>> data: 'bar2.example.com.',
>>> hostname: 'bar2.example.com.'
>>> },
>>> ]
>>> }
>>>
>>> If you call dnsrecord-find ZONE --structured the output will be a
>>> ListOfEntries like before, but each Entry will have a structure
>>> like
>>> above.
>>>
 Another problem I see is that different RR types have parts with
 the
 same name (e.g. "preference" is both in MX, KX and NAPTR records).
 If
 any record could appear in an output entry, we would break current
 rule
 that every output parameter in an entry is uniquely defined.
 Though this
 issue could be solved with a prefix for every structured DNS
 record
 part, i.e. KX record would have "kxpreference" and "kxechanger"
 parts.
>>> Since the 'records' attribute is an array in an Entry, there
>>> shouldn't
>>> be any issue about uniqueness.
>>>
>>> Also as suggested in my previous email, we can also add a
>>> --rec-types
>>> parameter to the find/show command to select which rrtypes we want
>>> to
>>> see in the result. If not specified it should return all types.
>>>
>> But as Martin mentioned on the call we loose help capabilities and
>> make
>> things really more complex.
>> My vote would be to have separate commands. IMO it is better from
>> usability point of view.
> I disagree, it will make things a lot more cumbersome and will require
> entire new commands if we w

Re: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API

[Simo Sorce]

- Original Message -
> On 12/14/2011 01:43 PM, Endi Sukma Dewata wrote:
> > On 12/14/2011 12:53 AM, Martin Kosek wrote:
> >>> I found this works ok and adding records is definitely clearer
> >>> but it
> >>> seems odd to add with one command and delete/find with another. I
> >>> could
> >>> get used to it I suppose.
> >>
> >> Hm, we could add dnsrecord--del ZONE RECORD VALUE command, but
> >> this
> >> would increase the already high number of DNS commands.
> >
> > As suggested in the meeting, instead of having a separate command
> > for
> > each type:
> >
> >   dnsrecordsrv-add ZONE NAME [srv-specific parameters...]
> >   dnsrecordmx-add ZONE NAME [mx-specific parameters...]
> >
> > we could use the same command but we specify the type as a
> > parameter:
> >
> >   dnsrecord-add ZONE NAME --rec-type=srv [srv-specific
> >   parameters...]
> >   dnsrecord-add ZONE NAME --rec-type=mx [mx-specific parameters...]
> >
> > This will keep the number of commands low regardless of the number
> > of
> > rrtypes we support now or in the future. Same thing for mod and
> > del.
> >
> > All type-specific options can be made optional, or we can require
> > some
> > options depending on the type specified. The doc needs to specify
> > which options are needed for each type.
> >
> > The interactive mode should still work too based on the type
> > specified. If the user doesn't specify a type the command can even
> > ask
> > for it.
> >
> >> Endi and Petr had an idea to add a new --structured option for
> >> dnsrecord-find/dnsrecord-show which would show structured DNS
> >> records
> >> instead of raw DNS records. But I think our current framework is
> >> not
> >> ready for this. While a raw DNS record is basically one entry item
> >> (label : value), structured DNS record is an entry on its own
> >> ({label1:value1, label2:value2, ...}):
> >>   - dnsrecord-find's output is ListOfEntries, but with use of
> >> --structured option it would have to be changed to something like
> >> ListOfListsOfEntries
> >>   - dnsrecord-show's output would have to be changed with a use of
> >> --structured option from Entry to ListOfEntries
> >
> > I think we're mixing up several alternatives in the discussion.
> > Never
> > mind about dnsrecord-find/show returning record data in
> > separate entries. I don't think right now it will be a good idea
> > since
> > they are actually attributes (no filter for certain param in the
> > type,
> > no primary key).
> >
> > What we're suggesting is the find command should always return a
> > ListOfEntries and the show command should always return an Entry,
> > which will be consistent with other commands. So when you call
> > dnsrecord-show ZONE NAME without --structured, it will return a
> > single
> > Entry like before:
> >
> > {
> > idnsname: 'foo',
> > arecord: [
> > '10.10.10.10'
> > ],
> > cnamerecord: [
> > 'bar.example.com.',
> > 'bar2.example.com.'
> > ]
> > }
> >
> > But when you specify --structured, it still returns a single Entry
> > 'foo' but the structure of the attributes will change like this (or
> > like the one suggested by Petr):
> >
> > {
> > idnsname: 'foo',
> > records: [
> > {
> > type: 'a',
> > data: '10.10.10.10',
> > ip_address: '10.10.10.10'
> > },
> > {
> > type: 'cname',
> > data: 'bar.example.com.',
> > hostname: 'bar.example.com.'
> > },
> > {
> > type: 'cname',
> > data: 'bar2.example.com.',
> > hostname: 'bar2.example.com.'
> > },
> > ]
> > }
> >
> > If you call dnsrecord-find ZONE --structured the output will be a
> > ListOfEntries like before, but each Entry will have a structure
> > like
> > above.
> >
> >> Another problem I see is that different RR types have parts with
> >> the
> >> same name (e.g. "preference" is both in MX, KX and NAPTR records).
> >> If
> >> any record could appear in an output entry, we would break current
> >> rule
> >> that every output parameter in an entry is uniquely defined.
> >> Though this
> >> issue could be solved with a prefix for every structured DNS
> >> record
> >> part, i.e. KX record would have "kxpreference" and "kxechanger"
> >> parts.
> >
> > Since the 'records' attribute is an array in an Entry, there
> > shouldn't
> > be any issue about uniqueness.
> >
> > Also as suggested in my previous email, we can also add a
> > --rec-types
> > parameter to the find/show command to select which rrtypes we want
> > to
> > see in the result. If not specified it should return all types.
> >
> But as Martin mentioned on the call we loose help capabilities and
> make
> things really more complex.
> My vote would be to have separate commands. IMO it is better from
> usability point of view.

I disagree, it will make things a lot more cumbersome and will require
entire new commands if we want to add new types in future. It d

Re: [Freeipa-devel] WIP: ipa trust command

[Simo Sorce]

- Original Message -
> On 12/14/2011 10:58 AM, Simo Sorce wrote:
> > - Original Message -
> > We can also generate the SID algorithmically from the
> > uidNumber/gidNumber
>  Do you mean the SID of the trusted domain user?
> >>> No I meant the SID of users and groups.
> >> ok, I would very much favor this approach it will make things much
> >> easier. But iirc the idea was rejected some time ago, because we
> >> couldn't agree on a good algorithm which can remove the conflicts
> >> when
> >> uid and gid are the same. What would you suggest? Adding the
> >> highest
> >> bit
> >> for groups? uid*2 for users, (gid*2)+1 for groups? ... ?
> > Good question.
> >
> > So we need to decide whether we want algorithmic mapping or not (or
> > a hybrid).
> >
> > Advantages of fixed NT SIDs:
> > - Full control of users and group SIDs, you can simply remove a SID
> > to make the user or the group unavailable wrt Windows
> > compatibility (reduce PAC size and so on)
> > - Do not change if the admin needs to change uidNumber or gidNumber
> > for whatever reason.
> > - Easy to search by SID, does not require guessing what the
> > corresponding uid/gid are.
> > - SIDs can be applied also to non-user/group objects w/o having to
> > waste a uidNumber
> > - No risk of conflicts if admins decide not to use UPGs and have
> > unrelated groups and user that happen to algorithmically end up
> > with the same SID (or force us to waste space to assure all groups
> > have even RIDs and users odd RIDs)
> >
> > Disadvantages of fixed NT SIDs:
> > - Requires DNA plugin to assign values since first install
> > - Requires manual assignment, or fixup task if feature is activated
> > after a consistent number of users/groups have been created.
> > - third parties that have to do SID -> UID mapping on their own
> > (think a samba server joined to the AD side and that has no
> > knowledge these SIDs belong to an IPA domain) may get different
> > SID -> UID mappings.
> >
> >
> > I think the points above suggest we should indeed stick with the
> > original decision of storing the SID and not go algorithmic
> > (although the last point may be slightly annoying, it could be
> > easily solved by forcing mappings on the other side or giving them
> > read access to the IPA LDAP server for mapping purposes).
> >
> > The main issue is that we cannot assume DNA is configured from
> > first install because an upgrade from v2 to v3 will simply go
> > against it.
> > But a fixup task to handle the situation shouldn't be too bad.
> > The hardest problem will be to insure all servers that create
> > users/groups have the DNA plugin properly configured. And a
> > secondary, very minor, annoyance is that we will have to assign a
> > range for SIDs as well.
> > But this is not too hard we should probably just always assign a
> > 200k IDs starting from 2000 or so. We do not need a random range
> > because SIDs are unique across domains so we do not need to fear
> > any collisions on trust relationships. So this part is easy. We
> > limit initially to 1 Million only to keep RIDs in a very low
> > range, so that mapping SIDs to UID/GID numbers for 3rd parties is
> > not going to be problematic.
> > If we assigne a larger range like 2Billion the as soon as you
> > install a replica and create users there the range will be split
> > in 2 and users create from that other replica will have their RID
> > starting at 1Billion (as the range is split in 2 between the 2
> > replicas) which will make life difficult if someone want to limit
> > SID ranges for posix mapping purposes.
> >
> > Simo.
> >
> With the static IDs you will have an issue with DNA that you will
> have
> to implement 2 dimensional slicing if ranges. Right now the ranges
> are
> sliced per replica and traded accordingly. With your proposal the DNA
> would have to deal with a concept of group of ranges belonging to
> each
> domain and make sure that every replica has its slice for the group.
> I
> seems that it would require changes to the DNA plugin logic, not only
> configuration.
> Also the point about third parties IMO is just a showstopper. If we
> go
> with static IDs nobody would deploy us as we are nonexistent in real
> deployments while samba and other solutions are already deployed in
> multiple places. Poeple will be very frustrated to find out that our
> ids
> do not match.
> 
> Man ye we should do our own samba id mapping back end that would work
> like idmap_rid but factor in configured range and contribute it to
> samba.
> 
> But the problem of the collisions already exists  with samba when
> multiple domains are in play so I really do not understand why we
> should
> try to solve the problem that is pretty much unsolvable.

I think you are confusing 2 problems here.
1 problem (the one you have in mind) is mapping foreign SIDs from AD
domains to uid/gids, this is NOT the problem we are discussing here.

What we are discussing here is how to generate the SIDs for

Re: [Freeipa-devel] [PATCH] s4u2proxy support

[Alexander Bokovoy]

On Wed, 14 Dec 2011, Rob Crittenden wrote:

> Dmitri Pal wrote:
> >On 12/12/2011 07:15 PM, Simo Sorce wrote:
> >>On Mon, 2011-12-12 at 15:22 -0500, Rob Crittenden wrote:
> >>>This patch adds support for s4u2proxy. This means that the Apache
> >>>server
> >>>will obtain the ldap service ticket on behalf of the user rather than
> >>>the using having to send their TGT. The user's ticket still needs to
> >>>be
> >>>forwardable, we just don't require it to be forwarded any more.
> >>
> >>Should we make the patch allow the old behavior by using a switch that
> >>revert to forwarding the TGT ?
> >>
> >>It would be useful during upgrades if some of your servers still need
> >>forwarded TGTs, or if you want to use a newer client against an old
> >>server while you have the newer stuff under test.
> >>(And to test in general).
> >>
> >>Simo.
> >+1
> >
> 
> Updated patch attached.
> 
> rob

> >From 03a2c9a536811437e4847e1c6b11d2ac0eff98f2 Mon Sep 17 00:00:00 2001
> From: Rob Crittenden 
> Date: Thu, 8 Dec 2011 14:23:18 -0500
> Subject: [PATCH] Don't set delegation flag in client, we're using S4U2Proxy
>  now
> 
> A forwardable ticket is still required but we no longer need to send
> the TGT to the IPA server. A new flag, --delegation, is available if
> the old behavior is required.
A minor point: please fix commit message to use proper option name:

--delegate

> +parser.add_option('--delegate', action='store_true',
> +help='Delegate the TGT to the IPA server',
> +)

Otherwise ACK.

-- 
/ Alexander Bokovoy

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] s4u2proxy support

[Rob Crittenden]

Dmitri Pal wrote:

On 12/12/2011 07:15 PM, Simo Sorce wrote:

On Mon, 2011-12-12 at 15:22 -0500, Rob Crittenden wrote:

This patch adds support for s4u2proxy. This means that the Apache
server
will obtain the ldap service ticket on behalf of the user rather than
the using having to send their TGT. The user's ticket still needs to
be
forwardable, we just don't require it to be forwarded any more.


Should we make the patch allow the old behavior by using a switch that
revert to forwarding the TGT ?

It would be useful during upgrades if some of your servers still need
forwarded TGTs, or if you want to use a newer client against an old
server while you have the newer stuff under test.
(And to test in general).

Simo.

+1



Updated patch attached.

rob
>From 03a2c9a536811437e4847e1c6b11d2ac0eff98f2 Mon Sep 17 00:00:00 2001
From: Rob Crittenden 
Date: Thu, 8 Dec 2011 14:23:18 -0500
Subject: [PATCH] Don't set delegation flag in client, we're using S4U2Proxy
 now

A forwardable ticket is still required but we no longer need to send
the TGT to the IPA server. A new flag, --delegation, is available if
the old behavior is required.

https://fedorahosted.org/freeipa/ticket/1098
---
 ipa.1   |3 +++
 ipalib/backend.py   |2 +-
 ipalib/constants.py |1 +
 ipalib/plugable.py  |5 -
 ipalib/rpc.py   |   24 +---
 5 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/ipa.1 b/ipa.1
index 4c8ba377effba3324de4d2c9c0e5898f2e9fa2b9..91432a0afa3e2e88d744505234b2b459cbd6b77e 100644
--- a/ipa.1
+++ b/ipa.1
@@ -37,6 +37,9 @@ Load configuration from \fIFILE\fR.
 \fB\-d\fR, \fB\-\-debug\fR
 Produce full debugging output.
 .TP
+\fB\-\-\-delegate\fR
+Delegate the user's TGT to the IPA server
+.TP
 \fB\-e\fR \fIKEY=VAL\fR
 Set environmental variable \fIKEY\fR to the value \fIVAL\fR. This option overrides configuration files.
 .TP
diff --git a/ipalib/backend.py b/ipalib/backend.py
index 79f190832b72f3e41ff0d6b0a4dcf619b35ded37..7ed378e80e1a0a209116ea8b73f8192a1ef5 100644
--- a/ipalib/backend.py
+++ b/ipalib/backend.py
@@ -110,7 +110,7 @@ class Executioner(Backend):
 self.Backend.ldap2.connect(ccache=ccache)
 else:
 self.Backend.xmlclient.connect(verbose=(self.env.verbose >= 2),
-fallback=self.env.fallback)
+fallback=self.env.fallback, delegate=self.env.delegate)
 if client_ip is not None:
 setattr(context, "client_ip", client_ip)
 
diff --git a/ipalib/constants.py b/ipalib/constants.py
index 96cf3ba604d0a53e687a76d01ab0b9b7b3e185fb..c6b3b63ffcb0bee8b21997a32e9e86e76b5576fe 100644
--- a/ipalib/constants.py
+++ b/ipalib/constants.py
@@ -133,6 +133,7 @@ DEFAULT_CONFIG = (
 ('prompt_all', False),
 ('interactive', True),
 ('fallback', True),
+('delegate', False),
 
 # Enable certain optional plugins:
 ('enable_ra', False),
diff --git a/ipalib/plugable.py b/ipalib/plugable.py
index e0b6e7f968ca16c3fed4667ba1d972edf5262546..4d0011029573df44d8d5e85e0e2b2a3f872c0703 100644
--- a/ipalib/plugable.py
+++ b/ipalib/plugable.py
@@ -530,6 +530,9 @@ class API(DictProxy):
 parser.add_option('-d', '--debug', action='store_true',
 help='Produce full debuging output',
 )
+parser.add_option('--delegate', action='store_true',
+help='Delegate the TGT to the IPA server',
+)
 parser.add_option('-v', '--verbose', action='count',
 help='Produce more verbose output. A second -v displays the XML-RPC request',
 )
@@ -570,7 +573,7 @@ class API(DictProxy):
 pass
 overrides[str(key.strip())] = value.strip()
 for key in ('conf', 'debug', 'verbose', 'prompt_all', 'interactive',
-'fallback'):
+'fallback', 'delegate'):
 value = getattr(options, key, None)
 if value is not None:
 overrides[key] = value
diff --git a/ipalib/rpc.py b/ipalib/rpc.py
index 8ec3a2f2706f6a18216ea8cfc74bc50b21159d31..4670283c99118e9804e13599337c3fe000c17617 100644
--- a/ipalib/rpc.py
+++ b/ipalib/rpc.py
@@ -234,6 +234,7 @@ class KerbTransport(SSLTransport):
 """
 Handles Kerberos Negotiation authentication to an XML-RPC server.
 """
+flags = kerberos.GSS_C_MUTUAL_FLAG | kerberos.GSS_C_SEQUENCE_FLAG
 
 def _handle_exception(self, e, service=None):
 (major, minor) = ipautil.get_gsserror(e)
@@ -259,10 +260,7 @@ class KerbTransport(SSLTransport):
 service = "HTTP@" + host.split(':')[0]
 
 try:
-(rc, vc) = kerberos.authGSSClientInit(service,
-kerberos.GSS_C_DELEG_FLAG |
-kerberos.GSS_C_MUTUAL_FLAG |
-kerberos.GSS_C_SEQUENCE_FLAG)
+(rc, vc) = kerberos.authGSSClientInit(service, self.flags)
 except kerberos.GSSError, e:
  

Re: [Freeipa-devel] WIP: ipa trust command

[Dmitri Pal]

On 12/14/2011 10:58 AM, Simo Sorce wrote:
> - Original Message -
> We can also generate the SID algorithmically from the
> uidNumber/gidNumber
 Do you mean the SID of the trusted domain user?
>>> No I meant the SID of users and groups.
>> ok, I would very much favor this approach it will make things much
>> easier. But iirc the idea was rejected some time ago, because we
>> couldn't agree on a good algorithm which can remove the conflicts
>> when
>> uid and gid are the same. What would you suggest? Adding the highest
>> bit
>> for groups? uid*2 for users, (gid*2)+1 for groups? ... ?
> Good question.
>
> So we need to decide whether we want algorithmic mapping or not (or a hybrid).
>
> Advantages of fixed NT SIDs:
> - Full control of users and group SIDs, you can simply remove a SID to make 
> the user or the group unavailable wrt Windows compatibility (reduce PAC size 
> and so on)
> - Do not change if the admin needs to change uidNumber or gidNumber for 
> whatever reason.
> - Easy to search by SID, does not require guessing what the corresponding 
> uid/gid are.
> - SIDs can be applied also to non-user/group objects w/o having to waste a 
> uidNumber
> - No risk of conflicts if admins decide not to use UPGs and have unrelated 
> groups and user that happen to algorithmically end up with the same SID (or 
> force us to waste space to assure all groups have even RIDs and users odd 
> RIDs)
>
> Disadvantages of fixed NT SIDs:
> - Requires DNA plugin to assign values since first install
> - Requires manual assignment, or fixup task if feature is activated after a 
> consistent number of users/groups have been created.
> - third parties that have to do SID -> UID mapping on their own (think a 
> samba server joined to the AD side and that has no knowledge these SIDs 
> belong to an IPA domain) may get different SID -> UID mappings.
>
>
> I think the points above suggest we should indeed stick with the original 
> decision of storing the SID and not go algorithmic (although the last point 
> may be slightly annoying, it could be easily solved by forcing mappings on 
> the other side or giving them read access to the IPA LDAP server for mapping 
> purposes).
>
> The main issue is that we cannot assume DNA is configured from first install 
> because an upgrade from v2 to v3 will simply go against it.
> But a fixup task to handle the situation shouldn't be too bad.
> The hardest problem will be to insure all servers that create users/groups 
> have the DNA plugin properly configured. And a secondary, very minor, 
> annoyance is that we will have to assign a range for SIDs as well.
> But this is not too hard we should probably just always assign a 200k IDs 
> starting from 2000 or so. We do not need a random range because SIDs are 
> unique across domains so we do not need to fear any collisions on trust 
> relationships. So this part is easy. We limit initially to 1 Million only to 
> keep RIDs in a very low range, so that mapping SIDs to UID/GID numbers for 
> 3rd parties is not going to be problematic.
> If we assigne a larger range like 2Billion the as soon as you install a 
> replica and create users there the range will be split in 2 and users create 
> from that other replica will have their RID starting at 1Billion (as the 
> range is split in 2 between the 2 replicas) which will make life difficult if 
> someone want to limit SID ranges for posix mapping purposes.
>
> Simo.
>
With the static IDs you will have an issue with DNA that you will have
to implement 2 dimensional slicing if ranges. Right now the ranges are
sliced per replica and traded accordingly. With your proposal the DNA
would have to deal with a concept of group of ranges belonging to each
domain and make sure that every replica has its slice for the group. I
seems that it would require changes to the DNA plugin logic, not only
configuration.
Also the point about third parties IMO is just a showstopper. If we go
with static IDs nobody would deploy us as we are nonexistent in real
deployments while samba and other solutions are already deployed in
multiple places. Poeple will be very frustrated to find out that our ids
do not match.

Man ye we should do our own samba id mapping back end that would work
like idmap_rid but factor in configured range and contribute it to samba.

But the problem of the collisions already exists  with samba when
multiple domains are in play so I really do not understand why we should
try to solve the problem that is pretty much unsolvable.


> ___
> Freeipa-devel mailing list
> Freeipa-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel
>
>


-- 
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

Re: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API

[Dmitri Pal]

On 12/14/2011 01:43 PM, Endi Sukma Dewata wrote:
> On 12/14/2011 12:53 AM, Martin Kosek wrote:
>>> I found this works ok and adding records is definitely clearer but it
>>> seems odd to add with one command and delete/find with another. I could
>>> get used to it I suppose.
>>
>> Hm, we could add dnsrecord--del ZONE RECORD VALUE command, but this
>> would increase the already high number of DNS commands.
>
> As suggested in the meeting, instead of having a separate command for
> each type:
>
>   dnsrecordsrv-add ZONE NAME [srv-specific parameters...]
>   dnsrecordmx-add ZONE NAME [mx-specific parameters...]
>
> we could use the same command but we specify the type as a parameter:
>
>   dnsrecord-add ZONE NAME --rec-type=srv [srv-specific parameters...]
>   dnsrecord-add ZONE NAME --rec-type=mx [mx-specific parameters...]
>
> This will keep the number of commands low regardless of the number of
> rrtypes we support now or in the future. Same thing for mod and del.
>
> All type-specific options can be made optional, or we can require some
> options depending on the type specified. The doc needs to specify
> which options are needed for each type.
>
> The interactive mode should still work too based on the type
> specified. If the user doesn't specify a type the command can even ask
> for it.
>
>> Endi and Petr had an idea to add a new --structured option for
>> dnsrecord-find/dnsrecord-show which would show structured DNS records
>> instead of raw DNS records. But I think our current framework is not
>> ready for this. While a raw DNS record is basically one entry item
>> (label : value), structured DNS record is an entry on its own
>> ({label1:value1, label2:value2, ...}):
>>   - dnsrecord-find's output is ListOfEntries, but with use of
>> --structured option it would have to be changed to something like
>> ListOfListsOfEntries
>>   - dnsrecord-show's output would have to be changed with a use of
>> --structured option from Entry to ListOfEntries
>
> I think we're mixing up several alternatives in the discussion. Never
> mind about dnsrecord-find/show returning record data in
> separate entries. I don't think right now it will be a good idea since
> they are actually attributes (no filter for certain param in the type,
> no primary key).
>
> What we're suggesting is the find command should always return a
> ListOfEntries and the show command should always return an Entry,
> which will be consistent with other commands. So when you call
> dnsrecord-show ZONE NAME without --structured, it will return a single
> Entry like before:
>
> {
> idnsname: 'foo',
> arecord: [
> '10.10.10.10'
> ],
> cnamerecord: [
> 'bar.example.com.',
> 'bar2.example.com.'
> ]
> }
>
> But when you specify --structured, it still returns a single Entry
> 'foo' but the structure of the attributes will change like this (or
> like the one suggested by Petr):
>
> {
> idnsname: 'foo',
> records: [
> {
> type: 'a',
> data: '10.10.10.10',
> ip_address: '10.10.10.10'
> },
> {
> type: 'cname',
> data: 'bar.example.com.',
> hostname: 'bar.example.com.'
> },
> {
> type: 'cname',
> data: 'bar2.example.com.',
> hostname: 'bar2.example.com.'
> },
> ]
> }
>
> If you call dnsrecord-find ZONE --structured the output will be a
> ListOfEntries like before, but each Entry will have a structure like
> above.
>
>> Another problem I see is that different RR types have parts with the
>> same name (e.g. "preference" is both in MX, KX and NAPTR records). If
>> any record could appear in an output entry, we would break current rule
>> that every output parameter in an entry is uniquely defined. Though this
>> issue could be solved with a prefix for every structured DNS record
>> part, i.e. KX record would have "kxpreference" and "kxechanger" parts.
>
> Since the 'records' attribute is an array in an Entry, there shouldn't
> be any issue about uniqueness.
>
> Also as suggested in my previous email, we can also add a --rec-types
> parameter to the find/show command to select which rrtypes we want to
> see in the result. If not specified it should return all types.
>
But as Martin mentioned on the call we loose help capabilities and make
things really more complex.
My vote would be to have separate commands. IMO it is better from
usability point of view.

-- 
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

Re: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API

[Endi Sukma Dewata]

On 12/14/2011 12:53 AM, Martin Kosek wrote:

I found this works ok and adding records is definitely clearer but it
seems odd to add with one command and delete/find with another. I could
get used to it I suppose.


Hm, we could add dnsrecord--del ZONE RECORD VALUE command, but this
would increase the already high number of DNS commands.


As suggested in the meeting, instead of having a separate command for 
each type:


  dnsrecordsrv-add ZONE NAME [srv-specific parameters...]
  dnsrecordmx-add ZONE NAME [mx-specific parameters...]

we could use the same command but we specify the type as a parameter:

  dnsrecord-add ZONE NAME --rec-type=srv [srv-specific parameters...]
  dnsrecord-add ZONE NAME --rec-type=mx [mx-specific parameters...]

This will keep the number of commands low regardless of the number of 
rrtypes we support now or in the future. Same thing for mod and del.


All type-specific options can be made optional, or we can require some 
options depending on the type specified. The doc needs to specify which 
options are needed for each type.


The interactive mode should still work too based on the type specified. 
If the user doesn't specify a type the command can even ask for it.



Endi and Petr had an idea to add a new --structured option for
dnsrecord-find/dnsrecord-show which would show structured DNS records
instead of raw DNS records. But I think our current framework is not
ready for this. While a raw DNS record is basically one entry item
(label : value), structured DNS record is an entry on its own
({label1:value1, label2:value2, ...}):
  - dnsrecord-find's output is ListOfEntries, but with use of
--structured option it would have to be changed to something like
ListOfListsOfEntries
  - dnsrecord-show's output would have to be changed with a use of
--structured option from Entry to ListOfEntries


I think we're mixing up several alternatives in the discussion. Never 
mind about dnsrecord-find/show returning record data in separate 
entries. I don't think right now it will be a good idea since they are 
actually attributes (no filter for certain param in the type, no primary 
key).


What we're suggesting is the find command should always return a 
ListOfEntries and the show command should always return an Entry, which 
will be consistent with other commands. So when you call dnsrecord-show 
ZONE NAME without --structured, it will return a single Entry like before:


{
idnsname: 'foo',
arecord: [
'10.10.10.10'
],
cnamerecord: [
'bar.example.com.',
'bar2.example.com.'
]
}

But when you specify --structured, it still returns a single Entry 'foo' 
but the structure of the attributes will change like this (or like the 
one suggested by Petr):


{
idnsname: 'foo',
records: [
{
type: 'a',
data: '10.10.10.10',
ip_address: '10.10.10.10'
},
{
type: 'cname',
data: 'bar.example.com.',
hostname: 'bar.example.com.'
},
{
type: 'cname',
data: 'bar2.example.com.',
hostname: 'bar2.example.com.'
},
]
}

If you call dnsrecord-find ZONE --structured the output will be a 
ListOfEntries like before, but each Entry will have a structure like above.



Another problem I see is that different RR types have parts with the
same name (e.g. "preference" is both in MX, KX and NAPTR records). If
any record could appear in an output entry, we would break current rule
that every output parameter in an entry is uniquely defined. Though this
issue could be solved with a prefix for every structured DNS record
part, i.e. KX record would have "kxpreference" and "kxechanger" parts.


Since the 'records' attribute is an array in an Entry, there shouldn't 
be any issue about uniqueness.


Also as suggested in my previous email, we can also add a --rec-types 
parameter to the find/show command to select which rrtypes we want to 
see in the result. If not specified it should return all types.


--
Endi S. Dewata

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] WIP: ipa trust command

[Simo Sorce]

- Original Message -
> > > > We can also generate the SID algorithmically from the
> > > > uidNumber/gidNumber
> > > 
> > > Do you mean the SID of the trusted domain user?
> > 
> > No I meant the SID of users and groups.
> 
> ok, I would very much favor this approach it will make things much
> easier. But iirc the idea was rejected some time ago, because we
> couldn't agree on a good algorithm which can remove the conflicts
> when
> uid and gid are the same. What would you suggest? Adding the highest
> bit
> for groups? uid*2 for users, (gid*2)+1 for groups? ... ?

Good question.

So we need to decide whether we want algorithmic mapping or not (or a hybrid).

Advantages of fixed NT SIDs:
- Full control of users and group SIDs, you can simply remove a SID to make the 
user or the group unavailable wrt Windows compatibility (reduce PAC size and so 
on)
- Do not change if the admin needs to change uidNumber or gidNumber for 
whatever reason.
- Easy to search by SID, does not require guessing what the corresponding 
uid/gid are.
- SIDs can be applied also to non-user/group objects w/o having to waste a 
uidNumber
- No risk of conflicts if admins decide not to use UPGs and have unrelated 
groups and user that happen to algorithmically end up with the same SID (or 
force us to waste space to assure all groups have even RIDs and users odd RIDs)

Disadvantages of fixed NT SIDs:
- Requires DNA plugin to assign values since first install
- Requires manual assignment, or fixup task if feature is activated after a 
consistent number of users/groups have been created.
- third parties that have to do SID -> UID mapping on their own (think a samba 
server joined to the AD side and that has no knowledge these SIDs belong to an 
IPA domain) may get different SID -> UID mappings.


I think the points above suggest we should indeed stick with the original 
decision of storing the SID and not go algorithmic (although the last point may 
be slightly annoying, it could be easily solved by forcing mappings on the 
other side or giving them read access to the IPA LDAP server for mapping 
purposes).

The main issue is that we cannot assume DNA is configured from first install 
because an upgrade from v2 to v3 will simply go against it.
But a fixup task to handle the situation shouldn't be too bad.
The hardest problem will be to insure all servers that create users/groups have 
the DNA plugin properly configured. And a secondary, very minor, annoyance is 
that we will have to assign a range for SIDs as well.
But this is not too hard we should probably just always assign a 200k IDs 
starting from 2000 or so. We do not need a random range because SIDs are unique 
across domains so we do not need to fear any collisions on trust relationships. 
So this part is easy. We limit initially to 1 Million only to keep RIDs in a 
very low range, so that mapping SIDs to UID/GID numbers for 3rd parties is not 
going to be problematic.
If we assigne a larger range like 2Billion the as soon as you install a replica 
and create users there the range will be split in 2 and users create from that 
other replica will have their RID starting at 1Billion (as the range is split 
in 2 between the 2 replicas) which will make life difficult if someone want to 
limit SID ranges for posix mapping purposes.

Simo.

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 056 Added facet tabs coloring

[Endi Sukma Dewata]

On 12/13/2011 3:49 AM, Petr Vobornik wrote:

1. The original code uses different background images for
active/inactive tabs. I think the mockup in the ticket is also showing
different backgrounds. The new code uses the same background.


Fixed, using the background from mockup - but honestly I don't see much
difference.


The inactive tabs are slightly lighter and have graduated color. The 
difference is very small, but the important thing is the ability to show 
different backgrounds for different tab states.


ACK and pushed to master.

--
Endi S. Dewata

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 918, 919 update sudo schema

[Rob Crittenden]

Jan Cholasta wrote:

Dne 14.12.2011 15:23, Rob Crittenden napsal(a):

Jan Cholasta wrote:

Dne 14.12.2011 05:20, Rob Crittenden napsal(a):

The sudo schema now defines sudoOrder, sudoNotBefore and sudoNotAfter
but these weren't available in the sudorule plugin.

I've added support for these. sudoOrder enforces uniqueness because
duplicates are undefined.

I also added support for a GeneralizedTime parameter type. This is
similar to the existing AccessTime parameter but it only handles a
single time value.


You should parse the date/time part of the value with
time.strptime(timestr, '%Y%m%d%H%M%S') instead of doing it manually,
that way you'll get most of the validation for free.


Yes but it gives a crappy error message, just saying that some data is
left over not what is wrong.


IMHO having a separate error message for every field in the time string
(like you do in the patch) is an overkill, simple "invalid time" and/or
"unknown time format" should suffice (we don't have errors like "invalid
3rd octet" for IP adresses either).


Well, the work is done, hard to go back on a better error message.




Also, it would be nice to be able to enter the value in more
user-friendly format (e.g. "2011-12-14 13:01:25 +0100") and normalize
that to LDAP generalized time.


When dealing with time there are so many ways to input and display the
same values this becomes difficult.

I'd expect that the times for these two attributes will be relatively
simple and I somehow doubt users are going to want seconds, leap seconds
or fractions, but we'll need to consider how to do it for future
consistency (otherwise we could have a case where time is entered in one
format for some attributes and another for others).

If we input in a nice way we need to output in the same way.


We could make the preferred input/output time format user-configurable,
defaulting to current locale time format. This format would be used for
output. For input, we could go over a list of formats (first the
user-configured format, then current locale format, then a handful of
"standard" formats like -MM-DD HH:MM:SS) and use the first format
that can be successfully used to parse the time string.


See how far you get into the rabbit hole with even this simple format?

The LDAP GeneralizedTime needs to be either in GMT or include a 
differential. This gets us into the territory where the client could be 
in a different timezone than the server which leads us to why we dropped 
AccessTime in the first place. So I'd like the user to supply the 
timezone themselves so I don't have to guess (wrongly) and let them 
worry about differing timezones.


rob

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 918, 919 update sudo schema

[Jan Cholasta]

Dne 14.12.2011 15:23, Rob Crittenden napsal(a):

Jan Cholasta wrote:

Dne 14.12.2011 05:20, Rob Crittenden napsal(a):

The sudo schema now defines sudoOrder, sudoNotBefore and sudoNotAfter
but these weren't available in the sudorule plugin.

I've added support for these. sudoOrder enforces uniqueness because
duplicates are undefined.

I also added support for a GeneralizedTime parameter type. This is
similar to the existing AccessTime parameter but it only handles a
single time value.


You should parse the date/time part of the value with
time.strptime(timestr, '%Y%m%d%H%M%S') instead of doing it manually,
that way you'll get most of the validation for free.


Yes but it gives a crappy error message, just saying that some data is
left over not what is wrong.


IMHO having a separate error message for every field in the time string 
(like you do in the patch) is an overkill, simple "invalid time" and/or 
"unknown time format" should suffice (we don't have errors like "invalid 
3rd octet" for IP adresses either).





Also, it would be nice to be able to enter the value in more
user-friendly format (e.g. "2011-12-14 13:01:25 +0100") and normalize
that to LDAP generalized time.


When dealing with time there are so many ways to input and display the
same values this becomes difficult.

I'd expect that the times for these two attributes will be relatively
simple and I somehow doubt users are going to want seconds, leap seconds
or fractions, but we'll need to consider how to do it for future
consistency (otherwise we could have a case where time is entered in one
format for some attributes and another for others).

If we input in a nice way we need to output in the same way.


We could make the preferred input/output time format user-configurable, 
defaulting to current locale time format. This format would be used for 
output. For input, we could go over a list of formats (first the 
user-configured format, then current locale format, then a handful of 
"standard" formats like -MM-DD HH:MM:SS) and use the first format 
that can be successfully used to parse the time string.




rob


Honza

--
Jan Cholasta

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] WIP: ipa trust command

[Sumit Bose]

On Wed, Dec 14, 2011 at 08:31:57AM -0500, Simo Sorce wrote:
> On Wed, 2011-12-14 at 14:12 +0100, Sumit Bose wrote:
> > On Wed, Dec 14, 2011 at 07:45:53AM -0500, Simo Sorce wrote:
> > > On Wed, 2011-12-14 at 10:23 +0100, Sumit Bose wrote:
> > > > On Tue, Dec 13, 2011 at 07:08:24PM +0200, Alexander Bokovoy wrote:
> > > > > On Tue, 13 Dec 2011, Simo Sorce wrote:
> > > > > > On Mon, 2011-12-12 at 22:27 +0200, Alexander Bokovoy wrote:
> > > > > > > On Mon, 12 Dec 2011, Sumit Bose wrote:
> > > > > > > > > --password  [type-specific parameters]
> > > > > > > > > 
> > > > > > > > > Creates a trust between FreeIPA realm and another realm of 
> > > > > > > > > selected 
> > > > > > > > > type. Only 'ads' type is currently supported.
> > > > > > > > > 
> > > > > > > > > For 'ads' type running `ipa trust-add' would be equivalent to 
> > > > > > > > > following sequence:
> > > > > > > > >  * ipa-adtrust-install
> > > > > > > > >  * net rpc trust create
> > > > > > > > 
> > > > > > > > As Simo already mentioned theses should be two separate step 
> > > > > > > > and `ipa
> > > > > > > > trust-add' should just check is the needed components to create 
> > > > > > > > AD
> > > > > > > > trusts are already installed on the IPA server.
> > > > > > > See my answer to Simo, I think we can substantially improve this 
> > > > > > > situation.
> > > > > > > 
> > > > > > > > Additionally I think we need some commands to define a UID 
> > > > > > > > range for the
> > > > > > > > trusted domains, especially for AD trusts. For the domain given 
> > > > > > > > with the
> > > > > > > > `ipa trust-add' command we could just use another command line 
> > > > > > > > option.
> > > > > > > > But if this domain already has trusts to other domains it will 
> > > > > > > > become
> > > > > > > > difficult to handle this with options to `ipa trust-add'. So I 
> > > > > > > > would
> > > > > > > > suggest to add a new command to the `ipa trust' family which 
> > > > > > > > can set UID
> > > > > > > > ranges for domains before the trust is created. If the trust is 
> > > > > > > > already
> > > > > > > > created we may still allow to change the range but with a 
> > > > > > > > strong warning
> > > > > > > > that existing UIDs and GIDs will change.
> > > > > > > Ok, this would qualify for ipa trust-add options for UID/GID 
> > > > > > > ranges 
> > > > > > > and would also warrant addition of ipa trust-mod that Rob has 
> > > > > > > proposed.
> > > > > > > 
> > > > > > > What else except UID/GID ranges could be modified?
> > > > > > 
> > > > > > 
> > > > > > Ok we had a discussion this morning about how to handle this.
> > > > > > 
> > > > > > We decided to do a few things to simplify installing and managing 
> > > > > > the
> > > > > > problem when multiple replicas are involved.
> > > > > > 
> > > > > > 1. We will fold back as much as possible into ipa-server-install 
> > > > > > (and
> > > > > > update scripts for 2 -> 3 updates), in particular we will move 
> > > > > > generic
> > > > > > ACI creation (including additional ACI for a new group called Trusts
> > > > > > Admins), and the creation of a system user called adtrust and 
> > > > > > associated
> > > > > > DS user under uid=adtrust,cn=sysaccount,cn=etc,
> > > > > > 
> > > > > > 2. We will preconfigure DS so that SASL/EXTERNAL authentication with
> > > > > > that user results in using the uid=adtrust DN that will have also
> > > > > > pre-assigned ACIs
> > > > > > 
> > > > > > 3. We will change samba's ipasm to use the adtrust user and
> > > > > > SASL/EXTERNAL auth to access DS in order to have privilege 
> > > > > > separation.
> > > > > > This means smbd keeps operating as a restricted user but will not 
> > > > > > need a
> > > > > > password to be set via smbpasswd -e
> > > > > > 
> > > > > > 4. We change ipa-adtrust-install to ipa-adtrust-enable, this script 
> > > > > > will
> > > > > > verify the necessary trust objects are in place and enables 
> > > > > > starting the
> > > > > > adtrust service (smbd daemon, cldap plugin, ...) It also adds the 
> > > > > > server
> > > > > > to the _msdcs DNS hive.
> > > > > > 
> > > > > > 5. Each ipa server admins need to use as a bridge to/from AD will 
> > > > > > need
> > > > > > to be 'activated' by running ipa-adtrust-enable once for now. We can
> > > > > > also consider automatically running it by passing a --enable-adtrust
> > > > > > parameter to ipa-replica-install
> > > > > > 
> > > > > > 6. We change ipa-replica-manage to make sure _msdcs records are also
> > > > > > deleted when a replica is removed.
> > > > > > 
> > > > > > 
> > > > > > This should be all, please send corrections if I forgot something.
> > > > > 'ipa trust' family of commands will be used to manage trust 
> > > > > information after configuration -- listing existing trusts, removing 
> > > > > and modifying them.
> > > > > 
> > > > > In addition, 'ipa trust-add' will do similar ground work 
> > > > > when configuring AD trusts on the master -- it will ens

Re: [Freeipa-devel] [PATCH] 918, 919 update sudo schema

[Rob Crittenden]

Jan Cholasta wrote:

Dne 14.12.2011 05:20, Rob Crittenden napsal(a):

The sudo schema now defines sudoOrder, sudoNotBefore and sudoNotAfter
but these weren't available in the sudorule plugin.

I've added support for these. sudoOrder enforces uniqueness because
duplicates are undefined.

I also added support for a GeneralizedTime parameter type. This is
similar to the existing AccessTime parameter but it only handles a
single time value.


You should parse the date/time part of the value with
time.strptime(timestr, '%Y%m%d%H%M%S') instead of doing it manually,
that way you'll get most of the validation for free.


Yes but it gives a crappy error message, just saying that some data is 
left over not what is wrong.



Also, it would be nice to be able to enter the value in more
user-friendly format (e.g. "2011-12-14 13:01:25 +0100") and normalize
that to LDAP generalized time.


When dealing with time there are so many ways to input and display the 
same values this becomes difficult.


I'd expect that the times for these two attributes will be relatively 
simple and I somehow doubt users are going to want seconds, leap seconds 
or fractions, but we'll need to consider how to do it for future 
consistency (otherwise we could have a case where time is entered in one 
format for some attributes and another for others).


If we input in a nice way we need to output in the same way.

rob

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] WIP: ipa trust command

[Simo Sorce]

On Wed, 2011-12-14 at 14:12 +0100, Sumit Bose wrote:
> On Wed, Dec 14, 2011 at 07:45:53AM -0500, Simo Sorce wrote:
> > On Wed, 2011-12-14 at 10:23 +0100, Sumit Bose wrote:
> > > On Tue, Dec 13, 2011 at 07:08:24PM +0200, Alexander Bokovoy wrote:
> > > > On Tue, 13 Dec 2011, Simo Sorce wrote:
> > > > > On Mon, 2011-12-12 at 22:27 +0200, Alexander Bokovoy wrote:
> > > > > > On Mon, 12 Dec 2011, Sumit Bose wrote:
> > > > > > > > --password  [type-specific parameters]
> > > > > > > > 
> > > > > > > > Creates a trust between FreeIPA realm and another realm of 
> > > > > > > > selected 
> > > > > > > > type. Only 'ads' type is currently supported.
> > > > > > > > 
> > > > > > > > For 'ads' type running `ipa trust-add' would be equivalent to 
> > > > > > > > following sequence:
> > > > > > > >  * ipa-adtrust-install
> > > > > > > >  * net rpc trust create
> > > > > > > 
> > > > > > > As Simo already mentioned theses should be two separate step and 
> > > > > > > `ipa
> > > > > > > trust-add' should just check is the needed components to create AD
> > > > > > > trusts are already installed on the IPA server.
> > > > > > See my answer to Simo, I think we can substantially improve this 
> > > > > > situation.
> > > > > > 
> > > > > > > Additionally I think we need some commands to define a UID range 
> > > > > > > for the
> > > > > > > trusted domains, especially for AD trusts. For the domain given 
> > > > > > > with the
> > > > > > > `ipa trust-add' command we could just use another command line 
> > > > > > > option.
> > > > > > > But if this domain already has trusts to other domains it will 
> > > > > > > become
> > > > > > > difficult to handle this with options to `ipa trust-add'. So I 
> > > > > > > would
> > > > > > > suggest to add a new command to the `ipa trust' family which can 
> > > > > > > set UID
> > > > > > > ranges for domains before the trust is created. If the trust is 
> > > > > > > already
> > > > > > > created we may still allow to change the range but with a strong 
> > > > > > > warning
> > > > > > > that existing UIDs and GIDs will change.
> > > > > > Ok, this would qualify for ipa trust-add options for UID/GID ranges 
> > > > > > and would also warrant addition of ipa trust-mod that Rob has 
> > > > > > proposed.
> > > > > > 
> > > > > > What else except UID/GID ranges could be modified?
> > > > > 
> > > > > 
> > > > > Ok we had a discussion this morning about how to handle this.
> > > > > 
> > > > > We decided to do a few things to simplify installing and managing the
> > > > > problem when multiple replicas are involved.
> > > > > 
> > > > > 1. We will fold back as much as possible into ipa-server-install (and
> > > > > update scripts for 2 -> 3 updates), in particular we will move generic
> > > > > ACI creation (including additional ACI for a new group called Trusts
> > > > > Admins), and the creation of a system user called adtrust and 
> > > > > associated
> > > > > DS user under uid=adtrust,cn=sysaccount,cn=etc,
> > > > > 
> > > > > 2. We will preconfigure DS so that SASL/EXTERNAL authentication with
> > > > > that user results in using the uid=adtrust DN that will have also
> > > > > pre-assigned ACIs
> > > > > 
> > > > > 3. We will change samba's ipasm to use the adtrust user and
> > > > > SASL/EXTERNAL auth to access DS in order to have privilege separation.
> > > > > This means smbd keeps operating as a restricted user but will not 
> > > > > need a
> > > > > password to be set via smbpasswd -e
> > > > > 
> > > > > 4. We change ipa-adtrust-install to ipa-adtrust-enable, this script 
> > > > > will
> > > > > verify the necessary trust objects are in place and enables starting 
> > > > > the
> > > > > adtrust service (smbd daemon, cldap plugin, ...) It also adds the 
> > > > > server
> > > > > to the _msdcs DNS hive.
> > > > > 
> > > > > 5. Each ipa server admins need to use as a bridge to/from AD will need
> > > > > to be 'activated' by running ipa-adtrust-enable once for now. We can
> > > > > also consider automatically running it by passing a --enable-adtrust
> > > > > parameter to ipa-replica-install
> > > > > 
> > > > > 6. We change ipa-replica-manage to make sure _msdcs records are also
> > > > > deleted when a replica is removed.
> > > > > 
> > > > > 
> > > > > This should be all, please send corrections if I forgot something.
> > > > 'ipa trust' family of commands will be used to manage trust 
> > > > information after configuration -- listing existing trusts, removing 
> > > > and modifying them.
> > > > 
> > > > In addition, 'ipa trust-add' will do similar ground work 
> > > > when configuring AD trusts on the master -- it will ensure all needed 
> > > > records are in LDAP (or will create them) and will ask admin to use 
> > > > ipa-adtrust-enable to actually activate the trust. All this is due to 
> > > > the fact that we need to start/restart services with root privileges.
> > > > 
> > > > This way we can have a common CLI that will stay the same for all 
> > > > futur

Re: [Freeipa-devel] WIP: ipa trust command

[Sumit Bose]

On Wed, Dec 14, 2011 at 07:45:53AM -0500, Simo Sorce wrote:
> On Wed, 2011-12-14 at 10:23 +0100, Sumit Bose wrote:
> > On Tue, Dec 13, 2011 at 07:08:24PM +0200, Alexander Bokovoy wrote:
> > > On Tue, 13 Dec 2011, Simo Sorce wrote:
> > > > On Mon, 2011-12-12 at 22:27 +0200, Alexander Bokovoy wrote:
> > > > > On Mon, 12 Dec 2011, Sumit Bose wrote:
> > > > > > > --password  [type-specific parameters]
> > > > > > > 
> > > > > > > Creates a trust between FreeIPA realm and another realm of 
> > > > > > > selected 
> > > > > > > type. Only 'ads' type is currently supported.
> > > > > > > 
> > > > > > > For 'ads' type running `ipa trust-add' would be equivalent to 
> > > > > > > following sequence:
> > > > > > >  * ipa-adtrust-install
> > > > > > >  * net rpc trust create
> > > > > > 
> > > > > > As Simo already mentioned theses should be two separate step and 
> > > > > > `ipa
> > > > > > trust-add' should just check is the needed components to create AD
> > > > > > trusts are already installed on the IPA server.
> > > > > See my answer to Simo, I think we can substantially improve this 
> > > > > situation.
> > > > > 
> > > > > > Additionally I think we need some commands to define a UID range 
> > > > > > for the
> > > > > > trusted domains, especially for AD trusts. For the domain given 
> > > > > > with the
> > > > > > `ipa trust-add' command we could just use another command line 
> > > > > > option.
> > > > > > But if this domain already has trusts to other domains it will 
> > > > > > become
> > > > > > difficult to handle this with options to `ipa trust-add'. So I would
> > > > > > suggest to add a new command to the `ipa trust' family which can 
> > > > > > set UID
> > > > > > ranges for domains before the trust is created. If the trust is 
> > > > > > already
> > > > > > created we may still allow to change the range but with a strong 
> > > > > > warning
> > > > > > that existing UIDs and GIDs will change.
> > > > > Ok, this would qualify for ipa trust-add options for UID/GID ranges 
> > > > > and would also warrant addition of ipa trust-mod that Rob has 
> > > > > proposed.
> > > > > 
> > > > > What else except UID/GID ranges could be modified?
> > > > 
> > > > 
> > > > Ok we had a discussion this morning about how to handle this.
> > > > 
> > > > We decided to do a few things to simplify installing and managing the
> > > > problem when multiple replicas are involved.
> > > > 
> > > > 1. We will fold back as much as possible into ipa-server-install (and
> > > > update scripts for 2 -> 3 updates), in particular we will move generic
> > > > ACI creation (including additional ACI for a new group called Trusts
> > > > Admins), and the creation of a system user called adtrust and associated
> > > > DS user under uid=adtrust,cn=sysaccount,cn=etc,
> > > > 
> > > > 2. We will preconfigure DS so that SASL/EXTERNAL authentication with
> > > > that user results in using the uid=adtrust DN that will have also
> > > > pre-assigned ACIs
> > > > 
> > > > 3. We will change samba's ipasm to use the adtrust user and
> > > > SASL/EXTERNAL auth to access DS in order to have privilege separation.
> > > > This means smbd keeps operating as a restricted user but will not need a
> > > > password to be set via smbpasswd -e
> > > > 
> > > > 4. We change ipa-adtrust-install to ipa-adtrust-enable, this script will
> > > > verify the necessary trust objects are in place and enables starting the
> > > > adtrust service (smbd daemon, cldap plugin, ...) It also adds the server
> > > > to the _msdcs DNS hive.
> > > > 
> > > > 5. Each ipa server admins need to use as a bridge to/from AD will need
> > > > to be 'activated' by running ipa-adtrust-enable once for now. We can
> > > > also consider automatically running it by passing a --enable-adtrust
> > > > parameter to ipa-replica-install
> > > > 
> > > > 6. We change ipa-replica-manage to make sure _msdcs records are also
> > > > deleted when a replica is removed.
> > > > 
> > > > 
> > > > This should be all, please send corrections if I forgot something.
> > > 'ipa trust' family of commands will be used to manage trust 
> > > information after configuration -- listing existing trusts, removing 
> > > and modifying them.
> > > 
> > > In addition, 'ipa trust-add' will do similar ground work 
> > > when configuring AD trusts on the master -- it will ensure all needed 
> > > records are in LDAP (or will create them) and will ask admin to use 
> > > ipa-adtrust-enable to actually activate the trust. All this is due to 
> > > the fact that we need to start/restart services with root privileges.
> > > 
> > > This way we can have a common CLI that will stay the same for all 
> > > future trust variants and instruct admins how to activate actual trust 
> > > relationship once it is configured.
> > > 
> > > If we'll find solutions to automate activation process, we can then 
> > > replace the instructions with the actual calls to activation.
> > 
> > Simo, Alexander thank you for the summary.

Re: [Freeipa-devel] WIP: ipa trust command

[Simo Sorce]

On Wed, 2011-12-14 at 10:23 +0100, Sumit Bose wrote:
> On Tue, Dec 13, 2011 at 07:08:24PM +0200, Alexander Bokovoy wrote:
> > On Tue, 13 Dec 2011, Simo Sorce wrote:
> > > On Mon, 2011-12-12 at 22:27 +0200, Alexander Bokovoy wrote:
> > > > On Mon, 12 Dec 2011, Sumit Bose wrote:
> > > > > > --password  [type-specific parameters]
> > > > > > 
> > > > > > Creates a trust between FreeIPA realm and another realm of selected 
> > > > > > type. Only 'ads' type is currently supported.
> > > > > > 
> > > > > > For 'ads' type running `ipa trust-add' would be equivalent to 
> > > > > > following sequence:
> > > > > >  * ipa-adtrust-install
> > > > > >  * net rpc trust create
> > > > > 
> > > > > As Simo already mentioned theses should be two separate step and `ipa
> > > > > trust-add' should just check is the needed components to create AD
> > > > > trusts are already installed on the IPA server.
> > > > See my answer to Simo, I think we can substantially improve this 
> > > > situation.
> > > > 
> > > > > Additionally I think we need some commands to define a UID range for 
> > > > > the
> > > > > trusted domains, especially for AD trusts. For the domain given with 
> > > > > the
> > > > > `ipa trust-add' command we could just use another command line option.
> > > > > But if this domain already has trusts to other domains it will become
> > > > > difficult to handle this with options to `ipa trust-add'. So I would
> > > > > suggest to add a new command to the `ipa trust' family which can set 
> > > > > UID
> > > > > ranges for domains before the trust is created. If the trust is 
> > > > > already
> > > > > created we may still allow to change the range but with a strong 
> > > > > warning
> > > > > that existing UIDs and GIDs will change.
> > > > Ok, this would qualify for ipa trust-add options for UID/GID ranges 
> > > > and would also warrant addition of ipa trust-mod that Rob has proposed.
> > > > 
> > > > What else except UID/GID ranges could be modified?
> > > 
> > > 
> > > Ok we had a discussion this morning about how to handle this.
> > > 
> > > We decided to do a few things to simplify installing and managing the
> > > problem when multiple replicas are involved.
> > > 
> > > 1. We will fold back as much as possible into ipa-server-install (and
> > > update scripts for 2 -> 3 updates), in particular we will move generic
> > > ACI creation (including additional ACI for a new group called Trusts
> > > Admins), and the creation of a system user called adtrust and associated
> > > DS user under uid=adtrust,cn=sysaccount,cn=etc,
> > > 
> > > 2. We will preconfigure DS so that SASL/EXTERNAL authentication with
> > > that user results in using the uid=adtrust DN that will have also
> > > pre-assigned ACIs
> > > 
> > > 3. We will change samba's ipasm to use the adtrust user and
> > > SASL/EXTERNAL auth to access DS in order to have privilege separation.
> > > This means smbd keeps operating as a restricted user but will not need a
> > > password to be set via smbpasswd -e
> > > 
> > > 4. We change ipa-adtrust-install to ipa-adtrust-enable, this script will
> > > verify the necessary trust objects are in place and enables starting the
> > > adtrust service (smbd daemon, cldap plugin, ...) It also adds the server
> > > to the _msdcs DNS hive.
> > > 
> > > 5. Each ipa server admins need to use as a bridge to/from AD will need
> > > to be 'activated' by running ipa-adtrust-enable once for now. We can
> > > also consider automatically running it by passing a --enable-adtrust
> > > parameter to ipa-replica-install
> > > 
> > > 6. We change ipa-replica-manage to make sure _msdcs records are also
> > > deleted when a replica is removed.
> > > 
> > > 
> > > This should be all, please send corrections if I forgot something.
> > 'ipa trust' family of commands will be used to manage trust 
> > information after configuration -- listing existing trusts, removing 
> > and modifying them.
> > 
> > In addition, 'ipa trust-add' will do similar ground work 
> > when configuring AD trusts on the master -- it will ensure all needed 
> > records are in LDAP (or will create them) and will ask admin to use 
> > ipa-adtrust-enable to actually activate the trust. All this is due to 
> > the fact that we need to start/restart services with root privileges.
> > 
> > This way we can have a common CLI that will stay the same for all 
> > future trust variants and instruct admins how to activate actual trust 
> > relationship once it is configured.
> > 
> > If we'll find solutions to automate activation process, we can then 
> > replace the instructions with the actual calls to activation.
> 
> Simo, Alexander thank you for the summary.
> 
> I have an open ticket (#1614) which I planned to add to
> ipa-adtrust-install but which might be better solved elsewhere whit the
> current plans.
> 
> In ticket #1614 a DNS plugin configuration shall be created to add SIDs
> to IPA user which should be used in the trusted AD domain as well. We
> can create

Re: [Freeipa-devel] [PATCH] 918, 919 update sudo schema

[Jan Cholasta]

Dne 14.12.2011 05:20, Rob Crittenden napsal(a):

The sudo schema now defines sudoOrder, sudoNotBefore and sudoNotAfter
but these weren't available in the sudorule plugin.

I've added support for these. sudoOrder enforces uniqueness because
duplicates are undefined.

I also added support for a GeneralizedTime parameter type. This is
similar to the existing AccessTime parameter but it only handles a
single time value.


You should parse the date/time part of the value with 
time.strptime(timestr, '%Y%m%d%H%M%S') instead of doing it manually, 
that way you'll get most of the validation for free.


Also, it would be nice to be able to enter the value in more 
user-friendly format (e.g. "2011-12-14 13:01:25 +0100") and normalize 
that to LDAP generalized time.




The sudo patch relies on my patch 916 or you'll have merge issues.

rob



Honza

--
Jan Cholasta

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] WIP: ipa trust command

[Alexander Bokovoy]

On Wed, 14 Dec 2011, Sumit Bose wrote:

> On Tue, Dec 13, 2011 at 07:08:24PM +0200, Alexander Bokovoy wrote:
> > On Tue, 13 Dec 2011, Simo Sorce wrote:
> > > On Mon, 2011-12-12 at 22:27 +0200, Alexander Bokovoy wrote:
> > > > On Mon, 12 Dec 2011, Sumit Bose wrote:
> > > > > > --password  [type-specific parameters]
> > > > > > 
> > > > > > Creates a trust between FreeIPA realm and another realm of selected 
> > > > > > type. Only 'ads' type is currently supported.
> > > > > > 
> > > > > > For 'ads' type running `ipa trust-add' would be equivalent to 
> > > > > > following sequence:
> > > > > >  * ipa-adtrust-install
> > > > > >  * net rpc trust create
> > > > > 
> > > > > As Simo already mentioned theses should be two separate step and `ipa
> > > > > trust-add' should just check is the needed components to create AD
> > > > > trusts are already installed on the IPA server.
> > > > See my answer to Simo, I think we can substantially improve this 
> > > > situation.
> > > > 
> > > > > Additionally I think we need some commands to define a UID range for 
> > > > > the
> > > > > trusted domains, especially for AD trusts. For the domain given with 
> > > > > the
> > > > > `ipa trust-add' command we could just use another command line option.
> > > > > But if this domain already has trusts to other domains it will become
> > > > > difficult to handle this with options to `ipa trust-add'. So I would
> > > > > suggest to add a new command to the `ipa trust' family which can set 
> > > > > UID
> > > > > ranges for domains before the trust is created. If the trust is 
> > > > > already
> > > > > created we may still allow to change the range but with a strong 
> > > > > warning
> > > > > that existing UIDs and GIDs will change.
> > > > Ok, this would qualify for ipa trust-add options for UID/GID ranges 
> > > > and would also warrant addition of ipa trust-mod that Rob has proposed.
> > > > 
> > > > What else except UID/GID ranges could be modified?
> > > 
> > > 
> > > Ok we had a discussion this morning about how to handle this.
> > > 
> > > We decided to do a few things to simplify installing and managing the
> > > problem when multiple replicas are involved.
> > > 
> > > 1. We will fold back as much as possible into ipa-server-install (and
> > > update scripts for 2 -> 3 updates), in particular we will move generic
> > > ACI creation (including additional ACI for a new group called Trusts
> > > Admins), and the creation of a system user called adtrust and associated
> > > DS user under uid=adtrust,cn=sysaccount,cn=etc,
> > > 
> > > 2. We will preconfigure DS so that SASL/EXTERNAL authentication with
> > > that user results in using the uid=adtrust DN that will have also
> > > pre-assigned ACIs
> > > 
> > > 3. We will change samba's ipasm to use the adtrust user and
> > > SASL/EXTERNAL auth to access DS in order to have privilege separation.
> > > This means smbd keeps operating as a restricted user but will not need a
> > > password to be set via smbpasswd -e
> > > 
> > > 4. We change ipa-adtrust-install to ipa-adtrust-enable, this script will
> > > verify the necessary trust objects are in place and enables starting the
> > > adtrust service (smbd daemon, cldap plugin, ...) It also adds the server
> > > to the _msdcs DNS hive.
> > > 
> > > 5. Each ipa server admins need to use as a bridge to/from AD will need
> > > to be 'activated' by running ipa-adtrust-enable once for now. We can
> > > also consider automatically running it by passing a --enable-adtrust
> > > parameter to ipa-replica-install
> > > 
> > > 6. We change ipa-replica-manage to make sure _msdcs records are also
> > > deleted when a replica is removed.
> > > 
> > > 
> > > This should be all, please send corrections if I forgot something.
> > 'ipa trust' family of commands will be used to manage trust 
> > information after configuration -- listing existing trusts, removing 
> > and modifying them.
> > 
> > In addition, 'ipa trust-add' will do similar ground work 
> > when configuring AD trusts on the master -- it will ensure all needed 
> > records are in LDAP (or will create them) and will ask admin to use 
> > ipa-adtrust-enable to actually activate the trust. All this is due to 
> > the fact that we need to start/restart services with root privileges.
> > 
> > This way we can have a common CLI that will stay the same for all 
> > future trust variants and instruct admins how to activate actual trust 
> > relationship once it is configured.
> > 
> > If we'll find solutions to automate activation process, we can then 
> > replace the instructions with the actual calls to activation.
> 
> Simo, Alexander thank you for the summary.
> 
> I have an open ticket (#1614) which I planned to add to
> ipa-adtrust-install but which might be better solved elsewhere whit the
> current plans.
> 
> In ticket #1614 a DNS plugin configuration shall be created to add SIDs
> to IPA user which should be used in the trusted AD domain as well. We
> can create the DNA conf

Re: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API

[Jan Cholasta]

Dne 14.12.2011 07:53, Martin Kosek napsal(a):

On Fri, 2011-12-09 at 15:55 -0500, Rob Crittenden wrote:

Martin Kosek wrote:

On Thu, 2011-12-01 at 17:18 -0500, Rob Crittenden wrote:

Martin Kosek wrote:

On Mon, 2011-11-28 at 17:35 +0100, Martin Kosek wrote:

I have prepared a working prototype of the new structured DNS API. It
may still have rough edges (and unit tests are not ready), but it will
provide a base for discussion and for WebUI folks - so that they can
start development of the new DNS WebUI API.

The patch takes advantage of the DNS refactor I did in 172. For all
supported non-DNSSEC RR types, the following commands are available:

dnsrecord-show ZONE NAME
dnsrecord-add ZONE NAME
dnsrecord-mod ZONE NAME VALUE

This is an example of the new API in action:

# ipa dnsrecord-show example.com foo
 Record name: foo
 A record: 10.0.0.1

# ipa dnsrecordmx-add example.com foo --exchanger="foo.example.com."
 MX record: 0 foo.example.com.
 Preference: 0
 Exchanger: foo.example.com.

Number of entries returned 1


# ipa dnsrecordmx-add example.com foo --preference=1 
--exchanger="foo.example.com."
 MX record: 0 foo.example.com.
 Preference: 0
 Exchanger: foo.example.com.

 MX record: 1 foo.example.com.
 Preference: 1
 Exchanger: foo.example.com.

Number of entries returned 2


# ipa dnsrecordmx-show example.com foo
 MX record: 0 foo.example.com.
 Preference: 0
 Exchanger: foo.example.com.

 MX record: 1 foo.example.com.
 Preference: 1
 Exchanger: foo.example.com.

Number of entries returned 2



There is an interactive wizard to help user modify a record without
specifying an updated value first. If there is just one (MX) record, no
wizard would be run.

# ipa dnsrecordmx-mod example.com foo --preference=2
Which MX record would you like to modify?

[1]: 0 foo.example.com.
[2]: 1 foo.example.com.

DNS record number: 2
 MX record: 0 foo.example.com.
 Preference: 0
 Exchanger: foo.example.com.

 MX record: 2 foo.example.com.
 Preference: 2
 Exchanger: foo.example.com.

Number of entries returned 2


# ipa dnsrecordmx-mod example.com foo "2 foo.example.com." --preference=3
 MX record: 0 foo.example.com.
 Preference: 0
 Exchanger: foo.example.com.

 MX record: 3 foo.example.com.
 Preference: 3
 Exchanger: foo.example.com.

Number of entries returned 2



There are few open questions I am still thinking about:

1) The commands return a list of structured records (just like *-find
commands) instead of returning just one record. I thought that it may be
more usable this way and consistent with dnsrecord-add/mod/show commands
behavior which returns all records too. Otherwise, we would have to
change the show command API and add VALUE argument, which would specify
a value to be displayed:
dnsrecord-show ZONE NAME VALUE

2) Raw DNS record value is in the output too. I though it would be
useful to see the raw DNS record value + its parts at one place.

3) The commands are in format dnsrecord-cmd, for example
dnsrecordmx-add. I think dnsrecord-mx-add may be more readable. If we
want to go this way, I would have to bend the server framework a little
which parses an LDAP object from the command name (LDAP object name is
dnsrecordmx in this case). This is doable, although I am not sure if
this does not have some implications in WebUI side.

Martin


I rebased both patches to the most recent master. Adding CSVs now works
ok again (with the fix in 175):

# ipa dnsrecord-mod example.com foo --a-rec=10.0.0.1,10.0.0.2
 Record name: foo
 A record: 10.0.0.1, 10.0.0.2

Martin




Rob, thank you for the review! What do you think about the 3 open
questions I posted above?


I think some abbreviations can be eliminated:

siz ->   size
alt ->   altitude


Sure, this can be fixed.



For MX record (and probably KX) you can make preference required. It
should fill in without prompting since it has a default. This way it
will show as required in the UI.


Right, we don't want to run into issues we had with user fields.



PTRRecord doc I think would read better as "The hostname this reverse
record points to"


Ok. Btw do you think it would be good to document this way all these new
DNSRecord part parameters? As I checked with Petr, these would be shown
in the UI - so the UI user would benefit from it. But it will require a
lot of writing and RFC study :-)



I'm not sure I follow the makeapi change. I see the new entry types in
API.txt but this makeapi seems to suggest the DNS api is not checked.


This fix is in validate_doc(), which tries to check that all our
commands have proper __doc__ string. It fails with the new DNS API
commands 

Re: [Freeipa-devel] WIP: ipa trust command

[Sumit Bose]

On Tue, Dec 13, 2011 at 07:08:24PM +0200, Alexander Bokovoy wrote:
> On Tue, 13 Dec 2011, Simo Sorce wrote:
> > On Mon, 2011-12-12 at 22:27 +0200, Alexander Bokovoy wrote:
> > > On Mon, 12 Dec 2011, Sumit Bose wrote:
> > > > > --password  [type-specific parameters]
> > > > > 
> > > > > Creates a trust between FreeIPA realm and another realm of selected 
> > > > > type. Only 'ads' type is currently supported.
> > > > > 
> > > > > For 'ads' type running `ipa trust-add' would be equivalent to 
> > > > > following sequence:
> > > > >  * ipa-adtrust-install
> > > > >  * net rpc trust create
> > > > 
> > > > As Simo already mentioned theses should be two separate step and `ipa
> > > > trust-add' should just check is the needed components to create AD
> > > > trusts are already installed on the IPA server.
> > > See my answer to Simo, I think we can substantially improve this 
> > > situation.
> > > 
> > > > Additionally I think we need some commands to define a UID range for the
> > > > trusted domains, especially for AD trusts. For the domain given with the
> > > > `ipa trust-add' command we could just use another command line option.
> > > > But if this domain already has trusts to other domains it will become
> > > > difficult to handle this with options to `ipa trust-add'. So I would
> > > > suggest to add a new command to the `ipa trust' family which can set UID
> > > > ranges for domains before the trust is created. If the trust is already
> > > > created we may still allow to change the range but with a strong warning
> > > > that existing UIDs and GIDs will change.
> > > Ok, this would qualify for ipa trust-add options for UID/GID ranges 
> > > and would also warrant addition of ipa trust-mod that Rob has proposed.
> > > 
> > > What else except UID/GID ranges could be modified?
> > 
> > 
> > Ok we had a discussion this morning about how to handle this.
> > 
> > We decided to do a few things to simplify installing and managing the
> > problem when multiple replicas are involved.
> > 
> > 1. We will fold back as much as possible into ipa-server-install (and
> > update scripts for 2 -> 3 updates), in particular we will move generic
> > ACI creation (including additional ACI for a new group called Trusts
> > Admins), and the creation of a system user called adtrust and associated
> > DS user under uid=adtrust,cn=sysaccount,cn=etc,
> > 
> > 2. We will preconfigure DS so that SASL/EXTERNAL authentication with
> > that user results in using the uid=adtrust DN that will have also
> > pre-assigned ACIs
> > 
> > 3. We will change samba's ipasm to use the adtrust user and
> > SASL/EXTERNAL auth to access DS in order to have privilege separation.
> > This means smbd keeps operating as a restricted user but will not need a
> > password to be set via smbpasswd -e
> > 
> > 4. We change ipa-adtrust-install to ipa-adtrust-enable, this script will
> > verify the necessary trust objects are in place and enables starting the
> > adtrust service (smbd daemon, cldap plugin, ...) It also adds the server
> > to the _msdcs DNS hive.
> > 
> > 5. Each ipa server admins need to use as a bridge to/from AD will need
> > to be 'activated' by running ipa-adtrust-enable once for now. We can
> > also consider automatically running it by passing a --enable-adtrust
> > parameter to ipa-replica-install
> > 
> > 6. We change ipa-replica-manage to make sure _msdcs records are also
> > deleted when a replica is removed.
> > 
> > 
> > This should be all, please send corrections if I forgot something.
> 'ipa trust' family of commands will be used to manage trust 
> information after configuration -- listing existing trusts, removing 
> and modifying them.
> 
> In addition, 'ipa trust-add' will do similar ground work 
> when configuring AD trusts on the master -- it will ensure all needed 
> records are in LDAP (or will create them) and will ask admin to use 
> ipa-adtrust-enable to actually activate the trust. All this is due to 
> the fact that we need to start/restart services with root privileges.
> 
> This way we can have a common CLI that will stay the same for all 
> future trust variants and instruct admins how to activate actual trust 
> relationship once it is configured.
> 
> If we'll find solutions to automate activation process, we can then 
> replace the instructions with the actual calls to activation.

Simo, Alexander thank you for the summary.

I have an open ticket (#1614) which I planned to add to
ipa-adtrust-install but which might be better solved elsewhere whit the
current plans.

In ticket #1614 a DNS plugin configuration shall be created to add SIDs
to IPA user which should be used in the trusted AD domain as well. We
can create the DNA configuration with the initial setup of the IPA
domain, but since we current store SID strings in the related attribute
the domain SID of the IPA domain must be know. I can think of two was to
solve this. One would be to not store the SID string, but only the RID
part of the SID and let the