On 04/09/2013 01:28 PM, Martin Kosek wrote:
Hello FreeIPA users!
We would like to give you a heads up about a OCSP/CRL certificate validation
issue introduced in FreeIPA 3.1 release (ticket 3074) we have discovered.
ISSUE:
Certificates issued by FreeIPA server 3.1 and later contains 2
Joseph, Matthew (EXP) wrote:
Hey,
I’m still trying to figure out this error but I am getting nothing.
Anyone have any suggestions or ideas on why this is failing?
Is there a chance you're using a replica file prepared from a different
IPA installation? I'd probably go ahead and use
Hey Rob,
Yes I've tried to do that. Everytime I try to run an ipa-replica-install I make
sure I create a new replica file from the server.
Matt
-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Wednesday, April 10, 2013 10:47 AM
To: Joseph, Matthew (EXP);
Joseph, Matthew (EXP) wrote:
Hey Rob,
Yes I've tried to do that. Everytime I try to run an ipa-replica-install I make
sure I create a new replica file from the server.
Well, it is confusing because this worked once, when you got the error
about replication ID.
I guess I'd use certutil to
Hey Rob,
Here is the output from cerutil -L -d /etc/dirsrv/slapd-DOMAIN-CA/
Server:
Server-Cert u,u,u
Client:
Server-Cert u,u,u
Matt
-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Wednesday, April 10, 2013 11:01 AM
To: Joseph, Matthew (EXP); Nathan
[root@freeipa ~]# ipa hbactest --user=myuser --host=my.fqdn. --service=sshd
Access granted: True
Matched rules: allow_all
[root@freeipa ~]#
└─ ssh myus...@ec2-54-xxx.xxx.compute-1.amazonaws.com -i
/home/user/.ssh/key
Connection closed by 54x.x.x.x
Shawn wrote:
[root@freeipa ~]# ipa hbactest --user=myuser --host=my.fqdn. --service=sshd
Access granted: True
Matched rules: allow_all
[root@freeipa ~]#
└─ ssh myus...@ec2-54-xxx.xxx.compute-1.amazonaws.com
On Wed, Apr 10, 2013 at 02:11:14PM -0400, Rob Crittenden wrote:
Shawn wrote:
[root@freeipa ~]# ipa hbactest --user=myuser --host=my.fqdn. --service=sshd
Access granted: True
Matched rules: allow_all
[root@freeipa ~]#
└─ ssh
(Wed Apr 10 14:22:45 2013) [sssd[pam]] [sss_parse_name_for_domains]
(0x0200): name 'staaj' matched without domain, user is staaj
(Wed Apr 10 14:22:45 2013) [sssd[pam]] [sss_parse_name_for_domains]
(0x0200): using default domain [(null)]
(Wed Apr 10 14:22:45 2013) [sssd[pam]] [pam_print_data]
On Wed, Apr 10, 2013 at 02:27:36PM -0400, Shawn wrote:
(Wed Apr 10 14:22:45 2013) [sssd[pam]] [write_selinux_login_file] (0x0040):
creating the temp file for SELinux data failed.
/etc/selinux/targeted/logins/staajtlQ108(Wed Apr 10 14:22:45 2013)
[sssd[pam]] [pam_reply] (0x0100): blen: 30
I
[root@freeclient1 sssd]# sestatus
SELinux status: disabled
[root@freeclient1 sssd]# ls -ldZ /etc/selinux/
drwxr-xr-x root root ?/etc/selinux/
[root@freeclient1 sssd]#
On Wed, Apr 10, 2013 at 2:31 PM, Jakub Hrozek jhro...@redhat.com wrote:
On
Yep, sure does. Thanks much.
If selinux is disabled, why does it care?
On Wed, Apr 10, 2013 at 2:37 PM, Jakub Hrozek jhro...@redhat.com wrote:
On Wed, Apr 10, 2013 at 02:34:06PM -0400, Shawn wrote:
[root@freeclient1 sssd]# sestatus
SELinux status: disabled
On Wed, Apr 10, 2013 at 02:49:46PM -0400, Shawn wrote:
Yep, sure does. Thanks much.
If selinux is disabled, why does it care?
It's an SSSD bug:
https://bugzilla.redhat.com/show_bug.cgi?id=914433
We didn't realize that SELinux disabled might mean that the directory is
not there at all.
On 04/10/2013 09:55 PM, Joseph, Matthew (EXP) wrote:
Hey,
I’m still trying to figure out this error but I am getting nothing.
Anyone have any suggestions or ideas on why this is failing?
Matt
*From:*freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] *On Behalf Of
14 matches
Mail list logo
