Re: ipropd slow when pushing complete database

On Thu, Dec 20, 2018 at 09:40:39AM +0100, Harald Barth wrote: > Have you considered that this could be a problem with TCP packet sizes and > Nagle's algorithm? https://en.wikipedia.org/wiki/Nagle%27s_algorithm > > We have identified back in 2015 that kadmin get * is slow because of > this and I

Re: ipropd slow when pushing complete database

On Wed, Dec 19, 2018 at 07:35:23PM -0500, Jeffrey Altman wrote: > If the statement that transfers took 10s with 7.1 and Jessie is > accurate, then the expected time should be 10s. > > Nico replied with a list of changes that are present on the "master" > branch which will speed up writes by

Re: ipropd slow when pushing complete database

Hi, you need the commits from master listed below (which will be in 8.0), which disable sync writes whild doing bulk HDB loads. It's the per-record fsync()s that kill performance. If you copied the HDB with scp and loaded it with kadmin -l, you'd find it's still slow -- the network has nothing

Re: How krb5.conf is parsed (especially in respect to comments)

On Mon, Mar 26, 2018 at 09:26:11PM +0200, Harald Barth wrote: > > A value string is all of the contents to the right of the equal sign > > until the end of line. > > To the right of the equal sign and any following whitespace. So it > seems one can have whitespace inside the value but no value

Re: iprop: Problem forcing complete database sync

On Thu, Oct 12, 2017 at 05:38:32PM +0200, Patrik Lundin wrote: > On 2017-10-06 10:03:37, Nico Williams wrote: > > Trungcating the log is not the same thing as resetting it, and preserves > > the version number. > > To summarize this tread: The --reset flag should

Re: iprop: Problem forcing complete database sync

On Mon, Oct 9, 2017 at 3:40 PM Nico Williams <n...@cryptonector.com> wrote: > On Mon, Oct 9, 2017 at 3:19 AM Harald Barth <h...@kth.se> wrote: > >> >> Have I got this right? >> >> 1. Does write_dump(context, s, database, current_version) always wr

Re: iprop: Problem forcing complete database sync

On Mon, Oct 9, 2017 at 3:19 AM Harald Barth wrote: > > Have I got this right? > > 1. Does write_dump(context, s, database, current_version) always write > a comptele dump no matter the value of current_version? > > 2. Does write_dump(context, s, database, current_version) only use >

Re: iprop: Problem forcing complete database sync

We're going to revisit the when-to-send_complete() logic. We've had one case where a slave was stuck doing repeated send_completes. It's also problematic that send_complete() is synchronous and ipropd-master does not fork() and is not multi-threaded. We've seen a case where one send_complete

Re: iprop: Problem forcing complete database sync

On Fri, Oct 06, 2017 at 04:48:20PM +0200, Patrik Lundin wrote: > On 2017-10-06 09:29:33, Jeffrey Hutzelman wrote: > > It shouldn't be needed. First, a full dump is automatically triggered > > if the master doesn't have enough log entries to bring the slave from > > its current version to the

Re: iprop: Problem forcing complete database sync

On Fri, Oct 06, 2017 at 09:29:33AM -0400, Jeffrey Hutzelman wrote: > On October 6, 2017 5:56:22 AM EDT, Harald Barth wrote: > It's also not necessary and in fact potentially harmful to check the > master's version for 0. A real database can never be at version 0, so > if you see

Re: iprop: Problem forcing complete database sync

Trungcating the log is not the same thing as resetting it, and preserves the version number.

Re: kinit error message (Heimdal 7.4.0)

On Thu, Oct 05, 2017 at 08:01:00PM +0200, Harald Barth wrote: > I may have found it! The 1.5.X KDC has a mile long function > _kdc_as_rep() which in the middle somewhere has > > e_text = "No ENC-TS found"; Ahh, ok, got it. Nico --

Re: kinit error message (Heimdal 7.4.0)

On Thu, Oct 05, 2017 at 10:37:26AM +0200, Harald Barth wrote: > I'm currently looking at why kinit can not give a decent error message > on the easy fact that a credential has expired. Well, now with 7.4.0 > it handles "password expired" but "principal expired" still gives: So, to reproduce just

Re: kinit error message (Heimdal 7.4.0)

On Thu, Oct 05, 2017 at 10:37:26AM +0200, Harald Barth wrote: > I'm currently looking at why kinit can not give a decent error message > on the easy fact that a credential has expired. Well, now with 7.4.0 > it handles "password expired" but "principal expired" still gives: > > kinit:

Re: Expired tickets not renewed

On Thu, Aug 10, 2017 at 09:24:08AM +0700, Victor Sudakov wrote: > 1. The 7.x kdc did not understand the heimdal.db Kerberos database > created by 1.5.2. Are they not compatible? What should I know about > this? Looking at differences in lib/hdb/hdb.asn1... they should be compatible. Is it

Re: Expired tickets not renewed

On Wed, Aug 09, 2017 at 03:06:37PM -0400, Roland C. Dowdeswell wrote: > It appears that Heimdal 1.5 had incorrect behaviour. The ccache code > should skip expired credentials when finding service tickets. This looks > like it was fixed by the following commit: > > commit

Re: Expired tickets not renewed

On Wed, Aug 09, 2017 at 03:01:16PM -0400, Jeffrey Altman wrote: > I hope this is an unnecessary question, but will all Kerberos libraries > that parse the file cache know to skip the expired entries and keep > searching? Or are there implementations that will only return the first > service

Re: Expired tickets not renewed

On Wed, Aug 09, 2017 at 01:44:56PM -0500, Nico Williams wrote: > We do need to re-think re-initialization in the new locking regimen -- > re-init via truncation probably works well enough right now, but mostly > by accident. Ah, right, we never do that.

Re: Expired tickets not renewed

On Wed, Aug 09, 2017 at 06:34:27PM +, Viktor Dukhovni wrote: > On Wed, Aug 09, 2017 at 01:11:07PM -0500, Nico Williams wrote: > > On Wed, Aug 09, 2017 at 06:01:26PM +, Viktor Dukhovni wrote: > > > On Wed, Aug 09, 2017 at 07:34:15PM +0200, Harald Barth wrote: > > &

Re: Expired tickets not renewed

On Wed, Aug 09, 2017 at 02:25:11PM -0400, Roland C. Dowdeswell wrote: > On Wed, Aug 09, 2017 at 01:11:07PM -0500, Nico Williams wrote: > > Actually, no, the FILE ccache does support deletion, certainly in > > Heimdal 7.x. > > Well, we can invalidate entries but I don't thi

Re: Expired tickets not renewed

On Wed, Aug 09, 2017 at 06:01:26PM +, Viktor Dukhovni wrote: > On Wed, Aug 09, 2017 at 07:34:15PM +0200, Harald Barth wrote: > > > Btw, one of my ticket caches looks like this (probably MIT library): > > > > IssuedExpires Principal > > Aug 5 18:06:47 2017

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

On Mon, Jun 26, 2017 at 11:18:28AM +0200, Andreas Haupt wrote: > Heimdal 7.3 seems to suffer from a bug in privilege checking. A prinicipal > having all rights on the database is unable to extract keytabs: This is on purpose. We decided that it was never a good idea for "all" to have meant

Re: Re-encrypt on change of master key

On Tue, Mar 14, 2017 at 03:54:36PM -0700, Adam Lewenberg wrote: > If you use a master key and you back up all your files _except_ the master > key to some remote location, wouldn't that suffice to protect the database > in that remote location? No. The problem is that the master key is not used

Heimdal 7 Release candidate 3

On Wed, Dec 14, 2016 at 03:03:32PM -0500, viktor.dukho...@twosigma.com wrote: > Please test this release. If no significant issues are found, this will > become Heimdal 7.1 on Monday 19/Dec/2016. We had some issues with make dist, so we made an rc3. The 7.1 target release date is unchanged.