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
worse than accessing the test cache.
That's fair. Attached is a v2 that just sets KRB5CCNAME globally. Makes
for a much smaller patch :)
--Jacob
From 86a7331868e6155488e568864c099caf1f21dffb Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Mon, 25 Jan 2021 09:32:44 -0800
Subject: [PATC
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
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
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. (Yo
On Tue, Mar 06, 2018 at 10:58:54AM -0500, Peter Eisentraut wrote:
> On 3/5/18 16:34, Thomas Munro wrote:
> > On Tue, Mar 6, 2018 at 8:45 AM, Peter Eisentraut
> > wrote:
> >> New patch attached.
> >
> > Passes here. LGTM.
>
> committed
This fails on my machine, where /etc/hosts has:
127.0.0.
Peter Eisentraut wrote:
> On 3/5/18 21:08, Michael Paquier wrote:
> > +my $kdc_port = int(rand() * 16384) + 49152;
> > That may not be worth worrying as that's an ephemeral port range but it
> > can make the test a bit unstable...
>
> This is what we've been using in the other tests as well. It's
Peter Eisentraut writes:
> On 3/5/18 21:08, Michael Paquier wrote:
>
>> Perhaps the tests should be skipped on Windows or just produce an error?
>> Like LDAP tests, libraries are supported on Windows but the hardcoded
>> paths make things harder to handle there.
>
> Hmm, why couldn't someone inst
On 3/5/18 21:08, Michael Paquier wrote:
> +my $kdc_port = int(rand() * 16384) + 49152;
> That may not be worth worrying as that's an ephemeral port range but it
> can make the test a bit unstable...
This is what we've been using in the other tests as well. It's clearly
not optimal, but making it
On 3/5/18 16:34, Thomas Munro wrote:
> On Tue, Mar 6, 2018 at 8:45 AM, Peter Eisentraut
> wrote:
>> New patch attached.
>
> Passes here. LGTM.
committed
> Only complaint is your assumption that 'darwin' implies HomeBrew
> installation paths, but you already did that in other tests before
> thi
On Mon, Mar 05, 2018 at 02:45:07PM -0500, Peter Eisentraut wrote:
> On 2/27/18 00:21, Michael Paquier wrote:
>> +my ($stdout, $krb5_version);
>> +IPC::Run::run [ 'krb5-config', '--version' ], '>', \$stdout or die
>> "could not execute krb5-config";
>> +$stdout =~ m/Kerberos 5 release ([0-9]+\.[0-9]
On Tue, Mar 6, 2018 at 8:45 AM, Peter Eisentraut
wrote:
> New patch attached.
Passes here. LGTM.
Only complaint is your assumption that 'darwin' implies HomeBrew
installation paths, but you already did that in other tests before
this one. Perhaps we can sort that out globally in some future pa
On 2/27/18 00:21, Michael Paquier wrote:
> Thanks. Could you document that on the README please? krb5-user and
> krb5-kdc is a split from Debian. For darwin, are you using macports or
> homebrew? I would assume the later, and it would be nice to precise
> that in the README as well. On Debian
Thomas Munro writes:
> Peter Eisentraut wrote:
>> On 2/27/18 00:56, Thomas Munro wrote:
>>> FWIW it passes for me if I add this:
>>>
>>> +elsif ($^O eq 'freebsd')
>>> +{
>>> + $krb5_bin_dir = '/usr/local/bin';
>>> + $krb5_sbin_dir = '/usr/local/sbin';
>>
>> I suppose you only need th
Michael Paquier writes:
> On Wed, Feb 14, 2018 at 09:27:04AM -0500, Peter Eisentraut wrote:
>
>> (If it appears to hang for you in the "setting up Kerberos" step, you
>> might need more entropy/wait a while. That problem appears to be
>> limited to some virtual machine setups, but the specifics
On Thu, Mar 1, 2018 at 4:43 AM, Peter Eisentraut
wrote:
> On 2/27/18 00:56, Thomas Munro wrote:
>> FWIW it passes for me if I add this:
>>
>> +elsif ($^O eq 'freebsd')
>> +{
>> + $krb5_bin_dir = '/usr/local/bin';
>> + $krb5_sbin_dir = '/usr/local/sbin';
>
> I suppose you only need the
On 2/27/18 00:56, Thomas Munro wrote:
> FWIW it passes for me if I add this:
>
> +elsif ($^O eq 'freebsd')
> +{
> + $krb5_bin_dir = '/usr/local/bin';
> + $krb5_sbin_dir = '/usr/local/sbin';
I suppose you only need the second one, right? The first one should be
in the path.
> +}
>
>
On Thu, Feb 15, 2018 at 3:27 AM, Peter Eisentraut
wrote:
> Here is a patch with a test suite for the Kerberos/GSSAPI authentication
> functionality. It's very similar in principle to the recently added
> LDAP tests, and similar caveats apply.
+not run by default. You might need to adjust some p
On Wed, Feb 14, 2018 at 09:27:04AM -0500, Peter Eisentraut wrote:
> Here is a patch with a test suite for the Kerberos/GSSAPI authentication
> functionality. It's very similar in principle to the recently added
> LDAP tests, and similar caveats apply.
>
> You will need the client and server parts
Here is a patch with a test suite for the Kerberos/GSSAPI authentication
functionality. It's very similar in principle to the recently added
LDAP tests, and similar caveats apply.
You will need the client and server parts of a krb5 package
installation, possibly named krb5-workstation and krb5-se
25 matches
Mail list logo
