Re: [Freeipa-devel] bind-dyndb-ldap: [PATCH] Handle termination of SyncRepl watcher thread

[Petr Spacek]

On 19.12.2016 13:04, Tomas Krizek wrote:
> Hi Thierry,
> 
> could you please take a look at this bind-dyndb-ldap patch? I was trying
> to fix https://fedorahosted.org/bind-dyndb-ldap/ticket/149
> 
> I wasn't able to reproduce the issue, but I think the problem is fixed
> now. Petr Spacek was helping me with this, but I think it would be good
> if you could take a look as well.
> 
> We were able to identify two causes: a) isc_thread_create fails and
> ldap_inst->watcher is undefined (fixed by setting it to 0) and b) the
> thread terminates for some reason (i.e. some checks fail) and then a
> signal can't be sent to it. This was addressed by removing the REQUIRE
> and logging an error instead.

Please send this as PR on Github and abandon this thread ;-)

-- 
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] using Reviewer field on Github instead of Trac

[Petr Spacek]

Dear FreeIPA developers,

I just noticed that Github PRs now have Reviewers field.

Can we replace reviewed-by field in Trac with Reviewers field on Github? It is
easier to set myself as Reviewer on Github as it does not force me to edit
ticket. Assuming the Github workflow works, the ipatool could pick up this
value automatically and add it to commit messages as needed...

Given that Trac is going away is sounds like good move to me :-)

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

Re: [Freeipa-devel] NTP in FreeIPA

[Petr Spacek]

On 29.11.2016 16:02, Rob Crittenden wrote:
> Petr Spacek wrote:
>> On 29.11.2016 09:11, Jan Cholasta wrote:
>>> On 28.11.2016 20:57, Rob Crittenden wrote:
>>>> David Kupka wrote:
>>>>> On 22/11/16 23:15, Gabe Alford wrote:
>>>>>> I would say that it is worth keeping in FreeIPA. I know myself and some
>>>>>> customers use its functionality by having the clients sync to the IPA
>>>>>> servers and have the servers sync to the NTP source. This way if the NTP
>>>>>> source ever gets disrupted for long periods of time (which has
>>>>>> happened in
>>>>>> my environment) the client time drifts with the authentication source.
>>>>>> This
>>>>>> is the way that AD often works and is configured.
>>>>>
>>>>> Hello Gabe,
>>>>> I agree that it's common practice to synchronize all nodes in network
>>>>> with single source in order to have the same time and save bandwidth.
>>>>> Also I understand that it's comfortable to let FreeIPA installer take
>>>>> care of it.
>>>>> But I don't think FreeIPA should do it IMO this is job for Ansible or
>>>>> similar tool. Also the problem is that in some situations FreeIPA
>>>>> installer makes it worse.
>>>>>
>>>>> Example:
>>>>>
>>>>> 1. Install FreeIPA server (ipa1.example.org)
>>>>> 2. Install FreeIPA client on all nodes in network
>>>>> 3. Install replica (ipa2.example.org) of FreeIPA server to increase
>>>>> redundancy
>>>>>
>>>>> Now all the clients have ipa1.example.org as the only server in
>>>>> /etc/ntp.conf. If the first FreeIPA server becomes unreachable all
>>>>> clients will be able to contact KDC on the other server thanks to DNS
>>>>> autodiscovery in libkrb5 but will be unable to synchronize time.
>>>>
>>>> Remember that the goal of IPA was to herd together a bunch of software
>>>> to make hard things easier. This included dealing with the 5-minute
>>>> Kerberos window so ntp was configured on the client and server (which is
>>>> less of any issue now).
>>>>
>>>> When making changes you have to ask yourself who are you making this
>>>> easier for: you or the user.
>>>>
>>>> Yes, getting NTP right is hard, but does it meet the 80/20 rule in terms
>>>> of success? I'd think so. I
>>>>
>>>> If someone wants to configure it using Ansible they can use the
>>>> --no-ntp. If they want to use different time servers they can pass in
>>>> --ntp-server. But by default IMHO it should do something sane to give a
>>>> good experience.
>>>
>>> I think to do something sane is exactly the point of this, and the sanest
>>> thing we can do is to not touch NTP configuration at all:
>>>
>>>   * if the NTP configuration obtained via DHCP works, we can't make it any
>>> better by touching it, only worse,
>>>   * if the default NTP configuration shipped with the distribution works, we
>>> again can't make it any better by touching it,
>>>   * if we are running inside container, time is synchronized by other means
>>> and we should not touch NTP configuration at all,
>>>   * if neither the default NTP configuration nor the NTP configuration
>>> obtained via DHCP works and we are not running inside container, we may
>>> attempt to fix the configuration, but it will not be permanent and will work
>>> only for this specific host.
>>>
>>> I think the first 3 points cover 99% of real-life deployments, and yet we 
>>> are
>>> optimized towards the remaining 1%, with the potential of breaking the
>>> configuration for the 99%. This is far from sane IMHO.
>>
>> +1 for Honza's point.
>>
>> Current NTP code is works only for initial setup and silently breaks
>> synchronization later on. Most importantly it breaks synchronization as soon
>> as admin removes old replicas and replaces them with new ones - there is no
>> mechanism to update the records in the client configuration (and SRV 
>> discovery
>> is not supported by clients).
>>
>> I.e. when admin decommission replicas which were around at the time of client
>> installation, the NTP on client will silently break. This would not happen if
>> you did not touch it.
>>
>> (This also implicitly means that IPA-c

Re: [Freeipa-devel] NTP in FreeIPA

[Petr Spacek]

On 29.11.2016 09:11, Jan Cholasta wrote:
> On 28.11.2016 20:57, Rob Crittenden wrote:
>> David Kupka wrote:
>>> On 22/11/16 23:15, Gabe Alford wrote:
 I would say that it is worth keeping in FreeIPA. I know myself and some
 customers use its functionality by having the clients sync to the IPA
 servers and have the servers sync to the NTP source. This way if the NTP
 source ever gets disrupted for long periods of time (which has
 happened in
 my environment) the client time drifts with the authentication source.
 This
 is the way that AD often works and is configured.
>>>
>>> Hello Gabe,
>>> I agree that it's common practice to synchronize all nodes in network
>>> with single source in order to have the same time and save bandwidth.
>>> Also I understand that it's comfortable to let FreeIPA installer take
>>> care of it.
>>> But I don't think FreeIPA should do it IMO this is job for Ansible or
>>> similar tool. Also the problem is that in some situations FreeIPA
>>> installer makes it worse.
>>>
>>> Example:
>>>
>>> 1. Install FreeIPA server (ipa1.example.org)
>>> 2. Install FreeIPA client on all nodes in network
>>> 3. Install replica (ipa2.example.org) of FreeIPA server to increase
>>> redundancy
>>>
>>> Now all the clients have ipa1.example.org as the only server in
>>> /etc/ntp.conf. If the first FreeIPA server becomes unreachable all
>>> clients will be able to contact KDC on the other server thanks to DNS
>>> autodiscovery in libkrb5 but will be unable to synchronize time.
>>
>> Remember that the goal of IPA was to herd together a bunch of software
>> to make hard things easier. This included dealing with the 5-minute
>> Kerberos window so ntp was configured on the client and server (which is
>> less of any issue now).
>>
>> When making changes you have to ask yourself who are you making this
>> easier for: you or the user.
>>
>> Yes, getting NTP right is hard, but does it meet the 80/20 rule in terms
>> of success? I'd think so. I
>>
>> If someone wants to configure it using Ansible they can use the
>> --no-ntp. If they want to use different time servers they can pass in
>> --ntp-server. But by default IMHO it should do something sane to give a
>> good experience.
> 
> I think to do something sane is exactly the point of this, and the sanest
> thing we can do is to not touch NTP configuration at all:
> 
>   * if the NTP configuration obtained via DHCP works, we can't make it any
> better by touching it, only worse,
>   * if the default NTP configuration shipped with the distribution works, we
> again can't make it any better by touching it,
>   * if we are running inside container, time is synchronized by other means
> and we should not touch NTP configuration at all,
>   * if neither the default NTP configuration nor the NTP configuration
> obtained via DHCP works and we are not running inside container, we may
> attempt to fix the configuration, but it will not be permanent and will work
> only for this specific host.
> 
> I think the first 3 points cover 99% of real-life deployments, and yet we are
> optimized towards the remaining 1%, with the potential of breaking the
> configuration for the 99%. This is far from sane IMHO.

+1 for Honza's point.

Current NTP code is works only for initial setup and silently breaks
synchronization later on. Most importantly it breaks synchronization as soon
as admin removes old replicas and replaces them with new ones - there is no
mechanism to update the records in the client configuration (and SRV discovery
is not supported by clients).

I.e. when admin decommission replicas which were around at the time of client
installation, the NTP on client will silently break. This would not happen if
you did not touch it.

(This also implicitly means that IPA-configured NTP is broken on all clients
in topologies which were completely migrated from RHEL 6 to RHEL 7.)

Either DHCP or default distro config would solve the problem better.

Petr^2 Spacek


>> There don't seem to be a ton of NTP tickets and I don't recall a lot of
>> user's pressing for it to go away (the reverse, many times their
>> problems revolve around time not being synced). I wonder if a survey on
>> freeipa-users would be in order to see how hot an issue this really is.

-- 
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] NTP in FreeIPA

[Petr Spacek]

On 24.11.2016 17:14, Martin Basti wrote:
> If NTP is still configured on the IPA server, this may be less of an issue.
> Not everyone has/is/will be using ansible. Also in secure environments, DHCP
> is not allowed/used at all.

If DHCP is not good enough for your environment then you *must not* use
standard NTP, otherwise you just broke all the security.

Standard NTP is not more secure than DHCP.

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

Re: [Freeipa-devel] client-only FreeIPA build

[Petr Spacek]

On 23.11.2016 13:53, Lukas Slebodnik wrote:
> On (22/11/16 11:25), Rob Crittenden wrote:
>> Lukas Slebodnik wrote:
>>> On (22/11/16 16:29), Petr Spacek wrote:
>>>> On 22.11.2016 16:27, Jan Cholasta wrote:
>>>>> Hi,
>>>>>
>>>>> On 22.11.2016 16:04, Petr Spacek wrote:
>>>>>> Hello,
>>>>>>
>>>>>> the recent changes with regard to
>>>>>> http://www.freeipa.org/page/V4/Integration_Improvements
>>>>>> beg a question whether we should invest into supporting client-only 
>>>>>> builds in
>>>>>> FreeIPA build system.
>>
>> Note that the Integration efforts don't really apply. The client-only
>> install is for doing client enrollment and integration can mean lots of
>> things.
>>
>>>>>>
>>>>>> Right now, FreeIPA can be built on all architectures we care about so 
>>>>>> there is
>>>>>> no incentive to invest into client-only build - this applies to 
>>>>>> binary/RPM
>>>>>> builds.
>>>>>
>>>>> Client-only build lowers the barrier for porting IPA to new platforms 
>>>>> (porting
>>>>> only client code is *much* easier than porting the whole thing), so I 
>>>>> would
>>>>> very much prefer if we kept it.
>>>>
>>>> Understood.
>>>>
>>> Agree about portability
>>>
>>> But upstream spec file needn't have such relicts.
>>> The upstream spec file is pure fedora specific.
>>
>> The upstream spec is what is used to document and verify that the
>> client-only build actually works.
>>
>> I also think it is a worthy goal to maintain.
>>
> Maintaing is not enough. It would be also good to test it.
> 
> And maybe it might be much simpler to have separate
> spec file for client only build. Because too many if conditions
> does not improve readability of spec file. But that's up to
> others to decide what would be simpler.

The maintenance cost you mention is the only con I can see.

I think that if we decide to support it, client-only support should be part of
configure machinery. It would enable packagers to simply run
./configure --disable-server && make install
and have the client installed. It would make easy to package it for whatever
distro.

Of course, upstream spec will be a good reference for packaging but IMHO we
should keep separated build & install matters from packaging.

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

Re: [Freeipa-devel] client-only FreeIPA build

[Petr Spacek]

On 22.11.2016 16:14, Lukas Slebodnik wrote:
> On (22/11/16 16:04), Petr Spacek wrote:
>> Hello,
>>
>> the recent changes with regard to
>> http://www.freeipa.org/page/V4/Integration_Improvements
>> beg a question whether we should invest into supporting client-only builds in
>> FreeIPA build system.
>>
>> Right now, FreeIPA can be built on all architectures we care about so there 
>> is
>> no incentive to invest into client-only build - this applies to binary/RPM 
>> builds.
>>
>>
>> The question is, do we need something special in build system for Integration
>> Improvements effort? If not, can we drop the remains of client-only build?
>> (They are not functional anyway so we should either drop them or fix them.)
>>
> What do you mean by "remains of client-only build"?
> IIRC you drop this feature in the 1st patch set.

There are still references to it in freeipa.spec.in and so on.

-- 
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] client-only FreeIPA build

[Petr Spacek]

Hello,

the recent changes with regard to
http://www.freeipa.org/page/V4/Integration_Improvements
beg a question whether we should invest into supporting client-only builds in
FreeIPA build system.

Right now, FreeIPA can be built on all architectures we care about so there is
no incentive to invest into client-only build - this applies to binary/RPM 
builds.


The question is, do we need something special in build system for Integration
Improvements effort? If not, can we drop the remains of client-only build?
(They are not functional anyway so we should either drop them or fix them.)

Thank you for answers.

For completeness, the RPM build somehow works on following architectures:
aarch64
armv7hl
i686
ppc
ppc64
ppc64le
s390
s390x
x86_64

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

Re: [Freeipa-devel] Design document: Integration Improvements

[Petr Spacek]

On 21.11.2016 14:15, Christian Heimes wrote:
> On 2016-11-21 13:31, Jan Cholasta wrote:
>> Hi,
>>
>> On 11.11.2016 15:25, Christian Heimes wrote:
>>> Hello,
>>>
>>> I have released the first version of a new design document. It describes
>>> how I'm going to improve integration of FreeIPA's client libraries
>>> (ipalib, ipapython, ipaclient, ipaplatform) for third party developers.
>>>
>>> http://www.freeipa.org/page/V4/Integration_Improvements
>>
>> 3.1 API for local configuration directory
>>
>> "Both approaches have some disadvantages. A user must repeat the -e
>> option in every call to ipa or create a shell alias. It's both tedious
>> and error-prone."
>>
>> This is pretty subjective. I don't think it's error-prone at all, since
>> it is explicit and you always know what confdir value will be used in
>> the ipa command just by looking at its arguments, as opposed to the
>> environment variable, which makes the configuration implicit and
>> depending on *sane* environment and is equivalent to preferring global
>> variables to function arguments in Python code.
> 
> It's not implicit. The env var has to be set explicitly just like you
> have to use -e confdir explicitly in every call.
> 
>> That being said, this whole section is filled with one-sided "facts" and
>> simply ignores everything else, which might lead the reader to believe
>> that the environment variable is something required, while it is in fact
>> just a nice-to-have convenience feature. A good design should include
>> both sides of an argument, even if you don't agree with one.
>>
>> BTW, shell alias works perfectly fine in your virtualenv example above
>> in the design.
> 
> No, it does not work perfectly fine. By default shell aliases are
> limited to interactive shells. My proposal also works with Python
> subprocess module, a C program with execve(), Makefile, Ansible local
> command, non-interactive shell script...
> 
>> 3.2.1 Build and runtime requirements
>>
>> How are we going to detect and report missing runtime dependencies?
>> Currently if they are not installed, the code will fail at random places
>> during execution with an often cryptic error message. I think this is
>> unacceptable, and since there is no way specify external dependencies
>> using setuptools (right?), it needs to be done in our code during
>> package import (or other suitable place).
> 
> Instead of detecting missing dependencies, we document requirements and
> treat users as adults. Runtime checks are a performance issue. Since
> wheels don't execute code at installation time, we can't check for
> missing dependencies during installation.
> 
>> 3.3 ipaplatform auto-configuration
>>
>> I'm not sure if guessing platform from ID_LIKE is really a good idea. It
>> might work fine for centos -> rhel, but in general we can't really
>> assume it will always work, as the platforms listed in ID_LIKE might not
>> be similar enough to the one in ID. I would rather add an ipaplatform
>> subpackage for every supported platform (including CentOS) than depend
>> on error-prone guesswork.
> 
> Can you show me a real-world example for your statement that ID_LIKE is
> error-prone?
> 
> Your proposal doesn't scale. There are tons of Debian spins with their
> own ID. For example my Raspberry Pi has ID=raspbian and ID_LIKE=debian.
> Do you want to maintain an exhaustive list of all Debian and Ubuntu
> variants?

Can we agree that it would be much better to get rid of platform depedency in
client libraries and be done with this philosophical debate?

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

Re: [Freeipa-devel] Design document: Integration Improvements: ipaplatform

[Petr Spacek]

On 11.11.2016 15:25, Christian Heimes wrote:
> Hello,
> 
> I have released the first version of a new design document. It describes
> how I'm going to improve integration of FreeIPA's client libraries
> (ipalib, ipapython, ipaclient, ipaplatform) for third party developers.
> 
> http://www.freeipa.org/page/V4/Integration_Improvements

Looking at
http://www.freeipa.org/page/V4/Integration_Improvements#Scope
the first step is to make ipalib functional.

I think that correct approach is to inspect ipalib and its dependencies and
reshuffle code in a way which will allow us to remove ipaplatform dependency
from ipalib.

That way we can have platform-independent ipalib and at the same time use
configure phase to auto-generate platform stuff. In long-term we should be
able to get rid of explicit ipaplatform definitions and have these generated
at build time for particular platform the build is running on.

That will make porting to other distros way easier and remove implicit
dependency on particular paths hard-coded in platform files.

-- 
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] Build system refactoring was pushed to master

[Petr Spacek]

Hi FreeIPA gang,

we just pushed Build system refactoring to master.

Most visible change is that you need to use command "./makerpms.sh" instead of
"make rpms" when building FreeIPA from clean Git tree.

"make rpms" will work as usual after initial autoreconf -i && ./configure
combo so this affects only the very first build.

Page
http://www.freeipa.org/page/Build
was updated with other changes as well, most notably file VERSION was renamed
to VERSION.m4.

Other details are mentioned in design document
http://www.freeipa.org/page/V4/Build_system_refactoring

and pull request:
https://github.com/freeipa/freeipa/pull/213

Let me know if you encounter any issues!

-- 
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] Is checks/check-ra.py still useful?

[Petr Spacek]

Hi,

when working on build system refactoring, I've noticed file
checks/check-ra.py.

README follows:
> This directory is for integration tests that require a live backend (LDAP,
> Certificate Server, etc.).  It's named "checks" so nose wont discover tests
> here.

Is it still useful? As far as I can tell it was last updated in 2009 and it
contains hardcoded host name of a dead machine.

We should either revive it or remove it. I do not want to distribute
non-functional code in the new shiny tarball.

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

Re: [Freeipa-devel] What would break if loopback addresses were allowed for IPA server?

[Petr Spacek]

On 17.10.2016 17:55, Simo Sorce wrote:
> On Mon, 2016-10-17 at 09:02 +0200, Petr Spacek wrote:
>> On 27.9.2016 14:31, Jan Pazdziora wrote:
>>> On Wed, Sep 21, 2016 at 12:01:44PM +0200, Jan Pazdziora wrote:
>>>>
>>>> I've recently hit again the situation of IPA installer not happy
>>>> about the provided IP address not being local to it, this time in
>>>> containerized environment:
>>>>
>>>>https://bugzilla.redhat.com/show_bug.cgi?id=1377973
>>>>
>>>> During the discussion, we came to an interesting question:
>>>>
>>>>What would break if loopback addresses were allowed for IPA
>>>>server?
>>>>
>>>> Of course, the idea is that it would only be used for installation and
>>>> then IPA would change its IP address in DNS to whatever is the real IP
>>>> address under which it is accessible.
>>>>
>>>> Where does the allow_loopback=False requirement in the installer come
>>>> from and what would break if it was removed altogether?
>>>
>>> I also see messages like
>>>
>>> Adding [10.11.12.13 ipa.example.com] to your /etc/hosts file
>>>
>>> in some cases. Actually, it's
>>>
>>> 10.11.12.13 ipa.example.com ipa
>>>
>>> which gets added so the message is not accurate.
>>>
>>> Modification of /etc/hosts itself seems unfortunate. Should the IP
>>> address change in the future, there will be one more place where
>>> the IP address stays hardcoded.
>>>
>>> I wonder why
>>>
>>> hosts:  files dns myhostname
>>>
>>> isn't enough, and whether
>>>
>>> hosts:  files myhostname dns
>>>
>>> might actually be better order.
>>
>> Theoretically yes. Practically it will break Dogtag and other components 
>> which
>> are not able to cope up with link-local addresses returned from myhostname 
>> module.
>>
>>
>>> When the value is not in /etc/hosts,
>>> I see weird startup issues, presumably because individual components
>>> time out resolving $HOSTNAME, so systemctl start ipa fails. Perhaps
>>> it has something to do with named being up at that point, rather than
>>> unreachable, just not resolving anything yet. Chicken and egg.
>>>
>>> I wonder why we cannot add ipa.example.com to 127.0.0.1. I've tried
>>> that and have seen
>>>
>>> named-pkcs11[453]: LDAP error: Local error: SASL(-1): generic
>>> failure: GSSAPI Error: Unspecified GSS failure.  Minor code
>>> may provide more information (Server
>>> ldap/localh...@example.test not found in Kerberos database):
>>> bind to LDAP server failed
>>>
>>> which suggests something derives the hostname and thus the principal
>>> from the IP address used. Why is not $HOSTNAME used everywhere? What
>>> part of the system cares about the IP address (and the reverse
>>> resolution)?
>>
>> AFAIK FQDN is used everywhere. The "localhost" name might be coming from
>> Kerberos name canonicalization, which works like this:
>> FQDN (name resolution) record-> IP address (IP address resolution)->new name.
>>
>> You might try to add rdns=false to [libdefaults] section in /etc/krb5.conf. 
>> It
>> should be default anyway, but why not try it explicitly.
>>
>> Also, I would try if dns_canonicalize_hostname=false makes any difference or 
>> not.
> 
> Btw this attribute came up also elsewhere, I think we should consider
> changing ipa-client-install (or SSSD) to make
> dns_canonicalize_hostname=false the default in IPa installs.
> 
> Should we open a ticket for that?

I would leave it for Jan so we know that it has desired effect in his setup.

Petr^2 Spacek

>>> If overloading 127.0.0.1 with the $HOSTNAME does not work, could
>>> 127.0.0.2 do the trick? It seems to work for subsequent starts (did
>>> not try it during ipa-server-install) in containers.
>>
>> It will likely suffer with very similar problems. It if works, it works just
>> accidentally and might break at any time in future.
>>
>> Before we touch IP address/domain name logic, we need to agree how it should
>> behave.
>>
>> What is the purpose of --ip-address option?
>> a) Specify IP addresses used in DNS.
>> ab) What checks should be performed on it?
>> b) To bind deamons only to specific IP addresses instead of all interfaces?
>>
>> I have seen requests for both. We need to decide what is the intended 
>> behavior
>> and design it before making further changes. The spaghetti code is too
>> intertwined for making any non-systematic changes.
>>
>> -- 
>> 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

Re: [Freeipa-devel] What would break if loopback addresses were allowed for IPA server?

[Petr Spacek]

On 27.9.2016 14:31, Jan Pazdziora wrote:
> On Wed, Sep 21, 2016 at 12:01:44PM +0200, Jan Pazdziora wrote:
>>
>> I've recently hit again the situation of IPA installer not happy
>> about the provided IP address not being local to it, this time in
>> containerized environment:
>>
>>  https://bugzilla.redhat.com/show_bug.cgi?id=1377973
>>
>> During the discussion, we came to an interesting question:
>>
>>  What would break if loopback addresses were allowed for IPA
>>  server?
>>
>> Of course, the idea is that it would only be used for installation and
>> then IPA would change its IP address in DNS to whatever is the real IP
>> address under which it is accessible.
>>
>> Where does the allow_loopback=False requirement in the installer come
>> from and what would break if it was removed altogether?
> 
> I also see messages like
> 
>   Adding [10.11.12.13 ipa.example.com] to your /etc/hosts file
> 
> in some cases. Actually, it's
> 
>   10.11.12.13 ipa.example.com ipa
> 
> which gets added so the message is not accurate.
> 
> Modification of /etc/hosts itself seems unfortunate. Should the IP
> address change in the future, there will be one more place where
> the IP address stays hardcoded.
> 
> I wonder why
> 
>   hosts:  files dns myhostname
> 
> isn't enough, and whether
> 
>   hosts:  files myhostname dns
> 
> might actually be better order.

Theoretically yes. Practically it will break Dogtag and other components which
are not able to cope up with link-local addresses returned from myhostname 
module.


> When the value is not in /etc/hosts,
> I see weird startup issues, presumably because individual components
> time out resolving $HOSTNAME, so systemctl start ipa fails. Perhaps
> it has something to do with named being up at that point, rather than
> unreachable, just not resolving anything yet. Chicken and egg.
> 
> I wonder why we cannot add ipa.example.com to 127.0.0.1. I've tried
> that and have seen
> 
>   named-pkcs11[453]: LDAP error: Local error: SASL(-1): generic
>   failure: GSSAPI Error: Unspecified GSS failure.  Minor code
>   may provide more information (Server
>   ldap/localh...@example.test not found in Kerberos database):
>   bind to LDAP server failed
> 
> which suggests something derives the hostname and thus the principal
> from the IP address used. Why is not $HOSTNAME used everywhere? What
> part of the system cares about the IP address (and the reverse
> resolution)?

AFAIK FQDN is used everywhere. The "localhost" name might be coming from
Kerberos name canonicalization, which works like this:
FQDN (name resolution) record-> IP address (IP address resolution)->new name.

You might try to add rdns=false to [libdefaults] section in /etc/krb5.conf. It
should be default anyway, but why not try it explicitly.

Also, I would try if dns_canonicalize_hostname=false makes any difference or 
not.


> If overloading 127.0.0.1 with the $HOSTNAME does not work, could
> 127.0.0.2 do the trick? It seems to work for subsequent starts (did
> not try it during ipa-server-install) in containers.

It will likely suffer with very similar problems. It if works, it works just
accidentally and might break at any time in future.

Before we touch IP address/domain name logic, we need to agree how it should
behave.

What is the purpose of --ip-address option?
a) Specify IP addresses used in DNS.
ab) What checks should be performed on it?
b) To bind deamons only to specific IP addresses instead of all interfaces?

I have seen requests for both. We need to decide what is the intended behavior
and design it before making further changes. The spaghetti code is too
intertwined for making any non-systematic changes.

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

Re: [Freeipa-devel] Heimdal Kerberos support for client

[Petr Spacek]

On 12.10.2016 20:22, Rob Crittenden wrote:
> Petr Spacek wrote:
>> Hello list,
>>
>> I just noticed that client/configure.ac contains some checks to detect and
>> support Heimdal Kerberos libraries.
>>
>> Was it tested? Does it work? Can I drop it? :-)
>>
> 
> Wow, that's some old code.
> 
> Only Simo would know if it was ever tested or ever worked.
> 
> I suppose since theoretically the client can be built separately theoretically
> it might do the right thing in some cases.
> 
> Seems like enough of a corner case to me that I'd remove it, given it is
> likely untested these last 9 years or so.

Simo told me on IRC that we could remove it. According to Alexander, Ubuntu is
building IPA packages against MIT Kerberos so it should be okay.

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

Re: [Freeipa-devel] links to docs in the messages from code

[Petr Spacek]

On 13.10.2016 08:54, Martin Basti wrote:
> 
> 
> On 12.10.2016 19:56, Petr Spacek wrote:
>> Hello FreeIPA developers,
>>
>> looking at freeipa-users mailing list, a lot of questions could be answered 
>> by
>> just quick glance to the docs.
>>
>> I wonder if we should add links HTML version of docs on access.redhat.com to
>> the messages generated by the code.
>>
>> If we really want, we can make these platform-specific, but I would not even
>> bother with it. Fedora & CentOS & RHEL users end up on the very same page,
>> only the way how then find it is different (mailing list vs. Google vs. paid
>> support).
>>
>>
>> Examples:
>>
>> a) Installation without DNS could end up with message like this:
>> Do not forget to finish post-installation steps listed on
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-without-dns
>>
>>
>>
>> b) Failed connection check could print link to
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#prereq-ports
>>
>>
>>
>> c) Failed DNS check could mention link
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#dns-reqs
>>
>>
>>
>> d) Failed attempt to find AD DC could print a link to:
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-requirements.html#dns-realm-settings
>>
>>
>> etc.
>>
>> What do you think about this?
>>
> 
> I'm afraid that those links can change over time, so we have to check them
> regularly otherwise we may end up with links pointing to nowhere.

This check can be easily automated. AFAIK docs team already have tools like 
this.


> I'm not excited too much with this idea.

Okay then. I'm open to any other idea to alleviate the problem with
ever-repeating questions on the freeipa-users list. Do you have one?

-- 
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] Heimdal Kerberos support for client

[Petr Spacek]

Hello list,

I just noticed that client/configure.ac contains some checks to detect and
support Heimdal Kerberos libraries.

Was it tested? Does it work? Can I drop it? :-)

-- 
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] links to docs in the messages from code

[Petr Spacek]

Hello FreeIPA developers,

looking at freeipa-users mailing list, a lot of questions could be answered by
just quick glance to the docs.

I wonder if we should add links HTML version of docs on access.redhat.com to
the messages generated by the code.

If we really want, we can make these platform-specific, but I would not even
bother with it. Fedora & CentOS & RHEL users end up on the very same page,
only the way how then find it is different (mailing list vs. Google vs. paid
support).


Examples:

a) Installation without DNS could end up with message like this:
Do not forget to finish post-installation steps listed on
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-without-dns


b) Failed connection check could print link to
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#prereq-ports


c) Failed DNS check could mention link
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#dns-reqs


d) Failed attempt to find AD DC could print a link to:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-requirements.html#dns-realm-settings

etc.

What do you think about this?

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

Re: [Freeipa-devel] Broken IPA installation caused by new python-dns package

[Petr Spacek]

On 10.10.2016 10:28, Martin Basti wrote:
> https://bodhi.fedoraproject.org/updates/FEDORA-2016-1857421df6
> 
> 
> Please set karma accordingly
> 
> 
> Traceback:
> 
> ...
> 
>   File "/usr/lib/python2.7/site-packages/ipaserver/dns_data_management.py",
> line 426, in update_dns_records
> self.update_base_records(),
>   File "/usr/lib/python2.7/site-packages/ipaserver/dns_data_management.py",
> line 377, in update_base_records
> base_zone = self.get_base_records()
>   File "/usr/lib/python2.7/site-packages/ipaserver/dns_data_management.py",
> line 328, in get_base_records
> include_kerberos_realm=include_kerberos_realm
>   File "/usr/lib/python2.7/site-packages/ipaserver/dns_data_management.py",
> line 179, in _add_base_dns_records_for_server
> self.__add_kerberos_txt_rec(zone_obj)
>   File "/usr/lib/python2.7/site-packages/ipaserver/dns_data_management.py",
> line 165, in __add_kerberos_txt_rec
> rdataset.add(rd, ttl=86400)  # FIXME: use TTL from config
>   File "/usr/lib/python2.7/site-packages/dns/rdataset.py", line 129, in add
> super(Rdataset, self).add(rd)
>   File "/usr/lib/python2.7/site-packages/dns/set.py", line 49, in add
> if item not in self.items:
>   File "/usr/lib/python2.7/site-packages/dns/rdata.py", line 217, in __eq__
> return self._cmp(other) == 0
>   File "/usr/lib/python2.7/site-packages/dns/rdata.py", line 203, in _cmp
> our = self.to_digestable(dns.name.root)
>   File "/usr/lib/python2.7/site-packages/dns/rdata.py", line 174, in
> to_digestable
> self.to_wire(f, None, origin)
>   File "/usr/lib/python2.7/site-packages/dns/rdtypes/txtbase.py", line 75, in
> to_wire
> file.write(s)
> 
> 2016-10-10T04:44:05Z DEBUG The ipa-replica-install command failed, exception:
> TypeError: 'unicode' does not have the buffer interface
> 2016-10-10T04:44:05Z ERROR 'unicode' does not have the buffer interface
> 
> 
> I'll investigate if IPA using it wrong or there is new error introduced in
> pyhton-dns

For archaeologists:
Fix
https://github.com/freeipa/freeipa/pull/150
was merged.

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

Re: [Freeipa-devel] Build system refactoring - design document

[Petr Spacek]

On 11.10.2016 15:47, Petr Vobornik wrote:
> On 10/07/2016 11:56 AM, Petr Spacek wrote:
>> Dear FreeIPA developers and packagers,
>>
>> you can find first version of the Build system refactoring design document 
>> on:
>> http://www.freeipa.org/page/V4/Build_system_refactoring
>>
>> If you do not care about implementation details, please be so kind and 
>> quickly
>> scan through chapter
>> http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management
>>
>> I'm not an FreeIPA packager so I might miss some important thing which needs
>> to be configurable.
>>
>>
>> Also, I would appreciate ideas how to handle build versioning:
>> http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning
>>
>> My main questions are:
>> * What is triggering IPA upgrade?
>> * Would it be sufficient to bump release in RPM? (I mean - theoretically.
>> Could the code be modified to detect this?)
>>
>> Here I'm trying to avoid unnecessary rebuilds caused by changes to
>> IPA_VENDOR_VERSION during each build.
>>
>>
>> Timo, what can I do to help you with packaging for Ubuntu/Debian?
>>
>> Dream big, even wild ideas are welcome!
>>
> 
> I'd like to add one use case which is a prerequisite for "packager":
> release engineer.
> 
> Currently, IPA is released by running
>   $ make IPA_VERSION_IS_GIT_SNAPSHOT=no rpms
> 
> Then tarball is copied from dist/sources to freeipa.org
> 
> http://www.freeipa.org/page/Release#Building_the_sources
> 
> With current code, it may be done only with:
>  $ make tarball
> 
> But it probably wasn't tested much so I'd not rely on it.
> 
> What I'd like to see:
> 
> Release engineer:
>  $ make dist
>  $ # copy tarball
> 
> Packager:
>  $ ./configure [--options]
>  $ make install
> 
> I think that this workflow is implied by "Automake: Standard Targets"
> but IMHO it should be specified in the design explicitly because it is a
> change in our process.

Fine with me. Please formulate your requirements to user stories and add them 
to:
http://www.freeipa.org/page/V4/Build_system_refactoring#User_stories

I will look at them after that.

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

Re: [Freeipa-devel] Build system refactoring - design document

[Petr Spacek]

On 11.10.2016 10:04, Jan Cholasta wrote:
> On 11.10.2016 09:36, Petr Spacek wrote:
>> On 11.10.2016 09:00, Jan Cholasta wrote:
>>> Hi,
>>>
>>> On 7.10.2016 11:56, Petr Spacek wrote:
>>>> Dear FreeIPA developers and packagers,
>>>>
>>>> you can find first version of the Build system refactoring design document
>>>> on:
>>>> http://www.freeipa.org/page/V4/Build_system_refactoring
>>>>
>>>> If you do not care about implementation details, please be so kind and
>>>> quickly
>>>> scan through chapter
>>>> http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management
>>>>
>>>> I'm not an FreeIPA packager so I might miss some important thing which 
>>>> needs
>>>> to be configurable.
>>>
>>> 1) There should be a --with-python switch to select the version of Python to
>>> use in our command line tools and/or during build. The default would be
>>> "python", i.e. the default Python interpreter found in the path.
>>
>> Okay. Can we pick some descriptive name?
>>
>> --with-default-python
>> or
>> --with--python?
>>
>> I think that it would be confusing if we had just
>> --with-python
>> --with-python2
>> --with-python3
> 
> If the default values are "python", "python2", "python3" respectively, I don't

These need to be full paths. I hope that some autoconf detection logic will
help with autodetection.


> think it would be confusing, since most of the time you only need to specify
> --with-python, if anything.

Okay, let me be explicit: It *is* confusing for me. Would you be okay with
--with-default-python ?


> Do we even need --with-python2 and --with-python3? I think they would only
> make sense if you had multiple Python minor versions installed and wanted to
> make packages for all of them.

AFAIK autoconf-style is to provide these for options where path to external
binary is needed. I would like to keep these conventions to avoid NIH syndrome
in the new build system.

Also, --without-python2/--without-python3 is needed anyway to disable this
part of build on systems without Python X version. I want to keep this
explicit (as with any other optional part of the build).


>> Besides that, I would make --with-default-python to accept either "2" or "3"
>> (and thus use path specified by --with-python? option).
>>
>>
>>
>>> 2) There is --with-pylint, --with-jslint, but no --with-po-validate.
>>
>> Let me clarify: I plan to use --with for things which have paths or other
>> parameters, --enable for booleans.
> 
> I see, that was not clear to me, I confused the two.
> 
>>
>> Where po-validate belongs? AFAIK target validate-po in install/po/Makefile is
>> calling script ../../ipatests/i18n.py which is in IPA source tree anyway.
>>
>> Do you want to have a --enable/--disable switch for these PO checks?
> 
> Not really.
> 
>>
>>
>>> 3) I would prefer that if pylint (or jslint or python-polib) is not 
>>> installed
>>> the build would fail instead of silently skipping the lint. Let it be a 
>>> wilful
>>> decision of the packager whether to run the lint or not.
>>
>> Yes, that is my intent. It will not skip anything automatically.
> 
> Right.
> 
>>
>>
>>
>>> 4) It is explicitly stated that I can turn off features using
>>> --without-feature. But how do I disable building server components?
>>
>> I've added explicit mention of --disable-feature:
>> http://www.freeipa.org/index.php?title=V4%2FBuild_system_refactoring=revision=14311=14310
>>
> 
> Thanks.
> 
>>
>>
>>>> Also, I would appreciate ideas how to handle build versioning:
>>>> http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning
>>>>
>>>> My main questions are:
>>>> * What is triggering IPA upgrade?
>>>> * Would it be sufficient to bump release in RPM? (I mean - theoretically.
>>>> Could the code be modified to detect this?)
>>>>
>>>> Here I'm trying to avoid unnecessary rebuilds caused by changes to
>>>> IPA_VENDOR_VERSION during each build.
>>>
>>> How exactly is IPA_VENDOR_VERSION causing unnecessary rebuilds? I can see it
>>> is written only to ipapython/version.py:
>>>
>>> $ git grep -E '\bIPA_VENDOR_VERSION\b'
>>> Makefile:IPA_VENDOR_VERSION=$(IPA_VERSION)$(IPA_VENDOR_VERSION_SUFFIX)
>>> Makefile:   sed -

Re: [Freeipa-devel] Build system refactoring - design document

[Petr Spacek]

On 11.10.2016 09:00, Jan Cholasta wrote:
> Hi,
> 
> On 7.10.2016 11:56, Petr Spacek wrote:
>> Dear FreeIPA developers and packagers,
>>
>> you can find first version of the Build system refactoring design document 
>> on:
>> http://www.freeipa.org/page/V4/Build_system_refactoring
>>
>> If you do not care about implementation details, please be so kind and 
>> quickly
>> scan through chapter
>> http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management
>>
>> I'm not an FreeIPA packager so I might miss some important thing which needs
>> to be configurable.
> 
> 1) There should be a --with-python switch to select the version of Python to
> use in our command line tools and/or during build. The default would be
> "python", i.e. the default Python interpreter found in the path.

Okay. Can we pick some descriptive name?

--with-default-python
or
--with--python?

I think that it would be confusing if we had just
--with-python
--with-python2
--with-python3


Besides that, I would make --with-default-python to accept either "2" or "3"
(and thus use path specified by --with-python? option).



> 2) There is --with-pylint, --with-jslint, but no --with-po-validate.

Let me clarify: I plan to use --with for things which have paths or other
parameters, --enable for booleans.

Where po-validate belongs? AFAIK target validate-po in install/po/Makefile is
calling script ../../ipatests/i18n.py which is in IPA source tree anyway.

Do you want to have a --enable/--disable switch for these PO checks?


> 3) I would prefer that if pylint (or jslint or python-polib) is not installed
> the build would fail instead of silently skipping the lint. Let it be a wilful
> decision of the packager whether to run the lint or not.

Yes, that is my intent. It will not skip anything automatically.



> 4) It is explicitly stated that I can turn off features using
> --without-feature. But how do I disable building server components?

I've added explicit mention of --disable-feature:
http://www.freeipa.org/index.php?title=V4%2FBuild_system_refactoring=revision=14311=14310


>> Also, I would appreciate ideas how to handle build versioning:
>> http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning
>>
>> My main questions are:
>> * What is triggering IPA upgrade?
>> * Would it be sufficient to bump release in RPM? (I mean - theoretically.
>> Could the code be modified to detect this?)
>>
>> Here I'm trying to avoid unnecessary rebuilds caused by changes to
>> IPA_VENDOR_VERSION during each build.
> 
> How exactly is IPA_VENDOR_VERSION causing unnecessary rebuilds? I can see it
> is written only to ipapython/version.py:
> 
> $ git grep -E '\bIPA_VENDOR_VERSION\b'
> Makefile:IPA_VENDOR_VERSION=$(IPA_VERSION)$(IPA_VENDOR_VERSION_SUFFIX)
> Makefile:   sed -i -e "s:__VENDOR_VERSION__:$(IPA_VENDOR_VERSION):"
> ipapython/version.py

My bad, I should write 'IPA*VERSION*'.

Especially unconditional write to version.m4 is problematic but unconditional
writes to other files slows things as well, just not that much.

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

Re: [Freeipa-devel] kinit: Cannot contact any KDC for realm... from Freeipa clinet (Active Directory trust setup)

[Petr Spacek]

On 10.10.2016 05:23, rajat gupta wrote:
> Hi,
> 
> I am trying to setup the freeipa  Active Directory trust setup and i am
> following
> the http://www.freeipa.org/page/Active_Directory_trust_setup documentation.
> 
> I am able to login on freeipa Server with AD users.
> 
> But when i am trying to login with some other IPA client machine I am not
> able to to login with AD user.
> 
> Required firewall port is opened between freeipa server to AD server and
> freeipa server to freeipa clinets
> 
> There is no firewall port is opened between from  freeipa client to AD
> server.
> 
> =
> against addomain from ipaserver :-
> 
> ipa01 ~]# KRB5_TRACE=/dev/stdout kinit raja...@ad.addomain.com
> [24633] 1476069033.462976: Resolving unique ccache of type KEYRING
> [24633] 1476069033.463027: Getting initial credentials for
> raja...@ad.addomain.com
> [24633] 1476069033.465229: Sending request (183 bytes) to AD.ADDOMAIN.COM
> [24633] 1476069033.471891: Resolving hostname ad1.ad.addomain.com
> [24633] 1476069033.474439: Sending initial UDP request to dgram
> 192.168.20.100:88
> [24633] 1476069033.487765: Received answer (212 bytes) from dgram
> 192.168.20.100:88
> [24633] 1476069033.488098: Response was not from master KDC
> [24633] 1476069033.488136: Received error from KDC: -1765328359/Additional
> pre-authentication required
> [24633] 1476069033.488179: Processing preauth types: 16, 15, 19, 2
> [24633] 1476069033.488192: Selected etype info: etype aes256-cts, salt
> "AD.ADDOMAIN.COMRajat.Gupta", params ""
> [24633] 1476069033.488215: PKINIT client has no configured identity; giving
> up
> [24633] 1476069033.488233: PKINIT client has no configured identity; giving
> up
> [24633] 1476069033.488242: Preauth module pkinit (16) (real) returned:
> 22/Invalid argument
> [24633] 1476069033.488250: PKINIT client has no configured identity; giving
> up
> [24633] 1476069033.488255: Preauth module pkinit (14) (real) returned:
> 22/Invalid argument
> Password for raja...@ad.addomain.com:
> 
> this is working fine.
> =
> 
> 
> =
> against addomain from ipaclinet :-
> 
> *ipaclinet ~] #  KRB5_TRACE=/dev/stdout kinit  raja...@ad.addomain.com
> [4133] 1476067599.43421: Getting initial
> credentials for raja...@ad.addomain.com [4133]
> 1476067599.43599: Sending request (183 bytes) to AD.ADDOMAIN.COM
> *
> *[4133] 1476067599.49544: Resolving hostname *
> *ad1.ad.addomain.com .*
> *[4133] 1476067599.53762: Sending initial UDP request to dgram
> 192.168.20.100*
> 
> NOT WORKING
> =
> 
> =
> against ipdomain from ipaclinet
> 
> # KRB5_TRACE=/dev/stdout kinit  admin@IPA.IPASERVER.LOCAL
> [4914] 1476068067.763574: Getting initial credentials for
> admin@IPA.IPASERVER.LOCAL
> [4914] 1476068067.763889: Sending request (177 bytes) to IPA.IPASERVER.LOCAL
> [4914] 1476068067.764033: Initiating TCP connection to stream
> 10.246.104.14:88
> [4914] 1476068067.765089: Sending TCP request to stream 192.168.100.100:88
> [4914] 1476068067.767593: Received answer (356 bytes) from stream
> 192.168.100.100:88
> [4914] 1476068067.767603: Terminating TCP connection to stream
> 192.168.100.100:88
> [4914] 1476068067.767661: Response was from master KDC
> [4914] 1476068067.767685: Received error from KDC: -1765328359/Additional
> pre-authentication required
> [4914] 1476068067.767730: Processing preauth types: 136, 19, 2, 133
> [4914] 1476068067.767742: Selected etype info: etype aes256-cts, salt
> "k},(k&+qA)Mosf6z", params ""
> [4914] 1476068067.767747: Received cookie: MIT
> Password for admin@IPA.IPASERVER.LOCAL:
> 
> this is working fine.
> =
> 
> 
> it looks for password-based authentication requests, the IPA clients
> connect directly to the AD servers using Kerberos.
> 
> then there is port firewall opening required  between ipaclinet and AD
> Server as well. Is it required ? OR I am doing something wrong.

Yes, IPA clients need to talk to AD servers as well. Please see
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-requirements.html#trust-req-ports


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

Re: [Freeipa-devel] Build system refactoring - design document

[Petr Spacek]

On 7.10.2016 12:59, Martin Basti wrote:
> 
> 
> On 07.10.2016 11:56, Petr Spacek wrote:
>> Dear FreeIPA developers and packagers,
>>
>> you can find first version of the Build system refactoring design document 
>> on:
>> http://www.freeipa.org/page/V4/Build_system_refactoring
>>
>> If you do not care about implementation details, please be so kind and 
>> quickly
>> scan through chapter
>> http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management
>>
>> I'm not an FreeIPA packager so I might miss some important thing which needs
>> to be configurable.
>>
>>
>> Also, I would appreciate ideas how to handle build versioning:
>> http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning
>>
>> My main questions are:
>> * What is triggering IPA upgrade?
>> * Would it be sufficient to bump release in RPM? (I mean - theoretically.
>> Could the code be modified to detect this?)
>>
>> Here I'm trying to avoid unnecessary rebuilds caused by changes to
>> IPA_VENDOR_VERSION during each build.
>>
>>
>> Timo, what can I do to help you with packaging for Ubuntu/Debian?
>>
>> Dream big, even wild ideas are welcome!
>>
> 
> Thank you for nice design,
> 
> 1)
> I'd like to have make clean as well (we have it there now, but I don't think
> that it works well)

I've added clean to the list. In general, we should get all targets listed in
https://www.gnu.org/software/automake/manual/html_node/Standard-Targets.html
"for free" (if we do it right).


> 2)
> Pylint:
> 
> currently we have (almost) python2/3 compatible code so what is the reason to
> have python2 and python3 separated checks? Pylint is doing that at once

I'm fine with just one pylint. Design updated:
http://www.freeipa.org/page/V4/Build_system_refactoring#Configuration

Thank you for clarification!

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

Re: [Freeipa-devel] Build system refactoring - design document

[Petr Spacek]

On 7.10.2016 11:56, Petr Spacek wrote:
> Dear FreeIPA developers and packagers,
> 
> you can find first version of the Build system refactoring design document on:
> http://www.freeipa.org/page/V4/Build_system_refactoring
> 
> If you do not care about implementation details, please be so kind and quickly
> scan through chapter
> http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management
> 
> I'm not an FreeIPA packager so I might miss some important thing which needs
> to be configurable.
> 
> 
> Also, I would appreciate ideas how to handle build versioning:
> http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning
> 
> My main questions are:
> * What is triggering IPA upgrade?
> * Would it be sufficient to bump release in RPM? (I mean - theoretically.
> Could the code be modified to detect this?)
> 
> Here I'm trying to avoid unnecessary rebuilds caused by changes to
> IPA_VENDOR_VERSION during each build.
> 
> 
> Timo, what can I do to help you with packaging for Ubuntu/Debian?
> 
> Dream big, even wild ideas are welcome!

Also, if you are packager or tester, please describe your
requirements/use-cases/user stories/whatever so I can design the system to
suit your needs.

I've tried to capture developer's needs to
http://www.freeipa.org/page/V4/Build_system_refactoring#User_stories

Please let me know if you are okay with that or if it needs corrections.

Thank you for your time!

-- 
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] Build system refactoring - design document

[Petr Spacek]

Dear FreeIPA developers and packagers,

you can find first version of the Build system refactoring design document on:
http://www.freeipa.org/page/V4/Build_system_refactoring

If you do not care about implementation details, please be so kind and quickly
scan through chapter
http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management

I'm not an FreeIPA packager so I might miss some important thing which needs
to be configurable.


Also, I would appreciate ideas how to handle build versioning:
http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning

My main questions are:
* What is triggering IPA upgrade?
* Would it be sufficient to bump release in RPM? (I mean - theoretically.
Could the code be modified to detect this?)

Here I'm trying to avoid unnecessary rebuilds caused by changes to
IPA_VENDOR_VERSION during each build.


Timo, what can I do to help you with packaging for Ubuntu/Debian?

Dream big, even wild ideas are welcome!

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

Re: [Freeipa-devel] CA-less installs: passive certmonger - watch-and-warn mode

[Petr Spacek]

On 18.7.2016 08:22, Jan Cholasta wrote:
> On 8.7.2016 15:59, Rob Crittenden wrote:
>> Petr Spacek wrote:
>>> On 8.7.2016 15:31, Rob Crittenden wrote:
>>>> Petr Spacek wrote:
>>>>> Hi,
>>>>>
>>>>> our docs
>>>>>
>>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-determine-ca
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> claim this:
>>>>> "The certmonger service is not used to track certificates.
>>>>> Therefore, it does
>>>>> not warn you of impending certificate expiration."
>>>>>
>>>>> Is this correct?
>>>>>
>>>>> Can we at least configure certmonger to passively track the
>>>>> certificates and
>>>>> throw warning about impending expiration into logs?
> 
> +1, I have already suggested we do this several times.
> 
>>>>>
>>>>
>>>> Throw a warning where? Register an e-mail address as part of the
>>>> tracking
>>>> perhaps?
>>>>
>>>> It would probably be fairly easy to write a "CA" that sends an
>>>> e-mail. The
>>>> trick, and this has always tripped us up, is having an MTA configured.
>>>
>>> I would start with logs, as I wrote in the original message. This will
>>> naturally evolve into something else when we finally get
>>> user-configurable hooks.
>>>
>>> In any case, having certmonger configured to track the certs is
>>> prerequisite
>>> for all cases...
>>
>> "Logs" is not very specific, do you mean syslog/journal?
>>
>> Feel free to open an RFE against certmonger with your proposal. I
>> suspect that anything logged will just get lost in most cases.

Finally, here is the ticket:
https://fedorahosted.org/certmonger/ticket/59

> For IPA CA certificate, we log warnings to syslog with ALERT level. I think
> doing that for other certs would be good enough for starters.

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

Re: [Freeipa-devel] pylint: remove unused variables

[Petr Spacek]

On 23.9.2016 07:28, Jan Cholasta wrote:
> On 22.9.2016 16:39, Martin Basti wrote:
>> Hello all,
>>
>> In 4.5, I would like to remove all unused variables from code and enable
>> pylint check. Due to big amount of unused variables in the code this
>> will be longterm effort.
>>
>> Why this?:
>>
>> * better code readability
>>
>> * removing dead code
>>
>> * unused variable may uncover potential bug
>>
>>
>> It is clear what to do with unused assignments, but I need an agreement
>> what to do with unpacking or iteration with unused variables
>>
>>
>> For example:
>>
>> for name, surname, gender in (('Martin', 'Basti', 'M'), ):
>>
>> name, surname, gender = user['mbasti']
>>
>> Where 'surname' is unused
>>
>>
>> Pylint will detect surname as unused variable and we have to agree on a
>> way how to tell pylint that this variable is unused on purpose:
>>
>>
>> 1)
>>
>> (
>>
>>name,
>>
>>surname,  # pylint: disable=unused-variable
>>
>>gender
>>
>> ) = user['mbasti']
>>
>>
>> I dont like this approach
> 
> +1
> 
>>
>>
>> 2)
>>
>> Use defined keyword: 'dummy' is default in pylint, we can set our own,
>> like ignored, unused
>>
>> name, dummy, gender = user['mbasti']
> 
> -1, not visible enough.
> 
>>
>>
>> 3)
>>
>> use a prefix for unused variables: '_' or 'ignore_'
>>
>> name, _surname, gender = user['mbasti']
> 
> This. We have already been using it in new code for quite some time, and it's
> common in other Python projects too. Don't reinvent the wheel.
> 
>>
>>
>> 4)
>>
>> we can combine all :)
>>
>>
>> For me the best is to have prefix '_' and 'dummy' keyword
> 
> Use '_dummy', it's both :-)

I like "__". If it is not acceptable for rest of the team, I would be okay
with _dummy. I would even use _dummy multiple times:
> name, _dummy, _dummy = user['mbasti']
so namespace is not polluted and garbage collector can do the right thing.

Petr^2 Spacek


>> As first step I'll enable pylint check and disable it locally per module
>> where unused variables are, to avoid new regressions. Then I will fix it
>> module by module.
>>
>>
>> I'm open to suggestions
>>
>> Martin^2

-- 
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] [DESIGN] Text-based rules for CSR autogeneration using Jinja2

[Petr Spacek]

On 2.9.2016 04:19, Ben Lipton wrote:
> On 07/27/2016 02:42 PM, Ben Lipton wrote:
>> On 07/21/2016 11:43 AM, Petr Spacek wrote:
>>> Besides this nit,
>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Mapping_Rules#Planned_implementation
>>>
>>> sounds reasonable. I like how it prevents bad data from template-injection.
>>
>> That's what I like about it, too. It does turn out to make things a little
>> tricky when it comes to writing rules that won't render if the data they
>> depend on is unavailable. (Because instead of rendering individual rules
>> which we can drop if they're missing data, we build one big template that
>> has to handle missing data correctly on its own.) I think it's probably
>> still worth it, though. I added this to the "Alternatives considered"
>> section of the above document.
> 
> By the way, I just wrote a followup blog post on this subject: describing the
> challenges I've had with suppressing rules when the data isn't available, and
> wondering if it's worth it. The post is here:
> http://blog.benjaminlipton.com/2016/09/01/rule-suppression.html. It might be a
> bit of a dense read, but I wanted to have the considerations documented at
> least. As always, please let me know if there's anything I can clarify. And if
> you do happen to read it and it makes you prefer one solution over the others,
> I'd love to hear your opinion.

Hello Ben,

my comments are in-line (text copied from the blog post):

> Conclusions
> 
> The current implementation is working ok, but the “Declaring data 
> dependencies” solution is also appealing. Recording in data rules what data 
> they depend on is only slightly more involved than wrapping that reference in 
> ipa.datafield(), and could also be useful for other purposes.

I agree that syntax with explicit "if"s is little bit more elaborate. On the
other hand, the explicit condition is easier to read (for me) because I can
see what it is doing directly - I do not remember meaning of magical IPA macros.

I.e. I like version with explicit "if"s more.

> Plus, it would get rid of the empty sections in openssl configs, as well as
some of the complex macros.

+1

> The extra templating and new tags required to get rid of extra commas and 
> newlines don’t seem worth it to me, unless we discover a version of openssl 
> or certutil that can’t consume the current output.

I definitely agree.


> Finally, I think the number of hoops needing to be jumped through to 
> fine-tune the output format hint at this “template interpolation” approach 
> being less successful than originally expected. While it was expected that 
> inserting data rule templates into syntax rule templates and rendering the 
> whole thing would produce similar results to rendering data rules first and 
> inserting the output into syntax rules, that is not turning out to be the 
> case. It might be wise to reconsider the simpler option - it may be easier to 
> implement reliable jinja2 template markup escaping than to build templates 
> smart enough to handle any combination of data that’s available.

This is certainly something to think about. Personally I think that version
with explicit "if"s is easy to understandad, write, and also it has no risk of
data injection (AFAIK).

Explicit escaping is usually very error prone... but I'm not in position to
judge how user-friendly it would be when compared with other solutions. After
all, goal of the feature is to make life of an average admin easier :-)


I hope this brain-dump will help you somehow :-) Have a nice day!

-- 
Petr^2 Spacek

P.S. I will not be available in next two weeks, sorry!

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

[Petr Spacek]

On 2.9.2016 05:22, Fraser Tweedale wrote:
> On Thu, Sep 01, 2016 at 07:37:53PM +0200, Tomas Krizek wrote:
>> On 09/01/2016 03:58 PM, Florence Blanc-Renaud wrote:
>>> Hi,
>>>
>>> please find attached a patch for ipa-certupdate in CA-less deployment.
>>> https://fedorahosted.org/freeipa/ticket/6288
>>>
>>> Flo.
>>>
>>>
>>>
>> The patch is malformed, but you can simply delete the very first character
>> to fix it.
>>
>> Other than that, patch works as expected -> ACK.
>>
> The patch malformation is caused by Thunderbird.  See [1] for how to
> configure Thunderbird (and Mutt) to not add the '>'.
> 
> [1] 
> http://www.freeipa.org/page/Contribute/Patch_Format#Ensuring_correct_transmission_of_patches

Or even better, abandon patches and start using pull requests:
http://www.freeipa.org/page/Pull_request_on_Github

:-)

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

Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

[Petr Spacek]

On 1.9.2016 14:09, Standa Laznicka wrote:
> On 09/01/2016 01:26 PM, Standa Laznicka wrote:
>> On 08/31/2016 12:57 PM, Petr Spacek wrote:
>>> On 31.8.2016 12:42, Standa Laznicka wrote:
>>>> On 08/30/2016 03:34 PM, Simo Sorce wrote:
>>>>> On Tue, 2016-08-30 at 08:47 +0200, Standa Laznicka wrote:
>>>>>> On 08/26/2016 05:37 PM, Simo Sorce wrote:
>>>>>>> On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote:
>>>>>>>> On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote:
>>>>>>>>> On Fri, 26 Aug 2016, Simo Sorce wrote:
>>>>>>>>>> On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote:
>>>>>>>>>>>> I miss "why" part of "To be able to handle backward compatibility
>>>>>>>>>>> with
>>>>>>>>>>>> ease, a new object called ipaHBACRulev2 is introduced. " in the
>>>>>>>>>>> design
>>>>>>>>>>>> page. If the reason is the above - old client's should ignore time
>>>>>>>>>>> rules
>>>>>>>>>>>> then it has to be mentioned there. Otherwise I don't see a reason 
>>>>>>>>>>>> to
>>>>>>>>>>>> introduce a new object type instead of extending the current.
>>>>>>>>>>> How do you want to enforce HBAC rule that have set time from 10 to 
>>>>>>>>>>> 14
>>>>>>>>>>> everyday? With the same objectclass old clients will allow this HBAC
>>>>>>>>>>> for
>>>>>>>>>>> all day. Isn't this CVE?
>>>>>>>>>> This is a discussion worth having.
>>>>>>>>>>
>>>>>>>>>> In general it is a CVE only if an authorization mechanism fails to 
>>>>>>>>>> work
>>>>>>>>>> as advertised.
>>>>>>>>>>
>>>>>>>>>> If you make it clear that old clients *DO NOT* respect time rules 
>>>>>>>>>> then
>>>>>>>>>> there is no CVE material, it is working as "described".
>>>>>>>>>>
>>>>>>>>>> The admins already have a way to not set those rules for older 
>>>>>>>>>> clients
>>>>>>>>>> by simply grouping newer clients in a different host group and 
>>>>>>>>>> applying
>>>>>>>>>> time rules only there.
>>>>>>>>>>
>>>>>>>>>> So the question really is: should we allow admins to apply an HBAC 
>>>>>>>>>> Rule
>>>>>>>>>> potentially to older clients that do not understand it and will
>>>>>>>>>> therefore allow access at any time of the day, or should we prevent
>>>>>>>>>> it ?
>>>>>>>>>>
>>>>>>>>>> This is a hard question to answer and can go both ways.
>>>>>>>>>>
>>>>>>>>>> A time rule may be something that admins want to enforce at all cost 
>>>>>>>>>> or
>>>>>>>>>> deny access. In this case a client that fails to handle it would be a
>>>>>>>>>> problem.
>>>>>>>>>>
>>>>>>>>>> But it may be something that is just used for defense in depth and
>>>>>>>>>> not a
>>>>>>>>>> strictly hard requirement. In this case allowing older clients would
>>>>>>>>>> make it an easy transition as you just set up the rule and the client
>>>>>>>>>> will start enforcing the time when it is upgraded but work otherwise
>>>>>>>>>> with the same rules.
>>>>>>>>>>
>>>>>>>>>> I am a bit conflicted on trying to decide what scenario we should
>>>>>>>>>> target, but the second one appeals to me because host groups do 
>>>>>>>>>> already
>>>>>>>>>> give admins a good way to apply rules to a specific set of hosts and
>>>>>>>>>> exclude old 

Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

[Petr Spacek]

On 31.8.2016 12:42, Standa Laznicka wrote:
> On 08/30/2016 03:34 PM, Simo Sorce wrote:
>> On Tue, 2016-08-30 at 08:47 +0200, Standa Laznicka wrote:
>>> On 08/26/2016 05:37 PM, Simo Sorce wrote:
 On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote:
> On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote:
>> On Fri, 26 Aug 2016, Simo Sorce wrote:
>>> On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote:
> I miss "why" part of "To be able to handle backward compatibility
 with
> ease, a new object called ipaHBACRulev2 is introduced. " in the
 design
> page. If the reason is the above - old client's should ignore time
 rules
> then it has to be mentioned there. Otherwise I don't see a reason to
> introduce a new object type instead of extending the current.
 How do you want to enforce HBAC rule that have set time from 10 to 14
 everyday? With the same objectclass old clients will allow this HBAC
 for
 all day. Isn't this CVE?
>>> This is a discussion worth having.
>>>
>>> In general it is a CVE only if an authorization mechanism fails to work
>>> as advertised.
>>>
>>> If you make it clear that old clients *DO NOT* respect time rules then
>>> there is no CVE material, it is working as "described".
>>>
>>> The admins already have a way to not set those rules for older clients
>>> by simply grouping newer clients in a different host group and applying
>>> time rules only there.
>>>
>>> So the question really is: should we allow admins to apply an HBAC Rule
>>> potentially to older clients that do not understand it and will
>>> therefore allow access at any time of the day, or should we prevent it ?
>>>
>>> This is a hard question to answer and can go both ways.
>>>
>>> A time rule may be something that admins want to enforce at all cost or
>>> deny access. In this case a client that fails to handle it would be a
>>> problem.
>>>
>>> But it may be something that is just used for defense in depth and not a
>>> strictly hard requirement. In this case allowing older clients would
>>> make it an easy transition as you just set up the rule and the client
>>> will start enforcing the time when it is upgraded but work otherwise
>>> with the same rules.
>>>
>>> I am a bit conflicted on trying to decide what scenario we should
>>> target, but the second one appeals to me because host groups do already
>>> give admins a good way to apply rules to a specific set of hosts and
>>> exclude old clients w/o us making it a hard rule.
>>> OTOH if an admin does not understand this difference, they may be
>>> surprised to find out there are clients that do not honor it.
>>>
>>> Perhaps we could find a way to set a flag on the rule such that when set
>>> (and only when set) older clients get excluded by way of changing the
>>> objectlass or something else to similar effect.
>>>
>>> Open to discussion.
>> At this point using new object class becomes an attractive approach. We
>> don't have means to exclude HBAC rules other than applying them
>> per-host/hostgroup. We also have no deny rules.
>>
>> I have another idea: what about enforcing time rules always to apply
>> per-host or per-hostgroup by default? Add --force option to override the
>> behavior but default to not allow --hostcat=all. This would raise
>> awareness and make sure admins are actually applying these rules with
>> intention.
> This sounds like a good idea, but it is not a silver bullet I am afraid.
>
> Simo.
 I was thinking that for future proofing we could add a version field,
 then reasoned more and realized that changing the object class is
 basically the same thing.

 There is only one big problem, ipaHBACRule is a STRUCTURAL objectclass.
 (I know 389ds allows us to do an LDAPv3 illegal operation and change it,
 but I do not like to depend on that behavoir).

 Now looking into this I had an idea to solve the problem of legacy
 clients without having to swap classes.
 We can redefine the accessRuleType attribute to be a "capability" type.

 Ie rules that have a timeAccess component will be of type
 "allow_with_time" instead of just "allow".
 Old clients are supposed to search with accessRuleType=allow (and I can
 see that SSSD does that), so an older client will fail to get those
 rules as they won't match.

 New clients instead can recognize both types.

 Also if we need a future extension we will simpy add a new access rule
 type and we can have the same effect.
 The nice thing is that accessRyleType is defined as multivalue (no
 SINGLE in schema) so we may actually create compatible rules if we want
 to.
 Ie we could set both "allow" and 

Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

[Petr Spacek]

On 29.8.2016 16:34, Simo Sorce wrote:
> On Mon, 2016-08-29 at 09:13 +0200, Petr Spacek wrote:
>> On 26.8.2016 17:40, Simo Sorce wrote:
>>> On Fri, 2016-08-26 at 11:37 -0400, Simo Sorce wrote:
>>>> Ie we could set both "allow" and "allow_with_time" on an object for
>>>> cases where the admin wants to enforce the time part only o newer
>>>> client
>>>> but otherwise apply the rule to any client.
>>>
>>> I notice that SSSD does not like it if there are multiple values on this
>>> attribute, but we could change this easily in older clients when we
>>> update them. worst case the rule will not apply and admins have to
>>> create 2 rules, one with allow and one with allow_with_time.
>>
>> I like the idea in general but it needs proper design and detailed
>> specification first.
>>
>> Given that we have to modify SSSD anyway, I would go for ipaHBACRulev2 object
>> class with clear definition of "capabilities" (without any obsolete cruft).
>>
>> That should be future proof and without any negative impact to existing 
>> clients.
> 
> ipaHBACRule2 is needed anyway, it is just how it is implemented that
> differs, I really think we should go the accessRuleType route, I find it
> superior to messing with objects by ripping off structural objectclasses
> and replacing them.

So we are in agreement ;-)

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

Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

[Petr Spacek]

On 26.8.2016 17:40, Simo Sorce wrote:
> On Fri, 2016-08-26 at 11:37 -0400, Simo Sorce wrote:
>> Ie we could set both "allow" and "allow_with_time" on an object for
>> cases where the admin wants to enforce the time part only o newer
>> client
>> but otherwise apply the rule to any client.
> 
> I notice that SSSD does not like it if there are multiple values on this
> attribute, but we could change this easily in older clients when we
> update them. worst case the rule will not apply and admins have to
> create 2 rules, one with allow and one with allow_with_time.

I like the idea in general but it needs proper design and detailed
specification first.

Given that we have to modify SSSD anyway, I would go for ipaHBACRulev2 object
class with clear definition of "capabilities" (without any obsolete cruft).

That should be future proof and without any negative impact to existing clients.

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

Re: [Freeipa-devel] FreeIPA wiki - fighting the spammers

[Petr Spacek]

On 18.8.2016 16:25, Martin Kosek wrote:
> Hello everyone,
> 
> As some of you noticed, we had lately an increasing number of spam attacks
> against FreeIPA.org wiki. Even though we did not accept user registration
> through the standard Mediawiki User Creation form (which is often misused by
> attacked) and only allow Fedora users logged in by OpenID, the spam producers
> started to favor this authentication mode too.
> 
> This week and especially yesterday, the spam activity was high enough to
> warrant a "drastic change" in how we allow wiki modifications. Me and Petr
> Vobornik had to react quickly yesterday to hundreds of new spam-based pages
> (thanks to Petr for deleting the spam pages, Stephen for altering us and
> Patrick Uiterwijk for advising us!).
> 
> As a prevention for future attacks, I also needed to chose the most simple and
> convenient method to stop spammers from editing wiki. This is the result:
> 
> - Anonymous and regular users are no longer allowed to create or edit wiki 
> pages
> - Anyone who wants to be able to edit wiki needs to be in a new "editor" group
> 
> The full description of new group rights is here:
> http://www.freeipa.org/page/Special:ListGroupRights
> 
> I added the contributors active in the last 30 days to the editor group. If
> more people are needed, wiki "Bureaucrats" can it through this form:
> http://www.freeipa.org/page/Special:UserRights
> 
> If you do not know who is in the Bureaucrat group, this is the list:
> http://www.freeipa.org/index.php?title=Special%3AListUsers==bureaucrat=50
> 
> The model I had in mind was that new wiki contributors would ask for access on
> #freeipa IRC channel, when they have some content to be added to the pages. We
> should probably add that suggestion to the wiki somewhere.
> 
> I hope this works for you. If you have comments on above or even better ideas
> what is the easiest way to fight spam on our precious wiki, please let me 
> know.

In general I agree.

My attempt to edit "permission denied" error using
http://www.freeipa.org/page/Special:AllMessages
failed so I do not know.

For the beginning, I added note about this new process to
http://www.freeipa.org/page/Contribute#Contribute_documentation
and link to the process page to
http://www.freeipa.org/page/HowTo/Writing_how_to_documentation_on_the_wiki


Now the question is how to make information about getting edit access *really
visible*. Is this enough? I'm not sure.

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

Re: [Freeipa-devel] [PATCH 689] tests: fix test_ipalib.test_frontend.test_Object

[Petr Spacek]

On 18.8.2016 10:08, Jan Cholasta wrote:
> SSIA

Could you add one sentence or a link to a ticket which forced this change?

When reading the patch, I have no way to say why the change is necessary - so
it is impossible to verify correctness. (Sure, the test will pass, but I have
no way to distinguish incorrect test passing on incorrect implementation vs.
correct test passing on correct implementation.)

-- 
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] Announcing bind-dyndb-ldap version 10.1

[Petr Spacek]

The FreeIPA team is proud to announce bind-dyndb-ldap version 10.1.

It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/

The new version has also been built for Fedora 24+:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-ea30aafae1


Latest news:

10.1

[1] Prevent crash while reloading previously invalid but now valid DNS zone.
https://fedorahosted.org/bind-dyndb-ldap/ticket/166

[2] Fix zone removal to respect forward configuration inheritance.
https://fedorahosted.org/bind-dyndb-ldap/ticket/167

10.0

[1] Default TTL can be configured at zone level in dNSdefaultTTL attribute.
Please note that changes may not be applied until server reload.
https://fedorahosted.org/bind-dyndb-ldap/ticket/70

[2] Certain subset of configuration options can be specified
in idnsServerConfigObject in LDAP. Each bind-dyndb-ldap instance will
only use values from object with idnsServerId attribute matching server_id
configured in named.conf. This can be used for per-server configuration
in shared LDAP tree.
https://fedorahosted.org/bind-dyndb-ldap/ticket/162

[2] fake_mname option can be specified in idnsServerConfigObject in LDAP.
Please note that changes may not be applied until server reload.
https://fedorahosted.org/bind-dyndb-ldap/ticket/162

[3] Per-server global forwarders can be configured in idnsServerConfigObject.
https://fedorahosted.org/bind-dyndb-ldap/ticket/162

[4] Dynamic record generation using idnsTemplateObject and
idnsSubstitutionVariable;ipalocation attribute from idnsServerConfigObject
is supported. Please see README.
Please note that changes may not be applied until server reload.
https://fedorahosted.org/bind-dyndb-ldap/ticket/126

[5] Forwarding configuration is properly ignored for disabled master zones.

[6] Interaction between DNS root zone and global forwarding is now
deterministic and root zone has higher priority over global forwarding.

[7] Various problems in internal event processing were fixed.

[8] Potential crash in early start-up phase was fixed.

[9] Compatibility with BIND >= 9.10.4b1 was improved


== Upgrading ==
A server can be upgraded by installing updated RPM. BIND has to be restarted
manually after the RPM installation.

Downgrading back to any 9.x version is supported as long as new features are
not used.

FreeIPA users have to upgrade to version 10.0 or newer before enabling 'DNS
locations' feature in FreeIPA.


== Advance notification: Limited compatibility with BIND 9 ==
Please note that bind-dyndb-ldap 10.x is the last branch compatible with
BIND 9.10 or older.

bind-dyndb-ldap version 11.0 will be compatible only with BIND 9.11 and newer.
At the same time, version 11.0 will introduce incompatible changes to
configuration format.


== Feedback ==
Please provide comments, report bugs, and send any other feedback via the
freeipa-users mailing list:
http://www.redhat.com/mailman/listinfo/freeipa-users

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

Re: [Freeipa-devel] [PATCH] 0207, 0218-0219 Solving trust conflicts and external trust topology fixes

[Petr Spacek]

On 17.8.2016 12:41, Alexander Bokovoy wrote:
> On Wed, 17 Aug 2016, Martin Babinsky wrote:
>> On 08/15/2016 06:06 PM, Alexander Bokovoy wrote:
>>> On Mon, 15 Aug 2016, Alexander Bokovoy wrote:
 Hi!

 Attached are trust-related patches.

 0207 is a pre-requisite. I did send it before, it is re-formatting of
 the ipaserver/dcerpc.py to be close to PEP8 requirements.

 0218 is an automated trust topology conflict resolver for DNS namespace
 conflicts. Read the commit message for details, and also comments in the
 code. With this patch FreeIPA becomes more smart than Windows Server
 which doesn't have automated trust topology conflict resolution. ;)

 0219 fixes issue of topology details leaking through external trust. The
 problem is only in presentation as we store more data than needed -- it
 is impossible to cross external trust boundary anyway as it is handled
 by AD DC side, but one important consequence is that we need to store
 UPN suffixes before we start storing information about child domains.
 Again, read the commit message.

 These patches also are on top of my previously sent patches 0215-0216.
>>> Patches attached.
>>>
>>>
>>>
>>
>> Hi Alexander,
>>
>> patch 207: LGTM, but I have a feeling that the patch should be linked to
>> both #6021 and #6076 so that it is not lost during backports.
>>
>> patch 218:
>>
>> ipalib/errors.py:
>>
>> 1.)
>> I'm not sure if TrustTopologyConflictError should inherit from
>> InvocationError. The semantics of InvocationError implies that something was
>> wrong when trying to invoke the command (a param failed to validate/convert,
>> incorrect number of args, etc.), while this is more of an exception during
>> command execution (no. and type of params was correct, command started to
>> execute but encountered an error condition). Thus I think it should inherit
>> from ExecutionError. CC'ing Jan for more thoughts on this.
>>
>> 2.)
>>
>> Why is TrustTopologyConflictSolved listed amogn public errors? Since it is
>> used only in dcerpc.py to restart trust establishment after resolving
>> conflicts, it should be a private exception in dcerpc.py for this purpose.
>>
>> 3.)
>> Also please split the exception format string like this so that the line is
>> not too long (there is not much we can do about doctest so leave that line
>> as it is):
>>
>> @@ -882,7 +882,8 @@ class TrustTopologyConflictError(InvocationError):
>> """
>>
>> errno = 3017
>> -format = _("Forest '%(forest)s' has existing trust to forest(s)
>> %(domains)s which prevents a trust to '%(conflict)s'")
>> +format = _("Forest '%(forest)s' has existing trust to forest(s) "
>> +   "%(domains)s which prevents a trust to '%(conflict)s'")
>>
>> Do not worry about gettext, it can handle it just fine, there are plenty of
>> examples in server plugins, for example.
>>
>>
>> ipaserver/dcerpc.py:
>>
>> 1.)
>>
>> I think that instead of returning result and raising
>> TrustTopologyConflictError based on that, the 'clear_ftinfo_conflict' can
>> raise this exception directly. You can have an empty list defined at the
>> beginning instead of 'result list', append unresolvable conflicts to it and
>> then at the end of the method check if it is non-empty and raise the 
>> exception.
>>
>> 2.)
>>
>> +# In the code below:
>> +# self -- the forest we establish trust to
>> +# another_domain -- a forest that establishes trust to 'self'
>> +# cinfo -- lsa_ForestTrustCollisionInfo structure that contain
>> +#  set of of lsa_ForestTrustCollisionRecord structures
>> I would add this directly into the method docstring:
>>
>> """
>> ...
>>
>> :param self: the forest we establish trust to
>> :param another_domain: a forest that establishes trust to 'self'
>> :param cinfo: lsa_ForestTrustCollisionInfo structure that contain
>>   set of of lsa_ForestTrustCollisionRecord structures
>> """
>>
>> Additionally, the behavior specifed in previous comment can be added using
>> :raises: stanza:
>>
>> """
>> :raises: errors.TrustTopologyConflictError if there are unresolvable
>>namespace conflicts between trusted domains
>> """
>>
>> 3.)
>>
>> rewriting 'clear_ftinfo_conflict' according to point 1.) will allow to
>> simplify code in 'update_ftinfo' like this:
>>
>> """
>> -res = self.clear_ftinfo_conflict(another_domain, cinfo)
>> -if len(res[1]) != 0:
>> -domains = [x.name.string for x in res[1]]
>> -raise errors.TrustTopologyConflictError(
>> -  target=self.info['dns_domain'],
>> -  conflict=another_domain.info['dns_domain'],
>> -  domains=domains)
>> -else:
>> -raise errors.TrustTopologyConflictSolved(
>> -  target=self.info['dns_domain'],
>> - 

[Freeipa-devel] [PATCH 0435-0436] Preparation for bind-dyndb-ldap 10.1 release

[Petr Spacek]

Hello,

Pushed to master:

d7ae9e2e0206f770dd252c81abdc8b1be3fd30e2 Bump NVR to 10.1.
fddb67672e458c8cbb0fd7997e42f94adb288181 Update NEWS for upcoming 10.1 release.

Tagged as v10.1.

-- 
Petr^2 Spacek
From fddb67672e458c8cbb0fd7997e42f94adb288181 Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Wed, 17 Aug 2016 12:31:19 +0200
Subject: [PATCH] Update NEWS for upcoming 10.1 release.

---
 NEWS | 8 
 1 file changed, 8 insertions(+)

diff --git a/NEWS b/NEWS
index 32414b8a5cd466619b0b875df5ac19fd660c6512..12aa18ab63a99c4de3e267e8cd307981baed1e90 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,11 @@
+10.1
+
+[1] Prevent crash while reloading previously invalid but now valid DNS zone.
+https://fedorahosted.org/bind-dyndb-ldap/ticket/166
+
+[2] Fix zone removal to respect forward configuration inheritance.
+https://fedorahosted.org/bind-dyndb-ldap/ticket/167
+
 10.0
 
 [1] Default TTL can be configured at zone level in dNSdefaultTTL attribute.
-- 
2.7.4

From d7ae9e2e0206f770dd252c81abdc8b1be3fd30e2 Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Wed, 17 Aug 2016 12:31:35 +0200
Subject: [PATCH] Bump NVR to 10.1.

---
 configure.ac | 2 +-
 contrib/bind-dyndb-ldap.spec | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 6cdcefe2139537d912a3ed034638c9cbf6224922..9b2605871143ba090e9276d01cc28041d45eaa04 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
 AC_PREREQ([2.59])
-AC_INIT([bind-dyndb-ldap], [10.0], [freeipa-devel@redhat.com])
+AC_INIT([bind-dyndb-ldap], [10.1], [freeipa-devel@redhat.com])
 
 AM_INIT_AUTOMAKE([-Wall foreign dist-bzip2])
 
diff --git a/contrib/bind-dyndb-ldap.spec b/contrib/bind-dyndb-ldap.spec
index 063296611f6bc9c298911839e5228d1270d43c1b..f72cc11c57db751277d23729eaafe15645bd0551 100644
--- a/contrib/bind-dyndb-ldap.spec
+++ b/contrib/bind-dyndb-ldap.spec
@@ -1,7 +1,7 @@
 %define VERSION %{version}
 
 Name:   bind-dyndb-ldap
-Version:10.0
+Version:10.1
 Release:0%{?dist}
 Summary:LDAP back-end plug-in for BIND
 
-- 
2.7.4

-- 
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 0433-0434] Fix zone removal to respect forward configuration inheritance + Remove preserve_forwarding parameter from ldap_delete_zone2()

[Petr Spacek]

On 17.8.2016 10:26, Martin Sehnoutka wrote:
> I checked the code. ACK

Thanks, pushed to master:
d6e413c4cc88101b902d73e05e1ce35e2fe4aedd Fix zone removal to respect forward
configuration inheritance.
b40976263460d8f4aeeec2a2a8f41cc54dcd0b28 Remove preserve_forwarding parameter
from ldap_delete_zone2().

Petr^2 Spacek

> 
> Martin
> 
> On 08/12/2016 12:37 PM, Petr Spacek wrote:
>> Hello,
>>
>> please review attached patch set. It fixes
>> https://fedorahosted.org/bind-dyndb-ldap/ticket/167
>>
>> The code is also available on Github:
>> https://github.com/pspacek/bind-dyndb-ldap/tree/fix_root_zone_removal
>>
>> Patched SRPM:
>> https://pspacek.fedorapeople.org/bind-dyndb-ldap/bind-dyndb-ldap-10.0-3.fc24.src.rpm
>>
>> COPR build:
>> https://copr.fedorainfracloud.org/coprs/pspacek/bind-dyndb-ldap/build/440841/
>>
>> Martin Basti, please build it also in @freeipa/freeipa-master COPR so CI can
>> pick it up. Thank you!
>>
>>
>> Patch set description:
>> Fix zone removal to respect forward configuration inheritance.
>>
>> Ad-hoc fwd_delete_table() calls did not respect inheritance hierarchy
>> in forwarding configuration. Now all manipulation with forward table
>> is done in fwd_configure_zone() and fully respects configuration inheritance.
>>
>> There is a trick: When removing or deactivating a zone, fwd_configure_zone()
>> is called with empty configuration set to simulate that the zone does
>> not have any explicit configuration. This triggers the inheritance
>> logic when necessary (i.e. for the root zone).
>>
>> https://fedorahosted.org/bind-dyndb-ldap/ticket/167
>> https://github.com/pspacek/bind-dyndb-ldap/commit/d6e413c4cc88101b902d73e05e1ce35e2fe4aedd
>>
>>
>>
>> Remove preserve_forwarding parameter from ldap_delete_zone2().
>>
>> The parameter was TRUE only when called from zone_security_change().
>> zone_security_change() is calling ldap_delete_zone2() in exclusive mode
>> anyway so there is no need to optimize this.
>>
>> Removal of the parameter will make easier to centralize forwarding
>> configuration on one place.
>>
>> https://fedorahosted.org/bind-dyndb-ldap/ticket/167
>> https://github.com/pspacek/bind-dyndb-ldap/commit/b40976263460d8f4aeeec2a2a8f41cc54dcd0b28


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

Re: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation

[Petr Spacek]

On 16.8.2016 02:07, Fraser Tweedale wrote:
> On Mon, Aug 15, 2016 at 03:58:40PM +0200, Petr Spacek wrote:
>> On 15.8.2016 15:54, Fraser Tweedale wrote:
>>> On Mon, Aug 15, 2016 at 03:31:20PM +0200, Petr Spacek wrote:
>>>> On 15.8.2016 15:16, Fraser Tweedale wrote:
>>>>> On Mon, Aug 15, 2016 at 02:52:46PM +0200, Petr Spacek wrote:
>>>>>> On 2.8.2016 05:57, Fraser Tweedale wrote:
>>>>>>>>> Hah! This is what I get for thinking I know what the output has to 
>>>>>>>>> look
>>>>>>>>> like, and not testing all the way through to requesting the cert. I'll
>>>>>>>>> change the profile to generate a subject with CN= instead of UID=. 
>>>>>>>>> Updated
>>>>>>>>> patch is attached. Unfortunately these rules are only updated at
>>>>>>>>> ipa-server-install time, so if you'd like to fix it without 
>>>>>>>>> reinstalling:
>>>>>>>>>
>>>>>>> (Tangential commentary...) Yeah, currently cert-request demands the
>>>>>>> CN.  There is a design to relax the requirement to handle empty
>>>>>>> subject names (look at SAN only).  IMO it would make sense to accept
>>>>>>> other "obvious" mappings in Subject DN like accepting UID instead of
>>>>>>> CN for user subjects, but that would be a separate RFE.  Noone has
>>>>>>> actually asked for it yet :)
>>>>>>
>>>>>> Side-note:
>>>>>> I thought that subject format is enforced by certificate profile on 
>>>>>> server.
>>>>>> Am I wrong?
>>>>>>
>>>>> You are right - what I suggested above would (today) require a
>>>>> custom profile.
>>>>
>>>> Sooo...
>>>> can we just relax existing profiles not to require CN= but accept SAN-only 
>>>> CSRs?
>>>>
>>>> :-)
>>>>
>>> That is absolutely going to happen as part of
>>> http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance :)
>>
>> Good!
>>
>> Is it still targeting 4.4.x?
>>
> It's not going to make it.

Ok, I've removed version=4.4.0 tag from
http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance

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

Re: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation

[Petr Spacek]

On 15.8.2016 15:54, Fraser Tweedale wrote:
> On Mon, Aug 15, 2016 at 03:31:20PM +0200, Petr Spacek wrote:
>> On 15.8.2016 15:16, Fraser Tweedale wrote:
>>> On Mon, Aug 15, 2016 at 02:52:46PM +0200, Petr Spacek wrote:
>>>> On 2.8.2016 05:57, Fraser Tweedale wrote:
>>>>>>> Hah! This is what I get for thinking I know what the output has to look
>>>>>>> like, and not testing all the way through to requesting the cert. I'll
>>>>>>> change the profile to generate a subject with CN= instead of UID=. 
>>>>>>> Updated
>>>>>>> patch is attached. Unfortunately these rules are only updated at
>>>>>>> ipa-server-install time, so if you'd like to fix it without 
>>>>>>> reinstalling:
>>>>>>>
>>>>> (Tangential commentary...) Yeah, currently cert-request demands the
>>>>> CN.  There is a design to relax the requirement to handle empty
>>>>> subject names (look at SAN only).  IMO it would make sense to accept
>>>>> other "obvious" mappings in Subject DN like accepting UID instead of
>>>>> CN for user subjects, but that would be a separate RFE.  Noone has
>>>>> actually asked for it yet :)
>>>>
>>>> Side-note:
>>>> I thought that subject format is enforced by certificate profile on server.
>>>> Am I wrong?
>>>>
>>> You are right - what I suggested above would (today) require a
>>> custom profile.
>>
>> Sooo...
>> can we just relax existing profiles not to require CN= but accept SAN-only 
>> CSRs?
>>
>> :-)
>>
> That is absolutely going to happen as part of
> http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance :)

Good!

Is it still targeting 4.4.x?

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

Re: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation

[Petr Spacek]

On 15.8.2016 15:16, Fraser Tweedale wrote:
> On Mon, Aug 15, 2016 at 02:52:46PM +0200, Petr Spacek wrote:
>> On 2.8.2016 05:57, Fraser Tweedale wrote:
>>>>> Hah! This is what I get for thinking I know what the output has to look
>>>>> like, and not testing all the way through to requesting the cert. I'll
>>>>> change the profile to generate a subject with CN= instead of UID=. Updated
>>>>> patch is attached. Unfortunately these rules are only updated at
>>>>> ipa-server-install time, so if you'd like to fix it without reinstalling:
>>>>>
>>> (Tangential commentary...) Yeah, currently cert-request demands the
>>> CN.  There is a design to relax the requirement to handle empty
>>> subject names (look at SAN only).  IMO it would make sense to accept
>>> other "obvious" mappings in Subject DN like accepting UID instead of
>>> CN for user subjects, but that would be a separate RFE.  Noone has
>>> actually asked for it yet :)
>>
>> Side-note:
>> I thought that subject format is enforced by certificate profile on server.
>> Am I wrong?
>>
> You are right - what I suggested above would (today) require a
> custom profile.

Sooo...
can we just relax existing profiles not to require CN= but accept SAN-only CSRs?

:-)

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

Re: [Freeipa-devel] [PATCH] 0090, 0092..0094 cert-show: show subject alternative names

[Petr Spacek]

On 15.8.2016 15:07, Fraser Tweedale wrote:
> On Mon, Aug 15, 2016 at 07:48:22AM +0200, Jan Cholasta wrote:
>> On 12.8.2016 18:57, Petr Spacek wrote:
>>> On 12.8.2016 11:33, Jan Cholasta wrote:
>>>> On 4.8.2016 18:18, Petr Vobornik wrote:
>>>>> On 07/22/2016 07:13 AM, Fraser Tweedale wrote:
>>>>>> On Tue, Jul 19, 2016 at 08:50:34AM +0200, Jan Cholasta wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 14.7.2016 13:44, Fraser Tweedale wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> The attached patch includes SANs in cert-show output.  If you have
>>>>>>>> certs with esoteric altnames (especially any that are more than just
>>>>>>>> ASN.1 string types), please test with those certs.
>>>>>>>>
>>>>>>>> https://fedorahosted.org/freeipa/ticket/6022
>>>>>>>
>>>>>>> I think it would be better to have a separate attribute for each 
>>>>>>> supported
>>>>>>> SAN type rather than cramming everything into subject_alt_name. That 
>>>>>>> way if
>>>>>>> you care only about a single specific type you won't have to go through 
>>>>>>> all
>>>>>>> the values and parse them. Also it would allow you to use param types
>>>>>>> appropriate to the SAN types (DNSNameParam for DNS names, Principal for
>>>>>>> principal names, etc.)
>>>>>>>
>>>>>>> Nitpick: please don't mix moving existing stuff and adding new stuff in 
>>>>>>> a
>>>>>>> single patch.
>>>>>>>
>>>>>> Updated patches attached.
>>>>>>
>>>>>> Patches 0092..0094 are refactors and bugfixes.
>>>>>> Patch 0090-2 is the main feature (depends on 0092..0094).
>>>>>>
>>>>>> Thanks,
>>>>>> Fraser
>>>>>>
>>>>>
>>>>> bump for review
>>>>
>>>> Patch 0092: ACK
>>>>
>>>> Patch 0093: ACK
>>>>
>>>> Patch 0094: ACK
>>>>
>>>> Patch 0090:
>>>>
>>>> 1) Generic otherNames (san_other) do not work correctly. The OID is not
>>>> included in the value and names with complex type other than 
>>>> KerberosPrincipal
>>>> are not parsed correctly. The value should include the OID and DER blob of 
>>>> the
>>>> name.
>>>>
>>>> 2) With --all, san_other should be included in the result for all 
>>>> otherNames,
>>>> even the known ones, to provide (limited) forward compatibility.
>>>>
>>>> 3) Do we have to support *all* the name types? I mean we could, for the 
>>>> sake
>>>> of completeness, but it might be easier to just keep the few ones we 
>>>> actually
>>>> care about (email, DNS name, principal name, UPN and directory name in your
>>>> patch 0095).
>>>
>>> As far as I remember this reasoning usually comes back to bite us into butt.
>>>
>>> - "Implement only this subset, nobody else needs the other the of ...
>>> (whatever, e.g. DNS record type)."
>>> - "Yes my lord."
>>>
>>> Two months later:
>>>
>>> - "We need to support for XYZ. It was (already) late yesterday!"
>>>
>>> :-)
>>
>> Care to give a concrete example of when this actually happened? Because IIRC
>> this happened once or twice, not "usually".

I do not have list at hand, sorry. It is just my feeling.


>> Anyway, I'm fine with whatever, my point was that additional effort needs to
>> be put in to support "everything" and even then, we wouldn't actually
>> support everything (two months later: "we need to support extension XYZ!").
>>
> Sure, but in this case it was minimal additional effort to support
> even the esoteric name types - it is only for display after all; if
> an uncommon altname is (somehow) there we can display it.

That is the main point. The cost is minimal so why not to do it?

Petr^2 Spacek

>> (FWIW, I think it would be more useful to add support for Basic constraints
>> rather than X.400 SANs.)
>>
> I can only agree, and say: another RFE for another day :)
> 
>>>
>>> Petr^2 Spacek
>>>
>>>>
>>>> 4)
>>>>
>>>> +obj.setdefault(attr_name, []).append(unicode(name))
>>>>
>>>> The value should not (always) be unicode, but of the type declared by the
>>>> param (unicode or ipapython.kerberos.Principal or 
>>>> ipapython.dnsutil.DNSName).

-- 
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 0004-0012] Automatic CSR generation

[Petr Spacek]

On 2.8.2016 05:57, Fraser Tweedale wrote:
>> > Hah! This is what I get for thinking I know what the output has to look
>> > like, and not testing all the way through to requesting the cert. I'll
>> > change the profile to generate a subject with CN= instead of UID=. Updated
>> > patch is attached. Unfortunately these rules are only updated at
>> > ipa-server-install time, so if you'd like to fix it without reinstalling:
>> > 
> (Tangential commentary...) Yeah, currently cert-request demands the
> CN.  There is a design to relax the requirement to handle empty
> subject names (look at SAN only).  IMO it would make sense to accept
> other "obvious" mappings in Subject DN like accepting UID instead of
> CN for user subjects, but that would be a separate RFE.  Noone has
> actually asked for it yet :)

Side-note:
I thought that subject format is enforced by certificate profile on server.
Am I wrong?

-- 
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] [PATCH 0159] Tests: fix test_forward_zones in test_xmlrpc/test_dns_plugin

[Petr Spacek]

Hello,

this is the last patch necessary to get all test_xmlrpc/test_dns_plugin tests
to pass! (I hope :-)

Tests: fix test_forward_zones in test_xmlrpc/test_dns_plugin

Class test_forward_zones in ipatests/test_xmlrpc/test_dns_plugin
was using DNS zone 'fwzone2.test.' and expected to get warning
'Forwarding policy conflicts with some automatic empty zones.'
(aka 'DNSForwardPolicyConflictWithEmptyZone').

This does not make sense because 'test.' zone is not listed in IANA registry
'Locally-Served DNS Zones':

http://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml

To fix this I simply removed the warning from set of expected results.

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


-- 
Petr^2 Spacek
From 663178e3f305d25cd9ad53bbb85b80a89181b5b9 Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Fri, 12 Aug 2016 19:49:33 +0200
Subject: [PATCH] Tests: fix test_forward_zones in test_xmlrpc/test_dns_plugin

Class test_forward_zones in ipatests/test_xmlrpc/test_dns_plugin
was using DNS zone 'fwzone2.test.' and expected to get warning
'Forwarding policy conflicts with some automatic empty zones.'
(aka 'DNSForwardPolicyConflictWithEmptyZone').

This does not make sense because 'test.' zone is not listed in IANA registry
'Locally-Served DNS Zones':
http://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml

To fix this I simply removed the warning from set of expected results.

https://fedorahosted.org/freeipa/ticket/6213
---
 ipatests/test_xmlrpc/test_dns_plugin.py | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/ipatests/test_xmlrpc/test_dns_plugin.py b/ipatests/test_xmlrpc/test_dns_plugin.py
index aa011ceba69285b0149c60f87b1df4b0e0f3de9e..196aa0c39002050229209669cfc528574cc9ab26 100644
--- a/ipatests/test_xmlrpc/test_dns_plugin.py
+++ b/ipatests/test_xmlrpc/test_dns_plugin.py
@@ -3444,15 +3444,7 @@ class test_forward_zones(Declarative):
 expected={
 'value': fwzone2_dnsname,
 'summary': None,
-u'messages': (
-{u'message': lambda x: x.startswith(
-u"Forwarding policy conflicts with some "
-"automatic empty zones."),
- u'code': 13021,
- u'type': u'warning',
- u'name': u'DNSForwardPolicyConflictWithEmptyZone',
- u'data': {}},
-{u'message': lambda x: x.startswith(
+u'messages': ({u'message': lambda x: x.startswith(
 u"DNS server %s: query '%s SOA':" %
 (forwarder1, fwzone2)),
  u'code': 13006,
-- 
2.7.4

-- 
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 0003][Tests] Fix for integration tests replication layouts

[Petr Spacek]

On 9.8.2016 16:55, Ganna Kaihorodova wrote:
> Hello!
> 
> Domain level 0 doesn't allow to create replica file on CA master, testcase 
> was skipped with Domain level 0

You mean on CA-less master, right?

Petr^2 Spacek

> https://fedorahosted.org/freeipa/ticket/6134

-- 
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] 0090, 0092..0094 cert-show: show subject alternative names

[Petr Spacek]

On 12.8.2016 11:33, Jan Cholasta wrote:
> On 4.8.2016 18:18, Petr Vobornik wrote:
>> On 07/22/2016 07:13 AM, Fraser Tweedale wrote:
>>> On Tue, Jul 19, 2016 at 08:50:34AM +0200, Jan Cholasta wrote:
 Hi,

 On 14.7.2016 13:44, Fraser Tweedale wrote:
> Hi all,
>
> The attached patch includes SANs in cert-show output.  If you have
> certs with esoteric altnames (especially any that are more than just
> ASN.1 string types), please test with those certs.
>
> https://fedorahosted.org/freeipa/ticket/6022

 I think it would be better to have a separate attribute for each supported
 SAN type rather than cramming everything into subject_alt_name. That way if
 you care only about a single specific type you won't have to go through all
 the values and parse them. Also it would allow you to use param types
 appropriate to the SAN types (DNSNameParam for DNS names, Principal for
 principal names, etc.)

 Nitpick: please don't mix moving existing stuff and adding new stuff in a
 single patch.

>>> Updated patches attached.
>>>
>>> Patches 0092..0094 are refactors and bugfixes.
>>> Patch 0090-2 is the main feature (depends on 0092..0094).
>>>
>>> Thanks,
>>> Fraser
>>>
>>
>> bump for review
> 
> Patch 0092: ACK
> 
> Patch 0093: ACK
> 
> Patch 0094: ACK
> 
> Patch 0090:
> 
> 1) Generic otherNames (san_other) do not work correctly. The OID is not
> included in the value and names with complex type other than KerberosPrincipal
> are not parsed correctly. The value should include the OID and DER blob of the
> name.
> 
> 2) With --all, san_other should be included in the result for all otherNames,
> even the known ones, to provide (limited) forward compatibility.
> 
> 3) Do we have to support *all* the name types? I mean we could, for the sake
> of completeness, but it might be easier to just keep the few ones we actually
> care about (email, DNS name, principal name, UPN and directory name in your
> patch 0095).

As far as I remember this reasoning usually comes back to bite us into butt.

- "Implement only this subset, nobody else needs the other the of ...
(whatever, e.g. DNS record type)."
- "Yes my lord."

Two months later:

- "We need to support for XYZ. It was (already) late yesterday!"

:-)

Petr^2 Spacek

> 
> 4)
> 
> +obj.setdefault(attr_name, []).append(unicode(name))
> 
> The value should not (always) be unicode, but of the type declared by the
> param (unicode or ipapython.kerberos.Principal or ipapython.dnsutil.DNSName).

-- 
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] [DESIGN][UPDATE] Time-Based HBAC Policies

[Petr Spacek]

On 11.8.2016 12:34, Stanislav Laznicka wrote:
> Hello,
> 
> I updated the design of the Time-Based HBAC Policies according to the
> discussion we led here earlier. Please check the design page
> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest
> changes are in the Implementation and Feature Management sections. I also
> added a short How to Use section.

Nice page!

On the high level it all makes sense.

ad LDAP schema
==
1) Why accessTime attribute is MAY in ipaTimeRule object class?
Does it make sense to have the object without accessTime? I do not think so.

Also, it could be good to add description attribute to the object class and
incorporate it into commands (including find).

2) Besides all this, I spent few minutes in dark history of IPA. The
accessTime attribute was introduced back in 2009 in commit
"55ba300c7cb59cf05b16cc01281f51d93eb25acf" aka "Incorporate new schema for 
IPAv2".

The commit does not contain any reasoning for the change but I can see that
the attribute is already used as MAY in old object classes ipaHBACRule and
ipaSELinuxUserMap.

Is any of these a problem?

Why is it even in ipaSELinuxUserMap object class? Commit
55512dc938eb4a9a6655e473beab587e340af55c does not mention any reason for doing 
so.

I cannot see any other problem so the low-level stuff is good and can be
implemented.


ad User interface
=
We need to polish the user interface so it really usable.

At least the web interface should contain some shortcuts. E.g. when I'm adding
a new HBAC rule, the "time" section should contain also "something" to
immediately add new time rule so I do not need to go to time rules first and
then go back to HBAC page.

Similarly, dialog for rule modification should allow to easily change all the
values, warn if time rules is shared, and also have an easy way to
'disconnect' the time rule, i.e. make a copy of it and edit only the new copy
(instead of the shared original).

All these are user interface things not affecting the low-level stuff.


Maybe you should sat down with some UX designer, talk about these cases and
draw some hand-made pictures.

I do not believe that this will require any changes in schema so you can
polish SSSD and framework implementation in meantime.



> On the link below is a PROTOTYPE-patched FreeIPA that covers most of the CLI
> functionality (except for the creation of iCalendar strings from options) for
> better illustration of the design.
> 
> https://github.com/stlaz/freeipa/tree/timerules_2

Honestly I did not look at the code today :-)

Overall, I'm glad to see current proposal. After so many iteration, we reached
something which does not have any glaring problem :-)

-- 
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] [PATCH 0158] DNS: allow to add forward zone to already broken sub-domain

[Petr Spacek]

Hello,

DNS: allow to add forward zone to already broken sub-domain

Errors during DNS resolution might indicate that forwarder is the
necessary configuration which is missing. Now we disallow adding a
forwarder only if the zone is normally resolvable without the forwarder.

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

-- 
Petr^2 Spacek
From cf6e9499db8b23d8f55e9caa32ee97c7ca1533e5 Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Fri, 12 Aug 2016 17:08:30 +0200
Subject: [PATCH] DNS: allow to add forward zone to already broken sub-domain

Errors during DNS resolution might indicate that forwarder is the
necessary configuration which is missing. Now we disallow adding a
forwarder only if the zone is normally resolvable without the forwarder.

https://fedorahosted.org/freeipa/ticket/6062
---
 ipaserver/plugins/dns.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ipaserver/plugins/dns.py b/ipaserver/plugins/dns.py
index 585b28c15daf00df2918a67585f7fb6e99462f1e..6f1bd716d202bd85dfc46b5eb94f73e85683b917 100644
--- a/ipaserver/plugins/dns.py
+++ b/ipaserver/plugins/dns.py
@@ -2097,7 +2097,7 @@ class DNSZoneBase_add(LDAPCreate):
 
 if not options['skip_overlap_check']:
 try:
-check_zone_overlap(keys[-1])
+check_zone_overlap(keys[-1], raise_on_error=False)
 except ValueError as e:
 raise errors.InvocationError(e.message)
 
-- 
2.7.4

-- 
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 0433-0434] Fix zone removal to respect forward configuration inheritance + Remove preserve_forwarding parameter from ldap_delete_zone2()

[Petr Spacek]

Hello,

please review attached patch set. It fixes
https://fedorahosted.org/bind-dyndb-ldap/ticket/167

The code is also available on Github:
https://github.com/pspacek/bind-dyndb-ldap/tree/fix_root_zone_removal

Patched SRPM:
https://pspacek.fedorapeople.org/bind-dyndb-ldap/bind-dyndb-ldap-10.0-3.fc24.src.rpm

COPR build:
https://copr.fedorainfracloud.org/coprs/pspacek/bind-dyndb-ldap/build/440841/

Martin Basti, please build it also in @freeipa/freeipa-master COPR so CI can
pick it up. Thank you!


Patch set description:
Fix zone removal to respect forward configuration inheritance.

Ad-hoc fwd_delete_table() calls did not respect inheritance hierarchy
in forwarding configuration. Now all manipulation with forward table
is done in fwd_configure_zone() and fully respects configuration inheritance.

There is a trick: When removing or deactivating a zone, fwd_configure_zone()
is called with empty configuration set to simulate that the zone does
not have any explicit configuration. This triggers the inheritance
logic when necessary (i.e. for the root zone).

https://fedorahosted.org/bind-dyndb-ldap/ticket/167
https://github.com/pspacek/bind-dyndb-ldap/commit/d6e413c4cc88101b902d73e05e1ce35e2fe4aedd



Remove preserve_forwarding parameter from ldap_delete_zone2().

The parameter was TRUE only when called from zone_security_change().
zone_security_change() is calling ldap_delete_zone2() in exclusive mode
anyway so there is no need to optimize this.

Removal of the parameter will make easier to centralize forwarding
configuration on one place.

https://fedorahosted.org/bind-dyndb-ldap/ticket/167
https://github.com/pspacek/bind-dyndb-ldap/commit/b40976263460d8f4aeeec2a2a8f41cc54dcd0b28

-- 
Petr^2 Spacek
From 3b44a3d73a0d1980b43e9022d9249c4c19ba56d2 Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Thu, 11 Aug 2016 12:40:39 +0200
Subject: [PATCH] Remove preserve_forwarding parameter from
 ldap_delete_zone2().

The parameter was TRUE only when called from zone_security_change().
zone_security_change() is calling ldap_delete_zone2() in exclusive mode
anyway so there is no need to optimize this.

Removal of the parameter will make easier to centralize forwarding
configuration on one place.

https://fedorahosted.org/bind-dyndb-ldap/ticket/167
---
 src/ldap_helper.c   | 26 ++
 src/ldap_helper.h   |  3 +--
 src/zone_register.c |  2 +-
 3 files changed, 12 insertions(+), 19 deletions(-)

diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index 12a743b095ba400373cb87653d26af82cc95c2ea..696a755fb8001993ff1a16fa034a9286cbb5ad89 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -1285,8 +1285,7 @@ configure_zone_ssutable(dns_zone_t *zone, const char *update_str)
 
 /* Delete zone by dns zone name */
 isc_result_t
-ldap_delete_zone2(ldap_instance_t *inst, dns_name_t *name, isc_boolean_t lock,
-		  isc_boolean_t preserve_forwarding)
+ldap_delete_zone2(ldap_instance_t *inst, dns_name_t *name, isc_boolean_t lock)
 {
 	isc_result_t result;
 	isc_result_t isforward = ISC_R_NOTFOUND;
@@ -1302,13 +1301,11 @@ ldap_delete_zone2(ldap_instance_t *inst, dns_name_t *name, isc_boolean_t lock,
 	if (lock)
 		run_exclusive_enter(inst, _state);
 
-	if (!preserve_forwarding) {
-		CHECK(fwd_delete_table(inst->view, name, "zone",
-   zone_name_char));
-		isforward = fwdr_zone_ispresent(inst->fwd_register, name);
-		if (isforward == ISC_R_SUCCESS)
-			CHECK(fwdr_del_zone(inst->fwd_register, name));
-	}
+	CHECK(fwd_delete_table(inst->view, name, "zone",
+			   zone_name_char));
+	isforward = fwdr_zone_ispresent(inst->fwd_register, name);
+	if (isforward == ISC_R_SUCCESS)
+		CHECK(fwdr_del_zone(inst->fwd_register, name));
 
 	result = zr_get_zone_ptr(inst->zone_register, name, , );
 	if (result == ISC_R_NOTFOUND || result == DNS_R_PARTIALMATCH) {
@@ -1487,8 +1484,7 @@ ldap_parse_fwd_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst)
 	if (HEAD(values) != NULL &&
 	strcasecmp(HEAD(values)->value, "TRUE") != 0) {
 		/* Zone is not active */
-		result = ldap_delete_zone2(inst, >fqdn,
-	   ISC_TRUE, ISC_FALSE);
+		result = ldap_delete_zone2(inst, >fqdn, ISC_TRUE);
 		goto cleanup;
 	}
 
@@ -1990,7 +1986,7 @@ zone_security_change(ldap_entry_t * const entry, dns_name_t * const name,
 	 * in period where old zone was deleted but the new zone was not
 	 * created yet. */
 	run_exclusive_enter(inst, _state);
-	CHECK(ldap_delete_zone2(inst, name, ISC_FALSE, ISC_TRUE));
+	CHECK(ldap_delete_zone2(inst, name, ISC_FALSE));
 	CHECK(ldap_parse_master_zoneentry(entry, olddb, inst, task));
 
 cleanup:
@@ -2173,8 +2169,7 @@ cleanup:
 		log_error_r("%s: publishing failed, rolling back due to",
 			ldap_entry_logname(entry));
 		/* TODO: verify this */
-		result = ldap_delete_zone2(inst, >fqdn,
-	   ISC_TRUE, ISC_FALSE);
+		result = ldap_delete_zone2(inst, >fqdn, ISC_TRUE);
 		if (result !=

Re: [Freeipa-devel] [PATCH 0155] DNS server upgrade: do not fail when DNS server did not respond

[Petr Spacek]

On 11.8.2016 15:08, Petr Spacek wrote:
> Hello,
> 
> DNS server upgrade: do not fail when DNS server did not respond
> 
> Previously, update_dnsforward_emptyzones failed with an exeception if
> DNS query failed for some reason. Now the error is logged and upgrade
> continues.
> 
> I assume that this is okay because the DNS query is used as heuristics
> of last resort in the upgrade logic and failure to do so should not have
> catastrophics consequences: In the worst case, the admin needs to
> manually change forwarding policy from 'first' to 'only'.
> 
> In the end I have decided not to auto-start BIND because BIND depends on
> GSSAPI for authentication, which in turn depends on KDC ... Alternative
> like reconfiguring BIND to use LDAPI+EXTERNAL and reconfiguring DS to
> accept LDAP external bind from named user are too complicated.
> 
> https://fedorahosted.org/freeipa/ticket/6205

Here is variant for master branch. Enjoy.

-- 
Petr^2 Spacek
From 4816abee9150db26b330fa4ce99b4fb8f51597a1 Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Thu, 11 Aug 2016 13:44:29 +0200
Subject: [PATCH] DNS server upgrade: do not fail when DNS server did not
 respond

Previously, update_dnsforward_emptyzones failed with an exeception if
DNS query failed for some reason. Now the error is logged and upgrade
continues.

I assume that this is okay because the DNS query is used as heuristics
of last resort in the upgrade logic and failure to do so should not have
catastrophics consequences: In the worst case, the admin needs to
manually change forwarding policy from 'first' to 'only'.

In the end I have decided not to auto-start BIND because BIND depends on
GSSAPI for authentication, which in turn depends on KDC ... Alternative
like reconfiguring BIND to use LDAPI+EXTERNAL and reconfiguring DS to
accept LDAP external bind from named user are too complicated.

https://fedorahosted.org/freeipa/ticket/6205
---
 ipaserver/install/plugins/dns.py | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/ipaserver/install/plugins/dns.py b/ipaserver/install/plugins/dns.py
index 32247eedbac7fc7e00c7277ef0bc593a74cd22e4..7b06a5c0d3a59e5825af75fae87c9739a53d9913 100644
--- a/ipaserver/install/plugins/dns.py
+++ b/ipaserver/install/plugins/dns.py
@@ -17,6 +17,9 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
+from __future__ import absolute_import
+
+import dns.exception
 import re
 import traceback
 import time
@@ -489,8 +492,15 @@ class update_dnsforward_emptyzones(DNSUpdater):
 self.api.Command['dnsconfig_mod'](ipadnsversion=2)
 
 self.update_zones()
-if dnsutil.has_empty_zone_addresses(self.api.env.host):
-self.update_global_ldap_forwarder()
+try:
+if dnsutil.has_empty_zone_addresses(self.api.env.host):
+self.update_global_ldap_forwarder()
+except dns.exception.DNSException as ex:
+self.log.error('Skipping update of global DNS forwarder in LDAP: '
+   'Unable to determine if local server is using an '
+   'IP address belonging to an automatic empty zone. '
+   'Consider changing forwarding policy to "only". '
+   'DNS exception: %s', ex)
 
 return False, []
 
-- 
2.7.4

-- 
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 0156] server upgrade: do not start BIND if it was not running before the upgrad

[Petr Spacek]

On 11.8.2016 15:17, Petr Spacek wrote:
> On 11.8.2016 15:10, Petr Spacek wrote:
>> Hello,
>>
>> server upgrade: do not start BIND if it was not running before the upgrade
>>
>> https://fedorahosted.org/freeipa/ticket/6206
> 
> Here is variant for master branch.

Grr, this is a wrong thread. Please ignore this.

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

Re: [Freeipa-devel] [PATCH 0156] server upgrade: do not start BIND if it was not running before the upgrad

[Petr Spacek]

On 11.8.2016 15:10, Petr Spacek wrote:
> Hello,
> 
> server upgrade: do not start BIND if it was not running before the upgrade
> 
> https://fedorahosted.org/freeipa/ticket/6206

Here is variant for master branch.

-- 
Petr^2 Spacek
From 4816abee9150db26b330fa4ce99b4fb8f51597a1 Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Thu, 11 Aug 2016 13:44:29 +0200
Subject: [PATCH] DNS server upgrade: do not fail when DNS server did not
 respond

Previously, update_dnsforward_emptyzones failed with an exeception if
DNS query failed for some reason. Now the error is logged and upgrade
continues.

I assume that this is okay because the DNS query is used as heuristics
of last resort in the upgrade logic and failure to do so should not have
catastrophics consequences: In the worst case, the admin needs to
manually change forwarding policy from 'first' to 'only'.

In the end I have decided not to auto-start BIND because BIND depends on
GSSAPI for authentication, which in turn depends on KDC ... Alternative
like reconfiguring BIND to use LDAPI+EXTERNAL and reconfiguring DS to
accept LDAP external bind from named user are too complicated.

https://fedorahosted.org/freeipa/ticket/6205
---
 ipaserver/install/plugins/dns.py | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/ipaserver/install/plugins/dns.py b/ipaserver/install/plugins/dns.py
index 32247eedbac7fc7e00c7277ef0bc593a74cd22e4..7b06a5c0d3a59e5825af75fae87c9739a53d9913 100644
--- a/ipaserver/install/plugins/dns.py
+++ b/ipaserver/install/plugins/dns.py
@@ -17,6 +17,9 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
+from __future__ import absolute_import
+
+import dns.exception
 import re
 import traceback
 import time
@@ -489,8 +492,15 @@ class update_dnsforward_emptyzones(DNSUpdater):
 self.api.Command['dnsconfig_mod'](ipadnsversion=2)
 
 self.update_zones()
-if dnsutil.has_empty_zone_addresses(self.api.env.host):
-self.update_global_ldap_forwarder()
+try:
+if dnsutil.has_empty_zone_addresses(self.api.env.host):
+self.update_global_ldap_forwarder()
+except dns.exception.DNSException as ex:
+self.log.error('Skipping update of global DNS forwarder in LDAP: '
+   'Unable to determine if local server is using an '
+   'IP address belonging to an automatic empty zone. '
+   'Consider changing forwarding policy to "only". '
+   'DNS exception: %s', ex)
 
 return False, []
 
-- 
2.7.4

-- 
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 0156] server upgrade: do not start BIND if it was not running before the upgrad

[Petr Spacek]

Hello,

server upgrade: do not start BIND if it was not running before the upgrade

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

-- 
Petr^2 Spacek
From a01799ca093cc5572c11d9f73c90b8ee71a48d70 Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Thu, 11 Aug 2016 15:10:04 +0200
Subject: [PATCH] server upgrade: do not start BIND if it was not running
 before the upgrade

https://fedorahosted.org/freeipa/ticket/6206
---
 ipaserver/install/server/upgrade.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ipaserver/install/server/upgrade.py b/ipaserver/install/server/upgrade.py
index cc0af2b243d0c5693024e105fd0eab925b3f9b6c..d3ecde34f36d5adda730421d516110efd8ff29dd 100644
--- a/ipaserver/install/server/upgrade.py
+++ b/ipaserver/install/server/upgrade.py
@@ -1678,7 +1678,8 @@ def upgrade_configuration():
 root_logger.info('Changes to named.conf have been made, restart named')
 bind = bindinstance.BindInstance(fstore)
 try:
-bind.restart()
+if bind.is_running():
+bind.restart()
 except ipautil.CalledProcessError as e:
 root_logger.error("Failed to restart %s: %s", bind.service_name, e)
 
-- 
2.7.4

-- 
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 0155] DNS server upgrade: do not fail when DNS server did not respond

[Petr Spacek]

Hello,

DNS server upgrade: do not fail when DNS server did not respond

Previously, update_dnsforward_emptyzones failed with an exeception if
DNS query failed for some reason. Now the error is logged and upgrade
continues.

I assume that this is okay because the DNS query is used as heuristics
of last resort in the upgrade logic and failure to do so should not have
catastrophics consequences: In the worst case, the admin needs to
manually change forwarding policy from 'first' to 'only'.

In the end I have decided not to auto-start BIND because BIND depends on
GSSAPI for authentication, which in turn depends on KDC ... Alternative
like reconfiguring BIND to use LDAPI+EXTERNAL and reconfiguring DS to
accept LDAP external bind from named user are too complicated.

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

-- 
Petr^2 Spacek
From 145332c9c627594a49e8546c6afb2a7a77dd46b9 Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Thu, 11 Aug 2016 13:44:29 +0200
Subject: [PATCH] DNS server upgrade: do not fail when DNS server did not
 respond

Previously, update_dnsforward_emptyzones failed with an exeception if
DNS query failed for some reason. Now the error is logged and upgrade
continues.

I assume that this is okay because the DNS query is used as heuristics
of last resort in the upgrade logic and failure to do so should not have
catastrophics consequences: In the worst case, the admin needs to
manually change forwarding policy from 'first' to 'only'.

In the end I have decided not to auto-start BIND because BIND depends on
GSSAPI for authentication, which in turn depends on KDC ... Alternative
like reconfiguring BIND to use LDAPI+EXTERNAL and reconfiguring DS to
accept LDAP external bind from named user are too complicated.

https://fedorahosted.org/freeipa/ticket/6205
---
 ipaserver/install/plugins/dns.py | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/ipaserver/install/plugins/dns.py b/ipaserver/install/plugins/dns.py
index 873dbd03ed82d904fc712924db1a6bff813af065..6f67f9857778f3018666075c1616dab5d3f4ff11 100644
--- a/ipaserver/install/plugins/dns.py
+++ b/ipaserver/install/plugins/dns.py
@@ -17,6 +17,9 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
+from __future__ import absolute_import
+
+import dns.exception
 import ldap as _ldap
 import re
 import traceback
@@ -489,8 +492,15 @@ class update_dnsforward_emptyzones(DNSUpdater):
 self.api.Command['dnsconfig_mod'](ipadnsversion=2)
 
 self.update_zones()
-if dnsutil.has_empty_zone_addresses(self.api.env.host):
-self.update_global_ldap_forwarder()
+try:
+if dnsutil.has_empty_zone_addresses(self.api.env.host):
+self.update_global_ldap_forwarder()
+except dns.exception.DNSException as ex:
+self.log.error('Skipping update of global DNS forwarder in LDAP: '
+   'Unable to determine if local server is using an '
+   'IP address belonging to an automatic empty zone. '
+   'Consider changing forwarding policy to "only". '
+   'DNS exception: %s', ex)
 
 return False, []
 
-- 
2.7.4

-- 
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 0013-0015] Automatic CSR generation - usability improvements

[Petr Spacek]

On 9.8.2016 22:07, Ben Lipton wrote:
> Aaand there's a typo in patch 15. Updated version attached.

Ben,

it would be great if you can always send whole patch set, including the
patches which were not changed from the previous iteration.

It is getting quite hard to follow and mix-and-match patches from e-mails into
one patch set.

As a nice to have addition, you can push the whole patch set to Github (or
somewhere else) so we can just clone the repo and be done with it :-)

Thank you for understanding.

Petr^2 Spacek

> 
> On 08/09/2016 02:22 PM, Ben Lipton wrote:
>> Hello,
>>
>> The attached patches improve upon my last patchset to:
>>
>> 0013: Add support for generating a full script that makes a CSR, rather than
>> just a config, and use that support to automate the full flow from script
>> generation through cert issuance
>> Usage note: the UI for this could probably use work. I currently have the
>> --helper-args param that allows additional data to be passed to the helper.
>> Commonly this would be something like:
>> Certutil: --helper-args '-d /path/to/nss/db' (precreated with certutil -N -d
>> /path/to/nss/db)
>> Openssl: --helper-args 'd /path/to/keyfile' (precreated with openssl genrsa
>> -out /path/to/keyfile)
>> See the commit message for a full command line.
>>
>> 0014: Allow the feature to be used by non-admin users
>>
>> 0015: Improve error handling by reporting a nice message if the mapping
>> rules are broken, or if the data required to generate the subject DN is 
>> missing
>>
>> These improvements may make it easier to test the other patches.
>>
>> Thanks,
>> Ben
>>
>>
> 
> 
> 
> 


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

Re: [Freeipa-devel] [PATCH 0151-0152] install: Call hostnamectl set-hostname only if --hostname option is use server-install: Fix --hostname option to always override api.env value

[Petr Spacek]

On 10.8.2016 08:21, Jan Cholasta wrote:
> On 1.8.2016 17:42, Petr Spacek wrote:
>> On 1.8.2016 08:27, Jan Cholasta wrote:
>>> On 28.7.2016 16:55, Petr Spacek wrote:
>>>> On 28.7.2016 16:44, Jan Cholasta wrote:
>>>>> On 28.7.2016 16:37, Petr Spacek wrote:
>>>>>> On 28.7.2016 16:35, Jan Cholasta wrote:
>>>>>>> On 28.7.2016 16:20, Petr Spacek wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> install: Call hostnamectl set-hostname only if --hostname option is 
>>>>>>>> used
>>>>>>>>
>>>>>>>> This commit also splits hostname backup and configuration into two
>>>>>>>> separate
>>>>>>>> functions. This allows us to backup hostname without setting it at the
>>>>>>>> same time.
>>>>>>>>
>>>>>>>> https://fedorahosted.org/freeipa/ticket/6071
>>>>>>>
>>>>>>> Note that you can set ca_host in cfg unconditionally, the value is only
>>>>>>> valid
>>>>>>> during install and is not written anywhere.
>>>>>>
>>>>>> I prefer not to set it so the code blows up when we attempt to touch
>>>>>> variables
>>>>>> we should reference in particular setups. I.e. Take this as a first step
>>>>>> towards api.env without invalid values :-)
>>>>>
>>>>> OK. Use the proper condition then ("if setup_ca:").
>>>>
>>>> Oh, I'm probably blind. Here is revised version.
>>>
>>> But you used "if not setup_ca:" rather than "if setup_ca:" :-)
>>
>> This patch set is cursed!
> 
> The host name should not be backed up in server install if we are not changing
> it, so that it's not attempted to be changed on uninstall.
> 
> Otherwise works for me.

Okay, now I see that ipa-backup/restore is storing the host name in backup
header so we do not need it in sysrestore.

New patches are attached.

-- 
Petr^2 Spacek
From 96010d6f9d480c6eac39816f449bc647fd6b36c1 Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Tue, 12 Jul 2016 17:42:40 +0200
Subject: [PATCH] server-install: Fix --hostname option to always override
 api.env values

Attempts to compare local hostname with user-provided values are error
prone as we found out in #5794. This patch removes comparison and makes
the env values deterministic.

https://fedorahosted.org/freeipa/ticket/6071
---
 ipaserver/install/server/install.py | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/ipaserver/install/server/install.py b/ipaserver/install/server/install.py
index 65f9318201e648b30a3c13626e807ac6f3a9416d..1e925595b93ff95a98b3e6c3d0c357b1766dc1dc 100644
--- a/ipaserver/install/server/install.py
+++ b/ipaserver/install/server/install.py
@@ -560,7 +560,12 @@ def install_check(installer):
 cfg = dict(
 context='installer',
 in_server=True,
+# make sure host name specified by user is used instead of default
+host=host_name,
 )
+if setup_ca:
+# we have an IPA-integrated CA
+cfg['ca_host'] = host_name
 
 # Create the management framework config file and finalize api
 target_fname = paths.IPA_DEFAULT_CONF
@@ -586,14 +591,6 @@ def install_check(installer):
 # Must be readable for everyone
 os.chmod(target_fname, 0o644)
 
-system_hostname = get_fqdn()
-if host_name != system_hostname:
-root_logger.debug("Chosen hostname (%s) differs from system hostname "
-  "(%s) - change it" % (host_name, system_hostname))
-# update `api.env.ca_host` to correct hostname
-# https://fedorahosted.org/freeipa/ticket/4936
-api.env.ca_host = host_name
-
 api.bootstrap(**cfg)
 api.finalize()
 
-- 
2.7.4

From d546592834ea7b08908acf66d668c05203734c76 Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Thu, 28 Jul 2016 16:13:55 +0200
Subject: [PATCH] install: Call hostnamectl set-hostname only if --hostname
 option is used

This commit also splits hostname backup and configuration into two separate
functions. This allows us to backup hostname without setting it at the
same time.

https://fedorahosted.org/freeipa/ticket/6071
---
 client/ipa-client-install   |  3 ++-
 doc/guide/guide.org | 10 +-
 ipaplatform/base/tasks.py   |  7 ++-
 ipaplatform/redhat/tasks.py | 13 ++---
 ipaserver/install/server/install.py | 10 +-
 5 files changed, 16 insertions(+), 27 deletions(-)

diff --git a/client/ipa-client-ins

Re: [Freeipa-devel] [PATCH 0561] backup: backup /etc/tmpfiles.d/dirsrv-instance-*

[Petr Spacek]

On 9.8.2016 12:37, Martin Basti wrote:
> https://fedorahosted.org/freeipa/ticket/6165

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

Re: [Freeipa-devel] [PATCH 0002] Fix ipa-caacl-add-service error message

[Petr Spacek]

On 9.8.2016 16:16, Tomas Krizek wrote:
> Hi,
> 
> please review the attached patch.

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

Re: [Freeipa-devel] [PATCH 686] Revert "spec: add conflict with bind-chroot to freeipa-server-dns"

[Petr Spacek]

On 9.8.2016 14:16, Jan Cholasta wrote:
> Hi,
> 
> the attached patch fixes .

ACK

For historians: Further discussion can be found in
https://bugzilla.redhat.com/show_bug.cgi?id=1309700.

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

Re: [Freeipa-devel] [PATCH 0154] client: RPM require initscripts to get *-domainname.service

[Petr Spacek]

On 8.8.2016 13:37, Jan Cholasta wrote:
> Hi,
> 
> On 8.8.2016 13:22, Petr Spacek wrote:
>> Hello,
>>
>> client: RPM require initscripts to get *-domainname.service
>>
>> https://fedorahosted.org/freeipa/ticket/4831
> 
> IIRC there was a task associated with the ticket to investigate if there is a
> better way of setting the domain name on boot. So... is there?
> 
> AFAIK we set the domain name using authconfig, shouldn't authconfig be in
> charge of enabling any required services?

As far as I can tell, this is the way to set NIS domain in RHEL/Fedora.

authconfig cannot set NIS domain only, it does unwanted additional magic like
enabling rpcbind and ypbind services etc.

Alternative is to drop sysctl file to /etc but I do not like it because it
would not be the Red Hat standard way of doing NIS domain config.

Opinions?

-- 
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] [PATCH 0154] client: RPM require initscripts to get *-domainname.service

[Petr Spacek]

Hello,

client: RPM require initscripts to get *-domainname.service

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

-- 
Petr^2 Spacek
From b542e09b6d52b7ce22e47b6c08eb692b9f3b91b7 Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Mon, 8 Aug 2016 13:13:18 +0200
Subject: [PATCH] client: RPM require initscripts to get *-domainname.service

https://fedorahosted.org/freeipa/ticket/4831
---
 freeipa.spec.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index 135e9c980011c6c2730c6c29a3c22098e48270d5..06e35c25d2f8c8dd88c4a853953b86eac2fee113 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -325,6 +325,8 @@ Requires: krb5-workstation
 Requires: authconfig
 Requires: pam_krb5
 Requires: curl
+# NIS domain name config: /usr/lib/systemd/system/*-domainname.service
+Requires: initscripts
 Requires: libcurl >= 7.21.7-2
 Requires: xmlrpc-c >= 1.27.4
 Requires: sssd >= 1.14.0
-- 
2.7.4

-- 
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 0214] Support schema files for external plugins

[Petr Spacek]

On 8.8.2016 11:34, Alexander Bokovoy wrote:
> Hi!
> 
> Attached patch is what is needed to allow external plugins for FreeIPA
> framework to be functional if they need to extend a schema.
> 
> The idea is that we would have a separate directory as
> /usr/share/ipa/schema.d and will allow to use schema (*.ldif) files from
> it and its subdirectories during install and upgrade stages.
> 
> Without the patch only selected schema files from /usr/share/ipa are
> used during install and upgrade. This leads to a failure to install IPA
> server (or upgrade it) if a new plugin is added. If plugin defines
> managed permissions, upgrade tool will generate ACIs which will fail to
> be inserted into LDAP store due to references to missing attributes and
> object classes.
> 
> The patch adds a directory to be installed and a helper utility that
> loads files from the directory and adds them to the list of schema files
> used during update of dsinstance and upgrade of the server.
> 
> With this patch I'm successfully managed to make FleetCommander
> integration plugin completely independent of FreeIPA.

1. I cannot see a patch attached to this e-mail :-)

2. Needless to say that ticket in appropriate milestone is going to be required.

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

Re: [Freeipa-devel] [PATCH 0153] Fix ipa-replica-prepare's error message about missing local CA instanc

[Petr Spacek]

On 3.8.2016 22:56, Ben Lipton wrote:
> 
> On 08/01/2016 11:38 AM, Petr Spacek wrote:
>> Hello,
>>
>> Fix ipa-replica-prepare's error message about missing local CA instance
>>
>> ipa-replica-prepare must be run on a replica with CA or all the certs
>> needs to be provided (for CA-less case).
>>
>> The old messages were utterly confusing because they mixed errors about
>> missing certs and missing local CA instance into one text.
>>
>> https://fedorahosted.org/freeipa/ticket/6134
>>
>>
>>
> The error message in the patch says "must be ran" instead of "must be run".

Thanks! Fixed patch is attached.

-- 
Petr^2 Spacek
From 22bba42b7ac8ec4a11af0e08609adf03f3aa2332 Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Mon, 1 Aug 2016 17:32:04 +0200
Subject: [PATCH] Fix ipa-replica-prepare's error message about missing local
 CA instance

ipa-replica-prepare must be run on a replica with CA or all the certs
needs to be provided (for CA-less case).

The old messages were utterly confusing because they mixed errors about
missing certs and missing local CA instance into one text.

https://fedorahosted.org/freeipa/ticket/6134
---
 ipaserver/install/ipa_replica_prepare.py | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/ipaserver/install/ipa_replica_prepare.py b/ipaserver/install/ipa_replica_prepare.py
index fdd32f0c8437a0d8c3947d57089662ea09bb2304..a6f0f1e393707d40c62276d4c355afba82fc83f5 100644
--- a/ipaserver/install/ipa_replica_prepare.py
+++ b/ipaserver/install/ipa_replica_prepare.py
@@ -236,6 +236,10 @@ class ReplicaPrepare(admintool.AdminTool):
 except errors.DatabaseError as e:
 raise admintool.ScriptError(e.desc)
 
+if ca_enabled and not ipautil.file_exists(paths.CA_CS_CFG_PATH):
+raise admintool.ScriptError(
+"CA is not installed on this server. "
+"ipa-replica-prepare must be run on an IPA server with CA.")
 if not ca_enabled and not options.http_cert_files:
 raise admintool.ScriptError(
 "Cannot issue certificates: a CA is not installed. Use the "
@@ -347,13 +351,6 @@ class ReplicaPrepare(admintool.AdminTool):
 "Apache Server SSL certificate and Directory Server SSL "
  "certificate are not signed by the same CA certificate")
 
-if (not ipautil.file_exists(paths.CA_CS_CFG_PATH) and
-options.dirsrv_pin is None):
-self.log.info("If you installed IPA with your own certificates "
-"using PKCS#12 files you must provide PKCS#12 files for any "
-"replicas you create as well.")
-raise admintool.ScriptError("The replica must be created on the "
-"primary IPA server.")
 
 def run(self):
 options = self.options
-- 
2.7.4

-- 
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]: 0098-99 : Split make lint to more targets and add jslint

[Petr Spacek]

On 2.8.2016 17:12, Rob Crittenden wrote:
> Pavel Vomacka wrote:
>> Hello,
>>
>> please review attached patches which Split make lint to more targets and
>> add jslint
> 
> What's the driver to split the checks out into separate targets?
> 
> You are moving the makeapi and makeaci from version-update to lint. They were
> in version-update for a reason: downstream builds do not call lint. Downstream
> may patch code. API cannot break.
> 
> No ticket?

Jan, can you comment on this?

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

Re: [Freeipa-devel] [PATCH]: 0098-99 : Split make lint to more targets and add jslint

[Petr Spacek]

On 2.8.2016 17:12, Rob Crittenden wrote:
> Pavel Vomacka wrote:
>> Hello,
>>
>> please review attached patches which Split make lint to more targets and
>> add jslint
> 
> What's the driver to split the checks out into separate targets?

Most importantly, makeapi and makeaci do not need to be called 10 times during
single build (and can be called in parallel, once our build system can manage
that).

> You are moving the makeapi and makeaci from version-update to lint. They were
> in version-update for a reason: downstream builds do not call lint. Downstream
> may patch code. API cannot break.

This is very true, I definitely agree. Even better, downstream should call as
much checks as possible.

This split allows the downstream spec to call all tools which are available in
downstream as part of %check section of the spec, which was not possible
before the split.

> No ticket?

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

Re: [Freeipa-devel] [PATCH] 0001 six.u function instead of the decode

[Petr Spacek]

On 1.8.2016 18:31, Martin Basti wrote:
> 
> 
> On 28.07.2016 18:29, Ariel Barria wrote:
>> 2016-07-28 7:10 GMT-05:00 Petr Spacek <pspa...@redhat.com>:
>>> On 27.7.2016 18:26, Ariel Barria wrote:
>>>> 2016-07-26 9:39 GMT-05:00 Petr Spacek <pspa...@redhat.com>:
>>>>> On 26.7.2016 16:28, Jan Cholasta wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 26.7.2016 16:09, Martin Basti wrote:
>>>>>>>
>>>>>>> On 22.07.2016 00:14, Ariel Barria wrote:
>>>>>>>> Hello everyone.
>>>>>>>>
>>>>>>>> I send patch for review.
>>>>>> NACK, six.u() is supposed to be used on string literals *only* [1].
>>>>>>
>>>>>> A proper fix would be something like:
>>>>>>
>>>>>>  value = self.to_text()
>>>>>>  if not isinstance(value, unicode):
>>>>>>  value = value.decode('ascii')
>>>>>>  return value
>>>> thanks for the guidance and comments
>>>>
>>>>> Most importantly, we should fix/provide this method in python-dns and
>>>>> inherit
>>>>> this method from there.
>>>> Well, I made a pr, but apparently travis ci test failed with other
>>>> versions of python, so it is possible that they do not approve, I will
>>>> be performing other tests to see what the downside.
>>>>
>>>> https://github.com/rthalley/dnspython/pull/195
>>> Looking at the PR, there are functions
>>> dns.name.to_text()
>>> dns.name.to_unicode()
>>>
>>> What is missing in them?
>>>
>>> Petr^2 Spacek
>>>
>>>
>>>>>>> I will look on this, for some reason we received your e-mail just today
>>>>>>> (2016-07-26)
>>>> welcome.
>>>> it was my mistake, I sent the patch to the list before being signed to the
>>>> list
>>>>
>>>>>> Honza
>>>>>>
>>>>>> [1] <https://pythonhosted.org/six/#six.u>
>>> -- 
>>> Petr^2 Spacek
>> Hi.
>> I send the requested changes
>> thanks for review.
>>
>>
> 
> According the 
> https://github.com/rthalley/dnspython/blob/master/dns/name.py#L375
> 
> New dnspython always return binary strings, so we should always decode it,
> because IPA internals need punycoded domain in unicode format
> 
> IMO this is broken in current dnspython released in Fedora. There are plenty
> of py3 bugs, we have to provide newer dnspython package to fedora, so this
> should not be fixed on IPA side.

I'm fine with rebasing python-dns in Fedora when we find a version which works
better. Just tell me what version it is :-)

-- 
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] [PATCH 0153] Fix ipa-replica-prepare's error message about missing local CA instanc

[Petr Spacek]

Hello,

Fix ipa-replica-prepare's error message about missing local CA instance

ipa-replica-prepare must be run on a replica with CA or all the certs
needs to be provided (for CA-less case).

The old messages were utterly confusing because they mixed errors about
missing certs and missing local CA instance into one text.

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

-- 
Petr^2 Spacek
From c47c6966107f7d913137667cb9164f5f43c5daaa Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Mon, 1 Aug 2016 17:32:04 +0200
Subject: [PATCH] Fix ipa-replica-prepare's error message about missing local
 CA instance

ipa-replica-prepare must be run on a replica with CA or all the certs
needs to be provided (for CA-less case).

The old messages were utterly confusing because they mixed errors about
missing certs and missing local CA instance into one text.

https://fedorahosted.org/freeipa/ticket/6134
---
 ipaserver/install/ipa_replica_prepare.py | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/ipaserver/install/ipa_replica_prepare.py b/ipaserver/install/ipa_replica_prepare.py
index fdd32f0c8437a0d8c3947d57089662ea09bb2304..49c4552a80540e4b7c1242bdaf9dc583259d7149 100644
--- a/ipaserver/install/ipa_replica_prepare.py
+++ b/ipaserver/install/ipa_replica_prepare.py
@@ -236,6 +236,10 @@ class ReplicaPrepare(admintool.AdminTool):
 except errors.DatabaseError as e:
 raise admintool.ScriptError(e.desc)
 
+if ca_enabled and not ipautil.file_exists(paths.CA_CS_CFG_PATH):
+raise admintool.ScriptError(
+"CA is not installed on this server. "
+"ipa-replica-prepare must be ran on an IPA server with CA.")
 if not ca_enabled and not options.http_cert_files:
 raise admintool.ScriptError(
 "Cannot issue certificates: a CA is not installed. Use the "
@@ -347,13 +351,6 @@ class ReplicaPrepare(admintool.AdminTool):
 "Apache Server SSL certificate and Directory Server SSL "
  "certificate are not signed by the same CA certificate")
 
-if (not ipautil.file_exists(paths.CA_CS_CFG_PATH) and
-options.dirsrv_pin is None):
-self.log.info("If you installed IPA with your own certificates "
-"using PKCS#12 files you must provide PKCS#12 files for any "
-"replicas you create as well.")
-raise admintool.ScriptError("The replica must be created on the "
-"primary IPA server.")
 
 def run(self):
 options = self.options
-- 
2.7.4

-- 
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 0151-0152] install: Call hostnamectl set-hostname only if --hostname option is use server-install: Fix --hostname option to always override api.env value

[Petr Spacek]

On 1.8.2016 08:27, Jan Cholasta wrote:
> On 28.7.2016 16:55, Petr Spacek wrote:
>> On 28.7.2016 16:44, Jan Cholasta wrote:
>>> On 28.7.2016 16:37, Petr Spacek wrote:
>>>> On 28.7.2016 16:35, Jan Cholasta wrote:
>>>>> On 28.7.2016 16:20, Petr Spacek wrote:
>>>>>> Hello,
>>>>>>
>>>>>> install: Call hostnamectl set-hostname only if --hostname option is used
>>>>>>
>>>>>> This commit also splits hostname backup and configuration into two 
>>>>>> separate
>>>>>> functions. This allows us to backup hostname without setting it at the
>>>>>> same time.
>>>>>>
>>>>>> https://fedorahosted.org/freeipa/ticket/6071
>>>>>
>>>>> Note that you can set ca_host in cfg unconditionally, the value is only
>>>>> valid
>>>>> during install and is not written anywhere.
>>>>
>>>> I prefer not to set it so the code blows up when we attempt to touch
>>>> variables
>>>> we should reference in particular setups. I.e. Take this as a first step
>>>> towards api.env without invalid values :-)
>>>
>>> OK. Use the proper condition then ("if setup_ca:").
>>
>> Oh, I'm probably blind. Here is revised version.
> 
> But you used "if not setup_ca:" rather than "if setup_ca:" :-)

This patch set is cursed!

Petr^2 Spacek

> 
>>
>> Petr^2 Spacek
>>
>>>
>>>>
>>>> (In my stash I have a patch which removes nonsense defaults from
>>>> ipalib.constants. To be pushed when we a new git branch for 4.4...)
>>>>
>>>> Petr^2 Spacek
>>>>
>>>>>> server-install: Fix --hostname option to always override api.env values
>>>>>>
>>>>>> Attempts to compare local hostname with user-provided values are error
>>>>>> prone as we found out in #5794. This patch removes comparison and makes
>>>>>> the env values deterministic.
>>>>>>
>>>>>> https://fedorahosted.org/freeipa/ticket/6071
>>>>>>
>>>>>>
>>>>>> Jan, this patch set should fix problems you have seen in containers.
> 
> 


-- 
Petr^2 Spacek
From 16c62d99391ec2efff93e0652bf00ecb72f37a42 Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Tue, 12 Jul 2016 17:42:40 +0200
Subject: [PATCH] server-install: Fix --hostname option to always override
 api.env values

Attempts to compare local hostname with user-provided values are error
prone as we found out in #5794. This patch removes comparison and makes
the env values deterministic.

https://fedorahosted.org/freeipa/ticket/6071
---
 ipaserver/install/server/install.py | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/ipaserver/install/server/install.py b/ipaserver/install/server/install.py
index 65f9318201e648b30a3c13626e807ac6f3a9416d..1e925595b93ff95a98b3e6c3d0c357b1766dc1dc 100644
--- a/ipaserver/install/server/install.py
+++ b/ipaserver/install/server/install.py
@@ -560,7 +560,12 @@ def install_check(installer):
 cfg = dict(
 context='installer',
 in_server=True,
+# make sure host name specified by user is used instead of default
+host=host_name,
 )
+if setup_ca:
+# we have an IPA-integrated CA
+cfg['ca_host'] = host_name
 
 # Create the management framework config file and finalize api
 target_fname = paths.IPA_DEFAULT_CONF
@@ -586,14 +591,6 @@ def install_check(installer):
 # Must be readable for everyone
 os.chmod(target_fname, 0o644)
 
-system_hostname = get_fqdn()
-if host_name != system_hostname:
-root_logger.debug("Chosen hostname (%s) differs from system hostname "
-  "(%s) - change it" % (host_name, system_hostname))
-# update `api.env.ca_host` to correct hostname
-# https://fedorahosted.org/freeipa/ticket/4936
-api.env.ca_host = host_name
-
 api.bootstrap(**cfg)
 api.finalize()
 
-- 
2.7.4

From 719db115f1e02e1f1e635f3f8c16b234458d0703 Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Thu, 28 Jul 2016 16:13:55 +0200
Subject: [PATCH] install: Call hostnamectl set-hostname only if --hostname
 option is used

This commit also splits hostname backup and configuration into two separate
functions. This allows us to backup hostname without setting it at the
same time.

https://fedorahosted.org/freeipa/ticket/6071
---
 client/ipa-client-install   |  3 ++-
 doc/guide/guide.org | 10 +-
 ipaplatf

Re: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation

[Petr Spacek]

On 27.7.2016 19:06, Ben Lipton wrote:
> Hi all,
> 
> I think the automatic CSR generation feature
> (https://fedorahosted.org/freeipa/ticket/4899,
> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation) is
> stable enough to review now. The following are summaries of the attached 
> patches:
> 0004: LDAP schema changes for the new feature
> 0005: Basic API for new objects and CSR generation
> 0006: Update install automation to create some default mapping rules
> 0007: Implement the lookups and text processing that generates the CSR config
> 0008 and 0009: Implement some actual transformation rules so that the feature
> is usable
> 0010: Add a new cert profile for user certs, with mappings
> 0011: Implement import/export of cert profiles with mappings
> 0012: Tests for profile import/export
> 
> Generally speaking, later patches depend on earlier ones, but I don't
> anticipate any problems from committing earlier patches without later ones.
> 
> If you prefer, you can also comment on the pull request version:
> https://github.com/LiptonB/freeipa/pull/4. Note that I may force push on this
> branch.
> 
> Allocation of OIDs for schema change also needs review:
> https://code.engineering.redhat.com/gerrit/#/c/80061/
> 
> Known issues:
> - When the requested principal does not have some of the requested data,
> produces funny-looking configs with extra commas, empty sections, etc. They
> are still accepted by my copies of openssl and certutil, but they look ugly.
> - The new objects don't have any ACIs, so for the moment only admin can run
> the new commands.
> - Does not yet have support for prompting user for field values, so currently
> all data must come from the database.
> - All processing happens on the server side. As discussed in a previous
> thread, it would be desirable to break this out into a library so it could be
> used client-side.
> 
> Very excited to hear your thoughts!

Hi Ben,

I wanted to give it a try from user's point of view first, before diving into
implementation details. Here are some observations:

0. Design pages are using term "helper" and it is used even as option in the
example with smartcards. Please fix either design page or the code so they are
consistent.

1. The "ipa cert-request" command is missing options --autofill and --use (aka
helper aka format :-) which are mentioned in the design pages.

2. "ipa cert_get_requestdata" command passes even without --profile-id and
generates empty config. I think that this is not expected :-)

3. "ipa cert_get_requestdata --format=openssl" prints the text to stdout
including label "Configuration file contents:". This is hard to use because
simple redirection like "ipa cert_get_requestdata --format=openssl > config"
will not give you valid OpenSSL config file - it needs hand-editing.

It would be good to add --out parameter you envisioned in the design page.
Please ask jcholast for proper name and semantics :-) With --out option the
command can be used to generate valid config (or script if certutil was 
selected).

4. "ipa cert_get_requestdata --format=openssl" could print hint what OpenSSL
command should be executed on the generated config file. For testing I've used
command "openssl req -new -out csr -text -config config" (stolen and modified
from smart card example). Also, as a second hint, it could print the IPA
command which needs to be used to sign the CSR generated by the helper.

5. My naive attempt to get userCert for admin failed:
$ ipa cert_get_requestdata --format=openssl --principal=admin
--profile-id=userCert > usercert.conf
# remove the trailing label
$ openssl req -new -out csr -text -config usercert.conf
$ ipa cert-request --principal=admin --profile-id=userCert usercert.csr
ipa: ERROR: invalid 'csr': No Common Name was found in subject of request.

I'm attaching files generated by the commands above. I did not modify anything
in the templates or profiles, just tried to use the new profile added by
freeipa-blipton-0010-Add-a-new-cert-profile-for-users.patch .

Hopefully I will get to other things soon (but not this week).


Anyway, all this seems like (expected) initial problems. In general the first
touch with user interface seems reasonable and needs only small improvements.

Good work!

-- 
Petr^2 Spacek
[ req ]
prompt = no
encrypt_key = no

distinguished_name = sec0

[ sec0 ]
O=DOM-058-082.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM
UID=admin



usercert.csr
Description: application/pkcs10
-- 
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 0151-0152] install: Call hostnamectl set-hostname only if --hostname option is use server-install: Fix --hostname option to always override api.env value

[Petr Spacek]

On 28.7.2016 16:44, Jan Cholasta wrote:
> On 28.7.2016 16:37, Petr Spacek wrote:
>> On 28.7.2016 16:35, Jan Cholasta wrote:
>>> On 28.7.2016 16:20, Petr Spacek wrote:
>>>> Hello,
>>>>
>>>> install: Call hostnamectl set-hostname only if --hostname option is used
>>>>
>>>> This commit also splits hostname backup and configuration into two separate
>>>> functions. This allows us to backup hostname without setting it at the
>>>> same time.
>>>>
>>>> https://fedorahosted.org/freeipa/ticket/6071
>>>
>>> Note that you can set ca_host in cfg unconditionally, the value is only 
>>> valid
>>> during install and is not written anywhere.
>>
>> I prefer not to set it so the code blows up when we attempt to touch 
>> variables
>> we should reference in particular setups. I.e. Take this as a first step
>> towards api.env without invalid values :-)
> 
> OK. Use the proper condition then ("if setup_ca:").

Oh, I'm probably blind. Here is revised version.

Petr^2 Spacek

> 
>>
>> (In my stash I have a patch which removes nonsense defaults from
>> ipalib.constants. To be pushed when we a new git branch for 4.4...)
>>
>> Petr^2 Spacek
>>
>>>> server-install: Fix --hostname option to always override api.env values
>>>>
>>>> Attempts to compare local hostname with user-provided values are error
>>>> prone as we found out in #5794. This patch removes comparison and makes
>>>> the env values deterministic.
>>>>
>>>> https://fedorahosted.org/freeipa/ticket/6071
>>>>
>>>>
>>>> Jan, this patch set should fix problems you have seen in containers.
From d61ab05a3d9d978146a50f66c1c757144c78b700 Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Tue, 12 Jul 2016 17:42:40 +0200
Subject: [PATCH] server-install: Fix --hostname option to always override
 api.env values

Attempts to compare local hostname with user-provided values are error
prone as we found out in #5794. This patch removes comparison and makes
the env values deterministic.

https://fedorahosted.org/freeipa/ticket/6071
---
 ipaserver/install/server/install.py | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/ipaserver/install/server/install.py b/ipaserver/install/server/install.py
index c0c676b870b481696ae75742c7bf88074b0ecf9c..7e1c53b0575950302f90f9b7c9b8721df11f9b9e 100644
--- a/ipaserver/install/server/install.py
+++ b/ipaserver/install/server/install.py
@@ -559,7 +559,12 @@ def install_check(installer):
 cfg = dict(
 context='installer',
 in_server=True,
+# make sure host name specified by user is used instead of default
+host=host_name,
 )
+if not setup_ca:
+# we have an IPA-integrated CA
+cfg['ca_host'] = host_name
 
 # Create the management framework config file and finalize api
 target_fname = paths.IPA_DEFAULT_CONF
@@ -585,14 +590,6 @@ def install_check(installer):
 # Must be readable for everyone
 os.chmod(target_fname, 0o644)
 
-system_hostname = get_fqdn()
-if host_name != system_hostname:
-root_logger.debug("Chosen hostname (%s) differs from system hostname "
-  "(%s) - change it" % (host_name, system_hostname))
-# update `api.env.ca_host` to correct hostname
-# https://fedorahosted.org/freeipa/ticket/4936
-api.env.ca_host = host_name
-
 api.bootstrap(**cfg)
 api.finalize()
 
-- 
2.7.4

From acb5bb64bf23705a0d0efcf03d5f4015d9170f60 Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Thu, 28 Jul 2016 16:13:55 +0200
Subject: [PATCH] install: Call hostnamectl set-hostname only if --hostname
 option is used

This commit also splits hostname backup and configuration into two separate
functions. This allows us to backup hostname without setting it at the
same time.

https://fedorahosted.org/freeipa/ticket/6071
---
 client/ipa-client-install   |  3 ++-
 doc/guide/guide.org | 10 +-
 ipaplatform/base/tasks.py   |  7 ++-
 ipaplatform/redhat/tasks.py | 13 ++---
 ipaserver/install/server/install.py | 10 +-
 5 files changed, 16 insertions(+), 27 deletions(-)

diff --git a/client/ipa-client-install b/client/ipa-client-install
index 3c323173cc6f0a02aba1595f78637bbaac5a71ef..a4f15736bb20d83b305c6c14e7a51c469cd0e337 100755
--- a/client/ipa-client-install
+++ b/client/ipa-client-install
@@ -2518,7 +2518,8 @@ def install(options, env, fstore, statestore):
 if options.hostname and not options.on_master:
 # skip this step when run by ipa-server-install as it always configures
 # hostname
- 

Re: [Freeipa-devel] [PATCH 0151-0152] install: Call hostnamectl set-hostname only if --hostname option is use server-install: Fix --hostname option to always override api.env value

[Petr Spacek]

On 28.7.2016 16:35, Jan Cholasta wrote:
> On 28.7.2016 16:20, Petr Spacek wrote:
>> Hello,
>>
>> install: Call hostnamectl set-hostname only if --hostname option is used
>>
>> This commit also splits hostname backup and configuration into two separate
>> functions. This allows us to backup hostname without setting it at the
>> same time.
>>
>> https://fedorahosted.org/freeipa/ticket/6071
> 
> Note that you can set ca_host in cfg unconditionally, the value is only valid
> during install and is not written anywhere.

I prefer not to set it so the code blows up when we attempt to touch variables
we should reference in particular setups. I.e. Take this as a first step
towards api.env without invalid values :-)

(In my stash I have a patch which removes nonsense defaults from
ipalib.constants. To be pushed when we a new git branch for 4.4...)

Petr^2 Spacek

>> server-install: Fix --hostname option to always override api.env values
>>
>> Attempts to compare local hostname with user-provided values are error
>> prone as we found out in #5794. This patch removes comparison and makes
>> the env values deterministic.
>>
>> https://fedorahosted.org/freeipa/ticket/6071
>>
>>
>> Jan, this patch set should fix problems you have seen in containers.
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
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] [PATCH 0151-0152] install: Call hostnamectl set-hostname only if --hostname option is use server-install: Fix --hostname option to always override api.env value

[Petr Spacek]

Hello,

install: Call hostnamectl set-hostname only if --hostname option is used

This commit also splits hostname backup and configuration into two separate
functions. This allows us to backup hostname without setting it at the
same time.

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

server-install: Fix --hostname option to always override api.env values

Attempts to compare local hostname with user-provided values are error
prone as we found out in #5794. This patch removes comparison and makes
the env values deterministic.

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


Jan, this patch set should fix problems you have seen in containers.

-- 
Petr^2 Spacek
From 39a514f6818811d45e495da9bff7411df199a3fb Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Tue, 12 Jul 2016 17:42:40 +0200
Subject: [PATCH] server-install: Fix --hostname option to always override
 api.env values

Attempts to compare local hostname with user-provided values are error
prone as we found out in #5794. This patch removes comparison and makes
the env values deterministic.

https://fedorahosted.org/freeipa/ticket/6071
---
 ipaserver/install/server/install.py | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/ipaserver/install/server/install.py b/ipaserver/install/server/install.py
index c0c676b870b481696ae75742c7bf88074b0ecf9c..5d24a1358e7a5aeda1b23f92e7146efd6f629bbb 100644
--- a/ipaserver/install/server/install.py
+++ b/ipaserver/install/server/install.py
@@ -559,7 +559,12 @@ def install_check(installer):
 cfg = dict(
 context='installer',
 in_server=True,
+# make sure host name specified by user is used instead of default
+host=host_name,
 )
+if not (options.http_cert_files or options.dirsrv_cert_files):
+# we have an IPA-integrated CA
+cfg['ca_host'] = host_name
 
 # Create the management framework config file and finalize api
 target_fname = paths.IPA_DEFAULT_CONF
@@ -585,14 +590,6 @@ def install_check(installer):
 # Must be readable for everyone
 os.chmod(target_fname, 0o644)
 
-system_hostname = get_fqdn()
-if host_name != system_hostname:
-root_logger.debug("Chosen hostname (%s) differs from system hostname "
-  "(%s) - change it" % (host_name, system_hostname))
-# update `api.env.ca_host` to correct hostname
-# https://fedorahosted.org/freeipa/ticket/4936
-api.env.ca_host = host_name
-
 api.bootstrap(**cfg)
 api.finalize()
 
-- 
2.7.4

From fab9a97c62da4a6d08908e4e243af9a319a17e68 Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Thu, 28 Jul 2016 16:13:55 +0200
Subject: [PATCH] install: Call hostnamectl set-hostname only if --hostname
 option is used

This commit also splits hostname backup and configuration into two separate
functions. This allows us to backup hostname without setting it at the
same time.

https://fedorahosted.org/freeipa/ticket/6071
---
 client/ipa-client-install   |  3 ++-
 doc/guide/guide.org | 10 +-
 ipaplatform/base/tasks.py   |  7 ++-
 ipaplatform/redhat/tasks.py | 13 ++---
 ipaserver/install/server/install.py | 10 +-
 5 files changed, 16 insertions(+), 27 deletions(-)

diff --git a/client/ipa-client-install b/client/ipa-client-install
index 3c323173cc6f0a02aba1595f78637bbaac5a71ef..a4f15736bb20d83b305c6c14e7a51c469cd0e337 100755
--- a/client/ipa-client-install
+++ b/client/ipa-client-install
@@ -2518,7 +2518,8 @@ def install(options, env, fstore, statestore):
 if options.hostname and not options.on_master:
 # skip this step when run by ipa-server-install as it always configures
 # hostname
-tasks.backup_and_replace_hostname(fstore, statestore, options.hostname)
+tasks.backup_hostname(fstore, statestore)
+tasks.set_hostname(options.hostname)
 
 ntp_srv_servers = []
 if not options.on_master and options.conf_ntp:
diff --git a/doc/guide/guide.org b/doc/guide/guide.org
index 6d181559f0af90e7be7089aa94ab4900fa4e90b5..2e852a964991781ef5dd7b93ac481891897e1ed0 100644
--- a/doc/guide/guide.org
+++ b/doc/guide/guide.org
@@ -1039,14 +1039,14 @@ def restore_context_default(filepath):
 # version in platform services
 restore_context = restore_context_default
 
-# Default implementation of backup and replace hostname that does nothing
-def backup_and_replace_hostname_default(fstore, statestore, hostname):
+# Default implementation of backup hostname that does nothing
+def backup_hostname_default(fstore, statestore):
 return
 
-# Backup and replace system's hostname
-# Since many platforms have their own way how to store system's hostname, this method must be
+# Backup system's hostname
+# Since many platforms have their own way of handling system's hostname, this method must be
 # implemented in platform servi

Re: [Freeipa-devel] [PATCH] 0001 six.u function instead of the decode

[Petr Spacek]

On 27.7.2016 18:26, Ariel Barria wrote:
> 2016-07-26 9:39 GMT-05:00 Petr Spacek <pspa...@redhat.com>:
>> On 26.7.2016 16:28, Jan Cholasta wrote:
>>> Hi,
>>>
>>> On 26.7.2016 16:09, Martin Basti wrote:
>>>>
>>>>
>>>> On 22.07.2016 00:14, Ariel Barria wrote:
>>>>> Hello everyone.
>>>>>
>>>>> I send patch for review.
>>>
>>> NACK, six.u() is supposed to be used on string literals *only* [1].
>>>
>>> A proper fix would be something like:
>>>
>>> value = self.to_text()
>>> if not isinstance(value, unicode):
>>> value = value.decode('ascii')
>>> return value
> 
> thanks for the guidance and comments
> 
>>
>> Most importantly, we should fix/provide this method in python-dns and inherit
>> this method from there.
> 
> Well, I made a pr, but apparently travis ci test failed with other
> versions of python, so it is possible that they do not approve, I will
> be performing other tests to see what the downside.
> 
> https://github.com/rthalley/dnspython/pull/195

Looking at the PR, there are functions
dns.name.to_text()
dns.name.to_unicode()

What is missing in them?

Petr^2 Spacek


>>>> I will look on this, for some reason we received your e-mail just today
>>>> (2016-07-26)
> 
> welcome.
> it was my mistake, I sent the patch to the list before being signed to the 
> list
> 
>>>
>>> Honza
>>>
>>> [1] <https://pythonhosted.org/six/#six.u>
-- 
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

Re: [Freeipa-devel] [PATCH] 0002 Add client install option to set ipa_backup_server

[Petr Spacek]

On 27.7.2016 20:03, Martin Basti wrote:
> 
> 
> On 26.07.2016 17:01, Ariel Barria wrote:
>> Hello everyone.
>>
>> I send patch for review.
>>
>> Regards,
>>
>>
> Hello, thank you for the patch, but I have a few comments:
> 
> 1)
> can you please use option --backup-server instead of --ipa-backup-server to be
> consistent with --server (as we don't have option --ipa-server)
> 
> 2)
> values passed by --server option are validated if it is IPA server or not,
> this should happen for backup server(s) too.
> 
> But looking to current ipa-client-install, it may be challenging to achieve
> this goal. I'm afraid that you might rather wait until we refactor the client
> code (next release hopefully). But in case you are brave enough, I can provide
> advises, but it will be hell.
> 
> 3)
> There is a question, if the backup server should be used also for krb5.conf or
> other configs where multiple servers can be specified. Probably not. But at
> least this should be mentioned in manpage that this option is used only for
> SSSD (probably there should be check to prevent using --backup-server together
> with --no-sssd option)

I would use backup_servers even in krb5.conf. Quick testing indicates that
krb5 lib respects order of KDCs in krb5.conf so simply list backup servers at
the end of the list.

That would remove mutual exclusivity of --no-sssd and --backup-server options.

Petr^2 Spacek

> 
> 4)
> 'man ipa-client-install' should be updated with the new option
> 
> 5)
> ipa_backup_server allows to specify multiple servers, so the new option should
> be multivalued (and then joined to coma separated list into SSSD config)
> 
> regards,
> Martin

-- 
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] documentation: Manually Configuring a Linux Client & host-add-managedby

[Petr Spacek]

Hello list,

question from users led me to reading about host-add-managedby. While doing so
I found out procedure listed on
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/#host-setup-proc
and I wonder if it is correct or not. I think it needs update.

- In step 3 "create a host entry for the client" I would omit --force option
as this option should not be promoted at all.

- More interestingly, step 4 "set the client host to be managed by the server"
seems totally weird.
Why managedby from client should be pointing to a server? I do not think it is
necessary at all. Remove the step completely?

- Steps 5 & 7: sssd.conf and krb5.conf should not be pointing to one IPA
server but rather use server auto-discovery.

- AFAIK step 11 "set up a host certificate for the host in IdM" is obsolete as
we do not do this by default anymore. I would remove the step.

Any opinions?



As a side-note, help text for host-add-managedby is totally insufficient
because it does not explain purpose of the command:
> # ipa help host-add-managedby
> Usage: ipa [global-options] host-add-managedby HOSTNAME [options]
> 
> Add hosts that can manage this host.
> Options:
>   --hosts=STR   hosts to add

Docs
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/#Delegating_Host_Management
is a little bit more verbose but contains an invalid example. The delegation
was done to client2 but keytab used in the example was for server...

I would fix the example + add some explanation to the help command. With this
I need help from someone because I'm not even sure what is the correct 
semantics.

Should the 'manager' be able to retrieve keytab for host/ only? Or of any
service running on that host? What about certificates?

All this should be clarified somewhere in the help text.

Thank you for your attention :-)

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

Re: [Freeipa-devel] [PATCH] 0001 six.u function instead of the decode

[Petr Spacek]

On 26.7.2016 16:28, Jan Cholasta wrote:
> Hi,
> 
> On 26.7.2016 16:09, Martin Basti wrote:
>>
>>
>> On 22.07.2016 00:14, Ariel Barria wrote:
>>> Hello everyone.
>>>
>>> I send patch for review.
> 
> NACK, six.u() is supposed to be used on string literals *only* [1].
> 
> A proper fix would be something like:
> 
> value = self.to_text()
> if not isinstance(value, unicode):
> value = value.decode('ascii')
> return value

Most importantly, we should fix/provide this method in python-dns and inherit
this method from there.

Petr^2 Spacek

> 
>>>
>>> Regards,
>>>
>>>
>>
>> Thank you,
>>
>> I will look on this, for some reason we received your e-mail just today
>> (2016-07-26)
> 
> Honza
> 
> [1] 

-- 
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 0003] Fix several small typos

[Petr Spacek]

On 25.7.2016 17:00, Ben Lipton wrote:
> On 07/18/2016 04:54 PM, Lukas Slebodnik wrote:
>> On (18/07/16 16:38), Petr Spacek wrote:
>>> On 14.7.2016 16:11, Ben Lipton wrote:
>>>> On 07/14/2016 04:09 AM, Alexander Bokovoy wrote:
>>>>> On Wed, 13 Jul 2016, Ben Lipton wrote:
>>>>>> Nothing too exciting, just fixes a few typos I've noticed in comments.
>>>>> ACK. However, please file a ticket and mention it in the commit message.
>>> Is it worth the bureaucracy? I do not think so. We will certainly not 
>>> backport
>>> typo fixes in comments to older branches so I would say that ticket is
>>> useless.
>>>
>>> Just my two cents.
>>>
>> +1
>>
>> LS
>>
> Necessary or not, as the ticket is created now, any objection to pushing the
> patch?

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

Re: [Freeipa-devel] [PATCH 0150] replica-install: Fix --domain

[Petr Spacek]

On 25.7.2016 16:16, Jan Cholasta wrote:
> On 25.7.2016 15:55, Petr Spacek wrote:
>> Hello,
>>
>> replica-install: Fix --domain
>>
>> Replica installation must not check existence of --domain - the domain
>> must (logically) exist.
>>
>> https://fedorahosted.org/freeipa/ticket/6130
> 
> Note that Server.domain_name is already defined on line 1204 in
> ipaserver/install/server/install.py.

My bad, here is updated patch.

-- 
Petr^2 Spacek
From 29ddba2b6c031df60d4a9047e374c5ccbdd372ff Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Mon, 25 Jul 2016 15:54:43 +0200
Subject: [PATCH] replica-install: Fix --domain

Replica installation must not check existence of --domain - the domain
must (logically) exist.

https://fedorahosted.org/freeipa/ticket/6130
---
 ipaserver/install/server/common.py  |  5 -
 ipaserver/install/server/install.py | 11 ++-
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/ipaserver/install/server/common.py b/ipaserver/install/server/common.py
index 45fb2dc17976a08acab16783584524721411fb4e..e6093d15cd1067a83ed89945c4a9c983c66ec06f 100644
--- a/ipaserver/install/server/common.py
+++ b/ipaserver/install/server/common.py
@@ -284,11 +284,6 @@ class BaseServer(common.Installable, common.Interactive, core.Composite):
 @domain_name.validator
 def domain_name(self, value):
 validate_domain_name(value)
-if (self.setup_dns and
-not self.dns.allow_zone_overlap):  # pylint: disable=no-member
-print("Checking DNS domain %s, please wait ..." % value)
-check_zone_overlap(value, False)
-
 
 dm_password = Knob(
 str, None,
diff --git a/ipaserver/install/server/install.py b/ipaserver/install/server/install.py
index c0c676b870b481696ae75742c7bf88074b0ecf9c..ad95ddc59a7c1ad8bb27a9750b921b44c1acf58d 100644
--- a/ipaserver/install/server/install.py
+++ b/ipaserver/install/server/install.py
@@ -17,6 +17,7 @@ import six
 
 from ipapython import certmonger, ipaldap, ipautil, sysrestore
 from ipapython.dn import DN
+from ipapython.dnsutil import check_zone_overlap
 from ipapython.install import core
 from ipapython.install.common import step
 from ipapython.install.core import Knob
@@ -1200,12 +1201,20 @@ class ServerCA(BaseServerCA):
 
 class Server(BaseServer):
 realm_name = Knob(BaseServer.realm_name)
-domain_name = Knob(BaseServer.domain_name)
 
 setup_ca = None
 setup_kra = None
 setup_dns = Knob(BaseServer.setup_dns)
 
+domain_name = Knob(BaseServer.domain_name)
+
+@domain_name.validator
+def domain_name(self, value):
+if (self.setup_dns and
+not self.dns.allow_zone_overlap):  # pylint: disable=no-member
+print("Checking DNS domain %s, please wait ..." % value)
+check_zone_overlap(value, False)
+
 dm_password = Knob(
 BaseServer.dm_password,
 description="Directory Manager password",
-- 
2.7.4

-- 
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 0150] replica-install: Fix --domain

[Petr Spacek]

Hello,

replica-install: Fix --domain

Replica installation must not check existence of --domain - the domain
must (logically) exist.

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

-- 
Petr^2 Spacek
From 2a038b63f0ad6bc1e68ca62821efa8ced4f32a59 Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Mon, 25 Jul 2016 15:54:43 +0200
Subject: [PATCH] replica-install: Fix --domain

Replica installation must not check existence of --domain - the domain
must (logically) exist.

https://fedorahosted.org/freeipa/ticket/6130
---
 ipaserver/install/server/common.py  |  5 -
 ipaserver/install/server/install.py | 10 ++
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/ipaserver/install/server/common.py b/ipaserver/install/server/common.py
index 45fb2dc17976a08acab16783584524721411fb4e..e6093d15cd1067a83ed89945c4a9c983c66ec06f 100644
--- a/ipaserver/install/server/common.py
+++ b/ipaserver/install/server/common.py
@@ -284,11 +284,6 @@ class BaseServer(common.Installable, common.Interactive, core.Composite):
 @domain_name.validator
 def domain_name(self, value):
 validate_domain_name(value)
-if (self.setup_dns and
-not self.dns.allow_zone_overlap):  # pylint: disable=no-member
-print("Checking DNS domain %s, please wait ..." % value)
-check_zone_overlap(value, False)
-
 
 dm_password = Knob(
 str, None,
diff --git a/ipaserver/install/server/install.py b/ipaserver/install/server/install.py
index c0c676b870b481696ae75742c7bf88074b0ecf9c..8e3af4ab1d65746ea37936a33b8a62d379ec410b 100644
--- a/ipaserver/install/server/install.py
+++ b/ipaserver/install/server/install.py
@@ -17,6 +17,7 @@ import six
 
 from ipapython import certmonger, ipaldap, ipautil, sysrestore
 from ipapython.dn import DN
+from ipapython.dnsutil import check_zone_overlap
 from ipapython.install import core
 from ipapython.install.common import step
 from ipapython.install.core import Knob
@@ -1256,6 +1257,15 @@ class Server(BaseServer):
 "Domain Level cannot be higher than {0}".format(
 constants.MAX_DOMAIN_LEVEL))
 
+domain_name = Knob(BaseServer.domain_name)
+
+@domain_name.validator
+def domain_name(self, value):
+if (self.setup_dns and
+not self.dns.allow_zone_overlap):  # pylint: disable=no-member
+print("Checking DNS domain %s, please wait ..." % value)
+check_zone_overlap(value, False)
+
 ip_addresses = Knob(
 BaseServer.ip_addresses,
 description=("Master Server IP Address. This option can be used "
-- 
2.7.4

-- 
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 0432] Prevent crash while reloading an invalid DNS zone

[Petr Spacek]

Hello,

Prevent crash while reloading an invalid DNS zone.

The crash happened under these circumstances:
- create a DNS zone (test.) with NS record relative to this zone (ns.test.)
- make sure that name pointed to by NS record does not have any A/ records
- restart BIND
- add missing A/ record to ns.test.
-> CRASH!

https://fedorahosted.org/bind-dyndb-ldap/ticket/166

-- 
Petr^2 Spacek
From 97897d97c68f34d35b95aaf05bb0d2e2da727932 Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Fri, 22 Jul 2016 16:44:17 +0200
Subject: [PATCH] Prevent crash while reloading an invalid DNS zone.

The crash happened under these circumstance:
- create a DNS zone (test.) with NS record relative to this zone (ns.test.)
- make sure that name pointed to by NS record does not have any A/ records
- restart BIND
- add missing A/ record to ns.test.
-> CRASH!

https://fedorahosted.org/bind-dyndb-ldap/ticket/166
---
 src/ldap_helper.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index 681661b8910c8213030f38aa9ba38eee748d3109..12a743b095ba400373cb87653d26af82cc95c2ea 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -3824,6 +3824,7 @@ update_record(isc_task_t *task, isc_event_t *event)
 update_restart:
 	rbtdb = NULL;
 	ldapdb = NULL;
+	zone_settings = NULL;
 	ldapdb_rdatalist_destroy(mctx, );
 	CHECK(zr_get_zone_dbs(inst->zone_register, >zone_name, , ));
 	CHECK(dns_db_newversion(ldapdb, ));
-- 
2.7.4

-- 
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] 0012 Fix session cookies

[Petr Spacek]

On 22.7.2016 10:08, Florence Blanc-Renaud wrote:
> Hi,
> 
> please find attached a patch related to session cookies used by IPA API.
> 
> https://fedorahosted.org/freeipa/ticket/5984

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

Re: [Freeipa-devel] [PATCH 0555] AVC: use copy during instalation to keep SELinux context valid

[Petr Spacek]

On 21.7.2016 19:49, Martin Basti wrote:
> https://fedorahosted.org/freeipa/ticket/6111
> 
> I was able to reproduce this locally with vagrant, but I haven't been able to
> reproduce this in LAB, I don't know where differences are (cloud vs desktop
> fedora?)
> 
> 
> Patch attached.

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

Re: [Freeipa-devel] [PATCH 0556] host-del: fix behavior of --updatedns and PTR records

[Petr Spacek]

On 21.7.2016 20:01, Martin Basti wrote:
> https://fedorahosted.org/freeipa/ticket/6060
> 
> 
> Patch attached.

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

Re: [Freeipa-devel] [PATCH 0149] help: Add dnsserver commands to help topic 'dns'

[Petr Spacek]

On 15.7.2016 12:05, David Kupka wrote:
> On 12/07/16 12:54, Petr Spacek wrote:
>> Hello,
>>
>> help: Add dnsserver commands to help topic 'dns'
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1353888
>>
> Hi!
> 
> Your patch turns dnsserver topic to a subtopic of dns topic. I'm sorry I gave
> you wrong advice. Attached patch makes dnsserver-* commands appear in dns 
> topic.

ACK, it works for me.

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

Re: [Freeipa-devel] [DESIGN] Text-based rules for CSR autogeneration using Jinja2

[Petr Spacek]

On 20.7.2016 19:25, Ben Lipton wrote:
> On 07/20/2016 12:21 PM, Simo Sorce wrote:
>> On Wed, 2016-07-20 at 12:14 -0400, Ben Lipton wrote:
>>> On 07/20/2016 10:37 AM, Simo Sorce wrote:
 On Wed, 2016-07-20 at 10:17 -0400, Ben Lipton wrote:
> On 07/20/2016 06:27 AM, Simo Sorce wrote:
>> On Tue, 2016-07-19 at 16:20 -0400, Ben Lipton wrote:
>>> Hi,
>>>
>>> I have updated the design page
>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_
>>> Gene
>>> rati
>>> on/Mapping_Rules
>>> with my plan for implementing user-configurable rules for
>>> mapping
>>> IPA
>>> data into certificate requests. In brief: we will use Jinja2
>>> for
>>> templating. Data rules (which map individual data items) and
>>> syntax
>>> rules (which group them into certificate fields) will both be
>>> snippets
>>> of Jinja2 markup. The formatting process will be as follows:

I've finally found some time to read the sub-page Mapping_Rules and for me it
is kind of hard to follow. It would not be understandable without this e-mail
and the blog posts (BTW the blog articles are among best I have seen!).

Most importantly, the explanations in brackets above ["Data rules (which map
individual data items) and (which group them into certificate fields)"] are
missing in the wiki page itself :-)

Could you fold relevant parts of the e-mails and blogs back into the wiki page
so it is self-contained?

Besides this nit,
http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Mapping_Rules#Planned_implementation
sounds reasonable. I like how it prevents bad data from template-injection.

Regarding
http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema#Option_A
, I prefer Option A with separate object for each helper. It is somehow
cleaner and it might be useful to use distinct object classes for each helper 
etc.


API for ipa cert-get-requestdata sounds good.
API for ipa cert-request makes sense to me as well.

In any case I would recommend you to consult API design with Jan Cholasta
 - he is our API custodian.


BTW I very much like "Alternatives considered" sections, we should have this
for each design!

Good work, I really like the dutiful analysis!



>>> 1. Syntax rules will be rendered using Jinja2. Data rules
>>> (rule
>>> text,
>>> not rendered) will be passed as the datarules attribute.
>>> 2. Rendered syntax rules will be processed by the Formatter
>>> class
>>> for
>>> the selected CSR generation helper (e.g. openssl or
>>> certutil).
>>> The
>>> formatter combines these partial rules into a full template
>>> for
>>> the
>>> config.
>>> 3. The template will be rendered using Jinja2. Relevant data
>>> from
>>> the
>>> IPA database will be available in the context for this
>>> rendering.
>>> 4. The final rendered template will be returned to the
>>> caller,
>>> labeled
>>> with its function (e.g. a command line or a config file).
>>>
>>> Are there any comments or objections to this approach? Here's
>>> an
>>> example
>>> to show what it might look like in practice.
>>>
>>> Example data rules:
>>> email={{subject.email}}
>>> O={{config.ipacertificatesubjectbase}}\nCN={{subject.username
>>> }}
>>>
>>> Example syntax rule:
>>> subjectAltName=@{% section %}{{datarules|join('\n')}}{%
>>> endsection %}
>>>
>>> Example composed config template:
>>> [ req ]
>>> prompt = no
>>> encrypt_key = no
>>>
>>> distinguished_name = {% section
>>> %}O={{config.ipacertificatesubjectbase}}
>>> CN={{subject.username}}{% endsection %}
>>>
>>> req_extensions = exts
>>>
>>> [ exts ]
>>> subjectAltName=@{% section %}email={{subject.email}}{%
>>> endsection
>>> %}
>>>
>>> There's a lot more information about the thinking behind this
>>> at
>>> http://blog.benjaminlipton.com/2016/07/19/csr-generation-temp
>>> lati
>>> ng.h
>>> tml
>>> if you're interested, as well.
>> Nice work Ben,
>> it's been really nice to be able to follow your notes on the
>> blog
>> post,
>> one question remains lingering in my head, why jinja2 ?
>> I know that engine relatively well as I used it in ipsilon, so
>> I am
>> not
>> questioning the choice just asking why specifically jinja2 and
>> not
>> something else, potentially language agnostic.
>>
>> Simo.
> Honestly, my reasoning didn't go very far beyond that it seems to
> be
> widely used and is compatible with python, which is the language
> where
> the implementation is taking place (in the IPA RPC server). I
> thought
> about using the built-in python format strings or creating a
> simple
> domain-specific language, but the likelihood of wanting the
> built-in

Re: [Freeipa-devel] Using RPZ to overcome multi Kerberos domains and multiple DNS authorities.

[Petr Spacek]

On 18.7.2016 19:44, Jim Glenz wrote:
> IPA DNS configuration using Response Policy Zone (RPZ).
> 
> IPA utilizes DNS extensively to locate service records (SRV) and text
> records (TXT) associated with the Kerberos realm.
> IPA also heavily require DNS A records and PTR records to function
> correctly.
> Normally all A,SRV,TXT,PTR records are part of the same DNS domain zone.
> 
> The following shows how to decouple IPA "TXT and SRV" records only, and
> pass (forward) all other records to another internal DNS server when
> required to have all records (except SRV and TXT) records in the other DNS
> system.
> 
> Note: Below is very customized for specific environment, your environment
> may be different. Just wanted to pass on this DNS trick.
> Methodology used was to implement a BIND instance on at least two servers
> and then configuring a Response Policy Zone (RPZ).
> The RPZ is configured to respond to specific DNS records and forward other
> DNS records onward to next hop DNS.
> 
> All A and PTR records should exist in the next hop DNS authoritative server.
> As mentioned, the following solution is very specific to a unique
> environment.
> 
> IPA members and clinet servers must have their primary/secondary DNS
> resolvers set to the DNS RPZ BIND servers.
> 
> 
> Steps
>  Create your Master and Slave Bind DNS where RPZ will be used (can be your
> IPA server or any other server having Bind DNS installed)
>  Create Response Policy Zone (RPZ) files.
>  Test configuration.
> 
> Search below for " 
> nslookup  
> nslookup  
> 
> nslookup . 
> nslookup . 
> 
> nslookup  
> nslookup . 
> nslookup -type=TXT _kerberos.   Bind-DNS-RPZ2-IP-address>
> nslookup -type=SRV _kerberos-master._tcp.   Bind-DNS-RPZ2-IP-address>
> nslookup -type=SRV _kerberos-master._udp.   Bind-DNS-RPZ2-IP-address>
> nslookup -type=SRV _kerberos._tcp.  Bind-DNS-RPZ2-IP-address>
> nslookup -type=SRV _kerberos._udp.  Bind-DNS-RPZ2-IP-address>
> nslookup -type=SRV _kpasswd._tcp.   Bind-DNS-RPZ2-IP-address>
> nslookup -type=SRV _kpasswd._udp.   Bind-DNS-RPZ2-IP-address>
> nslookup -type=SRV _ldap._tcp.  Bind-DNS-RPZ2-IP-address>
> 
> nslookup  
> nslookup . 
> nslookup -type=TXT _kerberos.   Bind-DNS-RPZ1-IP-address>
> nslookup -type=SRV _kerberos-master._tcp.   Bind-DNS-RPZ1-IP-address>
> nslookup -type=SRV _kerberos-master._udp.   Bind-DNS-RPZ1-IP-address>
> nslookup -type=SRV _kerberos._tcp.  Bind-DNS-RPZ1-IP-address>
> nslookup -type=SRV _kerberos._udp.  Bind-DNS-RPZ1-IP-address>
> nslookup -type=SRV _kpasswd._tcp.   Bind-DNS-RPZ1-IP-address>
> nslookup -type=SRV _kpasswd._udp.   Bind-DNS-RPZ1-IP-address>
> nslookup -type=SRV _ldap._tcp.  Bind-DNS-RPZ1-IP-address>
> 
> nslookup google.com 
> nslookup google.com 
> 
> nslookup -type=ptr   Bind-DNS-RPZ2-IP-address>
> nslookup -type=ptr   Bind-DNS-RPZ1-IP-address>
> nslookup -type=ptr   Bind-DNS-RPZ2-IP-address>
> nslookup -type=ptr   Bind-DNS-RPZ1-IP-address>
> 
> 
> Will be referencing reverse.arpa zone 10.x.x.x internal network. Adjust as
> necessary for your environment.
> 
> Appendix A: Primary IPA DNS /etc/named.conf file
> # cat named.conf
> options {
> // Put files that named is allowed to write in the data/ directory:
> directory "/var/named"; // the default
> dump-file   "data/cache_dump.db";
> statistics-file "data/named_stats.txt";
> memstatistics-file  "data/named_mem_stats.txt";
> #forward first;
> forwarders {
> ;
> ;
> };
> response-policy {zone ""; };
> 
> // Any host is permitted to issue recursive queries
> allow-recursion { any; };
> 
>   tkey-gssapi-credential "DNS/";
>   tkey-domain "";
> };
> 
> /* If you want to enable debugging, eg. using the 'rndc trace' command,
>  * By default, SELinux policy does not allow named to modify the /var/named
> directory,
>  * so put the default debug log file in data/ :
>  */
> logging {
> channel default_debug {
> file "data/named.run";
> severity dynamic;
> };
> };
> 
> zone "" IN {
> type master;
> file "";
> also-notify {;};
> };
> 
> zone "10.in-addr.arpa" IN {
>  type forward;
> forwarders {
> ;
> ;
> };
> };
> 
> include "/etc/named.rfc1912.zones";
> 
> # dynamic not used, remark out.
> #dynamic-db "ipa" {
> #library "ldap.so";
> #};
> 
> Appendix B: Primary IPA DNS /var/named/ file
> $ORIGIN .
> $TTL 86400  ; 1 day
> .rpz IN SOA  localhost. root.localhost. (
> 201505162150 ; serial
> 3600   ; refresh (1 hour)
> 1800   ; retry (30 minutes)
> 604800 ; expire (1 week)
>   

Re: [Freeipa-devel] [PATCH 0003] Fix several small typos

[Petr Spacek]

On 14.7.2016 16:11, Ben Lipton wrote:
> On 07/14/2016 04:09 AM, Alexander Bokovoy wrote:
>> On Wed, 13 Jul 2016, Ben Lipton wrote:
>>> Nothing too exciting, just fixes a few typos I've noticed in comments.
>> ACK. However, please file a ticket and mention it in the commit message.

Is it worth the bureaucracy? I do not think so. We will certainly not backport
typo fixes in comments to older branches so I would say that ticket is useless.

Just my two cents.

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

Re: [Freeipa-devel] CI DNS locations: basic test for SRV records

[Petr Spacek]

On 8.7.2016 14:01, Martin Basti wrote:
> See commit message for details. Patch attached.
> 
> 
> This test does not cover:
> 
> * NTP service records
> 
> * ipa-ca A/ records
> 
> * ADTrust records
> 
> Should I open tickets to cover cases above?

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

Re: [Freeipa-devel] [PATCH] spec: require Dogtag >= 10.3.3-3

[Petr Spacek]

On 8.7.2016 06:52, Fraser Tweedale wrote:
> On Thu, Jul 07, 2016 at 01:16:04PM +0200, Petr Spacek wrote:
>> Hello,
>>
>> IPA 4.4.0 requires Dogtag >= 10.3.4. Is this version going to be built for
>> Fedora any time soon?
>>
>> Or should I update my scripts to automatically enable
>> COPR @freeipa/freeipa-master
>> in my testing VMs?
>>
>> Thanks.
>> Petr^2 Spacek
>>
> Hi Petr,
> 
> The required features were released for Fedora as 10.3.3-3.
> Attached patch retracts the min required version accordingly.

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] [PATCH 0149] help: Add dnsserver commands to help topic 'dns'

[Petr Spacek]

Hello,

help: Add dnsserver commands to help topic 'dns'

https://bugzilla.redhat.com/show_bug.cgi?id=1353888

-- 
Petr^2 Spacek
From 28e5f4d195c891a2eba2970c8a915469a2b0447f Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Tue, 12 Jul 2016 12:53:52 +0200
Subject: [PATCH] help: Add dnsserver commands to help topic 'dns'

https://bugzilla.redhat.com/show_bug.cgi?id=1353888
---
 ipaserver/plugins/dnsserver.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ipaserver/plugins/dnsserver.py b/ipaserver/plugins/dnsserver.py
index beddec04230d810479fff9612721cf12260bbb3a..c26be6ecb2caf59318c38010423c583bf0c50cd8 100644
--- a/ipaserver/plugins/dnsserver.py
+++ b/ipaserver/plugins/dnsserver.py
@@ -48,6 +48,8 @@ EXAMPLES:
 
 register = Registry()
 
+topic = 'dns'
+
 dnsserver_object_class = ['top', 'idnsServerConfigObject']
 
 @register()
-- 
2.7.4

-- 
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] CA-less installs: passive certmonger - watch-and-warn mode

[Petr Spacek]

On 8.7.2016 15:31, Rob Crittenden wrote:
> Petr Spacek wrote:
>> Hi,
>>
>> our docs
>>
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-determine-ca
>>
>>
>> claim this:
>> "The certmonger service is not used to track certificates. Therefore, it does
>> not warn you of impending certificate expiration."
>>
>> Is this correct?
>>
>> Can we at least configure certmonger to passively track the certificates and
>> throw warning about impending expiration into logs?
>>
> 
> Throw a warning where? Register an e-mail address as part of the tracking
> perhaps?
> 
> It would probably be fairly easy to write a "CA" that sends an e-mail. The
> trick, and this has always tripped us up, is having an MTA configured.

I would start with logs, as I wrote in the original message. This will
naturally evolve into something else when we finally get user-configurable 
hooks.

In any case, having certmonger configured to track the certs is prerequisite
for all cases...

-- 
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] CA-less installs: passive certmonger - watch-and-warn mode

[Petr Spacek]

Hi,

our docs

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-determine-ca

claim this:
"The certmonger service is not used to track certificates. Therefore, it does
not warn you of impending certificate expiration."

Is this correct?

Can we at least configure certmonger to passively track the certificates and
throw warning about impending expiration into logs?

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

Re: [Freeipa-devel] Proposed patch to resolve #828866 [RFE] enhance --subject option for ipa-server-install

[Petr Spacek]

On 8.7.2016 05:42, Fraser Tweedale wrote:
> 
>   2. If argument contains CN but it is not the "most specific"
>   RDN, move it to the front (to satisfy requirement of Dogtag
>   profile).

I wonder if we can relax the requirement in Dogtag so no reordering is needed.
After all, DN is just a name, isn't it? Why Dogtag requires particular field
in DN?

-- 
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 clients in AD DNS domain & Kerberos referrals

[Petr Spacek]

Hello,

this is probably a silly idea ...

I wonder if there is some way to use Kerberos referrals on AD side in a way
which would return cross-realm referral to IPA realm.

Maybe it could be used in Frankenstein setup where IPA client belongs to a DNS
domain managed by AD ... I do not know, just throwing out the idea.

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

Re: [Freeipa-devel] [PATCH] kdb: check for local realm in enterprise principals

[Petr Spacek]

On 7.7.2016 13:52, Sumit Bose wrote:
> On Thu, Jul 07, 2016 at 01:31:03PM +0200, Petr Vobornik wrote:
>> On 07/06/2016 07:01 PM, Sumit Bose wrote:
>>> Hi,
>>>
>>> although enterprise principals for trusted domains now are working as
>>> expected they do not work for the local domain:
>>>
>>> # kinit -E admin@IPA.DEVEL
>>> kinit: Client 'admin\@IPA.DEVEL@IPA.DEVEL' not found in Kerberos 
>>> database while getting initial credentials
>>>
>>> Attached patch handles this case. It is not that nice because of the
>>> duplication of ipadb_fetch_principals() and ipadb_find_principal(). But
>>> I think there was a reason I do not remember why we didn't check for
>>> enterprise principals before checking the local database. If there is no
>>> such reason it might make sense to check for enterprise principals
>>> before doing the lookup. Please let me know if I should change the patch
>>> accordingly or if the current version is ok,

I can't see the reason why we should not allow enterprise principals ...

Personally I like rule of thumb 'design is not documented -> change it as you
see fit & document it this time'.

Petr^2 Spacek

>>>
>>> bye,
>>> Sumit
>>>
>>
>> Hi Sumit,
>>
>> thanks for the patch. This patch should have a ticket. It will help
>> downstream planning.
> 
> sure, I created https://fedorahosted.org/freeipa/ticket/6036. Please
> clone it to suitable downstream tickets.
> 
> Please note that we didn't released a patch for SSSD to enable enterprise
> principals automatically if the IPA server (should) support them because
> of this issues. Since 4.4.0 is already released I think we have to wait
> on the SSSD side until a new FreeIPA version with a fix is released.

-- 
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] Dogtag 10.3.4 in Fedora 24?

[Petr Spacek]

Hello,

IPA 4.4.0 requires Dogtag >= 10.3.4. Is this version going to be built for
Fedora any time soon?

Or should I update my scripts to automatically enable
COPR @freeipa/freeipa-master
in my testing VMs?

Thanks.
Petr^2 Spacek


> commit 45daffa22fcc6c481a8302f1947a5e0ded0b3eb8
> CommitDate: Tue Jun 28 19:15:35 2016 +0200
> 
> Set default OCSP URI on install and upgrade
> 
> Dogtag has been updated to support a default OCSP URI when the
> profile includes AuthInfoAccess with URI method but does not specify
> the URI (instead of constructing one based on Dogtag's hostname and
> port).
> 
> Add the pkispawn config to ensure that the OCSP URI is set before
> issuing CA and system certificates, and add the config to existing
> CA instances on upgrade.
> 
> Fixes: https://fedorahosted.org/freeipa/ticket/5956
> Reviewed-By: Martin Basti 
> ---
>  freeipa.spec.in | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/freeipa.spec.in b/freeipa.spec.in
> index c86fc31..a4d3c06 100644
> --- a/freeipa.spec.in
> +++ b/freeipa.spec.in
> @@ -94,7 +94,7 @@ BuildRequires:  libunistring-devel
>  BuildRequires:  python-lesscpy
>  BuildRequires:  python-yubico >= 1.2.3
>  BuildRequires:  openssl-devel
> -BuildRequires:  pki-base >= 10.3.3
> +BuildRequires:  pki-base >= 10.3.4

-- 
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 0548] Fix replica install with CA

[Petr Spacek]

On 30.6.2016 18:05, Martin Basti wrote:
> 
> 
> On 30.06.2016 13:20, Martin Basti wrote:
>>
>>
>> On 30.06.2016 13:18, Petr Spacek wrote:
>>> On 30.6.2016 13:04, Martin Basti wrote:
>>>> https://fedorahosted.org/freeipa/ticket/5966
>>>>
>>>> This only for master branch, ipa-4-3 fix will be different (soon)
>>>>
>>>> Patch attached
>>> ACK
>>>
>> Pushed to master: a155f692e7ad7807a5ea28250d1e72b3e821991e
>>
> 
> And 4.3 patch attached.

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

Re: [Freeipa-devel] [PATCH] 0046 Create server certs with DNS altname

[Petr Spacek]

On 20.1.2016 05:04, Fraser Tweedale wrote:
> On Tue, Dec 08, 2015 at 07:06:39PM +1000, Fraser Tweedale wrote:
>> On Mon, Dec 07, 2015 at 05:50:05PM -0500, Rob Crittenden wrote:
>>> Fraser Tweedale wrote:
 On Mon, Dec 07, 2015 at 01:53:15PM +0100, Martin Kosek wrote:
> On 12/07/2015 06:26 AM, Fraser Tweedale wrote:
>> The attached patch fixes
>> https://fedorahosted.org/freeipa/ticket/4970.
>>
>> Note that the problem is addressed by adding the appropriate request
>> extension to the CSR; the fix does not involve changing the default
>> profile behaviour, which is complicated (see ticket for details).
>
> Thanks for the patch! This is something we should really fix, I already 
> get
> warnings in my Python scripts when I hit sites protected by such HTTPS 
> cert:
>
> /usr/lib/python2.7/site-packages/requests/packages/urllib3/connection.py:264:
> SubjectAltNameWarning: Certificate for projects.engineering.redhat.com 
> has no
> `subjectAltName`, falling back to check for a `commonName` for now. This
> feature is being removed by major browsers and deprecated by RFC 2818. 
> (See
> https://github.com/shazow/urllib3/issues/497 for details.)
>
> Should we split ticket 4970, for the FreeIPA server part and then for cert
> profile part? As it looks like the FreeIPA server will be fixed even in 
> FreeIPA
> 4.3.x and the other part later.
>
> How difficult do you see the general FreeIPA Certificate Profile part of 
> this
> request? Is it a too big task to handle in 4.4 time frame?
>
 I will split the ticket and would suggest 4.4 Backlog - it might be
 doable but is a lower priority than e.g. Sub-CAs.
>>>
>>> If you are going to defer the profile part then you should probably
>>> update the client to also include a SAN if --request-cert is provided.
>>>
>>> rob
>>>
>> Yes, good idea.  Updated patch attached.
>>
>> Cheers,
>> Fraser
> 
> Bump, with rebased patch.

Hi,

this seems to work for Apache on IPA server & client cert. ACK.

Interestingly enough I found out that Dogtag cert used on port 8443 does not
have any SAN.

Is it in scope of this ticket?

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