Replacing Firefox-esr with Firefox

I’d like to install the regularly updated version of Firefox.

A new installation of Debian was showing as using the stable long term supported Firefox ESR (extended support release) package.

The task was to remove the package firefox-esr and install the package firefox, or its installation equivalent.

To delete the currently installed package firefox-esr will be

apt remove firefox-esr

However, that can wait until the other package is all installed and shown to be working.

Yes, you can run both versions of Firefox.

To delete the stable version of Firefox and install in its place the I would prefer to use the more regularly updated version of Firefox.

For reference the initial content of the file /etc/apt/sources.list was:

deb http://mirror.ox.ac.uk/debian/ buster main
deb-src http://mirror.ox.ac.uk/debian/ buster main

To search for the installation package for Firefox, it will list all packages with a reference to firefox, use:

apt-cache search firefox

Comparing the new computer installation against an existing operational computer.

For the new computer configuration no Firefox packages were shown, but there were the equivalent language versions of firefox-esr, but on the already operational computer

The one which was already configured, there was a limited number of firefox-esr packages shown, with lots of language variations on the firefox package.

firefox - Mozilla Firefox web browser
firefox-l10n-ach - Acoli language package for Firefox
firefox-l10n-af - Afrikaans language package for Firefox
firefox-l10n-all - All language packages for Firefox (meta)
firefox-l10n-an - Aragonese language package for Firefox
firefox-l10n-ar - Arabic language package for Firefox
firefox-l10n-as - Assamese language package for Firefox
firefox-l10n-ast - Asturian language package for Firefox
firefox-l10n-az - Azerbaijani language package for Firefox
firefox-l10n-be - Belarusian language package for Firefox
: : :
firefox-l10n-sv-se - Swedish (Sweden) language package for Firefox
firefox-l10n-ta - Tamil language package for Firefox
firefox-l10n-te - Telugu language package for Firefox
firefox-l10n-th - Thai language package for Firefox
firefox-l10n-tr - Turkish language package for Firefox
firefox-l10n-uk - Ukrainian language package for Firefox
firefox-l10n-ur - Urdu language package for Firefox
firefox-l10n-uz - Uzbek language package for Firefox
firefox-l10n-vi - Vietnamese language package for Firefox
firefox-l10n-xh - Xhosa language package for Firefox
firefox-l10n-zh-cn - Chinese (China) language package for Firefox
firefox-l10n-zh-tw - Chinese (Taiwan) language package for Firefox
: : :
firefox-esr-l10n-be - Belarusian language package for Firefox ESR
firefox-esr-l10n-ia - Interlingua language package for Firefox ESR
firefox-esr-l10n-my - Burmese language package for Firefox ESR
firefox-esr-l10n-ne-np - Nepali (Nepal) language package for Firefox ESR
firefox-esr-l10n-oc - Occitan language package for Firefox ESR
firefox-esr-l10n-ur - Urdu language package for Firefox ESR

Can I simply install the firefox package then?

E: Package 'firefox' has no installation candidate

Should I use one of the language representations, as listed in  the search?

apt install firefox-l10n-uk

Once again it couldn’t find the package:

E: Package 'firefox-l10n-uk' has no installation candidate

I edited the file /etc/apt/sources.list, modifying the reference to buster to testing and added contrib non-frree, giving:

deb http://mirror.ox.ac.uk/debian/ testing main contrib non-free
deb-src http://mirror.ox.ac.uk/debian/ testing main contrib non-free

To reflect the change I action

apt update

Trying once more with the install and getting the now usual no installation candidate error.

I also replicated the reference to the testing distribution, adding two comparable lines for experimental.

As before I actioned an update and tried to do the installation. Another installation candidate error.

Looking at the Debian wiki page for Firefox it suggests using the unstable distribution.

I added this to the sources.list file:

deb http://mirror.ox.ac.uk/debian/ testing main contrib non-free
deb-src http://mirror.ox.ac.uk/debian/ testing main contrib non-free

deb http://mirror.ox.ac.uk/debian/ experimental main contrib non-free
deb-src http://mirror.ox.ac.uk/debian/ experimental main contrib non-free

deb http://mirror.ox.ac.uk/debian/ unstable main contrib non-free
deb-src http://mirror.ox.ac.uk/debian/ unstable main contrib non-free

Success! I now had the regularly update Firefox version installed.

Firefox as opposed to Firefox-esr can be installed on Debian via the repositories with a simple change to the sources.list file and acouple of command line actions.

Force Browser to Reload Cache From the Website

After updating a website, visitors see it as broken because their browser continues to reference the older JavaScript, JQuery and CSS files.

How to force the browsers of website visitors to make use of the newer updated support files?

Testing a website yourself its possible to refresh the browsers cache.

But for the visitor to your website this approach isn’t possible. What’s needed is for the website to tell the browser to forget the files which it has previously cached.

If its one or two files in the header or footer its possible to add an extension. But this is good for a one-off change, or at the end of a series of work, perhaps a major site update.

For example

<script type=’text/javascript’src’/jquery.js?ver=1.9.3’></script>

Note the added version number.

Changing the version number will cause the browser to get the revised file.

I’ve used this technique on images before where the image amendment, a rotation wasn’t being shown. On this occasion I added a parameter based on the edit time and date of the image.

For a website, such as WordPress, it may not be so easy to modify a file like this. If we have a child thime in use, is it worth copying the header file just to make this change?

Apache .htaccess file

For this method we’ll make use of mod_expires.

In the htaccess file make use of modexpires add the following to your .htaccess file located in the root of your website files.

<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 60 seconds"
ExpiresByType text/html "access plus 60 seconds"
ExpiresByType image/x-icon "access plus 60 seconds"
ExpiresByType image/gif "access plus 60 seconds"
ExpiresByType image/jpeg "access plus 60 seconds"
ExpiresByType image/png "access plus 60 seconds"
ExpiresByType text/css "access plus 60 seconds"
ExpiresByType text/javascript "access plus 60 seconds"
ExpiresByType application/x-javascript "access plus 60 seconds"
</IfModule>

Include as many entries as you deem necessary, and change the time out as appropriate. I used the above rather short value so my client’s browser would reload the files, having been used heavily viewing recent changes.

The time option is given as a number plus the type, which can be:

  • seconds
  • minutes
  • hours
  • days
  • weeks
  • months
  • years

Page Header Meta Entries

Also there are entries for the top of the page header.

These can be added to the <head> section of the website file.

<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="0" />

For a WordPress website I added them via the functions.php file. I didn’t want to go modifying the header.php file of the theme. The child theme didn’t have a copy, so why add one purely for this and also the theme had a header builder.

function vntweb_header_metadata() {
// Post object if needed
// global $post;
// Page conditional if needed
// if( is_page() ){}
?>
<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="0" />
<?php
}
add_action( 'wp_head', 'vntweb_header_metadata' );

One advantage with the use of the functions.php file is that a date test could be added. After, for example a week the addition of the meta entries could be removed.

It’s also possible to create a functions.php file to be added to each website development ,with a number of functions, enabling those which are required on a given website.

Other Options

Another approach is to use regular expressions to amend files. But this may presuppose that extensions do already exist. also looking for a simple modificatin, which isn’t prone to misinterpretatin. can be easily copied and used without the risk of doing damage I prefer the two solutions given above.

References

Inmotion hosting – apache mod expires

Stackoverflow – control web page caching

Mozilla – headers cache cotnrol

Setting a Custom 404 Page with htaccess

I bought a custom HTML website template with a 404.html page. How do I use it?

If I enter a wrong website address I don’t see the 404 page my browser simply shows a generic message from the hosting control panel.

The server needs to be configured to tell it what to do with when a page doesn’t exist.

The changes can be made in the .htaccess file found in the root of the public website.

Changes can be made either by FTP or via the file manager within the hosting control panel.

Often the file view begins one level down. Look for a directory called public_html, or similar.

In the .htaccess file add the following

ErrorDocument 404 /404.html

where 404.html is amended according to your error file name.

But this doesn’t work fully.. The error page is now shown as wished, but the address stays with the wrongly entered page.

What is required to complete is to redirect to the 404.html page. For this we’ll use the redirects.

RewriteEngine On 
RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /404.html [R=301,L]

The above is added to the .htaccess file.

  • The first line turns on the redirects.
  • The following two lines set the rewrite conditions, checking for an existing file and directory respectively
  • Lastly the setting of the rewrite rule which takes the visitor to the 404.html page located in the root of the website.

Speech-dispatcher Using Legacy Directory in /var/run

With an update of Debian packages there was a message related to the speech dispatcher.

The older version of the program used the directory /var/run/speech-dispatcher, whilst this version 0.8.8-8 was looking to use the directory /run/speech-dispatcher

Given below is the relevant lines from the apt upgrade, relating to speech-dispatcher.

Setting up speech-dispatcher (0.9.0-5) ...
[speech-dispatcher.conf:1] Line references path below legacy directory /var/run/, updating /var/run/speech-dispatcher → /run/speech-dispatcher; please update the tmpfiles.d/ drop-in file accordingly.
[speech-dispatcher.conf:2] Line references path below legacy directory /var/run/, updating /var/run/speech-dispatcher/.cache → /run/speech-dispatcher/.cache; please update the tmpfiles.d/ drop-in file accordingly.
[speech-dispatcher.conf:3] Line references path below legacy directory /var/run/, updating /var/run/speech-dispatcher/.speech-dispatcher → /run/speech-dispatcher/.speech-dispatcher; please update the tmpfiles.d/ drop-in file accordingly.
[speech-dispatcher.conf:4] Line references path below legacy directory /var/run/, updating /var/run/speech-dispatcher/.cache/speech-dispatcher → /run/speech-dispatcher/.cache/speech-dispatcher; please update the tmpfiles.d/ drop-in file accordingly.
[speech-dispatcher.conf:5] Line references path below legacy directory /var/run/, updating /var/run/speech-dispatcher/log → /run/speech-dispatcher/log; please update the tmpfiles.d/ drop-in file accordingly. 

The file in questions is

/usr/lib/tmpfiles.d/speech-dispatcher.conf

Below are the old file contents of this file

d /var/run/speech-dispatcher                            0750 speech-dispatcher audio -
d /var/run/speech-dispatcher/.cache                     0750 speech-dispatcher audio -
L /var/run/speech-dispatcher/.speech-dispatcher         -    speech-dispatcher audio - /var/run/speech-dispatcher
L /var/run/speech-dispatcher/.cache/speech-dispatcher   -    speech-dispatcher audio - /var/run/speech-dispatcher
L /var/run/speech-dispatcher/log                        -    speech-dispatcher audio - /var/log/speech-dispatcher

And once more the revised contents of the file /usr/lib/tmpfiles.d/speech-dispatcher.conf

d /run/speech-dispatcher                                0750 speech-dispatcher audio -
d /run/speech-dispatcher/.cache                         0750 speech-dispatcher audio -
L /run/speech-dispatcher/.speech-dispatcher             -    speech-dispatcher audio - /var/run/speech-dispatcher
L /run/speech-dispatcher/.cache/speech-dispatcher       -    speech-dispatcher audio - /var/run/speech-dispatcher
L /run/speech-dispatcher/log                            -    speech-dispatcher audio - /var/log/speech-dispatcher

htaccess Difference Between Files and FilesMatch

Whilst writing the two recent articles about blocking xml-rpc access and the matching of files in htaccess.

.htaccess uses Files and FilesMatch to control access to files.

For example for the single file wp-config.php

<Files "wp-config.php">
Order Allow, Deny
allow from all
deny from 192.0.2.52
</Files>

There’s also

<FilesMatch "\.(gif|jpe?g|png)$">
Order Allow, Deny
allow from all
deny from 192.0.2.52
</FilesMatch>

So what’s the difference and when should each be used?

Well none really. Its all about presentation and making the reading of the file easier to view.

When reading down better to see the single Files entry and expect a corresponding single file, in this case wp-config.php. And to have a multiple match of files, as given a number of image extensions. Again the FilesMatch leads the reader to expect that the match will be multiple files.

In the above two examples the files section is used to define the matching criteria and to set the actions associated.

I’ve shown two different example of file selection, but both are configured to allow access to their respective matching files to all visitors, except the single IP address.

Both of the above to examples are code added to the file .htaccess in the root of the website with the purpose of governing the access to files of the website.

An example of this code in use is in the blocking of xml-rpc.

Blocking xml-rpc Access

I’ve heard that I should disable xml-rpc on a WordPress website.

Why should I disable it and how?

XML-RPC What is it? And how to Disable.

What is xml-rpc?

This is the connection for the WordPress API interface.

It allows apps such as the WordPress app on an iPhone or Android device to connect to the WordPress website. With the app I can readily edit and crate blogs posts.

No need to navigate to the website with a browser to login and perform these actions.

Trackbacks and Pingbacks whereby the website checks to see who is referencing its post content.

The popular JetPack plugin, developed by Automattic, relies heavily on the use of xml-rpc.

Why would you want to restrict it?

It poses a security risk.

There’s potentially less chance of detection attempting to gain access this way.

Has the potential to be the target for a denial of service attack.

How to restrict it?

xml-rpc is implemented using the file xmlrpc.php.

Access to the file can be restricted completely or limited to configured IP addresses.

To do this we’ll use the file .htaccess, located in the root of the website, restricting file access by IP Address.

Here’s the block of lines which we’ll add to the file.

# block xml-rpc
<Files "xmlrpc.php">
Order Deny,Allow
deny from all
allow from 192.0.2.52
</Files>

We’ll chose to set the order as deny first then allow

Order Deny, Allow

This allows us to block all sites with the simple

deny from all

A one line global block on access.

If we are implementing a full restriction on access that’s all we would need.

But to allow access from a single IP address we add the following

allow from 192.0.2.52

Further instances of this can be added with single IP addresses or ranges.

Further thoughts

Its going to be a compromise. is there a plugin or app which you can’t do without? If the answer is yes then completely shutting down xml-rpc is probably not going to be an option.

Maybe restrict the access to a limited range or IP addresses. Dependant upon what you wish to connect to it this may be an option. Do you only blog with the WordPress app from a fixed location? Then not a problem.

If none of these is an option for you then leaving access to xml-rpc open will be your option.

Anything more?

Yes, you can use one of the WordPress security plugins to monitor and take action against attempts to gain access via xml-rpc.

And there’s the development of the WordPress Rest API – check to see whether there’s an equivalent of your must have app or program which uses this.

References

WordPress Codex: XML RPC Support

Wikipedia: XML RPC

Using htaccess to Restrict File Access by IP Address

Every so often there’s a new exploit targeted. This shows as an increase in the rate against a particular file.

For example some time ago there were lots of attempts trying to access to the file upload.php in either themes or plug-ins.

This reflects a vulnerability in an inclusion within a number of themes.

With the aim that only authorised users and IP address shall be looking to upload content I looked towards using the .htaccess file to add the restriction.

The .htaccess file is located in the root of the website. It allows local configuration overrides of the Apache web server.

Blocking access by IP Address

Access is restricted using the old favourite of deny and allow.

For example to only allow access from the IP address of 192.0.2.52.

Order Deny, Allow
Deny from all
Allow from 192.0.2.52

Here we first set the access rule order to be deny, then allow.

Where the order defines the sequence in which the deny and allow rules are processed.

The actual order in which the rules are presented within the .htaccess file doesn’t matter. Based upon the order either the deny rules will be processed first or the allow ones.

Beware – if the order in the above were set to Order Allow, Deny, the result would be to prevent access to all. The single address would be allowed, followed by all attempts at access being denied.

The restriction can be further adapted to incorporate the files structure. Either individual files or directories.

<Files /index.php>
Order Deny,Allow
Deny from all
Allow from 192.0.2.52
</Files>

In the above example a specific file is entered. The index.php file in the root of the website.

An alternative is a match, without the directory structure, with the simple name of the file.

This is the form which we will use, replacing /index.php with upload.php. It will then be restricted in whatever directory it is found, accounting for the potential themes and plug-ins.

<Files upload.php>
Order Deny,Allow
Deny from all
Allow from 192.0.2.52
</Files>

Pattern matching, which follows the regular expressions may be used. For example to prevent access to certain file types:

<Files ~ “.(inc|zip|rar)$”>

Here I’ve prevented access to compressed files and includes.

When matching multiple files FilesMatch is used in preference to Files. Although either may be used, its easy to read and gather the implication of the code within the .htaccess file where FilesMatch is showing an expectation of multiple matches, as opposed to the single file.

PHP Fatal error: include_path=’.:/usr/share/php:/usr/share/pear’

A fresh install and an installation of WordPress via the Debian apt package management gave the error

PHP Fatal error: include_path='.:/usr/share/php:/usr/share/pear'

On a development computer I chose to install WordPress via the package manager as opposed to creating Apache site directories.

With MySQL and Apache installed WordPress is added by executing, at the command prompt

apt-get install wordpress.

However, when I first navigated to the website at localhost/wordress/ rather than seeing the start of the me WordPress website creation sequence I had a blank white screen, the so called white screen of death!

Debug reporting can be enabled within the file wp-config.php, located in the root of the website. Here’s the 3 debug options, as disabled:

define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

The packaged Debian version relocates this to the directory

/etc/wordpress

Editing the file config-localhost.php I enabled debug logging setting my chosen options to true.

Still with a blank screen shown I chose to look at the Apache error log.

/var/log/apache2/error.log

using

tail -f /var/log/apache2/error.log

The last few lines of the log file are:

PHP Warning: require_once(/etc/wordpress/config-localhost.php): failed to open stream: Permission denied in /usr/share/wordpress/wp-config.php on line 19
PHP Fatal error: require_once(): Failed opening required '/etc/wordpress/config-localhost.php' (include_path='.:/usr/share/php:/usr/share/pear') in /usr/share/wordpress/wp-config.php on line 19
PHP Warning: require_once(/etc/wordpress/config-localhost.php): failed to open stream: Permission denied in /usr/share/wordpress/wp-config.php on line 19
PHP Fatal error: require_once(): Failed opening required '/etc/wordpress/config-localhost.php' (include_path='.:/usr/share/php:/usr/share/pear') in /usr/share/wordpress/wp-config.php on line 19

The error suggested that Pear was not installed.

To check to see if pear was installed at command prompt I typed pear

neil@abc:/home/neil# pear
bash: pear: command not found

I then installed pear using

apt-get install php-pear

Giving the following:

Suggested packages:
  php5-dev
The following NEW packages will be installed:
  php-pear
0 upgraded, 1 newly installed, 0 to remove and 107 not upgraded.
Need to get 264 kB of archives.
After this operation, 2,108 kB of additional disk space will be used.
Get:1 http://mirror.ox.ac.uk/debian testing/main amd64 php-pear all 5.6.16+dfsg-2 [264 kB]
Fetched 264 kB in 0s (625 kB/s)  
Selecting previously unselected package php-pear.
(Reading database ... 218176 files and directories currently installed.)
Preparing to unpack .../php-pear_5.6.16+dfsg-2_all.deb ...
Unpacking php-pear (5.6.16+dfsg-2) ...
Setting up php-pear (5.6.16+dfsg-2) ..

A restart of Apache

service apache2 reload

To my disappointment – no effect it still showed the error

Tue Dec 22 13:57:38.596887 2015] [:error] [pid 24889] [client ::1:41744] PHP Fatal error: require_once(): Failed opening required '/etc/wordpress/config-localhost.php' (include_path='.:/usr/share/php:/usr/share/pear') in /usr/share/wordpress/wp-config.php on line 19

I considered the permissions of the file in the directory /etc/wordpress, assigning to it the apache permissions

chown www-data:www-data /etc/wordpress/config-localhost.php

Once more I revisited the website at /localhost/wordpress

Success! I was now getting the WordPress installation.

Open IceDove Email Link in IceWeasel

Links in IceDove email messages weren’t opening in IceWeasel.

How to configure IceDove link options?

I found reports on the Internet that the file ~/.mozilla-thunderbird/default/<profile>/prefs.js should be edited as follows:

user_pref("network.protocol-handler.app.http","iceweasel");
user_pref("network.protocol-handler.app.https","iceweasel")

I considered IceWeasel’s configuration, available through the about:config

To make mailto links in firefox (iceweasel) open thunderbird (idedove) automatically, type about:config in the address bar and edit (or insert if it doesn’t exist) the following key and value

network.protocol-handler.app.mailto => icedove
open-icedove-link-iin-iceweasel

There’s a pop-up window to confirm that you know what you are doing:

Changing these advanced settings can be harmful to the stability, security and performance of the application. You should only continue of you are sure of what you are doing.

I'll be careful,  I promise!

I scrolled down the list and changed the entry to IceWeasel.

This didn’t work!

I used the popup dialogue when clicked on the link

  1. From the pop-up menu, select “New”.
  2. From the next pop-up menu, select “String”.
  3. In the pop-up dialog box “Enter preference name”, enter network.protocol-handler.app.http
  4. In the pop-up dialog box “network.protocol-handler.app.http” enter /usr/bin/iceweasel

Subsequent to following the dialogue I tried returning to the preferences and the config editor.

I was only able to find the one entry for IceWeasel in my search. Closing and restarting IceDove

The settings achieved through the linked dialogue proved to be used in place of any settings selected within the preferences.

dpkg: warning root’s PATH should usually contain sbin

Whilst updating a computer:

apt upgrade

It listed all the gets and then concluded with this error:

dpkg: warning: 'ldconfig' not found in PATH or not executable
dpkg: warning: 'start-stop-daemon' not found in PATH or not executable
dpkg: error: 2 expected programs not found in PATH or not executable
Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin
E: Sub-process /usr/bin/dpkg returned an error code (2)

I chose to resolve by editing root’s .bashrc (/root/.bashrc)file adding an export reference for the path at the end of the file.

export PATH=/sbin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin

You’ll need to login afresh for the change to be adopted.