You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+99-4Lines changed: 99 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,7 +23,7 @@ This project provides a virtual machine wherein it hosts the local REDCap instan
23
23
24
24
### Packaging and Deployment
25
25
26
-
The packaging and deployment tools are designed to deploy REDCap to Debian Linux hosts. They may or may not work with non-Debian REDCap hosts. They cannot deploy REDCap to Windows hosts. The packaging and deployment tools are written using the [Fabric](http://www.fabfile.org/) system. Fabric is written in Python3, so both Python 3 and Fabric3 must be installed to do packaging and deployment.
26
+
The packaging and deployment tools are designed to deploy REDCap to Debian Linux hosts. They may or may not work with non-Debian REDCap hosts. They cannot deploy REDCap to Windows hosts. The packaging and deployment tools are written using the [Fabric](http://www.fabfile.org/) system. The tools use Fabric 1.x
27
27
28
28
29
29
## Installing dependencies
@@ -117,7 +117,7 @@ After about two minutes, the VM should be accessible at the value of the variabl
117
117
118
118
## (Re)deploying REDCap with Fabric Tools
119
119
120
-
In addition to the REDCap deployed by the Vagrant provisioning scripts, this repository includes a suite of deployment and upgrade tools that can configure a host for deployment, package REDCap with numerous extensions, deploy a new REDCap instance and upgrade an existing one. You can use these commands any host where you have sufficient privileges or against this vagrant-deployed VM.
120
+
In addition to the REDCap deployed by the Vagrant provisioning scripts, this repository includes a suite of deployment and upgrade tools that can configure a host for deployment, package REDCap with numerous extensions, deploy a new REDCap instance and upgrade an existing one. You can use these commands on any Linux host where you have sufficient privileges or against this vagrant-deployed VM.
121
121
122
122
### Fabric Prerequisites
123
123
@@ -127,6 +127,14 @@ This tool is written in Python 3 and uses Fabric 1.x methods. To use it, make su
127
127
pip install 'fabric<2.0'
128
128
```
129
129
130
+
If you make a mess of things before you get it right, you might have to uninstall the mess like this:
131
+
132
+
```bash
133
+
brew uninstall fabric
134
+
pip uninstall 'fabric<2.0'
135
+
pip install 'fabric<2.0'
136
+
```
137
+
130
138
131
139
### Configure Fabric for the Virtual Machine
132
140
@@ -277,6 +285,54 @@ sudo a2enmod php8.1
277
285
sudo systemctl restart apache2
278
286
```
279
287
288
+
### Upgrade PHP from 7.4 to 8.2
289
+
290
+
```bash
291
+
# Upgrade PHP from 7.4 to 8.2
292
+
sudo apt install -y libapache2-mod-php8.2 \
293
+
php8.2 \
294
+
php8.2-cli \
295
+
php8.2-common \
296
+
php8.2-curl \
297
+
php8.2-gd \
298
+
php8.2-imap \
299
+
php8.2-mbstring \
300
+
php8.2-mysql \
301
+
php8.2-odbc \
302
+
php8.2-opcache \
303
+
php8.2-readline \
304
+
php8.2-soap \
305
+
php8.2-xml \
306
+
php8.2-zip
307
+
308
+
cd /etc
309
+
sudo -E git add .
310
+
sudo -E git commit -m "Commit PHP upgrades and other files"
sudo -E git commit -m "Install php-imagick and adjust policy to REDCap requirements"
329
+
330
+
# Switch to new PHP in Apache
331
+
sudo a2dismod php7.4
332
+
sudo a2enmod php8.2
333
+
sudo systemctl restart apache2
334
+
```
335
+
280
336
### Install specific PHP packages
281
337
282
338
On some hosts, you might need to install a specific packages. At UF, we have one host we call "warrior" that needs the `mpdf` package. To install a custom package, first, install `composer`
@@ -296,8 +352,8 @@ Then run these steps in the current redcap Libraries directory as user deploy
296
352
297
353
```bash
298
354
sudo su - deploy
299
-
#cd /var/https/stage_c/redcap_v13.4.11/Libraries/
300
-
cd /var/www/prod/redcap_v13.4.11/Libraries/
355
+
#cd /var/https/stage_c/redcap_v14.3.14/Libraries/
356
+
cd /var/www/prod/redcap_v14.6.2/Libraries/
301
357
```
302
358
303
359
Then run `composer require` with the package you need install:
@@ -313,6 +369,45 @@ Restart apache when you are done
313
369
sudo service apache2 restart
314
370
```
315
371
372
+
## Failed SQL upgrades
373
+
374
+
If an upgrade operation fails on a `.php` or a `.sql` file, the code will die like this:
375
+
376
+
```
377
+
[redcap.ctsi.ufl.edu] run: php /var/https/redcap/redcap_v14.1.3/generate_upgrade_sql_from_php.php /var/https/redcap/redcap_v14.1.3/Resources/sql/upgrade_14.01.01.php | mysql
378
+
[redcap.ctsi.ufl.edu] out: ERROR 1553 (HY000) at line 5: Cannot drop index 'redcap_userid': needed in a foreign key constraint
379
+
[redcap.ctsi.ufl.edu] out:
380
+
381
+
382
+
Fatal error: run() received nonzero return code 1 while executing!
383
+
384
+
Requested: php /var/https/redcap/redcap_v14.1.3/generate_upgrade_sql_from_php.php /var/https/redcap/redcap_v14.1.3/Resources/sql/upgrade_14.01.01.php | mysql
At this point things get messy and you will have to get creative in your problem solving. What follows is not a recipe. It's more like a pile of ingredients from which you could make an omelette. It's still your responsibility cook them right and not burn the omelette, because you're gonna have to eat it.
392
+
393
+
### Debugging
394
+
395
+
You can see the output of the script/SQl file that caused the by running that PHP command or catting out that SQL file that failed. e.g.,
Running the SQL lines in that file one by one might help you understand which one failed. It's challenging because some of those commands will fail because they _did_ run successfully the first time, but they will error the second time. This often happens when a SQL command added an object that cannot be "re-added". Think carefully about the responses you see when running each command. Read the REDCap community forum to see if others have experienced the errors you see and have a solution.
402
+
403
+
Even if that task goes well and you can apply the file that failed there might be more files to run after that one. You can locate those by enumerating the files in the `redcap_vN.M.O/Resources/sql/` directory. Look for versioned file names that are higher than the version number on which the script failed. If this seems tedious, you might want to try the next procedure.
404
+
405
+
406
+
### Ask REDCap to help you
407
+
408
+
Another approach is to generate all of the SQL upgrade commands between the version you are at and the version you are upgrading to by accessing the Upgrade page in the Control Center. It will make the whole blob, running the PHP scripts, concatenating their output with the SQL files and appending the lines that document the upgrade. All that's pretty useful. Do be aware that every SQL line that succeeded will still be in the blob of SQL the Control Center Upgrade page generates for you. It's more content to wade through, but it's all in one file with the last three "upgrade event" statements.
409
+
410
+
If you think you are done with the upgrade process, put the host back online via the Control Center _General Configuration_ page. Then check the Control Center _Configuration Check_ age for any SQL commands that still need to be applied.
0 commit comments