Update from old Security Mode: Difference between revisions

From Zymonic
Content added Content deleted
(Created page with "Update Procedure: N.B. This procedure has been designed with minimum downtime; the UI should be fully usable up until the resecure step and largely useable (see the * below)...")
 
(Added missing detail and polished)
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
This procedure will migrate systems onto a new security model.
⚫
Update Procedure:


It covers updating from sec_id based records in zz_record_security to being in zz_[table name]_rs tables and limiting to one sec_id per 'target/permission' combination.
⚫
N.B. This procedure has been designed with minimum downtime; the UI should be fully usable up until the resecure step and largely useable (see the * below) until the 'update_fap' step. The full resecure takes approx 1 hour on July's P&P live data.


⚫
<b>Update Procedure:</b><br/>
⚫
Check if there are any systems with pure numeric sec_ids left, i.e., last config build before March 2013 (check timestamp of /etc/zymonic/[system]/cache/*) - if you identify systems with a last config build before that then check with ARM before continuing.
⚫
This procedure has been designed with minimum downtime; the UI should be fully usable up until the resecure step and largely useable (see the * below) until the 'update_fap' step. The full resecure takes approx 1 hour on July's P&P live data.


⚫
Check if there are any systems with pure numeric sec_ids left, i.e., last config build before March 2013 (check timestamp of /etc/zymonic/[system]/cache/*) - if you identify systems with a last config build before that then email developers@zednax.com to ask for guidance before continuing.
zymobuild


<ol>
<li>
Zymobuild
<pre>sudo zymobuild</pre>
</li><li>
Config build
Config build
⚫
<pre>sudo zymonic_toolkit.pl System config_build --system SYSTEM</pre>

</li><li>
resecure all tables (leaves them with entries in both tables)*
Resecure all tables (leaves them with entries in both tables)*

sudo zymonic_toolkit.pl Security resecure --system [system] --zname '*' --unsecured true --debugfile=/tmp/full_resecure.log
<pre>sudo zymonic_toolkit.pl Security resecure --system SYSTEM --zname '*' --unsecured true --debugfile=/tmp/full_resecure.log</pre>
</li><li>

run detect security mode
Run detect security mode
⚫
<pre>sudo zymonic_toolkit.pl System detect_record_security_modes --system SYSTEM --debugfile /tmp/detect_security.log</pre>

</li><li>
⚫
sudo zymonic_toolkit.pl System detect_record_security_modes --system [system] --debugfile /tmp/detect_security.log
⚫
Do a full update_fap

<pre>sudo zymonic_toolkit.pl System update_fap --system SYSTEM --full yes</pre>
⚫
do a full update_fap**
</li><li>

⚫
sudo zymonic_toolkit.pl System update_fap --system [system] --full yes

Config build
Config build
<pre>sudo zymonic_toolkit.pl System config_build --system SYSTEM</pre>

</li>
⚫
* If at all possible adding new entries / changing existing entries in tables that are connected to 'groups' e.g. eBex areas, regions, companies and P&P clients should be avoided from the beginning of resecure until the end of the final config build - if changes are made then an additional resecure after the last config build should solve any resulting issues.
</ol>
<div class="boxed">
⚫
If at all possible adding new entries / changing existing entries in tables that are connected to 'groups' e.g. eBex areas, regions, companies and P&P clients should be avoided from the beginning of resecure until the end of the final config build - if changes are made then an additional resecure after the last config build should solve any resulting issues.


From starting update_fap to completing the config build the system will be unusable as there will be no accessible pages and all the menus will be empty.
From starting update_fap to completing the config build the system will be unusable as there will be no accessible pages and all the menus will be empty.
</div>

Latest revision as of 16:18, 2 April 2019

This procedure will migrate systems onto a new security model.

It covers updating from sec_id based records in zz_record_security to being in zz_[table name]_rs tables and limiting to one sec_id per 'target/permission' combination.

Update Procedure:
This procedure has been designed with minimum downtime; the UI should be fully usable up until the resecure step and largely useable (see the * below) until the 'update_fap' step. The full resecure takes approx 1 hour on July's P&P live data.

Check if there are any systems with pure numeric sec_ids left, i.e., last config build before March 2013 (check timestamp of /etc/zymonic/[system]/cache/*) - if you identify systems with a last config build before that then email developers@zednax.com to ask for guidance before continuing.

  1. Zymobuild 
    sudo zymobuild
  2. Config build 
    sudo zymonic_toolkit.pl System config_build --system SYSTEM
  3. Resecure all tables (leaves them with entries in both tables)* 
    sudo zymonic_toolkit.pl Security resecure --system SYSTEM --zname '*' --unsecured true --debugfile=/tmp/full_resecure.log
  4. Run detect security mode 
    sudo zymonic_toolkit.pl System detect_record_security_modes --system SYSTEM --debugfile /tmp/detect_security.log
  5. Do a full update_fap 
    sudo zymonic_toolkit.pl System update_fap --system SYSTEM --full yes
  6. Config build 
    sudo zymonic_toolkit.pl System config_build --system SYSTEM

If at all possible adding new entries / changing existing entries in tables that are connected to 'groups' e.g. eBex areas, regions, companies and P&P clients should be avoided from the beginning of resecure until the end of the final config build - if changes are made then an additional resecure after the last config build should solve any resulting issues.

From starting update_fap to completing the config build the system will be unusable as there will be no accessible pages and all the menus will be empty.

Retrieved from "https://wiki.zymonic.com/wiki/Update_from_old_Security_Mode?oldid=772"