[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--