Re: [Freeipa-devel] [PATCH 0064-0065] ipa-dns-install offers IP addresses from resolv.conf as default forwarder

[Martin Babinsky]

On 11/11/2015 09:32 AM, Jan Cholasta wrote:

On 11.11.2015 09:27, Martin Babinsky wrote:

On 11/11/2015 08:12 AM, Jan Cholasta wrote:

On 10.11.2015 16:58, Petr Spacek wrote:

Hello,

Patch 64:
ipa-dns-install offer IP addresses from resolv.conf as default
forwarders

In non-interactive more option --auto-forwarders can be used to do the
same. --forward option can be used to supply additional IP addresses.

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


IMO it's perverse to add option which effectively means "use default
value" instead of actually using the value as default. This is
inconsistent with every other option and I don't see what makes
forwarders so special to require this.

NACK unless you have a strong justification for this.


Is it possible to use default_getter decorator to fetch defaults for the
'forwarders' knob from the resolver if it is avaliable like so (warning:
untested and possibly wrong)?


Yes, this is exactly how it should be used (although the exception
handling could be better).

That was just a quick example off the top of my head without much 
thought going into it.


Anyway, when running in interactive mode the installer can inform the 
user that he found these forwarders as defaults and prompt whether they 
shoud be used.


"""
@@ -160,20 +162,27 @@ class BaseServerCA(common.Installable, core.Group,
core.Composite):
  class BaseServerDNS(common.Installable, core.Group, core.Composite):
  description = "DNS"

  forwarders = Knob(
  (list, 'ip'), None,
  description=("Add a DNS forwarder. This option can be used
multiple "
   "times"),
  cli_name='forwarder',
  )

+@forwarders.default_getter
+def forwarders(self):
+try:
+return resolver.get_default_resolver().nameservers
+except Exception:
+return None
+
  no_forwarders = Knob(
  bool, False,
  description="Do not add any DNS forwarders, use root servers
instead",
  )

  reverse_zones = Knob(
  (list, str), [],
  description=("The reverse DNS zone to use. This option can be
used "

"""




Patch 65:
Remove global variable dns_forwarders from ipaserver.install.dns
It seems to me that the global thingy is not necessary, so I've ripped
it out.


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] Fix download message

[Petr Spacek]

On 10.11.2015 23:35, Francois Cami wrote:
> 
> Hi,
> 
> The "Do you want download the CA cert from" message in ipa-client-install 
> should be changed to "Do you want to download the CA cert from".
> As this is a single-line trivial fix I haven't opened a trac ticket. I will 
> do so if anyone feels this is necessary even in this case.

Obvious ACK.

-- 
Petr^2 Spacek

-- 
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] ipa-kra-install at domain level 0

[Oleg Fayans]

Hi all,

when running ipa-kra-install on a replica with domain level 0 and with 
replica file proivided, I get the following error:


$ ipa-kra-install -U -p  
/home/ofayans/ipatests/replica-info.gpg


Your system may be partly configured.
Run ipa-kra-install --uninstall to clean up.

Too many parameters provided. No replica file is required.
The ipa-kra-install command failed. See 
/var/log/ipaserver-kra-install.log for more information


-

However, when I issue the same command without the replica file, the 
installation starts, but fails in the middle, without any reasonable 
error message that I do need a replica file:


$ ipa-kra-install -p  -U

===
This program will setup Dogtag KRA for the FreeIPA Server.


Configuring KRA server (pki-tomcatd). Estimated time: 2 minutes 6 seconds
  [1/8]: configuring KRA instance
Failed to configure KRA instance: Command ''/usr/sbin/pkispawn' '-s' 
'KRA' '-f' '/tmp/tmpPQGCs0'' returned non-zero exit status 1
See the installation logs and the following files/directories for more 
information:

  /var/log/pki-ca-install.log
  /var/log/pki/pki-tomcat
  [error] RuntimeError: KRA configuration failed.

Your system may be partly configured.
Run ipa-kra-install --uninstall to clean up.

KRA configuration failed.
The ipa-kra-install command failed. See 
/var/log/ipaserver-kra-install.log for more information




Both logs are attached


--
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.
2015-11-11T08:20:24Z DEBUG Logging to /var/log/ipaserver-kra-install.log
2015-11-11T08:20:24Z DEBUG ipa-kra-install was invoked with arguments [] and 
options: {'verbose': False, 'no_host_dns': False, 'quiet': False, 'log_file': 
None, 'unattended': True, 'uninstall': False}
2015-11-11T08:20:24Z DEBUG IPA version 4.2.90.201511101521GITc339abb-0.fc22
2015-11-11T08:20:25Z DEBUG Created connection context.ldap2_139715914147472
2015-11-11T08:20:25Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'
2015-11-11T08:20:25Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'
2015-11-11T08:20:25Z DEBUG Loading Index file from 
'/var/lib/ipa/sysrestore/sysrestore.index'
2015-11-11T08:20:25Z DEBUG Trying to find certificate subject base in sysupgrade
2015-11-11T08:20:25Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysupgrade/sysupgrade.state'
2015-11-11T08:20:25Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysupgrade/sysupgrade.state'
2015-11-11T08:20:25Z DEBUG Found certificate subject base in sysupgrade: 
O=IDM.LAB.ENG.BRQ.REDHAT.COM
2015-11-11T08:20:25Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'
2015-11-11T08:20:25Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'
2015-11-11T08:20:25Z DEBUG Configuring KRA server (pki-tomcatd). Estimated 
time: 2 minutes 6 seconds
2015-11-11T08:20:25Z DEBUG   [1/8]: configuring KRA instance
2015-11-11T08:20:25Z DEBUG Contents of pkispawn configuration file 
(/tmp/tmpPQGCs0):
[KRA]
pki_security_domain_https_port = 443
pki_security_domain_password = 
pki_security_domain_user = admin
pki_issuing_ca_uri = https://vm-070.idm.lab.eng.brq.redhat.com:443
pki_enable_proxy = True
pki_restart_configured_instance = False
pki_backup_keys = True
pki_backup_password = 
pki_client_database_dir = /tmp/tmp-eb6gBl
pki_client_database_password = 
pki_client_database_purge = False
pki_client_pkcs12_password = 
pki_admin_name = admin
pki_admin_uid = admin
pki_admin_email = root@localhost
pki_admin_password = 
pki_admin_nickname = ipa-ca-agent
pki_admin_subject_dn = cn=ipa-ca-agent,O=IDM.LAB.ENG.BRQ.REDHAT.COM
pki_import_admin_cert = True
pki_admin_cert_file = /root/.dogtag/pki-tomcat/ca_admin.cert
pki_client_admin_cert_p12 = /root/ca-agent.p12
pki_ds_ldap_port = 389
pki_ds_password = 
pki_ds_base_dn = o=kra,o=ipaca
pki_ds_database = ipaca
pki_ds_create_new_db = False
pki_subsystem_subject_dn = cn=CA Subsystem,O=IDM.LAB.ENG.BRQ.REDHAT.COM
pki_ssl_server_subject_dn = 
cn=vm-070.idm.lab.eng.brq.redhat.com,O=IDM.LAB.ENG.BRQ.REDHAT.COM
pki_audit_signing_subject_dn = cn=KRA Audit,O=IDM.LAB.ENG.BRQ.REDHAT.COM
pki_transport_subject_dn = cn=KRA Transport 
Certificate,O=IDM.LAB.ENG.BRQ.REDHAT.COM
pki_storage_subject_dn = cn=KRA Storage Certificate,O=IDM.LAB.ENG.BRQ.REDHAT.COM
pki_subsystem_nickname = subsystemCert cert-pki-ca
pki_ssl_server_nickname = Server-Cert cert-pki-ca
pki_audit_signing_nickname = auditSigningCert cert-pki-kra
pki_transport_nickname = transportCert cert-pki-kra
pki_storage_nickname = storageCert cert-pki-kra
pki_share_db = True
pki_share_dbuser_dn = uid=pkidbuser,ou=people,o=ipaca


2015-11-11T08:20:25Z DEBUG Starting external process
2015-11-11T08:20:25Z DEBUG args='/usr/sbin/pkispawn' '-s' 'KRA' '-f' 
'/tmp/tmpPQGCs0'

Re: [Freeipa-devel] [PATCH 0082] remove Kerberos authenticators after service uninstall

[Martin Basti]

On 10.11.2015 17:36, Petr Spacek wrote:

On 4.11.2015 11:56, Martin Babinsky wrote:

On 10/22/2015 05:32 PM, Petr Spacek wrote:

On 21.10.2015 17:55, Martin Babinsky wrote:

On 10/13/2015 09:17 AM, Petr Spacek wrote:

On 12.10.2015 13:38, Martin Babinsky wrote:

each service possessing Kerberos keytab wiil now remove it and destroy any
associated credentials cache during its uninstall

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

BTW some time ago Simo proposed that we should remove caches and old keytabs
during *install* so problems caused by failing uninstallation will be
fixed on
repeated install. This is yet another step towards idempotent installer.

To me this makes more sense than doing so on uninstall. Does it make sense to
you, too?


Attaching updated patch that does cleanup also before each instance creation.
It is a bit ugly I admit, but I couldn't think of a better way to do it and
didn't want to poke into service/instance code more than neccesary.

NACK, but we are almost there!

* kdestroy -A is too aggressive and wipes root's keyring after each run of
ipa-*-install utils.

* There are some scattered leftovers of ipautil.run['kdestroy'...] in the
tree. Please get rid of them.

Thank you!


Attaching updated patch. It got lost somewhere in the list.

ACK, thank you for patience.



The patch needs rebase.

--
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] [Update]Time-Based Account Policies

[Stanislav Laznicka]

On 11/05/2015 06:17 PM, Petr Spacek wrote:

On 4.11.2015 15:20, Martin Basti wrote:


Hello,

we (Standa and I) had offline discussion and I proposed following idea:

1) create new entry in LDAP for "time rule" instead of adding the time rule
string directly into HBACRule.
This will allow to reuse time rules among various HBAC Rules (and maybe in
future with sudo rules, etc.)
HBACrule gets only reference to time rule entry stored in LDAP db.

Good idea! I can see time rule entry 'working hours in Brno office' which is
linked to relevant HBAC rules.
This seems like a good idea. However, it might be a bit messy to have 
even the least significant rules stored in separate objects. But I 
agree. It brings some questions, though.
Where would be a good spot to store these time rules? Should they be 
able to form groups? Should such an object be able to hold more time 
policies strings and exceptions, as it does now, or would it be better 
to set that in the respective HBAC rule?



2) Do not create a new time format, just reuse iCal (parts of iCal we need),
to store time rule in LDAP in "time rule" entry
(Or is possible to not store the values just as one string, we can use
different attributes to store separate values, iCal can be used as export and
import format)

I very much agree with re-using iCal! We have sufficient number of custom
parsers already ;-)

Speaking about custom LDAP format, I do not think that it is a good idea. It
would prevent us from using iCal parsers and generators and we would risk that
our custom LDAP format will not be flexible enough.

For these reasons I would go with 1 iCal string which can be fed into any
standard-compliant iCal library.
I was thinking long and hard about actually using the iCalendar format 
for this purpose, ever since the 'repeat' keyword was supposed to be 
included in the language. However, as I mentioned some time ago, the 
iCalendar format recurrences are OK when it comes to recurring events 
but I am not sure about them being very suitable for describing time 
policies.


Let me do a comparison of the options. I will take in question only the 
RRULE (and possibly PERIOD) part of the iCalendar format. Having the 
whole iCalendar format involved along with its parsing C library seemed 
to be a no-go for SSSD some 6 months ago and I can imagine such feelings 
persist.



Some iCalendar cons:

1) It is hard to represent continuous time of a day ranges
There does not seem to be an easy equivalent to e.g. 'timeofday= 
0730~1100, 1200~1615'. The easiest way to do this in iCalendar would be 
to have 2 rules of the form:


DTSTART: 19700101T073000
DTEND: 19700101T11
RRULE: FREQ=DAILY; INTERVAL=1

DTSTART: 19700101T12
DTEND: 19700101T161500
RRULE: FREQ=DAILY; INTERVAL=1

If you were setting some more difficult policy, there would have to be a 
lot of duplicity in each of such rules.


2) All iCalendar events have to have a fixed starting point
There must always be a check against the interval and the starting point.

3) There are no ranges
e.g. 'dayofyear=2-50, 100-125' would translate to

DTSTART:19700101T00
RRULE: FREQ=SECONDLY; INTERVAL=1; 
BYYEARDAY=2,3,4,5,6,7,8,9,10,11,...50,100,101,102,...


4) There is no way to list specific years in which the HBAC rule should 
apply.


5) COUNT parameter makes you generate all previous events before you are 
able to tell if the current one actually applies.
Imagine COUNT being a big number and an event that hardly ever happens. 
Imagine current time to fall into the last event.


6) The event descriptions are not so intuitive
There would probably have to be better conversion system at least for 
CLI when user wants to set time ranges of access allowed times so that 
we can consider it good UX.


I am not mentioning the lack of weekofmonth in iCal as I would rather 
drop it from the current solution, too.


On the other hand, there are also some big pros for iCalendar.

1) It is a standard. It behaves in a known and described manner.
2)  By proper use of BYSETPOS of RRULE, it is able to describe some 
specific situations, e.g. last workday of a month. This is not possible 
in the current language.
3) Easier setting of absolute time ranges using the PERIOD property 
(although this could probably be easily solved by a minor addition to 
the current solution).

4) A GUI for setting RRULEs already exists.

ad 4) The GUI, however, hides some of the features of the language (e.g. 
the mentioned BYSETPOS) and is not suitable for setting time policies as 
is. Try, for example, setting a policy "allow access from 7:00 to 16:00 
(no break of the interval as iCalendar does not know it) every first 
Monday through Friday of a month for the first half of every year".


In current language:

timeofday=0700~1600 dayofmonth=1~7 dayofweek=1~5 monthofyear=1~6

In iCalendar RRULE:

DTSTART: 19700101T07
DTEND: 19700101T16
RRULE: FREQ=YEARLY; 

Re: [Freeipa-devel] [PATCH 0064-0065] ipa-dns-install offers IP addresses from resolv.conf as default forwarder

[Martin Babinsky]

On 11/11/2015 08:12 AM, Jan Cholasta wrote:

On 10.11.2015 16:58, Petr Spacek wrote:

Hello,

Patch 64:
ipa-dns-install offer IP addresses from resolv.conf as default forwarders

In non-interactive more option --auto-forwarders can be used to do the
same. --forward option can be used to supply additional IP addresses.

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


IMO it's perverse to add option which effectively means "use default
value" instead of actually using the value as default. This is
inconsistent with every other option and I don't see what makes
forwarders so special to require this.

NACK unless you have a strong justification for this.

Is it possible to use default_getter decorator to fetch defaults for the 
'forwarders' knob from the resolver if it is avaliable like so (warning: 
untested and possibly wrong)?


"""
@@ -160,20 +162,27 @@ class BaseServerCA(common.Installable, core.Group, 
core.Composite):

 class BaseServerDNS(common.Installable, core.Group, core.Composite):
 description = "DNS"

 forwarders = Knob(
 (list, 'ip'), None,
 description=("Add a DNS forwarder. This option can be used 
multiple "

  "times"),
 cli_name='forwarder',
 )

+@forwarders.default_getter
+def forwarders(self):
+try:
+return resolver.get_default_resolver().nameservers
+except Exception:
+return None
+
 no_forwarders = Knob(
 bool, False,
 description="Do not add any DNS forwarders, use root servers 
instead",

 )

 reverse_zones = Knob(
 (list, str), [],
 description=("The reverse DNS zone to use. This option can be 
used "


"""




Patch 65:
Remove global variable dns_forwarders from ipaserver.install.dns
It seems to me that the global thingy is not necessary, so I've ripped
it out.


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] Fix download message

[Martin Basti]

On 11.11.2015 09:46, Petr Spacek wrote:

On 10.11.2015 23:35, Francois Cami wrote:

Hi,

The "Do you want download the CA cert from" message in ipa-client-install should be 
changed to "Do you want to download the CA cert from".
As this is a single-line trivial fix I haven't opened a trac ticket. I will do 
so if anyone feels this is necessary even in this case.

Obvious ACK.


Pushed to master: 9f3e8943a7c0be1ba6ae8738f8f88420a098c276

--
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 0082] remove Kerberos authenticators after service uninstall

[Martin Babinsky]

On 11/11/2015 10:36 AM, Martin Basti wrote:



On 10.11.2015 17:36, Petr Spacek wrote:

On 4.11.2015 11:56, Martin Babinsky wrote:

On 10/22/2015 05:32 PM, Petr Spacek wrote:

On 21.10.2015 17:55, Martin Babinsky wrote:

On 10/13/2015 09:17 AM, Petr Spacek wrote:

On 12.10.2015 13:38, Martin Babinsky wrote:

each service possessing Kerberos keytab wiil now remove it and
destroy any
associated credentials cache during its uninstall

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

BTW some time ago Simo proposed that we should remove caches and
old keytabs
during *install* so problems caused by failing uninstallation will be
fixed on
repeated install. This is yet another step towards idempotent
installer.

To me this makes more sense than doing so on uninstall. Does it
make sense to
you, too?


Attaching updated patch that does cleanup also before each instance
creation.
It is a bit ugly I admit, but I couldn't think of a better way to
do it and
didn't want to poke into service/instance code more than neccesary.

NACK, but we are almost there!

* kdestroy -A is too aggressive and wipes root's keyring after each
run of
ipa-*-install utils.

* There are some scattered leftovers of ipautil.run['kdestroy'...]
in the
tree. Please get rid of them.

Thank you!


Attaching updated patch. It got lost somewhere in the list.

ACK, thank you for patience.



The patch needs rebase.

Rebased patch attached.

--
Martin^3 Babinsky
From a6615f4b0aa44056560149bcad059dba2929ed4f Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Fri, 9 Oct 2015 18:08:38 +0200
Subject: [PATCH] remove Kerberos authenticators when installing/uninstalling
 service instance

each service possessing Kerberos keytab/ccache will now perform their removal
before service principal creation and during service uninstall

https://fedorahosted.org/freeipa/ticket/5243
---
 ipaserver/install/adtrustinstance.py |  4 ++--
 ipaserver/install/bindinstance.py|  3 +++
 ipaserver/install/dnskeysyncinstance.py  |  3 +++
 ipaserver/install/dsinstance.py  |  4 ++--
 ipaserver/install/httpinstance.py| 10 +
 ipaserver/install/installutils.py| 37 
 ipaserver/install/odsexporterinstance.py |  3 +++
 7 files changed, 56 insertions(+), 8 deletions(-)

diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py
index b8f1b770a574fdf80b5b40439d6cd9d83b094b68..813d48e50f179f936d7811c3c86b28fa98f24a50 100644
--- a/ipaserver/install/adtrustinstance.py
+++ b/ipaserver/install/adtrustinstance.py
@@ -540,6 +540,7 @@ class ADTRUSTInstance(service.Service):
 self.print_msg("Cannot add CIFS service: %s" % e)
 
 self.clean_samba_keytab()
+installutils.remove_ccache(paths.KRB5CC_SAMBA)
 
 try:
 ipautil.run(["ipa-getkeytab", "--server", self.fqdn,
@@ -937,8 +938,7 @@ class ADTRUSTInstance(service.Service):
 self.print_msg('WARNING: ' + str(e))
 
 # Remove samba's credentials cache
-krb5cc_samba = paths.KRB5CC_SAMBA
-installutils.remove_file(krb5cc_samba)
+installutils.remove_ccache(ccache_path=paths.KRB5CC_SAMBA)
 
 # Remove samba's configuration file
 installutils.remove_file(self.smb_conf)
diff --git a/ipaserver/install/bindinstance.py b/ipaserver/install/bindinstance.py
index 1d98926b2769c8f314af06e7b0ee2513774f950b..6bfde83de600df43e3430299100565e554a80583 100644
--- a/ipaserver/install/bindinstance.py
+++ b/ipaserver/install/bindinstance.py
@@ -1203,3 +1203,6 @@ class BindInstance(service.Service):
 
 if named_regular_running:
 self.named_regular.start()
+
+installutils.remove_keytab(paths.NAMED_KEYTAB)
+installutils.remove_ccache(run_as='named')
diff --git a/ipaserver/install/dnskeysyncinstance.py b/ipaserver/install/dnskeysyncinstance.py
index 68130c92558a4feb8d08fa826dbf6333d4461d1f..b2ccc027469a352c815963abfd0c0a61dd37297f 100644
--- a/ipaserver/install/dnskeysyncinstance.py
+++ b/ipaserver/install/dnskeysyncinstance.py
@@ -417,6 +417,7 @@ class DNSKeySyncInstance(service.Service):
 
 def __setup_principal(self):
 assert self.ods_gid is not None
+installutils.remove_keytab(paths.IPA_DNSKEYSYNCD_KEYTAB)
 dnssynckey_principal = "ipa-dnskeysyncd/" + self.fqdn + "@" + self.realm
 installutils.kadmin_addprinc(dnssynckey_principal)
 
@@ -497,3 +498,5 @@ class DNSKeySyncInstance(service.Service):
 os.remove(paths.DNSSEC_SOFTHSM_PIN)
 except Exception:
 pass
+
+installutils.remove_keytab(paths.IPA_DNSKEYSYNCD_KEYTAB)
diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py
index 15b23a8704091fbcf54e5be52562f6da2eeb1d73..7bdcaea31dcdf593d1de3b98a2ddfb926c2ea990 100644
--- a/ipaserver/install/dsinstance.py
+++ b/ipaserver/install/dsinstance.py
@@ -937,8 +937,8 @@ class DsInstance(service.Service):
 

Re: [Freeipa-devel] [PATCH 0094] Fix bogus error message in choice-type installer options

[Martin Basti]

On 10.11.2015 11:01, Martin Basti wrote:



On 09.11.2015 09:55, Martin Babinsky wrote:

On 11/09/2015 07:15 AM, Jan Cholasta wrote:

On 6.11.2015 17:02, Martin Babinsky wrote:

On 11/06/2015 10:30 AM, Martin Babinsky wrote:

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





Attaching updated patch.


NACK, the first patch was better, there should be quotes around the 
values.




Attaching updated patch.


ACK


Pushed to:
master: b6a2a1cfd2d811e4df77e5b90324d1453dab4b18
ipa-4-2: dc0f2d1fec8bdbe5cccebb1d3dfe403ad994e6f6

--
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] ca-less tests updated - POC

[Oleg Fayans]

Hi guys,

Is there a chance these patches might be reviewed again this week?

On 11/06/2015 02:04 PM, Oleg Fayans wrote:

Hi Jan,

On 11/06/2015 09:01 AM, Jan Cholasta wrote:

Actually it might be better to keep them, but fix them to expect
ipa-server-certinstall to success.


Done. Updated patch attached.
Also in the patch 0013 I removed a trailing whitespace which caused lint
to complain

Now with domain level 0 the test output looks like this:

[11:40:51]ofayans@vm-076:~]$ ipa-run-tests test_integration/test_caless.py

test session starts
=

platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.6.4
plugins: multihost, sourceorder
collected 88 items

test_integration/test_caless.py
..xx..ss...xxssxx..ss...


= 76
passed, 6 skipped, 6 xfailed in 7871.10 seconds
=




On 6.11.2015 08:47, Jan Cholasta wrote:

Hi Oleg,

I think you can just remove
TestCertinstall.test_{http,ds}_intermediate_ca, the certificates are
imported correctly in this case and I didn't see anything break.

Honza

On 5.11.2015 20:20, Oleg Fayans wrote:

Patch 0014 updated and passes lint

On 11/05/2015 03:41 PM, Oleg Fayans wrote:

Wait a bit, the patch has problems with pylint: it does not build :)
The updated version (without the setupmaster nonsense) is being tested
now.

On 11/05/2015 08:45 AM, Oleg Fayans wrote:

Hi Jan,

Could you take a look at these, whenever you are free?

On 10/30/2015 02:57 PM, Oleg Fayans wrote:

Hi,

The following patches contain updates to ca-less integration tests.
It's still a proof of concept: 2 tests still fail seemingly due to
the
change in target system logic (marked as xfail with "ask jcholast
comment")

The test output looks like this:

$ ipa-run-tests test_integration/test_caless.py --pdb







test session starts
=







platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.6.4
plugins: multihost, sourceorder
collected 88 items

test_integration/test_caless.py
..xx..sssss.ss.xx..ssxx.









53

passed, 29 skipped, 6 xfailed in 5620.17 seconds
=


Numerous skips correspond to the tests related to
ipa-replica-prepare
(unsupported under domain level 1)























--
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.

--
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 0082] remove Kerberos authenticators after service uninstall

[Martin Basti]

On 11.11.2015 11:50, Petr Spacek wrote:

On 11.11.2015 10:49, Martin Babinsky wrote:

On 11/11/2015 10:36 AM, Martin Basti wrote:


On 10.11.2015 17:36, Petr Spacek wrote:

On 4.11.2015 11:56, Martin Babinsky wrote:

On 10/22/2015 05:32 PM, Petr Spacek wrote:

On 21.10.2015 17:55, Martin Babinsky wrote:

On 10/13/2015 09:17 AM, Petr Spacek wrote:

On 12.10.2015 13:38, Martin Babinsky wrote:

each service possessing Kerberos keytab wiil now remove it and
destroy any
associated credentials cache during its uninstall

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

BTW some time ago Simo proposed that we should remove caches and
old keytabs
during *install* so problems caused by failing uninstallation will be
fixed on
repeated install. This is yet another step towards idempotent
installer.

To me this makes more sense than doing so on uninstall. Does it
make sense to
you, too?


Attaching updated patch that does cleanup also before each instance
creation.
It is a bit ugly I admit, but I couldn't think of a better way to
do it and
didn't want to poke into service/instance code more than neccesary.

NACK, but we are almost there!

* kdestroy -A is too aggressive and wipes root's keyring after each
run of
ipa-*-install utils.

* There are some scattered leftovers of ipautil.run['kdestroy'...]
in the
tree. Please get rid of them.

Thank you!


Attaching updated patch. It got lost somewhere in the list.

ACK, thank you for patience.


The patch needs rebase.

Rebased patch attached.

I should have told you :-) Anyway, re-ACK.


Pushed to master: 117bf5af8c5ffa63dc380cb331843396ce8b8286

--
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] ipa-kra-install at domain level 0

[Martin Basti]

On 11.11.2015 15:43, Oleg Fayans wrote:

Hi Martin,


On 11/11/2015 03:32 PM, Martin Basti wrote:



On 11.11.2015 09:26, Oleg Fayans wrote:

Hi all,

when running ipa-kra-install on a replica with domain level 0 and with
replica file proivided, I get the following error:

$ ipa-kra-install -U -p 
/home/ofayans/ipatests/replica-info.gpg

Your system may be partly configured.
Run ipa-kra-install --uninstall to clean up.

Too many parameters provided. No replica file is required.
The ipa-kra-install command failed. See
/var/log/ipaserver-kra-install.log for more information

-

However, when I issue the same command without the replica file, the
installation starts, but fails in the middle, without any reasonable
error message that I do need a replica file:

$ ipa-kra-install -p  -U

===
This program will setup Dogtag KRA for the FreeIPA Server.


Configuring KRA server (pki-tomcatd). Estimated time: 2 minutes 6 
seconds

  [1/8]: configuring KRA instance
Failed to configure KRA instance: Command ''/usr/sbin/pkispawn' '-s'
'KRA' '-f' '/tmp/tmpPQGCs0'' returned non-zero exit status 1
See the installation logs and the following files/directories for more
information:
  /var/log/pki-ca-install.log
  /var/log/pki/pki-tomcat
  [error] RuntimeError: KRA configuration failed.

Your system may be partly configured.
Run ipa-kra-install --uninstall to clean up.

KRA configuration failed.
The ipa-kra-install command failed. See
/var/log/ipaserver-kra-install.log for more information



Both logs are attached



Just to be sure, do you have KRA installed on master?



Great catch, actually I did not. So is this the reason? Should not we 
provide a more meaningful error message in this case?



There is right error: "No replica file is required"

However IIRC in this case, ipa-kra-install without replica file should 
work, so this is the bug.









--
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 0095] remove an unneccesary check from IPA server uninstaller

[Jan Cholasta]

On 11.11.2015 16:24, Martin Babinsky wrote:

This check for a deprecated option added in
  https://fedorahosted.org/freeipa/ticket/4516 and somehow ended up in
both install_check and uninstall_check during installer refactoring.

The placement in the latter is rather pointless so this patch removes it.


ACK.

--
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] ipa-kra-install at domain level 0

[Oleg Fayans]

Hi Martin,


On 11/11/2015 03:32 PM, Martin Basti wrote:



On 11.11.2015 09:26, Oleg Fayans wrote:

Hi all,

when running ipa-kra-install on a replica with domain level 0 and with
replica file proivided, I get the following error:

$ ipa-kra-install -U -p 
/home/ofayans/ipatests/replica-info.gpg

Your system may be partly configured.
Run ipa-kra-install --uninstall to clean up.

Too many parameters provided. No replica file is required.
The ipa-kra-install command failed. See
/var/log/ipaserver-kra-install.log for more information

-

However, when I issue the same command without the replica file, the
installation starts, but fails in the middle, without any reasonable
error message that I do need a replica file:

$ ipa-kra-install -p  -U

===
This program will setup Dogtag KRA for the FreeIPA Server.


Configuring KRA server (pki-tomcatd). Estimated time: 2 minutes 6 seconds
  [1/8]: configuring KRA instance
Failed to configure KRA instance: Command ''/usr/sbin/pkispawn' '-s'
'KRA' '-f' '/tmp/tmpPQGCs0'' returned non-zero exit status 1
See the installation logs and the following files/directories for more
information:
  /var/log/pki-ca-install.log
  /var/log/pki/pki-tomcat
  [error] RuntimeError: KRA configuration failed.

Your system may be partly configured.
Run ipa-kra-install --uninstall to clean up.

KRA configuration failed.
The ipa-kra-install command failed. See
/var/log/ipaserver-kra-install.log for more information



Both logs are attached



Just to be sure, do you have KRA installed on master?



Great catch, actually I did not. So is this the reason? Should not we 
provide a more meaningful error message in this case?









--
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.

--
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 0095] remove an unneccesary check from IPA server uninstaller

[Martin Babinsky]

This check for a deprecated option added in
 https://fedorahosted.org/freeipa/ticket/4516 and somehow ended up in 
both install_check and uninstall_check during installer refactoring.


The placement in the latter is rather pointless so this patch removes it.

--
Martin^3 Babinsky
From 9835b6cd043db968040f6ddd1bfa41a76ca29ad0 Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Wed, 11 Nov 2015 15:34:32 +0100
Subject: [PATCH] remove an unneccesary check from IPA server uninstaller

---
 ipaserver/install/server/install.py | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/ipaserver/install/server/install.py b/ipaserver/install/server/install.py
index 16539892dcffb3ad0e95aab0c5a3d85f3bb44c48..6629e8ec12f50c83a691dcd60e2cbf1125598fcb 100644
--- a/ipaserver/install/server/install.py
+++ b/ipaserver/install/server/install.py
@@ -959,13 +959,6 @@ def uninstall_check(installer):
 
 tasks.check_selinux_status()
 
-if options.master_password:
-msg = ("WARNING:\noption '-P/--master-password' is deprecated. "
-   "KDC master password of sufficient strength is autogenerated "
-   "during IPA server installation and should not be set "
-   "manually.")
-print(textwrap.fill(msg, width=79, replace_whitespace=False))
-
 installer._installation_cleanup = False
 
 if not is_ipa_configured():
-- 
2.4.3

-- 
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 0064-0065] ipa-dns-install offers IP addresses from resolv.conf as default forwarder

[Jan Cholasta]

On 11.11.2015 09:27, Martin Babinsky wrote:

On 11/11/2015 08:12 AM, Jan Cholasta wrote:

On 10.11.2015 16:58, Petr Spacek wrote:

Hello,

Patch 64:
ipa-dns-install offer IP addresses from resolv.conf as default
forwarders

In non-interactive more option --auto-forwarders can be used to do the
same. --forward option can be used to supply additional IP addresses.

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


IMO it's perverse to add option which effectively means "use default
value" instead of actually using the value as default. This is
inconsistent with every other option and I don't see what makes
forwarders so special to require this.

NACK unless you have a strong justification for this.


Is it possible to use default_getter decorator to fetch defaults for the
'forwarders' knob from the resolver if it is avaliable like so (warning:
untested and possibly wrong)?


Yes, this is exactly how it should be used (although the exception 
handling could be better).




"""
@@ -160,20 +162,27 @@ class BaseServerCA(common.Installable, core.Group,
core.Composite):
  class BaseServerDNS(common.Installable, core.Group, core.Composite):
  description = "DNS"

  forwarders = Knob(
  (list, 'ip'), None,
  description=("Add a DNS forwarder. This option can be used
multiple "
   "times"),
  cli_name='forwarder',
  )

+@forwarders.default_getter
+def forwarders(self):
+try:
+return resolver.get_default_resolver().nameservers
+except Exception:
+return None
+
  no_forwarders = Knob(
  bool, False,
  description="Do not add any DNS forwarders, use root servers
instead",
  )

  reverse_zones = Knob(
  (list, str), [],
  description=("The reverse DNS zone to use. This option can be
used "

"""




Patch 65:
Remove global variable dns_forwarders from ipaserver.install.dns
It seems to me that the global thingy is not necessary, so I've ripped
it out.


ACK.







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

[Freeipa-devel] [PATCH 0384] ipa-client-automount: Leverage IPAChangeConf to configure the idmapd

[Tomas Babej]

Hi,

Simple regexp substitution caused that the domain directive fell under
an inapprorpiate section, if the domain directive was not present. Hence
the idmapd.conf file was not properly parsed.

Use IPAChangeConf to put the directive in its correct place even if it
the domain directive is missing.

https://fedorahosted.org/freeipa/ticket/5069
From 220fc10dd3ba5454f6bd28fa4d85149a4e5b8f92 Mon Sep 17 00:00:00 2001
From: Tomas Babej 
Date: Wed, 11 Nov 2015 14:23:43 +0100
Subject: [PATCH] ipachangeconf: Add ability to preserve section case

The IPAChangeConf normallizes section names to lower case. There are
cases where this behaviour might not be desirable, so provide a way to
opt out.

https://fedorahosted.org/freeipa/ticket/5069
---
 ipa-client/ipaclient/ipachangeconf.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/ipa-client/ipaclient/ipachangeconf.py b/ipa-client/ipaclient/ipachangeconf.py
index 3d485adbd6bddc7371874dea6f39c48ea2c49c44..e257c82228a56ad02284dce4f799a216c9648feb 100644
--- a/ipa-client/ipaclient/ipachangeconf.py
+++ b/ipa-client/ipaclient/ipachangeconf.py
@@ -63,6 +63,7 @@ class IPAChangeConf:
 self.deol = self.eol[0]
 self.sectnamdel = ("[", "]")
 self.subsectdel = ("{", "}")
+self.case_insensitive_sections = True
 
 def setProgName(self, name):
 self.progname = name
@@ -114,7 +115,9 @@ class IPAChangeConf:
 return False
 
 def matchSection(self, line):
-cl = "".join(line.strip().split()).lower()
+cl = "".join(line.strip().split())
+cl = cl.lower() if self.case_insensitive_sections else cl
+
 if len(self.sectnamdel) != 2:
 return False
 if not cl.startswith(self.sectnamdel[0]):
-- 
2.4.3

From 3bfc005eb1ca74a0508a8340012347b8ddce7681 Mon Sep 17 00:00:00 2001
From: Tomas Babej 
Date: Wed, 11 Nov 2015 14:28:46 +0100
Subject: [PATCH] ipa-client-automount: Leverage IPAChangeConf to configure the
 domain for idmapd

Simple regexp substitution caused that the domain directive fell under
an inapprorpiate section, if the domain directive was not present. Hence
the idmapd.conf file was not properly parsed.

Use IPAChangeConf to put the directive in its correct place even if it
the domain directive is missing.

https://fedorahosted.org/freeipa/ticket/5069
---
 ipa-client/ipa-install/ipa-client-automount | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/ipa-client/ipa-install/ipa-client-automount b/ipa-client/ipa-install/ipa-client-automount
index 54906e5b2c37d555bcd5e6f0dd4fae4b5bd0c917..1d04287722c3a0646c0fcc51f3b2c5b7d0cc80df 100755
--- a/ipa-client/ipa-install/ipa-client-automount
+++ b/ipa-client/ipa-install/ipa-client-automount
@@ -318,11 +318,21 @@ def configure_nfs(fstore, statestore):
 
 print("Configured %s" % paths.SYSCONFIG_NFS)
 
-replacevars = {
-'Domain': api.env.domain,
-}
-ipautil.backup_config_and_replace_variables(fstore,
-paths.IDMAPD_CONF, replacevars=replacevars)
+# Prepare the changes
+# We need to use IPAChangeConf as simple regexp substitution
+# does not cut it here
+conf = ipachangeconf.IPAChangeConf("IPA automount installer")
+conf.case_insensitive_sections = False
+conf.setOptionAssignment(" = ")
+conf.setSectionNameDelimiters(("[", "]"))
+
+changes = [conf.setOption('Domain', api.env.domain)]
+section_with_changes = [conf.setSection('General', changes)]
+
+# Backup the file and apply the changes
+fstore.backup_file(paths.IDMAPD_CONF)
+conf.changeConf(paths.IDMAPD_CONF, section_with_changes)
+
 tasks.restore_context(paths.IDMAPD_CONF)
 
 print("Configured %s" % paths.IDMAPD_CONF)
-- 
2.4.3

-- 
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] enable pem=True in export_pem_cert function

[Tomas Babej]

On 11/11/2015 02:03 AM, Niranjan wrote:
> Niranjan wrote:
>> Tomas Babej wrote:
>>> On 10/26/2015 08:59 PM, Niranjan wrote:
 Greetings,

 export_pem_cert function from ipapython/certdb  should export the 
 certificate
 in pem format but instead exports the cert in der format as it doesn't 
 enable pem=True.

 This patch specifies pem=True for export_pem_cert function

 Regards
 Niranjan
>>>
>>> Hi,
>>>
>>> the patch looks good, however, I'm curious as to how did you find this
>>> bug? Does it affect anything?
>> I am part of the CS(dogtag) QE team, and as part of CS Automation, i am 
>> relying 
>> on some generic functions provided by ipapython. While using those functions
>> for our automation, I found it. 
>>>
>>> It seems to me that this part of the code is a dead branch which should
>>> be removed.
>> I did not look further ipapython, so i am not aware where else 
>> export_pem_cert
>> is being used, but i would like the functions in certdb.py be available.
>>>
>>> $ git grep export_pem_cert
>>> ipapython/certdb.py:def export_pem_cert(self, nickname, location):
>>> ipaserver/install/certs.py:def export_pem_cert(self, nickname,
>>> ipaserver/install/certs.py:return self.nssdb.export_pem_ce..
> 
> Any update on this.
> 

Sure, I will push the patch. However, I am not sure how stable the
ipapython internal API is, so be watch out for changes if ipapython
package is upgraded.

ACK.

Pushed to master: 0152d16820e527060be3363f590c49544b51b710

-- 
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] [Update]Time-Based Account Policies

[Martin Basti]

Comments inline
Martin^2

On 11.11.2015 09:24, Stanislav Laznicka wrote:

On 11/05/2015 06:17 PM, Petr Spacek wrote:

On 4.11.2015 15:20, Martin Basti wrote:


Hello,

we (Standa and I) had offline discussion and I proposed following idea:

1) create new entry in LDAP for "time rule" instead of adding the time rule
string directly into HBACRule.
This will allow to reuse time rules among various HBAC Rules (and maybe in
future with sudo rules, etc.)
HBACrule gets only reference to time rule entry stored in LDAP db.

Good idea! I can see time rule entry 'working hours in Brno office' which is
linked to relevant HBAC rules.
This seems like a good idea. However, it might be a bit messy to have 
even the least significant rules stored in separate objects. But I 
agree. It brings some questions, though.
Imo to have separate entry for time rule is cleaner than add it directly 
to HBAC rule.



Where would be a good spot to store these time rules?
As I originally thought that we can share time rules between HBAC, SUDO 
and everything else, I couldn't be wrong more.


Example: HBAC admin have permission to edit HBAC rule, but doesn't have 
permission to edit SUDO rule. The HBAC admin should be able to edit time 
rules for HBAC rules, and cannot be able to edit time rules of SUDO 
rules. Thus time rules must be separated between HBAC, SUDO and others, 
and privilege that give the permission to modify HBAC rule, must give 
permission to modify only HBAC time rules.


I suggest to add HBAC time rules to HBAC container.


Should they be able to form groups?

I think to allow multiple time rules per HBAC rule is enough.
Should such an object be able to hold more time policies strings and 
exceptions, as it does now, or would it be better to set that in the 
respective HBAC rule?
Can it be one time policy per entry? Do you expect that users may need a 
many complicated rules?
Generally to have an object time policy that consist of time rule 
objects which are in fact the iCal string is good idea, but is it worth 
it? We should not overengineering it.



2) Do not create a new time format, just reuse iCal (parts of iCal we need),
to store time rule in LDAP in "time rule" entry
(Or is possible to not store the values just as one string, we can use
different attributes to store separate values, iCal can be used as export and
import format)

I very much agree with re-using iCal! We have sufficient number of custom
parsers already ;-)

Speaking about custom LDAP format, I do not think that it is a good idea. It
would prevent us from using iCal parsers and generators and we would risk that
our custom LDAP format will not be flexible enough.

For these reasons I would go with 1 iCal string which can be fed into any
standard-compliant iCal library.
I was thinking long and hard about actually using the iCalendar format 
for this purpose, ever since the 'repeat' keyword was supposed to be 
included in the language. However, as I mentioned some time ago, the 
iCalendar format recurrences are OK when it comes to recurring events 
but I am not sure about them being very suitable for describing time 
policies.


Let me do a comparison of the options. I will take in question only 
the RRULE (and possibly PERIOD) part of the iCalendar format. Having 
the whole iCalendar format involved along with its parsing C library 
seemed to be a no-go for SSSD some 6 months ago and I can imagine such 
feelings persist.



Some iCalendar cons:

1) It is hard to represent continuous time of a day ranges
There does not seem to be an easy equivalent to e.g. 'timeofday= 
0730~1100, 1200~1615'. The easiest way to do this in iCalendar would 
be to have 2 rules of the form:


DTSTART: 19700101T073000
DTEND: 19700101T11
RRULE: FREQ=DAILY; INTERVAL=1

DTSTART: 19700101T12
DTEND: 19700101T161500
RRULE: FREQ=DAILY; INTERVAL=1

If you were setting some more difficult policy, there would have to be 
a lot of duplicity in each of such rules.
Is this common usage? I personally cannot imagine reason to using more 
than max 2 time periods per day.


2) All iCalendar events have to have a fixed starting point
There must always be a check against the interval and the starting point.

MIN, or date of creation can be used as default


3) There are no ranges
e.g. 'dayofyear=2-50, 100-125' would translate to

DTSTART:19700101T00
RRULE: FREQ=SECONDLY; INTERVAL=1; 
BYYEARDAY=2,3,4,5,6,7,8,9,10,11,...50,100,101,102,...




4) There is no way to list specific years in which the HBAC rule 
should apply.

is this a real concern?


5) COUNT parameter makes you generate all previous events before you 
are able to tell if the current one actually applies.
Imagine COUNT being a big number and an event that hardly ever 
happens. Imagine current time to fall into the last event.
If we want to have the iCal support, we must live with this, but we can 
force user to use end date in CLI/webUI (in other words disable COUNT as 
option in 

Re: [Freeipa-devel] [PATCH 0066] Remove unused constant NEW_MASTER_MARK from ipaserver.install.dn

[Tomas Babej]

On 11/10/2015 05:04 PM, Petr Spacek wrote:
> Hello,
> 
> Remove unused constant NEW_MASTER_MARK from ipaserver.install.dns.
> 
> 
> 

ACK.

Pushed to master: 0043065598f8e7767b45922806f14ed17a18508c

-- 
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] ipa-kra-install at domain level 0

[Martin Basti]

On 11.11.2015 09:26, Oleg Fayans wrote:

Hi all,

when running ipa-kra-install on a replica with domain level 0 and with 
replica file proivided, I get the following error:


$ ipa-kra-install -U -p  
/home/ofayans/ipatests/replica-info.gpg


Your system may be partly configured.
Run ipa-kra-install --uninstall to clean up.

Too many parameters provided. No replica file is required.
The ipa-kra-install command failed. See 
/var/log/ipaserver-kra-install.log for more information


-

However, when I issue the same command without the replica file, the 
installation starts, but fails in the middle, without any reasonable 
error message that I do need a replica file:


$ ipa-kra-install -p  -U

===
This program will setup Dogtag KRA for the FreeIPA Server.


Configuring KRA server (pki-tomcatd). Estimated time: 2 minutes 6 seconds
  [1/8]: configuring KRA instance
Failed to configure KRA instance: Command ''/usr/sbin/pkispawn' '-s' 
'KRA' '-f' '/tmp/tmpPQGCs0'' returned non-zero exit status 1
See the installation logs and the following files/directories for more 
information:

  /var/log/pki-ca-install.log
  /var/log/pki/pki-tomcat
  [error] RuntimeError: KRA configuration failed.

Your system may be partly configured.
Run ipa-kra-install --uninstall to clean up.

KRA configuration failed.
The ipa-kra-install command failed. See 
/var/log/ipaserver-kra-install.log for more information




Both logs are attached



Just to be sure, do you have KRA installed on master?






-- 
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 0064-0065] ipa-dns-install offers IP addresses from resolv.conf as default forwarder

[Petr Spacek]

On 11.11.2015 09:36, Martin Babinsky wrote:
> On 11/11/2015 09:32 AM, Jan Cholasta wrote:
>> On 11.11.2015 09:27, Martin Babinsky wrote:
>>> On 11/11/2015 08:12 AM, Jan Cholasta wrote:
 On 10.11.2015 16:58, Petr Spacek wrote:
> Hello,
>
> Patch 64:
> ipa-dns-install offer IP addresses from resolv.conf as default
> forwarders
>
> In non-interactive more option --auto-forwarders can be used to do the
> same. --forward option can be used to supply additional IP addresses.
>
> https://fedorahosted.org/freeipa/ticket/5438

 IMO it's perverse to add option which effectively means "use default
 value" instead of actually using the value as default. This is
 inconsistent with every other option and I don't see what makes
 forwarders so special to require this.

 NACK unless you have a strong justification for this.

Motivation:
/etc/resolv.conf holds nearest DNS servers. On the other hand, you want to
have backup forwarder which may not be local but could work even if local ones
fail.

Option --default-forwarders reads list of "local" servers from resolv.conf and
--forwarder option allows you to add additional IP addresses to it.

So your Ansible script can contain call like:
ipa-server-install --setup-dns --default-forwarder
--forwarder=
and you do not need to worry about mapping sites to nearest servers etc.

>>> Is it possible to use default_getter decorator to fetch defaults for the
>>> 'forwarders' knob from the resolver if it is avaliable like so (warning:
>>> untested and possibly wrong)?
>>
>> Yes, this is exactly how it should be used (although the exception
>> handling could be better).
>>
> That was just a quick example off the top of my head without much thought
> going into it.
> 
> Anyway, when running in interactive mode the installer can inform the user
> that he found these forwarders as defaults and prompt whether they shoud be 
> used.

After discussion in person we decided to not use default_getter decorator
because that would change current behavior in an unexpected way.

Original option --auto-forwarders was renamed to --default-forwarders because
it sounds nicer :-D

> Patch 65:
> Remove global variable dns_forwarders from ipaserver.install.dns
> It seems to me that the global thingy is not necessary, so I've ripped
> it out.

 ACK.

Rebased version of patch 65 is attached.

-- 
Petr^2 Spacek
From ad97c62d747eed85505d5a2a54bdca1cad531d36 Mon Sep 17 00:00:00 2001
From: Petr Spacek 
Date: Tue, 10 Nov 2015 11:22:43 +0100
Subject: [PATCH] ipa-dns-install offer IP addresses from resolv.conf as
 default forwarders

In non-interactive more option --auto-forwarders can be used to do the
same. --forward option can be used to supply additional IP addresses.

https://fedorahosted.org/freeipa/ticket/5438
---
 ipaserver/install/dns.py   | 12 ++--
 ipaserver/install/installutils.py  |  7 +++
 ipaserver/install/server/common.py | 14 ++
 ipaserver/install/server/install.py|  7 ---
 ipaserver/install/server/replicainstall.py |  7 ---
 5 files changed, 39 insertions(+), 8 deletions(-)

diff --git a/ipaserver/install/dns.py b/ipaserver/install/dns.py
index da24a6f2f4872581f4c0dc6194614b27a4006a0d..8e2f1ba28180c4356d82a9caa17d491889c36558 100644
--- a/ipaserver/install/dns.py
+++ b/ipaserver/install/dns.py
@@ -2,8 +2,11 @@
 # Copyright (C) 2015  FreeIPA Contributors see COPYING for license
 #
 
+from __future__ import absolute_import
 from __future__ import print_function
 
+# absolute import is necessary because IPA module dns clashes with python-dns
+from dns import resolver
 import sys
 
 from subprocess import CalledProcessError
@@ -232,8 +235,13 @@ def install_check(standalone, replica, options, hostname):
 
 if options.no_forwarders:
 dns_forwarders = ()
-elif options.forwarders:
-dns_forwarders = options.forwarders
+elif options.forwarders or options.default_forwarders:
+if options.forwarders:
+dns_forwarders = options.forwarders
+else:
+dns_forwarders = []
+if options.default_forwarders:
+dns_forwarders += resolver.get_default_resolver().nameservers
 elif standalone or not replica:
 dns_forwarders = read_dns_forwarders()
 
diff --git a/ipaserver/install/installutils.py b/ipaserver/install/installutils.py
index 1d3551f8bb9cfcac1f6fa24043aea4b5d0a07719..39b5ba6eb2f3ddbe5fd6d68537330a482e966aec 100644
--- a/ipaserver/install/installutils.py
+++ b/ipaserver/install/installutils.py
@@ -295,6 +295,13 @@ def read_ip_addresses():
 def read_dns_forwarders():
 addrs = []
 if ipautil.user_input("Do you want to configure DNS forwarders?", True):
+print("Following DNS servers are configured in /etc/resolv.conf: %s" %
+", ".join(resolver.get_default_resolver().nameservers))
+if 

Re: [Freeipa-devel] [Update]Time-Based Account Policies

[Martin Basti]

On 11.11.2015 14:52, Martin Basti wrote:

Comments inline
Martin^2

On 11.11.2015 09:24, Stanislav Laznicka wrote:

On 11/05/2015 06:17 PM, Petr Spacek wrote:

On 4.11.2015 15:20, Martin Basti wrote:


Hello,

we (Standa and I) had offline discussion and I proposed following idea:

1) create new entry in LDAP for "time rule" instead of adding the time rule
string directly into HBACRule.
This will allow to reuse time rules among various HBAC Rules (and maybe in
future with sudo rules, etc.)
HBACrule gets only reference to time rule entry stored in LDAP db.

Good idea! I can see time rule entry 'working hours in Brno office' which is
linked to relevant HBAC rules.
This seems like a good idea. However, it might be a bit messy to have 
even the least significant rules stored in separate objects. But I 
agree. It brings some questions, though.
Imo to have separate entry for time rule is cleaner than add it 
directly to HBAC rule.



Where would be a good spot to store these time rules?
As I originally thought that we can share time rules between HBAC, 
SUDO and everything else, I couldn't be wrong more.


Example: HBAC admin have permission to edit HBAC rule, but doesn't 
have permission to edit SUDO rule. The HBAC admin should be able to 
edit time rules for HBAC rules, and cannot be able to edit time rules 
of SUDO rules. Thus time rules must be separated between HBAC, SUDO 
and others, and privilege that give the permission to modify HBAC 
rule, must give permission to modify only HBAC time rules.


I suggest to add HBAC time rules to HBAC container.

After IRC discussion with pspacek and jcholast:

We should just create separated privileges to time rules and allow them 
to be shared.

So they should be stored in new container in LDAP

Martin^2



Should they be able to form groups?

I think to allow multiple time rules per HBAC rule is enough.
Should such an object be able to hold more time policies strings and 
exceptions, as it does now, or would it be better to set that in the 
respective HBAC rule?
Can it be one time policy per entry? Do you expect that users may need 
a many complicated rules?
Generally to have an object time policy that consist of time rule 
objects which are in fact the iCal string is good idea, but is it 
worth it? We should not overengineering it.



2) Do not create a new time format, just reuse iCal (parts of iCal we need),
to store time rule in LDAP in "time rule" entry
(Or is possible to not store the values just as one string, we can use
different attributes to store separate values, iCal can be used as export and
import format)

I very much agree with re-using iCal! We have sufficient number of custom
parsers already ;-)

Speaking about custom LDAP format, I do not think that it is a good idea. It
would prevent us from using iCal parsers and generators and we would risk that
our custom LDAP format will not be flexible enough.

For these reasons I would go with 1 iCal string which can be fed into any
standard-compliant iCal library.
I was thinking long and hard about actually using the iCalendar 
format for this purpose, ever since the 'repeat' keyword was supposed 
to be included in the language. However, as I mentioned some time 
ago, the iCalendar format recurrences are OK when it comes to 
recurring events but I am not sure about them being very suitable for 
describing time policies.


Let me do a comparison of the options. I will take in question only 
the RRULE (and possibly PERIOD) part of the iCalendar format. Having 
the whole iCalendar format involved along with its parsing C library 
seemed to be a no-go for SSSD some 6 months ago and I can imagine 
such feelings persist.



Some iCalendar cons:

1) It is hard to represent continuous time of a day ranges
There does not seem to be an easy equivalent to e.g. 'timeofday= 
0730~1100, 1200~1615'. The easiest way to do this in iCalendar would 
be to have 2 rules of the form:


DTSTART: 19700101T073000
DTEND: 19700101T11
RRULE: FREQ=DAILY; INTERVAL=1

DTSTART: 19700101T12
DTEND: 19700101T161500
RRULE: FREQ=DAILY; INTERVAL=1

If you were setting some more difficult policy, there would have to 
be a lot of duplicity in each of such rules.
Is this common usage? I personally cannot imagine reason to using more 
than max 2 time periods per day.


2) All iCalendar events have to have a fixed starting point
There must always be a check against the interval and the starting point.

MIN, or date of creation can be used as default


3) There are no ranges
e.g. 'dayofyear=2-50, 100-125' would translate to

DTSTART:19700101T00
RRULE: FREQ=SECONDLY; INTERVAL=1; 
BYYEARDAY=2,3,4,5,6,7,8,9,10,11,...50,100,101,102,...




4) There is no way to list specific years in which the HBAC rule 
should apply.

is this a real concern?


5) COUNT parameter makes you generate all previous events before you 
are able to tell if the current one actually applies.
Imagine COUNT being a big number and an event