[midPoint] Systems temporarily offline

[Pavol Mederly]

Hello Petr,

let me try to answer your question. I do not have much experience in 
this area, but ... let me give the best I can.

_As for approach __*one*__("__set search timeout to 1ms in XML resource 
definition")_

> is hashed password delta safe this way?
If you mean the deltas with password change, that are being sent to the 
resource, I assume these are stored in "pending operations" with 
password encrypted (not hashed). So they should be re-applied after 
resource going online. But this would need to be tried.

_As for approach __*two*__("__set consistency/connectorErrorCriticality 
to ignore for generic, network and configuration")_

> will the deltas be cached?
I have no idea. This needs to be experimented with.

_As for approach __*three*__("delete resource object (and upload again 
afterward)")_

>   * will the deltas be cached?
>
Almost certainly not.
>
>   * how will the projections work?
>
They will not (AFAIK). The projector would simply loudly complain about 
the situation and won't do almost nothing.

_As for approach __*four*__("resource assigned only via inducements")_

This is really interesting idea.

>   * will the errors be gone?
>
I am not sure. I assume midPoint would try to remove now-obsolete (from 
its point of view) accounts from the users, and this would generate 
errors in itself.
>
>   * where to put the flag to?
>
It depends on how you would like to manage it. You could use e.g. a 
server file to signal this.
>
>   * how will assignemnts work in this enviroment? will shadows be
>     preserved?
>
Shadows will be probably deleted. Assignments will stay. After resource 
is online, they would get synchronized. (Except for passwords, if you do 
not store their values in user records.)

A colleague of mine suggested also an approach to create a fake resource 
with the same schema. Then, of course, changes would get redirected to 
it (so they would get lost, or needed to be manually synchronized). 
After original resource is online, a reconciliation would synchronize 
user objects with resource objects, except for passwords.

--

A second suggestion of him was to temporarily replace a connector with a 
manual one. I have almost no experiences in this area, so cannot tell if 
this could work. Probably yes. :)

---

> I think this is good candidate for wanted.evolveum.com 
> <https://wanted.evolveum.com>, if we can gather enough votes.
Probably so. I don't know much about this mechanism.


> On other side, I can't shatter the feeling that midPoint _should_have_ 
> this solved.
Definitely yes. But... there is a lot of things that midPoint "should 
have" solved. All of us are intensively working on them. You know :)

Best regards and nice Sunday :-)

-- 
Pavol Mederly
Software developer
evolveum.com


> Hi guys,
> I am looking for your experience with dealing with temporarily offline 
> systems.
>
> It means, we know they will be offline for week or so. We are trying 
> to find best way to deal with this. Why we are doing that - motivators:
>
>   * with system being offline, midpoint still tries to reach it
>   * this tries generate ERRORs, which clogs audit log
>   * plus, corresponding reconciliations and recomputes are delayed by
>     timeouts
>
>
> So far, we have developed three theoretical approaches, but *none 
> solves "too much errors in audit log" challenge*
>
> Approach one:
>
>   * set search timeout to 1ms in XML resource definition
>   * pros:
>       o changes are cached
>   * cons:
>       o admin unfriendly
>       o midPoint still generates timeout errors
>   * question:
>       o is hashed password delta safe this way?
>
> Approach two:
>
>   * set consistency/connectorErrorCriticality to ignore for generic,
>     network and configuration
>   * cons:
>       o admin unfriendly
>       o midPoint still generates timeout errors
>   * question:
>       o will the deltas be cached?¨
>
> Approach three:
>
>   * delete resource object (and upload again afterward)
>   * pros:
>       o admin friendly
>   * questions:
>       o will the deltas be cached?
>       o how will the projections work?
>
> Approcach four:
>
>   * resource assigned only via inducements
>   * inducements conditioned by flag "resourceXisOnline"
>   * pros:
>       o admin friendly
>   * cons:
>       o deltas are not probably cached
>   * question:
>       o will the errors be gone?
>       o where to put the flag to?
>       o how will assignemnts work in this enviroment? will shadows be
>         preserved?
>
>
> What are your experiences, guys?
> I think this is good candidate for wanted.evolveum.com 
> <https://wanted.evolveum.com>, if we can gather enough votes. On other 
> side, I can't shatter the feeling that midPoint _should_have_ this solved.
>
> --
>
> regards
>
> *Petr Gašparík*
> solution architect
>
> gsm: [+420] 603 523 860
> e‑mail: petr.gasparik at ami.cz <mailto:petr.gasparik at ami.cz>
>
> *AMI Praha a.s.*
> Pláničkova 11, 162 00 Praha 6
>
> tel.: [+420] 274 783 239 | web: www.ami.cz <https://www.ami.cz>
>
> AMI Praha a.s.
>
> Textem tohoto e‑mailu podepisující neslibuje uzavřít ani neuzavírá 
> za společnost AMI Praha a.s.
> jakoukoliv smlouvu. Každá smlouva, pokud bude uzavřena, musí mít 
> výhradně písemnou formu.
>
> Tento e‑mail je určen výhradně pro potřeby jeho adresáta/ů a může 
> obsahovat důvěrné nebo osobní
> informace. Nejste‑li zamýšleným příjemcem, je zakázáno jakékoliv 
> zveřejňování, zprostředkování
> nebo jiné použití těchto informací. Pokud jste obdrželi e‑mail 
> neoprávněně, informujte o tom prosím
> odesílatele a vymažte neprodleně všechny kopie tohoto e‑mailu včetně 
> všech jeho příloh. Nakládáním
> s neoprávněně získanými informacemi se vystavujete riziku právního 
> postihu.
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20190518/26c83e34/attachment.htm>