[Freeipa-users] Need for some pull-style replication, or an alternate solution

[Joshua J. Kugler]

So, we have a need for replication, but the existing push-only methodology 
doesn't work for us. I suppose our problems could be attributed to over-
zealous network rules, but it is what it is. :) I'd love to change our network 
policy, but we aren't in charge of network policy, and there is no way I'm 
swaying the person that is.

Topology:
1) DMZ environments 1,...,n
2) An Internal network
3) A remote rack in a data center.

Rules (by "talk" I mean initiate connections to):
1) DMZs can talk to each other, somewhat.
2) The Internal network can talk to the DMZs
3) The DMZ *cannot* connect to the Internal network
4) The remote rack of course cannot contact the Internal network, but can 
contact the DMZs.

Scenario A, Master in a DMZ:
 - Slave in the Internal network could contact the DMZ master for replica 
setup, but the Master could not contact the slave to push updates
 - Slave in the remote rack could contact master in DMZ, but incoming to 
remote rack is very restrictive, so it is possible that master couldn't push.

Scenario B: Master in the Internal network.
 - Slaves in DMZ and remote rack couldn't contact master for setup, although 
the master could contact the slaves to push updates.

Scenario C: Master in remote rack
 - Not acceptable as remote rack is a testing rack, and may go down at any 
time.

So, the best solution, from my current understanding is being able to somehow 
do pull-updates for replicas, because then we could have this:

 - Master in DMZs
 - Slaves in Internal network can contact Master in DMZ for replica setup and 
updates
 - Slaves in remote rack can contact Master in DMZ for replica setup and 
updates

Any feedback is appreciated, especially if I'm missing something...obvious or 
minor.

j

-- 
Joshua J. Kugler - Fairbanks, Alaska
Azariah Enterprises - Programming and Website Design
jos...@azariah.com - Jabber: pedah...@gmail.com
PGP Key: http://pgp.mit.edu/  ID 0x73B13B6A

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

Re: [Freeipa-users] Minimal permissions for "joiner" account?

[Michael Lasevich]

I wanted to use the python ipalib directly, but like you mentioned, I found
very little documentation and what I found indicated I was going to just
pass cli arguments to it, it seemed to be not much better than calling the
wrapper directly :-(

I will clean up my salt reactor of things specific to my install (mostly
just validating host against AWS and pulling AWS info to be added to the
host description fields) and try to add it to the salt-forumulas - then we
can link to it from the how-tos, etc. If someone is interested sooner, I
can post it here for time being.

As far as Host-Enrollment vs Host-Administrators privileges - it may be
that I am mixing up 2 ways to enroll hosts. My original attempt was to try
to have an "enroller" account that would add client directly from the
client - but I have relented and switched to a more proper method of adding
a host entrue with a generated OTP for the client followed by joining of
that client from the client itself with the OTP password. This works, but
when I try to add host entry with OTP password using account with only
"Host Enrollment" privilege I get:

ipa: ERROR: Insufficient access: Insufficient 'add' privilege to the
'userPassword' attribute

I really would like to have minimal privileges for my "adder" account, but
at least this account is only available on a much more restricted server
(salt-master) where only limited admins have access to it. For now I am
granting it the "Host Administrators" privilege, as it is what works.

-M



On Fri, Aug 15, 2014 at 9:26 AM, Petr Viktorin  wrote:

> On 08/15/2014 06:02 PM, James wrote:
>
>> On Fri, Aug 15, 2014 at 5:25 AM, Michael Lasevich
>>  wrote:
>>
>>> Sorry, I did not intend to belittle your efforts - just misread the code
>>>
>> Didn't take it that way, no worries :)
>>
>>  (saw you pass in $admin and $password and made wrong assumption that
>>> $admin
>>> was admin username) as well as trying to avoid puppet as I find Salt much
>>> quicker and much simpler (and already established in my setup)
>>>
>>> I sat down tonight and threw together a quick salt reactor that does same
>>> thing as your module - creates the host account in IPA with a generated
>>> OTP
>>> password and joins the host to the domain using that generated OTP (and
>>> while at it, validates the host against AWS and populates the metadata
>>> into
>>> IPA) Ended up having to join the salt master to the domain, which I was
>>> avoiding doing for security reasons, but I can just disable IPA logins in
>>> PAM and call it a day. The nice bit is that it is using the host's keytab
>>> for authentication, so I do not need any extra credentials sitting
>>> around.
>>> Seems to be working just fine. :-). I ended up granting the salt-master
>>> host
>>> the "Host Administrators" privilege. It seems that "Host Enrollment"
>>> privilege is not sufficient to enroll hosts -  go figure.
>>>
>> Great!
>>
>>
>>> The only thing that bugs me is that I am calling IPA python code from my
>>> salt reactor python code via subprocess - there has got to be a better,
>>> more
>>> direct way -  but I found documentation too confusing to follow at 1 am -
>>> will be a project for another day.
>>>
>> There is the python ipa API, not sure how stable or official it is,
>> but if you look in my code I use it occasionally.
>>
>
> The RPC API is not official (i.e. documented), but since IPA needs to keep
> backwards compatibility with its own client, it's very stable.
>
> Just be sure to send the API version with each call. (The server will send
> a warning if you don't.)
>
>
> --
> Petr³
>
>
> --
> 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
>
-- 
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

Re: [Freeipa-users] Minimal permissions for "joiner" account?

[Rob Crittenden]

Michael Lasevich wrote:
> Thanks, that was actually very helpful.
> 
> "Host Enrollment" privilege does not actually allow you to enroll hosts,
> not sure what that is about. But "Host Administrators" worked just fine.

I'd be curious to know how it was failing. It should be enough to do
just an enrollment (not add a missing host, etc).

Host Administrator also grants a slew of privileges beyond what you need.

rob

> 
> -M
> 
> 
> On Fri, Aug 15, 2014 at 1:18 AM, Martin Kosek  > wrote:
> 
> On 08/14/2014 10:23 PM, Michael Lasevich wrote:
> > Is there somewhere a documented minimum set of permissions required to
> > create a special role/account/principal to auto-join machines to
> the domain?
> >
> > I am not all too comfortable to run this as admin user and not
> quite ready
> > to set up the orchestration needed to pre-join the host.
> >
> > Thanks,
> >
> > -M
> >
> >
> >
> 
> You can simply create a system user or a joiner service and assign
> it a "Host
> Administrators" privilege:
> 
> # ipa privilege-show "Host Administrators"
>   Privilege name: Host Administrators
>   Description: Host Administrators
>   Permissions: add hosts, remove hosts, modify hosts, manage host
> ssh public keys,
>manage host keytab, enroll a host, retrieve
> certificates from
> the ca,
>revoke certificate, add krbprincipalname to a host
>   Granting privilege to roles: IT Specialist
> 
> HTH,
> Martin
> 
> 
> 
> 

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

Re: [Freeipa-users] PatternFly questions

[Martin Kosek]

Hello Duncan,

I think we are all set. As written below, I revisited the RFE that was filed
previously:

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

And added information from this thread. It is currently planned for FreeIPA 4.2
as our Web UI could indeed benefit from this functionality.

If we missed anything, please feel free to update the ticket.

THanks,
Martin

On 08/18/2014 09:49 AM, Innes, Duncan wrote:
> Bump
> 
> Back to work now - do you want RFE's written up for this stuff, or do
> you have it in hand?
> 
> D
> 
> -Original Message-
> From: freeipa-users-boun...@redhat.com
> [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Innes, Duncan
> Sent: 31 July 2014 21:47
> To: d...@redhat.com; Martin Kosek; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] PatternFly questions
> 
> Hi,
> 
> Sorry for delay - paternity leave took me away from work rather
> abruptly.
> 
> Do you still want RFE's written up for these?
> 
> My brain might have been fried when I thought about this, but is there
> any mileage in creating an elasticsearch (or similar) database of the
> useful fields and using that for searching?  If LDAP searches are the
> limiting factor that is.  Keeping the databases in sync might be an
> issue, but the elasticsearch database would be read-only for users and
> would allow a potentially richer method of searching.
> 
> Back at work on Monday, so should be able to write up some RFE's then if
> they're still needed.
> 
> Cheers
> 
> D 
> 
> -Original Message-
> From: freeipa-users-boun...@redhat.com
> [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dmitri Pal
> Sent: 18 July 2014 16:09
> To: Martin Kosek; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] PatternFly questions
> 
> On 07/18/2014 09:23 AM, Martin Kosek wrote:
>> On 07/18/2014 03:12 PM, Dmitri Pal wrote:
>>> On 07/18/2014 08:17 AM, Innes, Duncan wrote:
Hi Petr,

 On 18/07/2014 11:24, Petr Vobornik wrote:
> Hello Duncan,
>
> thank you for the input. If you or somebody else have any Web UI
 ideas/RFEs, feel free to write them down. I would like to
> know what people don't like or would like to have.
>
> On 18.7.2014 10:21, Innes, Duncan wrote:
>> Just poking around the new 4.0 demo page and very much liking what
> 
>> I
 see.  This will make a
>> big difference in use on large estates.
>>
>> A couple PatternFly related questions though:
>>
>> 1. The tables don't sort by column if I click on a column header.
 Is this not available in PatternFly yet,
>>or have FreeIPA decided against implementing it?
> First just a note about PatternFly. It's not really a widget 
> library,
 it is(or should be) more of a set of patterns and
> styles. But the referential implementation is built on Bootstrap 3,
> 
> so
 it is very easy to adopt. PatternFly doesn't have an
> official pattern for table sorting yet, but it has styles for
 DataTables (jQuery table plugin) which can do it.
> I don't remember any decision against it -> could be implemented if
 there is enough will and user demand.
> Sorting can be done on client side and on server side. Client side 
> is
 limited to issue #2 - only 20 items, so it is not really
> helpful.
>
> And server side (IPA API) doesn't support specifying a sort 
> attribute
 atm.
> You would like the server-side sorting, right?
>
 Hadn't considered there to be an option.  When I looked at the 
 PatternFly demos I hadn't thought about it, but the speed that 
 FreeIPA pulls data out for rendering, I suppose it would have to be.
 Even our modest estate (at a few hundred users and hosts) would slow
> 
 down far too much if the full dataset was sent.

 The other possibilities thrown up by PatternFly are also 
 interesting; add/remove columns, resize columns etc.  I know some of
> 
 these are still on the drawing board, but there are demo pages 
 available already.

>> 2. Browsing the screen on a large monitor still leaves the user 
>> page
 (at least) limited to around 22 rows.
>> This leaves the bottom third of my browser empty.  The table 
>> uses
 the full width of the browser, can it
>> not use the full height too?
> I have and idea/plan to make it configurable - to specify the 
> number
 of items and also to allow disabling of paging.
> The more rows the slower the UI is. Also paging has its own issues
 which are not straightforward to solve:
> -
 http://www.redhat.com/archives/freeipa-devel/2012-August/msg00295.ht
 ml True. What's the biggest time factor in loading large tables?

 When admining estates with tens of thousands of entries, however, 
 much emphasis needs to be placed on the table filters. No admin in 
 their right mind is going to be performing actions on all entries 

Re: [Freeipa-users] PatternFly questions

[Innes, Duncan]

Bump

Back to work now - do you want RFE's written up for this stuff, or do
you have it in hand?

D

-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Innes, Duncan
Sent: 31 July 2014 21:47
To: d...@redhat.com; Martin Kosek; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] PatternFly questions

Hi,

Sorry for delay - paternity leave took me away from work rather
abruptly.

Do you still want RFE's written up for these?

My brain might have been fried when I thought about this, but is there
any mileage in creating an elasticsearch (or similar) database of the
useful fields and using that for searching?  If LDAP searches are the
limiting factor that is.  Keeping the databases in sync might be an
issue, but the elasticsearch database would be read-only for users and
would allow a potentially richer method of searching.

Back at work on Monday, so should be able to write up some RFE's then if
they're still needed.

Cheers

D 

-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dmitri Pal
Sent: 18 July 2014 16:09
To: Martin Kosek; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] PatternFly questions

On 07/18/2014 09:23 AM, Martin Kosek wrote:
> On 07/18/2014 03:12 PM, Dmitri Pal wrote:
>> On 07/18/2014 08:17 AM, Innes, Duncan wrote:
>>>Hi Petr,
>>>
>>> On 18/07/2014 11:24, Petr Vobornik wrote:
 Hello Duncan,

 thank you for the input. If you or somebody else have any Web UI
>>> ideas/RFEs, feel free to write them down. I would like to
 know what people don't like or would like to have.

 On 18.7.2014 10:21, Innes, Duncan wrote:
> Just poking around the new 4.0 demo page and very much liking what

> I
>>> see.  This will make a
> big difference in use on large estates.
>
> A couple PatternFly related questions though:
>
> 1. The tables don't sort by column if I click on a column header.
>>> Is this not available in PatternFly yet,
>or have FreeIPA decided against implementing it?
 First just a note about PatternFly. It's not really a widget 
 library,
>>> it is(or should be) more of a set of patterns and
 styles. But the referential implementation is built on Bootstrap 3,

 so
>>> it is very easy to adopt. PatternFly doesn't have an
 official pattern for table sorting yet, but it has styles for
>>> DataTables (jQuery table plugin) which can do it.
 I don't remember any decision against it -> could be implemented if
>>> there is enough will and user demand.
 Sorting can be done on client side and on server side. Client side 
 is
>>> limited to issue #2 - only 20 items, so it is not really
 helpful.

 And server side (IPA API) doesn't support specifying a sort 
 attribute
>>> atm.
 You would like the server-side sorting, right?

>>> Hadn't considered there to be an option.  When I looked at the 
>>> PatternFly demos I hadn't thought about it, but the speed that 
>>> FreeIPA pulls data out for rendering, I suppose it would have to be.
>>> Even our modest estate (at a few hundred users and hosts) would slow

>>> down far too much if the full dataset was sent.
>>>
>>> The other possibilities thrown up by PatternFly are also 
>>> interesting; add/remove columns, resize columns etc.  I know some of

>>> these are still on the drawing board, but there are demo pages 
>>> available already.
>>>
> 2. Browsing the screen on a large monitor still leaves the user 
> page
>>> (at least) limited to around 22 rows.
> This leaves the bottom third of my browser empty.  The table 
> uses
>>> the full width of the browser, can it
> not use the full height too?
 I have and idea/plan to make it configurable - to specify the 
 number
>>> of items and also to allow disabling of paging.
 The more rows the slower the UI is. Also paging has its own issues
>>> which are not straightforward to solve:
 -
>>> http://www.redhat.com/archives/freeipa-devel/2012-August/msg00295.ht
>>> ml True. What's the biggest time factor in loading large tables?
>>>
>>> When admining estates with tens of thousands of entries, however, 
>>> much emphasis needs to be placed on the table filters. No admin in 
>>> their right mind is going to be performing actions on all entries 
>>> simultaneously.  Similar to Foreman's filters, could FreeIPA allow
>>> (example) in the hosts screen a filter of "hostgroup = groupX" to 
>>> show only hosts belonging to that group?  Or filtering users with 
>>> "manager = 'Duncan Innes'"?
>> Please open RFEs. This is really a valuable feedback.
> I think we are somewhat talking about this RFE:
>
> https://fedorahosted.org/freeipa/ticket/2388
>
> Maybe it is time to resurrect it from Ticket Deferred milestone given 
> it would bring big value for large user deployments.
>
> The API and the mighty LDAP search engine is alread