Macrotone Blogs

Macrotone blogs upon Joomla, our products and other matters.

ICANN looking to handle DNS namespace collision risks

I note from this article that a draft of a report (PDF) commissioned by ICANN and carried out by JAS (Joint Applicant Support) Global Advisors includes a series of recommendations — ranging from alerting network operators by returning 127.0.53.53 as an IP address to, in extreme conditions, killing a delegated second-level domain — to deal with the issue of traffic intended for internal network destinations ending up on the Internet via the Domain Name System.

Instead of the familiar 127.0.0.1 loopback address for localhost, the report suggests "127.0.53.53". Because the result is so unusual, it's likely to be flagged in logs and sysadmins who aren't aware of a name collision issue are likely to search online for information about the address problems.

"Numerous experiments performed by JAS confirmed that a wide range of application layer software logs something resembling a 'failed connection attempt to 127.0.53.53' which is the desired behavior. We also confirmed that all modern Microsoft, Linux, Apple, and BSD-derived operating systems correctly implement RFC 1122 (albeit with variations) and keep the traffic within the host system, not on the network," the report states.

MySQL and JSON data structures

mysqlHaving been working with JSON data structures recently our thoughts turned to how this could reasonably be handled by SQL queries in the production of items such as reports etc.  Leaving aside the question of how one would ‘know’ and handle the various constituents in the specific JSON object on a generic basis, we looked specifically at what was currently available.

Coming from a strong Oracle background we were familiar with the use of Java within the Oracle database and indeed have made use of it ourselves in the past, but our specific interest this time was MySQL and its use by Joomla, and we were not aware of any feature implementing Java with the MySQL database.

Continue reading

Kunena – Administrator post delete clarification

kunenaOne observation we have made since using Kunena is that one is presented with an ‘Access Denied’ message if an attempt is made to reference a non-existent Forum topic/message. We wanted to investigate this further since we wanted  to get a 404 redirection defined such that the URL could be redirected either to a full ‘404’ page or an alternative Forum post.

We started out creating a new forum post which we then wanted to ‘delete’.  This led us to a different puzzle since our Forum administrator was unable to ‘delete’ the post.

Being a little puzzled about why our Kunena administrator couldn’t see an option to delete a post I have delved a little deeper to understand what was going on with specific checking on the ability to ‘delete’ posts.

Continue reading

Oracle–Flashback Query

oracleWay back in 2001 Oracle announced Oracle9i with a new feature named ‘Flashback Query’. The implication was that Flashback technology would permit one to query past data, no matter how old it was days, weeks or even months old. In fact the actuality was very different since Flashback Query relied upon the undo information contained within the database Undo-Segments.

Later releases refined what was possible. It was named ‘Total Recall’ in Oracle 11g, and now goes by the name of ‘Flashback Data Archive’.  This recent blog goes into a little detail of the recent changes available in Oracle release 12c.

It is an easy read, but at the back of the mind one can’t help but think how much disk storage is required on a busy site to enable one to search back over long periods of time. The feature is useful, and is available ‘free-of-charge’ with all versions of Oracle 12c,  but at what cost in terms of system resources and performance?

Observation of Visitor Private IP addresses

It has been observed for some time that some of our site visitors, usually of the less desirable types have been ‘presenting’ Private IP addresses, as reported by our site protection software.

An IP address is considered private if the IP number falls within one of the IP address ranges reserved for private uses by Internet standards groups. These private IP address ranges exist:

10.0.0.0 through 10.255.255.255
169.254.0.0 through 169.254.255.255 (APIPA only)
172.16.0.0 through 172.31.255.255
192.168.0.0 through 192.168.255.255

Private IP addresses are typically used on local networks including home, school and business LANs including airports and hotels.

Devices with private IP addresses cannot (?) connect directly to the Internet. Likewise, computers outside the local network cannot connect directly to a device with a private IP. Instead, access to such devices must be brokered by a router or similar device that supports Network Address Translation (NAT). NAT hides the private IP numbers but can selectively transfer messages to these devices, affording a layer of security to the local network.

Standards groups created private IP addressing to prevent a shortage of public IP addresses available to Internet service providers and subscribers.

Despite the above, which is standard(?) Internet criteria, we have observed visitors using addresses in the 192.168 range for over a year.  However since the beginning of the month (February 2014) we have seen a large number of addresses in the 172.16 range as well.  Something has obviously changed as these should not be possible.

Searching on the web,  has not revealed any other site that reported the problem? Whilst not an issue for ourselves, since we do not use the IP address information for any purpose other than providing an assessment of where our visitors original from, it might well pose a problem  for other sites.  It is suspected that the only ‘real’ way to stop the practise would be to block the IP ranges, such that a visitor using an IP address from outside the local network, that has a value within the ranges, being effectively ‘blocked’ from accessing any information upon a site, although this should not, according to the criteria above be required.

Problems updating iTunes 11.1.4.62

apple logoJust received a update from Apple for iTunes, which I proceeded to install. Unfortunately it failed to install claiming it couldn’t restart Apple Mobile.

The error was 'Error 7 (Code 193)'

Tried a reinstall with the same results.

One suggestion seen on the web was to check the .Net installation, which I proceeded to do (version 4.5.1) and also checked that al .Net patched were applied, which they were.

Regretfully this didn’t not resolve the problem or make any difference at all.

In the end resorted to uninstalling all Apple products, including Quicktime. iTunes. Apple update service, Apple mobile etc., before performing a fresh reboot.

Now this time I could install the update successfully and it all works as before, picking up all existing music etc.

Why was the update so complicated?  I thought computing was supposed to be easy, not take up ones time performing pointless tasks.  Sarcastic smile

Website Features to avoid

Just read an interesting article on Mashable about a questionaire they did about annoying website features. I must admit many of them are all too familiar on a lot of sites one visits. I would however add one additional annoyance and that would be sites that do not support all of the common browsers - Firefox, IE, Chrome, Safari and Opera. No doubt you have your own particular pet hate as well.

Discussions forum migration to Kunena (Part 4) SEF links

kunenaWe anticipated our last post being our last on this topic, but we have enough information for an additional post.

First we discovered that the first topic id had not been correctly set up.  Not quite sure what went wrong here, but the topic title had the wrong name and pointed to a non-existing category, even though the topic text (message) was our submitted text.  We edited the the table entry directly to correct the category and title and this seems to have resolved the problem.

Much more of a concern has been the relentless number of ‘invalid URL addresses’ we have encountered that have required redirection since we moved forums.  These links seem to have a number of variations as follows:

  • index.php/link_name/cat id/thread id
  • index.php/components/discussions/cat id/thread id

In addition sometimes the category id is expressed a numeric values, sometimes as a text string and sometimes both are included.  Likewise the thread id is similarly expressed is a variety of forms although usually the thread id and title text are provided, separated by a hyphen.

Sometimes the menu id is provided (we changed our menu title from ‘Macrotone Forums’ to ‘Forum’), sometimes the language string ‘lang=en’ is also in the link.

Sometimes the link seems to have the index.php missing completely and consists only of a cat id/thread id.

Most do not have any ‘calling’ URL to check. Look with a tool such as Google web tools for a registered website sometimes show calling web links, and often the referring links are ‘unpublished’ or invalid.

This is despite us removing all ‘old’ existing SEF entries on our site.

We had expected a few since it can take a while for ‘robots’ from the likes of Google etc. to get up to date, but some six weeks after we moved, they are still being found on a regular basis, often > 10 a day.

We have created ‘redirect’ links within Joomla but the wide variety is something that we had not expected, and are sure we are not alone in this.  When could one safety remove these ‘temporary’ redirection links, since one would have expected at the most a few weeks.

We ourselves have a ‘modest’ number of forum entries, but for a large site constantly creating redirection links would become a major headache. Yes one could modify the ‘.htaccess’ file to place a 301 redirection pattern, but the number of patterns required seems to be more than an odd one or two, and is not something I have ever seen described in detail.

Definitely something to be aware of for others migrating from one forum to another, not just for the Discussions forum.

Whilst on the subject of SEF, there doesn’t seem to be a definite solution or suggestion as to how one should really deal with items such as ‘old’ articles.  If the ‘article’ is ‘unpublished’ then any existing links immediately become invalid. How long should one wait (or expect) to see these invalid URLs?  Should the articles be ‘archived’ instead and would this be a better approach? Any item whether it be a web article, a forum entry or whatever has a useful life, so what is the best way to handle their expiry?

Perhaps this is the suggestion for a new definite work on the topic.  It definitely seems to be one of the ‘black arts’.

Install IIS, PHP, MySQL & Joomla on Windows 7

iisWe had cause to investigate a problem with a Joomla component installed upon an IIS platform.  We usually use Apache as our web server, so were not totally familiar with the use of IIS, so this blog covers the installation, configuration and the basic options of IIS, PHP, MySQL and Joomla.

There is no intent to make use of such a setup upon a regular basis, and would anticipate only having to perform the task infrequently, hence the decision to document the steps.  We encountered a number of problems as we performed the set up, and we searched on the web in many placed before achieved our goal. For this reason this is somewhat long, but the benefit being that we have all the details in one location.

The installation is assuming the use of a local installation upon a single workstation.

Continue reading

Discussions forum migration to Kunena (Part 3) Images

kunenaThis is the latest (and probably last) post on our migration exercise for moving Discussions forum to Kunena. [Last post is here.]

Our previous posts did not discuss or address the question of images which are contained in forum entries. The two forums basically store images in the file system and then refer to them in the posts, however the way they do this is different which makes an automatic migration difficult.

First the images are located in Discussions in the directory images/discussions/thread id/post id/[large][original][small]  in the three separate directories each one reflecting a different size of the image, the entries in the ‘small’ and ‘large’ directories being is created when the image is stored.  The images details are then stored in the database table #__discussions_messages as extra fields in the table.  When the post is read the images are appended to the message and shown on the web page.

Kunena stores the images in directory media/kunena/attachments/[user_id], where user_id’ is the identifier for the user saving the images, and stores the image details in a separate database table #__kunena_attachments. The actual forum post is modified, within the #__kunena_message_text table, if the image is to be shown within the post, with tags referring to the actual image itself.

To automate this task would require the population of the kunena attachments table with the image details, after the images have been copied to the ‘new’ Kunena location, and also the specific messages in the #__kunena_message_text table would need modification to add the appropriate inclusion tags.

We have analysed the images in our ‘old’ Discussions forum and found less than a dozen images in total, and given the amount of work that would be required to automate this, have decided that it is probably not worth the bother, and that a one off manual task would be far quicker.  It also enabled us to ensure that image sizes are below the bounds specified in the Kunena configuration file.

Note: We do not have any embedded videos to consider so will not investigate this topic at all.

Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries