[Freeipa-users] Re: krb5kdc: No such file or directory

[Roberto Cornacchia via FreeIPA-users]

Rob,

ldapmodify worked fine and after that I was able to generate all the
missing SIDs, which solved my initial problem.

Thanks a lot!
Roberto

On Wed, 3 Jan 2024 at 15:54, Rob Crittenden  wrote:

> Roberto Cornacchia wrote:
> > BTW, from the currently used UIDs/GIDs you can clearly see that they
> > have been assigned by two servers which administered 100K IDs each.
> >
> > On Wed, 3 Jan 2024 at 15:30, Roberto Cornacchia
> > mailto:roberto.cornacc...@gmail.com>>
> wrote:
> >
> > Thanks Rob.
> >
> > This is the current situation (I added comma separators to make it
> > more readable)
> >
> > #
> > Domain range:
> > 117,200,000 - 117,200,999
> >
> > currently used UIDs/GIDs:
> > 1,172,000,000 (admin) - 1,172,000,029
> > 1,172,100,500 - 1,172,100,513
> >
> > DNA ranges:
> > 1,172,150,501 - 1,172,175,499
> > 1,172,175,501 - 1,172,199,999
> > #
> >
> > I have no idea how it came to this. I am the only one busy with it
> > and I never change any defaults, at least not intentionally.
>
> Thanks, the commas made this very gentle on my eyes :-)
>
> So there are several things to do. To reset to your original range
> you'll need to modify LDAP directly because our tooling doesn't allow
> the initial range to be changed (for the reason you're seeing, we just
> never expected it to somehow get out of whack on its own).
>
> This will show you how to get and modify the range. My realm is
> EXAMPLE.TEST and the domain is example.test. You'll need to modify to
> your installation.
>
> $ kinit admin
> $ ipa idrange-show --all --raw cn=EXAMPLE.TEST_id_range
>   dn: cn=EXAMPLE.TEST_id_range,cn=ranges,cn=etc,dc=example,dc=test
>   cn: EXAMPLE.TEST_id_range
>   ipabaseid: 180240
>   ipaidrangesize: 20
>   ipabaserid: 1000
>   ipasecondarybaserid: 1
>   iparangetype: ipa-local
>   objectclass: top
>   objectclass: ipaIDrange
>   objectclass: ipaDomainIDRange
>
> $ ldapmodify -Y GSSAPI -Q
> dn: cn=EXAMPLE.TEST_id_range,cn=ranges,cn=etc,dc=example,dc=test
> changetype: modify
> replace: ipaidrangesize
> ipaidrangesize: 20
> -
> replace: ipabaseid
> ipabaseid: 117200
> 
> modifying entry
> "cn=EXAMPLE.TEST_id_range,cn=ranges,cn=etc,dc=example,dc=test"
> ^D to quit
>
> You can use ipa-replica-manage dnarange-set to manage the DNA ranges.
> Typically it would be cut in half between the two servers assuming
> entries are added on both. In short it isn't mandatory for every IPA
> server to have a range, but since yours have one why not just split it.
>
> rob
>
> >
> > The domain range seems to be really wrong, because though the digits
> > are similar it is an order of magnitude smaller.
> > The only reason I could think of is that at some point I was in the
> > web UI, on the range field, and I accidentally removed a trailing
> > zero (and saved, apparently).
> > Still, the range size should have been 200K while now it's 1000,
> > that cannot be a typo.
> >
> > Besides the domain range, the DNA ranges don't overlap either with
> > the currently used IDs.
> >
> > Could you please advise on what the best way to set this straight is?
> >
> > My intuition would be to leave the existing IDs alone and reset both
> > the domain range and the DNA ranges so that they cover the existing
> >     IDs, so:
> >
> > Domain range: 1,172,000,000 - 1,172,199,999
> >
> > Is this the correct way? And would I then need to reset the DNA
> > ranges manually by splitting this in two, or is that done
> > automatically somehow?
> >
> > Thanks, Roberto
> >
> > On Wed, 3 Jan 2024 at 14:34, Rob Crittenden  > <mailto:rcrit...@redhat.com>> wrote:
> >
> > Roberto Cornacchia via FreeIPA-users wrote:
> > > Also, I just noticed this:
> > >
> > > # ipa-replica-manage  dnarange-show
> > > ipa02.hq.spinque.com <http://ipa02.hq.spinque.com>
> > <http://ipa02.hq.spinque.com>: 1172150501-1172175499
> > > ipa01.hq.spinque.com <http://ipa01.hq.spinque.com>
> > <http://ipa01.hq.spinque.com>: 1172175501-117219
> > >
> > > while ipa idrange-find showed:
> > >
> > >   ipabaseid: 11720
> > >   ipaidrangesize: 1000
> > >
> >

[Freeipa-users] Re: krb5kdc: No such file or directory

[Roberto Cornacchia via FreeIPA-users]

BTW, from the currently used UIDs/GIDs you can clearly see that they have
been assigned by two servers which administered 100K IDs each.

On Wed, 3 Jan 2024 at 15:30, Roberto Cornacchia <
roberto.cornacc...@gmail.com> wrote:

> Thanks Rob.
>
> This is the current situation (I added comma separators to make it more
> readable)
>
> #
> Domain range:
> 117,200,000 - 117,200,999
>
> currently used UIDs/GIDs:
> 1,172,000,000 (admin) - 1,172,000,029
> 1,172,100,500 - 1,172,100,513
>
> DNA ranges:
> 1,172,150,501 - 1,172,175,499
> 1,172,175,501 - 1,172,199,999
> #
>
> I have no idea how it came to this. I am the only one busy with it and I
> never change any defaults, at least not intentionally.
>
> The domain range seems to be really wrong, because though the digits are
> similar it is an order of magnitude smaller.
> The only reason I could think of is that at some point I was in the web
> UI, on the range field, and I accidentally removed a trailing zero (and
> saved, apparently).
> Still, the range size should have been 200K while now it's 1000, that
> cannot be a typo.
>
> Besides the domain range, the DNA ranges don't overlap either with the
> currently used IDs.
>
> Could you please advise on what the best way to set this straight is?
>
> My intuition would be to leave the existing IDs alone and reset both the
> domain range and the DNA ranges so that they cover the existing IDs, so:
>
> Domain range: 1,172,000,000 - 1,172,199,999
>
> Is this the correct way? And would I then need to reset the DNA ranges
> manually by splitting this in two, or is that done automatically somehow?
>
> Thanks, Roberto
>
> On Wed, 3 Jan 2024 at 14:34, Rob Crittenden  wrote:
>
>> Roberto Cornacchia via FreeIPA-users wrote:
>> > Also, I just noticed this:
>> >
>> > # ipa-replica-manage  dnarange-show
>> > ipa02.hq.spinque.com <http://ipa02.hq.spinque.com>:
>> 1172150501-1172175499
>> > ipa01.hq.spinque.com <http://ipa01.hq.spinque.com>:
>> 1172175501-117219
>> >
>> > while ipa idrange-find showed:
>> >
>> >   ipabaseid: 11720
>> >   ipaidrangesize: 1000
>> >
>> > These ranges are one order of magnitude far apart:
>> >
>> > 11720
>> > 1172150501
>> >
>> > I'm confused now. Shouldn't the two DNA ranges be the per-replica split
>> > of the defined local domain ID range?
>>
>> Typically yes. We have no insight into your installation so can't really
>> speculate.
>>
>> The ipa-local range should be immutable so I have no idea how that can
>> be changed other than someone using ldapmodify directly. The
>> initially-allocated range should be in the original
>> /var/log/ipaserver-install.log if you still have that.
>>
>> The DNA ranges can be manually set so it's possible someone fat-fingered
>> it at some point. I'd also suggest looking at the DNA next range to see
>> if something is set.
>>
>> I'd suggest to start by looking at the current ids (both uid and gid)
>> that have been issued and see what ranges they fall into.
>>
>> rob
>>
>> >
>> >
>> > On Wed, 3 Jan 2024 at 11:22, Roberto Cornacchia
>> > mailto:roberto.cornacc...@gmail.com>>
>> wrote:
>> >
>> > Hi Alexander,
>> >
>> > Looking back at related messages, I've read a bunch of RedHat
>> articles.
>> >
>> > I ran
>> >
>> > $  ipa config-mod --enable-sid --add-sids
>> >
>> > which did not return with failure but also did not add SIDs to
>> users.
>> >
>> > Looking further, I understood that this fails because some UIDs and
>> > GIDs are outside the defined ID range.
>> > I don't really know how that happened, but apparently it did.
>> >
>> > I have finally landed on this article [1], which should help me fix
>> > this and then I'll be able to try the SIDs generation again.
>> >
>> > If I look at the existing ID ranges, it looks like the primary range
>> > is defined to be only 1000 IDs long:
>> >
>> > # ipa idrange-find --all --raw
>> > 
>> > 2 ranges matched
>> > 
>> >   dn:
>> > cn=HQ.SPINQUE.COM_id_range,cn=ranges,cn=etc,dc=hq,dc=spinque,dc=com
>> >   cn: HQ.SPINQUE.COM_id_range
>> >   ipabaseid: 11720
>> >   ipaidrangesize: 1000
>>

[Freeipa-users] Re: krb5kdc: No such file or directory

[Roberto Cornacchia via FreeIPA-users]

Thanks Rob.

This is the current situation (I added comma separators to make it more
readable)

#
Domain range:
117,200,000 - 117,200,999

currently used UIDs/GIDs:
1,172,000,000 (admin) - 1,172,000,029
1,172,100,500 - 1,172,100,513

DNA ranges:
1,172,150,501 - 1,172,175,499
1,172,175,501 - 1,172,199,999
#

I have no idea how it came to this. I am the only one busy with it and I
never change any defaults, at least not intentionally.

The domain range seems to be really wrong, because though the digits are
similar it is an order of magnitude smaller.
The only reason I could think of is that at some point I was in the web UI,
on the range field, and I accidentally removed a trailing zero (and saved,
apparently).
Still, the range size should have been 200K while now it's 1000, that
cannot be a typo.

Besides the domain range, the DNA ranges don't overlap either with the
currently used IDs.

Could you please advise on what the best way to set this straight is?

My intuition would be to leave the existing IDs alone and reset both the
domain range and the DNA ranges so that they cover the existing IDs, so:

Domain range: 1,172,000,000 - 1,172,199,999

Is this the correct way? And would I then need to reset the DNA ranges
manually by splitting this in two, or is that done automatically somehow?

Thanks, Roberto

On Wed, 3 Jan 2024 at 14:34, Rob Crittenden  wrote:

> Roberto Cornacchia via FreeIPA-users wrote:
> > Also, I just noticed this:
> >
> > # ipa-replica-manage  dnarange-show
> > ipa02.hq.spinque.com <http://ipa02.hq.spinque.com>:
> 1172150501-1172175499
> > ipa01.hq.spinque.com <http://ipa01.hq.spinque.com>:
> 1172175501-117219
> >
> > while ipa idrange-find showed:
> >
> >   ipabaseid: 11720
> >   ipaidrangesize: 1000
> >
> > These ranges are one order of magnitude far apart:
> >
> > 11720
> > 1172150501
> >
> > I'm confused now. Shouldn't the two DNA ranges be the per-replica split
> > of the defined local domain ID range?
>
> Typically yes. We have no insight into your installation so can't really
> speculate.
>
> The ipa-local range should be immutable so I have no idea how that can
> be changed other than someone using ldapmodify directly. The
> initially-allocated range should be in the original
> /var/log/ipaserver-install.log if you still have that.
>
> The DNA ranges can be manually set so it's possible someone fat-fingered
> it at some point. I'd also suggest looking at the DNA next range to see
> if something is set.
>
> I'd suggest to start by looking at the current ids (both uid and gid)
> that have been issued and see what ranges they fall into.
>
> rob
>
> >
> >
> > On Wed, 3 Jan 2024 at 11:22, Roberto Cornacchia
> > mailto:roberto.cornacc...@gmail.com>>
> wrote:
> >
> > Hi Alexander,
> >
> > Looking back at related messages, I've read a bunch of RedHat
> articles.
> >
> > I ran
> >
> > $  ipa config-mod --enable-sid --add-sids
> >
> > which did not return with failure but also did not add SIDs to
> users.
> >
> > Looking further, I understood that this fails because some UIDs and
> > GIDs are outside the defined ID range.
> > I don't really know how that happened, but apparently it did.
> >
> > I have finally landed on this article [1], which should help me fix
> > this and then I'll be able to try the SIDs generation again.
> >
> > If I look at the existing ID ranges, it looks like the primary range
> > is defined to be only 1000 IDs long:
> >
> > # ipa idrange-find --all --raw
> > 
> > 2 ranges matched
> > 
> >   dn:
> > cn=HQ.SPINQUE.COM_id_range,cn=ranges,cn=etc,dc=hq,dc=spinque,dc=com
> >   cn: HQ.SPINQUE.COM_id_range
> >   ipabaseid: 11720
> >   ipaidrangesize: 1000
> >   ipabaserid: 1000
> >   ipasecondarybaserid: 1
> >   iparangetype: ipa-local
> >   objectclass: top
> >   objectclass: ipaIDrange
> >   objectclass: ipaDomainIDRange
> >
> >   dn:
> >
>  cn=HQ.SPINQUE.COM_subid_range,cn=ranges,cn=etc,dc=hq,dc=spinque,dc=com
> >   cn: HQ.SPINQUE.COM_subid_range
> >   ipabaseid: 2147483648
> >   ipaidrangesize: 2147352576
> >   ipabaserid: 2147482648
> >   ipanttrusteddomainsid: S-1-5-21-738065-838566-3901153701
> >   iparangetype: ipa-ad-trust
> >   objectclass: top
> >   objectclass: ipaIDrange
> >   objectclass: ipaTrustedADDomainRange

[Freeipa-users] Re: krb5kdc: No such file or directory

[Roberto Cornacchia via FreeIPA-users]

Also, I just noticed this:

# ipa-replica-manage  dnarange-show
ipa02.hq.spinque.com: 1172150501-1172175499
ipa01.hq.spinque.com: 1172175501-117219

while ipa idrange-find showed:

  ipabaseid: 11720
  ipaidrangesize: 1000

These ranges are one order of magnitude far apart:

11720
1172150501

I'm confused now. Shouldn't the two DNA ranges be the per-replica split of
the defined local domain ID range?


On Wed, 3 Jan 2024 at 11:22, Roberto Cornacchia <
roberto.cornacc...@gmail.com> wrote:

> Hi Alexander,
>
> Looking back at related messages, I've read a bunch of RedHat articles.
>
> I ran
>
> $  ipa config-mod --enable-sid --add-sids
>
> which did not return with failure but also did not add SIDs to users.
>
> Looking further, I understood that this fails because some UIDs and GIDs
> are outside the defined ID range.
> I don't really know how that happened, but apparently it did.
>
> I have finally landed on this article [1], which should help me fix this
> and then I'll be able to try the SIDs generation again.
>
> If I look at the existing ID ranges, it looks like the primary range is
> defined to be only 1000 IDs long:
>
> # ipa idrange-find --all --raw
> 
> 2 ranges matched
> 
>   dn: cn=HQ.SPINQUE.COM_id_range,cn=ranges,cn=etc,dc=hq,dc=spinque,dc=com
>   cn: HQ.SPINQUE.COM_id_range
>   ipabaseid: 11720
>   ipaidrangesize: 1000
>   ipabaserid: 1000
>   ipasecondarybaserid: 1
>   iparangetype: ipa-local
>   objectclass: top
>   objectclass: ipaIDrange
>   objectclass: ipaDomainIDRange
>
>   dn:
> cn=HQ.SPINQUE.COM_subid_range,cn=ranges,cn=etc,dc=hq,dc=spinque,dc=com
>   cn: HQ.SPINQUE.COM_subid_range
>   ipabaseid: 2147483648
>   ipaidrangesize: 2147352576
>   ipabaserid: 2147482648
>   ipanttrusteddomainsid: S-1-5-21-738065-838566-3901153701
>   iparangetype: ipa-ad-trust
>   objectclass: top
>   objectclass: ipaIDrange
>   objectclass: ipaTrustedADDomainRange
>
> I seem to remember that the default range size is 200K, and I'm sure I
> haven't reduced it myself.
>
> So my question, before trying to fix this, is: are you aware of this
> happening for a reason, maybe during one of the upgrades? Can I safely
> re-expand the range?
>
> Thanks for your support, Roberto
>
> [1] https://access.redhat.com/solutions/394763
>
> On Tue, 2 Jan 2024 at 17:04, Alexander Bokovoy 
> wrote:
>
>> On Аўт, 02 сту 2024, Roberto Cornacchia via FreeIPA-users wrote:
>> >Hi there, clients are having trouble with kerberos authentication:
>> >
>> >$ kinit -V user
>> >Using existing cache: xx:y
>> >Using principal: u...@sub.example.com 
>> >Password for u...@sub.example.com :
>> >kinit: Generic error (see e-text) while getting initial credentials
>> >
>> >On the ipa server, /var/log/krb5kdc.log says:
>> >
>> >Dec 24 14:40:34 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ (6
>> etypes
>> >{aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
>> >aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
>> >camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) <
>> ><http://192.168.0.202/>IP>: NEEDED_PREAUTH: u...@sub.example.com
>> > for krbtgt/sub.example@sub.example.com,
>> >Additional pre-authentication required
>> >Dec 24 14:40:34 ipa01.sub.example.com krb5kdc[3324](info): closing down
>> fd
>> >11
>> >Dec 24 14:40:51 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ :
>> >handle_authdata (2)
>> >Dec 24 14:40:51 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ (6
>> etypes
>> >{aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
>> >aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
>> >camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) <
>> ><http://192.168.0.202/>IP>: HANDLE_AUTHDATA: user <
>> robe...@sub.example.com>
>> >@SUB.EXAMPLE.COM  for krbtgt/
>> >sub.example@sub.example.com, No such file or directory
>>
>> ^^^ this means the user roberto has no SID assigned. Look into numerous
>> discussions on this mailing list in 2023, there are plenty of suggested
>> actions in those threads.
>>
>> >Dec 24 14:40:51 ipa01.sub.example.com krb5kdc[3324](info): closing down
>> fd
>> >11
>> >Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ (4
>> etypes
>> >{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
>> >aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19)}) <
>> ><http://192.168.0.16/>I

[Freeipa-users] Re: krb5kdc: No such file or directory

[Roberto Cornacchia via FreeIPA-users]

Hi Alexander,

Looking back at related messages, I've read a bunch of RedHat articles.

I ran

$  ipa config-mod --enable-sid --add-sids

which did not return with failure but also did not add SIDs to users.

Looking further, I understood that this fails because some UIDs and GIDs
are outside the defined ID range.
I don't really know how that happened, but apparently it did.

I have finally landed on this article [1], which should help me fix this
and then I'll be able to try the SIDs generation again.

If I look at the existing ID ranges, it looks like the primary range is
defined to be only 1000 IDs long:

# ipa idrange-find --all --raw

2 ranges matched

  dn: cn=HQ.SPINQUE.COM_id_range,cn=ranges,cn=etc,dc=hq,dc=spinque,dc=com
  cn: HQ.SPINQUE.COM_id_range
  ipabaseid: 11720
  ipaidrangesize: 1000
  ipabaserid: 1000
  ipasecondarybaserid: 1
  iparangetype: ipa-local
  objectclass: top
  objectclass: ipaIDrange
  objectclass: ipaDomainIDRange

  dn: cn=HQ.SPINQUE.COM_subid_range,cn=ranges,cn=etc,dc=hq,dc=spinque,dc=com
  cn: HQ.SPINQUE.COM_subid_range
  ipabaseid: 2147483648
  ipaidrangesize: 2147352576
  ipabaserid: 2147482648
  ipanttrusteddomainsid: S-1-5-21-738065-838566-3901153701
  iparangetype: ipa-ad-trust
  objectclass: top
  objectclass: ipaIDrange
  objectclass: ipaTrustedADDomainRange

I seem to remember that the default range size is 200K, and I'm sure I
haven't reduced it myself.

So my question, before trying to fix this, is: are you aware of this
happening for a reason, maybe during one of the upgrades? Can I safely
re-expand the range?

Thanks for your support, Roberto

[1] https://access.redhat.com/solutions/394763

On Tue, 2 Jan 2024 at 17:04, Alexander Bokovoy  wrote:

> On Аўт, 02 сту 2024, Roberto Cornacchia via FreeIPA-users wrote:
> >Hi there, clients are having trouble with kerberos authentication:
> >
> >$ kinit -V user
> >Using existing cache: xx:y
> >Using principal: u...@sub.example.com 
> >Password for u...@sub.example.com :
> >kinit: Generic error (see e-text) while getting initial credentials
> >
> >On the ipa server, /var/log/krb5kdc.log says:
> >
> >Dec 24 14:40:34 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ (6
> etypes
> >{aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
> >aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
> >camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) <
> ><http://192.168.0.202/>IP>: NEEDED_PREAUTH: u...@sub.example.com
> > for krbtgt/sub.example@sub.example.com,
> >Additional pre-authentication required
> >Dec 24 14:40:34 ipa01.sub.example.com krb5kdc[3324](info): closing down
> fd
> >11
> >Dec 24 14:40:51 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ :
> >handle_authdata (2)
> >Dec 24 14:40:51 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ (6
> etypes
> >{aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
> >aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
> >camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) <
> ><http://192.168.0.202/>IP>: HANDLE_AUTHDATA: user <
> robe...@sub.example.com>
> >@SUB.EXAMPLE.COM  for krbtgt/
> >sub.example@sub.example.com, No such file or directory
>
> ^^^ this means the user roberto has no SID assigned. Look into numerous
> discussions on this mailing list in 2023, there are plenty of suggested
> actions in those threads.
>
> >Dec 24 14:40:51 ipa01.sub.example.com krb5kdc[3324](info): closing down
> fd
> >11
> >Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ (4
> etypes
> >{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
> >aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19)}) <
> ><http://192.168.0.16/>IP>: NEEDED_PREAUTH: ldap/
> >ipa01.sub.example@sub.example.com for krbtgt/
> >sub.example@sub.example.com, Additional pre-authentication required
> >Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): closing down
> fd
> >11
> >Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ (4
> etypes
> >{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
> >aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19)}) <
> ><http://192.168.0.16/>IP>: ISSUE: authtime 1703425257, etypes
> >{rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18),
> >ses=aes256-cts-hmac-sha1-96(18)},
> >ldap/ipa01.sub.example@sub.example.com for
> >krbtgt/sub.example@sub.example.com
> >Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): closing down
> fd
> >11
> >Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): TGS_

[Freeipa-users] Re: krb5kdc: No such file or directory

[Roberto Cornacchia via FreeIPA-users]

Hi Alexander,

Thanks for the quick reply, I will look into that.

Roberto

On Tue, 2 Jan 2024 at 17:04, Alexander Bokovoy  wrote:

> On Аўт, 02 сту 2024, Roberto Cornacchia via FreeIPA-users wrote:
> >Hi there, clients are having trouble with kerberos authentication:
> >
> >$ kinit -V user
> >Using existing cache: xx:y
> >Using principal: u...@sub.example.com 
> >Password for u...@sub.example.com :
> >kinit: Generic error (see e-text) while getting initial credentials
> >
> >On the ipa server, /var/log/krb5kdc.log says:
> >
> >Dec 24 14:40:34 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ (6
> etypes
> >{aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
> >aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
> >camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) <
> ><http://192.168.0.202/>IP>: NEEDED_PREAUTH: u...@sub.example.com
> > for krbtgt/sub.example@sub.example.com,
> >Additional pre-authentication required
> >Dec 24 14:40:34 ipa01.sub.example.com krb5kdc[3324](info): closing down
> fd
> >11
> >Dec 24 14:40:51 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ :
> >handle_authdata (2)
> >Dec 24 14:40:51 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ (6
> etypes
> >{aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
> >aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
> >camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) <
> ><http://192.168.0.202/>IP>: HANDLE_AUTHDATA: user <
> robe...@sub.example.com>
> >@SUB.EXAMPLE.COM  for krbtgt/
> >sub.example@sub.example.com, No such file or directory
>
> ^^^ this means the user roberto has no SID assigned. Look into numerous
> discussions on this mailing list in 2023, there are plenty of suggested
> actions in those threads.
>
> >Dec 24 14:40:51 ipa01.sub.example.com krb5kdc[3324](info): closing down
> fd
> >11
> >Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ (4
> etypes
> >{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
> >aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19)}) <
> ><http://192.168.0.16/>IP>: NEEDED_PREAUTH: ldap/
> >ipa01.sub.example@sub.example.com for krbtgt/
> >sub.example@sub.example.com, Additional pre-authentication required
> >Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): closing down
> fd
> >11
> >Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ (4
> etypes
> >{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
> >aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19)}) <
> ><http://192.168.0.16/>IP>: ISSUE: authtime 1703425257, etypes
> >{rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18),
> >ses=aes256-cts-hmac-sha1-96(18)},
> >ldap/ipa01.sub.example@sub.example.com for
> >krbtgt/sub.example@sub.example.com
> >Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): closing down
> fd
> >11
> >Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): TGS_REQ (4
> >etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
> >aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17)}) <
> ><http://192.168.0.16/>IP>: ISSUE: authtime 1703425257, etypes
> >{rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18),
> >ses=aes256-cts-hmac-sha1-96(18)},
> >ldap/ipa01.sub.example@sub.example.com for
> >ldap/ipa02.sub.example@sub.example.com
> >Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): closing down
> fd
> >11
> >
> >There are 2 ipa servers, ipa01 (Rocky 9.3, ipa 4.10.2) and ipa02 (Rock
> 9.1,
> >ipa4.10.0), both with CA and DNS. ipa02 is CRL master.
> >On both, ipa-healthcheck doesn't find any issue.
> >
> >Also: kinit fails from within ipa01, succeeds from within ipa02.
> >
> >The issue seems to be in ipa01, and I have already tried to reinstall it
> >from scratch. One thing that is different is the version.
> >
> >Could you please help me figure out what's wrong?
> >
> >Best regards,
> >Roberto
>
>
>
>
> --
> / 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: 
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: krb5kdc: No such file or directory

[Roberto Cornacchia via FreeIPA-users]

Restarting krb5kdc doesn't help, and although it restarts, it complains
about /run/krb5kdc.pid.

[ipa01 ~]# systemctl restart krb5kdc
[ipa01 ~]# systemctl status krb5kdc
● krb5kdc.service - Kerberos 5 KDC
 Loaded: loaded (/usr/lib/systemd/system/krb5kdc.service; disabled;
preset: disabled)
 Active: active (running) since Tue 2024-01-02 16:45:10 CET; 8s ago
Process: 43349 ExecStart=/usr/sbin/krb5kdc -P /run/krb5kdc.pid
$KRB5KDC_ARGS (code=exited, status=0/SUCCESS)
   Main PID: 43351 (krb5kdc)
  Tasks: 3 (limit: 48859)
 Memory: 6.6M
CPU: 70ms
 CGroup: /system.slice/krb5kdc.service
 ├─43351 /usr/sbin/krb5kdc -P /run/krb5kdc.pid -w 2
 ├─43352 /usr/sbin/krb5kdc -P /run/krb5kdc.pid -w 2
 └─43353 /usr/sbin/krb5kdc -P /run/krb5kdc.pid -w 2

Jan 02 16:45:09 ipa01.hq.spinque.com systemd[1]: Starting Kerberos 5 KDC...
Jan 02 16:45:10 ipa01.hq.spinque.com systemd[1]: krb5kdc.service: Can't
open PID file /run/krb5kdc.pid (yet?) after start: Operation not permitted
Jan 02 16:45:10 ipa01.hq.spinque.com systemd[1]: Started Kerberos 5 KDC.

[ipa01 ~]# ll /run/krb5kdc.pid
-rw-r--r--. 1 root root 6 Jan  2 16:45 /run/krb5kdc.pid

[ipa01 ~]# kinit roberto
Password for robe...@hq.spinque.com:
kinit: Generic error (see e-text) while getting initial credentials


On Tue, 2 Jan 2024 at 16:19, Roberto Cornacchia <
roberto.cornacc...@gmail.com> wrote:

> Hi there, clients are having trouble with kerberos authentication:
>
> $ kinit -V user
> Using existing cache: xx:y
> Using principal: u...@sub.example.com 
> Password for u...@sub.example.com :
> kinit: Generic error (see e-text) while getting initial credentials
>
> On the ipa server, /var/log/krb5kdc.log says:
>
> Dec 24 14:40:34 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ (6
> etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
> aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
> camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) <
> IP>: NEEDED_PREAUTH: u...@sub.example.com
>  for krbtgt/sub.example@sub.example.com,
> Additional pre-authentication required
> Dec 24 14:40:34 ipa01.sub.example.com krb5kdc[3324](info): closing down
> fd 11
> Dec 24 14:40:51 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ :
> handle_authdata (2)
> Dec 24 14:40:51 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ (6
> etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
> aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
> camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) <
> IP>: HANDLE_AUTHDATA: user
> @SUB.EXAMPLE.COM  for
> krbtgt/sub.example@sub.example.com, No such file or directory
> Dec 24 14:40:51 ipa01.sub.example.com krb5kdc[3324](info): closing down
> fd 11
> Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ (4
> etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
> aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19)}) <
> IP>: NEEDED_PREAUTH: ldap/
> ipa01.sub.example@sub.example.com for krbtgt/
> sub.example@sub.example.com, Additional pre-authentication required
> Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): closing down
> fd 11
> Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ (4
> etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
> aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19)}) <
> IP>: ISSUE: authtime 1703425257, etypes
> {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18),
> ses=aes256-cts-hmac-sha1-96(18)}, ldap/
> ipa01.sub.example@sub.example.com for krbtgt/
> sub.example@sub.example.com
> Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): closing down
> fd 11
> Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): TGS_REQ (4
> etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
> aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17)}) <
> IP>: ISSUE: authtime 1703425257, etypes
> {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18),
> ses=aes256-cts-hmac-sha1-96(18)}, ldap/
> ipa01.sub.example@sub.example.com for ldap/
> ipa02.sub.example@sub.example.com
> Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): closing down
> fd 11
>
> There are 2 ipa servers, ipa01 (Rocky 9.3, ipa 4.10.2) and ipa02 (Rock
> 9.1, ipa4.10.0), both with CA and DNS. ipa02 is CRL master.
> On both, ipa-healthcheck doesn't find any issue.
>
> Also: kinit fails from within ipa01, succeeds from within ipa02.
>
> The issue seems to be in ipa01, and I have already tried to reinstall it
> from scratch. One thing that is different is the version.
>
> Could you please help me figure out what's wrong?
>
> Best regards,
> Roberto
>
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To 

[Freeipa-users] krb5kdc: No such file or directory

[Roberto Cornacchia via FreeIPA-users]

Hi there, clients are having trouble with kerberos authentication:

$ kinit -V user
Using existing cache: xx:y
Using principal: u...@sub.example.com 
Password for u...@sub.example.com :
kinit: Generic error (see e-text) while getting initial credentials

On the ipa server, /var/log/krb5kdc.log says:

Dec 24 14:40:34 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ (6 etypes
{aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) <
IP>: NEEDED_PREAUTH: u...@sub.example.com
 for krbtgt/sub.example@sub.example.com,
Additional pre-authentication required
Dec 24 14:40:34 ipa01.sub.example.com krb5kdc[3324](info): closing down fd
11
Dec 24 14:40:51 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ :
handle_authdata (2)
Dec 24 14:40:51 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ (6 etypes
{aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) <
IP>: HANDLE_AUTHDATA: user 
@SUB.EXAMPLE.COM  for krbtgt/
sub.example@sub.example.com, No such file or directory
Dec 24 14:40:51 ipa01.sub.example.com krb5kdc[3324](info): closing down fd
11
Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ (4 etypes
{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19)}) <
IP>: NEEDED_PREAUTH: ldap/
ipa01.sub.example@sub.example.com for krbtgt/
sub.example@sub.example.com, Additional pre-authentication required
Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): closing down fd
11
Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ (4 etypes
{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19)}) <
IP>: ISSUE: authtime 1703425257, etypes
{rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18),
ses=aes256-cts-hmac-sha1-96(18)},
ldap/ipa01.sub.example@sub.example.com for
krbtgt/sub.example@sub.example.com
Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): closing down fd
11
Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): TGS_REQ (4
etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17)}) <
IP>: ISSUE: authtime 1703425257, etypes
{rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18),
ses=aes256-cts-hmac-sha1-96(18)},
ldap/ipa01.sub.example@sub.example.com for
ldap/ipa02.sub.example@sub.example.com
Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): closing down fd
11

There are 2 ipa servers, ipa01 (Rocky 9.3, ipa 4.10.2) and ipa02 (Rock 9.1,
ipa4.10.0), both with CA and DNS. ipa02 is CRL master.
On both, ipa-healthcheck doesn't find any issue.

Also: kinit fails from within ipa01, succeeds from within ipa02.

The issue seems to be in ipa01, and I have already tried to reinstall it
from scratch. One thing that is different is the version.

Could you please help me figure out what's wrong?

Best regards,
Roberto
--
___
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: dirsrv times out at startup

[Roberto Cornacchia via FreeIPA-users]

>
> It isn't a common issue.
>
>
You are right. I thought it referred to the Python Anaconda package. This
file was generated by anaconda the installer, apparently we had a --noipv6
in the kickstart.
(bad practice by anaconda anyway, to use non-numbered configuration files)

Roberto
___
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: dirsrv times out at startup

[Roberto Cornacchia via FreeIPA-users]

Oh. I hadn't forgotten. This is what happened.

These are my settings:

[root@ipa02 etc]# cat sysctl.conf | grep -v '#'
net.ipv6.conf.all.disable_ipv6=0
net.ipv6.conf.default.disable_ipv6=0

These will overwrite my settings:

[root@ipa02 etc]# cat sysctl.d/anaconda.conf
# Anaconda disabling ipv6 (noipv6 option)
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1

Two questions:
- Does FreeIPA (or, some components therein) really require ipv6? During
installation, it forced me to enable it.
- If so, these anaconda settings look like a trivial way to break the
system. I didn't install anaconda, but it was probably part of some
dependencies. Can something be done to make this more robust?

Best, Roberto

On Thu, 17 Nov 2022 at 19:06, Roberto Cornacchia <
roberto.cornacc...@gmail.com> wrote:

> I found it!
>
> dirsrv listens on ipv6 only.
> I had set net.ipv6.conf.all.disable_ipv6
> and net.ipv6.conf.all.disable_ipv6 to 0, but apparently forgot to make the
> change permanent, so after the reboot ipv6 was disabled.
>
>
>
> On Thu, 17 Nov 2022 at 18:50, Roberto Cornacchia <
> roberto.cornacc...@gmail.com> wrote:
>
>> This, however, works:
>>
>> # ldapsearch -H ldap://localhost:389 -x uid=roberto
>> # extended LDIF
>> #
>> # LDAPv3
>> # base  (default) with scope subtree
>> # filter: uid=roberto
>> # requesting: ALL
>> #
>>
>> # roberto, users, compat, hq.spinque.com
>> dn: uid=roberto,cn=users,cn=compat,dc=hq,dc=spinque,dc=com
>> [.. omitted ..]
>>
>>
>> On Thu, 17 Nov 2022 at 18:44, Roberto Cornacchia <
>> roberto.cornacc...@gmail.com> wrote:
>>
>>>
 You still have a replication agreement, and until its removed you will
 keep seeing these messages.  However it's not related to this issue though.

>>>
>>> Good to know. I hope there is a way to force removal of that agreement.
>>>
 - sometimes, but not always, this log also shows:
 ERR - bdb_version_write - Could not open file
 "/dev/shm/slapd-HQ-SPINQUE-COM/DBVERSION" for writing Netscape Portable
 Runtime -5950 (File not found.)

 This might happen after a system reboot.  It should be safe to ignore
 as long as the server still starts :)

>>> Again, good to know, thanks
>>>
 So looking at the error log it looks like the server is started.
 Schema compat plugin is doing its initialization which is very resource
 intensive, but the server should still be working.

 Try doing a ldapsearch just to see if it's responding:

 ldapsearch -H ldap://localhost:389 -b "" -s base -D "cn=directory
 manager" -W

>>> Ouch, I don't have the directory manager password with me at the moment,
>>> I'll have to wait till tomorrow when I go to the office.
>>> The server is up and listening:
>>>
>>> # netstat -tulnp | grep 389
>>> tcp6   0  0 :::389  :::*
>>>  LISTEN  3575/ns-slapd
>>>
>>> However, it's not just a slow start.
>>> I can start all the other services via systemctl, so things seem ok, but
>>> when much later I do ipactl stop I get:
>>>
>>> # ipactl stop
>>> Failed to read data from Directory Service: Timeout exceeded
>>> Shutting down
>>>
>>> So, it's really not cooperating.
>>>
>>>
>>>
___
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: dirsrv times out at startup

[Roberto Cornacchia via FreeIPA-users]

I found it!

dirsrv listens on ipv6 only.
I had set net.ipv6.conf.all.disable_ipv6 and net.ipv6.conf.all.disable_ipv6
to 0, but apparently forgot to make the change permanent, so after the
reboot ipv6 was disabled.



On Thu, 17 Nov 2022 at 18:50, Roberto Cornacchia <
roberto.cornacc...@gmail.com> wrote:

> This, however, works:
>
> # ldapsearch -H ldap://localhost:389 -x uid=roberto
> # extended LDIF
> #
> # LDAPv3
> # base  (default) with scope subtree
> # filter: uid=roberto
> # requesting: ALL
> #
>
> # roberto, users, compat, hq.spinque.com
> dn: uid=roberto,cn=users,cn=compat,dc=hq,dc=spinque,dc=com
> [.. omitted ..]
>
>
> On Thu, 17 Nov 2022 at 18:44, Roberto Cornacchia <
> roberto.cornacc...@gmail.com> wrote:
>
>>
>>> You still have a replication agreement, and until its removed you will
>>> keep seeing these messages.  However it's not related to this issue though.
>>>
>>
>> Good to know. I hope there is a way to force removal of that agreement.
>>
>>> - sometimes, but not always, this log also shows:
>>> ERR - bdb_version_write - Could not open file
>>> "/dev/shm/slapd-HQ-SPINQUE-COM/DBVERSION" for writing Netscape Portable
>>> Runtime -5950 (File not found.)
>>>
>>> This might happen after a system reboot.  It should be safe to ignore as
>>> long as the server still starts :)
>>>
>> Again, good to know, thanks
>>
>>> So looking at the error log it looks like the server is started.  Schema
>>> compat plugin is doing its initialization which is very resource intensive,
>>> but the server should still be working.
>>>
>>> Try doing a ldapsearch just to see if it's responding:
>>>
>>> ldapsearch -H ldap://localhost:389 -b "" -s base -D "cn=directory
>>> manager" -W
>>>
>> Ouch, I don't have the directory manager password with me at the moment,
>> I'll have to wait till tomorrow when I go to the office.
>> The server is up and listening:
>>
>> # netstat -tulnp | grep 389
>> tcp6   0  0 :::389  :::*
>>  LISTEN  3575/ns-slapd
>>
>> However, it's not just a slow start.
>> I can start all the other services via systemctl, so things seem ok, but
>> when much later I do ipactl stop I get:
>>
>> # ipactl stop
>> Failed to read data from Directory Service: Timeout exceeded
>> Shutting down
>>
>> So, it's really not cooperating.
>>
>>
>>
___
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: dirsrv times out at startup

[Roberto Cornacchia via FreeIPA-users]

This, however, works:

# ldapsearch -H ldap://localhost:389 -x uid=roberto
# extended LDIF
#
# LDAPv3
# base  (default) with scope subtree
# filter: uid=roberto
# requesting: ALL
#

# roberto, users, compat, hq.spinque.com
dn: uid=roberto,cn=users,cn=compat,dc=hq,dc=spinque,dc=com
[.. omitted ..]


On Thu, 17 Nov 2022 at 18:44, Roberto Cornacchia <
roberto.cornacc...@gmail.com> wrote:

>
>> You still have a replication agreement, and until its removed you will
>> keep seeing these messages.  However it's not related to this issue though.
>>
>
> Good to know. I hope there is a way to force removal of that agreement.
>
>> - sometimes, but not always, this log also shows:
>> ERR - bdb_version_write - Could not open file
>> "/dev/shm/slapd-HQ-SPINQUE-COM/DBVERSION" for writing Netscape Portable
>> Runtime -5950 (File not found.)
>>
>> This might happen after a system reboot.  It should be safe to ignore as
>> long as the server still starts :)
>>
> Again, good to know, thanks
>
>> So looking at the error log it looks like the server is started.  Schema
>> compat plugin is doing its initialization which is very resource intensive,
>> but the server should still be working.
>>
>> Try doing a ldapsearch just to see if it's responding:
>>
>> ldapsearch -H ldap://localhost:389 -b "" -s base -D "cn=directory
>> manager" -W
>>
> Ouch, I don't have the directory manager password with me at the moment,
> I'll have to wait till tomorrow when I go to the office.
> The server is up and listening:
>
> # netstat -tulnp | grep 389
> tcp6   0  0 :::389  :::*LISTEN
>  3575/ns-slapd
>
> However, it's not just a slow start.
> I can start all the other services via systemctl, so things seem ok, but
> when much later I do ipactl stop I get:
>
> # ipactl stop
> Failed to read data from Directory Service: Timeout exceeded
> Shutting down
>
> So, it's really not cooperating.
>
>
>
___
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: dirsrv times out at startup

[Roberto Cornacchia via FreeIPA-users]

>
>
> You still have a replication agreement, and until its removed you will
> keep seeing these messages.  However it's not related to this issue though.
>

Good to know. I hope there is a way to force removal of that agreement.

> - sometimes, but not always, this log also shows:
> ERR - bdb_version_write - Could not open file
> "/dev/shm/slapd-HQ-SPINQUE-COM/DBVERSION" for writing Netscape Portable
> Runtime -5950 (File not found.)
>
> This might happen after a system reboot.  It should be safe to ignore as
> long as the server still starts :)
>
Again, good to know, thanks

> So looking at the error log it looks like the server is started.  Schema
> compat plugin is doing its initialization which is very resource intensive,
> but the server should still be working.
>
> Try doing a ldapsearch just to see if it's responding:
>
> ldapsearch -H ldap://localhost:389 -b "" -s base -D "cn=directory
> manager" -W
>
Ouch, I don't have the directory manager password with me at the moment,
I'll have to wait till tomorrow when I go to the office.
The server is up and listening:

# netstat -tulnp | grep 389
tcp6   0  0 :::389  :::*LISTEN
 3575/ns-slapd

However, it's not just a slow start.
I can start all the other services via systemctl, so things seem ok, but
when much later I do ipactl stop I get:

# ipactl stop
Failed to read data from Directory Service: Timeout exceeded
Shutting down

So, it's really not cooperating.
___
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] dirsrv times out at startup

[Roberto Cornacchia via FreeIPA-users]

Yesterday I installed a replica on a clean Rocky 9 system. No issues at
all. Everything
seemed to work fine.

Today the machine was rebooted (no dnf updates, no system changes) and ipa
could not start anymore.

ipactl start -d says:

Starting Directory Service
ipa: DEBUG: Starting external process
ipa: DEBUG: args=['/bin/systemctl', 'start', 'dirsrv@HQ-SPINQUE-COM.service
']
ipa: DEBUG: Process finished, return code=0
ipa: DEBUG: Starting external process
ipa: DEBUG: args=['/bin/systemctl', 'is-active',
'dirsrv@HQ-SPINQUE-COM.service']
ipa: DEBUG: Process finished, return code=0
ipa: DEBUG: stdout=active

ipa: DEBUG: stderr=
ipa: DEBUG: wait_for_open_ports: localhost [389] timeout 120
ipa: DEBUG: waiting for port: 389
ipa: DEBUG: Failed to connect to port 389 tcp on ::1
ipa: DEBUG:   File
"/usr/lib/python3.9/site-packages/ipaserver/install/installutils.py", line
781, in run_script
return_value = main_function()

  File "/usr/lib/python3.9/site-packages/ipaserver/install/ipactl.py", line
739, in main
ipa_restart(options)

  File "/usr/lib/python3.9/site-packages/ipaserver/install/ipactl.py", line
499, in ipa_restart
raise IpactlError("Failed to start Directory Service: " + str(e))

ipa: DEBUG: The ipactl command failed, exception: IpactlError: Failed to
start Directory Service: Timeout exceeded
Failed to start Directory Service: Timeout exceeded

/var/log/dirsrv/slapd-HQ-SPINQUE-COM/errors says:

[17/Nov/2022:17:22:21.074990853 +0100] - INFO - slapd_extract_cert - CA
CERT NAME: HQ.SPINQUE.COM IPA CA
[17/Nov/2022:17:22:21.668775045 +0100] - WARN - Security Initialization -
SSL alert: Sending pin request to SVRCore. You may need to run
systemd-tty-ask-password-agent to provide the password if pin.txt does not
exist.
[17/Nov/2022:17:22:22.295325169 +0100] - INFO - slapd_extract_cert - SERVER
CERT NAME: Server-Cert
[17/Nov/2022:17:22:23.275812957 +0100] - INFO - Security Initialization -
SSL info: Enabling default cipher set.
[17/Nov/2022:17:22:26.090728693 +0100] - INFO - Security Initialization -
SSL info: Configured NSS Ciphers
[17/Nov/2022:17:22:26.771211814 +0100] - INFO - Security Initialization -
SSL info: TLS_AES_128_GCM_SHA256: enabled
[17/Nov/2022:17:22:28.438124063 +0100] - INFO - Security Initialization -
SSL info: TLS_CHACHA20_POLY1305_SHA256: enabled
[17/Nov/2022:17:22:28.928766931 +0100] - INFO - Security Initialization -
SSL info: TLS_AES_256_GCM_SHA384: enabled
[17/Nov/2022:17:22:29.544178747 +0100] - INFO - Security Initialization -
SSL info: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled
[17/Nov/2022:17:22:30.099717701 +0100] - INFO - Security Initialization -
SSL info: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled
[17/Nov/2022:17:22:30.657974763 +0100] - INFO - Security Initialization -
SSL info: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256: enabled
[17/Nov/2022:17:22:31.245996850 +0100] - INFO - Security Initialization -
SSL info: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256: enabled
[17/Nov/2022:17:22:31.790186166 +0100] - INFO - Security Initialization -
SSL info: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled
[17/Nov/2022:17:22:32.205374722 +0100] - INFO - Security Initialization -
SSL info: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled
[17/Nov/2022:17:22:32.771492861 +0100] - INFO - Security Initialization -
SSL info: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled
[17/Nov/2022:17:22:33.139528386 +0100] - INFO - Security Initialization -
SSL info: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled
[17/Nov/2022:17:22:33.392948327 +0100] - INFO - Security Initialization -
SSL info: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled
[17/Nov/2022:17:22:33.420924018 +0100] - INFO - Security Initialization -
SSL info: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled
[17/Nov/2022:17:22:33.468560401 +0100] - INFO - Security Initialization -
SSL info: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled
[17/Nov/2022:17:22:33.524578902 +0100] - INFO - Security Initialization -
SSL info: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled
[17/Nov/2022:17:22:33.769874334 +0100] - INFO - Security Initialization -
SSL info: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled
[17/Nov/2022:17:22:34.596047264 +0100] - INFO - Security Initialization -
SSL info: TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256: enabled
[17/Nov/2022:17:22:35.137255640 +0100] - INFO - Security Initialization -
SSL info: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled
[17/Nov/2022:17:22:35.938316117 +0100] - INFO - Security Initialization -
SSL info: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled
[17/Nov/2022:17:22:36.492933614 +0100] - INFO - Security Initialization -
SSL info: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled
[17/Nov/2022:17:22:37.059388478 +0100] - INFO - Security Initialization -
SSL info: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled
[17/Nov/2022:17:22:37.497954414 +0100] - INFO - Security Initialization -
SSL info: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled
[17/Nov/2022:17:22:37.899521527 +0100] - INFO - Security Initialization -
SSL info: 

[Freeipa-users] Re: ipa-replica-install: "Trust is configured"

[Roberto Cornacchia via FreeIPA-users]

OK, thanks!

On Thu, 17 Nov 2022, 08:45 Florence Blanc-Renaud,  wrote:

> Hi,
>
> On Wed, Nov 16, 2022 at 10:44 PM Roberto Cornacchia via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
>
>> I'm adding a replica, with CA and DNS setup, to an existing server (also
>> DNS and CA).
>>
>> First enrolled the server-to-be with ipa-client-install, then promoting
>> it to replica with ipa-replica-install.
>>
>> With or without CA and DNs, I get:
>>
>> ===
>> # ipa-replica-install
>> Lookup failed: Preferred host ipa02.hq.spinque.com does not provide DNS.
>> Trust is configured but no NetBIOS domain name found, setting it now.
>> Enter the NetBIOS name for the IPA domain.
>> Only up to 15 uppercase ASCII letters, digits and dashes are allowed.
>> Example: EXAMPLE.
>>
>>
>> NetBIOS domain name [HQ]:
>> ===
>>
>> The system is a clean Rocky 9 install, we never had a single Windows
>> machine, we never used AD-trust, on both ipa01 and ipa02 ipa trust-find
>> returns 0 matches.
>>
>> Where is it getting this from, and how can I avoid it?
>>
>
> Starting with FreeIPA 4.9.8, the installers also configure SID generation
> even if no trust is configured. For more information you can refer to the
> design page:
> https://freeipa.readthedocs.io/en/latest/designs/adtrust/sidconfig.html
>
> This means that a NetBIOS name is assigned to each server, and a domain
> SID assigned to IPA.
> I agree with you that the message "*Trust is configured but no NetBIOS
> domain name found, setting it now*" could be misleading and should be
> replaced with "*No NetBIOS domain name found, setting it now*".
> Nothing to worry on your side, you can simply accept the proposed value
> (or enter a value).
>
> Hope this clarifies,
> flo
>
>
>> VERSION: 4.9.8, API_VERSION: 2.246
>>
>> Thanks, Roberto
>> ___
>> 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 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: failing ipa-server-upgrade

[Roberto Cornacchia via FreeIPA-users]

(I think) final update:

I was getting too many issues on ipa02.

I did a ipa-replica-manage del ipa02 and now I'm going to reinstall it from
scratch.

Thanks for the help so far!
Best, Roberto


On Wed, 16 Nov 2022 at 14:15, Roberto Cornacchia <
roberto.cornacc...@gmail.com> wrote:

> UPDATE:
>
> ipa01 had non-matching secrets
> between /etc/httpd/conf.d/ipa-pki-proxy.conf
> and /etc/pki/pki-tomcat/server.xml (I don't know how that happened. The
> latest upgrade log was successful).
>
> I modified /etc/pki/pki-tomcat/server.xml to use the secret found in
> /etc/httpd/conf.d/ipa-pki-proxy.conf and now the "Unable to communicate
> with CMS (403)" issue on ipa01 is solved. Health-check only shows minor
> issues now.
>
> Now I'm back to ipa02 with
>
> # getcert list
> Number of certificates and requests being tracked: 0.
>
>
>
> On Wed, 16 Nov 2022 at 12:38, Roberto Cornacchia <
> roberto.cornacc...@gmail.com> wrote:
>
>> It turns out that also ipa01 (the CA renewal master) has issue: Unable to
>> communicate with CMS (403)
>>
>> I found this:
>> https://www.mail-archive.com/freeipa-users@lists.fedorahosted.org/msg12594.html
>>
>> which mentions both "secret" and "requiredSecret" should be
>> in /etc/pki/pki-tomcat/server.xml and match.
>>
>> on ipa01 (VERSION: 4.9.8, API_VERSION: 2.246), I see only "secret"
>> on ipa02 (VERSION: 4.9.8, API_VERSION: 2.245) I see only "requiredSecret"
>>
>> Can this be important?
>>
>> Besides this, I ran ipa-healthcheck on both, the result is in attachment
>>
>>
>>
>> On Wed, 16 Nov 2022 at 10:46, Roberto Cornacchia <
>> roberto.cornacc...@gmail.com> wrote:
>>
>>> I also found in the journal:
>>>
>>> Nov 16 07:40:11 ipa02.hq.spinque.com certmonger[10967]: 2022-11-16
>>> 07:40:11 [10967] Running enrollment/cadata helper
>>> "/usr/libexec/certmonger/dogtag-ipa-renew-agent-submit".
>>> Nov 16 07:40:11 ipa02.hq.spinque.com certmonger[10967]: Error opening
>>> "/etc/httpd/alias/pwdfile.txt": No such file or directory.
>>>
>>>
>>> On Wed, 16 Nov 2022 at 10:34, Roberto Cornacchia <
>>> roberto.cornacc...@gmail.com> wrote:
>>>
>>>> No luck with that, unfortunately:
>>>>
>>>> # getcert resubmit -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
>>>> cert-pki-ca' -v -w
>>>> No request found that matched arguments.
>>>>
>>>> # getcert list
>>>> Number of certificates and requests being tracked: 0.
>>>>
>>>>
>>>> On Wed, 16 Nov 2022 at 01:40, Rob Crittenden 
>>>> wrote:
>>>>
>>>>> Roberto Cornacchia via FreeIPA-users wrote:
>>>>> >
>>>>> > I'm not sure why it was not renewed, but now that it is in this
>>>>> > state, what would be the correct procedure to renew it?
>>>>> >
>>>>> >
>>>>> > The other IPA server is the CA renewal master and it does have a
>>>>> valid
>>>>> > certificate.
>>>>>
>>>>> The CA subsystem certificates are renewed on the renewal master server
>>>>> and put into LDAP. The CA clones will pick up the certificates from
>>>>> there. You can force it to try to fetch it with:
>>>>>
>>>>> # getcert resubmit -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
>>>>> cert-pki-ca' -v -w
>>>>>
>>>>> With -v and -w you'll be able to follow along with the progress.
>>>>>
>>>>> 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: failing ipa-server-upgrade

[Roberto Cornacchia via FreeIPA-users]

UPDATE:

ipa01 had non-matching secrets between /etc/httpd/conf.d/ipa-pki-proxy.conf
and /etc/pki/pki-tomcat/server.xml (I don't know how that happened. The
latest upgrade log was successful).

I modified /etc/pki/pki-tomcat/server.xml to use the secret found in
/etc/httpd/conf.d/ipa-pki-proxy.conf and now the "Unable to communicate
with CMS (403)" issue on ipa01 is solved. Health-check only shows minor
issues now.

Now I'm back to ipa02 with

# getcert list
Number of certificates and requests being tracked: 0.



On Wed, 16 Nov 2022 at 12:38, Roberto Cornacchia <
roberto.cornacc...@gmail.com> wrote:

> It turns out that also ipa01 (the CA renewal master) has issue: Unable to
> communicate with CMS (403)
>
> I found this:
> https://www.mail-archive.com/freeipa-users@lists.fedorahosted.org/msg12594.html
>
> which mentions both "secret" and "requiredSecret" should be
> in /etc/pki/pki-tomcat/server.xml and match.
>
> on ipa01 (VERSION: 4.9.8, API_VERSION: 2.246), I see only "secret"
> on ipa02 (VERSION: 4.9.8, API_VERSION: 2.245) I see only "requiredSecret"
>
> Can this be important?
>
> Besides this, I ran ipa-healthcheck on both, the result is in attachment
>
>
>
> On Wed, 16 Nov 2022 at 10:46, Roberto Cornacchia <
> roberto.cornacc...@gmail.com> wrote:
>
>> I also found in the journal:
>>
>> Nov 16 07:40:11 ipa02.hq.spinque.com certmonger[10967]: 2022-11-16
>> 07:40:11 [10967] Running enrollment/cadata helper
>> "/usr/libexec/certmonger/dogtag-ipa-renew-agent-submit".
>> Nov 16 07:40:11 ipa02.hq.spinque.com certmonger[10967]: Error opening
>> "/etc/httpd/alias/pwdfile.txt": No such file or directory.
>>
>>
>> On Wed, 16 Nov 2022 at 10:34, Roberto Cornacchia <
>> roberto.cornacc...@gmail.com> wrote:
>>
>>> No luck with that, unfortunately:
>>>
>>> # getcert resubmit -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
>>> cert-pki-ca' -v -w
>>> No request found that matched arguments.
>>>
>>> # getcert list
>>> Number of certificates and requests being tracked: 0.
>>>
>>>
>>> On Wed, 16 Nov 2022 at 01:40, Rob Crittenden 
>>> wrote:
>>>
>>>> Roberto Cornacchia via FreeIPA-users wrote:
>>>> >
>>>> > I'm not sure why it was not renewed, but now that it is in this
>>>> > state, what would be the correct procedure to renew it?
>>>> >
>>>> >
>>>> > The other IPA server is the CA renewal master and it does have a valid
>>>> > certificate.
>>>>
>>>> The CA subsystem certificates are renewed on the renewal master server
>>>> and put into LDAP. The CA clones will pick up the certificates from
>>>> there. You can force it to try to fetch it with:
>>>>
>>>> # getcert resubmit -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
>>>> cert-pki-ca' -v -w
>>>>
>>>> With -v and -w you'll be able to follow along with the progress.
>>>>
>>>> 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: failing ipa-server-upgrade

[Roberto Cornacchia via FreeIPA-users]

It turns out that also ipa01 (the CA renewal master) has issue: Unable to
communicate with CMS (403)

I found this:
https://www.mail-archive.com/freeipa-users@lists.fedorahosted.org/msg12594.html

which mentions both "secret" and "requiredSecret" should be
in /etc/pki/pki-tomcat/server.xml and match.

on ipa01 (VERSION: 4.9.8, API_VERSION: 2.246), I see only "secret"
on ipa02 (VERSION: 4.9.8, API_VERSION: 2.245) I see only "requiredSecret"

Can this be important?

Besides this, I ran ipa-healthcheck on both, the result is in attachment



On Wed, 16 Nov 2022 at 10:46, Roberto Cornacchia <
roberto.cornacc...@gmail.com> wrote:

> I also found in the journal:
>
> Nov 16 07:40:11 ipa02.hq.spinque.com certmonger[10967]: 2022-11-16
> 07:40:11 [10967] Running enrollment/cadata helper
> "/usr/libexec/certmonger/dogtag-ipa-renew-agent-submit".
> Nov 16 07:40:11 ipa02.hq.spinque.com certmonger[10967]: Error opening
> "/etc/httpd/alias/pwdfile.txt": No such file or directory.
>
>
> On Wed, 16 Nov 2022 at 10:34, Roberto Cornacchia <
> roberto.cornacc...@gmail.com> wrote:
>
>> No luck with that, unfortunately:
>>
>> # getcert resubmit -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
>> cert-pki-ca' -v -w
>> No request found that matched arguments.
>>
>> # getcert list
>> Number of certificates and requests being tracked: 0.
>>
>>
>> On Wed, 16 Nov 2022 at 01:40, Rob Crittenden  wrote:
>>
>>> Roberto Cornacchia via FreeIPA-users wrote:
>>> >
>>> > I'm not sure why it was not renewed, but now that it is in this
>>> > state, what would be the correct procedure to renew it?
>>> >
>>> >
>>> > The other IPA server is the CA renewal master and it does have a valid
>>> > certificate.
>>>
>>> The CA subsystem certificates are renewed on the renewal master server
>>> and put into LDAP. The CA clones will pick up the certificates from
>>> there. You can force it to try to fetch it with:
>>>
>>> # getcert resubmit -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
>>> cert-pki-ca' -v -w
>>>
>>> With -v and -w you'll be able to follow along with the progress.
>>>
>>> rob
>>>
>>>
Expired Cert: ocsp_signing
Expired Cert: subsystem
Expired Cert: audit_signing
Internal server error HTTPConnectionPool(host='ipa02.hq.spinque.com', 
port=8080): Max retries exceeded with url: /ca/rest/securityDomain/domainInfo 
(Caused by NewConnectionError(': Failed to establish a new connection: [Errno 111] Connection 
refused',))
Internal server error HTTPSConnectionPool(host='ipa02.hq.spinque.com', 
port=8443): Max retries exceeded with url: /ca/admin/ca/getStatus (Caused by 
NewConnectionError(': Failed to establish a new connection: [Errno 111] Connection 
refused',))
Unhandler rdtype 256
Unhandler rdtype 256
Unhandler rdtype 256
Unhandler rdtype 256
Unhandler rdtype 256
Unhandler rdtype 256
Unhandler rdtype 256
Unhandler rdtype 256
[
  {
"source": "ipahealthcheck.meta.services",
"check": "ipa_dnskeysyncd",
"result": "ERROR",
"uuid": "428f9e24-cc48-4db2-8600-f7561b191921",
"when": "20221116113421Z",
"duration": "0.010753",
"kw": {
  "status": false,
  "msg": "ipa-dnskeysyncd: not running"
}
  },
  {
"source": "ipahealthcheck.meta.services",
"check": "ipa_otpd",
"result": "ERROR",
"uuid": "5e31e2cf-1acf-4432-86ef-a47608f6c73b",
"when": "20221116113421Z",
"duration": "0.010732",
"kw": {
  "status": false,
  "msg": "ipa-otpd: not running"
}
  },
  {
"source": "ipahealthcheck.meta.services",
"check": "pki_tomcatd",
"result": "ERROR",
"uuid": "7b28f0b7-9f69-4840-af4a-daf8880ec668",
"when": "20221116113421Z",
"duration": "0.000768",
"kw": {
  "status": false,
  "msg": "pki_tomcatd: not running"
}
  },
  {
"source": "pki.server.healthcheck.certs.expiration",
"check": "CASystemCertExpiryCheck",
"result": "ERROR",
"uuid": "49d19a69-32b6-4ed0-9e89-ac71d94aa1ae",
"when": "20221116113421Z",
"duration": "0.160780",
"kw": {
 

[Freeipa-users] Re: failing ipa-server-upgrade

[Roberto Cornacchia via FreeIPA-users]

I also found in the journal:

Nov 16 07:40:11 ipa02.hq.spinque.com certmonger[10967]: 2022-11-16 07:40:11
[10967] Running enrollment/cadata helper
"/usr/libexec/certmonger/dogtag-ipa-renew-agent-submit".
Nov 16 07:40:11 ipa02.hq.spinque.com certmonger[10967]: Error opening
"/etc/httpd/alias/pwdfile.txt": No such file or directory.


On Wed, 16 Nov 2022 at 10:34, Roberto Cornacchia <
roberto.cornacc...@gmail.com> wrote:

> No luck with that, unfortunately:
>
> # getcert resubmit -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
> cert-pki-ca' -v -w
> No request found that matched arguments.
>
> # getcert list
> Number of certificates and requests being tracked: 0.
>
>
> On Wed, 16 Nov 2022 at 01:40, Rob Crittenden  wrote:
>
>> Roberto Cornacchia via FreeIPA-users wrote:
>> >
>> > I'm not sure why it was not renewed, but now that it is in this
>> > state, what would be the correct procedure to renew it?
>> >
>> >
>> > The other IPA server is the CA renewal master and it does have a valid
>> > certificate.
>>
>> The CA subsystem certificates are renewed on the renewal master server
>> and put into LDAP. The CA clones will pick up the certificates from
>> there. You can force it to try to fetch it with:
>>
>> # getcert resubmit -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
>> cert-pki-ca' -v -w
>>
>> With -v and -w you'll be able to follow along with the progress.
>>
>> 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: failing ipa-server-upgrade

[Roberto Cornacchia via FreeIPA-users]

No luck with that, unfortunately:

# getcert resubmit -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
cert-pki-ca' -v -w
No request found that matched arguments.

# getcert list
Number of certificates and requests being tracked: 0.


On Wed, 16 Nov 2022 at 01:40, Rob Crittenden  wrote:

> Roberto Cornacchia via FreeIPA-users wrote:
> >
> > I'm not sure why it was not renewed, but now that it is in this
> > state, what would be the correct procedure to renew it?
> >
> >
> > The other IPA server is the CA renewal master and it does have a valid
> > certificate.
>
> The CA subsystem certificates are renewed on the renewal master server
> and put into LDAP. The CA clones will pick up the certificates from
> there. You can force it to try to fetch it with:
>
> # getcert resubmit -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
> cert-pki-ca' -v -w
>
> With -v and -w you'll be able to follow along with the progress.
>
> 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: failing ipa-server-upgrade

[Roberto Cornacchia via FreeIPA-users]

>
>
> I'm not sure why it was not renewed, but now that it is in this state,
> what would be the correct procedure to renew it?
>

The other IPA server is the CA renewal master and it does have a valid
certificate.
___
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: failing ipa-server-upgrade

[Roberto Cornacchia via FreeIPA-users]

Dear Rob,

Thanks for your pointers.

I did a

grep -v INFO debug.*

And found out that although there have been many "Connection refused"
errors for a long time (which could be due to a different issue - the
system worked so far), only in the past few days the error has become
"Authentication failed (48)".

In the meantime I was also browsing
https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tomcatd-fails-to-start/
which helped me find that the certificate that tomcat uses to authenticate
to LDAP has expired on 11-11-2022:

[root@ipa02 /]# certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
cert-pki-ca'
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1610547202 (0x5fff0002)
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Issuer: "CN=Certificate Authority,O=HQ.SPINQUE.COM"
Validity:
Not Before: Sat Nov 21 12:56:43 2020
Not After : Fri Nov 11 12:56:43 2022

I'm not sure why it was not renewed, but now that it is in this state, what
would be the correct procedure to renew it?

Best, Roberto


On Tue, 15 Nov 2022 at 19:47, Rob Crittenden  wrote:

> Roberto Cornacchia via FreeIPA-users wrote:
> > Hi there,
> >
> > I appear to be stuck in a failing upgrade.
> >
> > On Rocky Linux 8.6. The server is one of 2 replicas, both CA and DNS
> > servers.
> >
> > It all started with pki-tomcat being down on a running server
> > (ipa02.hq.spinque.com <http://ipa02.hq.spinque.com>):
> >
> > ipactl status
> > Directory Service: RUNNING
> > krb5kdc Service: RUNNING
> > kadmin Service: RUNNING
> > named Service: RUNNING
> > httpd Service: RUNNING
> > ipa-custodia Service: RUNNING
> > pki-tomcatd Service: STOPPED
> > ipa-otpd Service: RUNNING
> > ipa-dnskeysyncd Service: RUNNING
> > 1 service(s) are not running
> >
> > and unable to go up again, with these errors:
> >
> > ipa-pki-wait-running: Request failed unexpectedly, 404 Client Error:
> >  for url: http://ipa02.hq.spinque.com:8080/ca/admin/ca/getStatus
> >
> > SEVERE: LdapBoundConnFactory: Unable to connect to LDAP server:
> > Authentication failed
> > netscape.ldap.LDAPException: Authentication failed (48)
> >
> > Having read something about a similar issue being caused by nss 3.67
> > (the one installed in the system), I ran a dnf update (4.9.8-8
> installed).
> >
> > This actually complicated things, because now it still fails, but also
> > it tries to upgrade every time it starts, failing the upgrade. As far as
> > I can see in the upgrade log, The actual upgrade succeeds, but starting
> > the services at the end fails, which makes the whole procedure fail.
> >
> > So running ipactl restart --ignore-service-failures does not help,
> > because the automatic upgrade fails and that stops all the services as a
> > last step.
> >
> > I'm not sure how I could continue, some pointer would be appreciated.
> >
> > Errors I see now:
> >
> > ERR - set_krb5_creds - Could not get initial credentials for principal
> > [ldap/ipa02.hq.spinque@hq.spinque.com
> > <mailto:ipa02.hq.spinque@hq.spinque.com>] in keytab
> > [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
> > requested realm)
> >
> > ldap_child[2130]: Failed to initialize credentials using keytab
> > [MEMORY:/etc/krb5.keytab]: Cannot contact any KDC for realm
> > 'HQ.SPINQUE.COM <http://HQ.SPINQUE.COM>'. Unable to create
> > GSSAPI-encrypted LDAP connection.
>
> Add --skip-version-check to not force an upgrade.
>
> You need to determine why the CA won't start. See the journal and/or
> /var/log/pki/pki-tomcat/ca/debug*.
>
> The trick with the CA debug log is to start looking where the last
> server start is and move downwards in the file. Starting at the tail
> usually isn't fruitful.
>
> 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: failing ipa-server-upgrade

[Roberto Cornacchia via FreeIPA-users]

Correction:

After ipa-server-upgrade fails, dirsrv service is up (the only one):

$ systemctl status dirsrv@HQ-SPINQUE-COM -l
● dirsrv@HQ-SPINQUE-COM.service - 389 Directory Server HQ-SPINQUE-COM.
   Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor
preset: disabled)
  Drop-In: /usr/lib/systemd/system/dirsrv@.service.d
   └─custom.conf
   /etc/systemd/system/dirsrv@HQ-SPINQUE-COM.service.d
   └─ipa-env.conf
   Active: active (running) since Tue 2022-11-15 16:45:01 CET; 1h 11min ago
 Main PID: 4590 (ns-slapd)
   Status: "slapd started: Ready to process requests"
Tasks: 35 (limit: 24866)
   Memory: 105.8M
   CGroup: /system.slice/system-dirsrv.slice/dirsrv@HQ-SPINQUE-COM.service
   └─4590 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-HQ-SPINQUE-COM -i
/run/dirsrv/slapd-HQ-SPINQUE-COM.pid

Nov 15 17:51:19 ipa02.hq.spinque.com ns-slapd[4590]:
[15/Nov/2022:17:51:19.375860350 +0100] - ERR - set_krb5_creds - Could not
get initial credentials for principal [ldap/
ipa02.hq.spinque@hq.spinque.com] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765>
Nov 15 17:51:23 ipa02.hq.spinque.com ns-slapd[4590]:
[15/Nov/2022:17:51:23.385663283 +0100] - ERR - set_krb5_creds - Could not
get initial credentials for principal [ldap/
ipa02.hq.spinque@hq.spinque.com] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765>
Nov 15 17:51:24 ipa02.hq.spinque.com ns-slapd[4590]: GSSAPI client step 1
Nov 15 17:51:24 ipa02.hq.spinque.com ns-slapd[4590]: GSSAPI client step 1
Nov 15 17:51:24 ipa02.hq.spinque.com ns-slapd[4590]: GSSAPI Error:
Unspecified GSS failure.  Minor code may provide more information (Cannot
contact any KDC for realm 'HQ.SPINQUE.COM')
Nov 15 17:51:27 ipa02.hq.spinque.com ns-slapd[4590]:
[15/Nov/2022:17:51:27.604045400 +0100] - ERR - set_krb5_creds - Could not
get initial credentials for principal [ldap/
ipa02.hq.spinque@hq.spinque.com] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765>
Nov 15 17:51:28 ipa02.hq.spinque.com ns-slapd[4590]:
[15/Nov/2022:17:51:28.642136900 +0100] - ERR - set_krb5_creds - Could not
get initial credentials for principal [ldap/
ipa02.hq.spinque@hq.spinque.com] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765>
Nov 15 17:51:29 ipa02.hq.spinque.com ns-slapd[4590]: GSSAPI client step 1
Nov 15 17:51:29 ipa02.hq.spinque.com ns-slapd[4590]: GSSAPI client step 1
Nov 15 17:51:29 ipa02.hq.spinque.com ns-slapd[4590]: GSSAPI Error:
Unspecified GSS failure.  Minor code may provide more information (Cannot
contact any KDC for realm 'HQ.SPINQUE.COM')

On Tue, 15 Nov 2022 at 17:42, Roberto Cornacchia <
roberto.cornacc...@gmail.com> wrote:

> Hi there,
>
> I appear to be stuck in a failing upgrade.
>
> On Rocky Linux 8.6. The server is one of 2 replicas, both CA and DNS
> servers.
>
> It all started with pki-tomcat being down on a running server (
> ipa02.hq.spinque.com):
>
> ipactl status
> Directory Service: RUNNING
> krb5kdc Service: RUNNING
> kadmin Service: RUNNING
> named Service: RUNNING
> httpd Service: RUNNING
> ipa-custodia Service: RUNNING
> pki-tomcatd Service: STOPPED
> ipa-otpd Service: RUNNING
> ipa-dnskeysyncd Service: RUNNING
> 1 service(s) are not running
>
> and unable to go up again, with these errors:
>
> ipa-pki-wait-running: Request failed unexpectedly, 404 Client Error:  for
> url: http://ipa02.hq.spinque.com:8080/ca/admin/ca/getStatus
>
> SEVERE: LdapBoundConnFactory: Unable to connect to LDAP server:
> Authentication failed
> netscape.ldap.LDAPException: Authentication failed (48)
>
> Having read something about a similar issue being caused by nss 3.67 (the
> one installed in the system), I ran a dnf update (4.9.8-8 installed).
>
> This actually complicated things, because now it still fails, but also it
> tries to upgrade every time it starts, failing the upgrade. As far as I can
> see in the upgrade log, The actual upgrade succeeds, but starting the
> services at the end fails, which makes the whole procedure fail.
>
> So running ipactl restart --ignore-service-failures does not help, because
> the automatic upgrade fails and that stops all the services as a last step.
>
> I'm not sure how I could continue, some pointer would be appreciated.
>
> Errors I see now:
>
> ERR - set_krb5_creds - Could not get initial credentials for principal
> [ldap/ipa02.hq.spinque@hq.spinque.com] in keytab
> [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
> requested realm)
>
> ldap_child[2130]: Failed to initialize credentials using keytab
> [MEMORY:/etc/krb5.keytab]: Cannot contact any KDC for realm '
> HQ.SPINQUE.COM'. Unable to create GSSAPI-encrypted LDAP connection.
>
> Thanks for your help,
> Roberto
>
___
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: 

[Freeipa-users] failing ipa-server-upgrade

[Roberto Cornacchia via FreeIPA-users]

Hi there,

I appear to be stuck in a failing upgrade.

On Rocky Linux 8.6. The server is one of 2 replicas, both CA and DNS
servers.

It all started with pki-tomcat being down on a running server (
ipa02.hq.spinque.com):

ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
pki-tomcatd Service: STOPPED
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
1 service(s) are not running

and unable to go up again, with these errors:

ipa-pki-wait-running: Request failed unexpectedly, 404 Client Error:  for
url: http://ipa02.hq.spinque.com:8080/ca/admin/ca/getStatus

SEVERE: LdapBoundConnFactory: Unable to connect to LDAP server:
Authentication failed
netscape.ldap.LDAPException: Authentication failed (48)

Having read something about a similar issue being caused by nss 3.67 (the
one installed in the system), I ran a dnf update (4.9.8-8 installed).

This actually complicated things, because now it still fails, but also it
tries to upgrade every time it starts, failing the upgrade. As far as I can
see in the upgrade log, The actual upgrade succeeds, but starting the
services at the end fails, which makes the whole procedure fail.

So running ipactl restart --ignore-service-failures does not help, because
the automatic upgrade fails and that stops all the services as a last step.

I'm not sure how I could continue, some pointer would be appreciated.

Errors I see now:

ERR - set_krb5_creds - Could not get initial credentials for principal
[ldap/ipa02.hq.spinque@hq.spinque.com] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
requested realm)

ldap_child[2130]: Failed to initialize credentials using keytab
[MEMORY:/etc/krb5.keytab]: Cannot contact any KDC for realm 'HQ.SPINQUE.COM'.
Unable to create GSSAPI-encrypted LDAP connection.

Thanks for your help,
Roberto
___
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: Reinstalling client's OS

[Roberto Cornacchia via FreeIPA-users]

Thank you Angus and Detlev!


On Fri, 4 Dec 2020, 12:46 Angus Clarke via FreeIPA-users, <
freeipa-users@lists.fedorahosted.org> wrote:

> The steps you mention seem fine to me Roberto, Detlev has detailed an
> alternative.
>
> If you lose a client and need to rebuild (i.e. you didn't get chance to
> run the "--uninstall" option) then you can also just delete the host entry
> from IPA through the web gui or ipa command line before running the
> ipa-client-install (join) command.
>
> When I have issues with clients (very infrequent and I have some 5000
> clients) I find that running the "--uninstall" and then the install (steps
> 1 and 3) fix most issues without having to look into them (blind fix for
> the time wary!)
>
> Regards
> Angus
>
> --
> *From:* Detlev Habicht via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org>
> *Sent:* 04 December 2020 11:59
> *To:* FreeIPA users list 
> *Cc:* Detlev Habicht 
> *Subject:* [Freeipa-users] Re: Reinstalling client's OS
>
> Hi,
>
> you can reinstall a client with something like this:
>
> /usr/sbin/ipa-client-install --force --unattended —domain=xxx —realm=xxx
> —server=xxx —server=yyy --force-ntpd —keytab=./krb5.keytab
> --ca-cert-file=./ca.crt
>
> But you must save your keytab and ca file before.
>
> For me it is working …
>
> Detlev
>
> --
>   Detlev  | Institut fuer Mikroelektronische Systeme
>   Habicht | D-30167 Hannover +49 511 76219662 habi...@ims.uni-hannover.de
>   + Handy+49 172 5415752  ---
>
>
>
> > Am 04.12.2020 um 11:46 schrieb Roberto Cornacchia via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org>:
> >
> > Hello,
> >
> > Apologies if this is a trivial question, I could not find an obvious
> answer anywhere.
> >
> > If I want to reinstall from scratch the OS of an already enrolled
> client, is this the right procedure?
> >
> > 1. ipa-client-install --uninstall
> > 2. 
> > 3. ipa-client-install
> >
> > Best regards,
> > Roberto
> > ___
> > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=04%7C01%7C%7Ca51e09497c794cfb098908d89843bc39%7C84df9e7fe9f640afb435%7C1%7C0%7C637426763967360942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=fyz1F%2Bu9GU4%2BSe1iqHKETf1aXIetl7jt5RNrWaThsIs%3Dreserved=0
> > List Guidelines:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=04%7C01%7C%7Ca51e09497c794cfb098908d89843bc39%7C84df9e7fe9f640afb435%7C1%7C0%7C637426763967360942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=fdVD5aYltsHDH9OfcX3M7tRNSA5gQuIex%2BsUEXnEjpI%3Dreserved=0
> > List Archives:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.orgdata=04%7C01%7C%7Ca51e09497c794cfb098908d89843bc39%7C84df9e7fe9f640afb435%7C1%7C0%7C637426763967360942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=oIA%2BVUaGSmbN6BNGGeGFSApHNGWG6aolwCkd8CVNWHg%3Dreserved=0
> ___
> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=04%7C01%7C%7Ca51e09497c794cfb098908d89843bc39%7C84df9e7fe9f640afb435%7C1%7C0%7C637426763967360942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=fyz1F%2Bu9GU4%2BSe1iqHKETf1aXIetl7jt5RNrWaThsIs%3Dreserved=0
> List Guidelines:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelinesdata=04%7C01%7C%7Ca51e09497c794cfb098908d89843bc39%7C84df9e7fe9f640afb435%7C1%7C0%7C637426763967360942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=fdVD5aYltsHDH9OfcX3M7tRNSA5gQuIex%2BsUEXnEjpI%3Dreserved=0
> List Archives:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedoraho

[Freeipa-users] Reinstalling client's OS

[Roberto Cornacchia via FreeIPA-users]

Hello,

Apologies if this is a trivial question, I could not find an obvious answer
anywhere.

If I want to reinstall from scratch the OS of an already enrolled client,
is this the right procedure?

1. ipa-client-install --uninstall
2. 
3. ipa-client-install

Best regards,
Roberto
___
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

[Freeipa-users] Re: ipa-ca-install fails

[Roberto Cornacchia via FreeIPA-users]

var/log/pki/pki-tomcat/ca/debug
>>
>> [http-bio-8443-exec-3]: ConfigurationUtils: GET
>> https://ipa01.hq.spinque.com:443/ca/admin/ca/getCertChain
>> javax.ws.rs.ProcessingException: Unable to invoke request
>> at
>> org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:287)
>> ...
>> Caused by: java.io.IOException: SocketException cannot write on socket
>> at org.mozilla.jss.ssl.SSLSocket.write(SSLSocket.java:1503)
>>
>> ipa01:/var/log/httpd/error_log says:
>> [:error] [pid 18129] SSL Library Error: -12286 No common encryption
>> algorithm(s) with client
>>
>> I guess it makes sense, old ciphers have been disabled in the newer
>> release.
>>
>> Testing with openssl from ipa02 against ipa01, I found only these being
>> accepted:
>> AES128-SHA
>> DES-CBC3-SHA
>> RC4-SHA
>> RC4-MD5
>>
>> How can I temporarily make ipa-ca-install accept old ciphers?
>> Before running ipa-ca-install there is even no pki-tomcat configured on
>> ipa02, but running it fails.
>>
>> Any idea?
>>
>> On Fri, 24 Jul 2020 at 00:46, Rob Crittenden  wrote:
>>
>>> Roberto Cornacchia via FreeIPA-users wrote:
>>> > Hi Rob,
>>> >
>>> > Thanks for the tip.
>>> >
>>> > I don't see errors that I've found before, but quite some errors.
>>> >
>>> > In attachment is the result of
>>> > grep -v SUCCESS /var/log/httpd/error_log
>>> > for today.
>>>
>>> IPA stopped using memcached in I think version 4.5.0. I guess the key
>>> size in the session grew since then.
>>>
>>> I'm not sure what the best workaround is. On the 4.2 servers you could
>>> try to modify /usr/lib/python*/site-packages/ipaserver/session.py and
>>> find:
>>>
>>> self.mc = memcache.Client(self.servers, debug=0)
>>>
>>> Add check_keys=False to that initialization to not check sizing. That
>>> could have other unintended consequences that I'm not aware of.
>>>
>>> Restart httpd after making this change.
>>>
>>> > I've also tried to replicate the error that I got with
>>> > ipa-replica-install, during the server upgrade step.
>>> > I ran ipa-server-upgrade -v on ipa02, and got the same error
>>> > "ipaserver.install.ldapupdate: ERRORAdd failure attribute "cn" not
>>> > allowed".
>>>
>>> /var/log/ipaserver-upgrade.log should have more context.
>>>
>>> >
>>> > I also see something else that is strane in the output
>>> > of ipa-server-upgrade -v:
>>> >
>>> > Failed to check CA status: cannot connect to
>>> > 'http://ipa01.hq.spinque.com:8080/ca/admin/ca/getStatus': [Errno 113]
>>> No
>>> > route to host
>>> >
>>> > I wonder why 8080. Shouldn't this be on 80?
>>>
>>> Try opening port 8080. It tries to contact the CA directly and not
>>> through the Apache proxy.
>>>
>>> >
>>> > [root@ipa02 ~]# curl
>>> > 'http://ipa01.hq.spinque.com:8080/ca/admin/ca/getStatus'
>>> > curl: (7) Failed connect to ipa01.hq.spinque.com:8080
>>> > <http://ipa01.hq.spinque.com:8080>; No route to host
>>> >
>>> > [root@ipa02 ~]# curl '
>>> http://ipa01.hq.spinque.com/ca/admin/ca/getStatus'
>>> > >> >
>>> standalone="no"?>1CArunning10.2.6-20.fc23
>>> >
>>> > Roberto
>>> >
>>> > On Thu, 23 Jul 2020 at 19:08, Rob Crittenden >> > <mailto:rcrit...@redhat.com>> wrote:
>>> >
>>> > Roberto Cornacchia via FreeIPA-users wrote:
>>> > > ipa-replica-conncheck fails with --auto-master-check (used by
>>> > > ipa-ca-install), but not without:
>>> > >
>>> > >
>>> > > [root@ipa02 ~]# /usr/sbin/ipa-replica-conncheck --master
>>> > > ipa01.hq.spinque.com <http://ipa01.hq.spinque.com>
>>> > <http://ipa01.hq.spinque.com> --auto-master-check
>>> > > --realm HQ.SPINQUE.COM <http://HQ.SPINQUE.COM>
>>> > <http://HQ.SPINQUE.COM> --hostname
>>> > > ipa02.hq.spinque.com <http://ipa02.hq.spinque.com>
>>> > <http://ipa02.hq.spinque.com>
>>> > > Check connection from replica to remote master
>>> >  

[Freeipa-users] Re: ipa-ca-install fails

[Roberto Cornacchia via FreeIPA-users]

Thanks Rob.

Skipping the key checks got me past that error. So the connection test
passes!

Unfortunately now I have a cipher issue.

[root@ipa02 ~]# ipa-ca-install replica-info-ipa02.hq.spinque.com.gpg
Directory Manager (existing master) password:

Run connection check to master
Connection check OK
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
  [1/27]: configuring certificate server instance
ipaserver.install.dogtaginstance: CRITICAL Failed to configure CA instance:
Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpkUNbPC' returned non-zero exit
status 1
ipaserver.install.dogtaginstance: CRITICAL See the installation logs and
the following files/directories for more information:
ipaserver.install.dogtaginstance: CRITICAL   /var/log/pki/pki-tomcat

/var/log/pki/pki-tomcat/ca/debug

[http-bio-8443-exec-3]: ConfigurationUtils: GET
https://ipa01.hq.spinque.com:443/ca/admin/ca/getCertChain
javax.ws.rs.ProcessingException: Unable to invoke request
at
org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:287)
...
Caused by: java.io.IOException: SocketException cannot write on socket
at org.mozilla.jss.ssl.SSLSocket.write(SSLSocket.java:1503)

ipa01:/var/log/httpd/error_log says:
[:error] [pid 18129] SSL Library Error: -12286 No common encryption
algorithm(s) with client

I guess it makes sense, old ciphers have been disabled in the newer release.

Testing with openssl from ipa02 against ipa01, I found only these being
accepted:
AES128-SHA
DES-CBC3-SHA
RC4-SHA
RC4-MD5

How can I temporarily make ipa-ca-install accept old ciphers?
Before running ipa-ca-install there is even no pki-tomcat configured on
ipa02, but running it fails.

Any idea?

On Fri, 24 Jul 2020 at 00:46, Rob Crittenden  wrote:

> Roberto Cornacchia via FreeIPA-users wrote:
> > Hi Rob,
> >
> > Thanks for the tip.
> >
> > I don't see errors that I've found before, but quite some errors.
> >
> > In attachment is the result of
> > grep -v SUCCESS /var/log/httpd/error_log
> > for today.
>
> IPA stopped using memcached in I think version 4.5.0. I guess the key
> size in the session grew since then.
>
> I'm not sure what the best workaround is. On the 4.2 servers you could
> try to modify /usr/lib/python*/site-packages/ipaserver/session.py and find:
>
> self.mc = memcache.Client(self.servers, debug=0)
>
> Add check_keys=False to that initialization to not check sizing. That
> could have other unintended consequences that I'm not aware of.
>
> Restart httpd after making this change.
>
> > I've also tried to replicate the error that I got with
> > ipa-replica-install, during the server upgrade step.
> > I ran ipa-server-upgrade -v on ipa02, and got the same error
> > "ipaserver.install.ldapupdate: ERRORAdd failure attribute "cn" not
> > allowed".
>
> /var/log/ipaserver-upgrade.log should have more context.
>
> >
> > I also see something else that is strane in the output
> > of ipa-server-upgrade -v:
> >
> > Failed to check CA status: cannot connect to
> > 'http://ipa01.hq.spinque.com:8080/ca/admin/ca/getStatus': [Errno 113] No
> > route to host
> >
> > I wonder why 8080. Shouldn't this be on 80?
>
> Try opening port 8080. It tries to contact the CA directly and not
> through the Apache proxy.
>
> >
> > [root@ipa02 ~]# curl
> > 'http://ipa01.hq.spinque.com:8080/ca/admin/ca/getStatus'
> > curl: (7) Failed connect to ipa01.hq.spinque.com:8080
> > <http://ipa01.hq.spinque.com:8080>; No route to host
> >
> > [root@ipa02 ~]# curl 'http://ipa01.hq.spinque.com/ca/admin/ca/getStatus'
> >  >
> standalone="no"?>1CArunning10.2.6-20.fc23
> >
> > Roberto
> >
> > On Thu, 23 Jul 2020 at 19:08, Rob Crittenden  > <mailto:rcrit...@redhat.com>> wrote:
> >
> > Roberto Cornacchia via FreeIPA-users wrote:
> > > ipa-replica-conncheck fails with --auto-master-check (used by
> > > ipa-ca-install), but not without:
> > >
> > >
> > > [root@ipa02 ~]# /usr/sbin/ipa-replica-conncheck --master
> > > ipa01.hq.spinque.com <http://ipa01.hq.spinque.com>
> > <http://ipa01.hq.spinque.com> --auto-master-check
> > > --realm HQ.SPINQUE.COM <http://HQ.SPINQUE.COM>
> > <http://HQ.SPINQUE.COM> --hostname
> > > ipa02.hq.spinque.com <http://ipa02.hq.spinque.com>
> > <http://ipa02.hq.spinque.com>
> > > Check connection from replica to remote master
> > 'ipa01.hq.spinque.com <http://ipa01.hq.spinque.com>
> > > <http://ipa01.hq.spinque.co

[Freeipa-users] Re: ipa-ca-install fails

[Roberto Cornacchia via FreeIPA-users]

Hi Rob,

Thanks for the tip.

I don't see errors that I've found before, but quite some errors.

In attachment is the result of
grep -v SUCCESS /var/log/httpd/error_log
for today.


I've also tried to replicate the error that I got with ipa-replica-install,
during the server upgrade step.
I ran ipa-server-upgrade -v on ipa02, and got the same error
"ipaserver.install.ldapupdate: ERRORAdd failure attribute "cn" not
allowed".

I also see something else that is strane in the output
of ipa-server-upgrade -v:

Failed to check CA status: cannot connect to '
http://ipa01.hq.spinque.com:8080/ca/admin/ca/getStatus': [Errno 113] No
route to host

I wonder why 8080. Shouldn't this be on 80?

[root@ipa02 ~]# curl 'http://ipa01.hq.spinque.com:8080/ca/admin/ca/getStatus
'
curl: (7) Failed connect to ipa01.hq.spinque.com:8080; No route to host

[root@ipa02 ~]# curl 'http://ipa01.hq.spinque.com/ca/admin/ca/getStatus'
1CArunning10.2.6-20.fc23

Roberto

On Thu, 23 Jul 2020 at 19:08, Rob Crittenden  wrote:

> Roberto Cornacchia via FreeIPA-users wrote:
> > ipa-replica-conncheck fails with --auto-master-check (used by
> > ipa-ca-install), but not without:
> >
> >
> > [root@ipa02 ~]# /usr/sbin/ipa-replica-conncheck --master
> > ipa01.hq.spinque.com <http://ipa01.hq.spinque.com> --auto-master-check
> > --realm HQ.SPINQUE.COM <http://HQ.SPINQUE.COM> --hostname
> > ipa02.hq.spinque.com <http://ipa02.hq.spinque.com>
> > Check connection from replica to remote master 'ipa01.hq.spinque.com
> > <http://ipa01.hq.spinque.com>':
> >Directory Service: Unsecure port (389): OK
> >Directory Service: Secure port (636): OK
> >Kerberos KDC: TCP (88): OK
> >Kerberos Kpasswd: TCP (464): OK
> >HTTP Server: Unsecure port (80): OK
> >HTTP Server: Secure port (443): OK
> >
> > The following list of ports use UDP protocoland would need to be
> > checked manually:
> >Kerberos KDC: UDP (88): SKIPPED
> >Kerberos Kpasswd: UDP (464): SKIPPED
> >
> > Connection from replica to master is OK.
> > Start listening on required ports for remote master check
> > 389 tcp: Failed to bind
> > 636 tcp: Failed to bind
> > 88 tcp: Failed to bind
> > 88 udp: Failed to bind
> > 464 tcp: Failed to bind
> > 464 udp: Failed to bind
> > 80 tcp: Failed to bind
> > 443 tcp: Failed to bind
> > Get credentials to log in to remote master
> > Check RPC connection to remote master
> > trying https://ipa01.hq.spinque.com/ipa/session/json
> > *Connection to https://ipa01.hq.spinque.com/ipa/session/json failed with
> >  > <http://ipa01.hq.spinque.com/ipa/session/json>: 500 Internal Server
> Error>*
> > trying https://ipa02.hq.spinque.com/ipa/session/json
> > [try 1]: Forwarding 'schema' to json server
> > 'https://ipa02.hq.spinque.com/ipa/session/json'
> > trying https://ipa01.hq.spinque.com/ipa/session/json
> > Connection to https://ipa01.hq.spinque.com/ipa/session/json failed with
> >  > <http://ipa01.hq.spinque.com/ipa/session/json>: 500 Internal Server
> Error>
> > trying https://ipa02.hq.spinque.com/ipa/session/json
> > [try 1]: Forwarding 'ping/1' to json server
> > 'https://ipa02.hq.spinque.com/ipa/session/json'
> > Execute check on remote master
> > [try 1]: Forwarding 'server_conncheck' to json server
> > 'https://ipa02.hq.spinque.com/ipa/session/json'
> > *ERROR: Remote master check failed with following error message(s):
> > invalid 'cn': must be "ipa02.hq.spinque.com <http://ipa02.hq.spinque.com
> >"*
> >
> >
> > Now, without --auto-master-check:
> >
> > On ipa02 (I suppose the many "Failed to bind" below are expected?):
> > [root@ipa02 ~]# /usr/sbin/ipa-replica-conncheck --master
> > ipa01.hq.spinque.com <http://ipa01.hq.spinque.com>  --realm
> > HQ.SPINQUE.COM <http://HQ.SPINQUE.COM> --hostname ipa02.hq.spinque.com
> > <http://ipa02.hq.spinque.com>
> > Check connection from replica to remote master 'ipa01.hq.spinque.com
> > <http://ipa01.hq.spinque.com>':
> >Directory Service: Unsecure port (389): OK
> >Directory Service: Secure port (636): OK
> >Kerberos KDC: TCP (88): OK
> >Kerberos Kpasswd: TCP (464): OK
> >HTTP Server: Unsecure port (80): OK
> >HTTP Server: Secure port (443): OK
> >
> > The following list of ports use UDP protocoland would need to be
> > checked manually:
> >Kerberos KDC: UDP (88): SKIPPED
> >Kerberos Kpasswd: UDP (464): SKIPPED
> >
> > Connection from replica to master is OK.
> > Start listening on r

[Freeipa-users] Re: ipa-ca-install fails

[Roberto Cornacchia via FreeIPA-users]

ipa-replica-conncheck fails with --auto-master-check (used by
ipa-ca-install), but not without:


[root@ipa02 ~]# /usr/sbin/ipa-replica-conncheck --master
ipa01.hq.spinque.com --auto-master-check --realm HQ.SPINQUE.COM --hostname
ipa02.hq.spinque.com
Check connection from replica to remote master 'ipa01.hq.spinque.com':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

The following list of ports use UDP protocoland would need to be
checked manually:
   Kerberos KDC: UDP (88): SKIPPED
   Kerberos Kpasswd: UDP (464): SKIPPED

Connection from replica to master is OK.
Start listening on required ports for remote master check
389 tcp: Failed to bind
636 tcp: Failed to bind
88 tcp: Failed to bind
88 udp: Failed to bind
464 tcp: Failed to bind
464 udp: Failed to bind
80 tcp: Failed to bind
443 tcp: Failed to bind
Get credentials to log in to remote master
Check RPC connection to remote master
trying https://ipa01.hq.spinque.com/ipa/session/json
*Connection to https://ipa01.hq.spinque.com/ipa/session/json
 failed with http://ipa01.hq.spinque.com/ipa/session/json>: 500 Internal Server Error>*
trying https://ipa02.hq.spinque.com/ipa/session/json
[try 1]: Forwarding 'schema' to json server '
https://ipa02.hq.spinque.com/ipa/session/json'
trying https://ipa01.hq.spinque.com/ipa/session/json
Connection to https://ipa01.hq.spinque.com/ipa/session/json failed with

trying https://ipa02.hq.spinque.com/ipa/session/json
[try 1]: Forwarding 'ping/1' to json server '
https://ipa02.hq.spinque.com/ipa/session/json'
Execute check on remote master
[try 1]: Forwarding 'server_conncheck' to json server '
https://ipa02.hq.spinque.com/ipa/session/json'

*ERROR: Remote master check failed with following error message(s):invalid
'cn': must be "ipa02.hq.spinque.com "*


Now, without --auto-master-check:

On ipa02 (I suppose the many "Failed to bind" below are expected?):
[root@ipa02 ~]# /usr/sbin/ipa-replica-conncheck --master
ipa01.hq.spinque.com  --realm HQ.SPINQUE.COM --hostname ipa02.hq.spinque.com
Check connection from replica to remote master 'ipa01.hq.spinque.com':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

The following list of ports use UDP protocoland would need to be
checked manually:
   Kerberos KDC: UDP (88): SKIPPED
   Kerberos Kpasswd: UDP (464): SKIPPED

Connection from replica to master is OK.
Start listening on required ports for remote master check
389 tcp: Failed to bind
636 tcp: Failed to bind
88 tcp: Failed to bind
88 udp: Failed to bind
464 tcp: Failed to bind
464 udp: Failed to bind
80 tcp: Failed to bind
443 tcp: Failed to bind
Listeners are started. Use CTRL+C to terminate the listening part after the
test.

Please run the following command on remote master:
/usr/sbin/ipa-replica-conncheck --replica ipa02.hq.spinque.com
^C
Cleaning up...

On ipa01:
[root@ipa01 ~]# /usr/sbin/ipa-replica-conncheck --replica
ipa02.hq.spinque.com
Check connection from master to remote replica 'ipa02.hq.spinque.com':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos KDC: UDP (88): WARNING
   Kerberos Kpasswd: TCP (464): OK
   Kerberos Kpasswd: UDP (464): WARNING
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK
The following UDP ports could not be verified as open: 88, 464
This can happen if they are already bound to an application
and ipa-replica-conncheck cannot attach own UDP responder.

Connection from master to replica is OK.



On Thu, 23 Jul 2020 at 15:15, Roberto Cornacchia <
roberto.cornacc...@gmail.com> wrote:

> Hi,
>
> I have successfully created a replica from a 4.2.4 master (ipa01) into a
> new 4.6.6 master (ipa02).
>
> I did it without --setup-ca option (because it had failed), so the only CA
> is still on the 4.2.4 server (ipa01).
>
> When I try to setup theCA on ipa02 (the same replica file was used with
> ipa-replica-install), this fails:
>
> $ ipa-ca-install replica-info-ipa02.hq.spinque.com.gpg
> Directory Manager (existing master) password:
>
> Run connection check to master
>
> Your system may be partly configured.
> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>
> Connection check failed!
> See /var/log/ipareplica-conncheck.log for more information.
> If the check results are not valid it can be skipped with --skip-conncheck
> parameter.
>
> The log of conncheck (generated by ipa-ca-install) is in attachment. In
> there, I can see a couple of things going wrong:
>
> ProtocolError:  500 Internal Server Error>
> ...
> 2020-07-23T12:20:50Z ERROR 

[Freeipa-users] ipa-ca-install fails

[Roberto Cornacchia via FreeIPA-users]

Hi,

I have successfully created a replica from a 4.2.4 master (ipa01) into a
new 4.6.6 master (ipa02).

I did it without --setup-ca option (because it had failed), so the only CA
is still on the 4.2.4 server (ipa01).

When I try to setup theCA on ipa02 (the same replica file was used with
ipa-replica-install), this fails:

$ ipa-ca-install replica-info-ipa02.hq.spinque.com.gpg
Directory Manager (existing master) password:

Run connection check to master

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Connection check failed!
See /var/log/ipareplica-conncheck.log for more information.
If the check results are not valid it can be skipped with --skip-conncheck
parameter.

The log of conncheck (generated by ipa-ca-install) is in attachment. In
there, I can see a couple of things going wrong:

ProtocolError: 
...
2020-07-23T12:20:50Z ERROR ERROR: Remote master check failed with following
error message(s):
invalid 'cn': must be "ipa02.hq.spinque.com"

Not sure if relevant, but also ipa-replica-install, though it completed
successfully, gave this error:

Upgrading IPA:. Estimated time: 1 minute 30 seconds
  [1/10]: stopping directory server
  [2/10]: saving configuration
  [3/10]: disabling listeners
  [4/10]: enabling DS global lock
  [5/10]: disabling Schema Compat
  [6/10]: starting directory server
  [7/10]: upgrading server
ipaserver.install.ldapupdate: ERRORAdd failure attribute "cn" not
allowed
  [8/10]: stopping directory server
  [9/10]: restoring configuration
  [10/10]: starting directory server


Could you please help me find the issue?
2020-07-23T12:20:49Z DEBUG /usr/sbin/ipa-replica-conncheck was invoked with options: {'realm': 'HQ.SPINQUE.COM', 'log_to_file': True, 'hostname': 'ipa02.hq.spinque.com', 'quiet': False, 'kdc': None, 'replica': None, 'master': 'ipa01.hq.spinque.com', 'auto_master_check': True, 'debug': False, 'ca_cert_file': '/tmp/tmpmawFlLipa/realm_info/ca.crt', 'check_ca': False, 'principal': None}
2020-07-23T12:20:49Z DEBUG missing options might be asked for interactively later

2020-07-23T12:20:49Z DEBUG IPA version 4.6.6-11.el7.centos
2020-07-23T12:20:49Z INFO Check connection from replica to remote master 'ipa01.hq.spinque.com':
2020-07-23T12:20:49Z INFODirectory Service: Unsecure port (389): OK
2020-07-23T12:20:49Z INFODirectory Service: Secure port (636): OK
2020-07-23T12:20:49Z INFOKerberos KDC: TCP (88): OK
2020-07-23T12:20:49Z INFOKerberos Kpasswd: TCP (464): OK
2020-07-23T12:20:49Z INFOHTTP Server: Unsecure port (80): OK
2020-07-23T12:20:49Z INFOHTTP Server: Secure port (443): OK
2020-07-23T12:20:49Z INFO 
The following list of ports use UDP protocoland would need to be
checked manually:
2020-07-23T12:20:49Z INFOKerberos KDC: UDP (88): SKIPPED
2020-07-23T12:20:49Z INFOKerberos Kpasswd: UDP (464): SKIPPED
2020-07-23T12:20:49Z INFO 
Connection from replica to master is OK.
2020-07-23T12:20:49Z INFO Start listening on required ports for remote master check
2020-07-23T12:20:49Z DEBUG Starting listening thread.
2020-07-23T12:20:49Z DEBUG Original thread stopped
2020-07-23T12:20:49Z WARNING 389 tcp: Failed to bind
2020-07-23T12:20:49Z DEBUG Traceback (most recent call last):
  File "/usr/sbin/ipa-replica-conncheck", line 341, in _bind_to_port
sock.bind((host, port))
  File "/usr/lib64/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
error: [Errno 98] Address already in use

2020-07-23T12:20:49Z WARNING 636 tcp: Failed to bind
2020-07-23T12:20:49Z DEBUG Traceback (most recent call last):
  File "/usr/sbin/ipa-replica-conncheck", line 341, in _bind_to_port
sock.bind((host, port))
  File "/usr/lib64/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
error: [Errno 98] Address already in use

2020-07-23T12:20:49Z WARNING 88 tcp: Failed to bind
2020-07-23T12:20:49Z DEBUG Traceback (most recent call last):
  File "/usr/sbin/ipa-replica-conncheck", line 341, in _bind_to_port
sock.bind((host, port))
  File "/usr/lib64/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
error: [Errno 98] Address already in use

2020-07-23T12:20:49Z WARNING 88 udp: Failed to bind
2020-07-23T12:20:49Z DEBUG Traceback (most recent call last):
  File "/usr/sbin/ipa-replica-conncheck", line 341, in _bind_to_port
sock.bind((host, port))
  File "/usr/lib64/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
error: [Errno 98] Address already in use

2020-07-23T12:20:49Z WARNING 464 tcp: Failed to bind
2020-07-23T12:20:49Z DEBUG Traceback (most recent call last):
  File "/usr/sbin/ipa-replica-conncheck", line 341, in _bind_to_port
sock.bind((host, port))
  File "/usr/lib64/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
error: [Errno 98] Address already in use

2020-07-23T12:20:49Z WARNING 464 udp: Failed to bind
2020-07-23T12:20:49Z DEBUG Traceback 

[Freeipa-users] Replica from 4.2 to 4.8

[Roberto Cornacchia via FreeIPA-users]

Hi,

I currently have a single 4.2.4 server.

I would like to create a replica with 4.8 and later decommission the 4.2
server.

I had tested the procedure a while ago, from 4.2 to 4.6. I had created a
replica package from the old instance, and used it with ipa-replica-install
to create the new one.

However, I see that 4.8 no longer supports level 0. Does this mean I cannot
do this replica in one go? I also see that ipa-replica-install does not
accept the replica package in input. So I suppose it only supports the
upgrade to master of an existing client.

What is the best route for my 4.2 -> 4.8 replica?

Thanks,
Roberto
___
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

[Freeipa-users] Re: Upgrading from 4.2.4 (FC23)

[Roberto Cornacchia via FreeIPA-users]

Brian,

Thanks for your suggestions.
Actually using the Docker image seems very attractive, if it is close to
production quality. I can experiment anyway.

What I don't really know is whether I can experiment with creating replicas
of the current server. I mean, can creating replicas harm the existing
server in any way, in case something goes wrong?

On Mon, 17 Dec 2018 at 13:17 Brian Topping  wrote:

> Have you considered starting to use the docker image? I knew that there
> was upgrade and it worked very well, completely automated.
>
> Maybe start separate test cluster with older image, then experience the
> upgrade. When you are satisfied, use the docker image that is the same
> version as your current cluster, then upgrade it.
>
> Anyway, if that is uncomfortable, try to learn how to verify that the
> replicas are synchronized with CLI. When you can confirm that the replicas
> are synchronized, your plan is easier because you can also confirm at the
> end that they are still synchronized.
>
> I would also do this with three replicas, not two. Then when you shut down
> A replica, you can confirm B and C are properly replicating as you upgrade
> before destroying A. If you get stuck, you can still safely start over.
>
> Lastly, if you are using a system that supports snapshots, it’s the best
> way to keep the original copy of a replica before making changes. In the
> worst case, you can reset all the snapshots and reboot.
>
> > On Dec 17, 2018, at 6:17 PM, Roberto Cornacchia via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
> >
> > Dear all,
> >
> > Upgrading is always scary, I will appreciate any comment on the
> following.
> >
> > Our freeIPA is serving a small number of FC desktops and users (< 10),
> and is running on a FC 23 server, with packages for ipa versioned
> 4.2.4-2.fc23.
> >
> > The simplest thing I can do is of course to upgrade the FC system until
> the latest, one version at the time. What I probably want to do is actually
> move to CentOS - I'm fed up with running after FC releases.
> >
> > In both cases (especially in the second case), I thought it may be wise
> to make a replica of the ipa server before starting the upgrade.
> >
> > My plan would be:
> > - Have an up-to-date CentOS system (IPA-B), enroll it and promote it to
> replica of the existing one (IPA-A)
> > - [ Question: is it better to have IPA-B on a recent version or on the
> same version as IPA-A? ]
> > - Shut down IPA-A
> > - Verify that IPA-B works
> > - Wipe out IPA-A, install recent CentOS.
> > - Enroll IPA-A
> > - Promote it to replica.
> > - Enjoy
> >
> > Am I overlooking something? Could I do something more prudently?
> >
> > Thanks for your input!
> > Roberto
> >
> >
> > ___
> > 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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
>
>
___
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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: certificate has expired?

[Roberto Cornacchia via FreeIPA-users]

A relatively good news:
The current error (Insufficient access: Principal 'HTTP/
spinque04.hq.spinque@hq.spinque.com' is not permitted to use CA '.'
with profile 'caIPAserviceCert' for certificate issuance.) might not be due
to the package upgrade.

I looked at the journal of 16 Feb 2017 (28 days before the expiration
date): certmonger correctly tries to renew the certificate but fails with
the exact same error as I have now. So this explains why I ended up with an
expired certificate in the first place.

So hopefully I'm back to the original issue that caused all this. Any help
is highly appreciated.


On Wed, 7 Jun 2017 at 19:15 Rob Crittenden <rcrit...@redhat.com> wrote:

> Roberto Cornacchia via FreeIPA-users wrote:
> > Sorry for accidentally dropping freeipa-users.
> >
> > I was impatient so went back in time before your answer, but I did chose
> > a good date
> >
> > Before this, I had the following two entries with an expired date:
> >
> > Request ID '20150316184508':
> > status: NEED_TO_SUBMIT
> > ca-error: Error setting up ccache for "host" service on client using
> > default keytab: Cannot contact any KDC for requested realm.
> >
> > Request ID '20150316184529':
> > status: CA_UNREACHABLE
> > ca-error: Error setting up ccache for "host" service on client using
> > default keytab: Cannot contact any KDC for requested realm.
> >
> > After restarting certmonger, I have:
> >
> > Request ID '20150316184508':
> > status: MONITORING
> > ca-error: Server at https://spinque04.hq.spinque.com/ipa/xml
> > denied our request, giving up: 2100 (RPC failed at server.  Insufficient
> > access: Principal 'ldap/spinque04.hq.spinque@hq.spinque.com
> > <mailto:spinque04.hq.spinque@hq.spinque.com>' is not permitted to
> > use CA '.' with profile 'caIPAserviceCert' for certificate issuance.).
> >
> > Request ID '20150316184529':
> > status: MONITORING
> > ca-error: Server at https://spinque04.hq.spinque.com/ipa/xml
> > denied our request, giving up: 2100 (RPC failed at server.  Insufficient
> > access: Principal 'HTTP/spinque04.hq.spinque@hq.spinque.com
> > <mailto:spinque04.hq.spinque@hq.spinque.com>' is not permitted to
> > use CA '.' with profile 'caIPAserviceCert' for certificate issuance.).
>
> I think this is a side-effect of updating the packages with expired
> certs (you are about half upgraded right now). The new CA ACL rules
> don't seem to have been applied. I'm not sure what the safest course in,
> maybe Flo or Fraser know.
>
> rob
>
> >
> > The journal shows continuous Tomcat errors such as this:
> >
> > Mar 01 00:09:28 spinque04.hq.spinque.com
> > <http://spinque04.hq.spinque.com> named-pkcs11[5692]: validating
> > docs.oracle.com/CNAME <http://docs.oracle.com/CNAME>: bad cache hit
> > (oracle.com/DS <http://oracle.com/DS>)
> > Mar 01 00:09:28 spinque04.hq.spinque.com
> > <http://spinque04.hq.spinque.com> named-pkcs11[5692]: broken trust chain
> > resolving 'docs.oracle.com/A/IN <http://docs.oracle.com/A/IN>':
> 8.8.8.8#53
> > Mar 01 00:09:28 spinque04.hq.spinque.com
> > <http://spinque04.hq.spinque.com> named-pkcs11[5692]: validating
> > docs.oracle.com/CNAME <http://docs.oracle.com/CNAME>: bad cache hit
> > (oracle.com/DS <http://oracle.com/DS>)
> > Mar 01 00:09:28 spinque04.hq.spinque.com
> > <http://spinque04.hq.spinque.com> named-pkcs11[5692]: broken trust chain
> > resolving 'docs.oracle.com//IN <http://docs.oracle.com//IN>':
> > 8.8.8.8#53
> > Mar 01 00:09:32 spinque04.hq.spinque.com
> > <http://spinque04.hq.spinque.com> server[5912]: Mar 01, 2017 12:09:32 AM
> > org.apache.catalina.core.ContainerBase backgroundProcess
> > Mar 01 00:09:32 spinque04.hq.spinque.com
> > <http://spinque04.hq.spinque.com> server[5912]: WARNING: Exception
> > processing realm com.netscape.cms.tomcat.ProxyRealm@4077b502 background
> > process
> > Mar 01 00:09:32 spinque04.hq.spinque.com
> > <http://spinque04.hq.spinque.com> server[5912]:
> > java.lang.NullPointerException
> > Mar 01 00:09:32 spinque04.hq.spinque.com
> > <http://spinque04.hq.spinque.com> server[5912]: at
> > com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:109)
> > Mar 01 00:09:32 spinque04.hq.spinque.com
> > <http://spinque04.hq.spinque.com> server[5912]: at
> >
> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1154)
> > Mar 01 00:09:32 spinque04.hq.spinque.com
> > <http://

[Freeipa-users] Re: certificate has expired?

[Roberto Cornacchia via FreeIPA-users]

Hi Florence,
I just posted that the problem is solved, but thank for coming back to me!

Now (on the fixed system) I get:
$ getcert list-cas -c IPA
CA 'IPA':
is-default: no
ca-type: EXTERNAL
helper-location: /usr/libexec/certmonger/ipa-server-guard
/usr/libexec/certmonger/ipa-submit

One thing I didn't mention in the previous post is that the ACL was also
gone, I had to recreate it manually.
Now it looks like this:

$ ipa caacl-find

1 CA ACL matched

  ACL name: hosts_services_caIPAserviceCert
  Enabled: TRUE
  Host category: all
  Service category: all
  Profiles: caIPAserviceCert

Number of entries returned 1




On Thu, 8 Jun 2017 at 11:02 Roberto Cornacchia <roberto.cornacc...@gmail.com>
wrote:

> It seems solved now, reporting back.
>
> It looks to me like in February, when the certificate renewal failed, I
> had hit the bug described here:
> https://www.redhat.com/archives/freeipa-users/2016-February/msg00441.html
>
> Yesterday I updated the packages, including the fix to this bug, but then
> I still had an expired certificate. Which didn't allow to complete
> ipa-server-upgrade.
> Went back in time, asked certmonger to renew, but I was then missing
> certificate profiles, because the upgrade was not completed.
> Now however the certificate was valid, because the date was changed. With
> that, I could manually run ipa-server-upgrade, which successfully imported
> all profiles.
> Restarted ipa, restarted certmonger, got new certificates.
> Went back to today's date, restarted ipa, and everything seems fine.
>
>
>
>
> On Wed, 7 Jun 2017 at 23:25 Roberto Cornacchia <
> roberto.cornacc...@gmail.com> wrote:
>
>> A relatively good news:
>> The current error (Insufficient access: Principal 'HTTP/
>> spinque04.hq.spinque@hq.spinque.com' is not permitted to use CA '.'
>> with profile 'caIPAserviceCert' for certificate issuance.) might not be
>> due to the package upgrade.
>>
>> I looked at the journal of 16 Feb 2017 (28 days before the expiration
>> date): certmonger correctly tries to renew the certificate but fails with
>> the exact same error as I have now. So this explains why I ended up with an
>> expired certificate in the first place.
>>
>> So hopefully I'm back to the original issue that caused all this. Any
>> help is highly appreciated.
>>
>>
>> On Wed, 7 Jun 2017 at 19:15 Rob Crittenden <rcrit...@redhat.com> wrote:
>>
>>> Roberto Cornacchia via FreeIPA-users wrote:
>>> > Sorry for accidentally dropping freeipa-users.
>>> >
>>> > I was impatient so went back in time before your answer, but I did
>>> chose
>>> > a good date
>>> >
>>> > Before this, I had the following two entries with an expired date:
>>> >
>>> > Request ID '20150316184508':
>>> > status: NEED_TO_SUBMIT
>>> > ca-error: Error setting up ccache for "host" service on client using
>>> > default keytab: Cannot contact any KDC for requested realm.
>>> >
>>> > Request ID '20150316184529':
>>> > status: CA_UNREACHABLE
>>> > ca-error: Error setting up ccache for "host" service on client using
>>> > default keytab: Cannot contact any KDC for requested realm.
>>> >
>>> > After restarting certmonger, I have:
>>> >
>>> > Request ID '20150316184508':
>>> > status: MONITORING
>>> > ca-error: Server at https://spinque04.hq.spinque.com/ipa/xml
>>> > denied our request, giving up: 2100 (RPC failed at server.
>>> Insufficient
>>> > access: Principal 'ldap/spinque04.hq.spinque@hq.spinque.com
>>> > <mailto:spinque04.hq.spinque@hq.spinque.com>' is not permitted to
>>> > use CA '.' with profile 'caIPAserviceCert' for certificate issuance.).
>>> >
>>> > Request ID '20150316184529':
>>> > status: MONITORING
>>> > ca-error: Server at https://spinque04.hq.spinque.com/ipa/xml
>>> > denied our request, giving up: 2100 (RPC failed at server.
>>> Insufficient
>>> > access: Principal 'HTTP/spinque04.hq.spinque@hq.spinque.com
>>> > <mailto:spinque04.hq.spinque@hq.spinque.com>' is not permitted to
>>> > use CA '.' with profile 'caIPAserviceCert' for certificate issuance.).
>>>
>>> I think this is a side-effect of updating the packages with expired
>>> certs (you are about half upgraded right now). The new CA ACL rules
>>> don't seem to h

[Freeipa-users] Re: certificate has expired?

[Roberto Cornacchia via FreeIPA-users]

It seems solved now, reporting back.

It looks to me like in February, when the certificate renewal failed, I had
hit the bug described here:
https://www.redhat.com/archives/freeipa-users/2016-February/msg00441.html

Yesterday I updated the packages, including the fix to this bug, but then I
still had an expired certificate. Which didn't allow to complete
ipa-server-upgrade.
Went back in time, asked certmonger to renew, but I was then missing
certificate profiles, because the upgrade was not completed.
Now however the certificate was valid, because the date was changed. With
that, I could manually run ipa-server-upgrade, which successfully imported
all profiles.
Restarted ipa, restarted certmonger, got new certificates.
Went back to today's date, restarted ipa, and everything seems fine.




On Wed, 7 Jun 2017 at 23:25 Roberto Cornacchia <roberto.cornacc...@gmail.com>
wrote:

> A relatively good news:
> The current error (Insufficient access: Principal 'HTTP/
> spinque04.hq.spinque@hq.spinque.com' is not permitted to use CA '.'
> with profile 'caIPAserviceCert' for certificate issuance.) might not be
> due to the package upgrade.
>
> I looked at the journal of 16 Feb 2017 (28 days before the expiration
> date): certmonger correctly tries to renew the certificate but fails with
> the exact same error as I have now. So this explains why I ended up with an
> expired certificate in the first place.
>
> So hopefully I'm back to the original issue that caused all this. Any help
> is highly appreciated.
>
>
> On Wed, 7 Jun 2017 at 19:15 Rob Crittenden <rcrit...@redhat.com> wrote:
>
>> Roberto Cornacchia via FreeIPA-users wrote:
>> > Sorry for accidentally dropping freeipa-users.
>> >
>> > I was impatient so went back in time before your answer, but I did chose
>> > a good date
>> >
>> > Before this, I had the following two entries with an expired date:
>> >
>> > Request ID '20150316184508':
>> > status: NEED_TO_SUBMIT
>> > ca-error: Error setting up ccache for "host" service on client using
>> > default keytab: Cannot contact any KDC for requested realm.
>> >
>> > Request ID '20150316184529':
>> > status: CA_UNREACHABLE
>> > ca-error: Error setting up ccache for "host" service on client using
>> > default keytab: Cannot contact any KDC for requested realm.
>> >
>> > After restarting certmonger, I have:
>> >
>> > Request ID '20150316184508':
>> > status: MONITORING
>> > ca-error: Server at https://spinque04.hq.spinque.com/ipa/xml
>> > denied our request, giving up: 2100 (RPC failed at server.  Insufficient
>> > access: Principal 'ldap/spinque04.hq.spinque@hq.spinque.com
>> > <mailto:spinque04.hq.spinque@hq.spinque.com>' is not permitted to
>> > use CA '.' with profile 'caIPAserviceCert' for certificate issuance.).
>> >
>> > Request ID '20150316184529':
>> > status: MONITORING
>> > ca-error: Server at https://spinque04.hq.spinque.com/ipa/xml
>> > denied our request, giving up: 2100 (RPC failed at server.  Insufficient
>> > access: Principal 'HTTP/spinque04.hq.spinque@hq.spinque.com
>> > <mailto:spinque04.hq.spinque@hq.spinque.com>' is not permitted to
>> > use CA '.' with profile 'caIPAserviceCert' for certificate issuance.).
>>
>> I think this is a side-effect of updating the packages with expired
>> certs (you are about half upgraded right now). The new CA ACL rules
>> don't seem to have been applied. I'm not sure what the safest course in,
>> maybe Flo or Fraser know.
>>
>> rob
>>
>> >
>> > The journal shows continuous Tomcat errors such as this:
>> >
>> > Mar 01 00:09:28 spinque04.hq.spinque.com
>> > <http://spinque04.hq.spinque.com> named-pkcs11[5692]: validating
>> > docs.oracle.com/CNAME <http://docs.oracle.com/CNAME>: bad cache hit
>> > (oracle.com/DS <http://oracle.com/DS>)
>> > Mar 01 00:09:28 spinque04.hq.spinque.com
>> > <http://spinque04.hq.spinque.com> named-pkcs11[5692]: broken trust
>> chain
>> > resolving 'docs.oracle.com/A/IN <http://docs.oracle.com/A/IN>':
>> 8.8.8.8#53
>> > Mar 01 00:09:28 spinque04.hq.spinque.com
>> > <http://spinque04.hq.spinque.com> named-pkcs11[5692]: validating
>> > docs.oracle.com/CNAME <http://docs.oracle.com/CNAME>: bad cache hit
>> > (oracle.com/DS <http://oracle.com/DS>)
>> > Mar 01 00:09:28 spinque04.hq.spinque.com
>> > <http://spinque04.hq.spinque.com> named-pk

[Freeipa-users] Re: certificate has expired?

[Roberto Cornacchia via FreeIPA-users]

first try:
>
> # getcert resubmit -i 20150316184529
>
> It is very possible that the tool will reject the server cert since it
> is expired. If that happens then you'll need to set time back.
>
> I'd encourage you to run: getcert list | grep expires
>
> This will show you what certs need to be renewed and should give some
> insight into the window of opportunity for setting the date back.
>
> Assuming it's just the Apache cert that is expired I'd try setting the
> date back to March 15, restart IPA, then I'd restart certmonger or try
> the about resubmit command again.
>
> Things can get tricky when some certs have renewed and some haven't.
>
> rob
>
> >
> >
> > On Wed, 7 Jun 2017 at 15:36 Roberto Cornacchia
> > <roberto.cornacc...@gmail.com <mailto:roberto.cornacc...@gmail.com>>
> wrote:
> >
> > Thanks Rob,
> >
> > I've seen in similar posts that you recommend to go back in time and
> > restart certmonger. Would it work in this case?
> >
> >
> > On Wed, 7 Jun 2017 at 15:30 Rob Crittenden <rcrit...@redhat.com
> > <mailto:rcrit...@redhat.com>> wrote:
> >
> > Roberto Cornacchia via FreeIPA-users wrote:
> > > OK, I did so and httpd restarts.
> > >
> > > $ openssl s_client -connect 127.0.0.1:443
> > <http://127.0.0.1:443> <http://127.0.0.1:443> -showcerts
> > > CONNECTED(0003)
> > > depth=1 O = HQ.SPINQUE.COM <http://HQ.SPINQUE.COM>
> > <http://HQ.SPINQUE.COM>, CN = Certificate
> > > Authority
> > > verify return:1
> > > depth=0 O = HQ.SPINQUE.COM <http://HQ.SPINQUE.COM>
> > <http://HQ.SPINQUE.COM>, CN =
> > > spinque04.hq.spinque.com <http://spinque04.hq.spinque.com>
> > <http://spinque04.hq.spinque.com>
> > > verify error:num=10:certificate has expired
> > > notAfter=Mar 16 18:45:29 2017 GMT
> > > verify return:1
> > > depth=0 O = HQ.SPINQUE.COM <http://HQ.SPINQUE.COM>
> > <http://HQ.SPINQUE.COM>, CN =
> > > spinque04.hq.spinque.com <http://spinque04.hq.spinque.com>
> > <http://spinque04.hq.spinque.com>
> > > notAfter=Mar 16 18:45:29 2017 GMT
> > > verify return:1
> > > ---
> > > Certificate chain
> > >  0 s:/O=HQ.SPINQUE.COM/CN=spinque04.hq.spinque.com
> > <http://HQ.SPINQUE.COM/CN=spinque04.hq.spinque.com>
> > > <http://HQ.SPINQUE.COM/CN=spinque04.hq.spinque.com>
> > >i:/O=HQ.SPINQUE.COM/CN=Certificate
> > <http://HQ.SPINQUE.COM/CN=Certificate>
> > > <http://HQ.SPINQUE.COM/CN=Certificate> Authority
> > > ...
> > >
> > > Fair enough, but why does this say it expires in 2019? Are
> > they two
> > > different certificates?
> > >
> > > $ getcert list -d /etc/httpd/alias -n ipaCert
> > > Number of certificates and requests being tracked: 8.
> > > Request ID '20160501114633':
> > > status: MONITORING
> > > stuck: no
> > > key pair storage:
> > >
> >
>  type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
> > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> > > certificate:
> > >
> >
>  type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
> > > Certificate DB'
> > > CA: dogtag-ipa-ca-renew-agent
> > > issuer: CN=Certificate Authority,O=HQ.SPINQUE.COM
> > <http://HQ.SPINQUE.COM> <http://HQ.SPINQUE.COM>
> > > subject: CN=IPA RA,O=HQ.SPINQUE.COM <http://HQ.SPINQUE.COM>
> > <http://HQ.SPINQUE.COM>
> > > expires: 2019-01-26 19:41:51 UTC
> > > key usage:
> > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> > > eku: id-kp-serverAuth,id-kp-clientAuth
> > > pre-save command: /usr/lib64/ipa/certmonger/renew_ra_cert_pre
> > > post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert
> > > track: yes
> > > auto-renew: yes
> > >
> > > What's the right way to solve this?
> >
> > You're looking at the wrong cert.
> >
> > # getcert list -d /etc/httpd/alias -n Server-Cert
> >
> > And really, you should examine all certificate status, not just
> > a single
> > one.
> >
> > I was also strongly urge you to wait until all problems are
> resolved
> > before attempting to update packages in the future (unless a
> package
> > claims to fix a specific problem), particularly when it comes to
> > certificates.
> >
> > rob
> >
>
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: certificate has expired?

[Roberto Cornacchia via FreeIPA-users]

OK, I did so and httpd restarts.

$ openssl s_client -connect 127.0.0.1:443 -showcerts
CONNECTED(0003)
depth=1 O = HQ.SPINQUE.COM, CN = Certificate Authority
verify return:1
depth=0 O = HQ.SPINQUE.COM, CN = spinque04.hq.spinque.com
verify error:num=10:certificate has expired
notAfter=Mar 16 18:45:29 2017 GMT
verify return:1
depth=0 O = HQ.SPINQUE.COM, CN = spinque04.hq.spinque.com
notAfter=Mar 16 18:45:29 2017 GMT
verify return:1
---
Certificate chain
 0 s:/O=HQ.SPINQUE.COM/CN=spinque04.hq.spinque.com
   i:/O=HQ.SPINQUE.COM/CN=Certificate Authority
...

Fair enough, but why does this say it expires in 2019? Are they two
different certificates?

$ getcert list -d /etc/httpd/alias -n ipaCert
Number of certificates and requests being tracked: 8.
Request ID '20160501114633':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=HQ.SPINQUE.COM
subject: CN=IPA RA,O=HQ.SPINQUE.COM
expires: 2019-01-26 19:41:51 UTC
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command: /usr/lib64/ipa/certmonger/renew_ra_cert_pre
post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert
track: yes
auto-renew: yes

What's the right way to solve this?


On Wed, 7 Jun 2017 at 14:52 John Keates via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> I would suggest doing what the last line says:
>
> Add "NSSEnforceValidCerts off" to nss.conf so the server can start until
> the problem can be resolved.
>
> Then, you can check the certificates and maybe refresh it if it is
> actually expired.
>
> John
>
> On 7 Jun 2017, at 14:39, Roberto Cornacchia via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
>
> Things are getting worse.
>
> First, the version I reported before was incorrect (taken from a client).
> Here's the server one.
>
> $ ipa --version
> VERSION: 4.2.4, API_VERSION: 2.156
>
> I did a dnf update (Fedora 23). The IPA upgrade failed.
> I tried running it again, manually, after a reboot:
>
> $ ipa-server-upgrade
> session memcached servers not running
> Upgrading IPA:
>   [1/8]: saving configuration
>   [2/8]: disabling listeners
>   [3/8]: enabling DS global lock
>   [4/8]: starting directory server
>   [5/8]: updating schema
>   [6/8]: upgrading server
> Add failure attribute "cn" not allowed
>   [7/8]: stopping directory server
>   [8/8]: restoring configuration
> Done.
> Update complete
> Upgrading IPA services
> Upgrading the configuration of the IPA services
> [Verifying that root certificate is published]
> [Migrate CRL publish directory]
> CRL tree already moved
> [Verifying that CA proxy configuration is correct]
> [Verifying that KDC configuration is using ipa-kdb backend]
> [Fix DS schema file syntax]
> Syntax already fixed
> [Removing RA cert from DS NSS database]
> RA cert already removed
> [Enable sidgen and extdom plugins by default]
> [Updating mod_nss protocol versions]
> Protocol versions already updated
> [Fixing trust flags in /etc/httpd/alias]
> Trust flags already processed
> [Exporting KRA agent PEM file]
> KRA is not enabled
> 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' 'httpd.service''
> returned non-zero exit status 1
>
> The ipaupgrade log only says that starting httpd failed.
>
> HTTPD log says:
>
> [Wed Jun 07 14:32:26.822478 2017] [core:notice] [pid 3182] SELinux policy
> enabled; httpd running as context system_u:system_r:httpd_t:s0
> [Wed Jun 07 14:32:26.823122 2017] [suexec:notice] [pid 3182] AH01232:
> suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
> [Wed Jun 07 14:32:26.823467 2017] [:warn] [pid 3182]
> NSSSessionCacheTimeout is deprecated. Ignoring.
> [Wed Jun 07 14:32:26.913923 2017] [:error] [pid 3182] SSL Library Error:
> -8181 Certificate has expired
> [Wed Jun 07 14:32:26.913942 2017] [:error] [pid 3182] Unable to verify
> certificate 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so
> the server can start until the problem can be resolved.
>
> Any suggestion?
>
> On Wed, 7 Jun 2017 at 13:17 Roberto Cornacchia <
> roberto.cornacc...@gmail.com> wrote:
>
>> Not being able to login to the admin console, I checked the httpd log and
>> found the following errors:
>>
>> [Wed Jun 07 12:50:59.352022 201

[Freeipa-users] certificate has expired?

[Roberto Cornacchia via FreeIPA-users]

Not being able to login to the admin console, I checked the httpd log and
found the following errors:

[Wed Jun 07 12:50:59.352022 2017] [:error] [pid 10240] Unable to verify
certificate 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so
the server can start until the problem can be resolved.
[Wed Jun 07 12:50:59.353372 2017] [:error] [pid 10237] SSL Library Error:
-8181 Certificate has expired
[Wed Jun 07 12:50:59.353395 2017] [:error] [pid 10237] Unable to verify
certificate 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so
the server can start until the problem can be resolved.
[Wed Jun 07 12:50:59.986025 2017] [core:error] [pid 11522] AH00546: no
record of generation 47 of exiting child 10203

I also get an error during enrollment of a new client (which seems to
retrieve a valid certificate anyway):

Password for ad...@hq.spinque.com:
Successfully retrieved CA cert
Subject: CN=Certificate Authority,O=HQ.SPINQUE.COM
Issuer:  CN=Certificate Authority,O=HQ.SPINQUE.COM
Valid From:  Mon Mar 16 18:44:35 2015 UTC
Valid Until: Fri Mar 16 18:44:35 2035 UTC

Joining realm failed: libcurl failed to execute the HTTP POST transaction,
explaining:  TCP connection reset by peer

Services are up:

$ ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
ipa_memcached Service: RUNNING
httpd Service: RUNNING
pki-tomcatd Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful


Certificate monitoring seems ok:

$ getcert list -d /etc/httpd/alias -n ipaCert
Number of certificates and requests being tracked: 8.
Request ID '20160501114633':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=HQ.SPINQUE.COM
subject: CN=IPA RA,O=HQ.SPINQUE.COM
expires: 2019-01-26 19:41:51 UTC
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command: /usr/lib64/ipa/certmonger/renew_ra_cert_pre
post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert
track: yes
auto-renew: yes

Version:

$ ipa --version
VERSION: 4.4.3, API_VERSION: 2.215

Could you please point me at what else to check?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org