Is there a protocol you all follow to be safe with incremental propagation?
Like doing Full Sync, every now and then, maybe once a day or once a week?
Can the ulog or God forbid the database get clobbered corrupted and get
replicated everywhere?? that would be huge problem, but I cant imaging
Well! we had a theory based on facts, that the last 1 update from the master
KDC blew all other replicas out of the water!
So I performed a "kproplog -R” got reset log and perform a Full Sync. Restarted
kprop and what do you know, the incrementals started working and kprop never
crashed again!
Tareq Alrashid writes:
> RHEL 7.7
>
> 2am all of a sudden all my replicas kpropd process crashed with a core
> dump. Nothing has changed!
If you're running RHEL, I recommend you open a support case. That's
what you pay us for :)
> systemctl status kprop.service
>
> kprop.service: main proces
RHEL 7.7
2am all of a sudden all my replicas kpropd process crashed with a core dump.
Nothing has changed!
systemctl status kprop.service
kprop.service: main process exited, code=dumped, status=6/ABRT
Feb 20 09:35:13 kerb-replica systemd[1]: Unit kprop.service entered failed
state.
Feb 20
Since my last message, I came across the documentation part were it mentions
the iprop_slave_poll.
We’re running Kerberos 5 release 1.15.1! - Will make the proper change and the
test results should make more sense!
Thanks Greg.
> On Jan 12, 2020, at 5:54 PM, Greg Hudson wrote:
>
> On 1/10/
On 1/10/20 8:22 PM, Tareq Alrashid wrote:
> Maybe I am missing something but changing the kdc.conf to any value...
>
> iprop_replica_poll=1s
> or even...
> iprop_replica_poll = 0.017m
> (for 1s= 1/60min!)
>
> Based on tailing the kadmind.log, it is showing the replica polling
> ev
> You can assign a value as low as one second.
Maybe I am missing something but changing the kdc.conf to any value...
iprop_replica_poll=1s
or even...
iprop_replica_poll = 0.017m
(for 1s= 1/60min!)
Based on tailing the kadmind.log, it is showing the replica polling every 2m!?
>
Thanks Greg.
Final question if there is any negative impact for having replicas poll at
often as one second or maybe it is best to be at higher numbers of seconds?
On Thu, Jan 9, 2020 at 11:24 Greg Hudson wrote:
> On 1/8/20 1:38 PM, Tareq Alrashid wrote:
> > How can we make it as close to realti
On 1/8/20 1:38 PM, Tareq Alrashid wrote:
> How can we make it as close to realtime as possible?
> what is the smallest value possible we can assign?
You can assign a value as low as one second.
> Master receives a newly provisioned user, or new password change/reset, and
> since we live in the
Ah, OK. I cannot answer whether 2m is the minumum value.
Cheers,
Kenny.
On Thu, 2020-01-09 at 09:26 -0500, Tareq Alrashid wrote:
> Thanks for the reply, Kenny.
>
> I have left out an important detail, on campus of course all is
> configured to master KDC first, the kerb2/kerb3…etc., no problem
Thanks for the reply, Kenny.
I have left out an important detail, on campus of course all is configured to
master KDC first, the kerb2/kerb3…etc., no problem.
This affects users of our clouds services, for example in AWS where we have
duplicated all/most of our infrastructure services, if a use
On Wed, 2020-01-08 at 13:38 -0500, Tareq Alrashid wrote:
> How can we make it as close to realtime as possible?
> what is the smallest value possible we can assign?
>
> Background:
>
> Master receives a newly provisioned user, or new password
> change/reset, and since we live in the instant-grat
How can we make it as close to realtime as possible?
what is the smallest value possible we can assign?
Background:
Master receives a newly provisioned user, or new password change/reset, and
since we live in the instant-gratification times, users attempt to login onto
services that configured
13 matches
Mail list logo
