Re: [PATCH v20] GSSAPI encryption support
От | Stephen Frost |
---|---|
Тема | Re: [PATCH v20] GSSAPI encryption support |
Дата | |
Msg-id | 20190404162452.GM6197@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: [PATCH v20] GSSAPI encryption support (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCH v20] GSSAPI encryption support
|
Список | pgsql-hackers |
Greetings, * Tom Lane (tgl@sss.pgh.pa.us) wrote: > I wrote: > > Stephen Frost <sfrost@snowman.net> writes: > >> So I'm a bit surprised that it's taking 4 minutes for you. I wonder if > >> there might be an issue related to the KDC wanting to get some amount of > >> random data and the system you're on isn't producing random bytes very > >> fast..? > > > Not sure. This is my usual development box and it also does mail, DNS, > > etc for my household, so I'd expect it to have plenty of entropy. > > But it's running a pretty old kernel, and old Kerberos too, so maybe > > the explanation is in there somewhere. > > Same test on a laptop running Fedora 28 takes a shade under 5 seconds. > The laptop has a somewhat better geekbench rating than my workstation, > but certainly not 50x better. And I really doubt it's got more entropy > sources than the workstation. Gotta be something about the kernel. > > Watching the test logs, I see that essentially all the time on the RHEL6 > machine is consumed by the two > > # Running: /usr/sbin/kdb5_util create -s -P secret0 > > steps. Is there a case for merging the two scripts so we only have to > do that once? Maybe not, if nobody else sees this. I do think that mergeing them would be a good idea and I can look into that, though at least locally that step takes less than a second.. I wonder if you might strace (or whatever is appropriate) that kdb5_util and see what's taking so long. I seriously doubt it's the actual kdb5_util code and strongly suspect it's some kernel call. Thanks! Stephen
Вложения
В списке pgsql-hackers по дате отправления: