Re: [Freeipa-users] IPA wont start, all services fail

[Simpson Lachlan]

> -Original Message-
> From: Simpson Lachlan
 
> I would like to test a few things, but I'm finding it hard to find good 
> examples.
> 
>  How can I test that the one way trust relationship between the FreeIPA server
>and the AD DC is still in effect? (FreeIPA trusts AD, AD does not trust
> FreeIIPA).
>I presume there is an ldapsearch or sssd command that should connect 
> directly
> to
>the AD server?

I should have asked for what I wanted, because of course I found the solution 
to what 
I *did* ask almost immediately.

Real question: If I get the SID for the "SMB Default Group", is it just a 
matter of editing 
the ldap directory via ldapmodify?

No, because that's again not the issue.

The samba error I get is

pdb backend ipasam:ldapi://%2fvar%2frun%2fslapd-UNIX-CO-ORG-AU.socket did not 
correctly init (error was NT_STATUS_INVALID_PARAMETER)

pbdedit fails on the same problem. 

How can I set the SID of the default group manually - by which I mean, using a 
command line tool to manipulate text (rather than a shell script or 
ipa-adtrust).

Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] Cross Domain Trust

[Zoske, Fabian]

Hi Lukas,

such a realm does not exists, but it is my user principal name in AD, due to 
legacy compatibility with Exchange.

Best regards,
Fabian

-Ursprüngliche Nachricht-
Von: Lukas Slebodnik [mailto:lsleb...@redhat.com] 
Gesendet: Montag, 18. Januar 2016 18:03
An: Zoske, Fabian
Cc: freeipa-users@redhat.com
Betreff: Re: [Freeipa-users] Cross Domain Trust

On (12/01/16 11:11), Lukas Slebodnik wrote:
>On (12/01/16 08:25), Zoske, Fabian wrote:
>>We recently upgraded our IPA-Server from CentOS 7.1 to CentOS 7.2. So far no 
>>differences.
>>
>Then please provide sssd logfiles (1.13.3) from client and also log 
>files from sssd on freeipa server (sssd on freeipa server is used 
>indirectly by extop plugin in 389-ds)
>
>Please provide log files from the same time when you reproduced an issue.
>
Thank you very much for log files.

Authentication on client failed Due to following error:
(Thu Jan 14 12:58:36 2016) [[sssd[krb5_child[992 [sss_child_krb5_trace_cb] 
(0x4000): [992] 1452772716.736098: Sending request (173 bytes) to 
EUROIMMUN.TEST (master)

(Thu Jan 14 12:58:37 2016) [[sssd[krb5_child[992 [get_and_save_tgt] 
(0x0020): 1232: [-1765328230][Cannot find KDC for realm "EUROIMMUN.TEST"] (Thu 
Jan 14 12:58:37 2016) [[sssd[krb5_child[992 [map_krb5_error] (0x0020): 
1301: [-1765328230][Cannot find KDC for realm "EUROIMMUN.TEST"] (Thu Jan 14 
12:58:37 2016) [[sssd[krb5_child[992 [k5c_send_data] (0x0200): Received 
error code 1432158209 (Thu Jan 14 12:58:37 2016) [[sssd[krb5_child[992 
[pack_response_packet] (0x2000): response packet size: [4] (Thu Jan 14 12:58:37 
2016) [[sssd[krb5_child[992 [k5c_send_data] (0x4000): Response sent.
(Thu Jan 14 12:58:37 2016) [[sssd[krb5_child[992 [main] (0x0400): 
krb5_child completed successfully


Do you have defineded the realm "EUROIMMUN.TEST" in your krb5.conf?

It is possible that sssd wrote snippet to the directory 
/var/lib/sss/pubconf/krb5.include.d/
but this directory is not included in krb5.conf.

$ grep includedir /etc/krb5.conf
includedir /var/lib/sss/pubconf/krb5.include.d/

BTW you can test the same operation as sssd did from command line.

KRB5_TRACE=/dev/stderr kinit f.zo...@euroimmun.test

or is this principal name an enterprise name?

LS

-- 
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] IPA wont start, all services fail

[Simpson Lachlan]

> -Original Message-
> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
> Sent: Thursday, 21 January 2016 9:22 AM

> >ses=4294967295 subj=kernel pid=18340 comm="httpd" reason="memory
> >violation" sig=11 type=ANOM_ABEND msg=audit(1453325558.988:1245):
> >auid=4294967295 uid=991 gid=987 ses=4294967295 subj=kernel pid=18357
> >comm="httpd" reason="memory violation" sig=11
> Ok, I see two problems above and they may be related to recently fixed issue 
> with
> python-cryptography's use of python-cffi. However, this issue should not 
> affect
> CentOS 7.2 as the broken python-cryptography code is not in RHEL 7.2 at all, 
> so
> I'm a bit puzzled.


I’m sure it's now apparent that I'm a relative FreeIPA/sssd new comer, and tbh, 
my 
involvement with AD has been "enough to not hurt myself or others or 
production",
samba I last played with seriously for AD related issues way back when 2.x was 
around - since then it's been file sharing only.

I would like to test a few things, but I'm finding it hard to find good 
examples.

 How can I test that the one way trust relationship between the FreeIPA server
   and the AD DC is still in effect? (FreeIPA trusts AD, AD does not trust 
FreeIIPA).
   I presume there is an ldapsearch or sssd command that should connect 
directly to
   the AD server? 

Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] ipa-client-install and nsslapd-allow-anonymous-access: off

[Martin Kosek]

On 01/20/2016 05:55 PM, bahan w wrote:
> Ah sorry, for security reasons I didn't want to put the original name and I
> made a mistake.
> 
> Here we are, for the confusing lines :
> ###
> Assuming realm is the same as domain: 
> Generated basedn from realm: dc=
> Discovery result: NO_ACCESS_TO_LDAP; server=None, domain=,
> kdc=None, basedn=dc=
> Validated servers: 
> will use discovered domain: 
> Using servers from command line, disabling DNS discovery
> will use provided server: 
> will use discovered realm: 
> The provided realm name [] does not match discovered one
> []
> (: Assumed same as domain)
> Installation failed. Rolling back changes
> IPA client is not configured on this system.
> ###
> 
> Is it more clear ? Sorry again for the confusion.
> 
> I use a realm which is different than the domain.

Ah, I see. I think you just found a bug. The problem is that given the server
is not reachable, the realm is calculated based on the domain and then rejected
as it is different from the option. In this case, ipa-client-install should
just accept the realm passed to the script. It is very specific condition, but
we should be able to fix that easily

I filed a bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1300561

We will need to think if there is a workaround for you until the fix is 
delivered.

-- 
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] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists

[Nathan Peters]

All checks below were performed from the host we are trying to turn into a 
replica and they were performed against the master who logs I also show

The first check was to kinit admin and try the search.  Surprisingly, the 
GSSAPI bind returns no results when we search that.  In my previous email you 
can see that the standard bind gets a result as admin for that search.

Next, I tried as the host by kinit with its keytab.  Same result, nothing back.

Finally I tried as my own personal admin user.  Same result, nothing back.

For good measure, I tried a broad search against the base "cn=mydomain,cn=net" 
as each user as well and I'll spare you the ten thousand lines of screenshot 
but the results were as expected, several thousand entries in that tree.
Although the output differed slightly.  This is the total as admin or my 
personal user
# numResponses: 3372
# numEntries: 3371

and this is the total as the host keytab account

# numResponses: 3371
# numEntries: 3370

To be even more thorough, I did searches farther and farther up the config tree 
using GSSAPI until I found something.  The only thing that is visible through 
GSSAPI searches is the base of the config tree.  Even the mapping tree branch 
doesn't seem to be visible.

At the very bottom of this email is the results of the search against cn=config 
directly as the attempted new replica and as admin.  Admin gets about 50 
results and the host only gets about 30 for some reason.  I get the same 
results as admin on my personal account so I've excluded those.

So if I got all that right I was able to determine that only the base of the 
config tree is available using GSSAPI for any account, users for some reason 
get slightly more results than hosts, and all accounts can see the 
dc=mydomain,dc=net tree just fine using GSSAPI.

So does that help shed some light on what the cause of this might be or why the 
server is not answering as expected?

Is there some way I can adjust this so everyone can see the results they do 
using regular binds as they do using GSSAPI binds ?

Is there some way I can check ACLS on stuff ?

===
search as admin
===
[nathan.peters@dc2-ipa-dev-van ~]$ klist
Ticket cache: KEYRING:persistent:756600344:756600344
Default principal: ad...@mydomain.net

Valid starting ExpiresService principal
20/01/16 22:53:18  21/01/16 22:53:08  krbtgt/mydomain@mydomain.net
[nathan.peters@dc2-ipa-dev-van ~]$ ldapsearch -Y GSSAPI -H 
ldaps://dc2-ipa-dev-nvan.mydomain.net -b 
"cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config"
SASL/GSSAPI authentication started
SASL username: ad...@mydomain.net
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base 

Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists

[Nathan Peters]

I don't know if this makes a difference too, but I performed the same checks on 
a different completely working and joined FreeIPA master, against other 
masters, and even against itself directly.

It seems that no account, no keytab, and no host can see that mapping tree 
branch no matter who they search from or against if GSSAPI is used.


-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Nathan Peters
Sent: January-20-16 11:41 PM
To: Rich Megginson; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with 
DuplicateEntry: This entry already exists

All checks below were performed from the host we are trying to turn into a 
replica and they were performed against the master who logs I also show

The first check was to kinit admin and try the search.  Surprisingly, the 
GSSAPI bind returns no results when we search that.  In my previous email you 
can see that the standard bind gets a result as admin for that search.

Next, I tried as the host by kinit with its keytab.  Same result, nothing back.

Finally I tried as my own personal admin user.  Same result, nothing back.

For good measure, I tried a broad search against the base "cn=mydomain,cn=net" 
as each user as well and I'll spare you the ten thousand lines of screenshot 
but the results were as expected, several thousand entries in that tree.
Although the output differed slightly.  This is the total as admin or my 
personal user # numResponses: 3372 # numEntries: 3371

and this is the total as the host keytab account

# numResponses: 3371
# numEntries: 3370

To be even more thorough, I did searches farther and farther up the config tree 
using GSSAPI until I found something.  The only thing that is visible through 
GSSAPI searches is the base of the config tree.  Even the mapping tree branch 
doesn't seem to be visible.

At the very bottom of this email is the results of the search against cn=config 
directly as the attempted new replica and as admin.  Admin gets about 50 
results and the host only gets about 30 for some reason.  I get the same 
results as admin on my personal account so I've excluded those.

So if I got all that right I was able to determine that only the base of the 
config tree is available using GSSAPI for any account, users for some reason 
get slightly more results than hosts, and all accounts can see the 
dc=mydomain,dc=net tree just fine using GSSAPI.

So does that help shed some light on what the cause of this might be or why the 
server is not answering as expected?

Is there some way I can adjust this so everyone can see the results they do 
using regular binds as they do using GSSAPI binds ?

Is there some way I can check ACLS on stuff ?

===
search as admin
===
[nathan.peters@dc2-ipa-dev-van ~]$ klist Ticket cache: 
KEYRING:persistent:756600344:756600344
Default principal: ad...@mydomain.net

Valid starting ExpiresService principal
20/01/16 22:53:18  21/01/16 22:53:08  krbtgt/mydomain@mydomain.net 
[nathan.peters@dc2-ipa-dev-van ~]$ ldapsearch -Y GSSAPI -H 
ldaps://dc2-ipa-dev-nvan.mydomain.net -b 
"cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config"
SASL/GSSAPI authentication started
SASL username: ad...@mydomain.net
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base 

Re: [Freeipa-users] IPA wont start, all services fail

[Alexander Bokovoy]

On Thu, 21 Jan 2016, Simpson Lachlan wrote:

-Original Message-
From: Simpson Lachlan



I would like to test a few things, but I'm finding it hard to find good 
examples.

 How can I test that the one way trust relationship between the FreeIPA server
   and the AD DC is still in effect? (FreeIPA trusts AD, AD does not trust
FreeIIPA).
   I presume there is an ldapsearch or sssd command that should connect directly
to
   the AD server?


I should have asked for what I wanted, because of course I found the solution 
to what
I *did* ask almost immediately.

Real question: If I get the SID for the "SMB Default Group", is it just a 
matter of editing
the ldap directory via ldapmodify?

The SID is generated by sidgen plugin but you can edit it with
ldapmodify yes.



No, because that's again not the issue.

No, it *is* the issue for Samba to start.


The samba error I get is

pdb backend ipasam:ldapi://%2fvar%2frun%2fslapd-UNIX-CO-ORG-AU.socket did not 
correctly init (error was NT_STATUS_INVALID_PARAMETER)

pbdedit fails on the same problem.

Sure, because it cannot initialize its ipasam LDAP driver which requires
properly set up LDAP data which is supposed to be set up by
ipa-adtrust-install.

I would appreciate you concentrating on the right issue instead of
jumping around to pretend Samba can start without fixing the real issue
at hand.



How can I set the SID of the default group manually - by which I mean,
using a command line tool to manipulate text (rather than a shell
script or ipa-adtrust).

At this point let us do a different look. Can you provide
/var/log/ipaserver-install.log and /var/log/ipaupgrade.log somehow off
the mailing list to see what exactly had happened to your environment
when it was installed and when ipa-adtrust-install was run?

I'm pretty busy with other stuff so analyzing these files might take
several days.
--
/ Alexander Bokovoy

--
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] ipa-client-install and nsslapd-allow-anonymous-access: off

[bahan w]

Re Martin.

Here we are for the ipaclient-install.log :

###
2016-01-20T14:55:48Z DEBUG /usr/sbin/ipa-client-install was invoked with
options: {'domain': '', 'force': False, 'realm_name':
'', 'krb5_offline_passwords': True, 'primary': False, 'mkhomedir':
True, 'create_sshfp': True, 'conf_sshd': False, 'conf_ntp': False,
'on_master': False, 'ntp_server': None, 'nisdomain': None, 'no_nisdomain':
False, 'principal': 'admin', 'hostname': '', 'no_ac':
False, 'unattended': True, 'sssd': True, 'trust_sshfp': False,
'kinit_attempts': 5, 'dns_updates': False, 'conf_sudo': True, 'conf_ssh':
False, 'force_join': False, 'ca_cert_file': None, 'server': [''], 'prompt_password': False, 'permit': False, 'debug': True,
'preserve_sssd': False, 'uninstall': False}
2016-01-20T14:55:48Z DEBUG missing options might be asked for interactively
later
2016-01-20T14:55:48Z DEBUG Loading Index file from
'/var/lib/ipa-client/sysrestore/sysrestore.index'
2016-01-20T14:55:48Z DEBUG Loading StateFile from
'/var/lib/ipa-client/sysrestore/sysrestore.state'
2016-01-20T14:55:48Z DEBUG [IPA Discovery]
2016-01-20T14:55:48Z DEBUG Starting IPA discovery with domain=,
servers=[''], hostname=
2016-01-20T14:55:48Z DEBUG Server and domain forced
2016-01-20T14:55:48Z DEBUG [Kerberos realm search]
2016-01-20T14:55:48Z DEBUG Search DNS for TXT record of
_kerberos..
2016-01-20T14:55:48Z DEBUG No DNS record found
2016-01-20T14:55:48Z DEBUG [LDAP server check]
2016-01-20T14:55:48Z DEBUG Verifying that  (realm None) is
an IPA server
2016-01-20T14:55:48Z DEBUG Init LDAP connection with: ldap://:389
2016-01-20T14:55:48Z DEBUG LDAP Error: Anonymous access not allowed
2016-01-20T14:55:48Z DEBUG Assuming realm is the same as domain: 
2016-01-20T14:55:48Z DEBUG Generated basedn from realm:
dc=
2016-01-20T14:55:48Z DEBUG Discovery result: NO_ACCESS_TO_LDAP;
server=None, domain=, kdc=None, basedn=
2016-01-20T14:55:48Z DEBUG Validated servers: 
2016-01-20T14:55:48Z DEBUG will use discovered domain: 
2016-01-20T14:55:48Z DEBUG Using servers from command line, disabling DNS
discovery
2016-01-20T14:55:48Z DEBUG will use provided server: 
2016-01-20T14:55:48Z DEBUG will use discovered realm: 
2016-01-20T14:55:48Z ERROR The provided realm name [] does not
match discovered one []
2016-01-20T14:55:48Z DEBUG (: Assumed same as domain)
2016-01-20T14:55:48Z ERROR Installation failed. Rolling back changes.
2016-01-20T14:55:48Z ERROR IPA client is not configured on this system.
###

Best regards.

Bahan

On Wed, Jan 20, 2016 at 1:52 PM, Martin Kosek  wrote:

> Adding freeipa-users back, so that others can benefit from the answer.
>
> Can you please attach a full ipaclient-install.log DEBUG log somewhere so
> that
> we can get the full context of the bug? You may also want to open a RHEL-6
> Bugzilla as FreeIPA 3.0.0 is no longer developed upstream, but only
> maintained
> in RHEL-6.x.
>
> Thanks,
> Martin
>
> On 01/20/2016 01:39 PM, bahan w wrote:
> > Hello Martin !
> >
> > Thanks for your answer, Martin !
> >
> > I uninstalled the 3.0.0.25 and installed the 3.0.0.47, but unfortunately
> I
> > still have the same error message.
> >
> > # rpm -qa | grep ipa-client
> > ipa-client-3.0.0-47.el6.x86_64
> >
> > And in ipa-client-install.log :
> > ###
> > 2016-01-20T12:38:14Z DEBUG [LDAP server check]
> > 2016-01-20T12:38:14Z DEBUG Verifying that  (realm None)
> is
> > an IPA server
> > 2016-01-20T12:38:14Z DEBUG Init LDAP connection with: ldap:// > server>:389
> > 2016-01-20T12:38:14Z DEBUG LDAP Error: Anonymous access not allowed
> > ###
> >
> > Best regards.
> >
> > Bahan
> >
> >
> > On Wed, Jan 20, 2016 at 1:26 PM, Martin Kosek  wrote:
> >
> >> On 01/20/2016 12:08 PM, bahan w wrote:
> >>> Hello !
> >>>
> >>> I send you this mail because of the following topic.
> >>>
> >>> I have FreeIPA 3.0.0.25 with RHEL 6.6 and I deactivated the anonymous
> >>> access for security reasons.
> >>>
> >>> But now, I have a problem when I try to enroll a new host.
> >>>
> >>> Here is the command I try :
> >>> ###
> >>> ipa-client-install --domain= --realm= --server= >>> ipaserver> --principal=admin --password=
> >>> --mkhomedir  --hostname= --no-ntp --no-ssh --no-sshd
> >>> --unattended
> >>> ###
> >>>
> >>> And here is the error message :
> >>> ###
> >>> 2016-01-20T11:06:44Z DEBUG Verifying that  (realm None)
> >> is
> >>> an IPA server
> >>> 2016-01-20T11:06:44Z DEBUG Init LDAP connection with: ldap:// >>> server>:389
> >>> 2016-01-20T11:06:44Z DEBUG LDAP Error: Anonymous access not allowed
> >>> ###
> >>>
> >>> Is there a way with IPA 3.0.0.25 to enroll host with the anonymous
> acces
> >>> disabled ?
> >>>
> >>> Best regards.
> >>>
> >>> Bahan
> >>
> >> Hello,
> >>
> >> This looks like
> >> https://bugzilla.redhat.com/show_bug.cgi?id=922843
> >>
> >> It should be fixed in recent ipa-client versions (ipa-3.0.0-29.el6 and
> >> later).
> >>
> >> HTH,
> >> Martin
> >>
> >>
> >
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:

Re: [Freeipa-users] ipa-client-install and nsslapd-allow-anonymous-access: off

[Martin Kosek]

On 01/20/2016 04:03 PM, bahan w wrote:
> Re Martin.
> 
> Here we are for the ipaclient-install.log :
> 
> ###
> 2016-01-20T14:55:48Z DEBUG /usr/sbin/ipa-client-install was invoked with
> options: {'domain': '', 'force': False, 'realm_name':
> '', 'krb5_offline_passwords': True, 'primary': False, 'mkhomedir':
> True, 'create_sshfp': True, 'conf_sshd': False, 'conf_ntp': False,
> 'on_master': False, 'ntp_server': None, 'nisdomain': None, 'no_nisdomain':
> False, 'principal': 'admin', 'hostname': '', 'no_ac':
> False, 'unattended': True, 'sssd': True, 'trust_sshfp': False,
> 'kinit_attempts': 5, 'dns_updates': False, 'conf_sudo': True, 'conf_ssh':
> False, 'force_join': False, 'ca_cert_file': None, 'server': [' SERVER>'], 'prompt_password': False, 'permit': False, 'debug': True,
> 'preserve_sssd': False, 'uninstall': False}
> 2016-01-20T14:55:48Z DEBUG missing options might be asked for interactively
> later
> 2016-01-20T14:55:48Z DEBUG Loading Index file from
> '/var/lib/ipa-client/sysrestore/sysrestore.index'
> 2016-01-20T14:55:48Z DEBUG Loading StateFile from
> '/var/lib/ipa-client/sysrestore/sysrestore.state'
> 2016-01-20T14:55:48Z DEBUG [IPA Discovery]
> 2016-01-20T14:55:48Z DEBUG Starting IPA discovery with domain=,
> servers=[''], hostname=
> 2016-01-20T14:55:48Z DEBUG Server and domain forced
> 2016-01-20T14:55:48Z DEBUG [Kerberos realm search]
> 2016-01-20T14:55:48Z DEBUG Search DNS for TXT record of
> _kerberos..
> 2016-01-20T14:55:48Z DEBUG No DNS record found
> 2016-01-20T14:55:48Z DEBUG [LDAP server check]
> 2016-01-20T14:55:48Z DEBUG Verifying that  (realm None) is
> an IPA server
> 2016-01-20T14:55:48Z DEBUG Init LDAP connection with: ldap:// SERVER>:389
> 2016-01-20T14:55:48Z DEBUG LDAP Error: Anonymous access not allowed
> 2016-01-20T14:55:48Z DEBUG Assuming realm is the same as domain: 
> 2016-01-20T14:55:48Z DEBUG Generated basedn from realm:
> dc=
> 2016-01-20T14:55:48Z DEBUG Discovery result: NO_ACCESS_TO_LDAP;
> server=None, domain=, kdc=None, basedn=
> 2016-01-20T14:55:48Z DEBUG Validated servers: 
> 2016-01-20T14:55:48Z DEBUG will use discovered domain: 
> 2016-01-20T14:55:48Z DEBUG Using servers from command line, disabling DNS
> discovery
> 2016-01-20T14:55:48Z DEBUG will use provided server: 
> 2016-01-20T14:55:48Z DEBUG will use discovered realm: 
> 2016-01-20T14:55:48Z ERROR The provided realm name [] does not
> match discovered one []

Well, I think the line above is the key to the problem. The realm you provided
and the one discovered do not match.

> 2016-01-20T14:55:48Z DEBUG (: Assumed same as domain)
> 2016-01-20T14:55:48Z ERROR Installation failed. Rolling back changes.
> 2016-01-20T14:55:48Z ERROR IPA client is not configured on this system.
> ###
> 
> Best regards.
> 
> Bahan
> 
> On Wed, Jan 20, 2016 at 1:52 PM, Martin Kosek  wrote:
> 
>> Adding freeipa-users back, so that others can benefit from the answer.
>>
>> Can you please attach a full ipaclient-install.log DEBUG log somewhere so
>> that
>> we can get the full context of the bug? You may also want to open a RHEL-6
>> Bugzilla as FreeIPA 3.0.0 is no longer developed upstream, but only
>> maintained
>> in RHEL-6.x.
>>
>> Thanks,
>> Martin
>>
>> On 01/20/2016 01:39 PM, bahan w wrote:
>>> Hello Martin !
>>>
>>> Thanks for your answer, Martin !
>>>
>>> I uninstalled the 3.0.0.25 and installed the 3.0.0.47, but unfortunately
>> I
>>> still have the same error message.
>>>
>>> # rpm -qa | grep ipa-client
>>> ipa-client-3.0.0-47.el6.x86_64
>>>
>>> And in ipa-client-install.log :
>>> ###
>>> 2016-01-20T12:38:14Z DEBUG [LDAP server check]
>>> 2016-01-20T12:38:14Z DEBUG Verifying that  (realm None)
>> is
>>> an IPA server
>>> 2016-01-20T12:38:14Z DEBUG Init LDAP connection with: ldap://>> server>:389
>>> 2016-01-20T12:38:14Z DEBUG LDAP Error: Anonymous access not allowed
>>> ###
>>>
>>> Best regards.
>>>
>>> Bahan
>>>
>>>
>>> On Wed, Jan 20, 2016 at 1:26 PM, Martin Kosek  wrote:
>>>
 On 01/20/2016 12:08 PM, bahan w wrote:
> Hello !
>
> I send you this mail because of the following topic.
>
> I have FreeIPA 3.0.0.25 with RHEL 6.6 and I deactivated the anonymous
> access for security reasons.
>
> But now, I have a problem when I try to enroll a new host.
>
> Here is the command I try :
> ###
> ipa-client-install --domain= --realm= --server= ipaserver> --principal=admin --password=
> --mkhomedir  --hostname= --no-ntp --no-ssh --no-sshd
> --unattended
> ###
>
> And here is the error message :
> ###
> 2016-01-20T11:06:44Z DEBUG Verifying that  (realm None)
 is
> an IPA server
> 2016-01-20T11:06:44Z DEBUG Init LDAP connection with: ldap:// server>:389
> 2016-01-20T11:06:44Z DEBUG LDAP Error: Anonymous access not allowed
> ###
>
> Is there a way with IPA 3.0.0.25 to enroll host with the anonymous
>> acces
> disabled ?
>
> Best regards.
>
> Bahan

 

Re: [Freeipa-users] ipa-client-install and nsslapd-allow-anonymous-access: off

[bahan w]

Ah sorry, for security reasons I didn't want to put the original name and I
made a mistake.

Here we are, for the confusing lines :
###
Assuming realm is the same as domain: 
Generated basedn from realm: dc=
Discovery result: NO_ACCESS_TO_LDAP; server=None, domain=,
kdc=None, basedn=dc=
Validated servers: 
will use discovered domain: 
Using servers from command line, disabling DNS discovery
will use provided server: 
will use discovered realm: 
The provided realm name [] does not match discovered one
[]
(: Assumed same as domain)
Installation failed. Rolling back changes
IPA client is not configured on this system.
###

Is it more clear ? Sorry again for the confusion.

I use a realm which is different than the domain.

Best regards.

Bahan
​
-- 
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] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists

[Rich Megginson]

On 01/20/2016 12:24 PM, Nathan Peters wrote:

Now we are starting to get somewhere (although a resolution still is not 
visible) :)

First, thank you Petr and Rob for your help on this issue.  I apologize for our 
hard to parse server names.  I'm not a fan of them myself and in earlier 
reports I had been reformatting everything nicely with dc1, dc2, dc3 etc.  
After having to submit so many reports I started to get lazy an thought it may 
be more helpful to see data closer to what we are actually using.

Petr hit the nail on the head with the "does everyone who binds get the same 
result" question, which although it has not revealed a resolution, has revealed a 
bunch of really interesting facts about the process.

Going back to the original logs that were running on the remote master during 
the replica installation attempt I see the following :

[18/Jan/2016:09:28:32 -0800] conn=18732 fd=77 slot=77 connection from 
10.21.0.98 to 10.178.0.98

[18/Jan/2016:09:28:32 -0800] conn=18732 op=0 BIND dn="" method=sasl version=3 
mech=GSSAPI
[18/Jan/2016:09:28:32 -0800] conn=18732 op=0 RESULT err=14 tag=97 nentries=0 
etime=0, SASL bind in progress
[18/Jan/2016:09:28:32 -0800] conn=18732 op=1 BIND dn="" method=sasl version=3 
mech=GSSAPI
[18/Jan/2016:09:28:32 -0800] conn=18732 op=1 RESULT err=14 tag=97 nentries=0 
etime=0, SASL bind in progress
[18/Jan/2016:09:28:32 -0800] conn=18732 op=2 BIND dn="" method=sasl version=3 
mech=GSSAPI
[18/Jan/2016:09:28:32 -0800] conn=18732 op=2 RESULT err=0 tag=97 nentries=0 etime=0 
dn="fqdn=dc2-ipa-dev-van.mydomain.net,cn=computers,cn=accounts,dc=mydomain,dc=net"
[18/Jan/2016:09:28:32 -0800] conn=18732 op=3 SRCH 
base="cn=replication,cn=etc,dc=mydomain,dc=net" scope=0 
filter="(objectClass=*)" attrs=ALL
[18/Jan/2016:09:28:32 -0800] conn=18732 op=3 RESULT err=0 tag=101 nentries=1 
etime=0
[18/Jan/2016:09:28:32 -0800] conn=18732 op=4 SRCH base="cn=schema" scope=0 
filter="(objectClass=*)" attrs="attributeTypes objectClasses"
[18/Jan/2016:09:28:32 -0800] conn=18732 op=4 RESULT err=0 tag=101 nentries=1 
etime=0

So, conn18732 was opened with a bind dn of "" ?  Is this supposed to happen?


Yes.  GSSAPI/SASL binds are multi-stage binds.  You'll notice that the 
last stage is op=2, and the result has the full bind DN to which the 
kerberos principals mapped to.  The dn="" until the last stage at which 
time the mapped DN is known and logged.




Here is what I see when I search that base using the same empty bind dn :


nack - you have to first use "kinit myusername@MYDOMAIN", then use 
ldapsearch -Y GSSAPI , to do the bind in the same way to use GSSAPI.




---snip---
[root@dc2-ipa-dev-van ~]# ldapsearch -H ldaps://dc2-ipa-dev-nvan.mydomain.net -b 
"cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" -D ""
# extended LDIF
#
# LDAPv3
# base 

Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists

[Nathan Peters]

Now we are starting to get somewhere (although a resolution still is not 
visible) :)

First, thank you Petr and Rob for your help on this issue.  I apologize for our 
hard to parse server names.  I'm not a fan of them myself and in earlier 
reports I had been reformatting everything nicely with dc1, dc2, dc3 etc.  
After having to submit so many reports I started to get lazy an thought it may 
be more helpful to see data closer to what we are actually using.

Petr hit the nail on the head with the "does everyone who binds get the same 
result" question, which although it has not revealed a resolution, has revealed 
a bunch of really interesting facts about the process.

Going back to the original logs that were running on the remote master during 
the replica installation attempt I see the following :

[18/Jan/2016:09:28:32 -0800] conn=18732 fd=77 slot=77 connection from 
10.21.0.98 to 10.178.0.98
> [18/Jan/2016:09:28:32 -0800] conn=18732 op=0 BIND dn="" method=sasl version=3 
> mech=GSSAPI
> [18/Jan/2016:09:28:32 -0800] conn=18732 op=0 RESULT err=14 tag=97 nentries=0 
> etime=0, SASL bind in progress
> [18/Jan/2016:09:28:32 -0800] conn=18732 op=1 BIND dn="" method=sasl version=3 
> mech=GSSAPI
> [18/Jan/2016:09:28:32 -0800] conn=18732 op=1 RESULT err=14 tag=97 nentries=0 
> etime=0, SASL bind in progress
> [18/Jan/2016:09:28:32 -0800] conn=18732 op=2 BIND dn="" method=sasl version=3 
> mech=GSSAPI
> [18/Jan/2016:09:28:32 -0800] conn=18732 op=2 RESULT err=0 tag=97 nentries=0 
> etime=0 
> dn="fqdn=dc2-ipa-dev-van.mydomain.net,cn=computers,cn=accounts,dc=mydomain,dc=net"
> [18/Jan/2016:09:28:32 -0800] conn=18732 op=3 SRCH 
> base="cn=replication,cn=etc,dc=mydomain,dc=net" scope=0 
> filter="(objectClass=*)" attrs=ALL
> [18/Jan/2016:09:28:32 -0800] conn=18732 op=3 RESULT err=0 tag=101 nentries=1 
> etime=0
> [18/Jan/2016:09:28:32 -0800] conn=18732 op=4 SRCH base="cn=schema" scope=0 
> filter="(objectClass=*)" attrs="attributeTypes objectClasses"
> [18/Jan/2016:09:28:32 -0800] conn=18732 op=4 RESULT err=0 tag=101 nentries=1 
> etime=0

So, conn18732 was opened with a bind dn of "" ?  Is this supposed to happen?

Here is what I see when I search that base using the same empty bind dn :

---snip---
[root@dc2-ipa-dev-van ~]# ldapsearch -H ldaps://dc2-ipa-dev-nvan.mydomain.net 
-b "cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" -D ""
# extended LDIF
#
# LDAPv3
# base 

[Freeipa-users] DNS Module (DNSSEC) NSEC§

[Günther J . Niederwimmer]

Hello,

I can't find a way to integrate NSEC3, all DOC's I found is only for DNSSEC, 
but not including NSEC3.

Can any help me to set up this correct ?

Thanks for a answer, 

-- 
mit freundlichen Grüßen / best regards,

  Günther J. Niederwimmer

-- 
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] FreeIPA AD Trust

[Alexander Bokovoy]

On Wed, 20 Jan 2016, Andrew Meyer wrote:

So I'm getting this when trying to setup a trust between 2012r2 and FreeIPA on 
CentOS 7.2 
[user@asm-dns01 ~]$ sudo ipa-adtrust-install

I don't recommend running ipa-adtrust-install under sudo as you do. sudo
would keep some of user-related environment that is used by IPA
framework code to decide where user's cached session data is stored.

Use 'sudo -i' instead.

The rest of warnings and errors you've got are related to this
unexpected behavior.


--
/ Alexander Bokovoy

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

[Freeipa-users] FreeIPA AD Trust

[Andrew Meyer]

So I'm getting this when trying to setup a trust between 2012r2 and FreeIPA on 
CentOS 7.2 
[user@asm-dns01 ~]$ sudo ipa-adtrust-install
The log file for this installation can be found in 
/var/log/ipaserver-install.log==This
 program will setup components needed to establish trust to AD domains forthe 
IPA Server.
This includes:  * Configure Samba  * Add trust related objects to IPA LDAP 
server
To accept the default shown in brackets, press the Enter key.
ipa.ipaserver.rpcserver.xmlserver_session: ERROR    unable to parse 
session_auth_duration, defaulting to 3600: expected string or 
bufferipa.ipaserver.rpcserver.xmlserver_session: ERROR    unable to parse 
session_auth_duration, defaulting to 3600: expected string or 
bufferipa.ipaserver.rpcserver.login_kerberos: ERROR    unable to parse 
session_auth_duration, defaulting to 3600: expected string or 
bufferipa.ipaserver.rpcserver.login_password: ERROR    unable to parse 
session_auth_duration, defaulting to 3600: expected string or 
bufferipa.ipaserver.rpcserver.xmlserver: ERROR    unable to parse 
session_auth_duration, defaulting to 3600: expected string or 
bufferipa.ipaserver.rpcserver.jsonserver_session: ERROR    unable to parse 
session_auth_duration, defaulting to 3600: expected string or 
bufferipa.ipaserver.rpcserver.jsonserver_kerb: ERROR    unable to parse 
session_auth_duration, defaulting to 3600: expected string or bufferWARNING: 
The smb.conf already exists. Running ipa-adtrust-install will break your 
existing samba configuration.

Do you wish to continue? [no]:Aborting installation.[user@asm-dns01 ~]$
Not sure what i'm missing.  IS this a DNS issue?  Maybe I don't have a NS 
record or something?  
FreeIPA DNS domain is borg.localAD DNS Domain is ad.borg.local-- 
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] IPA wont start, all services fail

[Simpson Lachlan]

> -Original Message-
> 
> Is there any coredump available with 389-ds crashing? I've asked you to use
> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes to enable
> coredumps for 389-ds in one of previous discussions, was it done?
> You seemed to get diverted to winbindd core (which was expected to coredump as
> 389-ds was not available), but if you see 389-ds disappearing in several hours
> without any logging, this means there was a crash and we'd like to see the
> coredump of it.

Hi Alex,

I did perform the "Debugging Crashes" steps when you asked, but there are still 
no core dumps in /var/log/dirsrv/slapd-INSTANCENAME.

 
> You can check also /var/log/audit/audit.log to see if there is a trace of a 
> crash. It
> may take different ways but one crash type is following:
 
> type=ANOM_ABEND msg=audit(1453212583.746:2337): auid=4294967295
> uid=983
> gid=980 ses=4294967295 subj=system_u:system_r:dirsrv_t:s0 pid=26079
> comm="ns-slapd" exe="/usr/sbin/ns-slapd" sig=11

There are no instances of ns-slap in the audit.log, there are a dozen sig=11s, 
all of them relate to a "memory violation" in httpd_t, and all references to 
dirsrv look like this:

type=SERVICE_STOP msg=audit(1453174960.933:209): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=kernel msg='unit=dirsrv@UNIX-CO-ORG-AU comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'


cheers
L.  
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] FreeIPA AD Trust

[Andrew Meyer]

So then should I say yes to continue?  I don't have samba configured on here.  
Its just running FreeIPA... 

On Wednesday, January 20, 2016 3:14 PM, Alexander Bokovoy 
 wrote:
 
 

 On Wed, 20 Jan 2016, Andrew Meyer wrote:
>So I'm getting this when trying to setup a trust between 2012r2 and FreeIPA on 
>CentOS 7.2 
>[user@asm-dns01 ~]$ sudo ipa-adtrust-install
I don't recommend running ipa-adtrust-install under sudo as you do. sudo
would keep some of user-related environment that is used by IPA
framework code to decide where user's cached session data is stored.

Use 'sudo -i' instead.

The rest of warnings and errors you've got are related to this
unexpected behavior.


-- 
/ Alexander Bokovoy


 
  -- 
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] IPA wont start, all services fail

[Simpson Lachlan]

> -Original Message-
> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
> Sent: Thursday, 21 January 2016 9:22 AM
> To: Simpson Lachlan
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] IPA wont start, all services fail
> 
> On Wed, 20 Jan 2016, Simpson Lachlan wrote:
> >> -Original Message-
> >> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
> >> Sent: Thursday, 21 January 2016 8:44 AM
> >> To: Simpson Lachlan
> >> Cc: tbor...@redhat.com; freeipa-users@redhat.com
> >> Subject: Re: [Freeipa-users] IPA wont start, all services fail
> >>
> >> On Wed, 20 Jan 2016, Simpson Lachlan wrote:
> >> >> -Original Message-
> >> >>
> >> >> Is there any coredump available with 389-ds crashing? I've asked
> >> >> you to use
> >> >> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes
> >> >> to
> >> enable coredumps for 389-ds in one of previous discussions, was it done?
> >> >> You seemed to get diverted to winbindd core (which was expected to
> >> >> coredump as 389-ds was not available), but if you see 389-ds
> >> >> disappearing in several hours without any logging, this means
> >> >> there was a crash and we'd like to see the coredump of it.
> >> >
> >> >Hi Alex,
> >> >
> >> >I did perform the "Debugging Crashes" steps when you asked, but
> >> >there are still no core dumps in /var/log/dirsrv/slapd-INSTANCENAME.
> >> Well, perhaps it takes longer to get a crash than what you are expecting.
> >>
> >> >> You can check also /var/log/audit/audit.log to see if there is a
> >> >> trace of a crash. It may take different ways but one crash type is 
> >> >> following:
> >> >
> >> >> type=ANOM_ABEND msg=audit(1453212583.746:2337): auid=4294967295
> >> >> uid=983
> >> >> gid=980 ses=4294967295 subj=system_u:system_r:dirsrv_t:s0
> >> >> pid=26079 comm="ns-slapd" exe="/usr/sbin/ns-slapd" sig=11
> >> >
> >> >There are no instances of ns-slap in the audit.log, there are a
> >> >dozen sig=11s, all of them relate to a "memory violation" in
> >> >httpd_t, and all references to dirsrv look like this:
> >> >
> >> >type=SERVICE_STOP msg=audit(1453174960.933:209): pid=1 uid=0
> >> >auid=4294967295 ses=4294967295 subj=kernel
> >> >msg='unit=dirsrv@UNIX-CO-ORG-AU comm="systemd"
> >> >exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
> >> >res=success'
> >> What are the memory violation for httpd_t? Can you show exact line
> >> from audit.log?
> >
> >
> >
> >type=ANOM_ABEND msg=audit(1452818553.235:5394): auid=4294967295
> uid=48
> >gid=48 ses=4294967295 subj=system_u:system_r:httpd_t:s0 pid=32704
> >comm="httpd" reason="memory violation" sig=11 type=ANOM_ABEND
> Ok, I see two problems above and they may be related to recently fixed issue 
> with
> python-cryptography's use of python-cffi. However, this issue should not 
> affect
> CentOS 7.2 as the broken python-cryptography code is not in RHEL 7.2 at all, 
> so
> I'm a bit puzzled.

Me too. I can't even give SIDs to the smb default group with 
ipa-adtrust-install --add-sids (as mentioned in another email thread this 
morning). 

I tried this bc it reflects an obvious solution to the problem I seem to have? 
That everything starts except smb, and ipa also fails as a result of smb 
failing.


Smb fails with the error 

smbd[18615]: [2016/01/21 08:32:37.519517,  0] 
ipa_sam.c:3654(get_fallback_group_sid)
smbd[18615]:   Missing mandatory attribute ipaNTSecurityIdentifier.
smbd[18615]: [2016/01/21 08:32:37.519572,  0] ipa_sam.c:4606(pdb_init_ipasam)
smbd[18615]:   Cannot find SID of fallback group.
smbd[18615]: [2016/01/21 08:32:37.519593,  0] 
../source3/passdb/pdb_interface.c:179(make_pdb_method_name)
smbd[18615]:   pdb backend 
ipasam:ldapi://%2fvar%2frun%2fslapd-UNIX-CO-ORG-AU.socket did not correctly 
init (error was NT_STATUS_INVALID_PARAMETER)
systemd[1]: smb.service: main process exited, code=exited, status=1/FAILURE
systemd[1]: Failed to start Samba SMB Daemon.


I know I keep coming back to this, but it really does seem to be the error that 
I am seeing most often.

Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] IPA wont start, all services fail

[Alexander Bokovoy]

On Wed, 20 Jan 2016, Simpson Lachlan wrote:

-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com]
Sent: Thursday, 21 January 2016 8:44 AM
To: Simpson Lachlan
Cc: tbor...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] IPA wont start, all services fail

On Wed, 20 Jan 2016, Simpson Lachlan wrote:
>> -Original Message-
>>
>> Is there any coredump available with 389-ds crashing? I've asked you
>> to use
>> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes to
enable coredumps for 389-ds in one of previous discussions, was it done?
>> You seemed to get diverted to winbindd core (which was expected to
>> coredump as 389-ds was not available), but if you see 389-ds
>> disappearing in several hours without any logging, this means there
>> was a crash and we'd like to see the coredump of it.
>
>Hi Alex,
>
>I did perform the "Debugging Crashes" steps when you asked, but there
>are still no core dumps in /var/log/dirsrv/slapd-INSTANCENAME.
Well, perhaps it takes longer to get a crash than what you are expecting.

>> You can check also /var/log/audit/audit.log to see if there is a
>> trace of a crash. It may take different ways but one crash type is following:
>
>> type=ANOM_ABEND msg=audit(1453212583.746:2337): auid=4294967295
>> uid=983
>> gid=980 ses=4294967295 subj=system_u:system_r:dirsrv_t:s0 pid=26079
>> comm="ns-slapd" exe="/usr/sbin/ns-slapd" sig=11
>
>There are no instances of ns-slap in the audit.log, there are a dozen
>sig=11s, all of them relate to a "memory violation" in httpd_t, and all
>references to dirsrv look like this:
>
>type=SERVICE_STOP msg=audit(1453174960.933:209): pid=1 uid=0
>auid=4294967295 ses=4294967295 subj=kernel
>msg='unit=dirsrv@UNIX-CO-ORG-AU comm="systemd"
>exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
>res=success'
What are the memory violation for httpd_t? Can you show exact line from
audit.log?




type=ANOM_ABEND msg=audit(1452818553.235:5394): auid=4294967295 uid=48 gid=48 ses=4294967295 
subj=system_u:system_r:httpd_t:s0 pid=32704 comm="httpd" reason="memory 
violation" sig=11
type=ANOM_ABEND msg=audit(1452818553.258:5395): auid=4294967295 uid=48 gid=48 ses=4294967295 
subj=system_u:system_r:httpd_t:s0 pid=32707 comm="httpd" reason="memory 
violation" sig=11
type=ANOM_ABEND msg=audit(1452962463.319:1390): auid=4294967295 uid=991 gid=987 ses=4294967295 
subj=kernel pid=12939 comm="httpd" reason="memory violation" sig=11
type=ANOM_ABEND msg=audit(1453071013.594:2471): auid=0 uid=0 gid=0 ses=202 subj=kernel pid=17888 
comm="systemd-tty-ask" reason="memory violation" sig=11
type=ANOM_ABEND msg=audit(1453161444.878:732): auid=4294967295 uid=48 gid=48 ses=4294967295 
subj=kernel pid=15219 comm="httpd" reason="memory violation" sig=11
type=ANOM_ABEND msg=audit(1453162831.092:807): auid=4294967295 uid=991 gid=987 ses=4294967295 
subj=kernel pid=17619 comm="httpd" reason="memory violation" sig=11
type=ANOM_ABEND msg=audit(1453167608.043:869): auid=4294967295 uid=48 gid=48 ses=4294967295 
subj=kernel pid=19188 comm="httpd" reason="memory violation" sig=11
type=ANOM_ABEND msg=audit(1453167608.281:870): auid=4294967295 uid=48 gid=48 ses=4294967295 
subj=kernel pid=19191 comm="httpd" reason="memory violation" sig=11
type=ANOM_ABEND msg=audit(1453174424.305:167): auid=4294967295 uid=48 gid=48 ses=4294967295 
subj=kernel pid=13075 comm="httpd" reason="memory violation" sig=11
type=ANOM_ABEND msg=audit(1453174424.337:168): auid=4294967295 uid=48 gid=48 ses=4294967295 
subj=kernel pid=13078 comm="httpd" reason="memory violation" sig=11
type=ANOM_ABEND msg=audit(1453174959.183:205): auid=4294967295 uid=991 gid=987 ses=4294967295 
subj=kernel pid=14220 comm="httpd" reason="memory violation" sig=11
type=ANOM_ABEND msg=audit(1453174959.183:206): auid=4294967295 uid=991 gid=987 ses=4294967295 
subj=kernel pid=14203 comm="httpd" reason="memory violation" sig=11
type=ANOM_ABEND msg=audit(1453325222.755:1226): auid=4294967295 uid=48 gid=48 ses=4294967295 
subj=kernel pid=14716 comm="httpd" reason="memory violation" sig=11
type=ANOM_ABEND msg=audit(1453325222.825:1227): auid=4294967295 uid=48 gid=48 ses=4294967295 
subj=kernel pid=14713 comm="httpd" reason="memory violation" sig=11
type=ANOM_ABEND msg=audit(1453325558.988:1244): auid=4294967295 uid=991 gid=987 ses=4294967295 
subj=kernel pid=18340 comm="httpd" reason="memory violation" sig=11
type=ANOM_ABEND msg=audit(1453325558.988:1245): auid=4294967295 uid=991 gid=987 ses=4294967295 
subj=kernel pid=18357 comm="httpd" reason="memory violation" sig=11

Ok, I see two problems above and they may be related to recently fixed
issue with python-cryptography's use of python-cffi. However, this issue
should not affect CentOS 7.2 as the broken python-cryptography code is
not in RHEL 7.2 at all, so I'm a bit puzzled.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to 

Re: [Freeipa-users] IE10 Dialogs close on Enter keypress

[Petr Vobornik]

On 01/07/2016 06:11 AM, Jim Groffen wrote:

Hello,

I found that when running FreeIPA Web UI on IE10 that modal dialogs close
when enter is pressed. Normal functionality is to 'submit' the dialog on an
enter keypress.

I found a solution by adding a type="button" attribute to the close button
of the dialog (in /install/ui/src/freeipa/dialog.js).

I have tested on recent Chrome, IE and Firefox versions as well as on IE10.
Seems to be no side-effects.

Attached is a patch showing the change I made. Apologies if the patch isn't
formatted correctly.

Regards,

Jim G



Thanks for the patch. Looks good - ACK

was pushed to master branch

https://fedorahosted.org/freeipa/changeset/f5f5c8c603e95d246d2cde92f56959fedba4666d
--
Petr Vobornik

--
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] FreeIPA AD Trust

[Alexander Bokovoy]

On Wed, 20 Jan 2016, Andrew Meyer wrote:

So then should I say yes to continue?  I don't have samba configured on here.  
Its just running FreeIPA...

Yes, but please do follow my suggestion when running
ipa-adtrust-install.

--
/ Alexander Bokovoy

--
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] IPA wont start, all services fail

[Alexander Bokovoy]

On Wed, 20 Jan 2016, Simpson Lachlan wrote:

-Original Message-

Is there any coredump available with 389-ds crashing? I've asked you to use
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes to enable
coredumps for 389-ds in one of previous discussions, was it done?
You seemed to get diverted to winbindd core (which was expected to coredump as
389-ds was not available), but if you see 389-ds disappearing in several hours
without any logging, this means there was a crash and we'd like to see the
coredump of it.


Hi Alex,

I did perform the "Debugging Crashes" steps when you asked, but there
are still no core dumps in /var/log/dirsrv/slapd-INSTANCENAME.

Well, perhaps it takes longer to get a crash than what you are
expecting.


You can check also /var/log/audit/audit.log to see if there is a trace of a 
crash. It
may take different ways but one crash type is following:



type=ANOM_ABEND msg=audit(1453212583.746:2337): auid=4294967295
uid=983
gid=980 ses=4294967295 subj=system_u:system_r:dirsrv_t:s0 pid=26079
comm="ns-slapd" exe="/usr/sbin/ns-slapd" sig=11


There are no instances of ns-slap in the audit.log, there are a dozen
sig=11s, all of them relate to a "memory violation" in httpd_t, and all
references to dirsrv look like this:

type=SERVICE_STOP msg=audit(1453174960.933:209): pid=1 uid=0
auid=4294967295 ses=4294967295 subj=kernel
msg='unit=dirsrv@UNIX-CO-ORG-AU comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=success'

What are the memory violation for httpd_t? Can you show exact line from
audit.log?
--
/ Alexander Bokovoy

--
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] IPA wont start, all services fail

[Simpson Lachlan]

> -Original Message-
> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
> Sent: Thursday, 21 January 2016 8:44 AM
> To: Simpson Lachlan
> Cc: tbor...@redhat.com; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] IPA wont start, all services fail
> 
> On Wed, 20 Jan 2016, Simpson Lachlan wrote:
> >> -Original Message-
> >>
> >> Is there any coredump available with 389-ds crashing? I've asked you
> >> to use
> >> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes to
> enable coredumps for 389-ds in one of previous discussions, was it done?
> >> You seemed to get diverted to winbindd core (which was expected to
> >> coredump as 389-ds was not available), but if you see 389-ds
> >> disappearing in several hours without any logging, this means there
> >> was a crash and we'd like to see the coredump of it.
> >
> >Hi Alex,
> >
> >I did perform the "Debugging Crashes" steps when you asked, but there
> >are still no core dumps in /var/log/dirsrv/slapd-INSTANCENAME.
> Well, perhaps it takes longer to get a crash than what you are expecting.
> 
> >> You can check also /var/log/audit/audit.log to see if there is a
> >> trace of a crash. It may take different ways but one crash type is 
> >> following:
> >
> >> type=ANOM_ABEND msg=audit(1453212583.746:2337): auid=4294967295
> >> uid=983
> >> gid=980 ses=4294967295 subj=system_u:system_r:dirsrv_t:s0 pid=26079
> >> comm="ns-slapd" exe="/usr/sbin/ns-slapd" sig=11
> >
> >There are no instances of ns-slap in the audit.log, there are a dozen
> >sig=11s, all of them relate to a "memory violation" in httpd_t, and all
> >references to dirsrv look like this:
> >
> >type=SERVICE_STOP msg=audit(1453174960.933:209): pid=1 uid=0
> >auid=4294967295 ses=4294967295 subj=kernel
> >msg='unit=dirsrv@UNIX-CO-ORG-AU comm="systemd"
> >exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
> >res=success'
> What are the memory violation for httpd_t? Can you show exact line from
> audit.log?



type=ANOM_ABEND msg=audit(1452818553.235:5394): auid=4294967295 uid=48 gid=48 
ses=4294967295 subj=system_u:system_r:httpd_t:s0 pid=32704 comm="httpd" 
reason="memory violation" sig=11
type=ANOM_ABEND msg=audit(1452818553.258:5395): auid=4294967295 uid=48 gid=48 
ses=4294967295 subj=system_u:system_r:httpd_t:s0 pid=32707 comm="httpd" 
reason="memory violation" sig=11
type=ANOM_ABEND msg=audit(1452962463.319:1390): auid=4294967295 uid=991 gid=987 
ses=4294967295 subj=kernel pid=12939 comm="httpd" reason="memory violation" 
sig=11
type=ANOM_ABEND msg=audit(1453071013.594:2471): auid=0 uid=0 gid=0 ses=202 
subj=kernel pid=17888 comm="systemd-tty-ask" reason="memory violation" sig=11
type=ANOM_ABEND msg=audit(1453161444.878:732): auid=4294967295 uid=48 gid=48 
ses=4294967295 subj=kernel pid=15219 comm="httpd" reason="memory violation" 
sig=11
type=ANOM_ABEND msg=audit(1453162831.092:807): auid=4294967295 uid=991 gid=987 
ses=4294967295 subj=kernel pid=17619 comm="httpd" reason="memory violation" 
sig=11
type=ANOM_ABEND msg=audit(1453167608.043:869): auid=4294967295 uid=48 gid=48 
ses=4294967295 subj=kernel pid=19188 comm="httpd" reason="memory violation" 
sig=11
type=ANOM_ABEND msg=audit(1453167608.281:870): auid=4294967295 uid=48 gid=48 
ses=4294967295 subj=kernel pid=19191 comm="httpd" reason="memory violation" 
sig=11
type=ANOM_ABEND msg=audit(1453174424.305:167): auid=4294967295 uid=48 gid=48 
ses=4294967295 subj=kernel pid=13075 comm="httpd" reason="memory violation" 
sig=11
type=ANOM_ABEND msg=audit(1453174424.337:168): auid=4294967295 uid=48 gid=48 
ses=4294967295 subj=kernel pid=13078 comm="httpd" reason="memory violation" 
sig=11
type=ANOM_ABEND msg=audit(1453174959.183:205): auid=4294967295 uid=991 gid=987 
ses=4294967295 subj=kernel pid=14220 comm="httpd" reason="memory violation" 
sig=11
type=ANOM_ABEND msg=audit(1453174959.183:206): auid=4294967295 uid=991 gid=987 
ses=4294967295 subj=kernel pid=14203 comm="httpd" reason="memory violation" 
sig=11
type=ANOM_ABEND msg=audit(1453325222.755:1226): auid=4294967295 uid=48 gid=48 
ses=4294967295 subj=kernel pid=14716 comm="httpd" reason="memory violation" 
sig=11
type=ANOM_ABEND msg=audit(1453325222.825:1227): auid=4294967295 uid=48 gid=48 
ses=4294967295 subj=kernel pid=14713 comm="httpd" reason="memory violation" 
sig=11
type=ANOM_ABEND msg=audit(1453325558.988:1244): auid=4294967295 uid=991 gid=987 
ses=4294967295 subj=kernel pid=18340 comm="httpd" reason="memory violation" 
sig=11
type=ANOM_ABEND msg=audit(1453325558.988:1245): auid=4294967295 uid=991 gid=987 
ses=4294967295 subj=kernel pid=18357 comm="httpd" reason="memory violation" 
sig=11

cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this 

Re: [Freeipa-users] IPA wont start, all services fail

[Alexander Bokovoy]

On Tue, 19 Jan 2016, Simpson Lachlan wrote:

-Original Message-



From: Alexander Bokovoy [mailto:aboko...@redhat.com]
Let's start from the beginning:

 - What distribution you are running?


Centos, Linux release 7.2.1511 (Core)



 - What IPA packages are installed?


[root@vmts-linuxidm ~]# yum list installed | grep ipa
ipa-admintools.x86_64  4.2.0-15.el7.centos.3   @updates
ipa-client.x86_64  4.2.0-15.el7.centos.3   @updates
ipa-python.x86_64  4.2.0-15.el7.centos.3   @updates
ipa-server.x86_64  4.2.0-15.el7.centos.3   @updates
ipa-server-dns.x86_64  4.2.0-15.el7.centos.3   @updates
ipa-server-trust-ad.x86_64 4.2.0-15.el7.centos.3   @updates
libipa_hbac.x86_64 1.13.0-40.el7_2.1   @updates
python-iniparse.noarch 0.4-9.el7   @anaconda
python-libipa_hbac.x86_64  1.13.0-40.el7_2.1   @updates
sssd-ipa.x86_641.13.0-40.el7_2.1   @updates


 - What 389-ds-base package is installed?


[root@vmts-linuxidm ~]# yum list installed | grep 389
389-admin.x86_64   1.1.38-1.el7@epel
389-adminutil.x86_64   1.1.21-2.el7@epel
389-adminutil-devel.x86_64 1.1.21-2.el7@epel
389-ds-base.x86_64 1.3.4.0-21.el7_2@updates
389-ds-base-debuginfo.x86_64   1.3.4.0-21.el7_2
@base-debuginfo
389-ds-base-libs.x86_641.3.4.0-21.el7_2@updates



 - What slapi-nis package is installed?


slapi-nis.x86_64   0.54-6.el7_2@updates

Ok, thanks. I've looked at 4.2.0-15.el7.centos.3, it only has debranding
patch (change from Red Hat branding to a plain one and adding of CentOS
'OS'), this shouldn't be a problem.

Is there any coredump available with 389-ds crashing? I've asked you to
use http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes to
enable coredumps for 389-ds in one of previous discussions, was it done?
You seemed to get diverted to winbindd core (which was expected to
coredump as 389-ds was not available), but if you see 389-ds
disappearing in several hours without any logging, this means there was
a crash and we'd like to see the coredump of it.

You can check also /var/log/audit/audit.log to see if there is a trace
of a crash. It may take different ways but one crash type is following:

type=ANOM_ABEND msg=audit(1453212583.746:2337): auid=4294967295 uid=983
gid=980 ses=4294967295 subj=system_u:system_r:dirsrv_t:s0 pid=26079
comm="ns-slapd" exe="/usr/sbin/ns-slapd" sig=11

it is a crash with SIGSEGV (segmentation fault, a.k.a. null-pointer
dereference).

Thierry, is there any known issue with 1.3.4.0-21.el7_2 that might cause
389-ds crash?

--
/ Alexander Bokovoy

--
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] ns-slapd using all CPU ressources

[Domingues Luis Filipe]

Hi,

Thanks, this is actually the version we are running.

Do you have a link to the ticket? I tried to find it on the bug tracer but I 
have always a ticket not found.

Luis

-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Ludwig Krispenz
Sent: mardi 19 janvier 2016 16:59
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] ns-slapd using all CPU ressources

Hi,
if you are running 389-ds 1.3.4+ you may hit, ticket #48379. It id fixed and a 
new build is in preparation

Ludwig

On 01/19/2016 03:39 PM, Domingues Luis Filipe wrote:
> Hi,
>
> Reading the backtrace I have 30 threads with the same stack:
>
> Thread 6 (Thread 0x7f572efed700 (LWP 1335)):
> #0  0x7f576f80a877 in sched_yield () from /lib64/libc.so.6 No 
> symbol table info available.
> #1  0x7f577014df28 in PR_Sleep () from /lib64/libnspr4.so No 
> symbol table info available.
> #2  0x55c939e9e7c7 in connection_threadmain () No symbol table 
> info available.
> #3  0x7f577014d5cb in _pt_root () from /lib64/libnspr4.so No 
> symbol table info available.
> #4  0x7f576faec60a in start_thread () from /lib64/libpthread.so.0 
> No symbol table info available.
> #5  0x7f576f826a4d in clone () from /lib64/libc.so.6 No symbol 
> table info available.
>
> While the other instance which is running fine, almost all threads are 
> waiting on a cond_wait, with thise stack:
> Thread 48 (Thread 0x7fced53a9700 (LWP 1871)):
> #0  0x7fcee9269b10 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0 No symbol table info available.
> #1  0x7fcee98bfcf0 in PR_WaitCondVar () from /lib64/libnspr4.so No 
> symbol table info available.
> #2  0x7fceeb7172c8 in slapi_wait_condvar () from 
> /usr/lib64/dirsrv/libslapd.so.0 No symbol table info available.
> #3  0x7fcee127a67e in cos_cache_wait_on_change () from 
> /usr/lib64/dirsrv/plugins/libcos-plugin.so
> No symbol table info available.
> #4  0x7fcee98c55cb in _pt_root () from /lib64/libnspr4.so No 
> symbol table info available.
> #5  0x7fcee926460a in start_thread () from /lib64/libpthread.so.0 
> No symbol table info available.
> #6  0x7fcee8f9ea4d in clone () from /lib64/libc.so.6 No symbol 
> table info available.
>
> Luis.
> 
> From: Rob Crittenden [rcrit...@redhat.com]
> Sent: Friday, January 15, 2016 3:51 PM
> To: Domingues Luis Filipe; freeipa-users@redhat.com
> Cc: Aviolat Romain
> Subject: Re: [Freeipa-users] ns-slapd using all CPU ressources
>
> Domingues Luis Filipe wrote:
>> Hi all,
>>
>> On our infra, we have two machines running Fedora with FreeIPA installed.
>>
>> we have an issue with ns-slapd using 100% of CPU after a while. If we 
>> restart the service, it starts to use all CPU resources after one day.
>>
>> Outpute of the command strace -c -p  running for 4 minutes is:
>>
>> % time seconds  usecs/call callserrors syscall
>> -- --- --- - - 
>>   99.80  229.603633   11247 20415   poll
>>0.150.340032  10 32983 4 futex
>>0.050.114068  114068 1   restart_syscall
>>0.000.003464   0 20420 20416 getpeername
>>0.000.002752   0 20416   clock_gettime
>>0.000.001920   0  9840   read
>>0.000.000205   545   close
>>0.000.36   222   access
>>0.000.17   122   open
>>0.000.16   124   accept
>>0.000.12   045   setsockopt
>>0.000.07   022   fstat
>>0.000.00   022   stat
>>0.000.00   0 1   sendto
>>0.000.00   024   getsockname
>>0.000.00   0 4   getsockopt
>>0.000.00   070   fcntl
>>0.000.00   022   gettimeofday
>> -- --- --- - - 
>> 100.00  230.066162104398 20420 total
>>
>>
>>
>> Plus we looked at the syscalls using FTrace:
>>
>> ns-slapd-7963  [000]  4063846.395630: sys_sched_yield()
>> ns-slapd-7956  [000]  4063846.395631: sys_sched_yield -> 0x0
>> ns-slapd-7956  [000]  4063846.395632: sys_sched_yield()
>> ns-slapd-7973  [000]  4063846.395633: sys_sched_yield -> 0x0
>> ns-slapd-7973  [000]  4063846.395634: sys_sched_yield()
>> ns-slapd-7965  [000]  4063846.395635: sys_sched_yield -> 0x0
>> ns-slapd-7965  [000]  4063846.395637: sys_sched_yield()
>> ns-slapd-7963  [000]  4063846.395637: sys_sched_yield -> 0x0
>> ns-slapd-7963  [000]  4063846.395639: sys_sched_yield()
>> ns-slapd-7956  [000]  

Re: [Freeipa-users] ns-slapd using all CPU ressources

[Martin Basti]

On 20.01.2016 09:29, Domingues Luis Filipe wrote:

Hi,

Thanks, this is actually the version we are running.

Do you have a link to the ticket? I tried to find it on the bug tracer but I 
have always a ticket not found.

Luis

Link to DS ticket

https://fedorahosted.org/389/ticket/48379



-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Ludwig Krispenz
Sent: mardi 19 janvier 2016 16:59
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] ns-slapd using all CPU ressources

Hi,
if you are running 389-ds 1.3.4+ you may hit, ticket #48379. It id fixed and a 
new build is in preparation

Ludwig

On 01/19/2016 03:39 PM, Domingues Luis Filipe wrote:

Hi,

Reading the backtrace I have 30 threads with the same stack:

Thread 6 (Thread 0x7f572efed700 (LWP 1335)):
#0  0x7f576f80a877 in sched_yield () from /lib64/libc.so.6 No
symbol table info available.
#1  0x7f577014df28 in PR_Sleep () from /lib64/libnspr4.so No
symbol table info available.
#2  0x55c939e9e7c7 in connection_threadmain () No symbol table
info available.
#3  0x7f577014d5cb in _pt_root () from /lib64/libnspr4.so No
symbol table info available.
#4  0x7f576faec60a in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#5  0x7f576f826a4d in clone () from /lib64/libc.so.6 No symbol
table info available.

While the other instance which is running fine, almost all threads are waiting 
on a cond_wait, with thise stack:
Thread 48 (Thread 0x7fced53a9700 (LWP 1871)):
#0  0x7fcee9269b10 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0 No symbol table info available.
#1  0x7fcee98bfcf0 in PR_WaitCondVar () from /lib64/libnspr4.so No
symbol table info available.
#2  0x7fceeb7172c8 in slapi_wait_condvar () from
/usr/lib64/dirsrv/libslapd.so.0 No symbol table info available.
#3  0x7fcee127a67e in cos_cache_wait_on_change () from
/usr/lib64/dirsrv/plugins/libcos-plugin.so
No symbol table info available.
#4  0x7fcee98c55cb in _pt_root () from /lib64/libnspr4.so No
symbol table info available.
#5  0x7fcee926460a in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#6  0x7fcee8f9ea4d in clone () from /lib64/libc.so.6 No symbol
table info available.

Luis.

From: Rob Crittenden [rcrit...@redhat.com]
Sent: Friday, January 15, 2016 3:51 PM
To: Domingues Luis Filipe; freeipa-users@redhat.com
Cc: Aviolat Romain
Subject: Re: [Freeipa-users] ns-slapd using all CPU ressources

Domingues Luis Filipe wrote:

Hi all,

On our infra, we have two machines running Fedora with FreeIPA installed.

we have an issue with ns-slapd using 100% of CPU after a while. If we
restart the service, it starts to use all CPU resources after one day.

Outpute of the command strace -c -p  running for 4 minutes is:

% time seconds  usecs/call callserrors syscall
-- --- --- - - 
   99.80  229.603633   11247 20415   poll
0.150.340032  10 32983 4 futex
0.050.114068  114068 1   restart_syscall
0.000.003464   0 20420 20416 getpeername
0.000.002752   0 20416   clock_gettime
0.000.001920   0  9840   read
0.000.000205   545   close
0.000.36   222   access
0.000.17   122   open
0.000.16   124   accept
0.000.12   045   setsockopt
0.000.07   022   fstat
0.000.00   022   stat
0.000.00   0 1   sendto
0.000.00   024   getsockname
0.000.00   0 4   getsockopt
0.000.00   070   fcntl
0.000.00   022   gettimeofday
-- --- --- - - 
100.00  230.066162104398 20420 total



Plus we looked at the syscalls using FTrace:

ns-slapd-7963  [000]  4063846.395630: sys_sched_yield()
ns-slapd-7956  [000]  4063846.395631: sys_sched_yield -> 0x0
ns-slapd-7956  [000]  4063846.395632: sys_sched_yield()
ns-slapd-7973  [000]  4063846.395633: sys_sched_yield -> 0x0
ns-slapd-7973  [000]  4063846.395634: sys_sched_yield()
ns-slapd-7965  [000]  4063846.395635: sys_sched_yield -> 0x0
ns-slapd-7965  [000]  4063846.395637: sys_sched_yield()
ns-slapd-7963  [000]  4063846.395637: sys_sched_yield -> 0x0
ns-slapd-7963  [000]  4063846.395639: sys_sched_yield()
ns-slapd-7956  [000]  4063846.395640: sys_sched_yield -> 0x0
ns-slapd-7956  [000]  4063846.395641: sys_sched_yield()

Re: [Freeipa-users] IPA wont start, all services fail

[thierry bordaz]

On 01/20/2016 09:20 AM, Alexander Bokovoy wrote:

On Tue, 19 Jan 2016, Simpson Lachlan wrote:

-Original Message-



From: Alexander Bokovoy [mailto:aboko...@redhat.com]
Let's start from the beginning:

 - What distribution you are running?


Centos, Linux release 7.2.1511 (Core)



 - What IPA packages are installed?


[root@vmts-linuxidm ~]# yum list installed | grep ipa
ipa-admintools.x86_64 4.2.0-15.el7.centos.3   @updates
ipa-client.x86_64 4.2.0-15.el7.centos.3   @updates
ipa-python.x86_64 4.2.0-15.el7.centos.3   @updates
ipa-server.x86_64 4.2.0-15.el7.centos.3   @updates
ipa-server-dns.x86_64 4.2.0-15.el7.centos.3   @updates
ipa-server-trust-ad.x86_64 4.2.0-15.el7.centos.3   @updates
libipa_hbac.x86_64 1.13.0-40.el7_2.1   @updates
python-iniparse.noarch 0.4-9.el7   @anaconda
python-libipa_hbac.x86_64 1.13.0-40.el7_2.1   @updates
sssd-ipa.x86_64 1.13.0-40.el7_2.1   @updates


 - What 389-ds-base package is installed?


[root@vmts-linuxidm ~]# yum list installed | grep 389
389-admin.x86_64 1.1.38-1.el7@epel
389-adminutil.x86_64 1.1.21-2.el7@epel
389-adminutil-devel.x86_64 1.1.21-2.el7@epel
389-ds-base.x86_64 1.3.4.0-21.el7_2@updates
389-ds-base-debuginfo.x86_64 1.3.4.0-21.el7_2
@base-debuginfo

389-ds-base-libs.x86_64 1.3.4.0-21.el7_2@updates



 - What slapi-nis package is installed?


slapi-nis.x86_64 0.54-6.el7_2@updates

Ok, thanks. I've looked at 4.2.0-15.el7.centos.3, it only has debranding
patch (change from Red Hat branding to a plain one and adding of CentOS
'OS'), this shouldn't be a problem.

Is there any coredump available with 389-ds crashing? I've asked you to
use http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes to
enable coredumps for 389-ds in one of previous discussions, was it done?
You seemed to get diverted to winbindd core (which was expected to
coredump as 389-ds was not available), but if you see 389-ds
disappearing in several hours without any logging, this means there was
a crash and we'd like to see the coredump of it.

You can check also /var/log/audit/audit.log to see if there is a trace
of a crash. It may take different ways but one crash type is following:

type=ANOM_ABEND msg=audit(1453212583.746:2337): auid=4294967295 uid=983
gid=980 ses=4294967295 subj=system_u:system_r:dirsrv_t:s0 pid=26079
comm="ns-slapd" exe="/usr/sbin/ns-slapd" sig=11

it is a crash with SIGSEGV (segmentation fault, a.k.a. null-pointer
dereference).

Thierry, is there any known issue with 1.3.4.0-21.el7_2 that might cause
389-ds crash?



No known crash are fixed between 1.3.4.0-21.el7_2 and 1.3.4.0-24.el7_2.
We really need a core/pstack to match any known crash. Does it occur 
frequently, so you may wait for the next occurrence to get a core/pstack.


thanks
thierry

--
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] idoverride-add gives incorrect, inconsistant results?

[Jakub Hrozek]

On Wed, Jan 20, 2016 at 09:15:47AM +1100, Lachlan Musicman wrote:
> 1.13.0

I suspect it's 7.2, then. Did you alrady update to the latest available
version (1.13.0-41)? If yes, do you have logfiles?

See https://fedorahosted.org/sssd/wiki/Troubleshooting

-- 
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] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists

[Petr Vobornik]

On 01/20/2016 12:31 AM, Rob Crittenden wrote:

Nathan Peters wrote:

[18/Jan/2016:09:28:33 -0800] conn=18732 op=10 ADD 
dn="cn=replica,cn=dc\3Ddev-globalrelay\2Cdc\3Dnet,cn=mapping tree,cn=config"
  [18/Jan/2016:09:28:33 -0800] conn=18732 op=10 RESULT err=68 tag=105 
nentries=0 etime=0
  [18/Jan/2016:09:28:33 -0800] conn=18732 op=11 UNBIND

Do you mean that log entry ^?  I am seeing that entry on dc2-ipa-dev-nvan, the 
host that dc1-ipa-dev-van is contacting as its master when we attempt the 
ipa-replica-install.  Look through my earlier posts in this thread for a full 
log.


Don't assume we have any idea what your hostnames mean, especially when
they differ only by a few characters. It is good to list them but I'd
also suggest you use terms like existing master and new server or
something so we can distinguish the players without having to slowly
parse every name.


Yes, of course that DN exists on all my masters.  With a 3 way replication it would have 
to exist because the current master is replicating to 2 other masters.  Here is the 
ldapsearch for all 3 existing hosts showing that DN 
(dn="cn=replica,cn=dc\3Ddev-globalrelay\2Cdc\3Dnet,cn=mapping tree,cn=config") 
which is apparently failing to be added because it already exists on all my hosts.


The important thing here is that cn=config is not replicated. It is
configured on each master during replica setup, exactly where it is
failing for you. Given that it is failing on ANOTHER server says a lot.

It is failing, I think in part, because this search on the remote master
is returning no entries:

[18/Jan/2016:09:28:33 -0800] conn=18732 op=9 SRCH
base="cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config"
scope=0 filter="(objectClass=*)" attrs=ALL
[18/Jan/2016:09:28:33 -0800] conn=18732 op=9 RESULT err=0 tag=101
nentries=0 etime=0


IMO this is the culprit. It should return the entry if it is in fact there.



Right after this is the ADD which fails with err=68 which means that in
fact, it does exist.

I'm not sure why this is happening. I don't immediately see why a
NotFound would be raised in this case but I'm guessing it is. It would
be interesting to walk through the code using the python debugger, pdb.

In any case the duplicate entry is due to the replica setup code trying
to configure the remote master for basic replication and this has
already been done.


Yes the replica code works as expected.

Next step is to investigate why the search returns nothing. ACI issue? 
Weird DB state?


Can other user fetch it? E.g. admin?

If so wow does "cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping 
tree,cn=config" on the master server looks like?

--
Petr Vobornik

--
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] Fwd: Creating Trusts with AD - (RH#878168, FIPA#3266)

[Anon Lister]

So I had the same problem. For me it ended up being that some attribute was
not created correctly in 389 using the instructions in the guide. I don't
remember what it was off the top of my head. Something about a default user
or group SID I think. Had to turn samba logging up. Eventually it shows the
attribute it is failing on. I ended up manually adding it with vildap and
it worked fine after that. If noone else gets it I'll poke around and see
if I can find what it was, took me several hours to debug due to the
somewhat misleading error message.
On Jan 19, 2016 1:37 PM, "Jon"  wrote:

> Hello,
>
> While following the guide on setting up FreeIPA with AD
> , I got to the
> step where I'm adding the AD trust to FreeIPA but I receive an error:
>
>   >> Active Directory domain administrator's password:
>   >> ipa: ERROR: CIFS server communication error: code "-1073741801",
>   >> message "Memory allocation error" (both may be "None")
>
> Thinking that the error was what was stated (my VM at the time only had
> 1GB of ram), I shutdown my VM (memory hot add was not enabled in VMware, it
> is now), bumped the RAM to 4GB, and booted the VM.
>
> Upon running the same command after reboot I received an error:
>
>   >> ipa: ERROR: did not receive Kerberos credentials
>
> kinit admin is also reporting an error:
>
>   >>  kinit: Cannot contact any KDC for realm 'myrealm'  while getting
> initial credentials
>
> trying to start FreeIPA in debug mode identified the samba service as at
> fault.
>
>   >> Jan 19 10:19:50 myfreeipaserver smbd[3676]:   kerberos error:
> code=-1765328203, message=Keytab contains no suitable keys for cifs/
> myfreeipaser...@sub.domain.mydomain.com
>   >> Jan 19 10:19:51 myfreeipaserver smbd[3676]: [2016/01/19
> 10:19:51.261648,  0] ipa_sam.c:4520(pdb_init_ipasam)
>   >> Jan 19 10:19:51 myfreeipaserver smbd[3676]:   Failed to get base DN.
>   >> Jan 19 10:19:51 myfreeipaserver smbd[3676]: [2016/01/19
> 10:19:51.262675,  0]
> ../source3/passdb/pdb_interface.c:179(make_pdb_method_name)
>   >> Jan 19 10:19:51 myfreeipaserver smbd[3676]:   pdb backend
> ipasam:ldapi://%2fvar%2frun%2fslapd-SUB-DOMAIN-MYDOMAIN-COM.socket did not
> correctly init (error was NT_STATUS_UNSUCCESSFUL)
>
> Googling for these errors turned up a few similar threads but none of the
> solutions seemed to work and all signs pointed to AD integration as the
> culprit...
>
> So I did what any good sysadmin would do and forced freeipa to start while
> ignoring any failures.  Every service except samba starts without issue.
>
> So I tried my trust connection again, and received the same error,
>
>   >> Active Directory domain administrator's password:
>   >> ipa: ERROR: CIFS server communication error: code "-1073741801",
>   >> message "Memory allocation error" (both may be "None")
>
> Which brought me to googling two bug reports opened on this exact issue:
>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=878168
> >> https://fedorahosted.org/freeipa/ticket/3266
>
> Both of these bug reports indicate there's an upstream bug in Samba, the
> bug has been closed and reopened at least once.  I did add the AD servers
> to /etc/hosts and rebooted the server.  I have to go through the same
> process of forcing freeipa to start after the server rebooted... However, I
> received the same error message.
>
> While the bug report is currently closed, I seem to be experiencing the
> same issues...
>
> Given this bug report, can you please answer me these questions three:
>
> 1)  Given the issues with Samba starting after reboot, is this bug report
> actually what's wrong or is the error message when trying to create a trust
> a red herring and it's actually samba that's the problem?
> 2)  Does this bug report mean that trusts between FreeIPA and AD are
> broken and can not be established until the upstream bug in Samba is fixed?
> 3)  Is there a workaround?  (as adding the domain controllers to
> /etc/hosts with IPv4 address does not appear to work)
>
> System Stats:
> - AD Server:  Win2k8R2
> - FreeIPA server:
>
> >> CentOS Linux release 7.2.1511 (Core)
>
>
> >> # uname -a
> >> Linux myserver 3.10.0-327.4.4.el7.x86_64 #1 SMP Tue Jan 5 16:07:00 UTC
> 2016 x86_64 x86_64 x86_64 GNU/Linux
>
> >> # rpm -qa | grep ipa
> >> python-libipa_hbac-1.13.0-40.el7_2.1.x86_64
> >> ipa-server-4.2.0-15.el7.centos.3.x86_64
> >> ipa-server-dns-4.2.0-15.el7.centos.3.x86_64
> >> python-iniparse-0.4-9.el7.noarch
> >> libipa_hbac-1.13.0-40.el7_2.1.x86_64
> >> sssd-ipa-1.13.0-40.el7_2.1.x86_64
> >> ipa-python-4.2.0-15.el7.centos.3.x86_64
> >> ipa-client-4.2.0-15.el7.centos.3.x86_64
> >> ipa-server-trust-ad-4.2.0-15.el7.centos.3.x86_64
> >> ipa-admintools-4.2.0-15.el7.centos.3.x86_64
>
>
> I appreciate any help.  I've been trying to get FreeIPA going for a couple
> of weeks now and have run into nothing but frustrations.  The funny thing
> is, I've never 

Re: [Freeipa-users] Fwd: Creating Trusts with AD - (RH#878168, FIPA#3266)

[Alexander Bokovoy]

On Wed, 20 Jan 2016, Anon Lister wrote:

So I had the same problem. For me it ended up being that some attribute was
not created correctly in 389 using the instructions in the guide. I don't
remember what it was off the top of my head. Something about a default user
or group SID I think. Had to turn samba logging up. Eventually it shows the
attribute it is failing on. I ended up manually adding it with vildap and
it worked fine after that. If noone else gets it I'll poke around and see
if I can find what it was, took me several hours to debug due to the
somewhat misleading error message.

The message is the only thing we get from Samba Python libraries, so it
is as good as what we get.

Use
http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust
to produce debug output needed to find out where things happened.

If your setup lacks 'Default SMB Group' group with a SID
(ipaNTSecurityIdentifier attribute), run ipa-adtrust-install --add-sids.

ipa-adtrust-install can be re-run several times to fix missing parts. It
skips steps which were already done and only performs those that are
really needed.

However, if your base IPA deployment does not work, like in the Jon's
case, there is little reason to run any of ipa-adtrust-install or other
trust-related functions.

Additionally, DNS should be configured properly. ipa-adtrust-install
either automatically updates IPA DNS (if IPA manages the DNS zone) or
produces list of entries that should be added to the DNS zone whoever
manages it. This should not be overlooked -- when Active Directory
domain controller tries to validate the trust, it uses DNS SRV records
to find out IPA domain controllers ('trust controllers' in IPA speak,
the ones where ipa-adtrust-install was run) and only considers those
that are available via SRV records. If AD DC cannot find IPA DC via SRV
record, trust cannot be validated.


On Jan 19, 2016 1:37 PM, "Jon"  wrote:


Hello,

While following the guide on setting up FreeIPA with AD
, I got to the
step where I'm adding the AD trust to FreeIPA but I receive an error:

  >> Active Directory domain administrator's password:
  >> ipa: ERROR: CIFS server communication error: code "-1073741801",
  >> message "Memory allocation error" (both may be "None")

Thinking that the error was what was stated (my VM at the time only had
1GB of ram), I shutdown my VM (memory hot add was not enabled in VMware, it
is now), bumped the RAM to 4GB, and booted the VM.

Upon running the same command after reboot I received an error:

  >> ipa: ERROR: did not receive Kerberos credentials

kinit admin is also reporting an error:

  >>  kinit: Cannot contact any KDC for realm 'myrealm'  while getting
initial credentials

trying to start FreeIPA in debug mode identified the samba service as at
fault.

  >> Jan 19 10:19:50 myfreeipaserver smbd[3676]:   kerberos error:
code=-1765328203, message=Keytab contains no suitable keys for cifs/
myfreeipaser...@sub.domain.mydomain.com
  >> Jan 19 10:19:51 myfreeipaserver smbd[3676]: [2016/01/19
10:19:51.261648,  0] ipa_sam.c:4520(pdb_init_ipasam)
  >> Jan 19 10:19:51 myfreeipaserver smbd[3676]:   Failed to get base DN.
  >> Jan 19 10:19:51 myfreeipaserver smbd[3676]: [2016/01/19
10:19:51.262675,  0]
../source3/passdb/pdb_interface.c:179(make_pdb_method_name)
  >> Jan 19 10:19:51 myfreeipaserver smbd[3676]:   pdb backend
ipasam:ldapi://%2fvar%2frun%2fslapd-SUB-DOMAIN-MYDOMAIN-COM.socket did not
correctly init (error was NT_STATUS_UNSUCCESSFUL)

Googling for these errors turned up a few similar threads but none of the
solutions seemed to work and all signs pointed to AD integration as the
culprit...

So I did what any good sysadmin would do and forced freeipa to start while
ignoring any failures.  Every service except samba starts without issue.

So I tried my trust connection again, and received the same error,

  >> Active Directory domain administrator's password:
  >> ipa: ERROR: CIFS server communication error: code "-1073741801",
  >> message "Memory allocation error" (both may be "None")

Which brought me to googling two bug reports opened on this exact issue:

>> https://bugzilla.redhat.com/show_bug.cgi?id=878168
>> https://fedorahosted.org/freeipa/ticket/3266

Both of these bug reports indicate there's an upstream bug in Samba, the
bug has been closed and reopened at least once.  I did add the AD servers
to /etc/hosts and rebooted the server.  I have to go through the same
process of forcing freeipa to start after the server rebooted... However, I
received the same error message.

While the bug report is currently closed, I seem to be experiencing the
same issues...

Given this bug report, can you please answer me these questions three:

1)  Given the issues with Samba starting after reboot, is this bug report
actually what's wrong or is the error message when trying to create a trust
a red herring 

[Freeipa-users] ipa-client-install and nsslapd-allow-anonymous-access: off

[bahan w]

Hello !

I send you this mail because of the following topic.

I have FreeIPA 3.0.0.25 with RHEL 6.6 and I deactivated the anonymous
access for security reasons.

But now, I have a problem when I try to enroll a new host.

Here is the command I try :
###
ipa-client-install --domain= --realm= --server= --principal=admin --password=
--mkhomedir  --hostname= --no-ntp --no-ssh --no-sshd
--unattended
###

And here is the error message :
###
2016-01-20T11:06:44Z DEBUG Verifying that  (realm None) is
an IPA server
2016-01-20T11:06:44Z DEBUG Init LDAP connection with: ldap://:389
2016-01-20T11:06:44Z DEBUG LDAP Error: Anonymous access not allowed
###

Is there a way with IPA 3.0.0.25 to enroll host with the anonymous acces
disabled ?

Best regards.

Bahan
-- 
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] ipa-client-install and nsslapd-allow-anonymous-access: off

[Martin Kosek]

On 01/20/2016 12:08 PM, bahan w wrote:
> Hello !
> 
> I send you this mail because of the following topic.
> 
> I have FreeIPA 3.0.0.25 with RHEL 6.6 and I deactivated the anonymous
> access for security reasons.
> 
> But now, I have a problem when I try to enroll a new host.
> 
> Here is the command I try :
> ###
> ipa-client-install --domain= --realm= --server= ipaserver> --principal=admin --password=
> --mkhomedir  --hostname= --no-ntp --no-ssh --no-sshd
> --unattended
> ###
> 
> And here is the error message :
> ###
> 2016-01-20T11:06:44Z DEBUG Verifying that  (realm None) is
> an IPA server
> 2016-01-20T11:06:44Z DEBUG Init LDAP connection with: ldap:// server>:389
> 2016-01-20T11:06:44Z DEBUG LDAP Error: Anonymous access not allowed
> ###
> 
> Is there a way with IPA 3.0.0.25 to enroll host with the anonymous acces
> disabled ?
> 
> Best regards.
> 
> Bahan

Hello,

This looks like
https://bugzilla.redhat.com/show_bug.cgi?id=922843

It should be fixed in recent ipa-client versions (ipa-3.0.0-29.el6 and later).

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] ipa-client-install and nsslapd-allow-anonymous-access: off

[Martin Kosek]

Adding freeipa-users back, so that others can benefit from the answer.

Can you please attach a full ipaclient-install.log DEBUG log somewhere so that
we can get the full context of the bug? You may also want to open a RHEL-6
Bugzilla as FreeIPA 3.0.0 is no longer developed upstream, but only maintained
in RHEL-6.x.

Thanks,
Martin

On 01/20/2016 01:39 PM, bahan w wrote:
> Hello Martin !
> 
> Thanks for your answer, Martin !
> 
> I uninstalled the 3.0.0.25 and installed the 3.0.0.47, but unfortunately I
> still have the same error message.
> 
> # rpm -qa | grep ipa-client
> ipa-client-3.0.0-47.el6.x86_64
> 
> And in ipa-client-install.log :
> ###
> 2016-01-20T12:38:14Z DEBUG [LDAP server check]
> 2016-01-20T12:38:14Z DEBUG Verifying that  (realm None) is
> an IPA server
> 2016-01-20T12:38:14Z DEBUG Init LDAP connection with: ldap:// server>:389
> 2016-01-20T12:38:14Z DEBUG LDAP Error: Anonymous access not allowed
> ###
> 
> Best regards.
> 
> Bahan
> 
> 
> On Wed, Jan 20, 2016 at 1:26 PM, Martin Kosek  wrote:
> 
>> On 01/20/2016 12:08 PM, bahan w wrote:
>>> Hello !
>>>
>>> I send you this mail because of the following topic.
>>>
>>> I have FreeIPA 3.0.0.25 with RHEL 6.6 and I deactivated the anonymous
>>> access for security reasons.
>>>
>>> But now, I have a problem when I try to enroll a new host.
>>>
>>> Here is the command I try :
>>> ###
>>> ipa-client-install --domain= --realm= --server=>> ipaserver> --principal=admin --password=
>>> --mkhomedir  --hostname= --no-ntp --no-ssh --no-sshd
>>> --unattended
>>> ###
>>>
>>> And here is the error message :
>>> ###
>>> 2016-01-20T11:06:44Z DEBUG Verifying that  (realm None)
>> is
>>> an IPA server
>>> 2016-01-20T11:06:44Z DEBUG Init LDAP connection with: ldap://>> server>:389
>>> 2016-01-20T11:06:44Z DEBUG LDAP Error: Anonymous access not allowed
>>> ###
>>>
>>> Is there a way with IPA 3.0.0.25 to enroll host with the anonymous acces
>>> disabled ?
>>>
>>> Best regards.
>>>
>>> Bahan
>>
>> Hello,
>>
>> This looks like
>> https://bugzilla.redhat.com/show_bug.cgi?id=922843
>>
>> It should be fixed in recent ipa-client versions (ipa-3.0.0-29.el6 and
>> later).
>>
>> 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

[Freeipa-users] UNABLE TO SEARCH HBAC RULE

[Yogesh Sharma]

Hi,

We have created a user with HBAC Admin permission which has below
permission (Default as provided by IPA):

System: Add HBAC Rule
System: Add HBAC Service Groups
System: Add HBAC Services
System: Delete HBAC Rule
System: Delete HBAC Service Groups
System: Delete HBAC Services
System: Manage HBAC Rule Membership
System: Manage HBAC Service Group Membership
System: Modify HBAC Rule

When I try add below in a new RBAC, it denied the operation as it is
already open for all.

System: Read HBAC Rules
System: Read HBAC Service Groups
System: Read HBAC Services


If we change it to permission, then login is failing.

Please suggest what we need to do so that HBAC admin can search the HBAC
rule in FreeIPA rule.



*Best Regards,*

*__*

*Yogesh Sharma*
*Email: yks0...@gmail.com  | Web: www.initd.in
 *

*RHCE, VCE-CIA, RACKSPACE CLOUD U Certified*

   


-- 
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] Unable to search HBAC Rule

[Martin Basti]

On 20.01.2016 14:26, Yogesh Sharma wrote:

Hi,

We have created a user with HBAC Admin permission which has below 
permission (Default as provided by IPA):


System: Add HBAC Rule
System: Add HBAC Service Groups
System: Add HBAC Services
System: Delete HBAC Rule
System: Delete HBAC Service Groups
System: Delete HBAC Services
System: Manage HBAC Rule Membership
System: Manage HBAC Service Group Membership
System: Modify HBAC Rule

When I try add below in a new RBAC, it denied the operation as it is 
already open for all.


System: Read HBAC Rules
System: Read HBAC Service Groups
System: Read HBAC Services


If we change it to permission, then login is failing.

Please suggest what we need to do so that HBAC admin can search the 
HBAC rule in FreeIPA rule.




Hello, which version of IPA do you use?

This has been fixed (workaround).
https://fedorahosted.org/freeipa/ticket/5130

The proper fix requires changes in DS ACI evaluation that should be in 
RHEL 7.3


Martin



/Best Regards,/
/__
/
/Yogesh Sharma
/
/Email: yks0...@gmail.com  | Web: 
www.initd.in  /

/
/
/RHCE, VCE-CIA, RACKSPACE CLOUD U Certified/

  
 






-- 
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] Unable to search HBAC Rule

[Yogesh Sharma]

Hi Martin,

FreeIPA version 4.1.0

Will look into the Workaround. Thanks

*Best Regards,*

*__*

*Yogesh Sharma*
*Email: yks0...@gmail.com  | Web: www.initd.in
 *

*RHCE, VCE-CIA, RACKSPACE CLOUD U Certified*

   



On Wed, Jan 20, 2016 at 7:04 PM, Martin Basti  wrote:

>
>
> On 20.01.2016 14:26, Yogesh Sharma wrote:
>
> Hi,
>
> We have created a user with HBAC Admin permission which has below
> permission (Default as provided by IPA):
>
> System: Add HBAC Rule
> System: Add HBAC Service Groups
> System: Add HBAC Services
> System: Delete HBAC Rule
> System: Delete HBAC Service Groups
> System: Delete HBAC Services
> System: Manage HBAC Rule Membership
> System: Manage HBAC Service Group Membership
> System: Modify HBAC Rule
>
> When I try add below in a new RBAC, it denied the operation as it is
> already open for all.
>
> System: Read HBAC Rules
> System: Read HBAC Service Groups
> System: Read HBAC Services
>
>
> If we change it to permission, then login is failing.
>
> Please suggest what we need to do so that HBAC admin can search the HBAC
> rule in FreeIPA rule.
>
>
> Hello, which version of IPA do you use?
>
> This has been fixed (workaround).
> https://fedorahosted.org/freeipa/ticket/5130
>
> The proper fix requires changes in DS ACI evaluation that should be in
> RHEL 7.3
>
> Martin
>
>
> *Best Regards,*
>
> *__ *
>
> *Yogesh Sharma *
> *Email:  yks0...@gmail.com  | Web:
> www.initd.in  *
>
> *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified*
>
>    
> 
> 
>
>
>
>
-- 
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