[Freeipa-users] Re: FreeIPA for the maximally paranoid and overworked?

[K. M. Peterson via FreeIPA-users]

Charles,

Helpful fo know. The snapshot methodology is what we’ve done as well,
though we haven’t yet put it fully into production; I’ll still hold my
breath if we need it, but it’s good to hear it has worked for you.

Thanks!

On Wed, Jan 9, 2019 at 13:28 Charles Hedrick  wrote:

> Rob mentioned issues with restoring data for one entry. We run on VMs, and
> periodically take snapshots.
> ...
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: FreeIPA for the maximally paranoid and overworked?

[K. M. Peterson via FreeIPA-users]

Rob,

Thanks for your response, it was very helpful!

A monitoring tool would be great, I should say that I am sleeping better
because I'm getting to the point where I can at least back-out things when
there's that kind of failure.

It sounds like the level of caution that I've applied to this is
appropriate.  I was reading a blog post
<https://fy.blackhats.net.au/blog/html/2018/12/21/identity_ideas.html>
yesterday from William Brown that to some extent confirms what you'd said -
and my experience.

It's really helpful to hear, and I appreciate the assist.  I hope I can get
to the point where I have something to contribute to this project.

One more thing: I think I've figured out the series (or, perhaps "a"
series) of events that got me into this situation.  It appears that
initially on client installation for some reason, I would receive errors
indicating that there was a problem with the OpenLDAP configuration and it
failed because it could not update the /etc/openldap/ldap.conf file.  My
base installation doesn't have such a file, and previous installations of
clients may or may not have hit the same issue but it was never a problem
for us.  I created /etc/openldap/ldap.conf with a single "#" line, re-spun
the server and installed the client and ipa-replica-install - and
everything is working as expected now.

Again, many thanks!

On Tue, Jan 8, 2019 at 5:25 PM Rob Crittenden  wrote:

> K. M. Peterson via FreeIPA-users wrote:
> > Hi all,
> >
> > This is a newbie question with respect to FreeIPA, and I haven't seen
> > this elsewhere, so I thought I'd ask.
> >
> > I've just cleaned up an issue with trying to implement a new replica on
> > our domain, and I've realized that there are a couple of areas I don't
> > understand that are causing more stress than I need at this point, for I
> > am maximally paranoid and overworked, and I need some advice on how not
> > to make that worse when implementing FreeIPA.
> >
> > I've been reading this list on and off for most of the last year, and
> > what's struck me is how complicated this project is, especially of
> > course areas where I personally have less expertise (e.g., LDAP,
> > Kerberos).  Implementing and managing this is just one of my jobs, and
> > our IdM becomes more critical as time goes on, so I need to understand a
> > few things.
> >
> > Question 1: As I just had, for the first time, to manually modify LDAP
> > to remove data, I'd like to understand how taking that approach can
> > backfire.  In other words, it's clear this isn't habitually a good idea,
> > because mistakes will replicate, for example.  But, where are the real
> > danger points:  for example, I've seen stories of having to recover a
> > server in an environment where the time was intentionally set back to
> > allow an operation on an expired cert.  As with a database update that
> > triggers other (unexpected) changes, are there LDAP operations that
> > can't practically be "un-done"?  I know that deleting records is
> > permanent (obvious), but are there gotchas like changing a particular
> > object fires some large number of events that there's no way to revert?
> > Or, in colloquial terms, are there places that are really, really bad to
> > try to outwit the management interfaces?  I'm not talking everyday
> > updates, but instances where we get stuck (as I was yesterday and today)?
> >
> > Question 2: How to stay safe.  Our installation on a small network as a
> > pair of masters replicating with each other, CA and DNS installed on
> > both.  They are VMs allocated on separate physical hosts.  Before
> > updates, I snapshot both for recovery purposes.  I update one at a time,
> > now, and ensure that they're functional before doing the other one (I
> > know that schema changes will propagate before service is applied
> > elsewhere, but I can't do anything else about that). I haven't had to
> > deal with the question of how to make sure my (self-signed) CA
> > certificate doesn't expire, but I know when it will and am leaving
> > myself ample time to understand that.  I'm about to start pushing out
> > this functionality to multiple geos, again at small-ish scale, and I'm
> > reading the topology references to be sure I understand what I'm doing.
> > But: what am I missing? I get the impression that trying to
> > (conventionally) "back up" data isn't useful.  I've tried to design the
> > network to make it as simple as possible to meet our needs.  Does anyone
> > else have anything to add in the sense of "best practices", or to echo
> > my first question "there be dragons "?
> >
> > I've learn

[Freeipa-users] Re: ipa-replica-manage --force replica.server fails

[K. M. Peterson via FreeIPA-users]

I located every entry in LDAP that referenced the failed server and removed
each of them.  I know that the entries in the etc ipa masters hierarchies
wouldn't go until I'd removed several of the others, which know included
the custodia entries.  I think there weren't any topology entries by that
point.

Sorry not to be more helpful...

On Tue, Jan 8, 2019 at 5:12 PM Rob Crittenden  wrote:

> K. M. Peterson via FreeIPA-users wrote:
> > I'm going to reply to myself, after several more hours of digging, I
> > discovered that although it wasn't true at the time I posted the above
> > question, eventually, as with the original post from Lachlan Musicman
> > <
> https://lists.fedorahosted.org/archives/users/46343247263810572257541459042951629750/
> >,
> > the WebUI died, and that meant no self-service for the rest of the
> > team.  And that made it into an emergency.
> >
> > So, I fired up my LDAP editor (I've been using JXWorkBench) and went to
> > eradicate all the traces of the failed replica.  Which fixed the issue;
> > and I'm fairly sure there aren't any lingering effects.  I think.
> >
> > But this was the first time I've used the editor to actual effect any
> > changes to things; and I'm going to post the underlying question that
> > raised in a new thread...
> >
> > This seems to have bitten at least a few of us; I'd be happy to know how
> > to file a bug if there's a useful contribution there.  Thanks!
>
> You didn't happen to keep a list of the entries/values you removed did you?
>
> rob
>
> >
> > On Sat, Jan 5, 2019 at 4:47 PM K. M. Peterson  > <mailto:kmp.li...@gmail.com>> wrote:
> >
> > Hate _hate_ to open old threads, but...
> >
> > I'm also seeing this.  I've been trying to add another replica to
> > our topology (this would be on a different subnet than the current
> > pair); the ipa-replica-install command has been failing for various
> > reasons that I've been fixing or circumventing and I've just been
> > re-spinning the new server between each attempt to keep the
> > environment clean.  The latest death was apparently because of an
> > issue with /etc/openldap/ldap.conf which I was debugging and was
> > about to remove the server from IPA and reset it.
> >
> > However, I'm not able to do so.  All attempts are met with "ERROR:
> > invalid 'PKINIT enabled server': all masters must have IPA master
> > role enabled" - in fact, even poking around trying to do an ipa
> > config-show  (on either of the current masters) just generates that
> > error.  I've also tried uninstalling the replica and client on the
> > new host, and it seems to have completed successfully, but I can't
> > re-enroll it either, so it's "dead to the other masters", except...
>
> >
> > There is nothing I want to do at this point other than another
> > iteration on my problem adding another replica.  There's no data on
> > replica, nothing is relying on it, and I've tried as hard as
> > possible to make the installation entirely vanilla.  I haven't
> > manually enabled PKINIT; ipa-pkinit-manage status on the current
> > masters says it's enabled.  As for the server roles,
> > server-role-find shows the two current servers and the new one; the
> > latter's "role status" for CA Server is "absent".  I've had issues
> > before where I've had to enumerate the RUVs and remove them (done
> > that).  Just want the references to this to go away, so that I can
> > keep working towards the most minimal and concise installation.
> >
> > Any ideas on where I can go to get out of this situation?  Many
> thanks!
> >
> > (Everything completely updated to *4.6.4-10.el7.centos, initial
> > installation was about one year ago, domain level 1; tried all the
> > ipa server del and ipa-replica-manage del suggestions which aren't
> > working for me this time, no AD integration...)
> >
> > On Tue, Nov 20, 2018 at 1:48 AM Brian Topping via FreeIPA-users
> >  > <mailto:freeipa-users@lists.fedorahosted.org>> wrote:
> >
> > Oh, forgot to mention, current domain level is `1`...
> > ___
> > FreeIPA-users mailing list --
> > freeipa-users@lists.fedorahosted.org
> > <mailto:freeipa-users@lists.fedorahosted.org>
> > To unsubscribe send an email to
> > freeipa-users-le...@lists.fedorahosted.org
> > <

[Freeipa-users] FreeIPA for the maximally paranoid and overworked?

[K. M. Peterson via FreeIPA-users]

Hi all,

This is a newbie question with respect to FreeIPA, and I haven't seen this
elsewhere, so I thought I'd ask.

I've just cleaned up an issue with trying to implement a new replica on our
domain, and I've realized that there are a couple of areas I don't
understand that are causing more stress than I need at this point, for I am
maximally paranoid and overworked, and I need some advice on how not to
make that worse when implementing FreeIPA.

I've been reading this list on and off for most of the last year, and
what's struck me is how complicated this project is, especially of course
areas where I personally have less expertise (e.g., LDAP, Kerberos).
Implementing and managing this is just one of my jobs, and our IdM becomes
more critical as time goes on, so I need to understand a few things.

Question 1: As I just had, for the first time, to manually modify LDAP to
remove data, I'd like to understand how taking that approach can backfire.
In other words, it's clear this isn't habitually a good idea, because
mistakes will replicate, for example.  But, where are the real danger
points:  for example, I've seen stories of having to recover a server in an
environment where the time was intentionally set back to allow an operation
on an expired cert.  As with a database update that triggers other
(unexpected) changes, are there LDAP operations that can't practically be
"un-done"?  I know that deleting records is permanent (obvious), but are
there gotchas like changing a particular object fires some large number of
events that there's no way to revert?  Or, in colloquial terms, are there
places that are really, really bad to try to outwit the management
interfaces?  I'm not talking everyday updates, but instances where we get
stuck (as I was yesterday and today)?

Question 2: How to stay safe.  Our installation on a small network as a
pair of masters replicating with each other, CA and DNS installed on both.
They are VMs allocated on separate physical hosts.  Before updates, I
snapshot both for recovery purposes.  I update one at a time, now, and
ensure that they're functional before doing the other one (I know that
schema changes will propagate before service is applied elsewhere, but I
can't do anything else about that). I haven't had to deal with the question
of how to make sure my (self-signed) CA certificate doesn't expire, but I
know when it will and am leaving myself ample time to understand that.  I'm
about to start pushing out this functionality to multiple geos, again at
small-ish scale, and I'm reading the topology references to be sure I
understand what I'm doing.  But: what am I missing? I get the impression
that trying to (conventionally) "back up" data isn't useful.  I've tried to
design the network to make it as simple as possible to meet our needs.
Does anyone else have anything to add in the sense of "best practices", or
to echo my first question "there be dragons "?

I've learned a lot from this list, and I'd also like to add a thank you to
everyone here who have helped with that!  I do see this getting better and
better, and it's appreciated.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa-replica-manage --force replica.server fails

[K. M. Peterson via FreeIPA-users]

I'm going to reply to myself, after several more hours of digging, I
discovered that although it wasn't true at the time I posted the above
question, eventually, as with the original post from Lachlan Musicman
,
the WebUI died, and that meant no self-service for the rest of the team.
And that made it into an emergency.

So, I fired up my LDAP editor (I've been using JXWorkBench) and went to
eradicate all the traces of the failed replica.  Which fixed the issue; and
I'm fairly sure there aren't any lingering effects.  I think.

But this was the first time I've used the editor to actual effect any
changes to things; and I'm going to post the underlying question that
raised in a new thread...

This seems to have bitten at least a few of us; I'd be happy to know how to
file a bug if there's a useful contribution there.  Thanks!

On Sat, Jan 5, 2019 at 4:47 PM K. M. Peterson  wrote:

> Hate _hate_ to open old threads, but...
>
> I'm also seeing this.  I've been trying to add another replica to our
> topology (this would be on a different subnet than the current pair); the
> ipa-replica-install command has been failing for various reasons that
> I've been fixing or circumventing and I've just been re-spinning the new
> server between each attempt to keep the environment clean.  The latest
> death was apparently because of an issue with /etc/openldap/ldap.conf
> which I was debugging and was about to remove the server from IPA and reset
> it.
>
> However, I'm not able to do so.  All attempts are met with "ERROR:
> invalid 'PKINIT enabled server': all masters must have IPA master role
> enabled" - in fact, even poking around trying to do an ipa config-show
> (on either of the current masters) just generates that error.  I've also
> tried uninstalling the replica and client on the new host, and it seems to
> have completed successfully, but I can't re-enroll it either, so it's "dead
> to the other masters", except...
>
> There is nothing I want to do at this point other than another iteration
> on my problem adding another replica.  There's no data on replica, nothing
> is relying on it, and I've tried as hard as possible to make the
> installation entirely vanilla.  I haven't manually enabled PKINIT;
> ipa-pkinit-manage status on the current masters says it's enabled.  As
> for the server roles, server-role-find shows the two current servers and
> the new one; the latter's "role status" for CA Server is "absent".  I've
> had issues before where I've had to enumerate the RUVs and remove them
> (done that).  Just want the references to this to go away, so that I can
> keep working towards the most minimal and concise installation.
>
> Any ideas on where I can go to get out of this situation?  Many thanks!
>
> (Everything completely updated to *4.6.4-10.el7.centos, initial
> installation was about one year ago, domain level 1; tried all the ipa
> server del and ipa-replica-manage del suggestions which aren't working for
> me this time, no AD integration...)
>
> On Tue, Nov 20, 2018 at 1:48 AM Brian Topping via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
>
>> Oh, forgot to mention, current domain level is `1`...
>> ___
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> To unsubscribe send an email to
>> freeipa-users-le...@lists.fedorahosted.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
>>
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa-replica-manage --force replica.server fails

[K. M. Peterson via FreeIPA-users]

Hate _hate_ to open old threads, but...

I'm also seeing this.  I've been trying to add another replica to our
topology (this would be on a different subnet than the current pair); the
ipa-replica-install command has been failing for various reasons that I've
been fixing or circumventing and I've just been re-spinning the new server
between each attempt to keep the environment clean.  The latest death was
apparently because of an issue with /etc/openldap/ldap.conf which I was
debugging and was about to remove the server from IPA and reset it.

However, I'm not able to do so.  All attempts are met with "ERROR: invalid
'PKINIT enabled server': all masters must have IPA master role enabled" -
in fact, even poking around trying to do an ipa config-show  (on either of
the current masters) just generates that error.  I've also tried
uninstalling the replica and client on the new host, and it seems to have
completed successfully, but I can't re-enroll it either, so it's "dead to
the other masters", except...

There is nothing I want to do at this point other than another iteration on
my problem adding another replica.  There's no data on replica, nothing is
relying on it, and I've tried as hard as possible to make the installation
entirely vanilla.  I haven't manually enabled PKINIT; ipa-pkinit-manage
status on the current masters says it's enabled.  As for the server roles,
server-role-find shows the two current servers and the new one; the
latter's "role status" for CA Server is "absent".  I've had issues before
where I've had to enumerate the RUVs and remove them (done that).  Just
want the references to this to go away, so that I can keep working towards
the most minimal and concise installation.

Any ideas on where I can go to get out of this situation?  Many thanks!

(Everything completely updated to *4.6.4-10.el7.centos, initial
installation was about one year ago, domain level 1; tried all the ipa
server del and ipa-replica-manage del suggestions which aren't working for
me this time, no AD integration...)

On Tue, Nov 20, 2018 at 1:48 AM Brian Topping via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Oh, forgot to mention, current domain level is `1`...
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org