[Freeipa-users] Re: { possibly offtopic } -- can sssd.conf alone be configured to copy the custom AD ID Ranges used by IPA server?

[Jakub Hrozek via FreeIPA-users]

On Wed, Jun 28, 2017 at 01:03:45PM -0400, Chris Dagdigian via FreeIPA-users 
wrote:
> Hi folks,
> 
> 
> I have a set of servers that CANNOT become enrolled IDM clients due to a
> vendor refusing to support this type of config.
> 
> This server fleet is directly bound to an AD system via the standard non-IPA
> "realm join ..." type commands
> 
> Since I can't bring these servers "into the fold" so to speak at the very
> least I would love to offset at least one potential future problem by seeing
> if I can help them configure sssd.conf on their local machines to use the
> same AD SID-to-UID algorithm (complete with custom ID Range values that we
> have enabled on the IPA master) so that they at least get the same UID and
> GID values for their AD users as the same user would get if they logged into
> the much larger fleet of IDM-managed servers.
> 
> Hope I'm asking the question properly -- in a nutshell I'm wondering how to
> trick a standalone sssd.conf file so that it uses the same SID-to-UID
> algorithm that an IDM master would use. This would at least let me get
> consistent UID/GID values across my fleet of enrolled vs. non-enrolled IDM
> clients !  Tips or advice appreciated even if the response is "heck no; you
> can't do that .. "

So is the requirement absolutely to have the machines enrolled as part
of the AD domain?

If not, have you considered pointing the clients towards the compat tree
and using a plain LDAP setup, if your vendor supports that?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] { possibly offtopic } -- can sssd.conf alone be configured to copy the custom AD ID Ranges used by IPA server?

[Chris Dagdigian via FreeIPA-users]

Hi folks,


I have a set of servers that CANNOT become enrolled IDM clients due to a 
vendor refusing to support this type of config.


This server fleet is directly bound to an AD system via the standard 
non-IPA "realm join ..." type commands


Since I can't bring these servers "into the fold" so to speak at the 
very least I would love to offset at least one potential future problem 
by seeing if I can help them configure sssd.conf on their local machines 
to use the same AD SID-to-UID algorithm (complete with custom ID Range 
values that we have enabled on the IPA master) so that they at least get 
the same UID and GID values for their AD users as the same user would 
get if they logged into the much larger fleet of IDM-managed servers.


Hope I'm asking the question properly -- in a nutshell I'm wondering how 
to trick a standalone sssd.conf file so that it uses the same SID-to-UID 
algorithm that an IDM master would use. This would at least let me get 
consistent UID/GID values across my fleet of enrolled vs. non-enrolled 
IDM clients !  Tips or advice appreciated even if the response is "heck 
no; you can't do that .. "




Regards,
Chris

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

[Freeipa-users] Re: SSSD not starting

[Sean Hogan via FreeIPA-users]

Hi Jakub

  Thanks and it does not come off that way at all.  I made the same
recommendations.  I can only control the IPA servers and they are at 6.9
but the typical reason for not moving up... app not tested on higher level.




Sean Hogan










From:   Jakub Hrozek via FreeIPA-users

To: freeipa-users@lists.fedorahosted.org
Cc: Jakub Hrozek 
Date:   06/28/2017 07:47 AM
Subject:[Freeipa-users] Re: (no subject)



On Wed, Jun 28, 2017 at 07:04:58AM -0700, Sean Hogan via FreeIPA-users
wrote:
>
> Hi All,
>
>   We are having an issue performing RHEL 6.6 to 6.7 upgrade with SSSD.
The
> systems are already enrolled and working in IPA 3.0.0-50 using 6.6
client.
> We yum update and sssd gives this
>
>  Non-fatal POSTTRANS scriptlet failure in rpm package
>  sssd-1.12.4-47.el6_7.8.ppc64
>  warning: %posttrans(sssd-1.12.4-47.el6_7.8.ppc64) scriptlet
>  failed, exit status 1
>

I'm sorry if this comes off as less than helpful, but unless you have a
critical reason to use 6.7, please upgrade to 6.8 or even 6.9. You don't
have to upgrade the whole distro, but at least the sssd stack.

There was a ton of bugfixes between 6.7 and 6.8..

>
>
>
> Seems to install however sssd will no longer start.  I can run ldap
> searches against the IPA server and kinit without issue
> I have un-enrolled the client and re-enrolled to no avail... once enroll
> gets to starting sssd it says sssd restart failed and continues to
enroll.
> I have reinstalled sssd, ipa client and c-ares, I have removed the sssd
> cache db.
>
> The really strange part is if we wait approx 24 hours sssd starts working
> again which we have reproduced on 2 servers we are testing with... are we
> missing some sort of lease or cache?  Using this to remove the sssd db
> rm -rf /var/lib/sss/db/*
>
>
>
> Here is a piece of the gdb core dump
> Core was generated by `/usr/libexec/sssd/sssd_pac --uid 0 --gid 0 -d
0x37f0

This is a bug in the sssd_pac responder. I couldn't find any related
bug report upstream or in RHBZ, but I would really suggest upgrading
first.

If the sssd_pac service still crashes, then we need to investiage the
problem further. Seeing that you're using ppc, chances are there might be
an endianess issue, but I can't think of any recent one.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


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

[Freeipa-users] Re: SSSD not starting

[Sean Hogan via FreeIPA-users]

Apologies..

My subject line was "SSSD not starting" but posted it to the old address.
Made a new email with the info and copy paste must have dropped it





Sean Hogan







From:   Sean Hogan via FreeIPA-users

To: freeipa-users@lists.fedorahosted.org
Cc: Sean Hogan 
Date:   06/28/2017 07:29 AM
Subject:[Freeipa-users] (no subject)



Hi All,

We are having an issue performing RHEL 6.6 to 6.7 upgrade with SSSD. The
systems are already enrolled and working in IPA 3.0.0-50 using 6.6 client.
We yum update and sssd gives this
  
 Non-fatal POSTTRANS scriptlet failure in rpm package 
 sssd-1.12.4-47.el6_7.8.ppc64 
 warning: %posttrans(sssd-1.12.4-47.el6_7.8.ppc64) scriptlet  
 failed, exit status 1
  





Seems to install however sssd will no longer start. I can run ldap searches
against the IPA server and kinit without issue
I have un-enrolled the client and re-enrolled to no avail... once enroll
gets to starting sssd it says sssd restart failed and continues to enroll.
I have reinstalled sssd, ipa client and c-ares, I have removed the sssd
cache db.

The really strange part is if we wait approx 24 hours sssd starts working
again which we have reproduced on 2 servers we are testing with... are we
missing some sort of lease or cache? Using this to remove the sssd db
rm -rf /var/lib/sss/db/*



Here is a piece of the gdb core dump
Core was generated by `/usr/libexec/sssd/sssd_pac --uid 0 --gid 0 -d 0x37f0
'.
Program terminated with signal 11, Segmentation fault.
#0 0x0fff83f2bc64 in ._dl_vdso_vsym () from /lib64/libc.so.6

Part of SSSD.log with debug 9
(Tue Jun 27 21:13:14 2017) [sssd] [sbus_dispatch] (0x4000): dbus conn:
0x10034ca0c10
(Tue Jun 27 21:13:14 2017) [sssd] [sbus_dispatch] (0x4000): Dispatching.
(Tue Jun 27 21:13:14 2017) [sssd] [sbus_message_handler] (0x4000): Received
SBUS method [RegisterService]
(Tue Jun 27 21:13:14 2017) [sssd] [sbus_get_sender_id_send] (0x2000): Not a
sysbus message, quit
(Tue Jun 27 21:13:14 2017) [sssd] [sbus_handler_got_caller_id] (0x4000):
Received SBUS method [RegisterService]
(Tue Jun 27 21:13:14 2017) [sssd] [client_registration] (0x0100): Received
ID registration: (sudo,1)
(Tue Jun 27 21:13:14 2017) [sssd] [mark_service_as_started] (0x0200):
Marking sudo as started.
(Tue Jun 27 21:13:14 2017) [sssd] [sbus_dispatch] (0x4000): dbus conn:
0x10034ca4590
(Tue Jun 27 21:13:14 2017) [sssd] [sbus_dispatch] (0x4000): Dispatching.
(Tue Jun 27 21:13:14 2017) [sssd] [sbus_message_handler] (0x4000): Received
SBUS method [RegisterService]
(Tue Jun 27 21:13:14 2017) [sssd] [sbus_get_sender_id_send] (0x2000): Not a
sysbus message, quit
(Tue Jun 27 21:13:14 2017) [sssd] [sbus_handler_got_caller_id] (0x4000):
Received SBUS method [RegisterService]
(Tue Jun 27 21:13:14 2017) [sssd] [client_registration] (0x0100): Received
ID registration: (ssh,1)
(Tue Jun 27 21:13:14 2017) [sssd] [mark_service_as_started] (0x0200):
Marking ssh as started.
(Tue Jun 27 21:13:14 2017) [sssd] [sbus_dispatch] (0x4000): dbus conn:
0x10034ca31b0
(Tue Jun 27 21:13:14 2017) [sssd] [sbus_dispatch] (0x4000): Dispatching.
(Tue Jun 27 21:13:14 2017) [sssd] [sbus_message_handler] (0x4000): Received
SBUS method [RegisterService]
(Tue Jun 27 21:13:14 2017) [sssd] [sbus_get_sender_id_send] (0x2000): Not a
sysbus message, quit
(Tue Jun 27 21:13:14 2017) [sssd] [sbus_handler_got_caller_id] (0x4000):
Received SBUS method [RegisterService]
(Tue Jun 27 21:13:14 2017) [sssd] [client_registration] (0x0100): Received
ID registration: (pam,1)
(Tue Jun 27 21:13:14 2017) [sssd] [mark_service_as_started] (0x0200):
Marking pam as started.
(Tue Jun 27 21:13:14 2017) [sssd] [sbus_dispatch] (0x4000): dbus conn:
0x10034c9fc70
(Tue Jun 27 21:13:14 2017) [sssd] [sbus_dispatch] (0x4000): Dispatching.
(Tue Jun 27 21:13:14 2017) [sssd] [sbus_message_handler] (0x4000): Received
SBUS method [RegisterService]
(Tue Jun 27 21:13:14 2017) [sssd] [sbus_get_sender_id_send] (0x2000): Not a
sysbus message, quit
(Tue Jun 27 21:13:14 2017) [sssd] [sbus_handler_got_caller_id] (0x4000):
Received SBUS method [RegisterService]
(Tue Jun 27 21:13:14 2017) [sssd] [client_registration] (0x0100): Received
ID registration: (nss,1)
(Tue Jun 27 21:13:14 2017) [sssd] [mark_service_as_started] (0x0200):
Marking nss as started.
(Tue Jun 27 21:13:14 2017) [sssd] [mt_svc_exit_handler] (0x0040): Child
[pac] terminated with signal [11]
(Tue Jun 27 21:13:14 2017) [sssd] [mt_svc_restart] (0x0400): Scheduling
service pac for restart 1
(Tue Jun 27 21:13:14 2017) [sssd] [get_ping_config] (0x0100): Time between
service pings for [pac]: [10]
(Tue Jun 27 21:13:14 2017) [sssd] [get_ping_config] (0x0100): Time between
SIGTERM and SIGKILL for [pac]: [60]
(Tue Jun 27 21:13:14 2017) [sssd] 

[Freeipa-users] Re: Sync Issues

[Ludwig Krispenz via FreeIPA-users]

On 06/27/2017 07:36 PM, Devin Acosta via FreeIPA-users wrote:


I am running the latest CentOS 7.3 / FreeIPA release and it appears 
that my replication got broke.


[27/Jun/2017:17:28:58.705411461 +] NSMMReplicationPlugin - 
agmt="cn=meTolasdc-lmfpa-002.lxi.m451.tech" (lasdc-lmfpa-002:389): 
Data required to update replica has been purged from the changelog. 
The replica must be reinitialized.
[27/Jun/2017:17:29:02.257550913 +] 
agmt="cn=meTolasdc-lmfpa-002.lxi.m451.tech
" (lasdc-lmfpa-002:389) - Can't locate CSN 595283d600b40014 in the 
changelog (DB rc=-30988). If replication stops, the consumer may need 
to be reinitialized.


When I try to delete the agreement and re-create it I get the error:
Removal of IPA replication agreement is deprecated with managed IPA 
replication topology. Please use `ipa topologysegment-*` commands to 
manage the topology.


However when I try to delete the segment and recreate it I also get an 
error.


[root@lasdc-lmfpa-002 ~]# ipa topologysegment-del
Suffix name: domain
Segment name: las01-003-010.lxi.m451.tech-to-lasdc-lmfpa-002.lxi.m451.tech
ipa: ERROR: Server is unwilling to perform: Removal of Segment 
disconnects topology.Deletion not allowed.
if this is the only connection between these two servers you cannot 
remove the segment or the agreement, but this is not required. The error 
message says you might have to re-initialize (ipa-replica-manage 
re-initialize .).
you colud also first try to add another segment and see if replication 
will flow again.
Another option is to try to kickstart replication by forcing to ignore 
the missing csn by changing a param in the replcation agreement:


replace: nsds5ReplicaIgnoreMissingChange
nsds5ReplicaIgnoreMissingChange: once

But you should find what csn 95283d600b40014 refers to an if you 
could have lost changes.


Any ideas how i resolve this issue? I basically have 2 FreeIPA servers 
in each DC and the one DC is happy with the sync, but I lost all 
replication to the other so passwords aren't syncing across DC's.




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


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

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

[Freeipa-users] Re: Can't install client on scientific linux 7.3

[Florence Blanc-Renaud via FreeIPA-users]

On 06/27/2017 12:40 PM, Niels Walet via FreeIPA-users wrote:

I seem to have some serios issues with ipa on sl 7.3; on installing on a
client, the install works through fine until it bombs on the following
issue:
https://theoipa.ph.man.ac.uk/ipa/json
Created connection context.rpcclient_47349328
Forwarding 'schema' to json server 'https://ipa./ipa/json'
Destroyed connection context.rpcclient_47349328
Traceback (most recent call last):




Hi,

the traces until "Forwarding 'schema' to json server" look normal to me. 
Could you attach the traceback for us to find where the issue happens?


Thanks,
Flo.

---
Prof. Niels R. Walet Phone:  +44(0)1613063693
/School of Physics and Astronomy/ Mobile: +44(0)7516622121
/The University of Manchester /   Room 7.7, Schuster Building
/Manchester, M13 9PL,  UK/
email: niels.wa...@manchester.ac.uk   twitter: @nwalet


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


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