Re: [Freeipa-users] is ipa-cert-manage safe to use?
On 05/15/17 16:44, Rob Crittenden wrote: > > I'm confused. You mention replacing some "externally signed certificate" > and yet then ask switching to externally signed certificates. What is > the current configuration? What is signing the existing server certs? Or > do you have an external CA signing the IPA CA? > The current servers have been installed with --external-ca. freeipa created a csr, it was signed by an external CA and handed off back to the freeipa server. The question was if I should drop the whole certificate support in freeipa. Its called "CA-less install", if I got this correctly. I am not sure if it is possible to switch from external-ca to CA-less. > ipa-cacert-manage is for managing the CA certificate, not service > certificates. > Sure. Point is that I don't see how a problem on replacing freeipa's (externally signed) CA certificate by a new one affects freeipa. Sorry to say, but at install time I did not had the impression, that "ipa-server-install --external-ca" was thoroughly tested before. I ran straight into a problem, but fortunately that didn't matter, cause freeipa was not in production use, yet. (Look for "ipa-server-install --external-ca failed" on this mailing list, thread started 2015-12-15.) Today it is in production use. If I brick freeipa today, then I have a huge problem, so I am concerned. Regards Harri -- 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] is ipa-cert-manage safe to use?
Hi folks, I have to renew (or replace) the externally signed certificate on my ipa servers using a new ca. Apparently the tool of choice is ipa-cacert-manage. Of course I found https://www.freeipa.org/page/Howto/CA_Certificate_Renewal. Problem is, I cannot estimate the risk and if its worth the effort. What happens to freeipa if ipa-cacert-manage fails miserably? Does it affect the LDAP database or Kerberos? Will it break the connection between my ipa servers or between servers and clients? Would you suggest to forget all the "CA stuff" in freeipa and manage the certificates externally? The platform of the ipa servers is Centos 7.3. There are 100+ Debian and RedHat clients using freeipa 4.4.3 and 4.0.5 and 3.0.2. I am highly concerned. Every helpful comment is appreciated. Harri -- 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] ipa-client-install: please look for SELINUX=disabled
Hi folks, RHEL 7.3, sssd 1.14.0: If /etc/selinux/config says "SELINUX=disabled", then pam seems to fail (without telling why) and users cannot login. *Extremely* painful. Do you think ipa-client-install could add selinux_provider = none to the generated sssd.conf file, if selinux is disabled? Another option might be to check at runtime. Thanx in advance Harri -- 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] bad certificate used to sign freeipa
Hi folks, I stumbled over this problem: http://openbsd-archive.7691.n7.nabble.com/Certificate-Error-quot-format-error-in-certificate-s-notAfter-field-quot-td304262.html The details don't really matter. The important point is that the root certificate used to sign freeipa's certificate appears to be unacceptable on openBSD and maybe others. What would you suggest? Is there a guideline to migrate freeipa to a new certificate authority? Every helpful comment is highly appreciated Harri -- 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 generates bad sssd.conf
On 03/05/17 11:47, Timo Aaltonen wrote: > > pam-auth-update configures pam, there's nothing else to be configured.. > I just ran ipa-client-install on Ubuntu zesty with freeipa-client > 4.4.3-3ubuntu1, and services on the newly created sssd.conf look fine: > > services = nss, sudo, pam, ssh > > Do you get the same for 4.4.3-3 (the version in Debian experimental, AFAICT) on sid? I don't :-(. Command line: ipa-client-install --hostname `hostname` --no-ssh --no-sshd --no-nisdomain Regards Harri -- 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 generates bad sssd.conf
On 03/03/17 10:14, Jakub Hrozek wrote: > On Fri, Mar 03, 2017 at 09:56:55AM +0100, Harald Dunkel wrote: >> >> This is systemd-only? >> >> Wouldn't it be better to create a working sssd.conf, no matter >> what? > > It is up to whoever is creating the sssd.conf. As I said, the change is > backwards-compatible. If you want the services to be started by sssd, > then list them in the services line. If you want to have them started on > demand and have a simpler configuration, you rely on the systemd services > manager. > Understood. I will try 1.15.1 as soon as possible. Reading ipa-client-install it appears to me that the other services haven't been omitted on purpose. I have the impression that nss and pam have simply been forgotten. sssd's ssh service is defined only if ipa-client-install is allowed to touch the ssh or sshd configuration, but I have *no* idea why there is such a correlation. Would somebody mind to look into this? Thanx very much Harri -- 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 generates bad sssd.conf
Hi Jakub, On 03/03/17 09:32, Jakub Hrozek wrote: > On Fri, Mar 03, 2017 at 08:45:10AM +0100, Harald Dunkel wrote: >> Hi folks, >> >> running freeipa client 4.3.2-5 and sssd 1.15.0-3 on >> Debian Stretch > ~~ > This is important I guess. > > Since SSSD 1.15, SSSD allows to socket-activate the services, so it is > no longer required to have them explicitly listed in the services line > of the sssd section. But: > - there were some nasty bugs in the first version of the socket > activation. We will be releasing 1.15.1 today to address those > issues > - the sockets must be enabled (systemctl status sssd-nss.socket). I > understand Debian is doing this but I'm neither Debian user nor > developer. I would suggest to ask on some Debian-specific forum or > file a bug report if the resulting configurationd doesn't work. > This is systemd-only? Wouldn't it be better to create a working sssd.conf, no matter what? Regards Harri -- 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] ipa-client-install generates bad sssd.conf
Hi folks, running freeipa client 4.3.2-5 and sssd 1.15.0-3 on Debian Stretch ipa-client-install creates a bad sssd.conf file, e.g. [domain/example.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = example.com id_provider = ipa auth_provider = ipa access_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt ipa_hostname = stretch1.vs.example.com chpass_provider = ipa ipa_server = _srv_, ipa1.example.com dns_discovery_domain = example.com [sssd] domains = example.com services = sudo [sudo] Esp. the services for nss, pam and ssh are not setup. Is this as expected? Every helpful comment is highly appreciated. Harri -- 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] Jenkins integration?
On 02/11/17 11:57, Alexander Bokovoy wrote: > On la, 11 helmi 2017, Michael Ströder wrote: >> >> (Personally I'd avoid going through PAM.) > Any specific reason for not using pam_sss? Remember, with SSSD involved > you get also authentication for trusted users from Active Directory > realms. You don't get that with generic LDAP way. Also, you'd be more > efficient in terms of utilising LDAP connections. > I would prefer if the users are not allowed to login into a shell on the Jenkins server. Surely this restriction can be implemented with pam as well. Regards Harri -- 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] Jenkins integration?
On 02/10/17 15:07, Tomasz Torcz wrote: > On Fri, Feb 10, 2017 at 02:03:48PM +0100, Harald Dunkel wrote: >> Hi folks, >> >> did anybody succeed in using Freeipa for Jenkins' LDAP module? >> I can't make it work :-(. > > I'm using Jenkins with FreeIPA, but not with Jenkins's LDAP. > I have Jenkins set to PAM authentication, which in turn goes thru SSSD. > It works fine, groups are resolved correctly, too. > Thats plan B. Its good to know that this works, but I don't give up that easy. My major problem ist that jenkins doesn't write propper log files. Java is as awkward as it was 20 years ago. Thanx Harri -- 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] Jenkins integration?
Hi folks, did anybody succeed in using Freeipa for Jenkins' LDAP module? I can't make it work :-(. On the command line the jenkins user appears to have read access to the LDAP database. The config UI for Jenkin's LDAP plugin doesn't complain, either. Jenkins System Log appears to be fine. But if a "freeipa user" tries to login in Jenkins, then he gets an "invalid login information". For Confluence (both are Java Webapps) there was no such problem. Every helpful hint is highly appreciated. Harri -- 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] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]
Hi Thierry, On 01/30/17 09:10, thierry bordaz wrote: > > I understand your concern and in fact it is difficult to anticipate a > potential bad impact of this cleanup. However,I think it is safe to get rid > of the following entry. > Before doing so you may check it exists > > cn=ipaservers,cn=ng,cn=alt,dc=example,dc=de that is managedBy the > ipaservers_hostgoups. > > dn: > cn=ipaservers+nsuniqueid=109be304-ccd911e6-a5b3d0c8-d8da17db,cn=ng,cn=alt,dc=example,dc=de > mepManagedBy: cn=ipaservers,cn=hostgroups,cn=accounts,dc=example,dc=de > objectClass: mepManagedEntry > > > If you are willing to remove that entry you need to remove the > mepmanagedEntry oc. So you need to remove the mepManagedBy and oc in the same > operation > > > Regarding the following entry > dn: > cn=ipaservers+nsuniqueid=109be302-ccd911e6-a5b3d0c8-d8da17db,cn=hostgroups,cn=accounts,dc=example,dc=de > objectClass: mepOriginEntry > mepManagedEntry: cn=ipaservers,cn=ng,cn=alt,dc=example,dc=de > > You may want to check if it exists an entry it manages, looking for > "(mepManagedBy= > cn=ipaservers+nsuniqueid=109be302-ccd911e6-a5b3d0c8-d8da17db,cn=hostgroups,cn=accounts,dc=example,dc=de > )". If it exists none, you should be able to remove it. > > Also I think working on ipabak, you should be able to do some tests on the > cleanup instance to validate everything is working fine. > This looks like a pretty high risk, even if ipabak says everything is fine. The major problem was the failure on Debian Wheezy using the very old sssd. This seems to be gone now by resolving the "easy" cases. About the "hard" cases: AFAICS ipaservers+nsuniqueid=109be302-ccd911e6-a5b3d0c8-d8da17db,cn=hostgroups,cn=accounts,dc=example,dc=de doesn't list any hosts (the official entry does), and cn=ipaservers+nsuniqueid=109be304-ccd911e6-a5b3d0c8-d8da17db,cn=ng,cn=alt,dc=example,dc=de points to the duplicate entry only. They are not referenced anywhere else in the ldap database. So I would suggest to wait and see if I run in any problem here. Would you agree to this, or do you expect problems later? I highly appreciate your help Regards Harri > regards > 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] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]
Hi Thierry, On 01/26/17 16:55, thierry bordaz wrote: > > > Those entries are managed entries and it is not possible to delete them from > direct ldap command. > A solution proposed by Ludwig is not first make them unmanaged: > > cn=ipaservers+nsuniqueid=109be304-ccd911e6-a5b3d0c8-d8da17db,cn=ng,cn=alt,dc=example,dc=de > changetype: modify > modify: objectclass > delete: mepManagedEntry > > cn=ipaservers+nsuniqueid=109be304-ccd911e6-a5b3d0c8-d8da17db,cn=ng,cn=alt,dc=example,dc=de > changetype: modify > modify: objectclass > delete: mepManagedEntry > > Then retry to delete them. > It should work for the first one but unsure it will succeed for the second > one. > I am not sure about this "managed" thing. This sounds like some kind of external influence. How can I make sure that removing these entries doesn't break something? Is the original entry managed in the same way as the duplicate? Regards Harri -- 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] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]
Hi Thierry, good new: I got rid of most of the conflicting entries. There are only 2 left (see below). They look circular somehow. Please note that the unwanted list of ipa servers is empty. The official list looks OK. The record for cn=ipaservers,cn=ng,cn=alt\ ,dc=example,dc=de looks fine, too. It points to the official list. So hopefully the duplicates are not a big deal. It would be nice to get rid of both, though. Any helpful hint is highly appreciated Harri -- % cat < dn: > cn=ipaservers+nsuniqueid=109be304-ccd911e6-a5b3d0c8-d8da17db,cn=ng,cn=alt,dc=example,dc=de > changetype: delete > EOF deleting entry "cn=ipaservers+nsuniqueid=109be304-ccd911e6-a5b3d0c8-d8da17db,cn=ng,cn=alt,dc=example,dc=de" ldap_delete: Server is unwilling to perform (53) additional info: Deleting a managed entry is not allowed. It needs to be manually unlinked first. % cat < dn: > cn=ipaservers+nsuniqueid=109be302-ccd911e6-a5b3d0c8-d8da17db,cn=hostgroups,cn=accounts,dc=example,dc=de > changetype: delete > EOF deleting entry "cn=ipaservers+nsuniqueid=109be302-ccd911e6-a5b3d0c8-d8da17db,cn=hostgroups,cn=accounts,dc=example,dc=de" ldap_delete: Operations error (1) % ldapsearch -o ldif-wrap=no -D "cn=directory manager" -w secret -b "cn=ipaservers+nsuniqueid=109be304-ccd911e6-a5b3d0c8-d8da17db,cn=ng,cn=alt,dc=example,dc=de" -s base # extended LDIF # # LDAPv3 # base
Re: [Freeipa-users] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]
Hi Thierry, On 01/24/17 17:56, thierry bordaz wrote: > > > On 01/24/2017 04:18 PM, Harald Dunkel wrote: >> >> Would you suggest to disconnect ipabak from the network and ipa1, >> cleanup the mess as far as possible, and then connect ipabak >> to the network again to rely upon the regular replica synchroni- >> zation? > > Yes, as soon as ipaback is in sync with ipa1 and you took a snapshot of > ipaback, I think you can disconnect ipaback and run your script on it > (iterating with the snapshot). > My concern is that I will run into new conflicts on connecting the modified ipaback back with ipa1? Regards Harri -- 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] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]
Hi Thierry, On 01/24/17 15:01, thierry bordaz wrote: >> Hopefully yes, but there were 2 conflicts that already made some >> problems: >> >> deleting entry >> "cn=ipaservers+nsuniqueid=109be304-ccd911e6-a5b3d0c8-d8da17db,cn=ng,cn=alt,dc=example,dc=de" >> ldap_delete: Server is unwilling to perform (53) >> additional info: Deleting a managed entry is not allowed. It >> needs to be manually unlinked first. >> >> >> deleting entry >> "cn=ipaservers+nsuniqueid=109be302-ccd911e6-a5b3d0c8-d8da17db,cn=hostgroups,cn=accounts,dc=example,dc=de" >> ldap_delete: Operations error (1) >> >> I got these problems before I became more careful with this. > > This will be a difficulty to setup that script. > You may be unable to delete some entries (managed entry, tombstones..). > > I think one target of the script is to get the 'valid' entries at the > expected level: having the expected set of attribute/values. A kind of merge > of valid/conflict entries. > Then you may have to moddn some conflict children under the valid entry. > At the end, remove the conflict entries. I agree. But I still need to work on a snapshot first, without the risk of making things worse. Would you suggest to disconnect ipabak from the network and ipa1, cleanup the mess as far as possible, and then connect ipabak to the network again to rely upon the regular replica synchroni- zation? > > As I said, setting up such script could take you more time than fixing > manually the 43 conflicts. > Maybe there is a misunderstanding about "script" here: Its not a high-end shell script with man page and command line flags and so on. It is just a sequence of variable assignments and commands to run. Goal is to avoid having to type the same stuff twice, and to make use of copy and paste in an editor. One key feature is to get something reproducible. Every helpful advice is highly welcome Harri -- 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] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]
On 01/24/17 12:57, thierry bordaz wrote: > > If I understand correctly the iterations of development I do not understand > why, at this point, you need to reconnect ipabak. > After you create ipabak replica, you take a snapshot of it (let ipabak_0), > then disconnect it from ipa1/ipa2. > > Then you may start incremental dev of the script on the offline ipabak. > Before each test of the script, you just need to get ipabak to ipabak_0. > Am I missing something ? > ipa1 is not idle while the script is in development. I do not know if these conflicting entries pop up in some new entries on ipa1 while the script is in development. When the script seems to be ready, then I have to verify it with very recent copy of the database before the final run. > >> When the script appears to be ready I have to revert and sync >> ipabak again as above, but instead of disconnecting it from the >> network I have to stop all ipa servers in parallel to take a >> snapshot of each. (All ipa servers are LXC containers.) Next >> start the ipa servers again and run the script on ipabak, now >> connected with ipa1. This should make the changes "official". > > How do you know if the script is ready ? When it resolves all the conflict > entries ? > Hopefully yes, but there were 2 conflicts that already made some problems: deleting entry "cn=ipaservers+nsuniqueid=109be304-ccd911e6-a5b3d0c8-d8da17db,cn=ng,cn=alt,dc=example,dc=de" ldap_delete: Server is unwilling to perform (53) additional info: Deleting a managed entry is not allowed. It needs to be manually unlinked first. deleting entry "cn=ipaservers+nsuniqueid=109be302-ccd911e6-a5b3d0c8-d8da17db,cn=hostgroups,cn=accounts,dc=example,dc=de" ldap_delete: Operations error (1) I got these problems before I became more careful with this. Regards Harri -- 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] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]
Hi Thierry,
On 01/23/17 17:45, thierry bordaz wrote:
>
>
> On 01/23/2017 05:09 PM, Harald Dunkel wrote:
>>
>> I created a full replica (including CA) in an LXC container today
>> ("ipabak"). The idea is to take a snapshot of the whole container,
>> run ipabak without network connection, and then create and verify
>> a shell script to fix the disconnected replica. On problems I can
>> roll ipabak back to the snapshot. Maybe it needs some iterations to
>> create a working script.
>
> Do you want to run ipabak against ipa1 or ipa2 server ?
ipabak is a replica of ipa1:
# ipa-replica-manage -v list ipabak.vs.example.de
Directory Manager password:
ipa1.example.de: replica
last init status: None
last init ended: 1970-01-01 00:00:00+00:00
last update status: Error (0) Replica acquired successfully: Incremental
update succeeded
last update ended: 2017-01-24 10:13:13+00:00
# ipa-csreplica-manage -v list ipabak.vs.example.de
Directory Manager password:
ipa1.example.de
last init status: None
last init ended: 1970-01-01 00:00:00+00:00
last update status: Error (0) Replica acquired successfully: Incremental
update succeeded
last update ended: 2017-01-24 10:14:01+00:00
ipa1 is the first master. ipabak was setup using
# ssh r...@ipa1.example.de ipa-replica-prepare ipabak.vs.example.de
# scp -p
r...@ipa1.example.de:/var/lib/ipa/replica-info-ipabak.vs.example.de.gpg
/var/lib/ipa/
# ipa-replica-install /var/lib/ipa/replica-info-ipabak.vs.example.de.gpg
--setup-ca
Do you think this is OK?
BTW, freeipa doesn't provide DNS in my net.
>>
>> When the script appears to be fine I can revert the ipabak container
>> to the most recent snapshot again, connect it to the network to sync
>> it with ipa1 and then run the script with multisite replication
>> enabled.
>>
>> Do you think this could work?
>
> It should work if you run ipabak against ipa1 or ipa2. But then how to
> prevent that ipa1/ipa2 get more conflicts with the iterations of tests ?
>
ipabak is not supposed to be connected to ipa1 again, if it has
been modified by the script in development. It has to be reverted
back to the snapshot first. From ipa1's point of view, ipabak just
goes offline for some time, but it never comes back modified.
The development iterations are not cumulative, except for the
script. In each cycle I add code to the script, revert the dis-
connected ipabak back to the snapshot, and test the whole script.
The snapshot is not overwritten.
The snapshot of a LXC container is just an exact copy of its root
directory, taken while the container was off. To revert a LXC
container back to its snapshot, I have to turn it off, replace
its root directory by a copy of the snapshot, and turn it on
again.
To create a new snapshot I revert ipabak to the current snapshot,
connect it to the network, sync it with ipa1, disconnect it and
copy the containers root directory to the new snapshot directory.
The old snapshot has to be removed then.
When the script appears to be ready I have to revert and sync
ipabak again as above, but instead of disconnecting it from the
network I have to stop all ipa servers in parallel to take a
snapshot of each. (All ipa servers are LXC containers.) Next
start the ipa servers again and run the script on ipabak, now
connected with ipa1. This should make the changes "official".
Did I miss something here?
Harri
--
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] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]
Hi Thierry,
On 01/23/17 11:59, thierry bordaz wrote:
> We need to get a clear status before trying to swap them.
> For example in your attachment the valid entry is member of 'DNS Admin' while
> the conflict one is not. So possibly the valid entry is the one to keep.
>
> Conflicts entry
> dn: cn=DNS Servers,cn=privileges,cn=pbac,dc=example,dc=de
>
> belong to all these groups
> memberOf: cn=System: Read DNS
> Configuration,cn=permissions,cn=pbac,dc=example,dc=de
> memberOf: cn=System: Write DNS
> Configuration,cn=permissions,cn=pbac,dc=example,dc=de
> memberOf: cn=System: Add DNS Entries,cn=permissions,cn=pbac,dc=example,dc=de
> memberOf: cn=System: Manage DNSSEC
> keys,cn=permissions,cn=pbac,dc=example,dc=de
> memberOf: cn=System: Manage DNSSEC
> metadata,cn=permissions,cn=pbac,dc=example,dc=de
> memberOf: cn=System: Read DNS Entries,cn=permissions,cn=pbac,dc=example,dc=de
> memberOf: cn=System: Remove DNS
> Entries,cn=permissions,cn=pbac,dc=example,dc=de
> memberOf: cn=System: Update DNS
> Entries,cn=permissions,cn=pbac,dc=example,dc=de
> memberOf: cn=System: Read DNS Servers
> Configuration+nsuniqueid=109be363-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de
>
> My initial thought was to check how it was member (which attribute it is
> using and if it is nested/direct membership).
> So then we may try to repair the "valid" entry, making it similarly member of
> those groups.
>
> But this is looking to be complex job and no guaranty it will repair
> everything broken.
>
> Do you have a way to restore from a state where there was no conflict ?
>
I do have old backups. ipa1 and ipa2 were setup in dec 2015. They
are included in at least one monthly archive in jan 2016. I am not
sure if this old version is OK, though.
ldapsearch -o ldif-wrap=no -D "cn=directory manager" -w secret -b
"dc=example,dc=de" | grep nsuniqueid | wc -l
tells me that there are 43 problems open, including the DNs that
are not referenced anywhere. Maybe its easier and less risky to
fix the broken entries?
I created a full replica (including CA) in an LXC container today
("ipabak"). The idea is to take a snapshot of the whole container,
run ipabak without network connection, and then create and verify
a shell script to fix the disconnected replica. On problems I can
roll ipabak back to the snapshot. Maybe it needs some iterations to
create a working script.
When the script appears to be fine I can revert the ipabak container
to the most recent snapshot again, connect it to the network to sync
it with ipa1 and then run the script with multisite replication
enabled.
Do you think this could work?
Regards
Harri
--
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] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]
Hi Thierry, On 01/20/17 14:17, thierry bordaz wrote: > > I agree that it is looking like the conflict entry is the most up-to-date one. > To try to repair, it would help if you can search groups > > cn=System: Read DNS Configuration,cn=permissions,cn=pbac,dc=example,dc=de > cn=System: Write DNS Configuration,cn=permissions,cn=pbac,dc=example,dc=de > cn=System: Add DNS Entries,cn=permissions,cn=pbac,dc=example,dc=de > cn=System: Manage DNSSEC keys,cn=permissions,cn=pbac,dc=example,dc=de > cn=System: Manage DNSSEC metadata,cn=permissions,cn=pbac,dc=example,dc=de > cn=System: Read DNS Entries,cn=permissions,cn=pbac,dc=example,dc=de > cn=System: Remove DNS Entries,cn=permissions,cn=pbac,dc=example,dc=de > cn=System: Update DNS Entries,cn=permissions,cn=pbac,dc=example,dc=de > cn=System: Read DNS Servers > Configuration,cn=permissions,cn=pbac,dc=example,dc=de > cn=System: Read DNS Servers > Configuration+nsuniqueid=109be363-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de > > Hopefully the two last are identical, but the others may refer to ' > cn=System: Read DNS Servers > Configuration+nsuniqueid=109be363-ccd911e6-a5b3d0c8-d8da17db' instead of the > non conflict one. > They are not the same (see attachments): --- /tmp/system_read_dns2017-01-23 08:26:21.580128044 +0100 +++ /tmp/system_read_dns.nsuniqueid 2017-01-23 08:26:42.603217657 +0100 @@ -1,13 +1,13 @@ # extended LDIF # # LDAPv3 -# base
Re: [Freeipa-users] sssd doesn't cache, as it seems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Jakub, On 01/21/17 13:49, Jakub Hrozek wrote: > > Can you check what kind of query do you see in the LDAP server log? > The git server does just a few queries per hour: [21/Jan/2017:16:27:53.098932003 +0100] conn=8 op=39431 SRCH base="dc=example,dc=de" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=host/tisde8i005.ac.example...@example.de)(krbPrincipalName:caseIgnoreIA5Match:=host/tisde8i005.ac.example...@example.de)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Jan/2017:16:27:53.100196009 +0100] conn=8 op=39435 SRCH base="fqdn=tisde8i005.ac.example.de,cn=computers,cn=accounts,dc=example,dc=de" scope=0 filter="(objectClass=*)" attrs="objectClass uid cn fqdn gidNumber krbPrincipalName krbCanonicalName krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbLastAdminUnlock krbTicketFlags ipaNTSecurityIdentifier ipaNTLogonScript ipaNTProfilePath ipaNTHomeDirectory ipaNTHomeDirectoryDrive" [21/Jan/2017:16:27:53.100426687 +0100] conn=8 op=39436 SRCH base="cn=tisde8i005.ac.example.de,cn=masters,cn=ipa,cn=etc,dc=example,dc=de" scope=0 filter="(objectClass=*)" attrs=ALL [21/Jan/2017:16:27:53.100658375 +0100] conn=8 op=39437 MOD dn="fqdn=tisde8i005.ac.example.de,cn=computers,cn=accounts,dc=example,dc=de" [21/Jan/2017:16:27:53.125278099 +0100] conn=9119 op=3 RESULT err=0 tag=97 nentries=0 etime=0 dn="fqdn=tisde8i005.ac.example.de,cn=computers,cn=accounts,dc=example,dc=de" [21/Jan/2017:16:28:37.001050661 +0100] conn=9119 op=891 SRCH base="cn=accounts,dc=example,dc=de" scope=2 filter="(&(objectClass=ipaHost)(fqdn=tisde8i005.ac.example.de))" attrs="objectClass cn fqdn serverHostName memberOf ipaSshPubKey ipaUniqueID" [21/Jan/2017:16:28:37.003968246 +0100] conn=9119 op=892 SRCH base="fqdn=tisde8i005.ac.example.de,cn=computers,cn=accounts,dc=example,dc=de" scope=0 filter="(objectClass=*)" attrs="objectClass cn memberOf ipaUniqueID" [21/Jan/2017:16:28:37.006876504 +0100] conn=9119 op=894 SRCH base="cn=sudo,dc=example,dc=de" scope=2 filter="(&(objectClass=ipasudorule)(ipaEnabledFlag=TRUE)(|(!(memberHost=*))(hostCategory=ALL)(memberHost=fqdn=tisde8i005.ac.example.de,cn=computers,cn=accounts,dc=example,dc=de))(entryusn>=1))" attrs="objectClass cn ipaUniqueID ipaEnabledFlag ipaSudoOpt ipaSudoRunAs ipaSudoRunAsGroup memberAllowCmd memberDenyCmd memberHost memberUser sudoNotAfter sudoNotBefore sudoOrder cmdCategory hostCategory userCategory ipaSudoRunAsUserCategory ipaSudoRunAsGroupCategory ipaSudoRunAsExtUser ipaSudoRunAsExtGroup ipaSudoRunAsExtUserGroup externalUser entryusn" [21/Jan/2017:16:42:47.447444525 +0100] conn=7 op=22424 SRCH base="dc=example,dc=de" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=host/tisde8i005.ac.example...@example.de))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Jan/2017:16:42:47.459190497 +0100] conn=9208 op=3 RESULT err=0 tag=97 nentries=0 etime=0 dn="fqdn=tisde8i005.ac.example.de,cn=computers,cn=accounts,dc=example,dc=de" [21/Jan/2017:16:43:37.000841869 +0100] conn=9208 op=961 SRCH base="cn=accounts,dc=example,dc=de" scope=2 filter="(&(objectClass=ipaHost)(fqdn=tisde8i005.ac.example.de))" attrs="objectClass cn fqdn serverHostName memberOf ipaSshPubKey ipaUniqueID" [21/Jan/2017:16:43:37.002362473 +0100] conn=9208 op=962 SRCH base="fqdn=tisde8i005.ac.example.de,cn=computers,cn=accounts,dc=example,dc=de" scope=0 filter="(objectClass=*)" attrs="objectClass cn memberOf ipaUniqueID" [21/Jan/2017:16:43:37.005732600 +0100] conn=9208 op=964 SRCH base="cn=sudo,dc=example,dc=de" scope=2 filter="(&(objectClass=ipasudorule)(ipaEnabledFlag=TRUE)(|(!(memberHost=*))(hostCategory=ALL)(memberHost=fqdn=tisde8i005.ac.example.de,cn=computers,cn=accounts,dc=example,dc=de))(entryusn>=1))" attrs="objectClass cn
Re: [Freeipa-users] sssd doesn't cache, as it seems
On 01/20/17 18:42, Simo Sorce wrote: > > Is your server being used for authentication ? > SSSD, by default, always refreshes user credentials on authentication, > but you can use the cached_auth_timeout setting to relax this > requirement in SSSD, and reduce the roundtrips for auth attempts. > I have set both pam_id_timeout and cached_auth_timeout to 30. No change, still several requests per second for each user. ??? Harri [domain/example.de] debug_level = 0x0370 cache_credentials = True cached_auth_timeout = 30 krb5_store_password_if_offline = True ipa_domain = example.de id_provider = ipa auth_provider = ipa access_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt ipa_hostname = tisde8i005.ac.example.de chpass_provider = ipa ipa_server = _srv_, ipa1.example.de dns_discovery_domain = example.de selinux_provider = none [sssd] debug_level = 0x0370 services = nss, sudo, pam, ssh config_file_version = 2 domains = example.de [nss] debug_level = 0x0370 homedir_substring = /home [pam] pam_id_timeout = 30 debug_level = 0x0370 [sudo] [autofs] [ssh] debug_level = 0x0370 [pac] [ifp] -- 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] sssd doesn't cache, as it seems
Hi folks, I see a pretty large number of ldap requests sent by our git server, asking for the same account info again and again. Sometimes it asks 20 times per second for the same user info, for example. Obviously caching doesn't work. I remember some note in the installation guide suggesting to turn of nscd and that sssd takes over this job, so I wonder wth? A recent EMail in this forum suggested to set selinux_provider = none, but this didn't help. Ipa server is Centos 7.3, client is on Jessie with sssd 1.13.4. sssd.conf is attached, of course. Every helpful comment is highly appreciated. Harri [domain/example.de] debug_level = 0x0370 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = example.de id_provider = ipa auth_provider = ipa access_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt ipa_hostname = tisde8i005.ac.example.de chpass_provider = ipa ipa_server = _srv_, ipa1.example.de dns_discovery_domain = example.de selinux_provider = none [sssd] debug_level = 0x0370 services = nss, sudo, pam, ssh config_file_version = 2 domains = example.de [nss] debug_level = 0x0370 homedir_substring = /home [pam] debug_level = 0x0370 [sudo] [autofs] [ssh] debug_level = 0x0370 [pac] [ifp] signature.asc Description: OpenPGP digital signature -- 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] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]
On 01/18/17 16:22, Ludwig Krispenz wrote: > I think the procedure in the link about renaming is only needed if you want > to keep both entries with a "normal" dn. But you want to get rid of the > conflict entries. Since you have to cleanup each of them individually I > would suggest to start with one of them. > > First get both the conflict entry and the normal entry and compare them: > ldapsearch -D "cn=directory manager" . -b "cn=System: Manage Host > Principals,cn=permissions,cn=pbac,dc=example,dc=de" -s base > ldapsearch -D "cn=directory manager" . -b "cn=System: Manage Host > Principals+nsuniqueid=109be36e-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de" > -s base > > They should be identical. > Next check if the conflict entry has child entries: > ldapsearch -D "cn=directory manager" . -b "cn=System: Manage Host > Principals+nsuniqueid=109be36e-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de" > dn > > If there are no entries below the conflict entry you can remove it: > ldapmodify - D "cn=directory manager" .. > dn: cn=System: Manage Host > Principals+nsuniqueid=109be36e-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de > changetype: delete > Of course they are not identical :-(. Worst case seems to be this one: % ldapsearch -o ldif-wrap=no -D "cn=directory manager" -w secret -b "cn=DNS Servers+nsuniqueid=109be317-ccd911e6-a5b3d0c8-d8da17db,cn=privileges,cn=pbac,dc=example,dc=de" -s base # extended LDIF # # LDAPv3 # base
Re: [Freeipa-users] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]
On 01/19/17 16:23, Harald Dunkel wrote: > Now I get this: > > [root@ipa1 ~]# kinit admin > kinit: Generic error (see e-text) while getting initial credentials > Fortunately this went away after a reboot of the servers. Phew Harri -- 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] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]
Now I get this: [root@ipa1 ~]# kinit admin kinit: Generic error (see e-text) while getting initial credentials -- 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] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]
On 01/17/17 11:38, Sumit Bose wrote: > On Tue, Jan 17, 2017 at 10:44:14AM +0100, Harald Dunkel wrote: >> It seems something got corrupted in my ipa setup. I found this in the >> sssd log file on Wheezy: >> >> (Tue Jan 17 10:19:02 2017) [hbac_shost_attrs_to_rule] (0x0400): Processing >> source hosts for rule [allow_all] >> (Tue Jan 17 10:19:02 2017) [hbac_eval_user_element] (0x0080): Parse error on >> [cn=System: Manage Host >> Principals+nsuniqueid=109be36e-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de] > > Looks like there was a replication conflict, please see > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html > how to resolve it. > This is *way* too hot for me. How can I try this in a sandbox? Every helpful comment is highly appreciated Harri -- 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] report abuse
On 01/17/17 21:59, Lukas Slebodnik wrote: > On (16/01/17 07:53), Alexander Bokovoy wrote: >> >> The spam bot actually mines the mailing list archives and sends emails >> based on that one. >> I am not sure how to apply it in this case, but time is money for these spammers. Maybe it is possible to tarpit first access to the mailing list archive index.html? Another idea: fake entries in the mailing list archive with tons of fake EMail addresses. Regards Harri -- 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] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]
Hi Ludwig, On 01/17/17 17:01, Ludwig Krispenz wrote: > > On 01/17/2017 04:48 PM, Harald Dunkel wrote: >> On 01/17/17 16:12, Harald Dunkel wrote: >>> On 01/17/17 11:38, Sumit Bose wrote: >>>> On Tue, Jan 17, 2017 at 10:44:14AM +0100, Harald Dunkel wrote: >>>>> It seems something got corrupted in my ipa setup. I found this in the >>>>> sssd log file on Wheezy: >>>>> >>>>> (Tue Jan 17 10:19:02 2017) [hbac_shost_attrs_to_rule] (0x0400): >>>>> Processing source hosts for rule [allow_all] >>>>> (Tue Jan 17 10:19:02 2017) [hbac_eval_user_element] (0x0080): Parse error >>>>> on [cn=System: Manage Host >>>>> Principals+nsuniqueid=109be36e-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de] >>>> Looks like there was a replication conflict, please see >>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html >>>> how to resolve it. >>>> >>> % ldapsearch -D "cn=directory manager" -w secret -b "dc=example,dc=de" >>> "nsds5ReplConflict=*" \* nsds5ReplConflict | grep nsds5ReplConflict | wc -l >>> 26 >>> >> PS: >> >> nsds5ReplConflict: namingConflict >> cn=ipaservers,cn=hostgroups,cn=accounts,dc=example,dc=de >> nsds5ReplConflict: namingConflict cn=ipaservers,cn=ng,cn=alt,dc=example,dc=de >> nsds5ReplConflict: namingConflict >> cn=domain,cn=topology,cn=ipa,cn=etc,dc=example,dc=de >> nsds5ReplConflict: namingConflict cn=locations,cn=etc,dc=example,dc=de >> nsds5ReplConflict: namingConflict cn=dns >> administrators,cn=privileges,cn=pbac,dc=example,dc=de >> nsds5ReplConflict: namingConflict cn=dns >> servers,cn=privileges,cn=pbac,dc=example,dc=de >> nsds5ReplConflict: namingConflict cn=cas,cn=ca,dc=example,dc=de >> nsds5ReplConflict: namingConflict cn=custodia,cn=ipa,cn=etc,dc=example,dc=de >> nsds5ReplConflict: namingConflict >> cn=dogtag,cn=custodia,cn=ipa,cn=etc,dc=example,dc=de >> nsds5ReplConflict: namingConflict cn=system: add >> ca,cn=permissions,cn=pbac,dc=example,dc=de >> nsds5ReplConflict: namingConflict cn=system: delete >> ca,cn=permissions,cn=pbac,dc=example,dc=de >> nsds5ReplConflict: namingConflict cn=system: modify >> ca,cn=permissions,cn=pbac,dc=example,dc=de >> nsds5ReplConflict: namingConflict cn=system: read >> cas,cn=permissions,cn=pbac,dc=example,dc=de >> nsds5ReplConflict: namingConflict cn=system: modify dns servers >> configuration,cn=permissions,cn=pbac,dc=example,dc=de >> nsds5ReplConflict: namingConflict cn=system: read dns servers >> configuration,cn=permissions,cn=pbac,dc=example,dc=de >> nsds5ReplConflict: namingConflict cn=System: Manage Host >> Principals,cn=permissions,cn=pbac,dc=example,dc=de >> nsds5ReplConflict: namingConflict cn=System: Add IPA >> Locations,cn=permissions,cn=pbac,dc=example,dc=de >> nsds5ReplConflict: namingConflict cn=System: Modify IPA >> Locations,cn=permissions,cn=pbac,dc=example,dc=de >> nsds5ReplConflict: namingConflict cn=System: Read IPA >> Locations,cn=permissions,cn=pbac,dc=example,dc=de >> nsds5ReplConflict: namingConflict cn=System: Remove IPA >> Locations,cn=permissions,cn=pbac,dc=example,dc=de >> nsds5ReplConflict: namingConflict cn=System: Read Locations of IPA >> Servers,cn=permissions,cn=pbac,dc=example,dc=de >> nsds5ReplConflict: namingConflict cn=System: Read Status of Services on IPA >> Servers,cn=permissions,cn=pbac,dc=example,dc=de >> nsds5ReplConflict: namingConflict cn=System: Manage Service >> Principals,cn=permissions,cn=pbac,dc=example,dc=de >> nsds5ReplConflict: namingConflict cn=System: Manage User >> Principals,cn=permissions,cn=pbac,dc=example,dc=de >> >> This looks like a problem of ipa-server-install. These entries were created >> in the very first seconds. > Conflict entries are created if an entry is added on different servers at the > "same time", where same time means it is created on instance x before the add > of the entry on instance y was replicated to x. This can happen if you run > things in parallel, eg upgrades. > You mean Freeipa has a race condition? I use tools like clusterssh to install or upgrade several hosts in parallel (n <= 49 due to available screen and font size). The "same time" is built in. Of course I understand that Freeipa is a special case, because it is network application, but it should be able to handle n = 2. > There is no simple way to get rid of them,
Re: [Freeipa-users] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]
On 01/17/17 16:12, Harald Dunkel wrote: > On 01/17/17 11:38, Sumit Bose wrote: >> On Tue, Jan 17, 2017 at 10:44:14AM +0100, Harald Dunkel wrote: >>> It seems something got corrupted in my ipa setup. I found this in the >>> sssd log file on Wheezy: >>> >>> (Tue Jan 17 10:19:02 2017) [hbac_shost_attrs_to_rule] (0x0400): Processing >>> source hosts for rule [allow_all] >>> (Tue Jan 17 10:19:02 2017) [hbac_eval_user_element] (0x0080): Parse error >>> on [cn=System: Manage Host >>> Principals+nsuniqueid=109be36e-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de] >> >> Looks like there was a replication conflict, please see >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html >> how to resolve it. >> > > % ldapsearch -D "cn=directory manager" -w secret -b "dc=example,dc=de" > "nsds5ReplConflict=*" \* nsds5ReplConflict | grep nsds5ReplConflict | wc -l > 26 > PS: nsds5ReplConflict: namingConflict cn=ipaservers,cn=hostgroups,cn=accounts,dc=example,dc=de nsds5ReplConflict: namingConflict cn=ipaservers,cn=ng,cn=alt,dc=example,dc=de nsds5ReplConflict: namingConflict cn=domain,cn=topology,cn=ipa,cn=etc,dc=example,dc=de nsds5ReplConflict: namingConflict cn=locations,cn=etc,dc=example,dc=de nsds5ReplConflict: namingConflict cn=dns administrators,cn=privileges,cn=pbac,dc=example,dc=de nsds5ReplConflict: namingConflict cn=dns servers,cn=privileges,cn=pbac,dc=example,dc=de nsds5ReplConflict: namingConflict cn=cas,cn=ca,dc=example,dc=de nsds5ReplConflict: namingConflict cn=custodia,cn=ipa,cn=etc,dc=example,dc=de nsds5ReplConflict: namingConflict cn=dogtag,cn=custodia,cn=ipa,cn=etc,dc=example,dc=de nsds5ReplConflict: namingConflict cn=system: add ca,cn=permissions,cn=pbac,dc=example,dc=de nsds5ReplConflict: namingConflict cn=system: delete ca,cn=permissions,cn=pbac,dc=example,dc=de nsds5ReplConflict: namingConflict cn=system: modify ca,cn=permissions,cn=pbac,dc=example,dc=de nsds5ReplConflict: namingConflict cn=system: read cas,cn=permissions,cn=pbac,dc=example,dc=de nsds5ReplConflict: namingConflict cn=system: modify dns servers configuration,cn=permissions,cn=pbac,dc=example,dc=de nsds5ReplConflict: namingConflict cn=system: read dns servers configuration,cn=permissions,cn=pbac,dc=example,dc=de nsds5ReplConflict: namingConflict cn=System: Manage Host Principals,cn=permissions,cn=pbac,dc=example,dc=de nsds5ReplConflict: namingConflict cn=System: Add IPA Locations,cn=permissions,cn=pbac,dc=example,dc=de nsds5ReplConflict: namingConflict cn=System: Modify IPA Locations,cn=permissions,cn=pbac,dc=example,dc=de nsds5ReplConflict: namingConflict cn=System: Read IPA Locations,cn=permissions,cn=pbac,dc=example,dc=de nsds5ReplConflict: namingConflict cn=System: Remove IPA Locations,cn=permissions,cn=pbac,dc=example,dc=de nsds5ReplConflict: namingConflict cn=System: Read Locations of IPA Servers,cn=permissions,cn=pbac,dc=example,dc=de nsds5ReplConflict: namingConflict cn=System: Read Status of Services on IPA Servers,cn=permissions,cn=pbac,dc=example,dc=de nsds5ReplConflict: namingConflict cn=System: Manage Service Principals,cn=permissions,cn=pbac,dc=example,dc=de nsds5ReplConflict: namingConflict cn=System: Manage User Principals,cn=permissions,cn=pbac,dc=example,dc=de This looks like a problem of ipa-server-install. These entries were created in the very first seconds. Harri -- 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] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]
On 01/17/17 11:38, Sumit Bose wrote: > On Tue, Jan 17, 2017 at 10:44:14AM +0100, Harald Dunkel wrote: >> It seems something got corrupted in my ipa setup. I found this in the >> sssd log file on Wheezy: >> >> (Tue Jan 17 10:19:02 2017) [hbac_shost_attrs_to_rule] (0x0400): Processing >> source hosts for rule [allow_all] >> (Tue Jan 17 10:19:02 2017) [hbac_eval_user_element] (0x0080): Parse error on >> [cn=System: Manage Host >> Principals+nsuniqueid=109be36e-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de] > > Looks like there was a replication conflict, please see > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html > how to resolve it. > % ldapsearch -D "cn=directory manager" -w secret -b "dc=example,dc=de" "nsds5ReplConflict=*" \* nsds5ReplConflict | grep nsds5ReplConflict | wc -l 26 :-( I have 4 ipa servers. How can I make sure that no new problem arises while I try to cleanup this mess? Can I freeze Freeipa somehow to resolve this? > We already have a ticket for SSSD to ignore those object, but > unfortunately there is currently no patch available for SSSD so you have > to resolve the replication conflict to get it working again. > You mean sssd should ignore the conflict, not telling anybody? I am not sure if thats the right way. Thanx very much for your advice Harri -- 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] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]
It seems something got corrupted in my ipa setup. I found this in the sssd log file on Wheezy: (Tue Jan 17 10:19:02 2017) [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule [allow_all] (Tue Jan 17 10:19:02 2017) [hbac_eval_user_element] (0x0080): Parse error on [cn=System: Manage Host Principals+nsuniqueid=109be36e-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de] (Tue Jan 17 10:19:02 2017) [hbac_ctx_to_rules] (0x0020): Could not construct eval request (Tue Jan 17 10:19:02 2017) [ipa_hbac_evaluate_rules] (0x0020): Could not construct HBAC rules (Tue Jan 17 10:19:02 2017) [be_pam_handler_callback] (0x0100): Backend returned: (3, 4, ) [Internal Error (System error)] (Tue Jan 17 10:19:02 2017) [be_pam_handler_callback] (0x0100): Sending result [4][example.de] (Tue Jan 17 10:19:02 2017) [be_pam_handler_callback] (0x0100): Sent result [4][example.de] This happens on a login via ssh, or if I run "su - username" as root. The su session gives just a warning, but for sshd I have to disable pam to allow remote logins. Complete log is attached, of course. Every helpful comment is highly appreciated. Harri (Tue Jan 17 10:19:01 2017) [sssd[be[example.de]]] [be_get_account_info] (0x0100): Got request for [3][1][name=jupp] (Tue Jan 17 10:19:01 2017) [sssd[be[example.de]]] [sdap_get_initgr_next_base] (0x0400): Searching for users with base [cn=accounts,dc=example,dc=de] (Tue Jan 17 10:19:01 2017) [sssd[be[example.de]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=jupp)(objectclass=posixAccount))][cn=accounts,dc=example,dc=de]. (Tue Jan 17 10:19:01 2017) [sssd[be[example.de]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Tue Jan 17 10:19:01 2017) [sssd[be[example.de]]] [sdap_save_user] (0x0400): Storing info for user jupp (Tue Jan 17 10:19:01 2017) [sssd[be[example.de]]] [sdap_has_deref_support] (0x0400): The server supports deref method OpenLDAP (Tue Jan 17 10:19:01 2017) [sssd[be[example.de]]] [sdap_x_deref_search_send] (0x0400): Dereferencing entry [uid=jupp,cn=users,cn=accounts,dc=example,dc=de] using OpenLDAP deref (Tue Jan 17 10:19:01 2017) [sssd[be[example.de]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [no filter][uid=jupp,cn=users,cn=accounts,dc=example,dc=de]. (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [sdap_x_deref_parse_entry] (0x0400): Got deref control (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [sdap_parse_deref] (0x0080): Dereferenced entry [cn=User Administrator,cn=roles,cn=accounts,dc=example,dc=de] has no attributes (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [sdap_x_deref_parse_entry] (0x0040): sdap_parse_deref failed [22]: Invalid argument (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [sdap_get_generic_ext_done] (0x0020): reply parsing callback failed. (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [sdap_x_deref_search_done] (0x0100): sdap_get_generic_ext_recv failed [22]: Invalid argument (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [sdap_deref_search_done] (0x0040): dereference processing failed [22]: Invalid argument (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,22,Init Groups Failed (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [be_pam_handler] (0x0100): Got request with the following data (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [pam_print_data] (0x0100): domain: example.de (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [pam_print_data] (0x0100): user: jupp (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [pam_print_data] (0x0100): service: su (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [pam_print_data] (0x0100): tty: /dev/pts/4 (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [pam_print_data] (0x0100): ruser: root (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [pam_print_data] (0x0100): rhost: (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [pam_print_data] (0x0100): authtok type: 0 (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [pam_print_data] (0x0100): authtok size: 0 (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [pam_print_data] (0x0100): newauthtok size: 0 (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [pam_print_data] (0x0100): priv: 1 (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [pam_print_data] (0x0100): cli_pid: 15885 (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [sdap_access_send] (0x0400): Performing access check for user [jupp] (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [sdap_account_expired_rhds] (0x0400): Performing RHDS access check for user [jupp] (Tue Jan 17 10:19:02 2017) [sssd[be[example.de]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
Re: [Freeipa-users] core dump within ipa-backup
On 08/08/2016 03:28 PM, Martin Basti wrote: > > > On 08.08.2016 13:28, Harald Dunkel wrote: >> Hi Martin, >> >> On 08/08/2016 09:41 AM, Martin Basti wrote: >>> Hello, this is probably issue https://fedorahosted.org/389/ticket/48388 >>> >>> It was fixed, but IMO not backported to centos7.2 >>> >>> Martin >>> >>> >>> >> Does it put my ipa installation at risk? Are the backups >> generated by ipa-backup corrupted? > IMO it is affected, but dirsrv people may know more details, I would ask in > ticket I posted. > Seriously, this was not fixed in Redhat's current distro, putting freeipa's backup procedure at risk? I am still waiting for the confirmation mail for the signup procedure ... Thanx anyway Harri -- 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] core dump within ipa-backup
Hi Martin, On 08/08/2016 09:41 AM, Martin Basti wrote: > Hello, this is probably issue https://fedorahosted.org/389/ticket/48388 > > It was fixed, but IMO not backported to centos7.2 > > Martin > > > Does it put my ipa installation at risk? Are the backups generated by ipa-backup corrupted? Regards Harri -- 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] ldapsearch in cron job woes about no credentials
Hi Alexander, thanx very much for your detailed answer. There is one problem, though: gss-proxy is not available for most of my systems (Debian, Ubuntu, RedHat 6, ...). Its not in sssd 1.13.4, so I wonder if gss-proxy a part of the most recent freeipa releases? Regards Harri -- 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] ldapsearch in cron job woes about no credentials
On 06/09/16 15:16, Harald Dunkel wrote: > Hi folks, > > Platform: freeipa 4.2 (Centos7) > > Problem: My cron job needs a ticket to run ldapsearch. The > error message is: > > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Local error (-2) > additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified > GSS failure. Minor code may provide more information (No Kerberos > credentials available) > > Google pointed me to this solution > > http://www.cmf.nrl.navy.mil/krb/kerberos-faq.html#kerbcron > > I wonder what is the "freeipa way" to handle this scenario, > esp. how to generate the additional kerberos entry without > confusing FreeIPA? Maybe I am too blind to see, but I haven't > found this problem in the FAQs. > Too much noob? Harri -- 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] ldapsearch in cron job woes about no credentials
Hi folks, Platform: freeipa 4.2 (Centos7) Problem: My cron job needs a ticket to run ldapsearch. The error message is: SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available) Google pointed me to this solution http://www.cmf.nrl.navy.mil/krb/kerberos-faq.html#kerbcron I wonder what is the "freeipa way" to handle this scenario, esp. how to generate the additional kerberos entry without confusing FreeIPA? Maybe I am too blind to see, but I haven't found this problem in the FAQs. Every helpful comment is highly appreciated. Harri -- 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 -v ping lies about the cert database
On 05/13/16 14:48, Lukas Slebodnik wrote: > You might see in ticket that planned milestone is "Future Releases" > that isn't any particular release (4.4.x ...) > > It basically mean that patches are welcome. > That's how it works in open source world. > > LS > Sorry, I got confused about the comment on https://bugzilla.redhat.com/show_bug.cgi?id=1296665. I thought the "Changing version to '24'." means it is supposed to be fixed for F24. This bug was reported >4 months ago. Regards Harri -- 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] sssd went away, failed to restart
On 05/13/16 14:45, Lukas Slebodnik wrote: > On (12/05/16 15:35), Harald Dunkel wrote: >> On 05/12/16 13:48, Lukas Slebodnik wrote: > >>> I would like to fix it but I do not know what to fix. >>> >>> Is there anything interesting/suspicious in syslog/journald >>> from the same time? >>> >> >> "journalctl -u sssd" says >> > It is not helpful either. > We asked to find *ANYTHING* interesting/suspicious in syslog/journald > So it needn't be related to sssd. > Understood. Below is the complete journalctl and syslog from reboot till sssd being marked as failed by systemd. The only problems I see in between are the authentication failures and "user unknown" error messages. The log files on the ipa servers don't show any signs of a problem either (esp. krb5kdc.log, the slapd log files, and kernel.log of the ipa1 server). > It can be realted to swapping, out of entropy, disk needs to spin up, > high load, DNS not responding, whatever > > But it's task for you to find out what trigger the problem. > We do not have an access to problematic machines. > Does it really matter *why* this host is slow or why ipa1 didn't answer? My point is that sssd should be sufficiently stable to startup even when its slow "somehow" and when the first ipa server it tried appears to be unreachable. Looking at the log files I have the impression that ipa2 works as expected, and yet sssd on the client went Guru for some reason it didn't write into the log file. > So try to find a reason which trigger the problem and provide > reasonable reproducer. > I'd love to give you more information, but this is a production system. Rebooting the host to find some way to reproduce the problem is painful for a lot of people. Since the client runs Jessie I will try to backport Timo's freeipa 4.3.1 packages for Debian/Ubuntu. sssd is already up-to-date. ipa1 and ipa2 are running Centos 7 and freeipa 4.2; hopefully thats OK. And I am setting up additional servers ipa3 and ipa4 to improve availability. Regards Harri -- Logs begin at Sat 2016-05-07 01:00:34 CEST, end at Fri 2016-05-13 20:14:51 CEST. -- May 12 06:01:57 srvvm01.ac.example.com systemd-journal[24]: Runtime journal is using 8.0M (max allowed 3.1G, trying to leave 4.0G free of 31.4G available → current limit 3.1G). May 12 06:01:57 srvvm01.ac.example.com systemd-journal[24]: Runtime journal is using 8.0M (max allowed 3.1G, trying to leave 4.0G free of 31.4G available → current limit 3.1G). May 12 06:01:57 srvvm01.ac.example.com systemd-journal[24]: Journal started May 12 06:01:57 srvvm01.ac.example.com systemd[1]: Mounted Debug File System. May 12 06:01:57 srvvm01.ac.example.com systemd[1]: Mounted Huge Pages File System. May 12 06:01:57 srvvm01.ac.example.com systemd[1]: Mounted POSIX Message Queue File System. May 12 06:01:57 srvvm01.ac.example.com systemd[1]: Started Remount Root and Kernel File Systems. May 12 06:01:57 srvvm01.ac.example.com systemd[1]: Started Various fixups to make systemd work better on Debian. May 12 06:01:57 srvvm01.ac.example.com systemd[1]: Starting Load/Save Random Seed... May 12 06:01:57 srvvm01.ac.example.com systemd[1]: Starting Local File Systems (Pre). May 12 06:01:57 srvvm01.ac.example.com systemd[1]: Reached target Local File Systems (Pre). May 12 06:01:57 srvvm01.ac.example.com systemd[1]: Starting Local File Systems. May 12 06:01:57 srvvm01.ac.example.com systemd[1]: Reached target Local File Systems. May 12 06:01:57 srvvm01.ac.example.com systemd[1]: Starting Remote File Systems. May 12 06:01:57 srvvm01.ac.example.com systemd[1]: Started Trigger Flushing of Journal to Persistent Storage. May 12 06:02:06 srvvm01.ac.example.com systemd-journal[24]: Permanent journal is using 2.4G (max allowed 2.0G, trying to leave 4.0G free of 2.1T available → current limit 2.4G). May 12 06:02:14 srvvm01.ac.example.com systemd-journal[24]: Time spent on flushing to /var is 8.301385s for 16 entries. May 12 06:01:59 srvvm01.ac.example.com logger[65]: /etc/resolvconf/update-libc.d/sendmail (dynamic) update_resolv: May 12 06:01:59 srvvm01.ac.example.com logger[66]: /etc/resolvconf/update-libc.d/sendmail (dynamic) update_sendmail: May 12 06:02:15 srvvm01.ac.example.com logger[94]: /etc/network/if-up.d/sendmail (dynamic) update_interface: lo up May 12 06:02:15 srvvm01.ac.example.com logger[95]: /etc/network/if-up.d/sendmail (dynamic) update_sendmail: lo up May 12 06:02:15 srvvm01.ac.example.com logger[132]: /etc/resolvconf/update-libc.d/sendmail (dynamic) update_resolv: May 12 06:02:15 srvvm01.ac.example.com logger[133]: /etc/resolvconf/update-libc.d/sendmail (dynamic) update_sendmail: May 12 06:02:15 srvvm01.ac.example.com logger[145]: /etc/network/if-up.d/sendmail (dynamic) update_interface: eth0 up May 12 06:02:15 srvvm01.ac.example.com logger[146]: /etc/network/if-up.d/sendmail (dynamic) update_pro
Re: [Freeipa-users] ipa -v ping lies about the cert database
On 04/26/16 17:29, Timo Aaltonen wrote: > > I guess 4.3.1 would need to be in sid first, and it just got rejected > because of the minified javascript (bug #787593). Don't know when > that'll get fixed. > Since 24beta is out without fixing https://fedorahosted.org/freeipa/ticket/5639 I wonder if the Fedora folks really care about this bug. Did they kick out the freeipa RPMs for breaking the guidelines? Do you think it would be possible to put freeipa packages suitable for Debian/sid & Ubuntu on freeipa.org, in parallel to the RPMs for Fedora? Regards Harri -- 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] sssd went away, failed to restart
On 05/12/16 13:48, Lukas Slebodnik wrote: > It would be nice if you could provide reliable reproducer. > I'm sorry we do not have a crystall ball and sssd log files > did not help either. They are truncated. > Thats all I got. > I would like to fix it but I do not know what to fix. > > Is there anything interesting/suspicious in syslog/journald > from the same time? > "journalctl -u sssd" says May 12 06:03:15 srvvm01.ac.example.com sssd[373]: Starting up May 12 06:03:21 srvvm01.ac.example.com sssd[be[417]: Starting up May 12 06:03:26 srvvm01.ac.example.com sssd[438]: Starting up May 12 06:03:26 srvvm01.ac.example.com sssd[440]: Starting up May 12 06:03:26 srvvm01.ac.example.com sssd[437]: Starting up May 12 06:03:26 srvvm01.ac.example.com sssd[439]: Starting up May 12 06:03:29 srvvm01.ac.example.com sssd[441]: Starting up May 12 06:03:39 srvvm01.ac.example.com sssd_be[417]: GSSAPI client step 1 May 12 06:03:39 srvvm01.ac.example.com sssd_be[417]: GSSAPI client step 1 May 12 06:03:39 srvvm01.ac.example.com sssd_be[417]: GSSAPI client step 1 May 12 06:03:39 srvvm01.ac.example.com sssd_be[417]: GSSAPI client step 2 May 12 06:04:05 srvvm01.ac.example.com systemd[1]: sssd.service start operation timed out. Terminating. May 12 06:04:05 srvvm01.ac.example.com sssd[438]: Shutting down May 12 06:04:05 srvvm01.ac.example.com sssd[437]: Shutting down May 12 06:04:05 srvvm01.ac.example.com sssd[be[417]: Shutting down May 12 06:04:05 srvvm01.ac.example.com systemd[1]: Failed to start System Security Services Daemon. May 12 06:04:05 srvvm01.ac.example.com systemd[1]: Unit sssd.service entered failed state. AFAICS we have to focus in sssd_example.com.log on the log file entries between 06:03:29 and 06:04:05. Did you notice the "Backend is online, starting delayed online authentication" close to the end of the log file? Is this expected? What should have happened next? : : >> You have cut off the time stamps. Here they are: >> > That was on purpose. Because it's clear that "Communication with KDC timed > out" > The question is why? > 6 seconds must be enough unless you try to connect the the server > which is located in opposite site of globe. > Sorry to say, but this assumption is not justified. Next to network lag there can be other delays (swapped out jobs, out of entropy on /dev/random, a disk needs to spin up, high load, DNS not responding, whatever). Would you agree that this is OT, since sssd *did* find ipa1 within a reasonable time? Regards Harri -- 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] sssd went away, failed to restart
On 05/12/16 10:26, Lukas Slebodnik wrote: > On (12/05/16 09:42), Harald Dunkel wrote: >> >> It happened again :-(.This *really* needs to be fixed. >> I wouldn't like to move back to ypbind. >> > I would like to If I knew what to fix and how to reliably reproduce. > It would be very nice if sssd could become more reliable at startup time. It gives up to easy. And it is not restarted in case of a problem, which is fatal for a service providing access to a user database. >> Logfiles are attached. sssd is version 1.13.3. The server >> was rebooted at 05:56. At 06:03:18 sssd wrote the first >> logfile entries. >> > I cannot see in log files that sssd was started. : : (Thu May 12 05:56:12 2016) [sssd] [monitor_quit] (0x0020): Child [sudo] exited gracefully (Thu May 12 05:56:12 2016) [sssd] [monitor_quit] (0x0020): Terminating [nss][441] (Thu May 12 05:56:12 2016) [sssd] [monitor_quit] (0x0020): Child [nss] exited gracefully (Thu May 12 06:03:18 2016) [sssd] [sysdb_domain_init_internal] (0x0200): DB File for example.com: /var/lib/sss/db/cache_example.com.ldb (Thu May 12 06:03:20 2016) [sssd] [get_ping_config] (0x0100): Time between service pings for [example.com]: [10] (Thu May 12 06:03:20 2016) [sssd] [get_ping_config] (0x0100): Time between SIGTERM and SIGKILL for [example.com]: [60] (Thu May 12 06:03:20 2016) [sssd] [start_service] (0x0100): Queueing service example.com for startup (Thu May 12 06:03:22 2016) [sssd] [sbus_server_init_new_connection] (0x0200): Entering. : : > Log files seems to be truncated and there seems to be probllem > with network communication. > > [be_resolve_server_process] (0x0200): Found address for server > ipa2.example.com: [172.29.96.4] TTL 7200 > [init_timeout] (0x0040): Client timed out before Identification [0x12d50c0]! > [sdap_kinit_done] (0x0080): Communication with KDC timed out, trying the next > one > [fo_set_port_status] (0x0100): Marking port 389 of server 'ipa2.example.com' > as 'not working' > You have cut off the time stamps. Here they are: (Thu May 12 06:03:31 2016) [sssd[be[example.com]]] [be_resolve_server_process] (0x0200): Found address for server ipa2.example.com: [172.29.96.4] TTL 7200 (Thu May 12 06:03:36 2016) [sssd[be[example.com]]] [init_timeout] (0x0040): Client timed out before Identification [0x12d50c0]! (Thu May 12 06:03:37 2016) [sssd[be[example.com]]] [sdap_kinit_done] (0x0080): Communication with KDC timed out, trying the next one (Thu May 12 06:03:37 2016) [sssd[be[example.com]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'ipa2.example.com' as 'not working' Obviously the 5 secs timeout is not sufficient for stable operation. I am not sure if thats the reason for sssd to go away, though. > Do you have mounted nfs on /var/log/ or anywhere else? Surely not. All mount points are local. > It can explain a lot if there are network related issues. > I don't see why there should be any network related issues. The ipa servers were available all the time. The network is configured static. Regards Harri -- 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] sssd went away, failed to restart
Hi folks, On 02/23/16 13:46, Lukas Slebodnik wrote: > On (23/02/16 13:01), Harald Dunkel wrote: >> On 02/23/2016 11:58 AM, Lukas Slebodnik wrote: >>> I would rather focus on different thing. >>> Why is sssd_be process blocked for long time? >>> >> >> I have no idea. Was it really blocked? >> > It needn't be blocked itself. But it was busy > with some non-blocking operation which main process > considered as bad state. > > Would you mind to share sssd log files with > high debug level? > It happened again :-(.This *really* needs to be fixed. I wouldn't like to move back to ypbind. Logfiles are attached. sssd is version 1.13.3. The server was rebooted at 05:56. At 06:03:18 sssd wrote the first logfile entries. Every helpful comment is highly appreciated. Harri (Thu May 12 05:55:10 2016) [sssd] [message_type] (0x0200): netlink Message type: 24 (Thu May 12 05:55:40 2016) [sssd] [message_type] (0x0200): netlink Message type: 24 (Thu May 12 05:55:48 2016) [sssd] [message_type] (0x0200): netlink Message type: 25 (Thu May 12 05:56:05 2016) [sssd] [monitor_quit_signal] (0x0040): Monitor received Terminated: terminating children (Thu May 12 05:56:05 2016) [sssd] [monitor_quit] (0x0040): Returned with: 0 (Thu May 12 05:56:05 2016) [sssd] [monitor_quit] (0x0020): Terminating [example.com][51281] (Thu May 12 05:56:05 2016) [sssd] [monitor_quit] (0x0020): Child [example.com] exited gracefully (Thu May 12 05:56:05 2016) [sssd] [monitor_quit] (0x0020): Terminating [pac][445] (Thu May 12 05:56:12 2016) [sssd] [monitor_quit] (0x0020): Child [pac] terminated with a signal (Thu May 12 05:56:12 2016) [sssd] [monitor_quit] (0x0020): Terminating [ssh][444] (Thu May 12 05:56:12 2016) [sssd] [monitor_quit] (0x0020): Child [ssh] exited gracefully (Thu May 12 05:56:12 2016) [sssd] [monitor_quit] (0x0020): Terminating [pam][443] (Thu May 12 05:56:12 2016) [sssd] [monitor_quit] (0x0020): Child [pam] exited gracefully (Thu May 12 05:56:12 2016) [sssd] [monitor_quit] (0x0020): Terminating [sudo][442] (Thu May 12 05:56:12 2016) [sssd] [monitor_quit] (0x0020): Child [sudo] exited gracefully (Thu May 12 05:56:12 2016) [sssd] [monitor_quit] (0x0020): Terminating [nss][441] (Thu May 12 05:56:12 2016) [sssd] [monitor_quit] (0x0020): Child [nss] exited gracefully (Thu May 12 06:03:18 2016) [sssd] [sysdb_domain_init_internal] (0x0200): DB File for example.com: /var/lib/sss/db/cache_example.com.ldb (Thu May 12 06:03:20 2016) [sssd] [get_ping_config] (0x0100): Time between service pings for [example.com]: [10] (Thu May 12 06:03:20 2016) [sssd] [get_ping_config] (0x0100): Time between SIGTERM and SIGKILL for [example.com]: [60] (Thu May 12 06:03:20 2016) [sssd] [start_service] (0x0100): Queueing service example.com for startup (Thu May 12 06:03:22 2016) [sssd] [sbus_server_init_new_connection] (0x0200): Entering. (Thu May 12 06:03:22 2016) [sssd] [sbus_server_init_new_connection] (0x0200): Adding connection 0x10f2a40. (Thu May 12 06:03:22 2016) [sssd] [sbus_server_init_new_connection] (0x0200): Got a connection (Thu May 12 06:03:25 2016) [sssd] [services_startup_timeout] (0x0020): Providers did not start in time, forcing services startup! (Thu May 12 06:03:25 2016) [sssd] [services_startup_timeout] (0x0100): Now starting services! (Thu May 12 06:03:25 2016) [sssd] [get_ping_config] (0x0100): Time between service pings for [nss]: [10] (Thu May 12 06:03:25 2016) [sssd] [get_ping_config] (0x0100): Time between SIGTERM and SIGKILL for [nss]: [60] (Thu May 12 06:03:25 2016) [sssd] [start_service] (0x0100): Queueing service nss for startup (Thu May 12 06:03:25 2016) [sssd] [get_ping_config] (0x0100): Time between service pings for [sudo]: [10] (Thu May 12 06:03:25 2016) [sssd] [get_ping_config] (0x0100): Time between SIGTERM and SIGKILL for [sudo]: [60] (Thu May 12 06:03:25 2016) [sssd] [start_service] (0x0100): Queueing service sudo for startup (Thu May 12 06:03:25 2016) [sssd] [get_ping_config] (0x0100): Time between service pings for [pam]: [10] (Thu May 12 06:03:25 2016) [sssd] [get_ping_config] (0x0100): Time between SIGTERM and SIGKILL for [pam]: [60] (Thu May 12 06:03:25 2016) [sssd] [start_service] (0x0100): Queueing service pam for startup (Thu May 12 06:03:25 2016) [sssd] [get_ping_config] (0x0100): Time between service pings for [ssh]: [10] (Thu May 12 06:03:25 2016) [sssd] [get_ping_config] (0x0100): Time between SIGTERM and SIGKILL for [ssh]: [60] (Thu May 12 06:03:25 2016) [sssd] [start_service] (0x0100): Queueing service ssh for startup (Thu May 12 06:03:25 2016) [sssd] [get_ping_config] (0x0100): Time between service pings for [pac]: [10] (Thu May 12 06:03:25 2016) [sssd] [get_ping_config] (0x0100): Time between SIGTERM and SIGKILL for [pac]: [60] (Thu May 12 06:03:25 2016) [sssd] [start_service] (0x0100): Queueing service pac for startup (Thu May 12 06:03:26 2016) [sssd] [sbus_server_init_new_connection] (0x0200): Entering. (Thu May 12 06:03:26 2016) [ss
[Freeipa-users] running ipa without local ntp on LXC (debian)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi folks, the freeipa packages for client and server on Debian depend upon ntp. Is this hard requirement really necessary? Usually ntp is useless in containers (e.g. LXC), since the hardware access is not permitted and since there is exactly one system time managed by dom0. I understand that having the exact time is essential for Kerberos, but the install-server and install-client scripts are very verbose about not having ntp installed. That should be sufficient. I would suggest to drop the hard requirement for ntp in freeipa's debian/control. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJXLyPBAAoJEAqeKp5m04HLsWQIAIzSXjX8l3DtN7ARih6nm7eO NNIy/siHm0V3jepusjMXFdRT1M4IFBG0iGfZbfjdmhBl58OqAxpCVR3W8noh6RNN pbeAHat5SuJdGyFJuCQFjCXs/+k4sL/Qn0irO+5gudH5YeuGa4oP5W6DefBT0I+x DuOTMmpB3USpdnF19wscKusb80u9VSbmaePymH7Wze/NE2T9hWkofBjqfJgC338V iF0PvDWP9KCoWIDBhXgZQv+8BuOXGA2K7m2JoLiHfZyPTPIhFncG1LCqhm/u86r4 RQEEBVOjNntWDbY9zqQLs8BM8QKpEj6jmKa3AiNcxWPdgAwHMkpQPe5P+Gq4Ks8= =EGCL -END PGP SIGNATURE- -- 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] cron reports "ORPHAN (no passwd entry)" for the @reboot jobs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Lukas, On 05/03/16 10:21, Lukas Slebodnik wrote: > But that's not a problem of sssd. It bug in cron service file. If cron relies > on user lookup then it shoudl not be started before nss-user-lookup.target. > > Fedora has correct service file for crond. > > sh$ systemctl cat crond.service # /usr/lib/systemd/system/crond.service > [Unit] Description=Command Scheduler After=auditd.service > nss-user-lookup.target systemd-user-sessions.service time-sync.target > ypbind.service > > [Service] EnvironmentFile=/etc/sysconfig/crond ExecStart=/usr/sbin/crond -n > $CRONDARGS ExecReload=/bin/kill -HUP $MAINPID KillMode=process > > [Install] WantedBy=multi-user.target > > Debian has quite minimal version sh$ systemctl cat cron.service # > /lib/systemd/system/cron.service [Unit] Description=Regular background > program processing daemon Documentation=man:cron(8) > > [Service] EnvironmentFile=-/etc/default/cron ExecStart=/usr/sbin/cron -f > $EXTRA_OPTS IgnoreSIGPIPE=false KillMode=process > > [Install] WantedBy=multi-user.target > Sorry, but thats not the case for the cron service installed on my systems. See the first post in this thread: This cron.service contains "Type=idle", i.e. cron is run after all the other services, including nss-user-lookup.target. See https://bugs.debian.org/767016 IMHO sssd is the only instance to exactly know *when* its user database is available. Before this state is reached it should not give up control to the nss-user-lookup.target. The output of "ps -ef" run by the cron job showed it does. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJXKOl5AAoJEAqeKp5m04HLm/EH/3lCCnOQXW+i2vU0KENvjXJf 05KlPABO8ZOZzC10do7c/JwCpHXBFJjZwtfID9BRezdJ5KXWV2B5mT7Z/dpiPy+R 2/GKhoaHPpW+v8ZZdgFyS4hlRrq4B/6/XRs3FFJ8V8AAI257ZY6efQQAuYjWfBVG Eya+BqxUcjCZfddYp7ZziKxzOs+kEnFiLwi3rKeeohUMWdLGBuETL8EwnTjqDbmV Qq0jswmzVM7mDZuC0ZehUuHlu5WNeAkjnFzi2owkZ7H42SXoRxoz+RjXUkfxfIP+ X33Jw6BABIbn03FfHOApblirmbrh6+uxrtZQEEucRRdpO9RF92czEK6RQc2JTiU= =4x+q -END PGP SIGNATURE- -- 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] cron reports "ORPHAN (no passwd entry)" for the @reboot jobs
Hi Lukas, On 05/02/16 17:59, Lukas Slebodnik wrote: > Could you provide output of "systemctl cat sssd.service"? > In my case, it should be started before nss-user-lookup.target > > # /usr/lib/systemd/system/sssd.service > [Unit] > Description=System Security Services Daemon > # SSSD must be running before we permit user sessions > Before=systemd-user-sessions.service nss-user-lookup.target > Wants=nss-user-lookup.target > > [Service] > EnvironmentFile=-/etc/sysconfig/sssd > ExecStart=/usr/sbin/sssd -D -f > # These two should be used with traditional UNIX forking daemons > # consult systemd.service(5) for more details > Type=forking > PIDFile=/var/run/sssd.pid > > [Install] > WantedBy=multi-user.target I got # /lib/systemd/system/sssd.service [Unit] Description=System Security Services Daemon # SSSD must be running before we permit user sessions Before=systemd-user-sessions.service nss-user-lookup.target Wants=nss-user-lookup.target [Service] EnvironmentFile=-/etc/sysconfig/sssd ExecStart=/usr/sbin/sssd -D -f # These two should be used with traditional UNIX forking daemons # consult systemd.service(5) for more details Type=forking PIDFile=/var/run/sssd.pid [Install] WantedBy=multi-user.target Except for the first comment line diff doesn't show a difference. Maybe there is a misunderstanding: IMHO its not sufficient to start sssd before systemd-user-sessions.service and nss-user-lookup.target. sssd and all its internal sssd_something services must have completed their initialization (including the user database) before these services can be started. Here is the output of "ps -ef", created by the "@reboot" crontab entry: UID PID PPID C STIME TTY TIME CMD root 1 0 0 14:27 ?00:00:00 /sbin/init root 23 1 0 14:27 ?00:00:00 /lib/systemd/systemd-journald root159 1 0 14:28 ?00:00:00 dhclient -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0 daemon 193 1 0 14:28 ?00:00:00 /usr/sbin/atd -f root194 1 0 14:28 ?00:00:00 /usr/sbin/cron -f root195 1 0 14:28 ?00:00:00 /usr/sbin/ModemManager root198 1 0 14:28 ?00:00:00 /usr/sbin/inetd -i root199 1 0 14:28 ?00:00:00 /usr/sbin/sshd -D root200 1 0 14:28 ?00:00:00 lldpd: monitor root201 1 0 14:28 ?00:00:00 /usr/sbin/sssd -D -f message+206 1 0 14:28 ?00:00:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation lp 218 1 0 14:28 ?00:00:00 /usr/sbin/lpd -s root220 1 0 14:28 ?00:00:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -c /var/lib/ntp/ntp.conf.dhcp -u 112:121 root226 1 0 14:28 ?00:00:00 /usr/sbin/certmonger -S -p /var/run/certmonger.pid -n root227 1 0 14:28 ?00:00:00 /usr/sbin/rsyslogd -n _lldpd 229200 0 14:28 ?00:00:00 lldpd: no neighbor root262 1 0 14:28 ?00:00:00 /usr/lib/policykit-1/polkitd --no-debug root263194 0 14:28 ?00:00:00 /usr/sbin/CRON -f zabbix 271 1 0 14:28 ?00:00:00 /usr/sbin/zabbix_agentd zabbix 274271 0 14:28 ?00:00:00 /usr/sbin/zabbix_agentd: collector [idle 1 sec] zabbix 275271 0 14:28 ?00:00:00 /usr/sbin/zabbix_agentd: listener #1 [waiting for connection] zabbix 276271 0 14:28 ?00:00:00 /usr/sbin/zabbix_agentd: listener #2 [waiting for connection] zabbix 277271 0 14:28 ?00:00:00 /usr/sbin/zabbix_agentd: listener #3 [waiting for connection] zabbix 278271 0 14:28 ?00:00:00 /usr/sbin/zabbix_agentd: active checks #1 [idle 1 sec] root492226 0 14:28 ?00:00:00 /usr/lib/x86_64-linux-gnu/certmonger/ipa-submit root502226 0 14:28 ?00:00:00 /usr/lib/x86_64-linux-gnu/certmonger/ipa-submit Debian-+504 1 0 14:28 ?00:00:00 /usr/sbin/exim4 -bd -q30m root505226 0 14:28 ?00:00:00 /usr/lib/x86_64-linux-gnu/certmonger/ipa-submit root506226 0 14:28 ?00:00:00 /usr/lib/x86_64-linux-gnu/certmonger/ipa-submit root507226 0 14:28 ?00:00:00 /usr/lib/x86_64-linux-gnu/certmonger/ipa-submit root508226 0 14:28 ?00:00:00 /usr/lib/x86_64-linux-gnu/certmonger/ipa-submit root509226 0 14:28 ?00:00:00 /usr/lib/x86_64-linux-gnu/certmonger/certmaster-submit root510263 0 14:28 ?00:00:00 /bin/sh -c ( ps -ef; ls -al /home ) >/var/tmp/ls.log root511510 0 14:28 ?00:00:00 /bin/sh -c ( ps -ef; ls -al /home ) >/var/tmp/ls.log root
[Freeipa-users] cron reports "ORPHAN (no passwd entry)" for the @reboot jobs
Hi folks, System: freeipa client, Debian 8 (using systemd), cron 3.0pl1-128, sssd 1.13.4-2 Problem: Cron fails to start a few "@reboot" jobs at boot time. cron.log shows: : May 2 13:36:48 fpsde8i002 anacron[197]: Anacron 2.3 started on 2016-05-02 May 2 13:36:48 fpsde8i002 anacron[197]: Normal exit (0 jobs run) May 2 13:36:48 fpsde8i002 cron[194]: (CRON) INFO (pidfile fd = 3) May 2 13:36:48 fpsde8i002 cron[194]: (user1) ORPHAN (no passwd entry) May 2 13:36:48 fpsde8i002 cron[194]: (user2) ORPHAN (no passwd entry) May 2 13:36:48 fpsde8i002 cron[194]: (CRON) INFO (Running @reboot jobs) : AFAICT cron is started last at boot time. cron.service is [Unit] Description=Regular background program processing daemon Documentation=man:cron(8) [Service] EnvironmentFile=-/etc/default/cron ExecStart=/usr/sbin/cron -f $EXTRA_OPTS IgnoreSIGPIPE=false KillMode=process Type=idle [Install] WantedBy=multi-user.target The "Type=idle" should make sure (https://wiki.archlinux.org/index.php/systemd). If I add a crontab entry "@reboot ( ps -ef; ls -al /home ) >/var/tmp/ls.log" for root, then the generated file reveals that sssd has been started, but its sssd_something services are not running. ls shows just the numerical UIDs instead of the login IDs. Sssd might have been started first, but apparently its not ready yet. Shouldn't it block at boot time for some time to make sure that all internal services are available? Every helpful comment is highly appreciated Harri -- 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 -v ping lies about the cert database
On 04/26/2016 05:29 PM, Timo Aaltonen wrote: > > I guess 4.3.1 would need to be in sid first, and it just got rejected > because of the minified javascript (bug #787593). Don't know when > that'll get fixed. > Is this 3rd party code? Anyway, I was talking about a *private* backport of freeipa 4.3.1 and its dependencies to Jessie. Of course I would be glad to make these backports available in the official jessie-backports as well, but I would need a sponsor for uploading. Regards Harri -- 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 -v ping lies about the cert database
Hi Timo, On 04/18/2016 02:08 PM, Timo Aaltonen wrote: > > The old package used to create /etc/pki/nssdb on postinst, but with 644 > permissions so I'm not sure why they have 600 here. 4.1.4 in > experimental migrated to /etc/ipa/nssdb, and I'm about to upload 4.3.1 > to unstable this week, which should fix this for good. > AFAICS there are just a few pending dependencies for 4.3.1 on Jessie. Would you recommend to backport? I already did it for sssd. Regards Harri -- 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 -v ping lies about the cert database
Hi David, > Hello Harri, > > the FreeIPA certificate database is stored in /etc/ipa/nssdb, by default the > permissions are set to: > > $ ls -dl /etc/ipa/nssdb/ > drwxr-xr-x. 2 root root 73 Apr 15 14:00 /etc/ipa/nssdb/ > > $ ls -l /etc/ipa/nssdb/ > total 80 > -rw-r--r--. 1 root root 65536 Apr 15 14:00 cert8.db > -rw-r--r--. 1 root root 16384 Apr 15 14:00 key3.db > -rw---. 1 root root40 Apr 15 14:00 pwdfile.txt > -rw-r--r--. 1 root root 16384 Apr 15 14:00 secmod.db > > Please check the permission on your system. If it's different and you (or > system admin) haven't changed it please file a ticket > (https://fedorahosted.org/freeipa/newticket). > Sorry, I should have mentioned that the client runs Debian with freeipa 4.0.5. # ls -al /etc/ipa/ total 24 drwxr-xr-x 2 root root 4096 Dec 29 08:32 . drwxr-xr-x 190 root root 12288 Apr 15 12:44 .. -rw-r--r-- 1 root root 1792 Dec 29 08:32 ca.crt -rw-r--r-- 1 root root 194 Dec 29 08:32 default.conf No nssdb. AFAICS only the ipa servers in my lan have a directory /etc/ipa/nssdb (CentOS 7). On the clients I can see a cert8.db in /etc/pki/nssdb. Looking at the time stamp it seems to be related to freeipa. # ls -al /etc/pki/nssdb/ total 76 drwxr-xr-x 2 root root 4096 Dec 29 08:32 . drwxr-xr-x 3 root root 4096 Dec 28 16:09 .. -rw--- 1 root root 65536 Dec 29 08:32 cert8.db -rw--- 1 root root 16384 Dec 29 08:32 key3.db -rw--- 1 root root 16384 Dec 29 08:32 secmod.db No pwdfile.txt . I would guess the key database has been created with --empty-password. Does this look familiar, or is this misconfigured and weird? Sorry for asking stupid questions, but the setup in my lan is all I have. I have never had a chance to see another freeipa installation. Hope you don't mind? Regards Harri -- 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] howto ldapsearch for disabled/enabled users?
Hi folks, I have no luck with the ipa cli, so I wonder if it is possible to ldapsearch for disabled or enabled users? A command line like ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=com uid=somebody doesn't show :-(. Every helpful hint is highly welcome Harri -- 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] ipa -v ping lies about the cert database
Hi folks, If I run "kinit admin; ipa -v ping" as a regular user, then I get ipa: INFO: trying https://ipa2.example.com/ipa/json ipa: INFO: Connection to https://ipa2.example.com/ipa/json failed with (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. ipa: INFO: trying https://ipa1.example.com/ipa/json ipa: INFO: Connection to https://ipa1.example.com/ipa/json failed with (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. ipa: ERROR: cannot connect to 'any of the configured servers': https://ipa2.example.com/ipa/json, https://ipa1.example.com/ipa/json Using root there is no problem. Obviously this is a Unix access problem, not an old database. I would like to avoid running maintenance scripts as root, if possible. The error message doesn't include any path information, so I wonder how I can fix the access problem without opening the system too wide? Every helpful hint is highly appreciated Harri -- 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] sssd.service start operation timed out
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Lukas, On 03/19/16 10:59, Lukas Slebodnik wrote: > On (19/03/16 10:38), Harald Dunkel wrote: > >> Since freeipa doesn't work with anything else but systemd its a little bit >> cheap now to say "not my problem", is it? >> > "freeipa-server" doesn't work with anything else but systemd. and > freeipa-client just configure sssd and few other services. > Without systemd: root@lxc31:~# ipa-client-install Traceback (most recent call last): File "/usr/sbin/ipa-client-install", line 2790, in sys.exit(main()) File "/usr/sbin/ipa-client-install", line 2771, in main rval = install(options, env, fstore, statestore) File "/usr/sbin/ipa-client-install", line 2006, in install ipaclient.ntpconf.check_timedate_services() File "/usr/lib/python2.7/dist-packages/ipaclient/ntpconf.py", line 183, in check_timedate_services if instance.is_enabled() or instance.is_running(): File "/usr/lib/python2.7/dist-packages/ipaplatform/base/services.py", line 321, in is_enabled self.service_instance(instance_name)]) File "/usr/lib/python2.7/dist-packages/ipapython/ipautil.py", line 321, in run preexec_fn=preexec_fn) File "/usr/lib/python2.7/subprocess.py", line 710, in __init__ errread, errwrite) File "/usr/lib/python2.7/subprocess.py", line 1335, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory Of course I understand that writing portable software is a difficult task, but is this restriction really necessary, if ipa client support is about "just configure sssd and a few other services"? Currently I have to install systemd to make ipa-client-install work, and later I can move back to sysvinit to support HA services. You have to admit that this is weird. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJW7pDyAAoJEAqeKp5m04HLcYQIAJLxFHxVSGMhHz791iZUgGCX qBNIP1JI8QmADgS0G0FZZx/s94Gb0iLrH/64aFGYDFdQAC1HZex6DkOxzSfADJlD JSWU6cTAIw0ktGJpj05oJCQXU2VMCg5PswyPnY4rwOqKlVnb5zQrD6yk6alkhz37 p7lSbgtzj6MkfwkVBNlb9epJFQEzGZYVOC8tfNQhVOmDgnlBBDVcsUSxASQlXr2G 7ASxOKwukWCIrP62jIwamIstg9n8TUkI95avkvwh5DvitBBADQxDA/GmF2VZG8NG Ohy0ONrzZHXML2cB3Rvwab20rXUcwv2vypmgGP4QE9bOezNw89ZROtx1MsiqOn0= =64Gt -END PGP SIGNATURE- -- 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] sssd.service start operation timed out
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/16/16 14:43, Lukas Slebodnik wrote: > On (16/03/16 14:30), Harald Dunkel wrote: >> (Wed Mar 16 13:25:05 2016) [sssd] [sbus_add_watch] (0x2000): >> 0xb3e070/0xb3dda0 (14), R/- (enabled) (Wed Mar 16 13:25:05 2016) [sssd] >> [get_ping_config] (0x0100): Time between service pings for [example.com]: >> [10] (Wed Mar 16 13:25:05 2016) [sssd] [get_ping_config] (0x0100): Time >> between >> SIGTERM and SIGKILL for [example.com]: [60] (Wed Mar 16 13:25:05 2016) >> [sssd] [start_service] (0x0100): Queueing service example.com for startup > sssd should spawn child processes > here. >> (Wed Mar 16 13:25:06 2016) [sssd] [monitor_quit_signal] (0x2000): Received >> shutdown command > ^ After a second, sssd got signal for shutdown. >> (Wed Mar 16 13:25:08 2016) [sssd] [monitor_quit_signal] (0x0040): Monitor >> received Terminated: terminating children > ^^ SIGTERM >> (Wed Mar 16 13:25:08 2016) [sssd] [monitor_quit] (0x0040): Returned with: 0 >> (Wed Mar 16 13:25:08 2016) [sssd] [monitor_quit] (0x0020): Terminating >> [example.com][474] (Wed Mar 16 13:25:08 2016) [sssd] [monitor_quit] >> (0x0020): Child [example.com] terminated with a signal (Wed Mar 16 13:25:08 >> 2016) [sssd] [monitor_cleanup] (0x0010): Error removing pidfile! (2 [No such >> file or directory]) (Wed Mar 16 13:25:08 2016) [sssd] [sbus_remove_watch] >> (0x2000): 0xb3e070/0xb3dda0 >> >> > > It does not look like problem in sssd. > Are you sure? Then why doesn't it "spawn child processes here"? I would guess the SIGTERM was either sent by systemd or sssd's startup script? Since freeipa doesn't work with anything else but systemd its a little bit cheap now to say "not my problem", is it? Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJW7R4AAAoJEAqeKp5m04HLtY0H/2+96DjhCx873/koFhQm+nZo OLnsBbZd6O1ujFHHMYbtUelavHTGkKuClne5oojEfMle7YxuhgSmZdHQ8JC/b6AH mIR6W9dxDNsYB9ChXL1+BCGYr9RAq4G/dYymnvfSE1HlDEQ+mWTt9vhjD4p5za79 ldetXkHnGus25F1z7nNGONYtYDDmeRaqrBxuWblKTKCA6zRwfFjtOP+/Zr3D5/fG PkC2t7nciocFJIhPvEsfrV+5y1fGHfNS8JJ+aW2rFx70OvGIN+fcWF9q/yv6ibd4 MAg9R0ZigLgtqIS+o//c7BeL3yjInu6Pw5Ns16u8M832HDhDzCQsCffhdeX8n+A= =9yfe -END PGP SIGNATURE- -- 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] sssd.service start operation timed out
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Jakub, On 03/16/16 09:30, Jakub Hrozek wrote: > > If you can reproduce the issue, it would be nice to increase the debug_level > a bit so that the debug logs are more verbose.. > Using debug level 9 I got (Wed Mar 16 13:24:57 2016) [sssd] [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb (Wed Mar 16 13:25:00 2016) [sssd] [ldb] (0x4000): Added timed event "ltdb_callback": 0xb3c2a0 (Wed Mar 16 13:25:00 2016) [sssd] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xb3c360 (Wed Mar 16 13:25:00 2016) [sssd] [ldb] (0x4000): Running timer event 0xb3c2a0 "ltdb_callback" (Wed Mar 16 13:25:00 2016) [sssd] [ldb] (0x4000): Destroying timer event 0xb3c360 "ltdb_timeout" (Wed Mar 16 13:25:00 2016) [sssd] [ldb] (0x4000): Ending timer event 0xb3c2a0 "ltdb_callback" (Wed Mar 16 13:25:00 2016) [sssd] [ldb] (0x4000): no modules required by the db (Wed Mar 16 13:25:00 2016) [sssd] [ldb] (0x4000): No modules specified for this database (Wed Mar 16 13:25:00 2016) [sssd] [ldb] (0x4000): Added timed event "ltdb_callback": 0xb3c2d0 (Wed Mar 16 13:25:00 2016) [sssd] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xb3c390 (Wed Mar 16 13:25:00 2016) [sssd] [ldb] (0x4000): Running timer event 0xb3c2d0 "ltdb_callback" (Wed Mar 16 13:25:00 2016) [sssd] [ldb] (0x4000): Destroying timer event 0xb3c390 "ltdb_timeout" (Wed Mar 16 13:25:00 2016) [sssd] [ldb] (0x4000): Ending timer event 0xb3c2d0 "ltdb_callback" (Wed Mar 16 13:25:00 2016) [sssd] [ldb] (0x4000): Added timed event "ltdb_callback": 0xb3c4e0 (Wed Mar 16 13:25:00 2016) [sssd] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xb3c5a0 (Wed Mar 16 13:25:00 2016) [sssd] [ldb] (0x4000): Running timer event 0xb3c4e0 "ltdb_callback" (Wed Mar 16 13:25:00 2016) [sssd] [ldb] (0x4000): Destroying timer event 0xb3c5a0 "ltdb_timeout" (Wed Mar 16 13:25:00 2016) [sssd] [ldb] (0x4000): Ending timer event 0xb3c4e0 "ltdb_callback" (Wed Mar 16 13:25:00 2016) [sssd] [sysdb_domain_init_internal] (0x0200): DB File for example.com: /var/lib/sss/db/cache_example.com.ldb (Wed Mar 16 13:25:01 2016) [sssd] [ldb] (0x4000): Added timed event "ltdb_callback": 0xb3dbe0 (Wed Mar 16 13:25:01 2016) [sssd] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xb3dca0 (Wed Mar 16 13:25:01 2016) [sssd] [ldb] (0x4000): Running timer event 0xb3dbe0 "ltdb_callback" (Wed Mar 16 13:25:01 2016) [sssd] [ldb] (0x4000): Destroying timer event 0xb3dca0 "ltdb_timeout" (Wed Mar 16 13:25:01 2016) [sssd] [ldb] (0x4000): Ending timer event 0xb3dbe0 "ltdb_callback" (Wed Mar 16 13:25:01 2016) [sssd] [ldb] (0x0400): asq: Unable to register control with rootdse! (Wed Mar 16 13:25:01 2016) [sssd] [ldb] (0x4000): Added timed event "ltdb_callback": 0xb3dd80 (Wed Mar 16 13:25:01 2016) [sssd] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xb3de40 (Wed Mar 16 13:25:01 2016) [sssd] [ldb] (0x4000): Running timer event 0xb3dd80 "ltdb_callback" (Wed Mar 16 13:25:01 2016) [sssd] [ldb] (0x4000): Destroying timer event 0xb3de40 "ltdb_timeout" (Wed Mar 16 13:25:01 2016) [sssd] [ldb] (0x4000): Ending timer event 0xb3dd80 "ltdb_callback" (Wed Mar 16 13:25:01 2016) [sssd] [ldb] (0x4000): Added timed event "ltdb_callback": 0xb3dfd0 (Wed Mar 16 13:25:01 2016) [sssd] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xb3e090 (Wed Mar 16 13:25:01 2016) [sssd] [ldb] (0x4000): Running timer event 0xb3dfd0 "ltdb_callback" (Wed Mar 16 13:25:01 2016) [sssd] [ldb] (0x4000): Destroying timer event 0xb3e090 "ltdb_timeout" (Wed Mar 16 13:25:01 2016) [sssd] [ldb] (0x4000): Ending timer event 0xb3dfd0 "ltdb_callback" (Wed Mar 16 13:25:04 2016) [sssd] [sbus_new_server] (0x0400): D-BUS Server listening on unix:path=/var/lib/sss/pipes/private/sbus-monitor,guid=d5f35f30568405c90a0fc9e756e950a0 (Wed Mar 16 13:25:05 2016) [sssd] [sbus_add_watch] (0x2000): 0xb3e070/0xb3dda0 (14), R/- (enabled) (Wed Mar 16 13:25:05 2016) [sssd] [get_ping_config] (0x0100): Time between service pings for [example.com]: [10] (Wed Mar 16 13:25:05 2016) [sssd] [get_ping_config] (0x0100): Time between SIGTERM and SIGKILL for [example.com]: [60] (Wed Mar 16 13:25:05 2016) [sssd] [start_service] (0x0100): Queueing service example.com for startup (Wed Mar 16 13:25:06 2016) [sssd] [monitor_quit_signal] (0x2000): Received shutdown command (Wed Mar 16 13:25:08 2016) [sssd] [monitor_quit_signal] (0x0040): Monitor received Terminated: terminating children (Wed Mar 16 13:25:08 2016) [sssd] [monitor_quit] (0x0040): Returned with: 0 (Wed Mar 16 13:25:08 2016) [sssd] [monitor_quit] (0x0020): Terminating [example.com][474] (Wed Mar 16 13:25:08 2016) [sssd] [monitor_quit] (0x0020): Child [example.com] terminated with a signal (Wed Mar 16 13:25:08 2016) [sssd] [monitor_cleanup] (0x0010): Error removing pidfile! (2 [No such file or directory]) (Wed Mar 16 13:25:08 2016) [sssd] [sbus_remove_watch] (0x2000): 0xb3e070/0xb3dda0 daemon.log shows : Mar 16 13:16:57 lxc10 systemd[1]: Stopping Getty
Re: [Freeipa-users] sssd.service start operation timed out
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/15/16 19:21, Jakub Hrozek wrote: > On Tue, Mar 15, 2016 at 06:42:01PM +0100, Harald Dunkel wrote: >> -BEGIN PGP SIGNED MESSAGE- >> >> Shouldn't it keep on trying, or retry after a few minutes? > > We don't have any such functionality.. > Understood. Obviously the dependencies and parameters listed in sssd.service are not sufficient to guarantee a smooth system startup for sssd. Except for sssd the system booted fine, so I wonder what is different with sssd? >> >> sssd is version 1.12.5. Google doesn't mention this problem, so I wonder >> what is happening here? > > I would suggest to look into the sssd logs.. > I did, of course. There was no error message except (Sat Feb 27 17:18:53 2016) [sssd] [monitor_cleanup] (0x0010): Error removing pidfile! (2 [No such file or directory]) Looking at the time entry it seems this message came up after the timeout. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJW6GzuAAoJEAqeKp5m04HLFbcH/0+xuE1/f9T1L6mLGVWNKdBL KKlv4siSHYgF9gUsbaqyDYGpoO6wKeFnj9sFMtD92TX5+JrXttkqTS9VRzIoY3kx w4lchG83gKqTM10/tjjPHT4eLEviUg9C/AW+JfLUa85wG/hm507JSyYSgF1btRco Wp6qWlg5D6yaaZdRmJsuqBGotFmaIG88SfXLYxCuJsqnbZi2VA8s3lGkB+wfWHSQ sztI4uFCvgJjLwCRiwHRPvp5gv1SdOIY04A7du6IFGtaR4+UhNpRn8vev4MWeh8I uRIhfrbmmO/E+WgcyEIX4C6YqUR7gAMB8/7qNV7Wd9WsZxcLAiXZWqFo5Wh6BJU= =9CwW -END PGP SIGNATURE- -- 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] sssd.service start operation timed out
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi folks, If I reboot my LXC server, then sssd doesn't come up in some containers. The logfile of an affected host shows - -- Reboot -- Feb 27 17:17:23 lxc1.example.com systemd[1]: Starting System Security Services Daemon... Feb 27 17:17:53 lxc1.example.com sssd[392]: Starting up Feb 27 17:17:54 lxc1.example.com sssd[be[471]: Starting up Feb 27 17:17:59 lxc1.example.com sssd[485]: Starting up Feb 27 17:17:59 lxc1.example.com sssd[487]: Starting up Feb 27 17:17:59 lxc1.example.com sssd[486]: Starting up Feb 27 17:17:59 lxc1.example.com sssd[484]: Starting up Feb 27 17:18:00 lxc1.example.com sssd[488]: Starting up Feb 27 17:18:13 lxc1.example.com sssd_be[471]: GSSAPI client step 1 Feb 27 17:18:13 lxc1.example.com sssd_be[471]: GSSAPI client step 1 Feb 27 17:18:15 lxc1.example.com sssd_be[471]: GSSAPI client step 1 Feb 27 17:18:15 lxc1.example.com sssd_be[471]: GSSAPI client step 2 Feb 27 17:18:53 lxc1.example.com systemd[1]: sssd.service start operation timed out. Terminating. Feb 27 17:18:53 lxc1.example.com sssd[485]: Shutting down Feb 27 17:18:53 lxc1.example.com sssd[484]: Shutting down Feb 27 17:18:53 lxc1.example.com sssd[488]: Shutting down Feb 27 17:18:53 lxc1.example.com sssd[be[471]: Shutting down Feb 27 17:18:53 lxc1.example.com sssd[487]: Shutting down Feb 27 17:18:53 lxc1.example.com sssd[486]: Shutting down Feb 27 17:18:53 lxc1.example.com systemd[1]: Failed to start System Security Services Daemon. Feb 27 17:18:53 lxc1.example.com systemd[1]: Unit sssd.service entered failed state. Shouldn't it keep on trying, or retry after a few minutes? sssd is version 1.12.5. Google doesn't mention this problem, so I wonder what is happening here? Every insightful comment is highly appreciated Harri -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJW6ElpAAoJEAqeKp5m04HL5kEH/03uUy+kyoLqrDpndZALEX0f 3XHFZryUNaJTUjQwtKe6tywmaKWcreQwZamwAFNxEQloGzhXiseAJ5LFNoP1KNuk qDdYji4cpRczpP1E7TvNdKahqEXCSeUSLEKzreR9ZYfQb+/pxlFxR/yTvIPlZhMG Wg1ckXfKh4jDfR5PTR1FdmdzvGCOg/GUhjQs1av+jJ0OQhSnQyfDFJOXM0HfyQv2 sDh6wNL2SAlQ9rPtLxF9mBLYkgZK9ibQ8uhA2FuF5noeuie/za5SouqlwlnWy/Ji 8NOgrmKB+nSAfcmeGB26aosHqaFoKX/mgrcYAbCwDFNnZXzBEEumWmlULKH5h8w= =gPWc -END PGP SIGNATURE- -- 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] sssd went away, failed to restart
Hi Jakub, On 02/24/2016 09:24 AM, Jakub Hrozek wrote: > > Do you have debug_level=N in the [domain] section? > I have set N=5. Is this OK to set global debugging for all modules? I am used to set something like debug_level = info but the man page doesn't tell. Regards Harri -- 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] sssd went away, failed to restart
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Lukas, On 02/23/16 13:46, Lukas Slebodnik wrote: > On (23/02/16 13:01), Harald Dunkel wrote: >> On 02/23/2016 11:58 AM, Lukas Slebodnik wrote: >>> I would rather focus on different thing. Why is sssd_be process blocked for >>> long time? >>> >> >> I have no idea. Was it really blocked? >> > It needn't be blocked itself. But it was busy with some non-blocking > operation which main process considered as bad state. > Do you think this is OK? Did it try to terminate the unresponsive sssd_be, or did it just try to start a new one and ran into a conflict with the old? > Would you mind to share sssd log files with high debug level? > Surely I can increase the log level for sssd. I wonder why sssd_be doesn't write its own log file? >> >> Does it really have to be watched? Wouldn't it be the job of systemd to >> restart the service when it dies? >> > sssd works also on non-systemd distribution. We plan to reply on systemd. If > you want to speed-up process then patches are always welcomed. > I highly appreciate your effort on providing compatibility with sysv init and others, but do you know that ipa-client-install (4.0.5) dies without systemd? I cannot tell for more recent ipa versions, since they are not available for Debian 8. > And moreover systemd would not solve the main issue. we should try to find > out why sssd_be did not respond for long time. > Maybe it would help to improve the way how the monitor checks for un- responsive threads instead? We have no indication that sssd_be had any problem, except for sssd trying to start a new one. Since sssd couldn't I would assume that the old sssd_be was still up and running and that sssd was the buggy part. Would you agree to that? Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWzOIiAAoJEAqeKp5m04HLBRoH/3mxHo35XDqUlBFqNsB9k9Cj e+G+7I0gZtQr1+a0aWt5mSFTOesJIhL0xEUZZcr+6PTgGch8w9OThz9udYAqsa89 4s4KRwBHtMMggyQ4Z1eb+2KfOL4RmZbw85EfdN+8ExLY/Ui07SQDkiEpXW6WgeRx BIcUGqD877CH8q0hIrQte/VNY94LeN4rgxYhkAeijY7+tOSngP39ZHph2sx4a0ES jE5RgiVh799iRZLIk7OTrUmYKhAo1ZLfeMUqiOZYovjL3ZpxckbMr68vWkmePoj7 EFyZGjpZeOfix77iZ7h3kcQDH3nUv90F17F7N+BLmKEaKSgoe8YItEp98g4LO/4= =/Tr1 -END PGP SIGNATURE- -- 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] sssd went away, failed to restart
On 02/23/2016 11:58 AM, Lukas Slebodnik wrote: > I would rather focus on different thing. > Why is sssd_be process blocked for long time? > I have no idea. Was it really blocked? > Do you use enumeration? > If yes do you really need it. Nope. > > Workaround might be to increate timeout between heartbeats > which are used to ensure that the process is alive and capable of answering > requests. The default value is 10 seconds. Double it should be enough > because there is by default 6 heartbeats IIRC. > 10 seconds is surely not OK. On Unix its not unlikely that a job is swapped out for 20 seconds or more. (Zabbix said that memory was fine, so this is not the case here.) Does it really have to be watched? Wouldn't it be the job of systemd to restart the service when it dies? Regards Harri -- 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] sssd went away, failed to restart
On 02/23/2016 10:00 AM, Jakub Hrozek wrote: > > Typically, this happens when the machine SSSD is running on is very > busy, the sssd_be process is blocked writing some large result from > LDAP, the monitor process considers it stuck and kills it. However, we > /should/ restart and reconnect the subprocesses. > Shoot the slow horse? Sorry to say, but I doubt that this is a reasonable approach. Can I turn off this feature? I would like to avoid to move my mailhost back to NIS client, but ypbind was never shot. Incoming EMails have been lost. What would you suggest? Regards Harri -- 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] WARNING: Using deny rules is deprecated, the option ipa_hbac_treat_deny_as will be removed in the next upstream version
Hi folks, journalctl shows me a bazillion of Logfile entries: Jan 12 20:02:04 host.example.com sssd[be[2362]: WARNING: Using deny rules is deprecated, the option ipa_hbac_treat_deny_as will be removed in the next upstream version This makes about 10% of the whole log. What am I supposed to do to get rid of these messages? Regards Harri -- 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] sssd went away, failed to restart
On 02/22/2016 03:51 PM, Jakub Hrozek wrote: > > Is there anything else in the logs (/var/log/sssd/*) > Only some events after sssd went away: srvvm01:/var/log/sssd# cat sssd.log.1 (Sun Feb 21 18:02:21 2016) [sssd] [monitor_restart_service] (0x0010): Process [nss], definitely stopped! srvvm01:/var/log/sssd# cat sssd_nss.log.1 (Sun Feb 21 18:02:15 2016) [sssd[nss]] [sss_dp_init] (0x0010): Failed to connect to monitor services. (Sun Feb 21 18:02:15 2016) [sssd[nss]] [sss_process_init] (0x0010): fatal error setting up backend connector (Sun Feb 21 18:02:15 2016) [sssd[nss]] [nss_process_init] (0x0010): sss_process_init() failed (Sun Feb 21 18:02:17 2016) [sssd[nss]] [sss_dp_init] (0x0010): Failed to connect to monitor services. (Sun Feb 21 18:02:17 2016) [sssd[nss]] [sss_process_init] (0x0010): fatal error setting up backend connector (Sun Feb 21 18:02:17 2016) [sssd[nss]] [nss_process_init] (0x0010): sss_process_init() failed (Sun Feb 21 18:02:21 2016) [sssd[nss]] [sss_dp_init] (0x0010): Failed to connect to monitor services. (Sun Feb 21 18:02:21 2016) [sssd[nss]] [sss_process_init] (0x0010): fatal error setting up backend connector (Sun Feb 21 18:02:21 2016) [sssd[nss]] [nss_process_init] (0x0010): sss_process_init() failed srvvm01:/var/log/sssd# cat sssd_pac.log.1 (Sun Feb 21 18:02:31 2016) [sssd[pac]] [pac_dp_reconnect_init] (0x0010): Could not reconnect to example.com provider. > Do you run with enumeration enabled? > Nope. sssd.conf (as generated by ipa-client-install): [domain/example.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = example.com id_provider = ipa auth_provider = ipa access_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt ipa_hostname = srvvm01.example.com chpass_provider = ipa ipa_server = _srv_, ipa2.example.com dns_discovery_domain = example.com [sssd] services = nss, sudo, pam, ssh config_file_version = 2 domains = example.com [nss] homedir_substring = /home [pam] [sudo] [autofs] [ssh] [pac] [ifp] I have to mention that I missed to add ipa2.example.com to the local /etc/hosts. This is fixed now. sssd.conf says now : ipa_server = _srv_, ipa2.example.com, ipa1.example.com : Would you recommend to enable enumeration? Regards Harri -- 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] sssd went away, failed to restart
Hi folks, this morning I recognized that the sssd on our mail server went away (which is fatal). journalctl -u sssd sssd says : Feb 21 18:01:55 srvvm01.example.com sssd[199]: Killing service [example.com], not responding to pings! Feb 21 18:01:55 srvvm01.example.com sssd[199]: Killing service [nss], not responding to pings! Feb 21 18:02:15 srvvm01.example.com sssd[be[215]: Shutting down Feb 21 18:02:15 srvvm01.example.com sssd[152704]: Starting up Feb 21 18:02:17 srvvm01.example.com sssd[be[152709]: Starting up Feb 21 18:02:17 srvvm01.example.com sssd[152710]: Starting up Feb 21 18:02:21 srvvm01.example.com sssd[152711]: Starting up Feb 21 18:02:22 srvvm01.example.com sssd[199]: Exiting the SSSD. Could not restart critical service [nss]. Feb 21 18:02:37 srvvm01.example.com sssd[be[152709]: Shutting down Feb 21 18:02:37 srvvm01.example.com sssd[315]: Shutting down Feb 21 18:02:37 srvvm01.example.com sssd[313]: Shutting down Feb 21 18:02:37 srvvm01.example.com sssd[312]: Shutting down Feb 21 18:02:37 srvvm01.example.com sssd[311]: Shutting down Feb 21 18:02:37 srvvm01.example.com systemd[1]: sssd.service: main process exited, code=exited, status=1/FAILURE Feb 21 18:02:37 srvvm01.example.com systemd[1]: Unit sssd.service entered failed state. What has happened here? This was sssd version 1.12.5. I have upgraded to version 1.13.3-1 this morning. Every helpful comment is highly appreciated. Harri -- 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] sssd 1.13.3: sss_ssh_knownhostsproxy seems to break ssh -4
Hi Jakub, On 02/19/2016 04:04 PM, Jakub Hrozek wrote: > On Fri, Feb 19, 2016 at 03:27:50PM +0100, Harald Dunkel wrote: >> Hi Lukas, >> >> I found an ubuntu manpage saying sss_ssh_knownhostsproxy is >> an experimental feature. >> Would you suggest to drop it >> in ipa-client-install? > > It's not experimental (at least upstream) for several years.. What sssd > version is that? > Just google for sss_ssh_knownhostsproxy; its top of the list: http://manpages.ubuntu.com/manpages/precise/man1/sss_ssh_knownhostsproxy.1.html AFAIK ubuntu uses freeipa 4.1.5 and sssd 1.13.3. Maybe they did not update their man page on the web. I am using sssd 1.13.3 on Debian 8. The local man page does not say "experimental". >> >> IMHO this is a pretty annoying bug. I rely upon a port >> redirection for ssh on IPv4. For IPv6 there is no >> redirection, but the port is blocked in the packet filter. > > Would it help to set lookup_family_order to ipv4_only here so that ipv6 > is not even tried (or the other way around, depending on which AF you > want to try..) > Thats exactly what I was trying to achieve with the "-4". Sorry, but setting it globally conflicts with our efforts to propagate IPv6. I can still manually lookup the IPv4 address as a workaround. Regards Harri -- 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] sssd 1.13.3: sss_ssh_knownhostsproxy seems to break ssh -4
Hi Lukas, I found an ubuntu manpage saying sss_ssh_knownhostsproxy is an experimental feature. Would you suggest to drop it in ipa-client-install? IMHO this is a pretty annoying bug. I rely upon a port redirection for ssh on IPv4. For IPv6 there is no redirection, but the port is blocked in the packet filter. Regards Harri -- 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] sssd 1.13.3: sss_ssh_knownhostsproxy seems to break ssh -4
Hi folks, is it just me, or does sss_ssh_knownhostsproxy break ssh -4 host.example.com ? host.example.com has A and entries in DNS, of course. If I comment out the line in ssh_config # ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h then I get the expected IPv4 connection. ??? This is sssd 1.13.3-1, built and run on Debian Jessie. Every helpful comment is highly appreciated Harri -- 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] Joining realm failed with "SSL certificate problem: self signed certificate in certificate chain"
Found it. The error message on the ipa server (in /var/log/httpd/error_log) was less misleading: SSL Library Error: -12195 Peer does not recognize and trust the CA that issued your certificate After installing the ca-certificates package and adding the root certificate to it the problem was gone. Thanx to everybody Harri -- 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] Joining realm failed with "SSL certificate problem: self signed certificate in certificate chain"
Hi folks, Problem: ipa-client-install fails with # rm -f /etc/ipa/ca.crt # ipa-client-install Discovery was successful! Hostname: srvl023.ac.example.com Realm: EXAMPLE.COM DNS Domain: example.com IPA Server: ipa1.example.com BaseDN: dc=example,dc=com Continue to configure the system with these values? [no]: yes Synchronizing time with KDC... Unable to sync time with IPA NTP server, assuming the time is in sync. Please check that 123 UDP port is opened. User authorized to enroll computers: admin Password for ad...@example.com: Successfully retrieved CA cert Subject: CN=Certificate Authority,O=example AG,C=COM Issuer: CN=example Root CA,OU=example Certificate Authority,O=example AG,C=COM Valid From: Mon Dec 28 10:35:30 2015 UTC Valid Until: Mon Dec 31 23:59:59 2035 UTC Joining realm failed: libcurl failed to execute the HTTP POST transaction, explaining: SSL certificate problem: self signed certificate in certificate chain Installation failed. Rolling back changes. IPA client is not configured on this system. ??? Is this the chain sent from the ipa server to the new host? Every helpful idea would be highly appreciated. Regards Harri -- 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] Joining realm failed with "SSL certificate problem: self signed certificate in certificate chain"
Hi Rob, On 01/29/2016 04:12 PM, Rob Crittenden wrote: > > What version of server and client? > Server is freeipa 4.2 (Centos 7.2) Client is freeipa 4.0.5 (Debian 8) Sorry, I should have mentioned this in my first post. I am running >200 clients in this environment, appr. 40% are Debian Hosts with this freeipa version. One host cannot be joined :-(. > I gather you have installed with an external CA? How many certs are in > /etc/ipa/ca.crt? > Yes, its an external CA. There is one cert in ca.cert: It is the certificate of the ipa CA, signed by the expected external root CA. I see the same on the other hosts, but of course I checked only a few (4). Regards Harri -- 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] NIS support gone with 4.2?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/03/16 21:39, Alexander Bokovoy wrote: > Yes, this looks like a bug in the ipa-nis-manage which is a bit larger than I > thought originally. > > You can restore maps by running > > ipa-ldap-updater /usr/share/ipa/nis.uldif > > after that and restarting the dirsrv, you should be seeing the maps. > Now it works. Thanx very much Harri -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWiZeiAAoJEAqeKp5m04HLgsIH+wX09FFSWtb2r/lXAenlKBtl /IpdBMF5BUCIUGc/+o1iCl9d1Dwr4yYZxxwMFekHST1x1OZ1dz5g5OxFfFE1L92u HgKOOFb7FM9t7dWKUIUQ/5yhWxIJlhvMYuOCN62fExtd8Ca9V85QJDxgIvlDui4E XHi1wjA41mg4XNIXjEPGzQe3RmmOUDZ97PHiM7iIfBT4iPCod0KvQhcS9CI7CZdu MTNhnkfrY7oEItWCX4dnuMYmF0Q/hOAOOtHeOIwIco/cc3+jdWP4yaUHhoskDvQA LcZz6Du7LlH7a/6qnyC8YP31pvtvV9csVh7+moVhxxnaAqIG8omFzUWZYqWMydw= =vjgZ -END PGP SIGNATURE- -- 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] NIS support gone with 4.2?
PS: Please excuse the double post. It was an accident. Harri signature.asc Description: OpenPGP digital signature -- 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] NIS support gone with 4.2?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Alex, On 01/03/16 13:31, Alexander Bokovoy wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1286781 is the bug. It has > recommended workaround in comment 1. > What exactly is meant by "remove all NIS plugin entries"? I had the impression that modifying the LDAP database using vi is strictly prohibited. Is this correct? Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWiVNvAAoJEAqeKp5m04HLT40H/igxgJPK2q2pIGRoULu1PZST X+zfcPivBNlcVGm/em2XhwyF47MNlMaUdsr45Q6S3ykLngPVrRRNzeyD0w/FC4WJ eWr8BT74nzlRrFbzI+QRAWp7wxAjnxoYN5E3pLv5X61mSZ9vWrNB3Tpy9Oyv5Gc6 OJ2zdxCg7wZbHIHcRFnU7OcFgR+MBKHMv9TzyLV74MJ/zSij49TACqydZSP6i7yR qFU86CdiCaihOF6fswHwRpaQ3zjF/s/hAvlGlgJS114QJxCiYGPHV8GU1p33Bx3w 3FKd0XAQcyXmcTTtz7r4PHCqe07o85rfZx1rpMcorl6yU6QNbj5o1cKh9CvbV7I= =nZxr -END PGP SIGNATURE- -- 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] NIS support gone with 4.2?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/03/16 19:29, Alexander Bokovoy wrote: > Alternatively, do following: > > ipa-nis-manage disable > > ldapsearch -xLLL -D "cn=Directory Manager" -W -s onelevel -b "cn=NIS > Server,cn=plugins,cn=config" dn > > You'll get list of DNs like this: dn: > nis-domain=+nis-map=ethers.byaddr,cn=NIS Server,cn=plugins,cn=config > > dn: nis-domain=+nis-map=ethers.byname,cn=NIS > Server,cn=plugins,cn=config > > Run ldapdelete -D "cn=Directory Manager" -W "" "" ... > > where is what you've got after "dn: " > > This is how you can delete those entries. > > After that, run 'ipa-nis-manage enable'. > Hi Alex, sorry to say, but it did not work: [root@ipa2 ~]# ipa-nis-manage disable Directory Manager password: This setting will not take effect until you restart Directory Server. [root@ipa2 ~]# systemctl restart dirsrv@EXAMPLE-COM [root@ipa2 ~]# ldapsearch -xLLL -D "cn=Directory Manager" -W -s onelevel -b "cn=NIS Server,cn=plugins,cn=config" dn Enter LDAP Password: dn: nis-domain=example.com+nis-map=ethers.byaddr,cn=NIS Server,cn=plugins,cn=con fig dn: nis-domain=example.com+nis-map=ethers.byname,cn=NIS Server,cn=plugins,cn=con fig [root@ipa2 ~]# ldapdelete -D "cn=Directory Manager" -W "nis-domain=example.com+nis-map=ethers.byaddr,cn=NIS Server,cn=plugins,cn=config" "nis-domain=example.com+nis-map=ethers.byname,cn=NIS Server,cn=plugins,cn=config" Enter LDAP Password: [root@ipa2 ~]# ipa-nis-manage enable Directory Manager password: Enabling plugin This setting will not take effect until you restart Directory Server. The portmap service may need to be started. [root@ipa2 ~]# systemctl restart dirsrv@EXAMPLE-COM [root@ipa2 ~]# systemctl restart rpcbind [root@ipa2 ~]# ypcat -h localhost -d example.com passwd No such map passwd.byname. Reason: No such map in server's domain [root@ipa2 ~]# ldapsearch -xLLL -D "cn=Directory Manager" -W -s onelevel -b "cn=NIS Server,cn=plugins,cn=config" dn Enter LDAP Password: [root@ipa2 ~]# I tried it on a replica, though. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWiX8pAAoJEAqeKp5m04HLx2AH/igd+rgZf5FAXRBKk+M5qmHN kofjuCJ2aTaLRMmqY1J9FINsRax4pThP71bC34jHo2mQFWW15aNi7SYaur4cpEzW XA+0DLFmryS1yocg0HoFFfUK/lJxjL/uMm5yY7HI0A04QcrxCfoDjtOR4IqNLpGn eQwi6UmQdvv7srLfd2nKHtCgsmssq9jVzcH8c+EHm4aR/qL6V7dsDDiFYvuqvGu8 3mdw3sPCpxNC/9a259E5FUFZVocTrmucUKURzn07Ff6pckzonWY7kVVuieRZGzWC NYSsjl/Ai8o/qKW4DY+1dp3NeYYXnUG69PuO4EkgJ/l5oU3CCJJTkv6MVO6tFhs= =GIng -END PGP SIGNATURE- -- 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] NIS support gone with 4.2?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi folks, Using FreeIPA 4.2 (Centos 7.2) I have enabled NIS support as described in Red_Hat_Enterprise_Linux-7-Linux_Domain_Identity_Authentication_and_Policy_Guide-en-US.pdf 14.5.2 "Enabling the NIS Listener". Esp. I ran ipa-nis-manage enable ipa-compat-manage enable systemctl enable rpcbind and rebooted the server. Next: # ipa-nis-manage enable Directory Manager password: Plugin already Enabled # ipa-compat-manage status Directory Manager password: Plugin Enabled Problem: ypcat woes # ypcat -h localhost -d example.com passwd No such map passwd.byname. Reason: No such map in server's domain # ypcat -h localhost -d example.com group No such map group.byname. Reason: No such map in server's domain AFAICS this is not supposed to happen. I am stuck due to this problem. Every helpful comment is highly appreciated. Harri -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWh+SkAAoJEAqeKp5m04HLkxAH/3ZPdRN1FHhLU6oWAkxJlqOu ftCgIxSP4nYYUdJdnZxcTyDF7INmIDQOgKCJ0uGImmNwBo/YAmEfsYyF+V8SMcqR pkZxZfDiNI3+mbREvJnwX7GWrz7q0AP76IzfQSHNjhzS1dTJDQcq1bjZTx+sX/Rq 9HputYQZhbhCaDVlyuJ8WkG6j13l6CnVzX9WL7SeR6KdvEYma3Uo/yXqEyqZTCAB Of7794UH9Vuw4+315g6OqmKSFzsBkGBwL9RuBrrXWY2ccDbHu2Xa5jDeqfHJXvq+ 5aBp/+3xiDT4OU5js+PXnVYPJsNeu5eeCvDMq+A2/5hU0weTM2vATHZDXANJGNA= =Zm2r -END PGP SIGNATURE- -- 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] NIS support gone with 4.2?
Hi folks, I have enabled NIS support as described on https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/migrating-from-nis.html Esp. I have run ipa-nis-manage enable ipa-compat-manage enable systemctl enable rpcbind and rebooted the FreeIPA server (Centos 7.2, FreeIPA 4.2 as shipped). Problem: Basic verification on the ipa server failed # ypcat -h localhost -d example.com passwd No such map passwd.byname. Reason: No such map in server's domain # ypcat -h localhost -d example.com group No such map group.byname. Reason: No such map in server's domain Every helpful hint is highly appreciated. Regards Harri -- 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] ipa-replica-install --setup-ca: do or don't?
Hi folks, how comes that '--setup-ca' is not the default for ipa-replica-install? What is best practice wrt creating a local ca on the replicas? Every insightful comment is highly appreciated. Best seasons greetings Harri -- 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-server-install fails to compare DNs in certificates
On 12/16/2015 12:27 PM, Alexander Bokovoy wrote: > I've asked you to provide ipaserver-install.log in the bug. Without it > it is a bit hard to see how to help. Let's continue in the bug. Bug report has been updated. -- 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-server-install fails to compare DNs in certificates
On 12/15/2015 04:04 PM, Alexander Bokovoy wrote: > It makes possible others to see your specific details as this is the > first time we get such bug report. Done: https://bugzilla.redhat.com/show_bug.cgi?id=1292042 Now what would you suggest as a workaround? -- 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] ipa-server-install --external-ca failed
ipa-server-install asked me to get the csr signed and come back, but then it refused to continue: # ipa-server-install -n example.com -r EXAMPLE.COM --external-ca --subject="C=DE,O=example AG" --setup-dns --forwarder=8.8.4.4 --forwarder=8.8.8.8 : : The next step is to get /root/ipa.csr signed by your CA and re-run /usr/sbin/ipa-server-install as: /usr/sbin/ipa-server-install --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate # /usr/sbin/ipa-server-install --external-cert-file=/root/ipa_ipa1.crt --external-cert-file=/root/root-ca.crt : : ipa.ipapython.install.cli.install_tool(Server): ERRORIPA CA certificate not found in /root/ipa_ipa1.crt, /root/root-ca.crt openssl verify shows the certificate is OK: # openssl verify -CAfile /root/root-ca.crt /root/ipa_ipa1.crt /root/ipa_ipa1.crt: OK # openssl verify -CAfile /root/root-ca.crt /root/root-ca.crt /root/root-ca.crt: OK The CA attribute is set as well, pathlen=0, etc: # openssl x509 -in /root/ipa_ipa1.crt -noout -text | less : : X509v3 extensions: X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Subject Key Identifier: : Google hasn't seen this error before, either (AFAICS). Every helpful hint is highly appreciated. Harri -- 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-server-install fails to compare DNs in certificates
Hi folks,
apparently ipa-server-install (4.2) gets confused about the
attribute sequence in the DNs of the certificates. If I use
ipa-server-install --external-ca --subject="C=DE,O=example AG"
then ipa's csr contains
O=example AG, C=DE, CN=Certificate Authority
The signed certificate contains
C=DE, O=example AG, CN=Certificate Authority
If I run ipa-server-install again to hand off the certificate
chain, then the code in load_external_cert() (installutils.py)
sees
ca_subject = "CN=Certificate Authority,C=DE,O=example AG"
subject= "CN=Certificate Authority,O=example AG,C=DE"
:
if subject == ca_subject:
ca_nickname = nickname
:
if ca_nickname is None:
raise ScriptError("IPA CA certificate not found in %s" % (",
".join(files)))
The strings don't match and the certificate chain is rejected,
even though it is valid.
Please check https://tools.ietf.org/html/rfc5280#section-7.1 for
reference.
Can anybody reproduce this? What would you suggest to convince
ipa 4.2 to accept valid certificate chains?
Regards
Harri
--
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-server-install fails to compare DNs in certificates
On 12/15/2015 02:51 PM, Alexander Bokovoy wrote: > Could you please file a bug about it? I tried, but trac refused my username/password for redhat.com. Due to greylisting I haven't received the confirmation request by EMail, either. Anyway, I have to continue getting ipa running. Filing a bug doesn't help to work around the problem. Regards Harri -- 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] mixed DNS subnets for FreeIPA and M$ AD
Hi folks, currently I have a DNS domain "example.com" with several subdomains "s1.example.com", "s2.example.com", etc. (using NIS for IM). DNServer is bind9. There is a special stub zone "ws.example.com" provided by AD (including the correct TXT DNS records). Now I would like to move the Unix part to FreeIPA 4.2 (using integrated DNS) and to build a trust relationship to AD. I just wonder if this is possible without loosing the top level "example.com" for both DNS and Kerberos realm? Looking at http://www.freeipa.org/page/Deployment_Recommendations I got confused by expressions like "directly overlap" and "same DNS zone level". Obviously "ws.example.com" is on a different level than "example.com", but do they overlap "directly"? I had the impression that your recommendation is to move FreeIPA to "ipa.example.com", but will it still be possible to manage the old "s1.example.com", "s2.example.com", etc. subdomains in FreeIPA? Will I loose the bind integration? Every helpful comment is highly appreciated. Harri -- 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] mixed DNS subnets for FreeIPA and M$ AD
On 12/08/2015 03:08 PM, Petr Spacek wrote: > > Does > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/prerequisites.html#dns-reqs > > and > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-requirements.html#dns-realm-settings > > answer your questions? > Not really. All these documents bring up strings like "ipa.example.com". Sometimes thats a DNS domain, sometimes its a kerberos realm (even though its in lower case letters). The assumption that DNS and realm name match is based upon a recommendation, i.e. you cannot rely upon that. (Not to mention that "example.com" and "ad.example.com" *are* unique.) My point is: Currently I have a hierarchy between the DNS top level domain "example.com" and the windows DNS domain "ws.example.com". I do not have a hierarchy between the IM solutions for Unix and Windows (currently NIS and AD). Moving from NIS/bind to FreeIPA I would prefer to keep this setup. If this is not possible, then I can live with moving the IPA servers to "ipa.example.com" (DNS), but I cannot change the other DNS subnets. Changing existing host and domain names is *highly* expensive. I don't care very much about the realm name in Kerberos. IMU thats just a string. IPA.EXAMPLE.COM would be fine, if EXAMPLE.COM is not possible. What would be your suggestion? Harri -- 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] hesitate to deploy freeipa
Hi Simo, On 06/25/15 17:47, Simo Sorce wrote: Harald, the reason I (and others) started this project many years ago is that trying to set up all components myself was boring and highly error prone, and you would always end up with a bag of parts that had a lot of mismatches, and some functionality was always missing or poor or incomplete, due to the imperfect integration. Yes, the whole project is complex, but not because we like complexity, it is complex because the problem space is complex and we are bound to use existing protocols, which sometimes add in complexity, and we want to offer useful features to admins, so they can think about managing stuff and not about the plumbing all the time. Sorry to say, but this part is not in yet. ipa-client-install is included in RedHat/Fedora/Centos. On Debian it is improving (meaning I have to backport it from Testing to Jessie and Wheezy and hope), but for my other Unixes (Solaris, AIX, Suse, all designed more than 5 years ago) I have to do the plumbing on my own. Its a lot of work, but I can live with that. Missing client support is not the problem. The problem is that I do have a working environment (using NIS). NIS is deeply integrated everywhere for +20 years. I understand that NIS is not safe to use, but it is rock solid and *extremely* easy to manage and repair. If something goes wrong, then I can edit a file, run make -C /var/yp and its done. If something goes wrong with freeipa, then in the best case I have to find the bad component and fix it, as for NIS. Worst case is that 2 or more components disagree somehow. There would be several options to solve this: a) use low level component tools to manipulate their data, hoping to not make incompatible changes breaking things in other components of freeipa b) ask for help on the mailing list, which might imply a downtime of several hours and then option a) Both options don't appear very attractive to me. The best option is to study the individual components and how they are integrated, Thats the point: It is not sufficient to study the individual components. You have to know how they work together. For example, you have to know the constructs you should avoid in component A to make sure that you don't break other components of Freeipa. just like you (presumably) studied how a Unix/Linus OS is put together and operates. An OS is not simpler in anyway, but you probably do not see the complexity as menacing anymore because you are familiar with how it works. I am telling this to myself again and again, but its not sufficient to get rid of the bad feeling about it. Anyway, please don't get me wrong on this: I highly appreciate the work you and all the others do on creating and improving Freeipa. I completely agree that a modern way of identity management replacing historic tools like NIS and LDAP is overdue. Regards Harri -- 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] hesitate to deploy freeipa
Hi folks, I have a general problem with freeipa: It is *highly* complex and depends upon too many systems working together correctly (IMHO). My concern is, if there is a problem, then the usual tools following the Unix paradigm (do one thing and do it well) don't help anymore. I can speak only for my own stomach, but it turns upside down when I think about this. Your thoughts on this? Regards Harri -- 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] using pathlen:0 for freeipa's CA certificate?
Hi folks, Instead of a self-signed certificate I would like to use an external CA to sign freeipa's CSR (ipa-server-install --external-ca). Question: Is pathlen:0, e.g. basicConstraints=critical,CA:TRUE, pathlen:0 sufficient for freeipa's CA certificate? Regards Harri -- 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] setting up a subdomain
Hi folks, I am very new to freeipa, so hopefully its allowed to ask: I need a single realm EXAMPLE.COM and DNS zones for example.com , develop.example.com, sales.example.com, etc. freeipa makes it easy to create a subdomain using ipa dnszone-add a.example.com ipa dnszone-mod a.example.com --dynamic-update=TRUE but it appears that all these fancy _ldap._tcp, _kerberos ._tcp etc. records are not generated. Is this on purpose? Is a client foo.a.example.com supposed to look for _ldap._tcp.example.com, if _ldap._tcp.a.example.com cannot be found? The code for creating these basic entries must be somewhere in freeipa, so I wonder if I missed to recognize some command line options here? Is this setup something that freeipa (4.0.5) can handle at all? Every helpful comment is highly appreciated. Regards Harri -- 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
