ccasionally it is needed to gain access to sites that are behind firewall/s and also necessary to install software on them. This is when the graphical front ends may ‘break’ (refuse to work as expected), either because Drupal cannot access the outside world or because the outside world cannot access the Drupal instance. Drush would suffer because it depends on connection with the outside world (usually a two-way connection). If connection is made possible from the server to the outside world but not vice versa, then we can ‘pull’ files into the server, via SCP for example (or rsync). So in practice things are little more complicated, but not impossible to cope with.

Having gained access to the said server (e.g. ssh -p PORT_NUMBER USERNAME@SERVER_ADDRESS), it should be simple to see where files are transmitted from to visitors, either by checking the Apache configurations (usually under /etc/apache* for Debian-based distribution and /etc/http* for Red Hat-derived distributions). Another option is to use locate, finding some key Drupal files such as xmlrpc.php. In practice this latter option would be faster than to check Apache configuration files, so upon login run locate xmlrpc.php and go to the suitable location (e.g. /home/drupalsites/ or /var/www/), under /modules or /sites/all/modules (typically in Drupal 7). Modules are further sub-divided; under /contrib one should usually put non-core modules.

If this is an attempt at upgrading a module, then it would be wise to make a backup before replacing anything, e.g. mv MODULE_NAME /home/drupalsites/ to remove it or cp -r MODULE_NAME /home/drupalsites/ to make a copy. Use sudo su if permissions are insufficient, but don’t use sudo sparingly if it’s a live Web site.

If the module file (usually compressed archive) is accessible over the Web, then use wget. Otherwise, pull it from another server or a desktop with scp, e.g. scp USER@SERVER:/home/user/module.tar.gz .

For ZIP files use unzip/gunzip and for .tar.gz use the common piping tricks, e.g. tar cvf - foodir | gzip > foo.tar.gz. When deflated, these files should turn into directories, which can be put in place while the compressed archive gets deleted with rm. Set groups and owners appropriately, e.g. to www-data on CentOS/Red Hat and apache for Debian/Debian-derived. This can be done recursively also, e.g.:

chown -R www-data ./MODULE

chgrp -R www-data ./MODULE

The module/s should not be selectable from the front end (the Drupal site, under Modules) and there should be no permission issues. In case of problems it should be possible to revert back to other versions by restoring from the backup (if made) or by simply removing, with rm -rf, the ‘offending’ module. On Red Hat-based systems there is also room for debugging at code level, e.g.:

tail -n600 /var/log/httpd/error_log

tail -n600 /var/log/httpd/access_log

The exact file names depend on Apache configurations. System-level debugging can also be done with help from /var/log/messages (Red Hat) and /var/log/syslog (Debian), essentially tail‘ing them:

tail -n600 /var/log/messages

To update the whole of Drupal from the command line (without drush):

In Drupal 7:

• make a backup of the database
• Fetch the latest version, e.g. wget http://ftp.drupal.org/files/projects/drupal-7.24.zip
• unzip drupal-7.24.zip
• Go to maintenance mode at: http://YOUR_SITE/#overlay=admin/config/development/maintenance

Assuming the site is at public_html/home/:

• cd public_html/home/
• mv sites/ ../..
• rm -rf OR mv * ~/backup
• Go to the directory of the new version and rm -rf sites/
• cp -r * ../public_html/home/

Always MAKE BACKUPS of both files and DBs. This ensures that reverting back will be possible.

For Drupal 6:

• Go to YOUR_SITE/admin/settings/site-maintenance and set the site to maintenance mode
• Assuming the site is at /var/www/: cd /var/www/
• Get latest version, e.g.: wget http://ftp.drupal.org/files/projects/drupal-6.30.zip
• unzip drupal-6.30.zip
• cd drupal-6.30
• rm -rf sites
• rm robots.txt
• rm .htaccess
• rm -rf themes/
• rm -rf profiles
• chgrp -R apache * (for Debian systems usually)
• chown -R apache *
• unalias cp
• cp -rfp * ../html/
• Set .htaccess to allow upgrade.php access, then update
• Go to YOUR_SITE/admin/settings/site-maintenance and set the site to be accessible to all again

The above pretty much ensures that even when a site is heavily guarded and exists behind firewalls it can be maintained, extended, and kept up to date. Public-facing sites tend to be easier to maintain.

This entry was posted on Monday, April 21st, 2014 at 9:18 am and is filed under CMS. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.