[Freeipa-users] Announcing FreeIPA 4.3.0

[Petr Vobornik]

The FreeIPA team would like to announce FreeIPA v4.3.0 release!

It can be downloaded from http://www.freeipa.org/page/Downloads. The 
builds are available for Fedora rawhide. Builds for Fedora 23 are 
available in the official COPR repository 
.


This announcement is also available at 
.


== Highlights in 4.3.0 ==
* Simplified management of replication topology - control and display 
your topology from CLI and UI
* Simplified replica installation - install replica without ''replica 
package'' via OTP, keytab or privileged user credentials. The new method 
is called ''replica promotion'' as it adds FreeIPA server capability to 
existing or new client


=== Domain Level ===
Both feature sets are tight with introduction of new "server capability 
indicator" - a "domain level". Domain level indicates that server is 
capable of doing certain operations. Domain level 1 means that it 
supports replica promotion and topology management.


Old servers and servers upgraded to 4.3 in existing environments have 
domain level 0. In order to use new functionality all servers needs to 
be updated to a version which supports the domain level, right now it is 
only version 4.3. Domain level is raised by command:

$ ipa domainlevel-set 1

Current domain can be obtained by:
$ ipa domainlevel-get

Or supported levels of individual FreeIPA servers:
$ ipa server-show $HOSTNAME

=== Replica installation ===
 Old method - domain level 0 
Prior FreeIPA 4.3 replica installation needed to perform actions on both 
master and future replica.


First step on master:
$ ipa-replica-prepare $REPLICA_HOSTNAME --ip-address $REPLICA_IP

It created a replica file - an encrypted file containing secrets and 
other data needed for replica installation.


Second step on replica:
$ ipa-replica-install --various-options $REPLICA_FILE

Disadvantage is that both 'ipa-replica-prepared' and 
'ipa-replica-install' need directory manager password and that copying 
of the replica file is cumbersome.


Old method is still available for environments with domain level 0.

 New method - domain level 1 
New method transforms an IPA client into an IPA server. I.e., an IPA 
client can be installed first and then it can be "promoted" into an 
FreeIPA server - a new replica. Alternatively, replica installer can 
also install the client so it can be done in a single operation. New 
method doesn't require to run 'ipa-replica-prepare' and manipulate with 
replica file. There are multiple ways to install new replica:


= 1. Promotion of existing client =
On client which will become new FreeIPA server:
$ kinit admin
$ ipa-replica-install [--various-options, ...]

= 2. Installation of replica on non-FreeIPA client machine =
$ ipa-replica-install --principal admin -W [--various-options, ...]

It will ask for admin password, install a client and then promote it to 
replica. It will use DNS auto-discovery to locate the master server. 
Alternatively  the same discovery options as for 'ipa-client-install' 
can be provided: '--server', '--domain', '--realm'.


= 3. Installation of replica using one time password(OTP) =
On any host with 'ipa' command line utility available first prepare the 
host entry with One Time Password set and assign it to 'ipaservers' 
hostgroup to mark it as future IPA server.

$ kinit admin
$ ipa host-add $REPLICA_HOSTNAME --password $OTP
$ ipa hostgroup-add-member ipaservers --hosts=$REPLICA_HOSTNAME

On future replica:
$ ipa-replica-install --password $OTP [--various-options, ...]

= 4. Installation of replica using a host keytab =
Steps are similar as in installation with OTP:

On arbitrary FreeIPA client or server:
$ kinit admin
$ ipa host-add $REPLICA_HOSTNAME
$ ipa hostgroup-add-member ipaservers --hosts=$REPLICA_HOSTNAME
$ ipa-getkeytab --server=$IPASERVER_HOSTNAME 
--principal=host/$REPLICA_HOSTNAME@$REALM --keytab=replica_host.keytab
$ # copy the replica_host.keytab  to a replica on 
$REPLICA_KEYTAB_PATH (arbitrary)


On future replica:
$ ipa-replica-install --keytab  $REPLICA_KEYTAB_PATH 
[--various-options, ...]


=== Managed Replication Topology ===
FreeIPA is a multi-master technology. Data changes on a server are 
replicated automatically to all other servers. Data is stored in 
Directory Server server in two so-called suffixes: a 'domain' suffix, 
e.g., 'dc=example,dc=com' which contains all domain related data(users, 
groups, hbac and sudo rules, ...) and, if the setup has CA, a 'ca' 
suffix('o=ipaca') which contains Certificate Server data. IPA servers, 
in general, are not connected with all other servers, but usually with 
only a few. It means the data is gradually propagated.  The way is 
defined in Directory Server by so-called replication agreements. 
Replication agreements for each suffix need to be managed

Re: [Freeipa-users] unable to effectively delete a replica agreement

[Jan Pazdziora]

On Fri, Dec 18, 2015 at 03:45:33PM +0100, Karl Forner wrote:
> I am running a master freeIPA called "ipa" in an adelton/freeipa-server
> (freeIPA 4.1.4).
> I am able to create a replica server "ipa2", still in an
> adelton/freeipa-server.

I should mention that I failed to see the cause of the issues when
we discussed it with Karl in

https://github.com/adelton/docker-freeipa/issues/40

and at the same time I don't see anything container-specific in what
he attempts to do -- therefore I've asked him to bring the issue
to this forum.

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] unable to effectively delete a replica agreement

[Karl Forner]

I am running a master freeIPA called "ipa" in an adelton/freeipa-server
(freeIPA 4.1.4).
I am able to create a replica server "ipa2", still in an
adelton/freeipa-server.

If I stop my ipa2 replica, and try to delete the replication agreement:

%ipa-replica-manage del ipa2.example.com --force  -v

It hangs forever.
If I run it using the --cleanup option, it seems to work.

But when I try to run again from scratch my replica, using the same name, I
get:

Checking forwarders, please wait ...
WARNING: DNS forwarder 10.9.70.7 does not return DNSSEC signatures in
answers
Please fix forwarder configuration to enable DNSSEC support.
(For BIND 9 add directive "dnssec-enable yes;" to "options {}")
WARNING: DNSSEC validation will be disabled
Warning: skipping DNS resolution of host ipa2.example.com
Warning: skipping DNS resolution of host ipa.example.com
Using reverse zone(s) 0.17.172.in-addr.arpa.
A replication agreement for this host already exists. It needs to be
removed.
Run this on the master that generated the info file:
% ipa-replica-manage del ipa2.example.com --force

On my master:
# ipa-replica-manage list
ipas.example.com: master
ipa.example.com: master

I manually removed all DNS entries from the 3 zones mentioning ipa2. I can
check in the web UI, using the search feature that ipa2 has no occurrence.

So I do not understand why the replica install thinks there's still a
replication agreement.
And I'd like to know:
1) why this command did not work

ipa-replica-manage del ipa2.example.com --force  -v


2) How could I manually effectively delete this agrrement left-over.


Thanks.
Karl
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project