Re: [Freeipa-devel] design review: Certificate Profiles

[David Kupka]

On 04/16/2015 10:03 AM, Fraser Tweedale wrote:

Hi everyone,

Please review my Certificate Profiles design proposal:
http://www.freeipa.org/page/V4/Certificate_Profiles

Let me know what is unclear, what needs expansion, and what is plain
wrong :)

The schema for storing multiple certificates for a principal is
still being discussed but I expect it will be agreed soon, and I
will add it to the document.

I am revising the sub-CAs design proposal and it will soon be
published for review as well.

Cheers,
Fraser


Hi Fraser,
I've read the design page and even though I know only a little about 
Dogtag it makes sense to me.


Just a few notes:

3.4 Retrieve profile - There was XML format twice (probably 
copy-paste-forget to modify :-) I changed it, feel free to revert the 
change if it was intentional.


3.5 Delete profile - IMO the profile should be deleted when user 
requests that. If the profile must be disabled before deleted do it as a 
part of deletion.


3.6 Enable/disable profile - When user request enabling/disabling of 
already enabled/disabled profile there is no need to return an error. 
User wants it to be enabled/disabled and it is, job done.


5.2.1 CLI - I would change the command to 'ipa certprofile-add' to stay 
consistent with rest of FreeIPA commands.


--
David Kupka

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 0224-0225] Use NTP servers detected from SRV records in ntp configuration

[Martin Babinsky]

On 04/16/2015 05:14 PM, Martin Basti wrote:

On 16/04/15 13:53, Martin Babinsky wrote:

On 04/16/2015 01:34 PM, Martin Babinsky wrote:

On 04/15/2015 04:17 PM, Martin Basti wrote:

https://fedorahosted.org/freeipa/ticket/4981

These patches keep usage of IPA server address as NTP server in NTP
configuration on clients, in case that  no NTP servers were
specified by
user, and no NTP servers were resolved from SRV records. This will
ensure backward compatibility, as IPA does not configure NTP SRV
records
for each domain automatically.

Patches attached.

Martin^2



PATCH 224 NACK
PATCH 225 ACK

Patch 224 you keep the original destination (dest="ntp_server")
for --ntp-server option, but in patch 226 the code attempts to get the
server names from options.ntpservers resulting in:

Traceback (most recent call last):
   File "/sbin/ipa-client-install", line 2932, in 
 sys.exit(main())
   File "/sbin/ipa-client-install", line 2913, in main
 rval = install(options, env, fstore, statestore)
   File "/sbin/ipa-client-install", line 2342, in install
 if options.ntp_servers:
AttributeError: Values instance has no attribute 'ntp_servers'

So please fix this.

Naming the destination 'ntp_servers' (plural form) seems best because we
now store multiple values.


Also, if renaming "option.ntp_server" to "option.ntp_servers", do not
forget to change also these lines in "ipa-client-install":

2852 if options.ntp_server:
2853 ntp_servers = options.ntp_server

(line numbers after applying patches 224-226)


Stupid me, thank you

Updated patches attached.


ACK

--
Martin^3 Babinsky

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0226] Use user specified NTP servers during initial synchronization

[Martin Babinsky]

On 04/16/2015 05:14 PM, Martin Basti wrote:

On 16/04/15 13:36, Martin Babinsky wrote:

On 04/15/2015 04:18 PM, Martin Basti wrote:

https://fedorahosted.org/freeipa/ticket/4983

Patch attached.





NACK until you fix PATCH 224.


Updated patch attached.


ACK

--
Martin^3 Babinsky

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 0227-0229] Server upgrade: introduce ipa-server-upgrade command

[Martin Basti]

On 15/04/15 16:26, Martin Basti wrote:

https://fedorahosted.org/freeipa/ticket/4904

Patches attached.

Also ipa-upgradeconfig part is called as a subprocess. This will be 
removed after installer modifications.


This patch may cause temporal upgrade issues (corner cases), until 
installer part will be finished.


If somebody will be hit by them, please use --skip-version-check for 
ipactl and ipa-server-upgrade.





Updated patches attached.

--
Martin Basti

From c7421c744d3b42c5530324df7a84632900a77d14 Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Thu, 2 Apr 2015 14:14:15 +0200
Subject: [PATCH 1/3] Server Upgrade: ipa-server-upgrade command

---
 freeipa.spec.in |  2 +
 install/tools/Makefile.am   |  1 +
 install/tools/ipa-server-upgrade| 12 +
 install/tools/man/Makefile.am   |  1 +
 install/tools/man/ipa-server-upgrade.1  | 96 +
 ipaserver/install/ipa_server_upgrade.py | 74 +
 6 files changed, 186 insertions(+)
 create mode 100644 install/tools/ipa-server-upgrade
 create mode 100644 install/tools/man/ipa-server-upgrade.1
 create mode 100644 ipaserver/install/ipa_server_upgrade.py

diff --git a/freeipa.spec.in b/freeipa.spec.in
index 8d58f2568e1de418c25cb1bd34fc7d4736a15e54..0e262d445b80a279488fa77860168f46a0c8a045 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -660,6 +660,7 @@ fi
 %{_sbindir}/ipa-replica-manage
 %{_sbindir}/ipa-csreplica-manage
 %{_sbindir}/ipa-server-certinstall
+%{_sbindir}/ipa-server-upgrade
 %{_sbindir}/ipa-ldap-updater
 %{_sbindir}/ipa-otptoken-import
 %{_sbindir}/ipa-compat-manage
@@ -804,6 +805,7 @@ fi
 %{_mandir}/man1/ipa-replica-prepare.1.gz
 %{_mandir}/man1/ipa-server-certinstall.1.gz
 %{_mandir}/man1/ipa-server-install.1.gz
+%{_mandir}/man1/ipa-server-upgrade.1.gz
 %{_mandir}/man1/ipa-dns-install.1.gz
 %{_mandir}/man1/ipa-ca-install.1.gz
 %{_mandir}/man1/ipa-kra-install.1.gz
diff --git a/install/tools/Makefile.am b/install/tools/Makefile.am
index b791a8c748a18602f88522c3a0e3d74499700ae0..e5d45c47966a503da9f25aec13175793a36962e4 100644
--- a/install/tools/Makefile.am
+++ b/install/tools/Makefile.am
@@ -16,6 +16,7 @@ sbin_SCRIPTS =			\
 	ipa-replica-manage	\
 	ipa-csreplica-manage	\
 	ipa-server-certinstall  \
+	ipa-server-upgrade	\
 	ipactl			\
 	ipa-compat-manage	\
 	ipa-nis-manage		\
diff --git a/install/tools/ipa-server-upgrade b/install/tools/ipa-server-upgrade
new file mode 100644
index ..747024847a7c9d8837b4968395e2c63648a792cf
--- /dev/null
+++ b/install/tools/ipa-server-upgrade
@@ -0,0 +1,12 @@
+#!/usr/bin/python2
+#
+# Copyright (C) 2015  FreeIPA Contributors see COPYING for license
+#
+
+# Documentation can be found at:
+# http://freeipa.org/page/LdapUpdate
+# http://www.freeipa.org/page/V4/Server_Upgrade_Refactoring
+
+from ipaserver.install.ipa_server_upgrade import IPAServerUpgrade
+
+IPAServerUpgrade.run_cli()
diff --git a/install/tools/man/Makefile.am b/install/tools/man/Makefile.am
index 38c049c79fbd2ce22888b47ee576c4574e98c45b..6db1776191ca855986a152dbd4854a0dc1b744d7 100644
--- a/install/tools/man/Makefile.am
+++ b/install/tools/man/Makefile.am
@@ -12,6 +12,7 @@ man1_MANS = \
 	ipa-replica-prepare.1		\
 	ipa-server-certinstall.1	\
 	ipa-server-install.1		\
+	ipa-server-upgrade.1		\
 	ipa-dns-install.1		\
 	ipa-adtrust-install.1		\
 	ipa-ca-install.1		\
diff --git a/install/tools/man/ipa-server-upgrade.1 b/install/tools/man/ipa-server-upgrade.1
new file mode 100644
index ..9b5387301faf749515dcee6f7f5025d9916b2882
--- /dev/null
+++ b/install/tools/man/ipa-server-upgrade.1
@@ -0,0 +1,96 @@
+.\"
+.\" Copyright (C) 2015  FreeIPA Contributors see COPYING for license
+.\"
+
+.TH "ipa-server-upgrade" "1" "April 02 2015" "FreeIPA" "FreeIPA Manual Pages"
+.SH "NAME"
+ipa\-server\-upgrade \- upgrade IPA server
+.SH "SYNOPSIS"
+ipa\-server\-upgrade [options]
+.SH "DESCRIPTION"
+ipa\-server\-upgrade is used to upgrade IPA server when the IPA packages are being updated. It is not intended to be executed by end\-users.
+
+ipa\-server\-upgrade will:
+
+* update LDAP schema
+* process all files with the extension .update in /usr/share/ipa/updates (including update plugins).
+* upgrade local configurations of IPA services
+
+An update file describes an LDAP entry and a set of operations to be performed on that entry. It can be used to add new entries or modify existing entries.
+
+Blank lines and lines beginning with # are ignored.
+
+There are 7 keywords:
+
+* default: the starting value
+* add: add a value (or values) to an attribute
+* remove: remove a value (or values) from an attribute
+* only: set an attribute to this
+* onlyifexist: set an attribute to this only if the entry exists
+* deleteentry: remove the entry
+* replace: replace an existing value, format is old: new
+* addifnew: add a new attribute and va

Re: [Freeipa-devel] [PATCH 0226] Use user specified NTP servers during initial synchronization

[Martin Basti]

On 16/04/15 13:36, Martin Babinsky wrote:

On 04/15/2015 04:18 PM, Martin Basti wrote:

https://fedorahosted.org/freeipa/ticket/4983

Patch attached.





NACK until you fix PATCH 224.


Updated patch attached.

--
Martin Basti

From f1ec7e88a1218fe18a9ca253c5d90197da440330 Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Wed, 15 Apr 2015 15:06:45 +0200
Subject: [PATCH] ipa client: use NTP servers specified by user

NTP servers specified by user should be used to synchronize time.

https://fedorahosted.org/freeipa/ticket/4983
---
 ipa-client/ipa-install/ipa-client-install | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install
index 6cfaa1dd21131b49f99f78ed3df24602b5cf80f3..d3f362afee87491227e0de66cf42ba43890c55be 100755
--- a/ipa-client/ipa-install/ipa-client-install
+++ b/ipa-client/ipa-install/ipa-client-install
@@ -2336,19 +2336,25 @@ def install(options, env, fstore, statestore):
 ntp_srv_servers = ds.ipadns_search_srv(cli_domain, '_ntp._udp',
None, break_on_first=False)
 synced_ntp = False
-if ntp_srv_servers:
-for s in ntp_srv_servers:
-synced_ntp = ipaclient.ntpconf.synconce_ntp(s)
-if synced_ntp:
-break
-if not synced_ntp:
+ntp_servers = ntp_srv_servers
+
+# use user specified NTP servers if there are any
+if options.ntp_servers:
+ntp_servers = options.ntp_servers
+
+for s in ntp_servers:
+synced_ntp = ipaclient.ntpconf.synconce_ntp(s)
+if synced_ntp:
+break
+
+if not synced_ntp and not options.ntp_servers:
 synced_ntp = ipaclient.ntpconf.synconce_ntp(cli_server[0])
 if not synced_ntp:
-root_logger.warning("Unable to sync time with IPA NTP " +
+root_logger.warning("Unable to sync time with NTP " +
 "server, assuming the time is in sync. Please check " +
 "that 123 UDP port is opened.")
 else:
-root_logger.info('Skipping synchronizing time with IPA NTP server.')
+root_logger.info('Skipping synchronizing time with NTP server.')
 
 if not options.unattended:
 if (options.principal is None and options.password is None and
@@ -2843,7 +2849,7 @@ def install(options, env, fstore, statestore):
 if options.force_ntpd:
 ipaclient.ntpconf.force_ntpd(statestore)
 
-if options.ntp_server:
+if options.ntp_servers:
 ntp_servers = options.ntp_servers
 elif ntp_srv_servers:
 ntp_servers = ntp_srv_servers
-- 
2.1.0

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 0224-0225] Use NTP servers detected from SRV records in ntp configuration

[Martin Basti]

On 16/04/15 13:53, Martin Babinsky wrote:

On 04/16/2015 01:34 PM, Martin Babinsky wrote:

On 04/15/2015 04:17 PM, Martin Basti wrote:

https://fedorahosted.org/freeipa/ticket/4981

These patches keep usage of IPA server address as NTP server in NTP
configuration on clients, in case that  no NTP servers were 
specified by

user, and no NTP servers were resolved from SRV records. This will
ensure backward compatibility, as IPA does not configure NTP SRV 
records

for each domain automatically.

Patches attached.

Martin^2



PATCH 224 NACK
PATCH 225 ACK

Patch 224 you keep the original destination (dest="ntp_server")
for --ntp-server option, but in patch 226 the code attempts to get the
server names from options.ntpservers resulting in:

Traceback (most recent call last):
   File "/sbin/ipa-client-install", line 2932, in 
 sys.exit(main())
   File "/sbin/ipa-client-install", line 2913, in main
 rval = install(options, env, fstore, statestore)
   File "/sbin/ipa-client-install", line 2342, in install
 if options.ntp_servers:
AttributeError: Values instance has no attribute 'ntp_servers'

So please fix this.

Naming the destination 'ntp_servers' (plural form) seems best because we
now store multiple values.

Also, if renaming "option.ntp_server" to "option.ntp_servers", do not 
forget to change also these lines in "ipa-client-install":


2852 if options.ntp_server:
2853 ntp_servers = options.ntp_server

(line numbers after applying patches 224-226)


Stupid me, thank you

Updated patches attached.

--
Martin Basti

From 73a920ad890ddbce953daf1317034f21da07c529 Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Tue, 14 Apr 2015 18:56:47 +0200
Subject: [PATCH 1/2] ipa client: make --ntp-server option multivalued

There can be more ntp servers in ntp.conf

Required for ticket: https://fedorahosted.org/freeipa/ticket/4981
---
 ipa-client/ipa-install/ipa-client-install | 19 +++
 ipa-client/ipaclient/ntpconf.py   | 11 ++-
 ipa-client/man/ipa-client-install.1   |  2 +-
 3 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install
index 1590a08600bbb1b2fd7f4c3338b5060156d7dc38..b9c7df1485bf60c4c073cd168c8731a8130d8ac9 100755
--- a/ipa-client/ipa-install/ipa-client-install
+++ b/ipa-client/ipa-install/ipa-client-install
@@ -118,7 +118,9 @@ def parse_options():
 basic_group.add_option("", "--force-join", dest="force_join",
   action="store_true", default=False,
   help="Force client enrollment even if already enrolled")
-basic_group.add_option("--ntp-server", dest="ntp_server", help="ntp server to use")
+basic_group.add_option("--ntp-server", dest="ntp_servers", action="append",
+   help="ntp server to use. This option can be used "
+"multiple times")
 basic_group.add_option("-N", "--no-ntp", action="store_false",
   help="do not configure ntp", default=True, dest="conf_ntp")
 basic_group.add_option("", "--force-ntpd", dest="force_ntpd",
@@ -2330,10 +2332,11 @@ def install(options, env, fstore, statestore):
 # We assume that NTP servers are discoverable through SRV records in the DNS
 # If that fails, we try to sync directly with IPA server, assuming it runs NTP
 root_logger.info('Synchronizing time with KDC...')
-ntp_servers = ds.ipadns_search_srv(cli_domain, '_ntp._udp', None, break_on_first=False)
+ntp_srv_servers = ds.ipadns_search_srv(cli_domain, '_ntp._udp',
+   None, break_on_first=False)
 synced_ntp = False
-if ntp_servers:
-for s in ntp_servers:
+if ntp_srv_servers:
+for s in ntp_srv_servers:
 synced_ntp = ipaclient.ntpconf.synconce_ntp(s)
 if synced_ntp:
 break
@@ -2838,11 +2841,11 @@ def install(options, env, fstore, statestore):
 # disable other time&date services first
 if options.force_ntpd:
 ipaclient.ntpconf.force_ntpd(statestore)
-if options.ntp_server:
-ntp_server = options.ntp_server
+if options.ntp_servers:
+ntp_servers = options.ntp_servers
 else:
-ntp_server = cli_server[0]
-ipaclient.ntpconf.config_ntp(ntp_server, fstore, statestore)
+ntp_servers = cli_server
+ipaclient.ntpconf.config_ntp(ntp_servers, fstore, statestore)
 root_logger.info("NTP enabled")
 
 if options.conf_ssh:
diff --git a/ipa-client/ipaclient/ntpconf.py b/ipa-client/ipaclient/ntpconf.py
index 7d5c82a89b51f68362f12869a9234f5b69aa5ba9..c22fba401d33009b3b95d1418dc7c8a03328d569 100644
--- a/ipa-client/ipaclient/ntpconf.py
+++ b/ipa-client/ipaclient/ntpconf.py
@@ -41,7 +41,7 @@ restrict -6 ::1
 
 # Use public servers from the pool.ntp.org

[Freeipa-devel] [PATCH 0230] Server upgrade: fix comment in ldapupdater

[Martin Basti]

https://fedorahosted.org/freeipa/ticket/4904

Patch attached

--
Martin Basti

From 08e1b68b4f78dd52640bc61bbd67e03deff886fc Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Thu, 16 Apr 2015 15:32:01 +0200
Subject: [PATCH] Server Upgrade: fix a comment in ldapupdater

DN sorting was removed in previous patches

https://fedorahosted.org/freeipa/ticket/4904
---
 ipaserver/install/ldapupdate.py | 4 
 1 file changed, 4 deletions(-)

diff --git a/ipaserver/install/ldapupdate.py b/ipaserver/install/ldapupdate.py
index 1f30f4b215383a7964c578975b239ea4a57f68a8..bf352b157943387fee2dc0f04653f8909e159fcf 100644
--- a/ipaserver/install/ldapupdate.py
+++ b/ipaserver/install/ldapupdate.py
@@ -771,10 +771,6 @@ class LDAPUpdate:
 """
 Run through all the updates again looking for any that should be
 deleted.
-
-This must use a reversed list so that the longest entries are
-considered first so we don't end up trying to delete a parent
-and child in the wrong order.
 """
 
 dn = updates['dn']
-- 
2.1.0

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [PATCH 424] install: Introduce installer framework ipapython.install

[Jan Cholasta]

Hi,

the attached patch adds the basics of the new installer framework.

As a next step, I plan to convert the install scripts to use the 
framework with their old code (the old code will be gradually ported to 
the framework later).


(Note I didn't manage to write docstrings today, expect update tomorrow.)

Honza

--
Jan Cholasta
>From 04e25a74d0aea5f9883ed5b7d831f488a78eb33e Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Thu, 16 Apr 2015 14:35:24 +
Subject: [PATCH] install: Introduce installer framework ipapython.install

---
 ipapython/install.py | 403 +++
 1 file changed, 403 insertions(+)
 create mode 100644 ipapython/install.py

diff --git a/ipapython/install.py b/ipapython/install.py
new file mode 100644
index 000..cfbf261
--- /dev/null
+++ b/ipapython/install.py
@@ -0,0 +1,403 @@
+# Authors:
+#   Jan Cholasta 
+#
+# Copyright (C) 2015  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 .
+#
+
+"""
+Installer framework.
+"""
+
+# FIXME: docstrings!
+
+import sys
+import inspect
+import abc
+import itertools
+
+_VALIDATE_PENDING = 'VALIDATE_PENDING'
+_VALIDATE_RUNNING = 'VALIDATE_RUNNING'
+_EXECUTE_PENDING = 'EXECUTE_PENDING'
+_EXECUTE_RUNNING = 'EXECUTE_RUNNING'
+_STOPPED = 'STOPPED'
+_FAILED = 'FAILED'
+_CLOSED = 'CLOSED'
+
+_missing = object()
+
+
+def wait():
+yield
+
+
+def unroll(gen):
+exc_info = None
+
+while True:
+try:
+if exc_info is not None:
+sub_gen = gen.throw(*exc_info)
+else:
+sub_gen = gen.next()
+except StopIteration:
+break
+
+exc_info = None
+
+while True:
+try:
+sub_gen.next()
+except StopIteration:
+break
+except BaseException:
+exc_info = sys.exc_info()
+break
+
+try:
+yield
+except GeneratorExit:
+sub_gen.close()
+gen.close()
+return
+except BaseException:
+exc_info = sys.exc_info()
+break
+
+
+def rolled(func):
+def decorated(*args, **kwargs):
+return unroll(func(*args, **kwargs))
+decorated.__name__ = func.__name__
+decorated.__doc__ = func.__doc__
+
+return decorated
+
+
+class InvalidStateError(Exception):
+pass
+
+
+class Knob(object):
+__counter = itertools.count()
+
+def __init__(self, type, default=_missing, label=None):
+self.type = type
+if default is _missing:
+self.required = True
+self.default = None
+else:
+self.required = False
+self.default = default
+self.label = label
+self.order = next(self.__counter)
+
+def _set(self, obj, value):
+setattr(obj, '_knob{0}'.format(id(self)), value)
+
+def __get__(self, obj, obj_type):
+if obj is None:
+return self
+return getattr(obj, '_knob{0}'.format(id(self)))
+
+
+class Configurator(object):
+@classmethod
+def args(cls):
+for super_cls in cls.__mro__:
+if not issubclass(super_cls, Configurator):
+continue
+
+try:
+init = super_cls.__dict__['__init__']
+except KeyError:
+continue
+
+argspec = inspect.getargspec(init)
+for name in argspec.args[1:]:
+yield name
+
+for knob_cls, name, obj in cls.knobs():
+yield name
+
+@classmethod
+def knobs(cls):
+for name in dir(cls):
+obj = getattr(cls, name)
+if isinstance(obj, Knob):
+yield (cls, name, obj)
+
+def __init__(self, **kwargs):
+for cls, name, knob in self.knobs():
+try:
+value = kwargs.pop(name)
+except KeyError:
+if knob.required:
+continue
+value = knob.default
+setattr(self, name, value)
+
+missing = set()
+for name in self.args():
+try:
+getattr(self, name)
+except AttributeError:
+missing.add(name)
+
+if missing:
+missing = sorted(missing)
+  

Re: [Freeipa-devel] Time-Based Account Policies - Feature Proposal

[Alexander Bokovoy]

On Thu, 16 Apr 2015, Simo Sorce wrote:

On Thu, 2015-04-16 at 10:04 +0200, Stanislav Láznička wrote:

>> Possible values of each keyword:
>> timeofday   -2359
>> dayofweek   Mon, Tue, Wed, Thu, Fri, Sat, Sun
>> dayofmonth  1-31
>> weekofmonth 1-5
>> monthofyear Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct,
>> Nov, Dec
>> yeara year
>
> IMO dayofweek and monthofyear should use number as well. Numbers
> are easier to process.
>
On the other hand, names of days and months keep the rule more
readable,


... for English speakers ...

I agree. We can always provide readable interface in the UI or CLI but I don't
think having names as LDAP values would be good.


which I think might be better when checking for mistakes in those
rules.


In most cases people will read these rules after they have been through
a parser that can translate numbers in whatever locale names the user
uses. Using numbers is preferable.

Please let's not mix schema and presentation here. The LDAP schema
should be tilted toward coding convenience first and readability second
(with exceptions as always).

Yep.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-Based Account Policies - Feature Proposal

[Simo Sorce]

On Thu, 2015-04-16 at 10:04 +0200, Stanislav Láznička wrote:
> >> Possible values of each keyword:
> >> timeofday   -2359
> >> dayofweek   Mon, Tue, Wed, Thu, Fri, Sat, Sun
> >> dayofmonth  1-31
> >> weekofmonth 1-5
> >> monthofyear Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, 
> >> Nov, Dec
> >> yeara year
> >
> > IMO dayofweek and monthofyear should use number as well. Numbers
> are 
> > easier to process.
> >
> On the other hand, names of days and months keep the rule more
> readable, 

... for English speakers ...

> which I think might be better when checking for mistakes in those
> rules.

In most cases people will read these rules after they have been through
a parser that can translate numbers in whatever locale names the user
uses. Using numbers is preferable.

Please let's not mix schema and presentation here. The LDAP schema
should be tilted toward coding convenience first and readability second
(with exceptions as always).

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 0224-0225] Use NTP servers detected from SRV records in ntp configuration

[Martin Babinsky]

On 04/16/2015 01:34 PM, Martin Babinsky wrote:

On 04/15/2015 04:17 PM, Martin Basti wrote:

https://fedorahosted.org/freeipa/ticket/4981

These patches keep usage of IPA server address as NTP server in NTP
configuration on clients, in case that  no NTP servers were specified by
user, and no NTP servers were resolved from SRV records. This will
ensure backward compatibility, as IPA does not configure NTP SRV records
for each domain automatically.

Patches attached.

Martin^2



PATCH 224 NACK
PATCH 225 ACK

Patch 224 you keep the original destination (dest="ntp_server")
for --ntp-server option, but in patch 226 the code attempts to get the
server names from options.ntpservers resulting in:

Traceback (most recent call last):
   File "/sbin/ipa-client-install", line 2932, in 
 sys.exit(main())
   File "/sbin/ipa-client-install", line 2913, in main
 rval = install(options, env, fstore, statestore)
   File "/sbin/ipa-client-install", line 2342, in install
 if options.ntp_servers:
AttributeError: Values instance has no attribute 'ntp_servers'

So please fix this.

Naming the destination 'ntp_servers' (plural form) seems best because we
now store multiple values.

Also, if renaming "option.ntp_server" to "option.ntp_servers", do not 
forget to change also these lines in "ipa-client-install":


2852 if options.ntp_server:
2853 ntp_servers = options.ntp_server

(line numbers after applying patches 224-226)

--
Martin^3 Babinsky

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0226] Use user specified NTP servers during initial synchronization

[Martin Babinsky]

On 04/15/2015 04:18 PM, Martin Basti wrote:

https://fedorahosted.org/freeipa/ticket/4983

Patch attached.





NACK until you fix PATCH 224.

--
Martin^3 Babinsky

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 0224-0225] Use NTP servers detected from SRV records in ntp configuration

[Martin Babinsky]

On 04/15/2015 04:17 PM, Martin Basti wrote:

https://fedorahosted.org/freeipa/ticket/4981

These patches keep usage of IPA server address as NTP server in NTP
configuration on clients, in case that  no NTP servers were specified by
user, and no NTP servers were resolved from SRV records. This will
ensure backward compatibility, as IPA does not configure NTP SRV records
for each domain automatically.

Patches attached.

Martin^2



PATCH 224 NACK
PATCH 225 ACK

Patch 224 you keep the original destination (dest="ntp_server")
for --ntp-server option, but in patch 226 the code attempts to get the 
server names from options.ntpservers resulting in:


Traceback (most recent call last):
  File "/sbin/ipa-client-install", line 2932, in 
sys.exit(main())
  File "/sbin/ipa-client-install", line 2913, in main
rval = install(options, env, fstore, statestore)
  File "/sbin/ipa-client-install", line 2342, in install
if options.ntp_servers:
AttributeError: Values instance has no attribute 'ntp_servers'

So please fix this.

Naming the destination 'ntp_servers' (plural form) seems best because we 
now store multiple values.


--
Martin^3 Babinsky

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [PATCH] 0005 User life cycle: del/mod/find/show stageuser commands

[thierry bordaz]

Hello,

   Here is the next patch for User life cycle that introduces
   del/mod/find and show stageuser plugin commands.

 * -User Life Cycle (create containers and scoping  DS plugins):
   *pushed*
 * 0001-User-Life-Cycle-Exclude-subtree-for-ipaUniqueID-gene.patch:
   *pushed*
 * 0002-User-life-cycle-stageuser-add-verb.patch: *pushed*
 * 0007-User-life-cycle-allows-MODRDN-from-ldap2.patch: *pushed*
 * 0003-User-life-cycle-new-stageuser-commands-del-mod-find-*under
   review *(this one)**
 * 0004-User-life-cycle-new-stageuser-commands-activate.patch
 * 0005-User-life-cycle-new-stageuser-commands-activate-prov.patch
 * 0006-User-life-cycle-user-del-supports-permanently-preser.patch
 * 0008-User-life-cycle-user-find-support-finding-delete-use.patch
 * 0009-User-life-cycle-support-of-user-undel.patch
 * 0010-User-life-cycle-DNA-DS-plugin-should-exclude-provisi.patch
 * 0011-User-life-cycle-lockout-provisioning-stage-and-delet.patch
 * 0012-User-life-cycle-Create-stage-Admin-provisioning-acco.patch
 * 0013-User-life-cycle-Stage-Admin-permission-priviledge.patch

Thanks
thierry

From 1393b393468584579212e84be30142ae3049a625 Mon Sep 17 00:00:00 2001
From: Thierry Bordaz 
Date: Thu, 16 Apr 2015 10:17:31 +0200
Subject: [PATCH] User life cycle: new stageuser commands del/mod/find/show

Add plugin commands to stageuser plugin:
	stageuser_del
	stageuser_mod
	stageuser_find
	stageuser_show

https://fedorahosted.org/freeipa/ticket/3813
---
 API.txt | 128 ++
 VERSION |   4 +-
 ipalib/plugins/stageuser.py | 147 +++-
 3 files changed, 276 insertions(+), 3 deletions(-)

diff --git a/API.txt b/API.txt
index f747765d7f9c87761fed0277cd59d1bc3fbd57e9..f2d9af90cc1c0fd373ab9847d2d1327f68671414 100644
--- a/API.txt
+++ b/API.txt
@@ -3740,6 +3740,134 @@ option: Str('version?', exclude='webui')
 output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
 output: Output('summary', (, ), None)
 output: PrimaryKey('value', None, None)
+command: stageuser_del
+args: 1,2,3
+arg: Str('uid', attribute=True, cli_name='login', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True)
+option: Flag('continue', autofill=True, cli_name='continue', default=False)
+option: Str('version?', exclude='webui')
+output: Output('result', , None)
+output: Output('summary', (, ), None)
+output: ListOfPrimaryKeys('value', None, None)
+command: stageuser_find
+args: 1,52,4
+arg: Str('criteria?', noextrawhitespace=False)
+option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
+option: Str('carlicense', attribute=True, autofill=False, cli_name='carlicense', multivalue=True, query=True, required=False)
+option: Str('cn', attribute=True, autofill=False, cli_name='cn', multivalue=False, query=True, required=False)
+option: Str('departmentnumber', attribute=True, autofill=False, cli_name='departmentnumber', multivalue=True, query=True, required=False)
+option: Str('displayname', attribute=True, autofill=False, cli_name='displayname', multivalue=False, query=True, required=False)
+option: Str('employeenumber', attribute=True, autofill=False, cli_name='employeenumber', multivalue=False, query=True, required=False)
+option: Str('employeetype', attribute=True, autofill=False, cli_name='employeetype', multivalue=False, query=True, required=False)
+option: Str('facsimiletelephonenumber', attribute=True, autofill=False, cli_name='fax', multivalue=True, query=True, required=False)
+option: Str('gecos', attribute=True, autofill=False, cli_name='gecos', multivalue=False, query=True, required=False)
+option: Int('gidnumber', attribute=True, autofill=False, cli_name='gidnumber', minvalue=1, multivalue=False, query=True, required=False)
+option: Str('givenname', attribute=True, autofill=False, cli_name='first', multivalue=False, query=True, required=False)
+option: Str('homedirectory', attribute=True, autofill=False, cli_name='homedir', multivalue=False, query=True, required=False)
+option: Str('in_group*', cli_name='in_groups', csv=True)
+option: Str('in_hbacrule*', cli_name='in_hbacrules', csv=True)
+option: Str('in_netgroup*', cli_name='in_netgroups', csv=True)
+option: Str('in_role*', cli_name='in_roles', csv=True)
+option: Str('in_sudorule*', cli_name='in_sudorules', csv=True)
+option: Str('initials', attribute=True, autofill=False, cli_name='initials', multivalue=False, query=True, required=False)
+option: Str('ipatokenradiusconfiglink', attribute=True, autofill=False, cli_name='radius', multivalue=False, query=True, required=False)
+option: Str('ipatokenradiususername', attribute=True, autofill=False, cli_name='radius_username', multivalue=False, query=True, required=False)
+option: StrEnum('ipauserauthtype', attribute=True, autofill=False, cli_name='user_auth_type', csv=True, multivalue=Tru

Re: [Freeipa-devel] Time-Based Account Policies - Feature Proposal

[Standa Láznička]

On 4/16/2015 10:26 AM, Alexander Bokovoy wrote:

On Thu, 16 Apr 2015, Stanislav Láznička wrote:

On 04/16/2015 08:04 AM, Jan Cholasta wrote:

Hi,

Dne 15.4.2015 v 16:07 Stanislav Láznička napsal(a):

Hi,

I have prepared a feature proposal for the wiki. I followed the 
Feature
Proposal Template and the chapter "How to Test" is currently 
missing so
it might rather be considered a draft. Please, see it, I hope it's 
alright.


The text:

Overview
FreeIPA is currently missing any temporal settings in the HBAC rules.
However, handling access to a host in repeating time periods might 
be a
desirable feature. The administrator of a certain environment 
should be
able to set the time a host should be accessed in either the host 
local
time, a certain time zone time or in UTC. Host-local-time policies 
would

allow to adapt the time a host can be accessed to the host's movement
along different time zones. A time bound to a certain time zone is 
more

transparent than local time as it doesn't change with the host
traveling. Sometimes, it may also be important to set time in UTC. 
This

is rather strict setting that does not reflect daylight saving time.

Use Cases
1. A host is changing position on the globe quite often and needs 
to be

accessed at certain times reflecting its current time zone.
2. A host should only be accessed at certain times given by a certain
time zone. This access is repeated in a way, such as three times a 
week
the same time except for once a year where there's regular 
maintenance.


Design
The time based account policies are an extension to the current (April
2015) HBAC plugin. It assumes the time through the system is well 
set on

all host stations via the NTP.

Time Scenarios
This extension is designed so that it understands time in three
different views. These are: host local time, time at a certain time
zone, and UTC.

Host Local Time
Host local time approach is meant for those hosts that are most likely
to move across different time zones and for some reason it's important
that the time they can be accessed reflects their current position. 
This

helps creating only a single HBAC rule instead of multiple when only
time zone or UTC rules would apply. The time of a host is counted 
using
the /etc/timezone information of the certain host. Testing of such 
rule

requires the tester to specify a certain time zone the rule would be
tested against.
It's important to note that this type of policy may bring some
unexpected behavior as hosts move across the globe, or even in a 
single

hostgroup, when there're hosts from multiple timezones, and
administrator should be very sure they want to use this.

Time Zones
In this approach, the time is thought of as of a time at a certain 
time
zone. This might be interesting when the time settings should 
reflect a
certain time zone, eg. the host or the users connecting to it are 
to be
found in that certain time zone. The time zone offset to count the 
time

of access is taken from the Olson database. Therefore, even daylight
saving time is taken into account.

UTC
Sometimes the rules should apply for a certain time that is the 
same for

the whole globe throughout the year. That's why UTC should also be
supported.

Time Policies Storage
The time policies should be stored with each the HBAC rule that 
applies

such a policy. This extension is designed so that the LDAP schema does
not have to be changed.

The time policies are stored in the accessTime attribute of the HBAC
rule object. The policy is a string in a form of tuple: (anchor, 
time).
In this tuple, the anchor is one of "host", "utc" or Olson database 
time

zone name, such as "Europe/Prague". The meaning of the anchor follows
the time scenarios from this design. The time part of the policy tuple
is the time range of the policy.


It should be called "timezone", not "anchor". Anchor was something 
different (and I really regret calling it that, seeing how it got 
stuck).


Is there any real benefit in storing time zone with each access 
time? I think it should be good enough to have one time zone per 
HBAC rule, which would also reduce complexity of the whole thing.


I was thinking "host", "utc" - these are not timezones. Maybe it 
would be more accurate to call it an anchor or a handle.

And you are wrong here.
Olson database does have UTC as a timezone designator. I said previously
that this field should have just a value of Olson database and that's
fine. Simo was also talking about using an empty string to indicate 'use
timezone of the server' and I think with this we'd get a simple logic:

- if timezone value is empty (''), timezone of the target server is 
used, based

 on /etc/localtime value.
- if timezone value is not empty, it designates a timezone from Olson
 database.

No need to invent anything else here, in my opinion.


Oh, I see. No problem calling it a timezone, then, as such description 
is accurate.


--
Manage your subscription for the Freeipa-devel mailing list:
https:

Re: [Freeipa-devel] New installer PoC

[Jan Cholasta]

Dne 16.4.2015 v 10:51 Petr Vobornik napsal(a):

On 03/23/2015 09:03 AM, Jan Cholasta wrote:

Hi,

the attached patch contains a new PoC installer for httpd.

Design goals:

1) Make code related to any particular configuration change co-located,
be it install/uninstall/upgrade.

2) Get rid of code duplicates.

3) Use the same code path for install and upgrade.

4) Provide metadata for parameters from which option parsers etc. can be
generated.

5) Make installers plugable. This is not really apparent from the patch,
since it only implements installer for a single component, but I plan to
make the whole thing extensible by plugins.

Honza



1. In

-def install_http(config, auto_redirect):
+def install_http(config, http):

to me, it was not obvious whether `http` is an http instance or an http
installer. I would prefer `installer` or `http_installer`.
Distinguishing these two could be a good convention.


OK. Note that this particular piece of code is temporary though.



2. What is the reason for hard coding step numbers in output messages,
e.g.:

+if self.is_installer:
+self.service.print_msg("  [6/16] configuring httpd")

Is it temporary for the POC?


Yes.


I look forward to the plugin support. Do
you plan to allow adding a step in the plugin to an arbitrary place?


Yes, sort of.


It
could invalidate these hardcoded strings.


--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] New installer PoC

[Petr Vobornik]

On 03/23/2015 09:03 AM, Jan Cholasta wrote:

Hi,

the attached patch contains a new PoC installer for httpd.

Design goals:

1) Make code related to any particular configuration change co-located,
be it install/uninstall/upgrade.

2) Get rid of code duplicates.

3) Use the same code path for install and upgrade.

4) Provide metadata for parameters from which option parsers etc. can be
generated.

5) Make installers plugable. This is not really apparent from the patch,
since it only implements installer for a single component, but I plan to
make the whole thing extensible by plugins.

Honza



1. In

-def install_http(config, auto_redirect):
+def install_http(config, http):

to me, it was not obvious whether `http` is an http instance or an http 
installer. I would prefer `installer` or `http_installer`. 
Distinguishing these two could be a good convention.


2. What is the reason for hard coding step numbers in output messages, e.g.:

+if self.is_installer:
+self.service.print_msg("  [6/16] configuring httpd")

Is it temporary for the POC? I look forward to the plugin support. Do 
you plan to allow adding a step in the plugin to an arbitrary place? It 
could invalidate these hardcoded strings.

--
Petr Vobornik

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-Based Account Policies - Feature Proposal

[Alexander Bokovoy]

On Thu, 16 Apr 2015, Stanislav Láznička wrote:

On 04/16/2015 08:04 AM, Jan Cholasta wrote:

Hi,

Dne 15.4.2015 v 16:07 Stanislav Láznička napsal(a):

Hi,

I have prepared a feature proposal for the wiki. I followed the Feature
Proposal Template and the chapter "How to Test" is currently missing so
it might rather be considered a draft. Please, see it, I hope it's 
alright.


The text:

Overview
FreeIPA is currently missing any temporal settings in the HBAC rules.
However, handling access to a host in repeating time periods might be a
desirable feature. The administrator of a certain environment should be
able to set the time a host should be accessed in either the host local
time, a certain time zone time or in UTC. Host-local-time policies would
allow to adapt the time a host can be accessed to the host's movement
along different time zones. A time bound to a certain time zone is more
transparent than local time as it doesn't change with the host
traveling. Sometimes, it may also be important to set time in UTC. This
is rather strict setting that does not reflect daylight saving time.

Use Cases
1. A host is changing position on the globe quite often and needs to be
accessed at certain times reflecting its current time zone.
2. A host should only be accessed at certain times given by a certain
time zone. This access is repeated in a way, such as three times a week
the same time except for once a year where there's regular maintenance.

Design
The time based account policies are an extension to the current (April
2015) HBAC plugin. It assumes the time through the system is well set on
all host stations via the NTP.

Time Scenarios
This extension is designed so that it understands time in three
different views. These are: host local time, time at a certain time
zone, and UTC.

Host Local Time
Host local time approach is meant for those hosts that are most likely
to move across different time zones and for some reason it's important
that the time they can be accessed reflects their current position. This
helps creating only a single HBAC rule instead of multiple when only
time zone or UTC rules would apply. The time of a host is counted using
the /etc/timezone information of the certain host. Testing of such rule
requires the tester to specify a certain time zone the rule would be
tested against.
It's important to note that this type of policy may bring some
unexpected behavior as hosts move across the globe, or even in a single
hostgroup, when there're hosts from multiple timezones, and
administrator should be very sure they want to use this.

Time Zones
In this approach, the time is thought of as of a time at a certain time
zone. This might be interesting when the time settings should reflect a
certain time zone, eg. the host or the users connecting to it are to be
found in that certain time zone. The time zone offset to count the time
of access is taken from the Olson database. Therefore, even daylight
saving time is taken into account.

UTC
Sometimes the rules should apply for a certain time that is the same for
the whole globe throughout the year. That's why UTC should also be
supported.

Time Policies Storage
The time policies should be stored with each the HBAC rule that applies
such a policy. This extension is designed so that the LDAP schema does
not have to be changed.

The time policies are stored in the accessTime attribute of the HBAC
rule object. The policy is a string in a form of tuple: (anchor, time).
In this tuple, the anchor is one of "host", "utc" or Olson database time
zone name, such as "Europe/Prague". The meaning of the anchor follows
the time scenarios from this design. The time part of the policy tuple
is the time range of the policy.


It should be called "timezone", not "anchor". Anchor was something 
different (and I really regret calling it that, seeing how it got 
stuck).


Is there any real benefit in storing time zone with each access 
time? I think it should be good enough to have one time zone per 
HBAC rule, which would also reduce complexity of the whole thing.


I was thinking "host", "utc" - these are not timezones. Maybe it would 
be more accurate to call it an anchor or a handle.

And you are wrong here.
Olson database does have UTC as a timezone designator. I said previously
that this field should have just a value of Olson database and that's
fine. Simo was also talking about using an empty string to indicate 'use
timezone of the server' and I think with this we'd get a simple logic:

- if timezone value is empty (''), timezone of the target server is used, based
 on /etc/localtime value.
- if timezone value is not empty, it designates a timezone from Olson
 database.

No need to invent anything else here, in my opinion.


--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-Based Account Policies - Feature Proposal

[Jan Cholasta]

Dne 16.4.2015 v 10:04 Stanislav Láznička napsal(a):

On 04/16/2015 08:04 AM, Jan Cholasta wrote:

Hi,

Dne 15.4.2015 v 16:07 Stanislav Láznička napsal(a):

Hi,

I have prepared a feature proposal for the wiki. I followed the Feature
Proposal Template and the chapter "How to Test" is currently missing so
it might rather be considered a draft. Please, see it, I hope it's
alright.

The text:

Overview
FreeIPA is currently missing any temporal settings in the HBAC rules.
However, handling access to a host in repeating time periods might be a
desirable feature. The administrator of a certain environment should be
able to set the time a host should be accessed in either the host local
time, a certain time zone time or in UTC. Host-local-time policies would
allow to adapt the time a host can be accessed to the host's movement
along different time zones. A time bound to a certain time zone is more
transparent than local time as it doesn't change with the host
traveling. Sometimes, it may also be important to set time in UTC. This
is rather strict setting that does not reflect daylight saving time.

Use Cases
1. A host is changing position on the globe quite often and needs to be
accessed at certain times reflecting its current time zone.
2. A host should only be accessed at certain times given by a certain
time zone. This access is repeated in a way, such as three times a week
the same time except for once a year where there's regular maintenance.

Design
The time based account policies are an extension to the current (April
2015) HBAC plugin. It assumes the time through the system is well set on
all host stations via the NTP.

Time Scenarios
This extension is designed so that it understands time in three
different views. These are: host local time, time at a certain time
zone, and UTC.

Host Local Time
Host local time approach is meant for those hosts that are most likely
to move across different time zones and for some reason it's important
that the time they can be accessed reflects their current position. This
helps creating only a single HBAC rule instead of multiple when only
time zone or UTC rules would apply. The time of a host is counted using
the /etc/timezone information of the certain host. Testing of such rule
requires the tester to specify a certain time zone the rule would be
tested against.
It's important to note that this type of policy may bring some
unexpected behavior as hosts move across the globe, or even in a single
hostgroup, when there're hosts from multiple timezones, and
administrator should be very sure they want to use this.

Time Zones
In this approach, the time is thought of as of a time at a certain time
zone. This might be interesting when the time settings should reflect a
certain time zone, eg. the host or the users connecting to it are to be
found in that certain time zone. The time zone offset to count the time
of access is taken from the Olson database. Therefore, even daylight
saving time is taken into account.

UTC
Sometimes the rules should apply for a certain time that is the same for
the whole globe throughout the year. That's why UTC should also be
supported.

Time Policies Storage
The time policies should be stored with each the HBAC rule that applies
such a policy. This extension is designed so that the LDAP schema does
not have to be changed.

The time policies are stored in the accessTime attribute of the HBAC
rule object. The policy is a string in a form of tuple: (anchor, time).
In this tuple, the anchor is one of "host", "utc" or Olson database time
zone name, such as "Europe/Prague". The meaning of the anchor follows
the time scenarios from this design. The time part of the policy tuple
is the time range of the policy.


It should be called "timezone", not "anchor". Anchor was something
different (and I really regret calling it that, seeing how it got stuck).

Is there any real benefit in storing time zone with each access time?
I think it should be good enough to have one time zone per HBAC rule,
which would also reduce complexity of the whole thing.


I was thinking "host", "utc" - these are not timezones. Maybe it would
be more accurate to call it an anchor or a handle.


"UTC" is a timezone according to 
.


The value usually is a valid timezone, I don't think we need to call it 
differently because of *one* value which is not.




The timezone should probably be stored just once in the rule, you're
right. In the design, I was aiming for not changing the schema, but it
probably makes no sense to keep it as it is.


The language of the time half of the time policy tuple is inspired by
the time part of Bind Rules of 389 Directory Server. Aside from the Bind
Rules keywords timeofday and dayofweek, it adds keywords dayofmonth,
weekofmonth, monthofyear and year. There are three operators: assignment
("="), range ("-") and union(","). Assignment operator is used after
each of the keywords above to specif

Re: [Freeipa-devel] Time-Based Account Policies - Feature Proposal

[Stanislav Láznička]

On 04/16/2015 08:04 AM, Jan Cholasta wrote:

Hi,

Dne 15.4.2015 v 16:07 Stanislav Láznička napsal(a):

Hi,

I have prepared a feature proposal for the wiki. I followed the Feature
Proposal Template and the chapter "How to Test" is currently missing so
it might rather be considered a draft. Please, see it, I hope it's 
alright.


The text:

Overview
FreeIPA is currently missing any temporal settings in the HBAC rules.
However, handling access to a host in repeating time periods might be a
desirable feature. The administrator of a certain environment should be
able to set the time a host should be accessed in either the host local
time, a certain time zone time or in UTC. Host-local-time policies would
allow to adapt the time a host can be accessed to the host's movement
along different time zones. A time bound to a certain time zone is more
transparent than local time as it doesn't change with the host
traveling. Sometimes, it may also be important to set time in UTC. This
is rather strict setting that does not reflect daylight saving time.

Use Cases
1. A host is changing position on the globe quite often and needs to be
accessed at certain times reflecting its current time zone.
2. A host should only be accessed at certain times given by a certain
time zone. This access is repeated in a way, such as three times a week
the same time except for once a year where there's regular maintenance.

Design
The time based account policies are an extension to the current (April
2015) HBAC plugin. It assumes the time through the system is well set on
all host stations via the NTP.

Time Scenarios
This extension is designed so that it understands time in three
different views. These are: host local time, time at a certain time
zone, and UTC.

Host Local Time
Host local time approach is meant for those hosts that are most likely
to move across different time zones and for some reason it's important
that the time they can be accessed reflects their current position. This
helps creating only a single HBAC rule instead of multiple when only
time zone or UTC rules would apply. The time of a host is counted using
the /etc/timezone information of the certain host. Testing of such rule
requires the tester to specify a certain time zone the rule would be
tested against.
It's important to note that this type of policy may bring some
unexpected behavior as hosts move across the globe, or even in a single
hostgroup, when there're hosts from multiple timezones, and
administrator should be very sure they want to use this.

Time Zones
In this approach, the time is thought of as of a time at a certain time
zone. This might be interesting when the time settings should reflect a
certain time zone, eg. the host or the users connecting to it are to be
found in that certain time zone. The time zone offset to count the time
of access is taken from the Olson database. Therefore, even daylight
saving time is taken into account.

UTC
Sometimes the rules should apply for a certain time that is the same for
the whole globe throughout the year. That's why UTC should also be
supported.

Time Policies Storage
The time policies should be stored with each the HBAC rule that applies
such a policy. This extension is designed so that the LDAP schema does
not have to be changed.

The time policies are stored in the accessTime attribute of the HBAC
rule object. The policy is a string in a form of tuple: (anchor, time).
In this tuple, the anchor is one of "host", "utc" or Olson database time
zone name, such as "Europe/Prague". The meaning of the anchor follows
the time scenarios from this design. The time part of the policy tuple
is the time range of the policy.


It should be called "timezone", not "anchor". Anchor was something 
different (and I really regret calling it that, seeing how it got stuck).


Is there any real benefit in storing time zone with each access time? 
I think it should be good enough to have one time zone per HBAC rule, 
which would also reduce complexity of the whole thing.


I was thinking "host", "utc" - these are not timezones. Maybe it would 
be more accurate to call it an anchor or a handle.


The timezone should probably be stored just once in the rule, you're 
right. In the design, I was aiming for not changing the schema, but it 
probably makes no sense to keep it as it is.


The language of the time half of the time policy tuple is inspired by
the time part of Bind Rules of 389 Directory Server. Aside from the Bind
Rules keywords timeofday and dayofweek, it adds keywords dayofmonth,
weekofmonth, monthofyear and year. There are three operators: assignment
("="), range ("-") and union(","). Assignment operator is used after
each of the keywords above to specify the value of the certain keyword.
Range operator may be used for setting ranges of hours, days, months
etc. The final range includes both boundaries of the range set. A union
operator is used when the keyword should contain a union of values
rather than a range. Also

[Freeipa-devel] design review: Certificate Profiles

[Fraser Tweedale]

Hi everyone,

Please review my Certificate Profiles design proposal:
http://www.freeipa.org/page/V4/Certificate_Profiles

Let me know what is unclear, what needs expansion, and what is plain
wrong :)

The schema for storing multiple certificates for a principal is
still being discussed but I expect it will be agreed soon, and I
will add it to the document.

I am revising the sub-CAs design proposal and it will soon be
published for review as well.

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Splitting out ipaldap

[Petr Viktorin]

On 04/15/2015 08:30 AM, Jan Cholasta wrote:

Dne 14.4.2015 v 19:21 Petr Viktorin napsal(a):

On 04/14/2015 06:18 PM, Jan Cholasta wrote:

Dne 14.4.2015 v 17:50 Petr Viktorin napsal(a):

On 04/14/2015 05:22 PM, Jan Cholasta wrote:

Hi,

Dne 14.4.2015 v 16:38 Petr Viktorin napsal(a):

Hello!

As some of you know, I'm looking to help porting FreeIPA to Python 3.
One of the major dependencies holding this back is python-ldap, which
hasn't been ported yet. Some preliminary porting patches by Raphaël
Barrois [0] are ready and have been sent to the python-ldap list. The
python-ldap upstream has been very quiet about reviewing them so far,
but they're something for me to test against, and maybe improve.

To make the testing easier, I'd like to split out "ipaldap" to a
stand-alone package, and port it to Python 3 first.
This split will make it easier to test (since I don't have to port
all
of IPA), and being able to use our generic LDAP wrappers in non-IPA
projects could maybe also invite some community participation. Also,
ipaldap unit tests are somewhat lacking, so I'll help with that.
Packaging-wise, I want "ipaldap" to be on the same level as
"ipapython"
or "ipaserver"; additionally I want to release it on PyPI [1].


Note that I don't consider ipaldap API stable and don't want to put
any
effort in maintaining backward compatibility when something needs
to be
changed, so you might want to hold the PyPI release, or at least put a
big fat warning in some visible place.


If it's released early & often, it'll at least be visible to interested
people.
It would be nice to include a roadmap file saying what needs to change
before we start claiming API stability.


 From the top of my head, in no particular order:

   * High-level class for attribute values


+1


   * High-level classes for schema elements
   * Support different schema styles (LDAPv3, AD), or at least make it
possible


Here I'm inclined to just say the schema API isn't done.


It will affect how syntax mapping is done, so it depends on whether
syntax mapping is exposed or not. There are also some schema-related
LDAPClient methods (like get_allowed_attributes) which will be (re)moved
when the schema API is done.


I think putting warnings around the unfinished parts would work.


   * Some better way of doing "extended" operations (paged search, deref
search, etc.)
   * Support different transports (LDAP, local LDIF file), or at least
make it possible


Those two should be possible to add while keeping compatibility.


I don't think I want the paged_search argument of find_entries to be
supported.


Then I'll document it as unsupported.


My general plan is:
- Move ipapython.dn -> ipaldap.dn (keeping ipapython.dn importable
for
old scripts/plugins)


DNs are not strictly LDAP specific, so I would rather move
ipapython.dn
to a new ipautil package.


I'd rather not, at least until there's something that needs it (and
doesn't also depend on ipaldap). The scope of "ipautil" is far too
badly
defined for such a package to be useful.


IMO generic stuff should be in a package for generic stuff. I guess it
should originally have been ipapython, but it's too fused with ipalib
ATM, hence my proposal to use a new package.


No. Any vaguely defined collection of generic utilities needed in a
project is really a single-purpose package. Nobody likes pulling in a
bunch of unrelated stuff because of one particular thing they need, and
without a scope the amount of unnecessary stuff grows without bound.
I'd be OK with an "ipadn", if you can manage the overhead of a package.


IMO "ipadn" is just too specific. I guess we can use X.500 as scope,
since the basic types like DN or OID are defined in X.500, and put it in
"ipax500". Does that sound OK?


It might make sense conceptually, but do you have a use case? Some 
software that would want to depend on python-ldap (since that's what DNs 
depend on), but couldn't also bring in ipaldap?


I don't see the benefit, so I don't really want to do this myself.


- Move CIDict to ipaldap.cidict. For Python 3, I'd really like to
replace this with something based on collections.MutableMapping,
since
the semantics of subclassing "dict" aren't very well defined.


I have WIP which does just that.


Could you send it?


Not yet unfortunately, CIDict removal is actually just a side effect of
other changes, and it still needs a lot of work before it is sendable.


I was thinking the Python 3 boundary is a good point to switch, since
stuff will be breaking anyway. I can import the new one under py3, and
keep the old one for py2.



I'm a bit lost here, what do you mean by "new one" and "old one"?


Use the existing (old) CIDict under Python 2, and a new one based on 
MutableMapping for all Python 3 code.



--
Petr Viktorin

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] otptoken_yubikey, append CR by default and add a option for not doing so

[Jan Cholasta]

Dne 9.4.2015 v 15:11 Luc de Louw napsal(a):


On 04/09/2015 02:28 PM, Jan Cholasta wrote:

Let's say you now introduce --no-cr flag. What if we decide to change
the default to False? How would you then change the option/API?


You would have to add --cr flag.


That was the point - some clients would send "ct" flag, some "no_cr"
and there
would have to be special handling.


It is more flexible IMO to just use something like

--cr=TRUE|FALSE with TRUE being the default


I would say --append-cr=TRUE|FALSE with no default, meaning do not
add the flag
to the config at all.


I though the idea was to append the CR by default, i.e.
--append-cr=TRUE|FALSE
with TRUE being the default.



If you want to hardcode the default into the plugin, there is no benefit
in using Bool over Flag, because Flag is actually a Bool with hardcoded
default value.



I actually started with a bool, default=True. I had the problem that the
Default value was ignored, the value was None.

Changing the default behavior is IMHO bad anyway does not matter if Bool
or Flag.


+1



Please advise what is you wish to be implemented :-)


That depends. Is there a difference between "do not set APPEND_CR ticket 
flag" and "set APPEND_CR ticket flag to false"?




Thanks,

Luc



--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES] 0688-0689 Remove Editable DN and DN component classes

[Jan Cholasta]

Hi,

Dne 10.4.2015 v 15:58 Petr Viktorin napsal(a):

The attached patches remove EditableDN, EditableRDN and EditableAVA.
They depend on Petr Voborník's patch 811 (performance: faster DN
implementation).


Mutable DNs are not very useful. When creating them it is easier to work
with lists or generators, and needing to change DNs aside from
operations like `DN(new_rdn, original[1:])` is very rare -- I'd even say
theoretical.
Mutable DNs are not hashable, so they can't be used as dist keys.
Storing them as "keys" in other structures (e.g. in a LDAPEntry) is
dangerous -- it's hard to reason about outside modifications.

The first patch removes the last use of EditableDN. I could be convinced
it's not an improvement in elegance/readability, but I believe this is
the strongest case for EditableDN in IPA, and it doesn't justify keeping
it.


LGTM, but patch 688 needs to be rebased.

Honza

--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 408-423] ldap: Remove IPASimpleLDAPObject

[Jan Cholasta]

Dne 13.4.2015 v 14:57 Petr Viktorin napsal(a):

On 04/13/2015 08:12 AM, Jan Cholasta wrote:

Dne 9.4.2015 v 17:28 Petr Viktorin napsal(a):

On 04/08/2015 03:18 PM, Jan Cholasta wrote:

Hi,

the attached patches remove IPASimpleLDAPObject from ipaldap.

As a result, the one and only IPA LDAP API is the LDAPClient API.


This is definitely an improvement :)

0408: ACK  (woohoo!)
0409: ACK
0410:
I quite like the new __init__ signature, and the context manager
functionality.
Can you add a comment for the `object.__setattr__(self, '_conn', None)`
in _disconnect? It's a real eyesore.


Added.


0411: ACK
0412: Can _force_schema_updates be set already in __init__?


Unfortunately not. ldap2 is now used with different API instances, and
the current API instance is not available in __init__.

I'm working on an additional patch for
 to pass the API object to
plugins in their __init__ (because why do it somewhere else), which will
fix this.


0413: ACK
0414: ACK
0415: ACK
0416: I think you should show off the `with` statement support here.


Fixed.


0417: ... and here


Fixed.


0418: ACK
0419: ACK
0420: ACK
0421: ACK


Added a comment about ldap2's locking here as well.

Also moved LDAPClient.schema back to its original location to save some
lines in the patch.


0422: ACK, and good riddance


You missed 423 :-)


Ah, that comment was meant for 423 :)



ACK for all


Rebased and pushed to master: b48cfe05e9e6d9fa0d55c9c61f4ac23d8f5ee743

--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code