What options are there to stop people using Matrix for a short while, for example while we perform an upgrade? In the past we have just told people not to use it, but this method is risky in a distributed environment.
There are so many ways to edit pages that it would be difficult to create a simple redirect … and creating rules to catch _admin and _edit at the web server to just stop use of Matrix for a few minutes seems like overkill.
Maybe there is a flag that can be set somewhere that locks the system? Or somehow disabling the LDAP bridge? Or run a script that locks every asset for a period of time?
Hopefully someone has thought of a clean way of doing this that I am not aware of.
On the System Administration screen, just change the _admin and _edit aliases. 
That's what I usually recommend.
What effect would that have on people currently editing?
[quote]What effect would that have on people currently editing?
[right][post=“6729”]<{POST_SNAPBACK}>[/post][/right][/quote]
They would lose their changes. The commit would not work. This is why you should use the Active Locks screen to double-check that there are no active locks in the system before doing this.
You can also change the status of the whole Users folder to Under Construction and cascade. This will then prevent people from logging in.
For the people already logged in, remove all /path/to/matrix/cache/sess_* files. Anyone halfway through changes will be logged out when they commit, and the changes will be unsuccessful.
[quote][…] This is why you should use the Active Locks screen to double-check that there are no active locks in the system before doing this.
[right][post=“6730”]<{POST_SNAPBACK}>[/post][/right][/quote]
Silly question I’m sure, but where is the Active Locks screen?
[quote]Silly question I’m sure, but where is the Active Locks screen?
[right][post=“6742”]<{POST_SNAPBACK}>[/post][/right][/quote]
Click the “MAPS” button (logged in as root) in the top-righthand corner. In the drop-down box, select the “Active Locks” screen.
To ensure consistency between Filesystem and DB during a backup, we would halt the web publishing by switching the aliases as Avi suggested above.
- I am assuming that this can be done through a script, right?
- What happens to other things like a Squiz server job started before the alias switch?
- Is the Cron manager an issue if the backup (or any other action requiring the system to be read-only) takes more than 15mins?
- Anything else that should be taken into account?
- Yes. You could just change the main.inc file. However, the change is obviously immediate.
- A job running the Squiz Server should not be affected. Jobs running inside the browser will crash on the next reload of the browser window (as the URL will change).
- Cron is only an issue if a Job occurs during the backup window (i.e. a file goes live) that makes a write change to the filesystem/database. Cron Manager does update the DB every fifteen minutes though, but that has no filesystem equivalent.
- Not that I can think of. Most of my clients don't disable editing while the backup occurs, but that's usually because most backups occur at obscene times in the morning.
Custom forms are also an issue when trying to set Matrix to Read-only. Unfortunately there is no simple _edit or _admin to rename. Is there an easy (or what would be the approach) to disable user form submissions during that window?
PS: Reliable 'obscene' time don't always exists if your users are internationally spread… 
[quote]Custom forms are also an issue when trying to set Matrix to Read-only. Unfortunately there is no simple _edit or _admin to rename. Is there an easy (or what would be the approach) to disable user form submissions during that window?
[right][post=“8418”]<{POST_SNAPBACK}>[/post][/right][/quote]
There is no file system requirements for custom forms, so there is no reason to stop submissions during the backup: Any good database backup agent will allow you to backup a running database. Any submissions that are submitted after the backup occurs will be lost when restoring along with all other changes made after the backup.
Edited to add that you could also configure an email for every form submit so that you always have a record of all form submissions, even if they are lost by Matrix due to a restore.
True, FS write was the main concern. Oracle hot backup would take care of the rest with redo logs (I hear..).
Long time ago (about 12months now) when we were still discussing architecture and possible load balancing of Matrix with Greg and JP, custom forms came up as requiring FS write.
I am taking from what you are saying that it is not required anymore, right?
[quote]I am taking from what you are saying that it is not required anymore, right?
[right][post=“8431”]<{POST_SNAPBACK}>[/post][/right][/quote]
Yes. In terms of storing submissions on the filesystem, this used to be the case in version 3.2, but form submissions have been stored as assets since the 3.4-branch.
k, Forms are not a problem.
How about Asset Builder (e.g. for uploading files)?
[quote]How about Asset Builder (e.g. for uploading files)?
[right][post=“8578”]<{POST_SNAPBACK}>[/post][/right][/quote]
Yeah, if people are using an Asset Builder to upload files (images, pdfs, etc) then these are written to the database and file system at the same time.
The simplest way around this is to use “snapshot” style backup engines, where available. I.E., engines that can take a snapshot of the file system and database simultaneously, then backup the snapshot (instead of the live data).