VER the past couple of weeks we have made major visual changes in Tux Machines, including modernisation that keeps up with new browser technologies like CSS3. Traffic in the site is growing fast and we hope to gain readers who are as passionate about Free software as we are.

(more…)

Direct download as Ogg (1:35:15, 41.3 MB) | High-quality MP3 (44.8 MB) | Low-quality Ogg (24.8 MB)

Summary: An episode which focuses on the role of Free software when it comes to development of games and the role of GNU/Linux in gaming platforms

We hope you will join us for future shows and consider subscribing to the show via the RSS feed. You can also visit our archives for past shows.

As embedded (HTML5):

(more…)

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.

Direct download as Ogg (1:38:36, 54.2 MB) | High-quality MP3 (52.1 MB) | Low-quality MP3 (27.9 MB)

Summary: The first audio episode in a very long time covers some of the latest happenings when it comes to privacy and, contrariwise, mass surveillance

We hope you will join us for future shows and consider subscribing to the show via the RSS feed. You can also visit our archives for past shows.

As embedded (HTML5):

(more…)

Direct download as Ogg

Summary: Dr. Richard Stallman, the Free Software Foundation’s founder, explains what inspired him to get involved in non-software matters

After this interview we looked up some lines from “The Prisoner” (on his laptop).

Made entirely using Free/libre software, heavily compressed for performance on the Web at quality’s expense