kadmin not working after server migration, but kdc works
Wouter Verhelst
w at uter.be
Wed Sep 21 11:44:40 EDT 2022
On Wed, Sep 21, 2022 at 10:29:57AM -0400, Greg Hudson wrote:
> On 9/21/22 03:45, Wouter Verhelst wrote:
> > default_principal_expiration = 0
>
> This value is failing to parse as a timestamp. Removing this line
> appears to clear up the config parsing error, and the default should
> have the same effect.
Yes, that seems to fix the issue -- at least kadmin.local works again.
\o/
Thanks!
> I see that the documentation for default_principal_expiration says "The
> default value is 0, which means no expiration date." I see how someone
> would get that from the code when writing the documentation, but clearly
> the documented default should be something that parses. (I think you'd
> have to write out the beginning of the POSIX time epoch--in local
> time--in something like yyyymmddhhmmss format to get this default.) The
> whole concept of default_principal_expiration as an absolute time seems
> suspect to me; I have trouble imagining a productive realm configuration
> where every new principal by default expires on some particular fixed date.
>
> I don't see any meaningful differences between the current code in this
> area and the code going back fifteen years or so. So I'm not sure how
> this broke during a migration.
The migration was quite a while ago; it is possible (given this error,
perhaps a better way to put it is "likely") that I fiddled with the
configuration files while migrating to the new server (while wanting to
"clean things up" or some such) and forgot about it in the time since.
Sincerest apologies for the confusion there, but a heartfelt thanks for
helping me fix it! I never would've found that by myself...
--
w at uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
More information about the Kerberos
mailing list