Introduction About Site Map

RSS 2 Feed RSS 2 Feed

Main Page | Blog Index

Wednesday, May 21st, 2014, 8:13 pm

EasyJet Powered by Incompetence, Seemingly Requiring Passengers to Install Malware on Their Computers to Just Board a Flight

Earlier today I was horrified when I attempted to print plane tickets that I had purchased last week. Check-in is possible now as the flight is less than 30 days away (that’s the standard accepted by several companies). Upon attempting to obtain the tickets (as PDF, also a common standard among airlines) I was greeted with nothing at all (no download). I proceeded towards an oblivion of cyclical links and cruft. Both Firefox and Chromium were tested for this, even the latest Android. Nothing would work. When pressing on “check in” I’d be redirected to the Adobe Web site. It’s absolutely impossible to do anything else. Adobe would then pressure the visitor to download and install (with full/root access to the system) a piece of spyware/malware known as “Reader”. In the process, by linkage, EasyJet was forcing one to receive more Adobe ads (proprietary software). Everything in the process is proprietary despite the fact that the Web is “open” and all the software I use is FOSS. Worse yet, EasyJet has me running through screens of non-ending malicious advertising while just trying to log in and check in. Without Adobe’s proprietary Reader, on the face of it, one cannot check in at all. EasyJet ought to take a closer look at who’s hired for its IT team to avoid such embarrassment.

EasyJet should know that Reader is not required to open PDFs. Every IT professional should know this.

Sunday, May 11th, 2014, 4:04 pm

Unrest in Ukraine

JUST under a year ago I protested in this blog against Obama’s intent to invade Syria and officially start another dirty war. It is now evident that the US teaches Syrian terrorists how to fight their government and also provides heavy weaponry, essentially promoting peace/calm by advancing profitable war at the expense of Syrian lives (cannon fodder and civilian casualties). In the United States, attention is being shifted away from the role of a US facility in Libya, which was being attacked while/after it had been funneling weapons (through Turkey) to Syrian terrorists. So much for peace, eh?

Less than a day ago a report surfaced in the German media (it is now in the French, Danish, and Russian press, to name just few examples, but the British and American media ignore it) saying that Blackwater, which is famously linked to the CIA, is now running things around the Ukraine (hundreds of mercenaries on the ground), only weeks after the CIA’s head visited the country, followed by — reportedly — several FBI and CIA agents. For those who don’t know, neo-Nazis gained power in Ukraine with much help from NATO and the US. These are the people responsible for the burning (while alive) dozens of nonviolent people in Odessa. The Western media is so fanatic about propaganda right now that it is lying to readers and viewers, mostly by omission.

Based on actions of NATO member nations in Ukraine, peace is clearly not a goal and calm won’t be restored any time soon. It is just yet another proxy war among several others. I feel sorry for the Ukrainian people, some of whom were my childhood friends.

Friday, May 2nd, 2014, 7:31 pm

Long Pingpong

Read the rest of this entry »

Tuesday, April 29th, 2014, 10:07 am

Tux Machines Improvements

roy rianne

OVER 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.

Monday, April 28th, 2014, 5:46 pm

Fast Pingpong

Read the rest of this entry »

Monday, April 28th, 2014, 10:01 am

TechBytes Episode 88: Games and GNU/Linux

TechBytes 2014

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):

Read the rest of this entry »

Monday, April 21st, 2014, 9:18 am

Updating and Adding Modules to Drupal From the Command Line

Occasionally 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
  • unzip
  • 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
  • unzip
  • 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.

Real-time Posts

Retrieval statistics: 23 queries taking a total of 0.435 seconds • Please report low bandwidth using the feedback form
Original styles created by Ian Main (all acknowledgements) • PHP scripts and styles later modified by Roy Schestowitz • Help yourself to a GPL'd copy
|— Proudly powered by W o r d P r e s s — based on a heavily-hacked version 1.2.1 (Mingus) installation —|