Version 17 (modified by 8 years ago) (diff) | ,
---|
- 1. Development workflow
- 2. New plans
- 3. Important management tasks
-
4. Current issues (2016)
-
4.1. The
clarin_eric_config
module depends onwysiwyg
and other outdated and/or custom modules - 4.2. Complex redirects
-
4.3. Migrate from multisite setup (multiple directories in
sites
) to single site setup. - 4.4. Create fresh and clean Drupal and drush installation
- 4.5. Use different passwords for Unix root, Drupal admin and MySQL database
- 4.6. Update each module piece by piece, not just for security issues
-
4.1. The
- 5. Historical situation
We use the Drupal Content Management System (CMS) for https://www.clarin.eu. A general, brief overview of Drupal.
All communications with the ICT & Media admins, the data center that hosts the website (see links to FQDNs below), should have sysops@clarin.eu in CC.
1. Development workflow
Development follows a three-stage workflow:
- development: dev-www.clarin.eu?
- acceptance
- production: Archive/www.clarin.eu
Drupal should be managed from the command line with Drush. Commands for drush.
1.1. Tickets
Results (1 - 10 of 23)
Ticket | Priority | Summary | Owner | Keywords | Created | Modified |
---|---|---|---|---|---|---|
#907 | minor | support multi-file upload again | 8 years ago | 6 years ago | ||
#938 | major | Replace clarin_datatable custom code by standard feeds module | 8 years ago | 6 years ago | ||
#958 | minor | Files missing | 8 years ago | 6 years ago | ||
#965 | minor | Clean up Drupal redirects | 8 years ago | 6 years ago | ||
#967 | major | User involvement group pages on new website | 8 years ago | 6 years ago | ||
#990 | major | Recreate organig group views | 7 years ago | 6 years ago | ||
#1002 | minor | strip typographic quotes from URLs | 7 years ago | 6 years ago | ||
#1003 | minor | Investigate possibilities to add the content of views to search index | 7 years ago | 7 years ago | ||
#1006 | minor | Investigate a web-based alternative to google earth for the VLW | 7 years ago | 7 years ago | ||
#1029 | minor | provide governance view with affiliation field | 7 years ago | 6 years ago |
2. New plans
3. Important management tasks
Execute all drush
commands from within /hum/web/clarin.eu/htdocs/
.
3.1. Use the working custom Drush version
alias drush=/hum/web/clarin.eu/private/drush/drush/drush
3.2. Set website to read-only or back to read-write
drush --uri='http://www.clarin.eu' vset site_readonly 1
the last parameter is 1
for read-only, 0
for read-write.
4. 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.
4.1. The clarin_eric_config
module depends on wysiwyg
and other outdated and/or custom modules
For WYSIWYG rich text editing, either wysiwyg
or ckeditor
is needed. wysiwyg
is an extra layer of complexity that allows you to configure various alternative WYSIWYG editing libraries. However, only CKEditor
seems current and still maintained among these. The CKEditor JavaScript? library must be installed locally inside the Drupal code base for it to be detected by wysiwyg
. wysiwyg
conflicts with ckeditor
and only supports CKEditor >= 3, < 4. After the emergency (security) update of Drupal from 7.39 to 7.43, WYSIWYG editing stopped working. For some reason, the CKEditor 4 library is/was still inside the Drupal code base. wysiwyg
now fails to detect this CKEditor library, and this is on purpose, since its version is not supported apparently. CKEditor 4 has been installed via the ckeditor
module after that in order to replace wysiwyg
. But wysiwyg
does not work when ckeditor
is installed. Yet wysiwyg
is required (depended on) by the custom clarin_eric_config
module that is currently unmaintained but essential to site functionality. Thus ckeditor
had to be disabled againg and there is no WYSIWYG editor available anymore for the time being. The solution is to update the clarin_eric_config
to not depend on wysiwyg
or any other unnecessary modules, and then to replace the module wysiwyg
with ckeditor
.
4.2. Complex redirects
There are a lot of redirects in place in /etc/apache2/
. See how we can simplify this.
4.3. 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 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.
4.4. Create fresh and clean Drupal and drush installation
Current problems:
- It appears that Composer or just any OS or PHP package manager hasn't been used to manage Drush and Drupal. An outdated Drush version was hand-installed at
/hum/web/clarin.eu/private/drush/drush/drush
. 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.
4.5. 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 also to the global MySQL settings tables. Since drush
has design flaws, this is risky: it has been found to overwrite the MySQL root user password during backup restoration. If someone gets Drupal's settings.php
file (e.g., because of a .htaccess
problem) and can exploit any PHP/Drupal bug or misconfiguration, he can root the entire OS.
4.6. Update each module piece by piece, not just for security issues
We should use only stable versions of third party 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.
5. Historical situation
5.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.
5.2. Backups
ICT & Media system administrators are responsible for a regular backup through a filesystem(?) snapshot.
5.2.1. Manually, through web interface
https://www.clarin.eu/admin/config/system/backup_migrate
5.2.2. Manually, from command line
With `archive-dump`
drush archive-dump # --no-core
drush bam
5.2.3. Manually, from command line (error prone version)
sudo tar -cvJ -C '/hum/web/www.clarin.eu/htdocs' -f ‘bckup_clarin_28oct15’ .
5.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
5.4. Common error messages
5.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.
5.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
5.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.
5.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