[Freeipa-users] Re: Problems setting up replica on Raspberry Pi 3B (ARM)

[Jonathan Vaughn via FreeIPA-users]

Thanks! I'm looking forward to seeing these fixes hit the Fedora repo :)

On Sat, Jun 2, 2018 at 8:07 AM, Mark Reynolds  wrote:

> I was right I did fix all the ARM issues, but not in 1.3.8, only in
> 1.4.0.  It was a large change though that required a few patches.  I'll see
> what I can do about backporting the changes...
>
> On 06/01/2018 05:38 PM, Jonathan Vaughn wrote:
>
> Created https://pagure.io/389-ds-base/issue/49746
>
> I'll get you the build log once it's done building without the patch.
>
> On Fri, Jun 1, 2018 at 3:54 PM, Mark Reynolds 
> wrote:
>
>>
>>
>> On 06/01/2018 04:32 PM, Jonathan Vaughn wrote:
>>
>> Alright, I think I've got everything* working. (* Not running the CA
>> server on the Arm device, not tested, but from what I've read before I
>> would need to adjust the startup timeout since OpenJDK is so slow).
>>
>> 1) I removed the Arm replica from the cluster and reimaged the device
>> entirely and started over.
>>
>> 2) Rebuilt 389-ds-base using the patch by Mark Reynolds, and replica
>> install succeeded (just as it did with the patch before). I did use the
>> next version (1.3.8) of 389-ds-base because the package installed version
>> bumped up to 1.3.8.1 - patch worked same as on 1.3.7
>>
>> 3) I also had to apply the fix to /etc/httpd/conf.d/ipa.conf from
>> https://pagure.io/freeipa/issue/7337 so that Web UI login could work (I
>> did this previously on the Arm device but still couldn't login - likely
>> just too many things were tried and something else was busted elsewhere).
>>
>> As far as I can tell everything seems to be working now.
>>
>> I'm not sure if the patch provided would work as-is or if it would break
>> on non-Arm architectures.
>>
>> The patch :
>>
>> diff --git a/ldap/servers/plugins/replication/repl5_agmt.c
>> b/ldap/servers/plugins/replication/repl5_agmt.c
>> index d71d3f38b..e0f1f41bd 100644
>> --- a/ldap/servers/plugins/replication/repl5_agmt.c
>> +++ b/ldap/servers/plugins/replication/repl5_agmt.c
>> @@ -3035,7 +3035,7 @@ agmt_update_maxcsn(Replica *r, Slapi_DN *sdn, int
>> op, LDAPMod **mods, CSN *csn)
>>  slapi_ch_free_string(>maxcsn);
>>  agmt->maxcsn = slapi_ch_smprintf("%s;%s;%s;%ld;%d;%s",
>> slapi_sdn_get_dn(agmt->replarea),
>>
>> slapi_rdn_get_value_by_ref(slapi_rdn_get_rdn(agmt->rdn)), agmt->hostname,
>> - agmt->port,
>> agmt->consumerRID, maxcsn);
>> + (long)agmt->port,
>> (int)agmt->consumerRID, maxcsn);
>>  }
>>  PR_Unlock(agmt->lock);
>>  }
>>
>> To get this fixed properly (to avoid building from source), should I open
>> an issue in Pagure.io ? Or will someone else handle that?
>>
>>
>> Please file ticket:
>>
>> https://pagure.io/389-ds-base/new_issue
>>
>> Can you also do me a favor please?  Please build the server again, but
>> without my patch, and send the build output to me.  I want to see if there
>> are any compiler errors/warnings.  The issue is that I fixed all the issues
>> on ARM, including this exact issue you ran into.  Its working for others
>> without issue.  I was wondering if it was perhaps Raspberry's version of
>> ARM  that was causing issues.  Anyway the build output (without my fix)
>> would be very interesting to look at.
>>
>> Thanks,
>> Mark
>>
>>
>> On Wed, May 23, 2018 at 4:04 PM, Jonathan Vaughn 
>> wrote:
>>
>>> Anyone have any further suggestions for troubleshooting this issue with
>>> the web UI?
>>>
>>> On Fri, May 18, 2018 at 4:01 PM, Jonathan Vaughn >> > wrote:
>>>
 httpd error_log

 [Fri May 18 15:58:29.546255 2018] [wsgi:error] [pid 14004:tid
 2903716672] [remote 10.10.11.3:59284] ipa: DEBUG: WSGI
 wsgi_dispatch.__call__:
 [Fri May 18 15:58:29.547217 2018] [wsgi:error] [pid 14004:tid
 2903716672] [remote 10.10.11.3:59284] ipa: DEBUG: WSGI
 login_password.__call__:
 [Fri May 18 15:58:29.549799 2018] [wsgi:error] [pid 14004:tid
 2903716672] [remote 10.10.11.3:59284] ipa: DEBUG: Obtaining armor in
 ccache /var/run/ipa/ccaches/armor_14004
 [Fri May 18 15:58:29.550812 2018] [wsgi:error] [pid 14004:tid
 2903716672] [remote 10.10.11.3:59284] ipa: DEBUG: Initializing
 anonymous ccache
 [Fri May 18 15:58:29.552268 2018] [wsgi:error] [pid 14004:tid
 2903716672] [remote 10.10.11.3:59284] ipa: DEBUG: Starting external
 process
 [Fri May 18 15:58:29.553377 2018] [wsgi:error] [pid 14004:tid
 2903716672] [remote 10.10.11.3:59284] ipa: DEBUG: args=/usr/bin/kinit
 -n -c /var/run/ipa/ccaches/armor_14004 -X X509_anchors=
 FILE:/var/kerberos/krb5kdc/kdc.crt -X X509_anchors=FILE:/var/lib/ipa
 -client/pki/kdc-ca-bundle.pem
 [Fri May 18 15:58:30.486537 2018] [wsgi:error] [pid 14004:tid
 2903716672] [remote 10.10.11.3:59284] ipa: DEBUG: Process finished,
 return code=0
 [Fri May 18 15:58:30.488137 2018] [wsgi:error] [pid 14004:tid
 2903716672] [remote 

[Freeipa-users] Re: Logon by ssh but not console?

[Bret Wortman via FreeIPA-users]

Here's weirdness for you. I left yesterday and it wasn't working. I 
arrived this morning and it was. Near as I can tell, it had to do with 
the sssd cache.


Another user had a similar problem when I unenrolled & enrolled his 
system to the new servers. It wouldn't take any of his passwords (he had 
been authenticated by the old servers when he first got in). I stopped 
sssd, rm -rf'd the cache db files, and then restarted it and voila, he 
was able to authenticate with the new servers.


Thanks, all!


On 06/03/2018 03:30 PM, Bret Wortman via FreeIPA-users wrote:
I don’t think it is, actually. That’s just where we left off. I’ll 
start walking more logs this week.


photo   

*Bret Wortman*
Founder,Damascus Products LLC

855-644-2783 |b...@damascusproducts.com 



http://damascusproducts.com/ 



10332 Main St Suite 319 Fairfax, VA 22030 

 
	



  





  

On Jun 3, 2018, 3:00 PM -0400, Jakub Hrozek , wrote:



On 3 Jun 2018, at 13:33, Bret Wortman via FreeIPA-users 
 wrote:


I just realized that I never closed the loop on this problem and 
just finished upgrading all my systems to use our new IPA servers. 
And this problem is still with me.


I can log onto some workstations but not all. My only enabled hbac 
rule is still "allow_all", and it's as permissive as it gets.


Is there anything else I can check? I'm trying to get this working 
before my users arrive on Monday and carry off my head on a pikestaff…


Are you sure the issue is HBAC, then? Normally I first check either 
/var/log/secure or journald, search for pam_sss to see what kind of 
error sssd returned (if any..) and then work my way through the sssd 
logs, the sssd_pam.log/sssd_nss.log first and then the sssd_domain.log..





Bret


On 02/22/2018 09:30 AM, Bret Wortman wrote:
Back to this thread; I stood up a new VM and used 
ipa-client-install to subscribe it to the new server. I can log on 
to it from both ssh and console, so the problem on my original 
workstation appears to be in switching from one server to another.


Thoughts?


On 02/21/2018 10:29 AM, Bret Wortman wrote:
My only hbac rule is "allow_all", and it's enabled. I hadn't 
gotten around to setting up any additional ones yet.



On 02/21/2018 10:14 AM, Rob Crittenden wrote:

Bret Wortman via FreeIPA-users wrote:
Any ideas why I might be prevented from logging in on a system 
through

GDM and the console, but if I log in as root and:

# ssh bretw@localhost

I'm able to log in without issues? And it'll tell me about 
failed logins

for every time I try through GDM or the console.

This is on a brand new IPA server I'm setting up using data from our
older ones but it's not set up as a replica.
Check HBAC rules. Logging into console is a different pam service 
than ssh.


rob





___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To 

[Freeipa-users] Re: apparent error with ad_enum_cross_dom_members

[Sumit Bose via FreeIPA-users]

On Mon, Jun 04, 2018 at 05:33:28AM +, Craig H Silva (Cenitex) via 
FreeIPA-users wrote:
> Background - stupidly large AD domain with 30,000 plus groups. It is a forest 
> with a number of legacy domains that are not relevant to our authentication 
> on Linux but the AD admins don't want to allow us to mess with their schema 
> so we still use group membership to manage sudo.
> 
> We're also attempting to align with Windows through use of nested groups to 
> fit in with enterprise preference for RBAC.
> 
> It's complicated and there's no resourcing to put in place an IPA service 
> which would help.
> 
> Anyway these are the relevant config elements:
> 
> id_provider = ad
> auth_provider = ad
> access_provider = ad
> subdomains_provider = none
> enumerate = true
> ignore_group_members = true
> cache_credentials = true
> ldap_id_mapping = true
> ldap_schema = ad
> 
> ( I can provide full config if requested). We had gone to full enumeration 
> and ignore_group_members to ensure that the groups that provide sudo access 
> are available without ridiculous cpu utilisation and it was working but hit 
> this apparent issue:
> 
> [sssd[be[ourdomain.xxx.xxx]]] [ad_enum_cross_dom_members] (0x0080): Failed to 
> add [CN=RG-Ourcompany-Ops-3rd Party-Data\#3-G,OU=CenITex,OU=Operations 
> Roles,OU=Delegated Groups,OU=
> Infrastructure Security,DC=ourcompany,DC=xxx,DC=xxx,,DC=xx]: Input/output 
> error

I guess this issue might be caused by the '\#3' part of the DN which is
not properly sanitized for a search.

Is the literal group name 'RG-Ourcompany-Ops-3rd Party-Data\#3-G'? I'm
asking to see if the '\' was already added to sanitize the original
name.

Do you have other groups with similar name which do not trigger this
error message?

bye,
Sumit

> 
> Can raise a bug report if it's clear that this is the issue.
> 
> Symptom is that group enumeration that was comprehensive, now seems to stop 
> abruptly.
> 
> Cheers
> 
> Craig Silva
> _
> Craig Silva | Specialist Engineer - Unix Services - Servers, Storage and IDAM
> Cenitex | Level 15, 80 Collins Street, Melbourne 3000
> ph: 03-8688-1297 mob: 0429 365 609 | 
> www.cenitex.vic.gov.au
> This office is located on the land of the Traditional Owners of the Kulin 
> Nation.
> 
> [cenitex logo]  
> [cid:image004.jpg@01D36DDE.27450B80] 
>    
> [cid:image006.jpg@01D36DDE.27450B80]    
> [cid:image010.jpg@01D36DDE.27450B80] 
> 
> Accountability, Collaboration, Respect, Initiative and Courage
> 
> 
> --
> Notice:
> 
> This email and any attachments may contain information that is personal,
> confidential, legally privileged and/or copyright. No part of it should be
> reproduced, adapted or communicated without the prior written consent of the
> copyright owner.
> 
> It is the responsibility of the recipient to check for and remove viruses.
> 
> If you have received this email in error, please notify the sender by return
> email, delete it from your system and destroy any copies. You are not 
> authorised
> to use, communicate or rely on the information contained in this email.
> 
> Please consider the environment before printing this email.






> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/2UT3LSZLQT6YHMVZVW6Q6YXTUQIK4C7U/
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/Q5YRR2NMPOGQ3WXE7EBZC234BCVLMXWA/