Back to bug 1220791
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Pavel Stehlik | 2015-05-18 11:32:49 UTC | Depends On | 1217402 | |
| Link ID | oVirt gerrit 40818 | |||
| Status | NEW | POST | ||
| CC | pstehlik | |||
| Tal Nisan | 2015-05-18 14:43:10 UTC | Status | POST | MODIFIED |
| CC | tnisan | |||
| Yedidyah Bar David | 2015-05-19 07:41:54 UTC | Doc Text | Cause: engine-backup used pg_dump's default, which is to dump (also) ownership of objects and grants on them to other users. Consequence: If the dump included grants to users that existed on the backed up database, but do not exist on the database we restore to, restore will fail. Fix: engine-backup now does not backup or (try to) restore any ownership/grants, so only the defaults apply (each db user owns the objects in its schema, and no other user has access to them). Result: restore now succeeds even if the database that was backed up had extra users with grants on one or more of the applications' objects. These are not restored, and the user should manually reconfigure these if relevant. Note to doc team: In 3.3 (only), dwh setup asked whether to create a read-only db user allowing remote access to the dwh database. In 3.4 and later, we did not have similar functionality. In 3.2, we also didn't have it, but we did have instructions [1] about how to do that manually. We might want to write something similar for 3.4+, perhaps as a KB article. Note that 3.4 requires a bit more manual configuration than 3.5 - 3.5 configures postgresql.conf 'listen_address=*', which 3.4 does not. In any case, as explained above, such users, whether created manually or by 3.3's dwh-setup (which was later upgraded), are not backed up or restored by engine-backup. [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.2/html/Administration_Guide/Allowing_Read_Only_Access_to_the_History_Database.html |
|
| Sandro Bonazzola | 2015-07-01 15:24:10 UTC | Status | MODIFIED | ON_QA |
| Jiri Belka | 2015-07-14 14:44:21 UTC | Status | ON_QA | ASSIGNED |
| Yedidyah Bar David | 2015-07-14 16:53:25 UTC | CC | jbelka | |
| Flags | needinfo?(jbelka) | |||
| Jiri Belka | 2015-07-15 13:55:17 UTC | CC | pm-rhel | |
| Flags | needinfo?(jbelka) | needinfo?(pm-rhel) | ||
| Sandro Bonazzola | 2015-07-15 14:50:10 UTC | Flags | needinfo?(pm-rhel) | needinfo?(ydary) |
| Yaniv Lavi | 2015-07-21 22:35:05 UTC | Target Release | 3.5.4 | 3.5.5 |
| Flags | needinfo?(ydary) | |||
| Yedidyah Bar David | 2015-07-22 06:20:53 UTC | Flags | needinfo?(ydary) | |
| Yaniv Lavi | 2015-07-23 07:47:37 UTC | Flags | needinfo?(ydary) | |
| Sandro Bonazzola | 2015-08-04 07:27:24 UTC | Assignee | didi | sbonazzo |
| Flags | needinfo?(ydary) | |||
| Yaniv Lavi | 2015-08-09 15:38:51 UTC | Flags | needinfo?(ydary) | |
| Sandro Bonazzola | 2015-09-03 14:02:42 UTC | Assignee | sbonazzo | didi |
| Yedidyah Bar David | 2015-09-06 13:29:50 UTC | Flags | needinfo?(ydary) | |
| Sandro Bonazzola | 2015-09-18 06:11:55 UTC | Target Release | 3.5.5 | 3.5.6 |
| Sandro Bonazzola | 2015-09-21 13:06:11 UTC | Comment 0 is private | 1 | 0 |
| CC | bugs | |||
| Component | ovirt-engine-setup | Backup-Restore | ||
| Product | Red Hat Enterprise Virtualization Manager | ovirt-engine | ||
| Target Milestone | --- | ovirt-3.5.6 | ||
| QA Contact | jbelka | pstehlik | ||
| Red Hat Bugzilla Rules Engine | 2015-09-21 13:06:15 UTC | Flags | testing_ack? planning_ack? | |
| Sandro Bonazzola | 2015-09-21 13:06:51 UTC | Flags | ovirt-3.5.z? | |
| Sandro Bonazzola | 2015-09-21 13:07:18 UTC | QA Contact | pstehlik | jbelka |
| Yaniv Lavi | 2015-09-22 08:22:57 UTC | Flags | needinfo?(ydary) planning_ack? | planning_ack+ |
| Pavel Stehlik | 2015-09-29 07:42:06 UTC | Flags | testing_ack? | testing_ack+ |
| Red Hat Bugzilla Rules Engine | 2015-09-29 07:42:08 UTC | Flags | ovirt-3.5.z? | ovirt-3.5.z+ |
| Red Hat Bugzilla Rules Engine | 2015-10-19 10:58:00 UTC | Target Release | 3.5.6 | --- |
| Doron Fediuck | 2015-10-26 07:09:53 UTC | Target Release | --- | 3.5.7 |
| Target Milestone | ovirt-3.5.6 | ovirt-3.5.7 | ||
| Red Hat Bugzilla Rules Engine | 2015-10-26 14:34:11 UTC | Target Release | 3.5.7 | --- |
| Yedidyah Bar David | 2015-11-16 15:40:33 UTC | Doc Text | Cause: engine-backup used pg_dump's default, which is to dump (also) ownership of objects and grants on them to other users. Consequence: If the dump included grants to users that existed on the backed up database, but do not exist on the database we restore to, restore will fail. Fix: engine-backup now does not backup or (try to) restore any ownership/grants, so only the defaults apply (each db user owns the objects in its schema, and no other user has access to them). Result: restore now succeeds even if the database that was backed up had extra users with grants on one or more of the applications' objects. These are not restored, and the user should manually reconfigure these if relevant. Note to doc team: In 3.3 (only), dwh setup asked whether to create a read-only db user allowing remote access to the dwh database. In 3.4 and later, we did not have similar functionality. In 3.2, we also didn't have it, but we did have instructions [1] about how to do that manually. We might want to write something similar for 3.4+, perhaps as a KB article. Note that 3.4 requires a bit more manual configuration than 3.5 - 3.5 configures postgresql.conf 'listen_address=*', which 3.4 does not. In any case, as explained above, such users, whether created manually or by 3.3's dwh-setup (which was later upgraded), are not backed up or restored by engine-backup. [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.2/html/Administration_Guide/Allowing_Read_Only_Access_to_the_History_Database.html | Cause: engine-backup used pg_dump's default, which is to dump (also) ownership of objects and grants on them to other users. Consequence: If the dump included grants to users that existed on the backed up database, but do not exist on the database we restore to, restore will fail. Fix: engine-backup now does not backup or (try to) restore any ownership/grants, so only the defaults apply (each db user owns the objects in its schema, and no other user has access to them). Result: restore now succeeds even if the database that was backed up had extra users with grants on one or more of the applications' objects. These are not restored, and the user should manually reconfigure these if relevant. Note to doc team: In 3.3 (only), dwh setup asked whether to create a read-only db user allowing remote access to the dwh database. In 3.4 and later, we did not have similar functionality. In 3.2, we also didn't have it, but we did have instructions [1] about how to do that manually. I now see that we also have them in 3.5 [2]. We might want to write something similar for 3.4+, perhaps as a KB article. Note that 3.4 requires a bit more manual configuration than 3.5 - 3.5 configures postgresql.conf 'listen_address=*', which 3.4 does not. In any case, as explained above, such users, whether created manually or by 3.3's dwh-setup (which was later upgraded), are not backed up or restored by engine-backup. [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.2/html/Administration_Guide/Allowing_Read_Only_Access_to_the_History_Database.html [2] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/sect-History_Database.html#Allowing_Read_Only_Access_to_the_History_Database |
| Sandro Bonazzola | 2015-11-30 14:40:53 UTC | Blocks | 1286704 | |
| Sandro Bonazzola | 2015-11-30 14:44:04 UTC | Target Milestone | ovirt-3.5.7 | ovirt-3.6.2 |
| Flags | ovirt-3.5.z+ | ovirt-3.6.z? | ||
| Red Hat Bugzilla Rules Engine | 2015-11-30 14:44:07 UTC | Flags | ovirt-3.6.z? | ovirt-3.6.z+ |
| Yedidyah Bar David | 2015-12-01 13:02:33 UTC | Flags | needinfo?(ydary) | |
| Yaniv Lavi | 2015-12-02 10:26:32 UTC | Summary | [engine-backup] unable to restore if backup contains read only user for DWH DB access | [engine-backup] Add option to restore permissions in custom format and add note on no permissions dump on plain format. |
| Flags | needinfo?(ydary) | |||
| Yedidyah Bar David | 2015-12-02 15:20:18 UTC | Link ID | oVirt gerrit 49584 | |
| Status | ASSIGNED | POST | ||
| Sandro Bonazzola | 2015-12-18 06:49:07 UTC | oVirt Team | --- | Integration |
| Sandro Bonazzola | 2016-01-13 08:34:12 UTC | Status | POST | MODIFIED |
| Link ID | oVirt gerrit 51620 | |||
| Status | MODIFIED | POST | ||
| Status | POST | MODIFIED | ||
| Target Release | --- | 3.6.2.5 | ||
| QA Contact | jbelka | pstehlik | ||
| Pavel Stehlik | 2016-01-20 15:02:06 UTC | Status | MODIFIED | ON_QA |
| QA Contact | pstehlik | jbelka | ||
| John Skeoch | 2016-01-28 22:02:02 UTC | CC | ecohen | ykaul |
| Haoxing Wang | 2016-02-03 03:32:20 UTC | Whiteboard | integration | |
| Jiri Belka | 2016-02-04 17:46:34 UTC | Status | ON_QA | VERIFIED |
| Sandro Bonazzola | 2016-02-18 11:01:31 UTC | Status | VERIFIED | CLOSED |
| Resolution | --- | CURRENTRELEASE | ||
| Last Closed | 2016-02-18 06:01:31 UTC | |||
| Yedidyah Bar David | 2016-03-21 08:19:36 UTC | Doc Text | Cause: engine-backup used pg_dump's default, which is to dump (also) ownership of objects and grants on them to other users. Consequence: If the dump included grants to users that existed on the backed up database, but do not exist on the database we restore to, restore will fail. Fix: engine-backup now does not backup or (try to) restore any ownership/grants, so only the defaults apply (each db user owns the objects in its schema, and no other user has access to them). Result: restore now succeeds even if the database that was backed up had extra users with grants on one or more of the applications' objects. These are not restored, and the user should manually reconfigure these if relevant. Note to doc team: In 3.3 (only), dwh setup asked whether to create a read-only db user allowing remote access to the dwh database. In 3.4 and later, we did not have similar functionality. In 3.2, we also didn't have it, but we did have instructions [1] about how to do that manually. I now see that we also have them in 3.5 [2]. We might want to write something similar for 3.4+, perhaps as a KB article. Note that 3.4 requires a bit more manual configuration than 3.5 - 3.5 configures postgresql.conf 'listen_address=*', which 3.4 does not. In any case, as explained above, such users, whether created manually or by 3.3's dwh-setup (which was later upgraded), are not backed up or restored by engine-backup. [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.2/html/Administration_Guide/Allowing_Read_Only_Access_to_the_History_Database.html [2] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/sect-History_Database.html#Allowing_Read_Only_Access_to_the_History_Database | Cause: engine-backup used pg_dump's default, which is to dump (also) ownership of objects and grants on them to other users. Consequence: If the dump included grants to users that existed on the backed up database, but do not exist on the database we restore to, restore will fail. Fix: With custom (default) dump format, permissions are always saved, and during restore user must pass either --restore-permissions' or '--no-restore-permissions'. For default setups, there is no difference. It does make a difference if extra users/grants were added to the database after setup - in that case, if user wants to keep the grants, the user has to manually create the users prior to running restore. With plain dump format, permissions are never saved, and the user is notified with the following text: ##################################################################################################### Please note: permissions are not backed up with a plain dump format, thus not restored during restore ##################################################################################################### Note to doc team: In 3.3 (only), dwh setup asked whether to create a read-only db user allowing remote access to the dwh database. In 3.4 and later, we did not have similar functionality. In 3.2, we also didn't have it, but we did have instructions [1] about how to do that manually. I now see that we also have them in 3.5 [2]. We might want to write something similar for 3.4+, perhaps as a KB article. Note that 3.4 requires a bit more manual configuration than 3.5 - 3.5 configures postgresql.conf 'listen_address=*', which 3.4 does not. In any case, as explained above, such users, whether created manually or by 3.3's dwh-setup (which was later upgraded), are not backed up or restored by engine-backup with plain format, and with custom format user must choose whether to restore them or not. [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.2/html/Administration_Guide/Allowing_Read_Only_Access_to_the_History_Database.html [2] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/sect-History_Database.html#Allowing_Read_Only_Access_to_the_History_Database |
Back to bug 1220791