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.
/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 USER@SERVER:/home/user/module.tar.gz .
For ZIP files use
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 -n600 /var/log/messages
To update the whole of Drupal from the command line (without
In Drupal 7:
- make a backup of the database
- Fetch the latest version, e.g.
- unzip drupal-7.24.zip
- Go to maintenance mode at:
Assuming the site is at
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
- Get latest version, e.g.:
rm -rf sites
rm -rf themes/
rm -rf profiles
chgrp -R apache * (for Debian systems usually)
chown -R apache *
cp -rfp * ../html/
.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.