[Freeipa-users] Re: FreeIPA would freeze and require a service restart

2024-02-05 Thread Marcelo Carvalho via FreeIPA-users
Many thanks, I'll look into it.

_M

On Mon, Feb 5, 2024 at 8:00 AM Rob Crittenden  wrote:

> Marcelo Carvalho via FreeIPA-users wrote:
> > FreeIPA  would periodically freeze and would require a service restart -
> sudo ipactl restart.
> >
> > This has happened on freeipa-01 and freeipa-02. When it freezes, CLI
> commands would timeout and we would not be able to join systems to the
> FreeIPA domain.
> >
> > NOTE:   I have only caught FreeIPA frozen up while joining systems to
> the domain.
> >
> > Anyone with similar experience?  Any root cause related to the above?
> >
> > Please advise.
>
> Define "freeze". I'll assume hung.
>
> You'll want to try to identify the process that is hung and get a pstack
> from it, preferably with the debuginfo packages installed. That should
> help identify what is going on.
>
> rob
>
>

-- 



This email and any attachments may contain Astranis confidential 
and/or proprietary information governed by a non-disclosure agreement, and 
are intended solely for the individual or entity specified by the message.
--
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Freeipa-users] Re: FreeIPA would freeze and require a service restart

2024-02-05 Thread Rob Crittenden via FreeIPA-users
Marcelo Carvalho via FreeIPA-users wrote:
> FreeIPA  would periodically freeze and would require a service restart - sudo 
> ipactl restart.
> 
> This has happened on freeipa-01 and freeipa-02. When it freezes, CLI commands 
> would timeout and we would not be able to join systems to the FreeIPA domain. 
> 
> NOTE:   I have only caught FreeIPA frozen up while joining systems to the 
> domain.
> 
> Anyone with similar experience?  Any root cause related to the above?
> 
> Please advise.

Define "freeze". I'll assume hung.

You'll want to try to identify the process that is hung and get a pstack
from it, preferably with the debuginfo packages installed. That should
help identify what is going on.

rob
--
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Freeipa-users] Re: FreeIPA would freeze and require a service restart

2024-02-05 Thread Marcelo Carvalho via FreeIPA-users
Running on RHEL-9, up to version ipa --version
VERSION: 4.10.2, API_VERSION: 2.252
--
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Freeipa-users] FreeIPA would freeze and require a service restart

2024-02-05 Thread Marcelo Carvalho via FreeIPA-users
FreeIPA  would periodically freeze and would require a service restart - sudo 
ipactl restart.

This has happened on freeipa-01 and freeipa-02. When it freezes, CLI commands 
would timeout and we would not be able to join systems to the FreeIPA domain. 

NOTE:   I have only caught FreeIPA frozen up while joining systems to the 
domain.

Anyone with similar experience?  Any root cause related to the above?

Please advise.

Many thanks,

Marcelo Carvalho
IT Senior System Administrator
Astranis Space Technologies Corp.
mcarva...@astranis.com
https://www.astranis.com/
--
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Freeipa-users] FreeIPA replicas introducing third replica - only one CA

2024-02-05 Thread Finn Fysj via FreeIPA-users
I'm trying to setup a third replica server using the ansible_freeipa.ipareplica 
role. 
The role fails on the following step:

"[freeipa.ansible_freeipa.ipaclient : Install - Join IPA]":
"servers": [
  "192.168.1.100", (replica1.example.com
  "192.168.1.101"  (replica2.example.com
]
  "msg": "Cannot obtain CA certificate\nHTTP certificate download requires 
--force"


Following playbook:
roles:
  - role: freeipa.ansible_freeipa.ipareplica
vars:
  ipareplica_servers: ["replica1.example.com", "replica1.example.com"]
 

replica1 (master with CA) and replica2 already exists. I introduced replica2 to 
the ipareplica_servers variable, as seen above. If I remove replica2, I'm able 
to install and setup replica3, but from my understanding I'll be stuck with 
following topology:

replica2 <---> replica1 <---> replica3

When I in reality want:
replica2 <---> replica1 <---> replica3
^--^


I've also experienced a lot of errors with Install - Setup DS, after an 
uninstall: /usr/sbin/ipa-getkeytab Failed to parse result: Insufficient access 
rights\\n\\nFailed to get keytab!. 
Doesn't seem like the role cleans up properly. 


I struggle to understand this error, since the topology shows only Domain in 
the UI. 
--
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Freeipa-users] Re: Cannot create users on platform migration: sambaSID failure

2024-02-05 Thread Melissa Ferreira da Silva Boiko via FreeIPA-users
Thanks for the suggestions so far!

I'm documenting this on this thread because I found out why the previous
system had the custom sambaSamAccount attributes: They seem to be necessary
to authenticate SMB shares when FreeIPA is the LDAP backend to a Synology
NAS.  If I try to set LDAP authentication now, I get this error on Synology
DSM:

> Issue Details: The LDAP server does not support Samba schema.
> ...
> Recommended action: Enable CIFS plain text password authentication.  [and
if you do], this DSM cannot be the remote mount target of CIFS.

Some past threads on freeipa-users (mostly for TrueNAS) suggest that the
Samba schema attributes are deprecated in favour of something using
Kerberos, but I do not get that option in Synology at all.

I believe the previous sysadmins of our shop must have followed this guide
by Markus Opolka, or a similar HOWTO:
https://blog.cubieserver.de/2018/synology-nas-samba-nfs-and-kerberos-with-freeipa-ldap/

That would explain why I couldn't create users with the Web interface in my
new FreeIPA (4.11) instance; this guide necessitates manual setting of the
Samba attributes via command-line `ipa user-add` flags.

However, it is then a mystery to me why user account creation worked via
Web interface in the old (4.5) instance.

I'm not sure how to proceed here since CIFS mounting is one of our users'
primary uses of LDAP in the first place.  Maybe I'll recreate the Samba
attributes after all, try to restore the previous values from backups, and
document properly how to create users with the command-line options.

[]s

Am Mo., 29. Jan. 2024 um 14:52 Uhr schrieb Alexander Bokovoy <
aboko...@redhat.com>:

> On Пан, 29 сту 2024, Melissa Ferreira da Silva Boiko via FreeIPA-users
> wrote:
> >Seems like it has "ipaUserObjectClasses: sambasamaccount" which I see
> >mentioned in very old threads about Samba support only.  Here's the
> >full config:
>
> Thanks. You can remove sambaSamAccount by running
>
> $ ipa config-mod --delattr=ipaUserObjectClasses=sambaSamAccount
>
> Same applies to shadowAccount which we don't use by default either.
>
> >
> >```
> >  dn: cn=ipaConfig,cn=etc,dc=example,dc=local
> >  ipamaxusernamelength: 32
> >  ipahomesrootdir: /home
> >  ipadefaultloginshell: /bin/bash
> >  ipadefaultprimarygroup: ipausers
> >  ipadefaultemaildomain: example.com
> >  ipasearchtimelimit: 2
> >  ipasearchrecordslimit: 100
> >  ipausersearchfields: uid,givenname,sn,telephonenumber,ou,title
> >  ipagroupsearchfields: cn,description
> >  ipamigrationenabled: FALSE
> >  ipacertificatesubjectbase: O=EXAMPLE.LOCAL
> >  ipapwdexpadvnotify: 4
> >  ipaconfigstring: AllowNThash
> >  ipaconfigstring: KDC:Disable Last Success
> >  ipaselinuxusermaporder:
> guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
> >  ipaselinuxusermapdefault: unconfined_u:s0-s0:c0.c1023
> >  ipakrbauthzdata: MS-PAC
> >  ipakrbauthzdata: nfs:NONE
> >  ipauserauthtype: disabled
> >  ipauserauthtype: password
> >  cn: ipaConfig
> >  ipaGroupObjectClasses: top
> >  ipaGroupObjectClasses: groupofnames
> >  ipaGroupObjectClasses: nestedgroup
> >  ipaGroupObjectClasses: ipausergroup
> >  ipaGroupObjectClasses: ipaobject
> >  ipaMaxHostnameLength: 64
> >  ipaUserObjectClasses: top
> >  ipaUserObjectClasses: person
> >  ipaUserObjectClasses: organizationalperson
> >  ipaUserObjectClasses: inetorgperson
> >  ipaUserObjectClasses: inetuser
> >  ipaUserObjectClasses: posixaccount
> >  ipaUserObjectClasses: krbprincipalaux
> >  ipaUserObjectClasses: krbticketpolicyaux
> >  ipaUserObjectClasses: ipaobject
> >  ipaUserObjectClasses: ipasshuser
> >  ipaUserObjectClasses: sambasamaccount
> >  ipaUserObjectClasses: shadowAccount
> >  objectClass: nsContainer
> >  objectClass: top
> >  objectClass: ipaGuiConfig
> >  objectClass: ipaConfigObject
> >  objectClass: ipaUserAuthTypeClass
> >  objectClass: ipaNameResolutionData
> >```
> >
> >Thanks!
> >--
> >___
> >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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >List Archives:
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> >Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
>
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
>
>
--
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

[Freeipa-users] Re: CentOS 7 FreeIPA upgrade, 4.5 to 4.6.8: certmonger hanger

2024-02-05 Thread Melissa Ferreira da Silva Boiko via FreeIPA-users
Oh I'm not touching the original instance, it's still up and I'll leave it
there for the foreseeable future.  Attempts to upgrade CentOS in-place all
ran into tricky problems.  (The way I tested this was: I prepared snapshots
*and* backups of the VM, then tried to upgrade, and when it broke I rolled
it all back.)

What I did was to create replicas; as you've seen in my story, the winning
combination was a temporary CentOS 8 Stream / FreeIPA 4.9 replica as a
stepping-stone from 4.5, and from there a definitive replica with Fedora 39
/ FreeIPA 4.11.  This was mostly done with commands like
ipa-replica-install --server very-old-instance.example.com -n
example.com -r EXAMPLE.COM --setup-ca --no-ntp -w "$adminpass"
(--no-ntp because our instances are all LXC containers and the clock is set
by the host machine.)

Our installation uses the CA feature but not the DNS server.  Once I got a
FreeIPA 4.11 replica working with a functional CA, I promoted it to CA
"renewal master" as instructed in
https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master .
That also seems to have worked without a hitch.

I now changed our FreeIPA client configs, Ansible, and various LDAP clients
to point to the new replica.  So far it appears to work.  If a couple
months go uneventfully, I'll shut down the old instance and probably leave
it like that for a few months more, until finally I'm convinced everything
is working properly, and then unenroll the old instance from the replica
list (but still leave the VM there, shut down but not deleted. just in
case.)

Good luck with your systems!
[]s

Am Mo., 5. Feb. 2024 um 15:15 Uhr schrieb Kevin Vasko :

> Melissa,
>
> I’ve been following your thread here as I also have a 4.5.x system that
> _really_ needs to be updated, but I’m nervous to touch it since it “works”.
>
> How you testing this without breaking the instance? Im nervous I have
> issues like you are experiencing and it breaks everything. I would like to
> test and validate that the upgrade works before going all in. Care to share
> your process?
>
> -Kevin
>
> On Feb 5, 2024, at 7:21 AM, Melissa Ferreira da Silva Boiko via
> FreeIPA-users  wrote:
>
> 
> Thanks for the suggestion!
>
> I spun a new CentOS 7 image with 7.9.2009 / FreeIPA 4.6.8 (which involved
> setting up the incus server to cgroups v1).  Then I tried creating a
> replica from the 4.5.  It again broke on pki-tomcatd, but with a somewhat
> baffling error that I didn't know what to do about:
>
>   [3/30]: creating ACIs for admin
>   [4/30]: creating installation admin user
>   [5/30]: configuring certificate server instance
>   [error] IOError: [Errno 13] Permission denied: '/tmp/tmpRJcwYV'
> Your system may be partly configured.
> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>
> This appears to be related to
> https://bugzilla.redhat.com/show_bug.cgi?id=1677027
> Which apparently was fixed on FreeIPA 4.7.
>
> I couldn't find a release with 4.7 so I tried again with a VM with CentOS
> 8-Stream, which is supposed to have 4.9.  Only yum/dnf couldn't find the
> ipa-server package at all; they'd list ipa-client, but not server.  I'm not
> familiar with RPM-based systems so it took a lot of digging (including
> trying my hand at Rocky Linux and localinstall from manual RPM downloads,
> which led to problems with dependencies) until I found out I had to add
> module_hotfixes=1 in the appstream.repo file.
>
> With FreeIPA 4.9 once again the CA setup failed, with a new error:
>   [28/30]: importing IPA certificate profiles
> Lookup failed: Preferred host vm-ipa-half-3.intra.viaboxxsystems.de does
> not provide CA.
> Lookup failed: Preferred host vm-ipa-half-3.intra.viaboxxsystems.de does
> not provide CA.
>   [error] RemoteRetrieveError: Failed to authenticate to CA REST API
> Your system may be partly configured.
> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>
> There were some hard-to-read HTTP errors on the install log so I was
> already getting ready to give up and try to create a replica from Docker or
> something.  But just as a hail-mary I run the uninstall scripts, rebooted,
> and tried again, and to my surprise this time pki-tomcatd install worked!
> I got a warning then on the KDC step:
>
> Configuring Kerberos KDC (krb5kdc)
>   [1/1]: installing X509 Certificate for PKINIT
> PKINIT certificate request failed: Certificate issuance failed
> (CA_UNREACHABLE: Server at https://vm-ipa-half-3.intra.vi
> aboxxsystems.de/ipa/json failed request, will retry: 4035 (Request failed
> with status 500: Non-2xx response from CA REST
>  API: 500. ).)
> Failed to configure PKINIT
> Full PKINIT configuration did not succeed
> The setup will only install bits essential to the server functionality
> You can enable PKINIT after the setup completed using 'ipa-pkinit-manage'
>
> But ipa-replica-install finished with status: successful for the first
> time, and "ipa-pkinit-manage enable" worked.  I now have a FreeIPA 

[Freeipa-users] Re: CentOS 7 FreeIPA upgrade, 4.5 to 4.6.8: certmonger hanger

2024-02-05 Thread Kevin Vasko via FreeIPA-users
Melissa,I’ve been following your thread here as I also have a 4.5.x system that _really_ needs to be updated, but I’m nervous to touch it since it “works”.How you testing this without breaking the instance? Im nervous I have issues like you are experiencing and it breaks everything. I would like to test and validate that the upgrade works before going all in. Care to share your process?-KevinOn Feb 5, 2024, at 7:21 AM, Melissa Ferreira da Silva Boiko via FreeIPA-users  wrote:Thanks for the suggestion!I spun a new CentOS 7 image with 7.9.2009 / FreeIPA 4.6.8 (which involved setting up the incus server to cgroups v1).  Then I tried creating a replica from the 4.5.  It again broke on pki-tomcatd, but with a somewhat baffling error that I didn't know what to do about:      [3/30]: creating ACIs for admin      [4/30]: creating installation admin user      [5/30]: configuring certificate server instance      [error] IOError: [Errno 13] Permission denied: '/tmp/tmpRJcwYV'    Your system may be partly configured.    Run /usr/sbin/ipa-server-install --uninstall to clean up.This appears to be related tohttps://bugzilla.redhat.com/show_bug.cgi?id=1677027Which apparently was fixed on FreeIPA 4.7.I couldn't find a release with 4.7 so I tried again with a VM with CentOS 8-Stream, which is supposed to have 4.9.  Only yum/dnf couldn't find the ipa-server package at all; they'd list ipa-client, but not server.  I'm not familiar with RPM-based systems so it took a lot of digging (including trying my hand at Rocky Linux and localinstall from manual RPM downloads, which led to problems with dependencies) until I found out I had to add module_hotfixes=1 in the appstream.repo file.With FreeIPA 4.9 once again the CA setup failed, with a new error:  [28/30]: importing IPA certificate profilesLookup failed: Preferred host vm-ipa-half-3.intra.viaboxxsystems.de does not provide CA.Lookup failed: Preferred host vm-ipa-half-3.intra.viaboxxsystems.de does not provide CA.  [error] RemoteRetrieveError: Failed to authenticate to CA REST APIYour system may be partly configured.Run /usr/sbin/ipa-server-install --uninstall to clean up.There were some hard-to-read HTTP errors on the install log so I was already getting ready to give up and try to create a replica from Docker or something.  But just as a hail-mary I run the uninstall scripts, rebooted, and tried again, and to my surprise this time pki-tomcatd install worked!  I got a warning then on the KDC step:Configuring Kerberos KDC (krb5kdc)  [1/1]: installing X509 Certificate for PKINITPKINIT certificate request failed: Certificate issuance failed (CA_UNREACHABLE: Server at https://vm-ipa-half-3.intra.viaboxxsystems.de/ipa/json failed request, will retry: 4035 (Request failed with status 500: Non-2xx response from CA REST API: 500. ).)Failed to configure PKINITFull PKINIT configuration did not succeedThe setup will only install bits essential to the server functionalityYou can enable PKINIT after the setup completed using 'ipa-pkinit-manage'But ipa-replica-install finished with status: successful for the first time, and "ipa-pkinit-manage enable" worked.  I now have a FreeIPA 4.9.13 replica with CA; hopefully 4.11 will replicate from that without issues and then I can promote it to primary CA.---In summary, these are the issues I found so far trying to upgrade from FreeIPA 4.5.0:Upgrade FreeIPA 4.5 / CentOS7 to the last CentOS 7 / FreeIPA 4.6: breaks due to certmonger timeout.Replicate to current FreeIPA 4.11 / Fedora 39: breaks due to hash incompatibility.Replicate to FreeIPA 4.6 / fresh CentOS 7: breaks due to systemd /tmp permissions error.Replicate to FreeIPA 4.7: couldn't find lxc containers with this version.Replicate to Freeipa 4.9 / CentOS 8-Stream: had to downgrade incus host to cgroups v1; first couple attempts failed, but eventually it worked.[]sAm Do., 1. Feb. 2024 um 17:07 Uhr schrieb Rob Crittenden :Melissa Ferreira da Silva Boiko via FreeIPA-users wrote:
> Hello all.
> 
> I'm trying to replace an ancient FreeIPA 4.5.0 master (and primary CA
> master) on CentOS 7.4.  I am having problems trying to make replicas
> with FreeIPA 4.11, and past threads suggest the errors are due to
> incompatibility of password hash algorithms, which are supposed to be
> fixed on the older releases rather than the newer.
> 
> Therefore I'm trying to upgrade the old server to the current version in
> the CentOS 7 repos, 4.6.8, to try to create fresh replicas from there. 
> But I'm having issues with the certmonger systemd service hanging, and
> breaking ipa-server-upgrade--whether I update the whole CentOS to
> 7.9.2009, or just ipa-server and its dependencies, the result is the same.
> 
> This is where ipa-server-upgrade breaks:
> 
>         [Verifying that root certificate is published]
>         [Migrate CRL publish directory]
>         CRL tree already moved
>         [Verifying that CA proxy configuration is correct]
>         IPA server upgrade failed: Inspect 

[Freeipa-users] Re: Installing CA certificate isuue

2024-02-05 Thread Rob Crittenden via FreeIPA-users
mskaraca--- via FreeIPA-users wrote:
> Hi 
> I have the exact same case.
> can you share how can I loose the policy or get a certificate with a
> stronger signature algorithm 

# update-crypto-policies --set DEFAULT:SHA1

It is recommended to reboot afterward.

Or you have to request stronger hashing from whoever issued the certificate.

rob
--
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Freeipa-users] Re: Issues with sudo permissions

2024-02-05 Thread slekkus75 via FreeIPA-users





Sent with Proton Mail secure email.

On Friday, February 2nd, 2024 at 10:36, slek kus via FreeIPA-users 
 wrote:

> Hi Jochen, nsswitch.conf checks local files and sss. Below is the contents of 
> etc/pam.d/sudo:
> 
> 
> #%PAM-1.0
> 
> # Set up user limits from /etc/security/limits.conf.
> session required pam_limits.so
> 
> @include common-auth
> @include common-account
> @include common-session-noninteractive
> 
> 
> sudo -l:
> 
> 
> ansible@debclient1:~$ sudo -l
> [sudo] password for ansible:
> Sorry, user ansible may not run sudo on debclient1.
> 
> 
> sssd_[domain].log:
> https://privatebin.net/?e841ce0e62791e1b#CU9EhpDrajzQXEihhp2jmjbD92RtG8YZ6Sw4FxaZw1Zx
> 
> sssd_sudo.log:
> https://privatebin.net/?40e60858ff984c15#HcQQK2u8wCTYzA6tcttnaiQMsoQ1mVbjCnAovkvDpY6V
> 
> 
> I have created a new testuser, placed this one in the same hbac rules group. 
> also no sudo access.
> Added this new test user to the local sudo group, and access has been 
> granted. It shouldn't be nessecary to add IPA users to local groups, or am I 
> wrong here.
> 
> kind regards.
> --
> ___
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue


Hi Jochen, thanks for taking the time to help.
While done the sudo debug and not finding anything, I tried and enabled the 
default "allow_all" rule and it worked.
Then disabled allow_all again and it continued working as there's a dedicated 
policy. No idea why it functions now.
Issue has been solved and today it still is OK.

kind regards.
--
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Freeipa-users] Re: CentOS 7 FreeIPA upgrade, 4.5 to 4.6.8: certmonger hanger

2024-02-05 Thread Melissa Ferreira da Silva Boiko via FreeIPA-users
Thanks for the suggestion!

I spun a new CentOS 7 image with 7.9.2009 / FreeIPA 4.6.8 (which involved
setting up the incus server to cgroups v1).  Then I tried creating a
replica from the 4.5.  It again broke on pki-tomcatd, but with a somewhat
baffling error that I didn't know what to do about:

  [3/30]: creating ACIs for admin
  [4/30]: creating installation admin user
  [5/30]: configuring certificate server instance
  [error] IOError: [Errno 13] Permission denied: '/tmp/tmpRJcwYV'
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

This appears to be related to
https://bugzilla.redhat.com/show_bug.cgi?id=1677027
Which apparently was fixed on FreeIPA 4.7.

I couldn't find a release with 4.7 so I tried again with a VM with CentOS
8-Stream, which is supposed to have 4.9.  Only yum/dnf couldn't find the
ipa-server package at all; they'd list ipa-client, but not server.  I'm not
familiar with RPM-based systems so it took a lot of digging (including
trying my hand at Rocky Linux and localinstall from manual RPM downloads,
which led to problems with dependencies) until I found out I had to add
module_hotfixes=1 in the appstream.repo file.

With FreeIPA 4.9 once again the CA setup failed, with a new error:
  [28/30]: importing IPA certificate profiles
Lookup failed: Preferred host vm-ipa-half-3.intra.viaboxxsystems.de does
not provide CA.
Lookup failed: Preferred host vm-ipa-half-3.intra.viaboxxsystems.de does
not provide CA.
  [error] RemoteRetrieveError: Failed to authenticate to CA REST API
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

There were some hard-to-read HTTP errors on the install log so I was
already getting ready to give up and try to create a replica from Docker or
something.  But just as a hail-mary I run the uninstall scripts, rebooted,
and tried again, and to my surprise this time pki-tomcatd install worked!
I got a warning then on the KDC step:

Configuring Kerberos KDC (krb5kdc)
  [1/1]: installing X509 Certificate for PKINIT
PKINIT certificate request failed: Certificate issuance failed
(CA_UNREACHABLE: Server at https://vm-ipa-half-3.intra.vi
aboxxsystems.de/ipa/json failed request, will retry: 4035 (Request failed
with status 500: Non-2xx response from CA REST
 API: 500. ).)
Failed to configure PKINIT
Full PKINIT configuration did not succeed
The setup will only install bits essential to the server functionality
You can enable PKINIT after the setup completed using 'ipa-pkinit-manage'

But ipa-replica-install finished with status: successful for the first
time, and "ipa-pkinit-manage enable" worked.  I now have a FreeIPA 4.9.13
replica with CA; hopefully 4.11 will replicate from that without issues and
then I can promote it to primary CA.

---

In summary, these are the issues I found so far trying to upgrade from
FreeIPA 4.5.0:

Upgrade FreeIPA 4.5 / CentOS7 to the last CentOS 7 / FreeIPA 4.6: breaks
due to certmonger timeout.
Replicate to current FreeIPA 4.11 / Fedora 39: breaks due to hash
incompatibility.
Replicate to FreeIPA 4.6 / fresh CentOS 7: breaks due to systemd /tmp
permissions error.
Replicate to FreeIPA 4.7: couldn't find lxc containers with this version.
Replicate to Freeipa 4.9 / CentOS 8-Stream: had to downgrade incus host to
cgroups v1; first couple attempts failed, but eventually it worked.

[]s

Am Do., 1. Feb. 2024 um 17:07 Uhr schrieb Rob Crittenden <
rcrit...@redhat.com>:

> Melissa Ferreira da Silva Boiko via FreeIPA-users wrote:
> > Hello all.
> >
> > I'm trying to replace an ancient FreeIPA 4.5.0 master (and primary CA
> > master) on CentOS 7.4.  I am having problems trying to make replicas
> > with FreeIPA 4.11, and past threads suggest the errors are due to
> > incompatibility of password hash algorithms, which are supposed to be
> > fixed on the older releases rather than the newer.
> >
> > Therefore I'm trying to upgrade the old server to the current version in
> > the CentOS 7 repos, 4.6.8, to try to create fresh replicas from there.
> > But I'm having issues with the certmonger systemd service hanging, and
> > breaking ipa-server-upgrade--whether I update the whole CentOS to
> > 7.9.2009, or just ipa-server and its dependencies, the result is the
> same.
> >
> > This is where ipa-server-upgrade breaks:
> >
> > [Verifying that root certificate is published]
> > [Migrate CRL publish directory]
> > CRL tree already moved
> > [Verifying that CA proxy configuration is correct]
> > IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and
> > run command ipa-server-upgrade manually.
> > Unexpected error - see /var/log/ipaupgrade.log for details:
> > CalledProcessError: Command '/bin/systemctl start
> > certmonger.service' returned non-zero exit status 1
> > The ipa-server-upgrade command failed. See
> > /var/log/ipaupgrade.log for more information
> >
> > This is because 

[Freeipa-users] Re: Upgrade issues from 4.9.11 to 4.10.2 pki-tomcatd fails to start

2024-02-05 Thread Tania Hagan via FreeIPA-users
Hi Rob, 

Cheers, I looked in those logs as well, but nothing in particular is standing 
out as an error. 

After a week trying to find a solution, I think we'll build new servers and 
migrate the data from working servers as a way to move forward.  It seems a 
safer option upgrading from el9 to el9 anyways. 

Many Thanks, 
Tania
--
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue