Jacob Champion writes:
> On Mon, 2021-01-25 at 14:36 -0500, Tom Lane wrote:
>> Also, it looks like the test causes /tmp/krb5cc_ to get
>> created or updated despite this setting.
> Huh. I wonder, if you run `klist -A` after running the tests, do you
> get anything more interesting?
"klist -A" pr
Jacob Champion writes:
> On Mon, 2021-01-25 at 14:04 -0500, Tom Lane wrote:
>> True, but if it did try to access the cache, accessing the user's
>> normal cache would be strictly worse than accessing the test cache.
> That's fair. Attached is a v2 that just sets KRB5CCNAME globally. Makes
> for a
On Mon, 2021-01-25 at 14:36 -0500, Tom Lane wrote:
> However, this doesn't seem to explain why the test script isn't
> causing a global state change. Whether the state is held in a
> file or the sssd daemon shouldn't matter, it seems like.
>
> Also, it looks like the test causes /tmp/krb5cc_ to g
I wrote:
> Jacob Champion writes:
>> Interesting. I'm running Ubuntu 20.04:
> Hmm. I'll poke harder.
Ah ... on both RHEL8 and Fedora 33, I find this:
--- snip ---
$ cat /etc/krb5.conf.d/kcm_default_ccache
# This file should normally be installed by your distribution into a
# directory that is
On Mon, 2021-01-25 at 14:04 -0500, Tom Lane wrote:
> Jacob Champion writes:
> > On Mon, 2021-01-25 at 13:49 -0500, Tom Lane wrote:
> > > Also, why are you only setting the ENV variable within narrow parts
> > > of the test script? I'd be inclined to enforce it throughout.
> > I considered it and
Jacob Champion writes:
> On Mon, 2021-01-25 at 13:49 -0500, Tom Lane wrote:
>> Yeah, changing global state is just awful. However, I don't
>> actually see any change here (RHEL8):
> Interesting. I'm running Ubuntu 20.04:
Hmm. I'll poke harder.
>> Also, why are you only setting the ENV variabl
On Mon, 2021-01-25 at 13:49 -0500, Tom Lane wrote:
> Yeah, changing global state is just awful. However, I don't
> actually see any change here (RHEL8):
Interesting. I'm running Ubuntu 20.04:
$ klist
klist: No credentials cache found (filename: /tmp/krb5cc_1000)
$ make check
...
$ klist
Ticket
Stephen Frost writes:
> * Jacob Champion (pchamp...@vmware.com) wrote:
>> I was running tests with a GSS-enabled stack, and ran into some very
>> long psql timeouts after running the Kerberos test suite. It turns out
>> the suite pushes test credentials into the user's global cache, and
>> these n
Greetings,
* Jacob Champion (pchamp...@vmware.com) wrote:
> I was running tests with a GSS-enabled stack, and ran into some very
> long psql timeouts after running the Kerberos test suite. It turns out
> the suite pushes test credentials into the user's global cache, and
> these no-longer-useful c
Hi all,
I was running tests with a GSS-enabled stack, and ran into some very
long psql timeouts after running the Kerberos test suite. It turns out
the suite pushes test credentials into the user's global cache, and
these no-longer-useful credentials persist after the suite has
finished. (You can
10 matches
Mail list logo
