Version 3 (modified by 8 years ago) (diff) | ,
---|
We use the Drupal Content Management System (CMS) for https://www.clarin.eu. A general, brief overview of Drupal.
Development follows a three-stage workflow:
- development: tst.clarin.eu?
- staging/acceptance: staging-www.clarin.eu?
- production: www.clarin.eu?
Drupal should be managed from the command line with Drush. Commands for drush.
1. Current issues (2016)
Below are the most pressing issues (defects, misconfigurations, etc.) at hand. These do not include functionality enhancements that are in the pipeline.
1.1. Migrate from multisite setup (multiple directories in sites
) to single site setup.
Reasons:
- Multisite leads to multiple
settings.php
files and multiple databases for various specificsites
. - With multisite, it is not clear which content resides where. (e.g. in
sites/default/
,sites/all/
orsites/clarin.eu/
?) - Multisite leads to unclarity about which sites are actually used and active.
- Multisite backup has caused issues with
drush archive-dump
backup: stale sites with incorrectsettings.php
files (e.g. MySQL credentials). drush
in general can only deal with specific sites, specified by the--uri
parameter. This parameter does not correspond one-to-one to a site directory. For example, http://www.clarin.eu actually matchesclarin.eu/
, but only hopefully/apparently.
1.2. Create fresh and clean Drupal installation
Current problems:
install.php
still accessible (major security risk!?). In case the website is misconfigured in any way, or if the MySQL table is not accessible, then an install page was offered publically.- Editor temp files (e.g.
*.swp
) lingering around in thehtdocs/
root directory. These give public access to contents without reason. - Many potentially outdated README-type documents lingering around.
1.3. Use different passwords for Unix root, Drupal admin and MySQL database
Currently, a single password is used, which means that e.g. drush archive-restore
has the password to not only the relevant MySQL database (as set in settings.php
) but the global MySQL root password. Since drush
has design flaws, this is risky. It has proven to overwrite the MySQL root user password during backup restoration. If someone gets Drupal's settings.php
file (e.g. because of .htaccess
problem) and can exploit any PHP/Drupal bug or misconfiguration, he can root the entire OS.
1.4. Update each module piece by piece, not just for security issues
We should use only stable versions of third pardty modules. Furthermore, we should cut down the number of modules insofar possible.
Current problems:
- Development versions (betas and even alphas) of modules are currently used in production.
- These versions are largely outdated according to
drush
. - In addition, a lot of modules cannot be updated by
drush
. They were customized or are incompatible/unavailable for other reasons. - It unclear whether updating the modules would break anything.
2. Historical situation
2.1. Drush availability
Drush is installed in Bas van der Veen and Jurriaan Roelof's home directories instead of in a system-wide $PATH
directory.
Users from the Unix group clarinadmin
can access it. At this moment Bas van der Veen can perform Drush commands (in directory /hum/web/www.clarin.eu/htdocs/sites/clarin.eu
or /hum/web/tst.clarin.eu/htdocs
)
/home/bvdveen/drush/drush status
The current version is outdated (5.8) and should be updated after planned OS upgrade (Feb 2016). Recent drush
subcommands may not work otherwise.
In the following, let "${Drupal_root_dir_path}"
be the root directory path of the Drupal installation.
2.2. Backups
ICT & Media system administrators are responsible for a regular backup through a filesystem(?) snapshot.
2.2.1. Manually, through web interface
https://www.clarin.eu/admin/config/system/backup_migrate
2.2.2. Manually, from command line
With `archive-dump`
drush archive-dump # --no-core
drush bam
2.2.3. Manually, from command line (error prone version)
sudo tar -cvJ -C '/hum/web/www.clarin.eu/htdocs' -f ‘bckup_clarin_28oct15’ .
2.3. Which updates are available?
drush -r "${Drupal_root_dir_path}" -s core-status Drupal
Check if a module is listed under ../sites/all/patches
. Patches are often integrated in higher non-patch versions of modules. See: https://www.drupal.org/patch (manually apply patch: https://www.drupal.org/node/534548).
# Or: '/hum/web/tst.clarin.eu/htdocs/' cd '/hum/web/www.clarin.eu/htdocs/sites/clarin.eu/' drush status # List patches drush ups --security-only # Apply patches drush upc --security-only
2.4. Common error messages
2.4.1. Wrong directory
Command pm-refresh needs a higher bootstrap level to run - you will need to invoke drush from a more [error] functional Drupal environment to run this command.
2.4.2. ups
failed
The drush command 'ups' could not be found. Run `drush cache-clear drush` to clear the commandfile cache if [error] you have installed new extensions.
You did not use Drush 5 or higher. Instead, you could issue:
drush up --security-only
2.4.3. Forbidden to download drupal core
It's forbidden to download drupal core into an existing core.
drush rf # In case database migration is needed: drush updb # Should not show available updates or errors: drush status
- Check website, and disable maintenance mode.
- Possibly, Drupal Features must be reset:
drush features-list # Reset Drupal Features: drush fr -y openscience_demo_content openscience_events --force
- In case the previous has failed, indicated by the status being
overridden
, consult https://www.drupal.org/node/986932. A quick fix is to remove and reinstall all Feature modules, but for custom Features (openscience
,clarin_eric_config
) that will fail.
2.4.4. Failed Drupal upgade …
Attachments (1)
- clarin website HA setup.png (26.6 KB) - added by 8 years ago.
Download all attachments as: .zip