|
| 1 | +```bash |
| 2 | +pg_dumpall -d "$SOURCE" \ |
| 3 | + --quote-all-identifiers \ |
| 4 | + --roles-only \ |
| 5 | + --no-role-passwords \ |
| 6 | + --file=roles.sql |
| 7 | +``` |
| 8 | + |
| 9 | +<Highlight type="important"> |
| 10 | +AWS RDS does not permit dumping of roles with passwords, which |
| 11 | +is why the above command is executed with the `--no-role-passwords`. However, |
| 12 | +when the migration of roles to your Timescale instance is complete, you |
| 13 | +need to manually assign passwords to the necessary roles using the following |
| 14 | +command: `ALTER ROLE name WITH PASSWORD 'password';` |
| 15 | +</Highlight> |
| 16 | + |
| 17 | +Timescale services do not support roles with superuser access. If your SQL |
| 18 | +dump includes roles that have such permissions, you'll need to modify the file |
| 19 | +to be compliant with the security model. |
| 20 | + |
| 21 | +You can use the following `sed` command to remove unsupported statements and |
| 22 | +permissions from your roles.sql file: |
| 23 | + |
| 24 | +```bash |
| 25 | +sed -i -E \ |
| 26 | +-e '/CREATE ROLE "postgres";/d' \ |
| 27 | +-e '/ALTER ROLE "postgres"/d' \ |
| 28 | +-e '/CREATE ROLE "rds/d' \ |
| 29 | +-e '/ALTER ROLE "rds/d' \ |
| 30 | +-e '/TO "rds/d' \ |
| 31 | +-e '/GRANT "rds/d' \ |
| 32 | +-e 's/(NO)*SUPERUSER//g' \ |
| 33 | +-e 's/(NO)*REPLICATION//g' \ |
| 34 | +-e 's/(NO)*BYPASSRLS//g' \ |
| 35 | +-e 's/GRANTED BY "[^"]*"//g' \ |
| 36 | +roles.sql |
| 37 | +``` |
| 38 | + |
| 39 | +<Highlight type="note"> |
| 40 | +This command works only with the GNU implementation of sed (sometimes referred |
| 41 | +to as gsed). For the BSD implementation (the default on macOS), you need to |
| 42 | +add an extra argument to change the `-i` flag to `-i ''`. |
| 43 | + |
| 44 | +To check the sed version, you can use the command `sed --version`. While the |
| 45 | +GNU version explicitly identifies itself as GNU, the BSD version of sed |
| 46 | +generally doesn't provide a straightforward --version flag and simply outputs |
| 47 | +an "illegal option" error. |
| 48 | +</Highlight> |
| 49 | + |
| 50 | +A brief explanation of this script is: |
| 51 | + |
| 52 | +- `CREATE ROLE "postgres"`; and `ALTER ROLE "postgres"`: These statements are |
| 53 | + removed because they require superuser access, which is not supported |
| 54 | + by Timescale. |
| 55 | + |
| 56 | +- `(NO)SUPERUSER` | `(NO)REPLICATION` | `(NO)BYPASSRLS`: These are permissions |
| 57 | + that require superuser access. |
| 58 | + |
| 59 | +- `CREATE ROLE "rds`, `ALTER ROLE “rds`, `TO "rds`, `GRANT "rds`: Any creation |
| 60 | + or alteration of rds prefixed roles are removed because of their lack of any use |
| 61 | + in a Timescale instance. Similarly, any grants to or from "rds" prefixed roles |
| 62 | + are ignored as well. |
| 63 | + |
| 64 | +- `GRANTED BY role_specification`: The GRANTED BY clause can also have permissions that |
| 65 | + require superuser access and should therefore be removed. Note: Per the |
| 66 | + TimescaleDB documentation, the GRANTOR in the GRANTED BY clause must be the |
| 67 | + current user, and this clause mainly serves the purpose of SQL compatibility. |
| 68 | + Therefore, it's safe to remove it. |
0 commit comments