Archive for the ‘Web’ Category

How to change “about:home” to anything in Firefox (Icecat, Iceweasel)

Thursday, March 20th, 2014

Before reading, please note that I’ve written this post with respect to Icecat 17.0.1 which is a rebranded version of Firefox. I can’t guarantee that things will work the same with Firefox or Iceweasel (another rebrand) or other versions of any of these Mozilla browsers.

The concept of a home page is not well defined in Firefox. In Edit->Preferences there is a Home Page setting. When Firefox starts, this is the url that will be displayed. But it’s not the url displayed when a new tab is created or when visiting about:home. Those are two other, independent settings. The first is set from the about:config screen by changing the preference browser.newtab.url. It’s also necessary to set browser.newtabpage.enabled to false. The latter is not easily changed. There is no preference to change it.

The about:home page is a static page included in the Firefox distribution. In can be found in the file omni.jar (or omni.ja in my distribution). The exact location of this file will depend on the distribution, the operating system, and probably the Firefox version. It’s probably easiest to find it by doing a search of your file system. One my try entering “chrome://browser/content/findme” in the address bar of a Firefox tab. The resulting error message might indicate where omni.jar is to be found.

Once located, the omni.jar file can be opened and it’s contents browsed and edited. I use fileroller on my Debian based pc to browse the contents of the archive. Inside the archive, you need to find the aboutHome.xhtml file. In my version of Icecat (17.0.1) it is located within the archive at /chrome/browser/content/branding/. If you don’t have a rebranded version of Firefox, you might find it at /chrome/browser/content/browser/abouthome/.

Open this file for editing. Within the <head> element of the xhtml page, simply add the following script tag:

<script>
window.location.href = "https://www.startpage.com";
</script>

Whenever about:home is accessed, the page will be automatically redirected to whatever url is set in the quotation marks. You can test this by typing “about:home” in the address bar of a Firefox tag. This shouldn’t require that you restart Firefox in order to work.

Playing around with the omni.jar file turns out to be a lot of fun. With my current configuration, I am able to browse the contents of the jar file using Firefox itself by typing in the following in the address bar of a tab: “jar:file:///home/Files/Programs/icecat-17.0.1/omni.ja!/”.

It also seems possible to access some components directly. For example, entering “chrome://browser/content/browser.xul” in the address bar of a tab, appears to load another instance of Firefox within that Firefox tab. It’s like a new Firefox window all contained within a tab. Very cool.

Screenshot - 03202014 - 03:35:10 PM

Disable traceback on old WordPress posts and pages

Wednesday, February 26th, 2014

The WordPress traceback/pingback feature is a spam magnet for bloggers, including me. I long ago disabled the feature globally in the Discussion options. It turns out that this only affects future posts. All of the posts and pages written before it was disabled are not affected (WordPress v.3.8.1). I’m tired of moderating spam tracebacks so I looked into a way to disable the feature.

The proper way is probably to use an SQL query as described by this link:

http://www.fatofthelan.com/2013/06/eliminate-pingback-and-traceback-spam-on-old-posts/

Since that involves me remembering how to log into MySQL, the passwords, and associated commands, I wanted something a little quicker, if not dirtier. Another suggestion from the interweb was to delete the php code that handles the tracebacks and automatically generates the comments. This file is called wp-trackback.php and is in the top level WordPress directory. I can’t imagine that I’d ever want to turn this feature back on, but deleting the entire file may be overkill. A rename is probably sufficient, but I worried that this would lead to logs being filled with php errors.

My solution was to kill the script before it got anywhere. A quick perusal shows that after handling the traceback, the script uses a php die() call to exit. I simply slipped one of these in at the top of the file (wp-trackback.php, below the “<?php” initiator) and voila. Any time this script is called it dies quietly and without error. No response is returned to the traceback sender (spammer). If you want to be more creative, just below where the function trackback_response() is defined you can call that function with an error code of 1 and a message for the spammers like this:

trackback_response(1, “Go to Hell. Or Cleveland.”);

On second thought, it might be more effective if you were to explain in your message the detrimental effects of spam on communication via the internet, the associated ethical problems, and the ineffectiveness of spam advertising. Encourage them to change their ways and contribute to a healthy, open exchange of real, meaningful ideas.

I’m sure that can all be said with a few choice four letter words.

One thing to mention: editing, deleting, or renaming the wp-trackback.php file, or any other WordPress php scripts, probably won’t survive an update. The SQL method mentioned above is update-safe.

How to fix slow DNS look-up’s in Firefox running under Linux

Sunday, July 21st, 2013

I’ve had this problem for some time now and chose today to do some research. Luckily, I found a workaround pretty quickly.

I use the Mozilla based browser GNU IceCat which is functionally equivalent to Mozilla Firefox. When a page is requested, the browser displays a small spinning icon in the left corner of the tab. Loading a page involves three basic steps: converting the URL into an IP address, contacting the web server at the IP address, receiving the web page (and other resources). During the first two steps, the icon will be grey and spinning counter-clockwise. The status bar will show messages like “Looking up google.com” and “Waiting for google.com”. Typically, DNS queries (the first step) take on the order of 100 ms to complete. Therefore if you see the first message, you may have the same problem.

The symptom was that IceCat (Firefox) was taking about 3 to 5 seconds to make DNS queries every time I tried to navigate to a new address. The cause of the problem seems to be that my system is making IPv6 DNS queries first by default but these types of requests are being ignored by the DNS resolver which doesn’t support IPv6. My system sends a query and then waits a certain amount of time before giving up and trying an IPv4 query. That time waiting was the delay I was experiencing.

The ideal fix would be to change the way the DNS resolver responds to IPv6 DNS queries. That’s obviously out of my control. A system-wide fix involves setting up your own DNS resolver – a bit more work than I’m interested in. The easy fix was to address the issue for IceCat (Firefox) only which is good enough for me as web-browsing is my primary internet activity.

The fix is to change the value for the key “network.dns.disableIPv6″ from “false” to “true” in IceCat’s (Firefox’s) “about:config” page.

For more information, the issue has been discussed extensively here:

https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/417757

Update the DNS record for a Namecheap hosted domain automatically

Saturday, May 18th, 2013

I thought I’d share this technique I use to update the dns records for hellonull.com automatically from the web server every 5 minutes. In the event that my ISP issues me a new IP address, my site will hopefully only be down for 5 minutes.

First, you must obtain the dynamic dns (ddns) update password for your domain from Namecheap. At the time of this post, this was done by clicking the ‘Dynamic DNS’ link from the left hand menu, once your domain was already selected. When you enable dynamic DNS, a password will be generated that looks like a long string of random letters and numbers. Copy this down.

Screenshot - 05182013 - 02:59:52 PM

Next, put this password into the updateddns.sh script (below) and edit the wget commands to point to your hosts (@, www, etc.) and domain (hellonull.com). Make this script executable. It’s a good idea to make the owner of this script root and save it in a protected location, like /root because it contains ‘plain-text’ passwords. Anyone who is able to access the script is able to read the password and is therefore able to change your site’s DNS records.

#!/bin/sh
# This script updates the dynamic DNS record for several domains
# hosted on this server. It is run automatically by cron. The crontab
# file that makes this happen is stored in /etc/cron.d/ddns.
# While this script can execute as any user, it should be owned by
# root because it contains 'plain text' passwords.
# Each host (as in host.hellonull.com) must get updated individually.
# In addition, all subdomain records must be updated individually.

logFile="/var/log/updateNamecheapDDNS.log"

# this is the password as generated by namecheap
pass="You'll have to look at the original or get new ones"

# add a wget line for each host and subdomain
wget -a $logFile -O /dev/null "https://dynamicdns.park-your-domain.com/update?host=www&domain=hellonull.com&password=$pass"
wget -a $logFile -O /dev/null "https://dynamicdns.park-your-domain.com/update?host=@&domain=hellonull.com&password=$pass"
wget -a $logFile -O /dev/null "https://dynamicdns.park-your-domain.com/update?host=teachingwiki&domain=hellonull.com&password=$pass"

If you run the updateddns.sh script it should update your DNS records. To automate the process simply schedule the script using cron. I added a crontab file called ddns in /etc/cron.d which executes the script every 5 minutes.

# use this file to schedule ddns updates
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# every 5 minutes
*/5 * * * * root /root/updateddns.sh >/dev/null 2>&1