从Indico 1.2迁移到2.0
indico-migrate的Python项目详细描述
此脚本将Indico 1.2.x服务器的数据库迁移到2.0版。
迁移到Indico 2.0
请参阅Upgrade Guide了解 有关如何从Indico 1.2升级到2.0的说明。
迁移设置
migration命令接受一系列选项，必须根据当前的indico设置进行调整 不管你想用什么方式组织你的新装置。我们将逐一检查，请仔细阅读！
基本迁移命令包括：
$ indico-migrate <sqlalchemy-uri> <zodb-uri> [--rb-zodb-uri <rb-zodb-uri>]
sqlalchemy-uri
This is the URI of your new SQLAlchemy database. If it’s located in your local machine, it will look like this:
postgresql:///indicoOtherwise, it will be something like ^{tt2}$.
zodb-uri
This is the URI of your Indico 1.2 ZODB. It should normally look like this:
zeo://localhost:9675/indicoIf you’re running it on a remote server, it will become ^{tt4}$
You can also choose to access the database file directly, instead of going through the ZEO service:
file:///opt/indico/db/Data.fsThis is slightly slower than the previous option but can be very useful if all you have is a database file and you don’t want to set up a ZEO server.
--rb-zodburi（可选）
This option only applies if you were running Indico’s Room Booking system and wish to migrate room and reservation information. The URI follows the same rules of ^{tt3}$. In most cases it will be something like:
zeo://localhost:9676/indico
接下来是以下列表中的相关选项：
--system-user-id（可选）
The “system user” is a user that performs automatic operations and which will also be used whenever, during the migration process, Indico doesn’t manage to figure out who was responsible for a given action.
For instance, in Indico < 2.0 we were not keeping track of whoever submitted a paper revision. In 2.0 that is enforced, which is why during the migration we set all revisions as if they were authored by the system user.
If you already had an Indico user that you were using for “bot” actions, you can specify its (numeric) ID using this option. If that’s not the case, you can safely ignore it and a new user will be created automatically.
Example:
$ indico-migrate postgresql:///indico2 zeo://127.0.0.1:9675 -v
--default-email（必需）
This is an e-mail address that will be used whenever Indico finds invalid addresses it cannot correct. Unfortunately, really old versions of Indico didn’t validate e-mail addresses that well, which is why we need a placeholder e-mail to use in case we find an address we cannot understand. E.g. ^{tt9}$.
--ldap-provider-name（可选）
This is the name of the LDAP provider that will be used in your new config. Existing LDAP identities will be mapped to it. The best choice at this point is to set it to something like ^{tt11}$ (e.g. ^{tt12}$). Write down this choice, you will need it when configuring Indico 2.0.
--default-group-provider（必需）
This is the name of the LDAP provider that will be used to resolve any groups in your new config. Existing LDAP groups will be mapped to the provider with this ID. It will be almost always the same value as that of ^{tt10}$. Once again, write it down, you will need it when configuring Indico 2.0.
--archive-dir（必需）
This is the ^{tt16}$ that was set in your old ^{tt17}$ (in version 1.2).
--storage-backend（必需）
This is the name of the storage backend where migrated files will be kept. This option was added since in Indico 2.0 you will be able to set more than one storage backend (thus being able to split your files across different folders and even storage technology). The setup process needs to know the ID you will give to the storage backend where files imported from 1.2 will be kept. Since the directory structure changes slightly in 2.0, we recommend that you set this to something like ^{tt19}$. Whatever you choose, write it down since you’ll need it when configuring 2.0.
--symlink-target和--symlink-backend（可选）
These two options are closely related and require each other.
The sanitization of file names was quite poor in some early versions of Indico. This could lead to files with non-UTF8 names, which would be difficult for Indico 2.0 to deal with. Instead of renaming those files (which is not as simple as it may seem), we chose to instead symlink them and store the name of the link instead. If these options are specified, symlinks to weirdly-named files will be kept in the directory indicated by ^{tt20}$. They will be associated with the storage backend ID specified in ^{tt21}$.
NOTE: This means that in the ^{tt24}$ option of your new ^{tt17}$ you will have something like:
STORAGE_BACKENDS = { ... 'fs-legacy-symlinks`: '/opt/indico/archive/legacy-symlinks' }
--photo-path（可选）
If ^{tt27}$ was specified, this is an optional directory (path) where Indico will be able to find photos of each room. Indico will look inside two directories: ^{tt28}$ (thumbnails) and ^{tt29}$ and import existing files (^{tt30}$) into the database.
--reference-type（可选，多个）
If you were storing “Report Numbers” (now known as “External References”), specify here the IDs of the systems that were being used. Those should correspond to the keys in your ^{tt32}$ dictionary (Indico 1.2 config). The result should be somethink like ^{tt33}$
--default-currency（必需）
This is the code of the currency unit that will be used by default in your server. E.g. ^{tt35}$ or ^{tt36}$.
--ignore-local-accounts（可选标志）
This option is meant for servers that were at some point using local accounts (username + password) but have since adopted another authentication method (LDAP + SSO, for instance). If you don’t need local accounts anymore and don’t want to move the old usernames and password to the new DB (which is probably a good idea), then set this option. This will also save you some migration time.
--migrate-broken-events（可选标志）
This option will import events that were previously broken due to not being associated with a valid category. Such events usually only exist if the old database had events imported from CDSAgenda. If this flag is enabled and any such events exist, a new top-level category named ‘Lost & Found’ will be created and the events stored in there.
其他设置
这些较少使用的设置主要用于调试目的。你通常不应该用它们除非你知道 你在干什么。
--no-gui（可选标志）
This option will disable the curses-like “graphical” interface, using plain text instead.
--verbose（可选标志）
This flag increases the verbosity of the Indico migration command. The amount of information can be overwhelming.
--dblog（可选标志）
If this option is specified, the migration command will contact the Indico DB logger running in the local machine and log every request that is made to the PostgreSQL server.
--debug（可选标志）
This option will launch the migration in debug mode, which means that the user will be given a debugger shell when something goes wrong.
--avoid-storage-check（可选标志）
DANGER! By specifying this option, you’re telling Indico it doesn’t need to check if a file really exists when migrating it. This will result in a faster migration but as well in possible data inconsistency and incomplete information.
--save-restore（可选标志）
This option triggers a dump of all intermediate migration data that is kept in memory to a file on disk, called ^{tt45}$, whenever the migration fails. This allows the process to be resumed from the point at which it failed.
--restore-file（可选标志）
DANGER! This option takes a file path as argument. The file in question should be a dump proced with ^{tt44}$ and which will be loaded to memory. The global migration steps that had been performed at the time of the failure will be skipped.
欢迎加入QQ群-->： 979659372
