[Freeipa-users] Re: [SSSD-users] Re: Getting DP Request [Account #4]: Returning [Internal Error]: 3,5,Group lookup failed

2018-02-01 Thread TomK via FreeIPA-users 

On 2/1/2018 3:30 AM, Jakub Hrozek via FreeIPA-users wrote:

On Wed, Jan 31, 2018 at 04:07:46PM -0500, TomK via FreeIPA-users wrote:

On 1/31/2018 2:34 PM, Jakub Hrozek via FreeIPA-users wrote:

On Wed, Jan 31, 2018 at 01:18:27PM -0500, TomK via FreeIPA-users wrote:

On 1/31/2018 12:21 PM, TomK wrote:

On 1/31/2018 9:41 AM, Jakub Hrozek wrote:

See inline..

On Wed, Jan 31, 2018 at 03:23:57AM -0500, TomK wrote:

On 1/31/2018 3:18 AM, TomK via FreeIPA-users wrote:
My bad, did not include sssd-users earlier.  :(


Hey All,

I'm wondering if anyone came across this error below.  We have two RHEL
7.4 servers with SSSD 1.15.2: http-srv01 and http-srv02

Both connect to the same AD DC host below: addc-srv03.addom.com.
Verified krb5.conf and sssd.conf both are identical.  We can login on
the http-srv01 and can list all groups for an AD account.

On http-srv02 we cannot login and any group listing from the CLI result
only in the user's local groups.  No AD groups.

Logs give us the output below.  Short of adding in the entire log which
I might not be able to do till the end of the week, what could we look
at to resolve this?

There's very little available online on this error.  The RH solution
doesn't make sense since the first host connects and
authenticates users
just fine so it's definitely GC enabled.




--
Cheers,
Tom K.
-


Living on earth is expensive, but it includes a free trip around
the sun.



samba-libs-4.6.2-12.el7_4.x86_64
samba-client-libs-4.6.2-12.el7_4.x86_64
sssd-1.15.2-50.el7_4.6.x86_64
openldap-2.4.44-5.el7.x86_64
sssd-ldap-1.15.2-50.el7_4.6.x86_64
sssd-common-pac-1.15.2-50.el7_4.6.x86_64
samba-winbind-clients-4.6.2-12.el7_4.x86_64
samba-common-4.6.2-12.el7_4.noarch
sssd-client-1.15.2-50.el7_4.6.x86_64
sssd-proxy-1.15.2-50.el7_4.6.x86_64
samba-winbind-modules-4.6.2-12.el7_4.x86_64
python-sssdconfig-1.15.2-50.el7_4.6.noarch
sssd-ipa-1.15.2-50.el7_4.6.x86_64
samba-common-libs-4.6.2-12.el7_4.x86_64
sssd-krb5-common-1.15.2-50.el7_4.6.x86_64
samba-winbind-4.6.2-12.el7_4.x86_64
sssd-krb5-1.15.2-50.el7_4.6.x86_64
sssd-ad-1.15.2-50.el7_4.6.x86_64
sssd-common-1.15.2-50.el7_4.6.x86_64
samba-common-tools-4.6.2-12.el7_4.x86_64


(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch]
(0x4000): dbus
conn: 0x55b2e22e8700
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000):
Dispatching.
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_message_handler]
(0x2000): Received SBUS method
org.freedesktop.sssd.dataprovider.getAccountInfo on path
/org/freedesktop/sssd/dataprovider
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_get_sender_id_send]
(0x2000): Not a sysbus message, quit
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]]
[dp_get_account_info_handler]
(0x0200): Got request for
[0x2][BE_REQ_GROUP][name=unix-admin-group@addom]
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req]
(0x0400): DP
Request [Account #4]: New request. Flags [0x0001].
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400):
Number of active DP request: 1
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state]
(0x1000): Domain ADDOM is Active
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state]
(0x1000): Domain ADDOM is Active
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_step]
(0x4000): beginning to connect
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send]
(0x0100): Trying to resolve service 'AD_GC'
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_server_status]
(0x1000):
Status of server 'addc-srv03.addom.com' is 'working'
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x1000):
Port status of port 0 for server 'addc-srv03.addom.com' is 'not working'


What debug level are you running with? Is this the first occurence of
'port not working' since sssd started?

It's debug_level = 9.  There was 1002 occurrances since I restarted sssd
last night.  If it's F/W, I'm not clear on the port this is referring
too.

Also confirmed that port 3268 from both clients to the AD DC is blocked in
F/W. However then that raises the question why authentication works on
http-srv01 even though traffic to port 3268 is also getting denied from that
host.


The 'port' here refers to an internal sssd structure that usually maps
to a network port, but not always.

Is there some more context around the very first 'not working' since the
sssd restart? Because here is not much, there's just connecting and then
not working which leaves me puzzled.

The very first state switch should have a message from
"_be_fo_set_port_status" which also includes who was the caller etc.
That should give some more context.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


Below is the snippet.

(Wed Jan 31 13:28:09 2018)

[Freeipa-users] Nextcloud with Freeipa and AD

2018-02-01 Thread Николай Савельев via FreeIPA-users 
I have Freeipa with AD trust. All works fine.
I want Nextcloud with all users - AD and IPA.
I set up Nextcloud for this article:
https://www.freeipa.org/page/Owncloud_Authentication_against_FreeIPA
But I want restrict users for only one group.
When I open User Filter tab I get message: 

The group box was disabled, because the LDAP / AD server does not support 
memberOf.

I waches ldap tree:
cn=users,cn=account,dc=domain,dc=lan - there are users have memberof attribute, 
there are тщ AD users

cn=users,cn=compat,dc=domain,dc=lan - there are AD users, but there ar users 
don't have memberof attribute.

What's wrong?


---
С уважением, Николай.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: How to recover from "split brain"

2018-02-01 Thread Rob Brown via FreeIPA-users 
BTW:
[root@ipa-prod-1201]# cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)
[root@ipa-prod-1201]# rpm -qa|grep ipa-server-4
ipa-server-4.4.0-14.el7.centos.6.x86_64


On Thu, Feb 1, 2018 at 10:53 AM, Rob Brown  wrote:

> Agreed! I would love to know if that is possible... seems like it should
> be.
> As mentioned previously, preprod still has the agreements, but prod does
> not.
> Not really sure how I should proceed. I'm a bit stuck, not wanting to
> further break anything. For now, auth is still working in both envs.
> ---
> [root@ipa-preprod-1201]# ipa topologysegment-find domain
> --
> 5 segments matched
> --
>   Segment name: ipa-preprod-1201-to-ipa-preprod-1202
>   Left node: ipa-preprod-1201
>   Right node: ipa-preprod-1202
>   Connectivity: both
>
>   Segment name: ipa-preprod-1201-to-ipa-prod-1201
>   Left node: ipa-preprod-1201
>   Right node: ipa-prod-1201
>   Connectivity: both
>
>   Segment name: ipa-preprod-1202-to-ipa-prod-1201
>   Left node: ipa-preprod-1202
>   Right node: ipa-prod-1201
>   Connectivity: both
>
>   Segment name: ipa-prod-1201-to-ipa-prod-1202
>   Left node: ipa-prod-1201
>   Right node: ipa-prod-1202
>   Connectivity: both
>
>   Segment name: ipa-prod-1202-to-ipa-preprod-1201
>   Left node: ipa-prod-1202
>   Right node: ipa-preprod-1201
>   Connectivity: both
>
> [root@ipa-prod-1201]# ipa topologysegment-find domain
> --
> 2 segments matched
> --
>   Segment name: ipa-preprod-1201-to-ipa-preprod-1202
>   Left node: ipa-preprod-1201
>   Right node: ipa-preprod-1202
>   Connectivity: both
>
>   Segment name: ipa-prod-1201-to-ipa-prod-1202
>   Left node: ipa-prod-1201
>   Right node: ipa-prod-1202
>   Connectivity: both
> 
> Number of entries returned 2
> 
>
> I think part of the problem is that when I did the ipa-replica-manage del,
> it removed the preprod servers:
>
> [root@ipa-prod-1201]# ipa server-find
> -
> 2 IPA servers matched
> -
>   Server name: ipa-prod-1201
>   Min domain level: 0
>   Max domain level: 1
>
>   Server name: ipa-prod-1202
>   Min domain level: 0
>   Max domain level: 1
> 
> Number of entries returned 2
> 
>
> but they still exist on the preprod side:
>
> [root@ipa-preprod-1201]# ipa server-find
> -
> 4 IPA servers matched
> -
>   Server name: ipa-preprod-1201
>   Min domain level: 0
>   Max domain level: 1
>
>   Server name: ipa-preprod-1202
>   Min domain level: 0
>   Max domain level: 1
>
>   Server name: ipa-prod-1201
>   Min domain level: 0
>   Max domain level: 1
>
>   Server name: ipa-prod-1202
>   Min domain level: 0
>   Max domain level: 1
> 
> Number of entries returned 4
> 
>
>
>
>
> On Wed, Jan 31, 2018 at 10:52 PM, Andrew Radygin 
> wrote:
>
>> Though you can completely rebuild preprod servers, still it would be
>> interesting how to reconnect prod servers with replicas again.
>>
>> 2018-02-01 8:41 GMT+03:00 Rob Brown via FreeIPA-users <
>> freeipa-users@lists.fedorahosted.org>:
>>
>>> ok, did a little googling, and seems like KRA refers to the "vault"
>>> feature?
>>> I didn't originally install this myself, so wasn't sure if it is used
>>> for anything critical.
>>> I ran:
>>> # ipa vault-find
>>> 
>>> 0 vaults matched
>>> 
>>> 
>>> Number of entries returned 0
>>> 
>>>
>>> So, can I assume it is safe to blow away and rebuild the server that has
>>> this role?
>>>
>>> On Wed, Jan 31, 2018 at 3:56 PM, Rob Brown 
>>> wrote:
>>>
 I have 4 IPA servers, all masters, that were previously configured in a
 "full mesh" replication.
 2 in "prod", 2 in "preprod".
 While trying to fix a replication issue, I accidentally did a:
 ipa-replica-manage del
 on one of the prod servers for BOTH preprod servers.

 Now, the prod servers don't "see" either of the preprod servers, so I
 effectively created a "split-brain" between the 2 environments. Preprod
 still "knows about" the prod ipa servers, but I can't figure out how to
 re-establish the replication agreements.

 I was about to just blow away the preprod servers and rebuild them
 (which i did before on one of them) but noticed one of them has the "KRA"
 role, and it is the only one in the domain that has it.
 I don't know what that does, or what the effects would be if it went
 away. I'm guessing bad.

 I have tried "ipa topologysegment-reinitialize domain" on the segments
 that preprod still has, but those segments did not show up in prod.
 ipa topologysuffix-verify domain says "in order" everywhere.

 At this point I am completely

[Freeipa-users] Re: Documented monitoring best practices

2018-02-01 Thread Rob Crittenden via FreeIPA-users 
Alex Corcoles via FreeIPA-users wrote:
> On Thu, Feb 1, 2018 at 5:25 PM, Jochen Hein  > wrote:
> 
> I'm using https://github.com/peterpakos/checkipaconsistency
>  to monitor
> my replicas.
> 
> 
> Yeah, but I'm not exactly reassured by choosing on of the many plugins
> out there- or running them all. It would be great to push for an
> official check.

There are not that many plugins doing this that I know of.

I'm pretty sure there is a nagios script that looks at the agreement in
LDAP, or the output of ipa-replica-manage list -v `hostname` to look for
replication issues.

For a more full-blown view there is http://cnmonitor.sourceforge.net/

389-ds instructions for this are at
http://directory.fedoraproject.org/docs/389ds/howto/howto-cn-equals-monitor-ldap-monitoring.html

The team has talked about a monitoring script but for now Peter's script
is filling the void.

> 
> I'm might be willing to help, but I'd need documentation about what (and
> how) to check, but that's basically 90% of the work. I would propose
> assimilating the best-looking plugin out there and expanding it every
> time sometime reports some broken thing that needs proactive fixing.
> 
> Any way we can help this happen?
> 
> Right now we had some problems with certificates not/halfway renewing,
> so some tool to check LDAP against the different cert-stores might be
> helpful.
> 
> 
> $ ipa cert-find --validnotafter-to=$(date --date="3 years" +"%Y-%m-%d")
> 
> Actually changing "3 years" to something inferior to the margin FreeIPA
> starts renewing certificates should warn you that something is amiss.

Server certs in IPA are good for 2 years.

We have in mind a tool to troubleshoot cert issues but haven't yet
started work on it.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Documented monitoring best practices

2018-02-01 Thread Alex Corcoles via FreeIPA-users 
On Thu, Feb 1, 2018 at 5:25 PM, Jochen Hein  wrote:

> I'm using https://github.com/peterpakos/checkipaconsistency to monitor
> my replicas.
>

Yeah, but I'm not exactly reassured by choosing on of the many plugins out
there- or running them all. It would be great to push for an official check.

I'm might be willing to help, but I'd need documentation about what (and
how) to check, but that's basically 90% of the work. I would propose
assimilating the best-looking plugin out there and expanding it every time
sometime reports some broken thing that needs proactive fixing.

Any way we can help this happen?

Right now we had some problems with certificates not/halfway renewing,
> so some tool to check LDAP against the different cert-stores might be
> helpful.
>

$ ipa cert-find --validnotafter-to=$(date --date="3 years" +"%Y-%m-%d")

Actually changing "3 years" to something inferior to the margin FreeIPA
starts renewing certificates should warn you that something is amiss.
-- 
   ___
 {~._.~}
  ( Y )
 ()~*~()  mail: alex at corcoles dot net
 (_)-(_)  http://alex.corcoles.net/
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: How to recover from "split brain"

2018-02-01 Thread Rob Brown via FreeIPA-users 
Agreed! I would love to know if that is possible... seems like it should be.
As mentioned previously, preprod still has the agreements, but prod does
not.
Not really sure how I should proceed. I'm a bit stuck, not wanting to
further break anything. For now, auth is still working in both envs.
---
[root@ipa-preprod-1201]# ipa topologysegment-find domain
--
5 segments matched
--
  Segment name: ipa-preprod-1201-to-ipa-preprod-1202
  Left node: ipa-preprod-1201
  Right node: ipa-preprod-1202
  Connectivity: both

  Segment name: ipa-preprod-1201-to-ipa-prod-1201
  Left node: ipa-preprod-1201
  Right node: ipa-prod-1201
  Connectivity: both

  Segment name: ipa-preprod-1202-to-ipa-prod-1201
  Left node: ipa-preprod-1202
  Right node: ipa-prod-1201
  Connectivity: both

  Segment name: ipa-prod-1201-to-ipa-prod-1202
  Left node: ipa-prod-1201
  Right node: ipa-prod-1202
  Connectivity: both

  Segment name: ipa-prod-1202-to-ipa-preprod-1201
  Left node: ipa-prod-1202
  Right node: ipa-preprod-1201
  Connectivity: both

[root@ipa-prod-1201]# ipa topologysegment-find domain
--
2 segments matched
--
  Segment name: ipa-preprod-1201-to-ipa-preprod-1202
  Left node: ipa-preprod-1201
  Right node: ipa-preprod-1202
  Connectivity: both

  Segment name: ipa-prod-1201-to-ipa-prod-1202
  Left node: ipa-prod-1201
  Right node: ipa-prod-1202
  Connectivity: both

Number of entries returned 2


I think part of the problem is that when I did the ipa-replica-manage del,
it removed the preprod servers:

[root@ipa-prod-1201]# ipa server-find
-
2 IPA servers matched
-
  Server name: ipa-prod-1201
  Min domain level: 0
  Max domain level: 1

  Server name: ipa-prod-1202
  Min domain level: 0
  Max domain level: 1

Number of entries returned 2


but they still exist on the preprod side:

[root@ipa-preprod-1201]# ipa server-find
-
4 IPA servers matched
-
  Server name: ipa-preprod-1201
  Min domain level: 0
  Max domain level: 1

  Server name: ipa-preprod-1202
  Min domain level: 0
  Max domain level: 1

  Server name: ipa-prod-1201
  Min domain level: 0
  Max domain level: 1

  Server name: ipa-prod-1202
  Min domain level: 0
  Max domain level: 1

Number of entries returned 4





On Wed, Jan 31, 2018 at 10:52 PM, Andrew Radygin  wrote:

> Though you can completely rebuild preprod servers, still it would be
> interesting how to reconnect prod servers with replicas again.
>
> 2018-02-01 8:41 GMT+03:00 Rob Brown via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org>:
>
>> ok, did a little googling, and seems like KRA refers to the "vault"
>> feature?
>> I didn't originally install this myself, so wasn't sure if it is used for
>> anything critical.
>> I ran:
>> # ipa vault-find
>> 
>> 0 vaults matched
>> 
>> 
>> Number of entries returned 0
>> 
>>
>> So, can I assume it is safe to blow away and rebuild the server that has
>> this role?
>>
>> On Wed, Jan 31, 2018 at 3:56 PM, Rob Brown 
>> wrote:
>>
>>> I have 4 IPA servers, all masters, that were previously configured in a
>>> "full mesh" replication.
>>> 2 in "prod", 2 in "preprod".
>>> While trying to fix a replication issue, I accidentally did a:
>>> ipa-replica-manage del
>>> on one of the prod servers for BOTH preprod servers.
>>>
>>> Now, the prod servers don't "see" either of the preprod servers, so I
>>> effectively created a "split-brain" between the 2 environments. Preprod
>>> still "knows about" the prod ipa servers, but I can't figure out how to
>>> re-establish the replication agreements.
>>>
>>> I was about to just blow away the preprod servers and rebuild them
>>> (which i did before on one of them) but noticed one of them has the "KRA"
>>> role, and it is the only one in the domain that has it.
>>> I don't know what that does, or what the effects would be if it went
>>> away. I'm guessing bad.
>>>
>>> I have tried "ipa topologysegment-reinitialize domain" on the segments
>>> that preprod still has, but those segments did not show up in prod.
>>> ipa topologysuffix-verify domain says "in order" everywhere.
>>>
>>> At this point I am completely lost on how to proceed.
>>>
>>> What details can I provide for any help anyone is willing to provide?
>>>
>>>
>>>
>>>
>>>
>>
>> ___
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-users-le...@lists.fedo
>> rahosted.org
>>
>>
>
>
> --
> Best regards, Andrew.
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To

[Freeipa-users] Re: Certificates renewing with the wrong Subject

2018-02-01 Thread Roderick Johnstone via FreeIPA-users 

On 31/01/2018 20:36, Rob Crittenden via FreeIPA-users wrote:

Roderick Johnstone via FreeIPA-users wrote:

On 25/01/2018 16:56, Roderick Johnstone via FreeIPA-users wrote:

On 25/01/2018 13:43, Rob Crittenden via FreeIPA-users wrote:

Roderick Johnstone via FreeIPA-users wrote:

On 24/01/2018 21:09, Rob Crittenden via FreeIPA-users wrote:

Roderick Johnstone via FreeIPA-users wrote:

On 24/01/2018 15:22, Rob Crittenden via FreeIPA-users wrote:

Roderick Johnstone via FreeIPA-users wrote:

On 23/01/2018 14:34, Rob Crittenden via FreeIPA-users wrote:

Roderick Johnstone via FreeIPA-users wrote:

On 15/01/2018 20:07, Rob Crittenden via FreeIPA-users wrote:

Roderick Johnstone via FreeIPA-users wrote:

On 15/01/2018 16:06, Rob Crittenden via FreeIPA-users wrote:

Roderick Johnstone via FreeIPA-users wrote:

Hi

Our freeipa certificates need to be renewed due to passing
their
expiry
dates.

While some certificates have renewed ok, the ipaCert and
auditSigningCert are renewing but the new certificates
have the
wrong
Subject.

Environment is:
serverA (CRL, first, master) RHEL 7.3, ipa 4.4
serverB (replica) RHEL 7.3, ipa 4.4
serverC (replica) RHEL 7.4, ipa 4.5

Once there are renewed certificates with the wrong Subject
present,
there are various problems with renewing the remaining
certificates,
which I think might be related to the bad Subject:

1) When just ipaCert has the wrong subject no further
renewals
happen

2) When auditSigningCert has the wrong subject the ipa
pki-tomcatd
service will not start and no further renewals happen.

I've been round the following loop many times on ServerA, our
first
master:

1) Restore good certificates from backup
2) Put the clock back to a time when certificates are all
valid
3) Resubmit certificates for renewal

Each time the ipaCert renews it has the same wrong
Subject. The
wrong
Subject includes the host name of one of our ipa client
systems.

Each time the auditSigningCert renews it has the same wrong
Subject
but
a different subject to the ipaCert. The wrong Subject in this
case
includes the host name of a system which has never been an
ipa
client,
but might have been added and removed with ipa host-add
and ipa
host-del
for testing something, a while ago.

As far as I can see, the "cert_subject" is set correctly
in the
file
/var/lib/certmonger/ until the point at which the
certificate is actually renewed.

I'd be very grateful for some pointers as to which
configuration
options
and logs to check through to resolve this problem on our
production
system.

If its of any relevance we did change which server is the
first
master
some time ago.


I'd pull the CSR out of dogtag (CS.cfg) and/or certmonger
to see
what
the subject is.


I'm not seeing any obvious CSR fields in the
/etc/pki/pki-tomcat/ca/CS.cfg file.


foo.bar.certreq=


The CSR in the certmonger requests file for the
auditSigningCert
seems
to be showing with the correct Subject. This is different from
the bad
subject showing in the requests file field:
cert_subject=


The value of cert_subject comes from the issued certificate.


and the Subject which is showing in the 'getcert list' output
(which is
the same as that in the cert_subject= field.>
I'm not quite sure what this all means.


It is displayed from the data within the tracked certmonger
request.

certmonger logs to syslog so you can check there or you can stop
the
process and run it manually with: certmonger -n -d 9 2>&1 | tee
certmonger.log

That will provide a lot of debugging output that may show
what is
going on.


I've restored certificate databases from backup and put the clock
back
to a time when certificates are valid and renewed the
ocspSigining
certificate with:
getcert resubmit -N "CN=OCSP Subsystem,O=" -i
20161124081302

(I've previously tried without the -N with similar results)

What I am seeing in the certmonger logs is:


2017-10-23 00:05:28 [438] Located the key 'ocspSigningCert
cert-pki-ca'.
2017-10-23 00:05:28 [438] Converted private key 'ocspSigningCert
cert-pki-ca' to public key.
2017-10-23 00:05:28 [439] Located the certificate
"ocspSigningCert
cert-pki-ca".
2017-10-23 00:05:28 [440] 0x1d Certificate named "ocspSigningCert
cert-pki-ca" in token "NSS Certificate DB" in database
"/etc/pki/pki-tomcat/alias" will not be valid after
20171025122401.
2017-10-23 00:05:28 [442] Located the key 'ocspSigningCert
cert-pki-ca'.
2017-10-23 00:05:28 [442] Converted private key 'ocspSigningCert
cert-pki-ca' to public key.
2017-10-23 00:05:28 [443] Located the certificate
"ocspSigningCert
cert-pki-ca".
2017-10-23 00:05:28 [444] Located the key 'ocspSigningCert
cert-pki-ca'.
2017-10-23 00:05:28 [444] Converted private key 'ocspSigningCert
cert-pki-ca' to public key.
2017-10-23 00:05:39 [581] Found a certificate with the same
nickname but
different subject, removing certificate "ocspSigningCert
cert-pki-ca"
with subject "CN=OCSP Subsystem,O=".
2017-10-23 00:05:39 [581] Imported certificate "ocspSigningCert
cert-pki-ca", got nickname "ocspSigningCert

[Freeipa-users] Re: IPA-Server Deletion issues

2018-02-01 Thread Jamal Mahmoud via FreeIPA-users 
Sorry about the lack of clarification Rob!

I have 3 servers, all running CentOS 7.4, FreeIPA version 4.5.0. the
hostnames are lithium, nitrogen and the recently deceased oxygen. all are
masters under the same Realm which is EGGVFX.IE

The "server not found" error is exactly what shows when i try to delete the
server from command line or the Web UI.

When i run ipa-replica-manage list -v `hostname` this is the output from
the servers:

Lithium Output:
root@lithium# ipa-replica-manage list -v `hostname`
nitrogen.eggvfx.ie: replica
  last init status: 0 Total update succeeded
  last init ended: 2018-02-01 10:51:14+00:00
  last update status: Error (0) Replica acquired successfully: Incremental
update succeeded
  last update ended: 2018-02-01 16:24:37+00:00

Nitrogen Output:
root@nitrogen# ipa-replica-manage list -v `hostname`
lithium.eggvfx.ie: replica
  last init status: None
  last init ended: 1970-01-01 00:00:00+00:00
  last update status: Error (0) Replica acquired successfully: Incremental
update succeeded
  last update ended: 2018-02-01 10:48:18+00:00
oxygen.eggvfx.ie: replica
  last init status: None
  last init ended: 1970-01-01 00:00:00+00:00
  last update status: Error (-1) Problem connecting to replica - LDAP
error: Can't contact LDAP server (connection error)
  last update ended: 1970-01-01 00:00:00+00:00

There is no entries for oxygen in host-find. I hope this helps clear the
story a bit for you.



*Jamal Mahmoud* / Pipeline TD
jamal.mahm...@egg.ie

35 Fitzwilliam Street Upper, Dublin.
P: +353 1 6345440

[image: Twitter]   [image: Facebook]
 [image: LinkedIn]
 [image: Vimeo]



On 1 February 2018 at 15:30, Rob Crittenden  wrote:

> Jamal Mahmoud via FreeIPA-users wrote:
> > I'm having strange issues with removing one of my freeIPA masters, I
> > managed to mess up the deletion process and my system seems to be stuck
> > in a state of limbo, my current setup is 3 servers ( 1 has been
> > decommissioned) that all share the CA/Domain responsibilities. When i
> > run the command .>
> > *ipa-replica-manage list*
> > *
> > *it produces 3 servers as active masters, when this is not true as i
> > have uninstalled ipa-server on one. Trying to delete it through that
> > command has given me no luck, even using *--force* and *--cleanup* does
> > not work. the same error output appears:
> >
> > *oxygen.eggvfx.ie : server not found*
>
> I think we need more information. What version of IPA is this, what
> distribution?
>
> Is the above error the exact error you are getting?
>
> As I understand it you ran ipa-server-install --uninstall and THEN tried
> to delete the master?
>
> What does ipa-replica-manage list -v `hostname` show on one of the other
> masters?
>
> > *
> > *
> > I'm not very good with ldap tools but after running
> >
> > *ldapsearch -x *
> > *
> > *there is a reference to the oxygen server still sitting in there, it
> > seems that the dirty entry is still hanging around my system, i'm
> > wondering if there is any way to resolve this?
> >
> > ldapsearch output:
> > *defaultServerList: oxygen.eggvfx.ie 
> > nitrogen.eggvfx.ie  lithium.eggvfx.ie
> > *
>
> An anonymous LDAP search won't show much.
>
> Does it show up in host-find?
>
> rob
>
> > *
> > Looking at the topology graph in the web ui i can see that there are
> > still ties between one of my servers and oxygen. It will also not allow
> > me to delete the server ties ( error: *Server is unwilling to perform:
> > Removal of Segment disconnects topology.Deletion not allowed.)* nor will
> > the ui allow me to delete the IPA server (*oxygen.eggvfx.ie
> > : server not found*)
> >
> > Any help is greatly appreciated,
> >
> > Many Thanks,
> > Jamal Mahmoud
> >
> >
> >
> > ___
> > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-users-leave@lists.
> fedorahosted.org
> >
>
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Documented monitoring best practices

2018-02-01 Thread Jochen Hein via FreeIPA-users 
Alex Corcoles via FreeIPA-users 
writes:

> Is there any official literature about how to monitor FreeIPA?

I'm using https://github.com/peterpakos/checkipaconsistency to monitor
my replicas.

> Is there any plan to provide an official way to monitor FreeIPA? My
> foremost concern would be to ensure that all clients are correctly enrolled
> and sudo/ssh work, so I am not locked out of my systems. Ensuring that
> replication works seems good and popular. Of course I can check that all
> services are running and ports respond.
>
> What are the most common ways for FreeIPA to break?

Right now we had some problems with certificates not/halfway renewing,
so some tool to check LDAP against the different cert-stores might be
helpful.

Jochen

-- 
This space is intentionally left blank.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Issue with SCEP enrollment to sub-CA

2018-02-01 Thread Rob Crittenden via FreeIPA-users 
Trevor Vaughan via FreeIPA-users wrote:
> As an update, the sscep application set works properly with the sub-CA
> so it's definitely an issue on the certmonger side of things.
> 
> sscep in AES mode throws an exception in Dogtag and, unfortunately,
> sscep also doesn't support above SHA1.
> 
> That said, it's at least reasonable isolation of the issue at hand.
> 
> It looks like the sscep code may be able to be lifted directly into the
> certmonger stack if the licenses are compatible without too much issue.

I think your best bet is to open an issue at
https://pagure.io/certmonger with as much detail as possible to
reproduce this.

rob

> 
> Thanks,
> 
> Trevor
> 
> On Wed, Jan 31, 2018 at 2:27 PM, Trevor Vaughan  > wrote:
> 
> Hi Rob,
> 
> Thanks for getting back to me, I have no idea how I missed this message.
> 
> I dug through the CA and KRA debug logs and don't see any PKCS7
> output anywhere.
> 
> I've been running certmonger in debug mode connected to the
> foreground and haven't really gotten anywhere there either.
> 
> I did determine that the spot where things are failing is at
> https://pagure.io/certmonger/blob/master/f/src/pkcs7.c#_1065
>  but I
> haven't been able to figure out how to print what is being received
> from the server.
> 
> Running the 'scep-submit' command by hand with -C works as expected
> (of course Dogtag doesn't respond with server capabilities so it
> downgrades itself into instanity but that doesn't seem to be the
> issue). I also checked to see that the certmonger configuration is
> correct in the ~/.config/certmonger space and the entire certificate
> chain appears to be present as expected.
> 
> Thanks,
> 
> Trevor
> 
> On Tue, Jan 30, 2018 at 10:38 AM, Rob Crittenden
> > wrote:
> 
> Trevor Vaughan via FreeIPA-users wrote:
> > Hi All,
> >
> > I have a setup where I have a root CA and a sub CA and the sub
> CA is set
> > up with a KRA and SCEP enabled.
> >
> > I've fired up certmonger and added the SCEP CA.
> >
> > When I attempt to request a certificate, the enrollment completes
> > successfully per the Dogtag side of the equation but the
> response from
> > the server cannot be decrypted by the client and I get the
> following
> > error in the certmonger debug log:
> >
> > 2018-01-29 23:56:43 [5396] Child output:   
> > "Error: failed to verify signature on server
> > response.  
> > "  
> > 2018-01-29 23:56:43 [5396] Error: failed to verify signature
> on server
> > response.
> >
> > The following commands were used for server addition and
> certificate
> > registration.
> >
> > getcert add-scep-ca -c Site_CA -u
> > https://ca.int.localdomain:8443/ca/cgi-bin/pkiclient.exe
> 
> >  > -R
> > /etc/pki/site-pki.pem
> >
> > getcert request -c Site_CA -k /etc/pki/my_cert.pem -f
> > /etc/pki/my_cert.pub -I Host_Cert -R -w -L password
> >
> > Looking at the certmonger code, it looks like it is completely
> skipping
> > all of the case statements and simply dropping down to the 'goto:'
> > https://pagure.io/certmonger/blob/master/f/src/pkcs7.c#_889
> 
> >  >
> >
> > I've tried recompiling certmonger with some debug statements but I
> > haven't managed to suss out what's going on. If someone could
> tell me
> > how to print the actual response from the server, it would be
> appreciated.
> >
> > It certainly feels like the SCEP support has taken a back seat
> to the
> > CMC features but the CMC features just aren't ready to replace
> SCEP at
> > this time and, of course, can't support a lot of hardware
> requirements.
> 
> A couple of things to try:
> 
> - look in the dogtag debug log (/var/log/pki-tomcat/somewhere).
> It may
> have the raw PKCS#7 data to poke at
> - stop the certmonger service and start it in a terminal with
> certmonger
> -d 9 -n 2>&1 | tee

[Freeipa-users] Re: IPA-Server Deletion issues

2018-02-01 Thread Rob Crittenden via FreeIPA-users 
Jamal Mahmoud via FreeIPA-users wrote:
> I'm having strange issues with removing one of my freeIPA masters, I
> managed to mess up the deletion process and my system seems to be stuck
> in a state of limbo, my current setup is 3 servers ( 1 has been
> decommissioned) that all share the CA/Domain responsibilities. When i
> run the command .>
> *ipa-replica-manage list*
> *
> *it produces 3 servers as active masters, when this is not true as i
> have uninstalled ipa-server on one. Trying to delete it through that
> command has given me no luck, even using *--force* and *--cleanup* does
> not work. the same error output appears:
> 
> *oxygen.eggvfx.ie : server not found*

I think we need more information. What version of IPA is this, what
distribution?

Is the above error the exact error you are getting?

As I understand it you ran ipa-server-install --uninstall and THEN tried
to delete the master?

What does ipa-replica-manage list -v `hostname` show on one of the other
masters?

> *
> *
> I'm not very good with ldap tools but after running 
> 
> *ldapsearch -x *
> *
> *there is a reference to the oxygen server still sitting in there, it
> seems that the dirty entry is still hanging around my system, i'm
> wondering if there is any way to resolve this? 
> 
> ldapsearch output:
> *defaultServerList: oxygen.eggvfx.ie 
> nitrogen.eggvfx.ie  lithium.eggvfx.ie
> *

An anonymous LDAP search won't show much.

Does it show up in host-find?

rob

> *
> Looking at the topology graph in the web ui i can see that there are
> still ties between one of my servers and oxygen. It will also not allow
> me to delete the server ties ( error: *Server is unwilling to perform:
> Removal of Segment disconnects topology.Deletion not allowed.)* nor will
> the ui allow me to delete the IPA server (*oxygen.eggvfx.ie
> : server not found*) 
> 
> Any help is greatly appreciated,
> 
> Many Thanks,
> Jamal Mahmoud
> 
> 
> 
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] IPA-Server Deletion issues

2018-02-01 Thread Jamal Mahmoud via FreeIPA-users 
I'm having strange issues with removing one of my freeIPA masters, I
managed to mess up the deletion process and my system seems to be stuck in
a state of limbo, my current setup is 3 servers ( 1 has been
decommissioned) that all share the CA/Domain responsibilities. When i run
the command .

*ipa-replica-manage list*

it produces 3 servers as active masters, when this is not true as i have
uninstalled ipa-server on one. Trying to delete it through that command has
given me no luck, even using *--force* and *--cleanup* does not work. the
same error output appears:

*oxygen.eggvfx.ie : server not found*

I'm not very good with ldap tools but after running

*ldapsearch -x *

there is a reference to the oxygen server still sitting in there, it seems
that the dirty entry is still hanging around my system, i'm wondering if
there is any way to resolve this?

ldapsearch output:
*defaultServerList: oxygen.eggvfx.ie 
nitrogen.eggvfx.ie  lithium.eggvfx.ie
*

Looking at the topology graph in the web ui i can see that there are still
ties between one of my servers and oxygen. It will also not allow me to
delete the server ties ( error: *Server is unwilling to perform: Removal of
Segment disconnects topology.Deletion not allowed.)* nor will the ui allow
me to delete the IPA server (*oxygen.eggvfx.ie :
server not found*)

Any help is greatly appreciated,

Many Thanks,
Jamal Mahmoud
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Host certificates association across IPA servers

2018-02-01 Thread David Harvey via FreeIPA-users 
Initial impression having re-initialised looks encouraging. I didn't have a
guarantee reproducible steps, so will keep an eye on it, but the errors are
no more, and associating a cert on one master was reflected on another. \o/
Thanks again,

David

On 1 February 2018 at 11:57, David Harvey 
wrote:

> Thanks for your swift response Rob,
>
> My apologies, it looks like my superficial replication check was
> insufficient.
>
> ipa-replica-manage -v list ipa2.mydom
> ipa3.mydom: replica
>   last init status: None
>   last init ended: 1970-01-01 00:00:00+00:00
>   last update status: Error (0) Replica acquired successfully: Incremental
> update succeeded
>   last update ended: 2018-02-01 11:47:10+00:00
> ipa1.mydom: replica
>   last init status: None
>   last init ended: 1970-01-01 00:00:00+00:00
>   last update status: Error (18) Replication error acquiring replica:
> Incremental update transient error.  Backing off, will retry update later.
> (transient error)
>   last update ended: 1970-01-01 00:00:00+00:00
>
> Which led me to check on the snowflake where I'm seeing
>
> Feb  1 11:48:49 ipa2 ns-slapd[9471]: [01/Feb/2018:11:48:49.866140639
> +] - ERR - NSMMReplicationPlugin - send_updates - agmt="cn=meToipa1.
> mydom" (ipa1:389): Data required to update replica has been purged from
> the changelog. If the error persists the replica must be reinitialized.
> Feb  1 11:48:52 ipa2 ns-slapd[9471]: [01/Feb/2018:11:48:52.916537089
> +] - ERR - agmt="cn=meToipa1.mydom" (ipa1:389) - clcache_load_buffer -
> Can't locate CSN 5a6872550010 in the changelog (DB rc=-30988). If
> replication stops, the consumer may need to be reinitialized.
> Feb  1 11:48:52 ipa2 ns-slapd[9471]: [01/Feb/2018:11:48:52.919314318
> +] - ERR - NSMMReplicationPlugin - changelog program -
> repl_plugin_name_cl - agmt="cn=meToipa1.mydom" (ipa1:389): CSN
> 5a6872550010 not found, we aren't as up to date, or we purged
> Feb  1 11:48:52 ipa2 ns-slapd[9471]: [01/Feb/2018:11:48:52.922208937
> +] - ERR - NSMMReplicationPlugin - send_updates - agmt="cn=meToipa1.
> mydom" (ipa1:389): Data required to update replica has been purged from
> the changelog. If the error persists the replica must be reinitialized.
> Feb  1 11:48:55 ipa2 ns-slapd[9471]: [01/Feb/2018:11:48:55.956362678
> +] - ERR - agmt="cn=meToipa1.mydom" (ipa1:389) - clcache_load_buffer
> - Can't locate CSN 5a6872550010 in the changelog (DB rc=-30988). If
> replication stops, the consumer may need to be reinitialized.
> Feb  1 11:48:55 ipa2 ns-slapd[9471]: [01/Feb/2018:11:48:55.959110311
> +] - ERR - NSMMReplicationPlugin - changelog program -
> repl_plugin_name_cl - agmt="cn=meToipa1.mydom" (ipa1:389): CSN
> 5a6872550010 not found, we aren't as up to date, or we purged
> Feb  1 11:48:55 ipa2 ns-slapd[9471]: [01/Feb/2018:11:48:55.961578933
> +] - ERR - NSMMReplicationPlugin - send_updates - agmt="cn=meToipa1.
> mydom" (ipa1:389): Data required to update replica has been purged from
> the changelog. If the error persists the replica must be reinitialized.
>
>
> The only obvious error (which I suspect is unrelated) I could spot in http
> land was:
>
> [Thu Feb 01 10:40:39.686959 2018] [wsgi:error] [pid 7302:tid
> 140268792428288] [remote 10.70.64.26:57792] ipa: ERROR: plugin index
> generation failed: Supplied plugin directory path is not a directory
>
> I'll aim to reinitialise the problem box based on this. Without wanting to
> make excuses for my ineptitude, are there any plans to increase visibility
> for replication issues to surface them more obviously?
>
> Thank you so much for your guidance, hugely appreciated.
>
> David
>
>
> On 31 January 2018 at 21:48, Rob Crittenden  wrote:
>
>> David Harvey via FreeIPA-users wrote:
>> > Dear ipa-users,
>> >
>> > I've recently observed a pattern where adding a host certificate to a
>> > host only shows the association in the GUI for the server which issues
>> > the cert. I'm running FreeIPA 4.4.4.
>> >
>> > I request a certificate from the host(s) in question with something
>> like:
>> >
>> > ipa-getcert request -f /path -k /path -r
>> >
>> > All IPA servers show the cert as being issued and valid on the
>> > certificates page.
>> > Visiting the "https://myserver/ipa/ui/#/e/host/details/hostame.fqdn
>> > shows a host certificate from the machine that issued the cert
>> > Visiting the same host page from other ipa servers does not show the
>> > host cert associated.
>> > Users and hosts continue to synchronise, as do other cert details!
>> >
>> > I can manually associate the host to cert on other servers using the
>> > "add" button in the Host certifcate section of the host page, but this
>> > feels wrong.
>> > Any ideas on how to troubleshoot this? It feels like the CAs don't quite
>> > get which one is in charge, and could be a result of me tearing down the
>> > original ubuntu based ones to replace with fedora, or a mistake I have
>> > made

[Freeipa-users] Re: Host certificates association across IPA servers

2018-02-01 Thread David Harvey via FreeIPA-users 
Thanks for your swift response Rob,

My apologies, it looks like my superficial replication check was
insufficient.

ipa-replica-manage -v list ipa2.mydom
ipa3.mydom: replica
  last init status: None
  last init ended: 1970-01-01 00:00:00+00:00
  last update status: Error (0) Replica acquired successfully: Incremental
update succeeded
  last update ended: 2018-02-01 11:47:10+00:00
ipa1.mydom: replica
  last init status: None
  last init ended: 1970-01-01 00:00:00+00:00
  last update status: Error (18) Replication error acquiring replica:
Incremental update transient error.  Backing off, will retry update later.
(transient error)
  last update ended: 1970-01-01 00:00:00+00:00

Which led me to check on the snowflake where I'm seeing

Feb  1 11:48:49 ipa2 ns-slapd[9471]: [01/Feb/2018:11:48:49.866140639 +]
- ERR - NSMMReplicationPlugin - send_updates - agmt="cn=meToipa1.mydom"
(ipa1:389): Data required to update replica has been purged from the
changelog. If the error persists the replica must be reinitialized.
Feb  1 11:48:52 ipa2 ns-slapd[9471]: [01/Feb/2018:11:48:52.916537089 +]
- ERR - agmt="cn=meToipa1.mydom" (ipa1:389) - clcache_load_buffer - Can't
locate CSN 5a6872550010 in the changelog (DB rc=-30988). If
replication stops, the consumer may need to be reinitialized.
Feb  1 11:48:52 ipa2 ns-slapd[9471]: [01/Feb/2018:11:48:52.919314318 +]
- ERR - NSMMReplicationPlugin - changelog program - repl_plugin_name_cl -
agmt="cn=meToipa1.mydom" (ipa1:389): CSN 5a6872550010 not found, we
aren't as up to date, or we purged
Feb  1 11:48:52 ipa2 ns-slapd[9471]: [01/Feb/2018:11:48:52.922208937 +]
- ERR - NSMMReplicationPlugin - send_updates - agmt="cn=meToipa1.mydom"
(ipa1:389): Data required to update replica has been purged from the
changelog. If the error persists the replica must be reinitialized.
Feb  1 11:48:55 ipa2 ns-slapd[9471]: [01/Feb/2018:11:48:55.956362678 +]
- ERR - agmt="cn=meToipa1.mydom" (ipa1:389) - clcache_load_buffer - Can't
locate CSN 5a6872550010 in the changelog (DB rc=-30988). If
replication stops, the consumer may need to be reinitialized.
Feb  1 11:48:55 ipa2 ns-slapd[9471]: [01/Feb/2018:11:48:55.959110311 +]
- ERR - NSMMReplicationPlugin - changelog program - repl_plugin_name_cl -
agmt="cn=meToipa1.mydom" (ipa1:389): CSN 5a6872550010 not found, we
aren't as up to date, or we purged
Feb  1 11:48:55 ipa2 ns-slapd[9471]: [01/Feb/2018:11:48:55.961578933 +]
- ERR - NSMMReplicationPlugin - send_updates - agmt="cn=meToipa1.mydom"
(ipa1:389): Data required to update replica has been purged from the
changelog. If the error persists the replica must be reinitialized.


The only obvious error (which I suspect is unrelated) I could spot in http
land was:

[Thu Feb 01 10:40:39.686959 2018] [wsgi:error] [pid 7302:tid
140268792428288] [remote 10.70.64.26:57792] ipa: ERROR: plugin index
generation failed: Supplied plugin directory path is not a directory

I'll aim to reinitialise the problem box based on this. Without wanting to
make excuses for my ineptitude, are there any plans to increase visibility
for replication issues to surface them more obviously?

Thank you so much for your guidance, hugely appreciated.

David


On 31 January 2018 at 21:48, Rob Crittenden  wrote:

> David Harvey via FreeIPA-users wrote:
> > Dear ipa-users,
> >
> > I've recently observed a pattern where adding a host certificate to a
> > host only shows the association in the GUI for the server which issues
> > the cert. I'm running FreeIPA 4.4.4.
> >
> > I request a certificate from the host(s) in question with something like:
> >
> > ipa-getcert request -f /path -k /path -r
> >
> > All IPA servers show the cert as being issued and valid on the
> > certificates page.
> > Visiting the "https://myserver/ipa/ui/#/e/host/details/hostame.fqdn
> > shows a host certificate from the machine that issued the cert
> > Visiting the same host page from other ipa servers does not show the
> > host cert associated.
> > Users and hosts continue to synchronise, as do other cert details!
> >
> > I can manually associate the host to cert on other servers using the
> > "add" button in the Host certifcate section of the host page, but this
> > feels wrong.
> > Any ideas on how to troubleshoot this? It feels like the CAs don't quite
> > get which one is in charge, and could be a result of me tearing down the
> > original ubuntu based ones to replace with fedora, or a mistake I have
> > made whilst doing so.
>
> I'd still check for replication issues.
>
> Are you sure the host entries in LDAP are the same between the different
> masters?
>
> Can you look in /var/log/httpd/error_log to see if anything is being
> logged when the certificate is not showing?
>
> rob
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] running log show late

2018-02-01 Thread barrykfl--- via FreeIPA-users 
Hi:

Any one find that the log of systemctl | grep running show late in putty?

dirsrv@ABC-COM.service
loaded active running   389 Directory Server ABC.COM.

systemctl | grep running  < after reboot type this not show 389 sever need
wait half - 1 min and retype then show .

Regards

Barry
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Documented monitoring best practices

2018-02-01 Thread Andrew Radygin via FreeIPA-users 
Wow! It's really important question.
I'm joining with it. It's good to be able to know what happening with
IPA-infra.
Espesially - ssh/sudo working (in general at least, with out concearning
about HBAC+Policy groups).

2018-01-31 22:04 GMT+03:00 Alex Corcoles via FreeIPA-users <
freeipa-users@lists.fedorahosted.org>:

> Hi all,
>
> Is there any official literature about how to monitor FreeIPA?
>
> The upstream guide mentions:
>
> 1) Testing clients using id
>
> https://access.redhat.com/documentation/en-us/red_hat_
> enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_
> guide/client-test
>
> 2) Adding a user on a replica and verifying it appears on another server
>
> https://access.redhat.com/documentation/en-us/red_hat_
> enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_
> guide/replica-verify
>
> There's also some troubleshooting appendices which look interesting.
>
> I see also ipactl, "ipa ping", there seems to be:
>
> https://www.freeipa.org/page/V4/Tool_to_Check_Status_of_All_Replicas
> (but it seems dead)
>
> https://www.freeipa.org/page/V4/Monitor_Replication_Topology
>
> , and also some indepedent initiatives all over the web.
>
> Is there any plan to provide an official way to monitor FreeIPA? My
> foremost concern would be to ensure that all clients are correctly enrolled
> and sudo/ssh work, so I am not locked out of my systems. Ensuring that
> replication works seems good and popular. Of course I can check that all
> services are running and ports respond.
>
> What are the most common ways for FreeIPA to break?
>
> Thoughts?
>
> Álex
>
> --
>___
>  {~._.~}
>   ( Y )
>  ()~*~()  mail: alex at corcoles dot net
>  (_)-(_)  http://alex.corcoles.net/
>
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>
>


-- 
Best regards, Andrew.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org