[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: iprop problem
> As to where you keep the keytab, it's just a matter of how many
> people do you want to access it? Your ssh daemon has no business
> seeing the key for the iprop service and vice versa.
Right, but since ssh daemon runs as root, there's no place I can hide the
iprop keytab from him. I try not to run daemons as root, but you managed
to pick one of the three daemons I *do* run as root: heimdal, ssh and
nfsd.
> Did you delete the /var/heimdal/heimdal.log file as part of the
Which log is this, the binary or the text log? Debian keeps the binary
log (the one replayable by replay_log) in /var/lib/heimdal-kdc/log and
Heimdal also logs through syslog to someplace in /var/log. I assume you
mean the former.
If I assume correctly, then yes, I did. If I assume incorrectly, then no,
I didn't.
> reset? A new slave should not have any log file to replay. It
> should simply download a complete fresh copy of the DB, and
> initialize the log file to 24 bytes, containing a no-op with the
> current DB version number. In other words, even after a real init, a
> replay should only consist of a single operation that could fail.
About a second after starting iprop slave, the binary log file is
970370 bytes long (and still growing as I write this).
And the non-binary log in /var/log again contains huge numbers of "Entry
already exists" and "Decrypt integrity failed" -messages.
> > UNKNOWN -- juhaj/admin@TFY.UTU.FI: Decrypt integrity check failed
> Is this error on the master or the slave? This looks like an
> ordinary user bad password error. Iprop would be using iprop/*
> principals, not juhaj/* principals.
This is on the slave, talking to itself to get a ticket and yes, it is an
ordinary user kinit, but the password supplied was certainly correct.
> Sounds like at least the master DB is fine. Do you have a copy of
> the master key file on the slave? The slave needs to be able to
> decrypt the DB to use it, just as the master does.
I do. (Though I thought I would not need it: I thought iprop decrypts the
data it sends, uses a session key to re-enrypt the data for transit over
the wire, slave decrypts and again re-encrypts before it puts it in the
DB. Otherwise, if I had an unencrypted DB on disc, iprop would transfer
the data unencrypted over the wire. Of course iprop could just encrypt
the already encrypted data... I really don't know, I'm guessing.)
> No you don't want to just copy the DB over because there's other
So I won't. =) Thanks for warning me!
-Juha
--
-----------------------------------------------
| Juha Jäykkä, juolja@utu.fi |
| home: http://www.utu.fi/~juolja/ |
-----------------------------------------------
--Sig_H0AfHOhC.Xz6Kp9wsd8HqXk
Content-Type: application/pgp-signature; nameÂgnature.asc
Content-Disposition: attachment; filenameÂgnature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFSlBJSqzK5nsyX0kRAkB/AKCX2uJroHSGe/vK/Co2SIQaSViVawCeNVq/
/2eZVFYLFnLmIlQrKayZ7bU"rr
-----END PGP SIGNATURE-----
--Sig_H0AfHOhC.Xz6Kp9wsd8HqXk--