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: through through (APIPA only) through through

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.

881 Hits

Problems updating iTunes

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

1050 Hits

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.
778 Hits

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

2199 Hits

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
41509 Hits

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.

1242 Hits

Problems with Windows 7 SP1 installation

windows7The question of quite how one is perceived as an expert in all things computing when one knows a little about one aspect of IT, is one that I will leave for those much more knowledgeable than I.

The other week I was presented with a PC that was reported as ‘crashing’ whilst in use.

I must admit I never managed to find it  crashing on me whilst I was looking it over, but there were a number of things that didn’t look quite right, as is usual when presented with a machine with ‘problems’.  There was a lot of ‘temp files’, consuming disk space and it was split into two partitions, the second of which (the data partition D:) was virtually empty and the system partition C: was virtually full, so a repartitioning would be a good start.  The Windows registry revealed a lot of entries that were not being used and there were obviously a lot of updates missing of which the most obvious was SP1.  One proceeded to run virus scans and starts updating with the latest Microsoft fixes. However whilst most of the updates applied themselves without any issues. SP1 would fail with an error message ‘0x800f081f’.

Searching the web suggested various solutions such as running a full disk check, installing the Windows Update Readiness Tool etc., but none of these made the slightest difference to the symptoms, even though there were a few disk errors detected and corrected.  As each solution involved quite a long time to complete, especially the disk check this was not going to be a quick resolution.

The Microsoft web site didn’t throw up any possible solution, but surely after all this time, I couldn’t be the first person to hit this problem? After several days spent trying the suggestions and after much searching I eventually found this link. Although it was concerning Windows 2008 R2 it was still applicable. The symptoms described almost exactly match what we were experiencing. Even the screenshots reflected the symptoms we observed, although the event log display was slightly different.  With this closeness we tried the suggestion.

The removal of the patch KB976932 with the Deployment Image Services and Management Tool, took over an hour and it was not always immediately obvious that it was being removed, or even doing anything at all, but one resisted the temptation to ‘tinker’.  Once removed the next attempt to install the SP1 upgrade immediately started working.

Over an hour later after a reboot we could then check for any further updates. As you may guess there were nearly another 100 patches to apply, so we were not complete yet, but at least we were over our major hurdle and we were almost ready to finish our tests and give the machine back to its owners.

762 Hits

Problems with a SEF component

We are currently trying to track down a strange problem with an installed SEF component.  The problem fortunately only occurs on our Development site but it has some very strange symptoms.

First we created our development site with a backup of our live environment.  Everything in the back end works fine but in the front end some pages display completely blank, with no tags what so ever.   Fine one would say, there must be a PHP error, (although why this should only occur on a restored system rather than the live site is another question), so we turn on ‘Site Error’ reporting to Maximum (or Development) and it makes no difference to the front end displays they still shown blank pages.

Perhaps a cache problem, but no, clearing all the caches, in the system, browser etc., still makes no difference.  Nothing is reported in system or error logs what so ever.

Then a break though, we disable our SEF component and the pages display OK. So if must be something with the SEF component!  We reinstall an older version of the SEF component and it all works perfectly.  Re-install the current version of the SEF component and the blank pages re-occur.  Re-install the ‘older’ version and the pages are fine.

At this point we report the problem to the component author’s support forum.

Now frustration starts to kick in.  The support from the vendor says that there isn’t a problem, since there is no PHP error, and it doesn’t occur on our live site!  Exactly what sort of support is it they are offering? And this is a component for which we pay for support!  I will withhold the name of the vendor for the moment, perhaps they will improve, and it might be a problem at my end, although it is not looking likely.

I am starting to hate SEF with a vengeance, and this is just another straw that is ‘starting to break the camels back’.

At least we have a mechanism to enable us to continue testing our components for a forth coming release, but we really need to resolve this at some time, so it will be revisited when we have some more time.  Watch this space.

772 Hits

Converting Joomla Discussions Forum to Kunena revisited

kunenaWe previously wrote about converting a Discussions Forum to Kunena and it was now time to revisit the topic as we prepared to perform the task again and this time make the final step to make it live on our site. Since then the Kunena version has moved on to 3.0.3 so we were expecting a few changes.

We must also take the opportunity to state that our Discussions forum did not make use of images/attachments, hence it was not necessary to consider these in the migration. There was also a know opportunity with the Discussions component in that although new user were synchronised between Joomla and the component, when users were removed from teh system for any reason, their details remained within the component. It was thus necessary to run an additional SQL script to clean out these old entries.

The installation of Kunena 2.0.4 and the Importer worked fine, as did the import of the Discussions items (posts and categories). Unfortunately the ‘live update’ to version Kunena 3.0.3 gave us a blank screen, so we resorted to the standard update mechanism which worked fine. (Perhaps the live update implementation needs some work?)

Then we started running our SQL scripts (See previous post for details, which are didn’t require any changes):

  1. Create the  view.
  2. Updated the topics table. We observed the message ‘1364: Field 'params' doesn't have a default value’.
  3. Update categories number of topics count. We saw a number of messages ‘1048: Column 'numTopics' cannot be null’.
  4. Update the last_topic_id, last_post_id and last_post_time fields.  Again we saw a number of ‘1048:Column xxxxx cannot be null’ messages. We were not too worried about these messages as they reflect the empty categories in our original Discussions source tables.
  5. We then updated the category hits.
  6. We then recalculated the statistics within the Kunena Forum Tools.
  7. As mentioned above, we run an additional script to remove 'old' users from our Kunena users table.

delete from #__kunena_users
where userid NOT IN (select id from #__users);

Note: There are several fields such as the number of views of a topic etc. which are not populated because this information is not retained by our source forum and we could not begin to guess what might be appropriate, so better to leave them empty. They will populate themselves over time and we are not too interested in how many people had read them.

Now we can either start configuring the component on our development site, or we can export our tables ready for loading into our live site and after loading configure the forum there. We decided upon the later option.

Inspecting the database tables if was apparent that a number of the tables were empty (since this was effectively a new forum installation) so only a small number needed to be exported and imported on our live site.  The list of tables was as follows:

#__kunena_aliases, #__kunena_categories, #_kunena_configuration, #__kunena_messages, #__kunena_messages_text, #__kunena_topics, #__kunena_user_topics, #__kunena_users, #_kunena_version

On our target (live) site we only need to install the latest Kunena version (3.0.3) and import the data we exported above.

We now disable the use of sh404SEF for the Kunena forum. Basically we have found it more trouble than it is worth, and the Forum entries are fine without the need to use the SEF translations in sh404SEF.

We now enable the Forum menu item, which is the menu link to the Kunena menu item, and after clearing out system cache, we are ready to see how it is looking.

Looking at the front end of the site we can enter our forum and see our posts etc., so all is basically sound.

The next step is to install an anti spam component for the Forum. We have chosen R-Antispam v1.3.0 by Ratmil, which uses a Bayesian algorithm to determine whether the message is spam or not. Being Bayesian it learns over time and becomes more accurate the longer it is used.

Our configuration included adding spam check API keys, changing the default Kunena menu tab, etc.  We also had to change our category headers slightly since Kunena didn’t like html in the category description.

Once done we made the new ‘forum’ available to users and disabled the ‘old’ forum.  Note the ‘disabled’ since we will monitor it over a few days/weeks before we finally ditch it altogether.

Addendum: Have to also change the SEF entries that refer to the 'old' forum entries to redirect to the new forun equivalent. Also search out 'smart search/finder' entries as well.  Note that Kunena does not currently install a 'smart search' plugin even though it is present in the installation file. See Kunena web site forum for the rationale for this.

2448 Hits

Web Site Security

b2ap3 icon joomlaJust read a short article in the December issue of the Joomla Community Magazine titled ‘Ten Arguments That Threaten the Security of Your Website’ that is well worth reading.  It applies equally well to any web site but obviously the emphasis is upon Joomla.

The point about always keeping your website up to date with the latest patches in particular is one that I usually have to use every week, when looking at reported problems our component users are experiencing.   Usually the Joomla version is several if not many versions behind current.  Perhaps one might miss or not have time to always be upon the latest release but there is really no valid reason for being, in some cases over a year behind.  It is just asking for trouble.

I recommend it for a worth while read, it is reasonably short, but quite concise, and unfortunately so true in many respects.

768 Hits
Go To Top

The Macrotone Consulting Web site would like to use cookies to store information on your computer, to improve our website. Cookies used for the essential operation of the site have already been set. To find out more about the cookies we use and how to delete them, see our Privacy Policy.

I accept cookies from this site.