date:20150624

Re: [Freeipa-devel] Topology: Central node removal in star topology

2015-06-24 Thread Ludwig Krispenz



On 06/24/2015 09:01 PM, Simo Sorce wrote:

On Wed, 2015-06-24 at 11:25 +0200, Ludwig Krispenz wrote:

Oleg,

the topology plugin relies on existing connection between servers which
remain in a topolgy. If you remove a central node in your topology you
are asking for trouble.
With Petr's patch it warns you that your topology will be disconnected,
and if you insist we cannot guarantee anything.
should we completely prohibit this ?

No, but a --force should be needed.
Without a --force option we should not allow to remove a replica
completely from another one.


I don't know, I think you could
also enforce an uninstall of vm175 with probably the same result.
what you mean be calculating the remaining topology and send it to the
remaining servers does not work, it would require to send a removal of a
segment, which would be rejected.

You would have to connect to each replica that has a replication
agreement with vm175 and remove the segment from that replica. But it
wouldn't really help much as once a replica is isolated from the central
one, it will not see the other operations going on in other replicas.

Once we have a topology resolver we will be able to warn that removing a
specific replica will cause a split brain and make very loud warnings

we have this already, see the output of Oleg's example:

ipa-replica-manage del vm-175.idm.lab.eng.brq.redhat.com
Topology after removal of vm-175.idm.lab.eng.brq.redhat.com will be 
disconnected:
Server vm-036.idm.lab.eng.brq.redhat.com can't contact servers: 
vm-056.idm.lab.eng.brq.redhat.com, vm-127.idm.lab.eng.brq.redhat.com
Server vm-056.idm.lab.eng.brq.redhat.com can't contact servers: 
vm-244.idm.lab.eng.brq.redhat.com, vm-036.idm.lab.eng.brq.redhat.com, 
vm-127.idm.lab.eng.brq.redhat.com
Server vm-127.idm.lab.eng.brq.redhat.com can't contact servers: 
vm-244.idm.lab.eng.brq.redhat.com, vm-056.idm.lab.eng.brq.redhat.com, 
vm-036.idm.lab.eng.brq.redhat.com
Server vm-244.idm.lab.eng.brq.redhat.com can't contact servers: 
vm-056.idm.lab.eng.brq.redhat.com, vm-127.idm.lab.eng.brq.redhat.com

Continue to delete? [no]: yes

it tells you that the topology gets disconnected and which connections 
will be missing, the continue yes/no is the --force,

the question was, should we allow a force in this situation ?


More interesting would be if we can heal this later by adding new segments.

Indeed, reconnecting all the severed replicas should cause all the
removals (segments or servers) to be replicated among servers and should
bring back the topology view in a consistent state. But not until all
servers are reconnected and replication has started again.
This healing can also be required without forcing removal by an admin. 
If you have a start topology and your central node goes down and is not 
recoverable


Simo.



Ludwig
On 06/24/2015 11:04 AM, Oleg Fayans wrote:

Hi everybody,

Current implementation of topology plugin (including patch 878 from
Petr) allows the deletion of the central node in the star topology.
I had the following topology:

vm056  vm036
  \ / |
  vm175 |
  / \ |
vm127   vm244

I was able to remove node vm175 from node vm244:

[17:54:48]ofayans@vm-244:~]$ ipa-replica-manage del
vm-175.idm.lab.eng.brq.redhat.com
Topology after removal of vm-175.idm.lab.eng.brq.redhat.com will be
disconnected:
Server vm-036.idm.lab.eng.brq.redhat.com can't contact servers:
vm-056.idm.lab.eng.brq.redhat.com, vm-127.idm.lab.eng.brq.redhat.com
Server vm-056.idm.lab.eng.brq.redhat.com can't contact servers:
vm-244.idm.lab.eng.brq.redhat.com, vm-036.idm.lab.eng.brq.redhat.com,
vm-127.idm.lab.eng.brq.redhat.com
Server vm-127.idm.lab.eng.brq.redhat.com can't contact servers:
vm-244.idm.lab.eng.brq.redhat.com, vm-056.idm.lab.eng.brq.redhat.com,
vm-036.idm.lab.eng.brq.redhat.com
Server vm-244.idm.lab.eng.brq.redhat.com can't contact servers:
vm-056.idm.lab.eng.brq.redhat.com, vm-127.idm.lab.eng.brq.redhat.com
Continue to delete? [no]: yes
Waiting for removal of replication agreements
unexpected error: limits exceeded for this query

I would expect this operation to delete 4 replication agreements on
all nodes:
vm056 - vm175
vm127 - vm175
vm244 - vm175
vm036 - vm175

However an arbitrary set of replication agreements was deleted on each
node leading to total infrastructure inconsistency:
===
vm056**thought the topology was as follows:
vm056  vm036
/ |
  vm175 |
  / \ |
vm127   vm244
[10:28:55]ofayans@vm-056:~]$ ipa topologysegment-find realm
--
4 segments matched
--
   Segment name: 036-to-244
   Left node: vm-036.idm.lab.eng.brq.redhat.com
   Right node: vm-244.idm.lab.eng.brq.redhat.com
   Connectivity: both

   Segment name:
vm-036.idm.lab.eng.brq.redhat.com-to-vm-175.idm.lab.eng.brq.redhat.com
   Left node: vm-036.idm.lab.eng.brq.redhat.com
   Right node: v

Re: [Freeipa-devel] [PATCH] Password vault

2015-06-24 Thread Jan Cholasta


Dne 23.6.2015 v 05:27 Endi Sukma Dewata napsal(a):

Please take a look at the new patch.

On 6/17/2015 1:32 AM, Jan Cholasta wrote:

I think it would be better to use a new attribute type which inherits
from ipaPublicKey (ipaVaultPublicKey?) rather than ipaPublicKey
directly
for assymetric vault public keys, so that assymetric public key and
escrow public key are on the same level and you can still use
ipaPublicKey to refer to either one:

 ipaPublicKey
 ipaVaultPublicKey
 ipaEscrowPublicKey


OK. To be consistent the parameters need to be renamed too:
--vault-public-key and --vault-public-key-file.


It doesn't need to, there is no requirement for CLI names to always
match attribute names. (Also I don't insist on the name
"ipaVaultPublicKey", feel free to change it if you want.)


It's unchanged for now. In a previous discussion it was advised to reuse
the existing attribute type whenever possible.


Well, in this discussion, it is not. Escrow public key should also reuse 
ipaPublicKey, but it can't if you use it for vault public key. By using 
ipaPublicKey subtypes you can distinguish between the two uses and still 
use ipaPublicKey to refer to either of them.





1. The vault_add was split into a client-side vault_add and
server-side
vault_add_internal since the parameters are different (i.e. public
key file and
future escrow-related params). Since vault_add inherits from Local
all
non-primary-key attributes have to be added explicitly.


The split is not really necessary, since the only difference is the
public_key_file option, which exists only because of the lack of proper
file support in the framework. This is a different situation from
vault_{archive,retrieve}, which has two different sets of options on
client and server side. Escrow adds only ipaescrowpublickey and
escrow_public_key_file, right? If yes, we can safely keep the
command in
a single piece.


We know the vault-add will have at least two client-only parameters:
vault_public_key_file and escrow_public_key_file. Keeping these
parameters on the server API would be wrong and confusing. If the API is
called on the server side with vault_public_key_file the operation will
fail. In the previous discussion you considered this as broken API:


Server API is used not only by the server itself, but also by
installers
for example. Anyway the point is that there *can't* be a broken API
like
this, you should at least raise an error if the command is called from
server API, although actually separating it into client and server
parts
would be preferable.


You are comparing apples and oranges:


Non-identical items are different by definition. Even between 2 apples
there are differences, but it doesn't mean the distinction is important.
The latest patch shows that the vault_add needs to be split, not just
because of the options, but because of what they do differently on the
client and server.


  a) When the non-split vault_{archive,retrieve} was called from a
server API with client-only options, it crashed. This is the broken API
I was talking about.


This is because in the current framework any API called on the server
side will be a server API, so you are not supposed to call it with
client options in the first place. Because of that limitation, the only
way to use client options is to use a separate API on the client side to
call the original API on the server side. The point is, client options
belong to client API, and server options belong to server API. In
vault_add the public key file name belongs to client API because it's
used to load a file on the client side. You should not add public key
file name option to the server API just because it can safely be ignored.


I don't disagree, but file name options do not belong to the general 
client API either, as they are strictly CLI-specific.





  b) The non-split vault_{archive,retrieve} had server-only options,
which were also accepted on client, but setting them had no effect.


Similarly, in a combined vault_add the public key file name option will
be accepted by the server, but it will be ignored. If something calls
vault_add on the server side and provides a file name, the operation
will crash too because the command expects the public key data to be
provided via another option. Splitting the vault_add into client and
server components avoids the potential problems.


  c) The CLI options to read param values from files should be generated
by the framework without having to specify dummy params. Once this is
implemented, the dummy params will go away. However, this will still
leave some client-only options in vault_{archive,retrieve}.


I'm not sure how the options will look like when that's implemented, but
regardless, the vault_add will still have client-only password option.


None of the above applies to vault_add - it does not have any
server-only options and the only client-only options it has are the
dummy options for file input, which are ignored on the serv

Re: [Freeipa-devel] python-kdcproxy > 0.3

2015-06-24 Thread Martin Kosek

On 06/24/2015 07:19 PM, Christian Heimes wrote:
> Hi,
> 
> today my patch for Kerberos over HTTP landed in FreeIPA. It introduces a
> new dependency on python-kdcproxy > 0.3. The package is not yet
> available from the official repositories. You can download it from Koji:
> 
>   http://koji.fedoraproject.org/koji/packageinfo?packageID=19292
> 
> F21 builds are currently broken. The tox.ini uses a feature, that is not
> supported by tox < 1.8. Fedora 21 has tox 1.7.1. I've submitted an
> upstream fix:
> 
>   https://github.com/npmccallum/kdcproxy/pull/19
> 
> I'm sorry for any inconveniences!
> Christian

We need to make sure it is at least in

https://copr.fedoraproject.org/coprs/mkosek/freeipa-4.2/builds/
https://copr.fedoraproject.org/coprs/mkosek/freeipa-master/builds/

I started the COPR builds based on the F22 SRPMs.

-- 
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] Topology: Central node removal in star topology

2015-06-24 Thread Simo Sorce

On Wed, 2015-06-24 at 15:01 -0400, Simo Sorce wrote:
> 
> No, but a --force should be needed.
> Without a --force option we should not allow to remove a replica
> completely from another one.

I meant to add: if that action breaks the topology.
I think it is ""ok"" if we are removing a leaf from a central node.

Simo.

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

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

Re: [Freeipa-devel] Topology: Central node removal in star topology

2015-06-24 Thread Simo Sorce

On Wed, 2015-06-24 at 11:25 +0200, Ludwig Krispenz wrote:
> Oleg,
> 
> the topology plugin relies on existing connection between servers which 
> remain in a topolgy. If you remove a central node in your topology you 
> are asking for trouble.
> With Petr's patch it warns you that your topology will be disconnected, 
> and if you insist we cannot guarantee anything.
> should we completely prohibit this ? 

No, but a --force should be needed.
Without a --force option we should not allow to remove a replica
completely from another one.

> I don't know, I think you could 
> also enforce an uninstall of vm175 with probably the same result.
> what you mean be calculating the remaining topology and send it to the 
> remaining servers does not work, it would require to send a removal of a 
> segment, which would be rejected.

You would have to connect to each replica that has a replication
agreement with vm175 and remove the segment from that replica. But it
wouldn't really help much as once a replica is isolated from the central
one, it will not see the other operations going on in other replicas.

Once we have a topology resolver we will be able to warn that removing a
specific replica will cause a split brain and make very loud warnings
and even offer solutions on how to reconnect the remaining replicas, but
nothing else can really be done if the admin insist in break the
replication topology, I guess.

> The topology is broken, and I don't know how much we should invest in 
> making this info consistent on all servers.

We just need to make it very clear to the admin that replication is
broken, later on we'll have visual tools to make it easier to understand
what is going on, but that's all we can do.

> More interesting would be if we can heal this later by adding new segments.

Indeed, reconnecting all the severed replicas should cause all the
removals (segments or servers) to be replicated among servers and should
bring back the topology view in a consistent state. But not until all
servers are reconnected and replication has started again.

Simo.


> Ludwig
> On 06/24/2015 11:04 AM, Oleg Fayans wrote:
> > Hi everybody,
> >
> > Current implementation of topology plugin (including patch 878 from 
> > Petr) allows the deletion of the central node in the star topology.
> > I had the following topology:
> >
> > vm056  vm036
> >  \ / |
> >  vm175 |
> >  / \ |
> > vm127   vm244
> >
> > I was able to remove node vm175 from node vm244:
> >
> > [17:54:48]ofayans@vm-244:~]$ ipa-replica-manage del 
> > vm-175.idm.lab.eng.brq.redhat.com
> > Topology after removal of vm-175.idm.lab.eng.brq.redhat.com will be 
> > disconnected:
> > Server vm-036.idm.lab.eng.brq.redhat.com can't contact servers: 
> > vm-056.idm.lab.eng.brq.redhat.com, vm-127.idm.lab.eng.brq.redhat.com
> > Server vm-056.idm.lab.eng.brq.redhat.com can't contact servers: 
> > vm-244.idm.lab.eng.brq.redhat.com, vm-036.idm.lab.eng.brq.redhat.com, 
> > vm-127.idm.lab.eng.brq.redhat.com
> > Server vm-127.idm.lab.eng.brq.redhat.com can't contact servers: 
> > vm-244.idm.lab.eng.brq.redhat.com, vm-056.idm.lab.eng.brq.redhat.com, 
> > vm-036.idm.lab.eng.brq.redhat.com
> > Server vm-244.idm.lab.eng.brq.redhat.com can't contact servers: 
> > vm-056.idm.lab.eng.brq.redhat.com, vm-127.idm.lab.eng.brq.redhat.com
> > Continue to delete? [no]: yes
> > Waiting for removal of replication agreements
> > unexpected error: limits exceeded for this query
> >
> > I would expect this operation to delete 4 replication agreements on 
> > all nodes:
> > vm056 - vm175
> > vm127 - vm175
> > vm244 - vm175
> > vm036 - vm175
> >
> > However an arbitrary set of replication agreements was deleted on each 
> > node leading to total infrastructure inconsistency:
> > ===
> > vm056**thought the topology was as follows:
> > vm056  vm036
> >/ |
> >  vm175 |
> >  / \ |
> > vm127   vm244
> > [10:28:55]ofayans@vm-056:~]$ ipa topologysegment-find realm
> > --
> > 4 segments matched
> > --
> >   Segment name: 036-to-244
> >   Left node: vm-036.idm.lab.eng.brq.redhat.com
> >   Right node: vm-244.idm.lab.eng.brq.redhat.com
> >   Connectivity: both
> >
> >   Segment name: 
> > vm-036.idm.lab.eng.brq.redhat.com-to-vm-175.idm.lab.eng.brq.redhat.com
> >   Left node: vm-036.idm.lab.eng.brq.redhat.com
> >   Right node: vm-175.idm.lab.eng.brq.redhat.com
> >   Connectivity: both
> >
> >   Segment name: 
> > vm-127.idm.lab.eng.brq.redhat.com-to-vm-175.idm.lab.eng.brq.redhat.com
> >   Left node: vm-127.idm.lab.eng.brq.redhat.com
> >   Right node: vm-175.idm.lab.eng.brq.redhat.com
> >   Connectivity: both
> >
> >   Segment name: 
> > vm-175.idm.lab.eng.brq.redhat.com-to-vm-244.idm.lab.eng.brq.redhat.com
> >   Left node: vm-175.idm.lab.eng.brq.redhat.com
> >   Right node: vm-244.idm.lab.eng.brq.redhat

[Freeipa-devel] [PATCHES 448-460] Allow multiple API instances (take 2)

2015-06-24 Thread Jan Cholasta


Hi,

the attached patches fix  
and .


Honza

--
Jan Cholasta
>From f7d33fa9f10da20460fb3d1c0a62c96742edab29 Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Wed, 24 Jun 2015 15:14:54 +
Subject: [PATCH 01/13] plugable: Move plugin base class and override logic to
 API

Each API object now maintains its own view of registered plugins. This change
removes the need to register plugin base classes.

This reverts commit 2db741e847c60d712dbc8ee1cd65a978a78eb312.

https://fedorahosted.org/freeipa/ticket/3090
https://fedorahosted.org/freeipa/ticket/5073
---
 ipalib/backend.py |   3 -
 ipalib/frontend.py|   9 +-
 ipalib/plugable.py| 273 +++---
 ipaserver/advise/base.py  |   5 +-
 ipatests/test_ipalib/test_plugable.py | 118 +++
 5 files changed, 144 insertions(+), 264 deletions(-)

diff --git a/ipalib/backend.py b/ipalib/backend.py
index fcbbd25..0f381cb 100644
--- a/ipalib/backend.py
+++ b/ipalib/backend.py
@@ -27,10 +27,7 @@ import os
 from errors import PublicError, InternalError, CommandError
 from request import context, Connection, destroy_context
 
-register = plugable.Registry()
 
-
-@register.base()
 class Backend(plugable.Plugin):
 """
 Base class for all backend plugins.
diff --git a/ipalib/frontend.py b/ipalib/frontend.py
index 19190c3..0b42cb6 100644
--- a/ipalib/frontend.py
+++ b/ipalib/frontend.py
@@ -27,7 +27,7 @@ from distutils import version
 from ipapython.version import API_VERSION
 from ipapython.ipa_log_manager import root_logger
 from base import NameSpace
-from plugable import Plugin, Registry, is_production_mode
+from plugable import Plugin, is_production_mode
 from parameters import create_param, Param, Str, Flag, Password
 from output import Output, Entry, ListOfEntries
 from text import _
@@ -40,9 +40,6 @@ from textwrap import wrap
 
 RULE_FLAG = 'validation_rule'
 
-register = Registry()
-
-
 def rule(obj):
 assert not hasattr(obj, RULE_FLAG)
 setattr(obj, RULE_FLAG, True)
@@ -369,7 +366,6 @@ class HasParam(Plugin):
 setattr(self, name, namespace)
 
 
-@register.base()
 class Command(HasParam):
 """
 A public IPA atomic operation.
@@ -1124,7 +1120,6 @@ class Local(Command):
 return self.forward(*args, **options)
 
 
-@register.base()
 class Object(HasParam):
 finalize_early = False
 
@@ -1283,7 +1278,6 @@ class Attribute(Plugin):
 super(Attribute, self)._on_finalize()
 
 
-@register.base()
 class Method(Attribute, Command):
 """
 A command with an associated object.
@@ -1370,7 +1364,6 @@ class Method(Attribute, Command):
 yield param
 
 
-@register.base()
 class Updater(Plugin):
 """
 An LDAP update with an associated object (always update).
diff --git a/ipalib/plugable.py b/ipalib/plugable.py
index 4c42e1e..ad662e5 100644
--- a/ipalib/plugable.py
+++ b/ipalib/plugable.py
@@ -35,6 +35,7 @@ import subprocess
 import optparse
 import errors
 import textwrap
+import collections
 
 from config import Env
 import util
@@ -74,94 +75,13 @@ class Registry(object):
 For forward compatibility, make sure that the module-level instance of
 this object is named "register".
 """
-
-__allowed = {}
-__registered = set()
-
-def base(self):
-def decorator(base):
-if not inspect.isclass(base):
-raise TypeError('plugin base must be a class; got %r' % base)
-
-if base in self.__allowed:
-raise errors.PluginDuplicateError(plugin=base)
-
-self.__allowed[base] = {}
-
-return base
-
-return decorator
-
-def __findbases(self, klass):
-"""
-Iterates through allowed bases that ``klass`` is a subclass of.
-
-Raises `errors.PluginSubclassError` if ``klass`` is not a subclass of
-any allowed base.
-
-:param klass: The plugin class to find bases for.
-"""
-found = False
-for (base, sub_d) in self.__allowed.iteritems():
-if issubclass(klass, base):
-found = True
-yield (base, sub_d)
-if not found:
-raise errors.PluginSubclassError(
-plugin=klass, bases=self.__allowed.keys()
-)
-
-def __call__(self, override=False):
-def decorator(klass):
-if not inspect.isclass(klass):
-raise TypeError('plugin must be a class; got %r' % klass)
-
-# Raise DuplicateError if this exact class was already registered:
-if klass in self.__registered:
-raise errors.PluginDuplicateError(plugin=klass)
-
-# Find the base class or raise SubclassError:
-for (base, sub_d) in self.__findbases(klass):
-# Check override:
-if klass.__name__ in sub_d:
-

[Freeipa-devel] docker-based upstream builder

2015-06-24 Thread Oleg Fayans


Hi everybody,

A while ago I've created a docker image to build freeipa packages with 
development patches applied on top of the upstream repo. I also created 
a script that would launch the container, tell it to build packages and, 
once done, stop the container. The container had a special folder on my 
laptop mounted as volume, so any time I wanted to test some patches, i 
just put the patches to this folder and container applied it for me, so 
all I had to do is just call my script. I find it pretty handy for 
testing purposes, so I'd like to share it with the team.

Everything needed to build the docker image (f22-based) can be found here:
https://github.com/ofayans/freeipa_upstream_builder
The local script to launch container is attached.

--
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.



buildrpms.sh
Description: application/shellscript
-- 
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] [Test Plan] Manage replication topology

2015-06-24 Thread Oleg Fayans


Hi,

The initial revision of the Replication Topology plugin Test Plan is 
available at

http://www.freeipa.org/page/V4/Manage_replication_topology/Test_plan

It does not yet contain testcases checking all possible Topology related 
actions, just a very basic stuff.


--
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.

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

Re: [Freeipa-devel] [PATCHES 330-331] Update translations and introduce Zanata configuration

2015-06-24 Thread Tomas Babej

On 06/24/2015 04:29 PM, Martin Basti wrote:
> On 24/06/15 14:39, Tomas Babej wrote:
>> +msgid "Automount location name."
>> +msgstr "Job Title"
>> +
> 
> in german po file
> 
> +msgid "Automount location name."
> +msgstr "Job Title"
> +
> 
> 
> AFAIK, this is not german language.
> 

Nice catch!

You can show off your German language skills by entering the correct
translation here:

https://fedora.zanata.org/webtrans/Application.seam?project=freeipa&iteration=master&localeId=de&locale=en#view:doc;doc:install/po/ipa;search:Automount%20location%20name

So far, I removed the wrong translation string in Zanata.

Tomas

-- 
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] topologysegment-mod question

2015-06-24 Thread Ludwig Krispenz



On 06/24/2015 04:19 PM, Oleg Fayans wrote:



On 06/24/2015 02:35 PM, Ludwig Krispenz wrote:


On 06/24/2015 02:30 PM, Oleg Fayans wrote:



On 06/24/2015 02:25 PM, Ludwig Krispenz wrote:


On 06/24/2015 01:59 PM, Oleg Fayans wrote:

Hi Petr,

Thanks for clarification! It seems though, that all possible 
attributes are already mapped to the topologysegment-mod options:


[13:42:45]ofayans@vm-244:~]$  ipa show-mappings topologysegment-mod
Parameter  : LDAP attribute
=  : ==
stripattrs : nsds5replicastripattrs
replattrs  : nsds5replicatedattributelist
replattrstotal : nsds5replicatedattributelisttotal
timeout: nsds5replicatimeout
enabled: nsds5replicaenabled
rights : rights
[13:47:41]ofayans@vm-244:~]$ ipa help topologysegment-mod
Usage: ipa [global-options] topologysegment-mod TOPOLOGYSUFFIX 
NAME [options]


Modify a segment.
Options:
  -h, --helpshow this help message and exit
  --stripattrs=STR  A space separated list of attributes which 
are removed

from replication updates.
  --replattrs=STR   Attributes that are not replicated to a 
consumer

server during a fractional update. E.g.,
`(objectclass=*) $ EXCLUDE accountlockout 
memberof
  --replattrstotal=STR  Attributes that are not replicated to a 
consumer
server during a total update. E.g. 
(objectclass=*) $

EXCLUDE accountlockout
  --timeout=INT Number of seconds outbound LDAP operations 
waits for a
response from the remote replica before 
timing out and

failing
  --enabled=['on', 'off']
Whether a replication agreement is active, 
meaning
whether replication is occurring per that 
agreement
  --setattr=STR Set an attribute to a name/value pair. 
Format is
attr=value. For multi-valued attributes, 
the command

replaces the values already present.
  --addattr=STR Add an attribute/value pair. Format is 
attr=value. The

attribute must be part of the schema.
  --delattr=STR Delete an attribute/value pair. The option 
will be

evaluated last, after all sets and adds.
  --rights  Display the access rights of this entry 
(requires

--all). See ipa man page for details.
  --all Retrieve and print all attributes from the 
server.

Affects command output.
  --raw Print entries as stored on the server. 
Only affects

output format.

So, setattr, addattr and delattr should, I think, be explained in 
the design document, with example usage.


Another question that I have:
In order to test topologysegment-reinitialize, I need to set the 
replica timeout to, say, 1, then turn this replica off, then make 
some changes on master and turn on the replica? I mean, my goal is 
to make master to give up attempts to synchronize with replica, is 
that correct?
I don't see why you want to do all these steps, initialize means 
that the database of B is overwritten by the database of A, so you 
could check that the content is the same. But to simulate a 
situation where init is required is not so easy, if you turn the 
replica on again, the changes could be normally replicated before 
you start the init
The question is: how do I make sure that the content on node /a /is 
overwritten with the content of node /b/? I kind of need the two 
nodes to have different content and not trying to synchronize 
automatically
you could combine this with a backup test. On server A make a backup, 
make some changes on any node and wait until it is replicated 
everywhere. restore A from the backup and reinitialize the complete 
topology. It should be enough with 2 or three servers
Will the changes introduced by restoring from backup not get 
replicated automatically?
no, a restore will only replace the database, then it depends on the 
replication agreements and state of other servers. On the restored 
server the changes after backup are no longer available, but they coul 
be replicated back from other servers, that's why it is recommended to 
disable repl agreements to this server and then reinit


On 06/24/2015 12:28 PM, Petr Vobornik wrote:

On 06/24/2015 12:19 PM, Oleg Fayans wrote:

Hi Ludwig,

I see some contradictions in the way the segment modification 
cli is

implemented:

1.
$ ipa help topologysegment-mod
Usage: ipa [global-options] topologysegment-mod TOPOLOGYSUFFIX NAME
[options]

$ ipa topologysegment-mod realm 127-to-244 --setattr=Segment 
name=test

ipa: ERROR: command 'topologysegment_mod' takes at most 2 arguments

(suffix + name + options = 3, not 2)


'Segment name' is not correct attribute name. More below.



2.
Is there a way to list a

Re: [Freeipa-devel] [PATCHES 330-331] Update translations and introduce Zanata configuration

2015-06-24 Thread Martin Basti


On 24/06/15 14:39, Tomas Babej wrote:

+msgid "Automount location name."
+msgstr "Job Title"
+


in german po file

+msgid "Automount location name."
+msgstr "Job Title"
+


AFAIK, this is not german language.

--
Martin Basti

--
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] topologysegment-mod question

2015-06-24 Thread Petr Vobornik


On 06/24/2015 04:19 PM, Oleg Fayans wrote:



On 06/24/2015 02:35 PM, Ludwig Krispenz wrote:


On 06/24/2015 02:30 PM, Oleg Fayans wrote:



On 06/24/2015 02:25 PM, Ludwig Krispenz wrote:


On 06/24/2015 01:59 PM, Oleg Fayans wrote:

Hi Petr,

Thanks for clarification! It seems though, that all possible
attributes are already mapped to the topologysegment-mod options:

[13:42:45]ofayans@vm-244:~]$  ipa show-mappings topologysegment-mod
Parameter  : LDAP attribute
=  : ==
stripattrs : nsds5replicastripattrs
replattrs  : nsds5replicatedattributelist
replattrstotal : nsds5replicatedattributelisttotal
timeout: nsds5replicatimeout
enabled: nsds5replicaenabled
rights : rights
[13:47:41]ofayans@vm-244:~]$ ipa help topologysegment-mod
Usage: ipa [global-options] topologysegment-mod TOPOLOGYSUFFIX NAME
[options]

Modify a segment.
Options:
  -h, --helpshow this help message and exit
  --stripattrs=STR  A space separated list of attributes which
are removed
from replication updates.
  --replattrs=STR   Attributes that are not replicated to a
consumer
server during a fractional update. E.g.,
`(objectclass=*) $ EXCLUDE accountlockout
memberof
  --replattrstotal=STR  Attributes that are not replicated to a
consumer
server during a total update. E.g.
(objectclass=*) $
EXCLUDE accountlockout
  --timeout=INT Number of seconds outbound LDAP operations
waits for a
response from the remote replica before
timing out and
failing
  --enabled=['on', 'off']
Whether a replication agreement is active,
meaning
whether replication is occurring per that
agreement
  --setattr=STR Set an attribute to a name/value pair.
Format is
attr=value. For multi-valued attributes,
the command
replaces the values already present.
  --addattr=STR Add an attribute/value pair. Format is
attr=value. The
attribute must be part of the schema.
  --delattr=STR Delete an attribute/value pair. The option
will be
evaluated last, after all sets and adds.
  --rights  Display the access rights of this entry
(requires
--all). See ipa man page for details.
  --all Retrieve and print all attributes from the
server.
Affects command output.
  --raw Print entries as stored on the server. Only
affects
output format.

So, setattr, addattr and delattr should, I think, be explained in
the design document, with example usage.

Another question that I have:
In order to test topologysegment-reinitialize, I need to set the
replica timeout to, say, 1, then turn this replica off, then make
some changes on master and turn on the replica? I mean, my goal is
to make master to give up attempts to synchronize with replica, is
that correct?

I don't see why you want to do all these steps, initialize means
that the database of B is overwritten by the database of A, so you
could check that the content is the same. But to simulate a
situation where init is required is not so easy, if you turn the
replica on again, the changes could be normally replicated before
you start the init

The question is: how do I make sure that the content on node /a /is
overwritten with the content of node /b/? I kind of need the two
nodes to have different content and not trying to synchronize
automatically

you could combine this with a backup test. On server A make a backup,
make some changes on any node and wait until it is replicated
everywhere. restore A from the backup and reinitialize the complete
topology. It should be enough with 2 or three servers



Will the changes introduced by restoring from backup not get replicated
automatically?


This is a good scenario to test. ipa-restore tries to disable all 
replication agreements of other servers with the to-be-restored replica 
prior the restore..


It announces it with:
  Each master will individually need to be re-initialized or
  re-created from this one. The replication agreements on
  masters running IPA 3.1 or earlier will need to be manually
  re-enabled. See the man page for details.



On 06/24/2015 12:28 PM, Petr Vobornik wrote:

On 06/24/2015 12:19 PM, Oleg Fayans wrote:

Hi Ludwig,

I see some contradictions in the way the segment modification cli is
implemented:

1.
$ ipa help topologysegment-mod
Usage: ipa [global-options] topologysegment-mod TOPOLOGYSUFFIX NAME
[options]

$ ipa topologysegment-mod realm 127-to-244 --setattr=Segment
name=test
ipa: ERROR: command 'topologysegment_mod' takes at most 2 arguments

(suffix + name + options = 3, not 2)


'Segment name' is not correct attribute name. More below.

Re: [Freeipa-devel] topologysegment-mod question

2015-06-24 Thread Oleg Fayans

On 06/24/2015 02:35 PM, Ludwig Krispenz wrote:

On 06/24/2015 02:30 PM, Oleg Fayans wrote:

On 06/24/2015 02:25 PM, Ludwig Krispenz wrote:

On 06/24/2015 01:59 PM, Oleg Fayans wrote:

Hi Petr,

Thanks for clarification! It seems though, that all possible
attributes are already mapped to the topologysegment-mod options:

[13:42:45]ofayans@vm-244:~]$ ipa show-mappings topologysegment-mod
Parameter : LDAP attribute
= : ==
stripattrs : nsds5replicastripattrs
replattrs : nsds5replicatedattributelist
replattrstotal : nsds5replicatedattributelisttotal
timeout: nsds5replicatimeout
enabled: nsds5replicaenabled
rights : rights
[13:47:41]ofayans@vm-244:~]$ ipa help topologysegment-mod
Usage: ipa [global-options] topologysegment-mod TOPOLOGYSUFFIX NAME
[options]

Modify a segment.
Options:
-h, --helpshow this help message and exit
--stripattrs=STR A space separated list of attributes which
are removed

from replication updates.
--replattrs=STR Attributes that are not replicated to a
consumer

server during a fractional update. E.g.,
`(objectclass=*) $ EXCLUDE accountlockout
memberof
--replattrstotal=STR Attributes that are not replicated to a
consumer
server during a total update. E.g.
(objectclass=*) $

EXCLUDE accountlockout
--timeout=INT Number of seconds outbound LDAP operations
waits for a
response from the remote replica before
timing out and

failing
--enabled=['on', 'off']
Whether a replication agreement is active,
meaning
whether replication is occurring per that
agreement
--setattr=STR Set an attribute to a name/value pair.
Format is
attr=value. For multi-valued attributes,
the command

replaces the values already present.
--addattr=STR Add an attribute/value pair. Format is
attr=value. The

attribute must be part of the schema.
--delattr=STR Delete an attribute/value pair. The option
will be

evaluated last, after all sets and adds.
--rights Display the access rights of this entry
(requires

--all). See ipa man page for details.
--all Retrieve and print all attributes from the
server.

Affects command output.
--raw Print entries as stored on the server. Only
affects

output format.

So, setattr, addattr and delattr should, I think, be explained in
the design document, with example usage.

Another question that I have:
In order to test topologysegment-reinitialize, I need to set the
replica timeout to, say, 1, then turn this replica off, then make
some changes on master and turn on the replica? I mean, my goal is
to make master to give up attempts to synchronize with replica, is
that correct?
I don't see why you want to do all these steps, initialize means
that the database of B is overwritten by the database of A, so you
could check that the content is the same. But to simulate a
situation where init is required is not so easy, if you turn the
replica on again, the changes could be normally replicated before
you start the init
The question is: how do I make sure that the content on node /a /is
overwritten with the content of node /b/? I kind of need the two
nodes to have different content and not trying to synchronize
automatically
you could combine this with a backup test. On server A make a backup,
make some changes on any node and wait until it is replicated
everywhere. restore A from the backup and reinitialize the complete
topology. It should be enough with 2 or three servers
Will the changes introduced by restoring from backup not get replicated
automatically?

On 06/24/2015 12:28 PM, Petr Vobornik wrote:

On 06/24/2015 12:19 PM, Oleg Fayans wrote:

Hi Ludwig,

I see some contradictions in the way the segment modification cli is
implemented:

1.
$ ipa help topologysegment-mod
Usage: ipa [global-options] topologysegment-mod TOPOLOGYSUFFIX NAME
[options]

$ ipa topologysegment-mod realm 127-to-244 --setattr=Segment
name=test

ipa: ERROR: command 'topologysegment_mod' takes at most 2 arguments

(suffix + name + options = 3, not 2)

'Segment name' is not correct attribute name. More below.

2.
Is there a way to list all possible attributes available for
modification?
When do topologysegment-show --all, I get quite a small number of
them,

and even them I am unable to modify:

$ ipa topologysegment-show realm 127-to-244 --all
dn:
cn=127-to-244,cn=realm,cn=topology,cn=ipa,cn=etc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com

Segment name: 127-to-244
Left node: vm-127.idm.lab.eng.brq.

[Freeipa-devel] python-kdcproxy > 0.3

2015-06-24 Thread Christian Heimes

Hi,

today my patch for Kerberos over HTTP landed in FreeIPA. It introduces a
new dependency on python-kdcproxy > 0.3. The package is not yet
available from the official repositories. You can download it from Koji:

  http://koji.fedoraproject.org/koji/packageinfo?packageID=19292

F21 builds are currently broken. The tox.ini uses a feature, that is not
supported by tox < 1.8. Fedora 21 has tox 1.7.1. I've submitted an
upstream fix:

  https://github.com/npmccallum/kdcproxy/pull/19

I'm sorry for any inconveniences!
Christian



signature.asc
Description: OpenPGP digital signature
-- 
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] Notice: FreeIPA localization strings updated, deadline 2015-07-01

2015-06-24 Thread Tomas Babej

Hello, FreeIPA translators!

Updated translation strings are available for localization at the
fedora.zanata.org Zanata server instance:

https://fedora.zanata.org/iteration/view/freeipa/master

Please update the translations at your leisure in the next 7 days, we
plan to pull the translations for 4.2 release from Zanata on Wednesday,
July the 1st.

Additionally, given the push for automated updates of the translation
strings in the past, this is the approach we will be taking during the
4.3 development cycle, as it is achievable given now that FreeIPA
translations are hosted at Zanata. The currently proposed intervals are
to upload new strings to Zanata once per month, but if you have other
proposals, let us know.

Tomas

-- 
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 0037] Hide traceback in ipa-dnskeysyncd if kinit failed

2015-06-24 Thread Petr Vobornik


On 06/23/2015 04:29 PM, Martin Babinsky wrote:

On 06/23/2015 02:15 PM, Petr Spacek wrote:

Hello,

Hide traceback in ipa-dnskeysyncd if kinit failed.

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




ACK



Pushed to master: 33bc9e7faca55497e00a3f6c08f4bff7262e290c
Pushed to ipa-4-1: 6f9d16fd0014427db223fe82f021b12f4db2fe37
--
Petr Vobornik

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

Re: [Freeipa-devel] topologysegment-mod question

2015-06-24 Thread Ludwig Krispenz

On 06/24/2015 02:30 PM, Oleg Fayans wrote:

On 06/24/2015 02:25 PM, Ludwig Krispenz wrote:

On 06/24/2015 01:59 PM, Oleg Fayans wrote:

Hi Petr,

Thanks for clarification! It seems though, that all possible
attributes are already mapped to the topologysegment-mod options:

Modify a segment.
Options:
-h, --helpshow this help message and exit
--stripattrs=STR A space separated list of attributes which
are removed

from replication updates.
--replattrs=STR Attributes that are not replicated to a consumer
server during a fractional update. E.g.,
`(objectclass=*) $ EXCLUDE accountlockout
memberof

--replattrstotal=STR Attributes that are not replicated to a consumer
server during a total update. E.g.
(objectclass=*) $

EXCLUDE accountlockout
--timeout=INT Number of seconds outbound LDAP operations
waits for a
response from the remote replica before
timing out and

failing
--enabled=['on', 'off']
Whether a replication agreement is active,
meaning
whether replication is occurring per that
agreement

--setattr=STR Set an attribute to a name/value pair. Format is
attr=value. For multi-valued attributes, the
command

replaces the values already present.
--addattr=STR Add an attribute/value pair. Format is
attr=value. The

attribute must be part of the schema.
--delattr=STR Delete an attribute/value pair. The option
will be

evaluated last, after all sets and adds.
--rights Display the access rights of this entry
(requires

--all). See ipa man page for details.
--all Retrieve and print all attributes from the
server.

Affects command output.
--raw Print entries as stored on the server. Only
affects

output format.

So, setattr, addattr and delattr should, I think, be explained in
the design document, with example usage.

Another question that I have:
In order to test topologysegment-reinitialize, I need to set the
replica timeout to, say, 1, then turn this replica off, then make
some changes on master and turn on the replica? I mean, my goal is
to make master to give up attempts to synchronize with replica, is
that correct?
I don't see why you want to do all these steps, initialize means that
the database of B is overwritten by the database of A, so you could
check that the content is the same. But to simulate a situation where
init is required is not so easy, if you turn the replica on again,
the changes could be normally replicated before you start the init
The question is: how do I make sure that the content on node /a /is
overwritten with the content of node /b/? I kind of need the two nodes
to have different content and not trying to synchronize automatically
you could combine this with a backup test. On server A make a backup,
make some changes on any node and wait until it is replicated
everywhere. restore A from the backup and reinitialize the complete
topology. It should be enough with 2 or three servers

On 06/24/2015 12:28 PM, Petr Vobornik wrote:

On 06/24/2015 12:19 PM, Oleg Fayans wrote:

Hi Ludwig,

I see some contradictions in the way the segment modification cli is
implemented:

1.
$ ipa help topologysegment-mod
Usage: ipa [global-options] topologysegment-mod TOPOLOGYSUFFIX NAME
[options]

$ ipa topologysegment-mod realm 127-to-244 --setattr=Segment
name=test

ipa: ERROR: command 'topologysegment_mod' takes at most 2 arguments

(suffix + name + options = 3, not 2)

'Segment name' is not correct attribute name. More below.

2.
Is there a way to list all possible attributes available for
modification?
When do topologysegment-show --all, I get quite a small number of
them,

and even them I am unable to modify:

$ ipa topologysegment-show realm 127-to-244 --all
dn:
cn=127-to-244,cn=realm,cn=topology,cn=ipa,cn=etc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com

Segment name: 127-to-244
Left node: vm-127.idm.lab.eng.brq.redhat.com
Right node: vm-244.idm.lab.eng.brq.redhat.com
Connectivity: both
objectclass: top, iparepltoposegment

$ ipa topologysegme