Opera slow Flash due to multiple plugin locations enabled

I use Opera as one of a number of browsers for testing purposes. Noticed that Flash was jumpy (Opera 12.16 with flash 11.2 r202 on Ubuntu 14.04 64 bit). It took a while to find the problem but I believe that it was due to multiple flash plugins enabled. To see what plugins are enabled go to,

Opera -> Page -> Developer Tools -> Plug-ins

(or the shortcut URL of opera:plugins )

If you see multiple locations of the Shockwave flash enabled then disable all except one e.g. leave the one located at,  /usr/lib/mozilla/plugins/libflashplayer.so enabled.

Restart Opera and hopefully this may clear your problem.

memtest86+ cannot load a ramdisk with an old kernel image

This error happens when you use UNetbootin to create an Ubuntu disk and it incorrectly adds a ramdisk to the memtest86+ boot option.

Until UNetbootin fix their code then cursor down to the “Test memory” option and hit tab and then at the boot options remove the “initrd=/ubninit” so that the command line is now just…

/install/mt86plus

and then hit enter and Memtest86+ will now run as expected.

My Ubuntu 14.04 currently has UNetbootin 585-2ubuntu1 and this quirk will possibly be fixed in newer releases but sometimes all you have lying around is an emergency install USB/disk so always good to know how to get around  a problem rather than downloading new code.

Internet Explorer (IE8,IE9) slow page load due to Flash and ONSPEED sliprt.dll

Client complained about slow internet page loads. They use Windows Vista and Internet Explorer 8 and to date it had been fine. When I looked at the problem it was just like the browser was stalled trying to connect to a down host. It would take minutes to load a page and was basically unusable. Very frustrating because Opera and Firefox both worked fine.

I got them working temporarily on Opera and arranged to pick up the laptop when they went on holiday for a few days. Back at base I tried a few things which did not work

  • IE8 -> IE9 upgrade
  • IE9 -> IE8 downgrade (uninstall IE9)
  • ONSpeed uninstall and re-install

and then I just got the feeling that flash was a problem. I downloaded the flash installer (which is a downloader not the full application) and tried to run this.

I got an error message about sliprt.dll was not found e.g. This program can’t start because sliprt.dll is missing from your computer.  Try reinstalling the program to fix this problem. The sliprt.dll is part of the Slipstream which is used by ONSPEED. This is HTTP cache/accelerator. The dll does exist in \Windows so obviously some other problem and the error message is due to a missing program call.

I then downloaded the full flash install file ( see http://forums.adobe.com/thread/889580 ) for both Internet Explorer and for “Other Browsers”.

These ran OK and installed without error. This cleared my Internet Explorer stalling and running slow problem and now IE8 is working fine. I upgraded to IE9 and that is also working fine. I was also able to upgrade to Windows 7 Home Premium (using upgrade disk) and the laptop remained stable.

May not work for you but it fixed my client problem.

Fault finding CDI ignition Aprilia Leonardo

A week back we had a very violent thunderstorm. It blew up a laptop PSU (fuse blown) but the oddest one is that my scooter got blown over and when I tried to start it wouldn’t fire. Thought it was low fuel but after top-up of the tank and a lot of cranking it was pretty clear I had more of a problem. The rest of this post details how I fault-found this problem.

The ignition system for this generation of bikes is fairly simple consisting of a TDC sensor in and an output to the ignition coil primary (plus 12 V and ground).

When the ignition  key is turned on then this provides 12 V to the CDI and to one leg of the ignition  coil primary. The other leg of the ignition coil primary goes back to the CDI unit. To fire the coil the CDI unit applies and removes ground to this primary coil leg. So a high current pulse then flows through the primary which energizes the primary coil, which is then multiplied in voltage by the ratio of windings to the secondary coil, the pulse of electricity is then discharged through the ignition  leads through the spark plug to the engine ground. The CDI knows when to fire because a coil pickup on the flywheel tells it when it is TDC.

Checks – Ignition Coil and Sparkplug

The ignition primary coil is easily checked. Looking at the coil (on the right hand side of the bike under the inspection panel), it has a RED/BLACK cable to the key, a WHITE/PURPLE cable to the CDI, a fat black cable to the sparkplug.

To stabilize the very high voltage secondary coil pulse  the sparkplug cap and the sparkplug are resistive. The cap is 5 KOhms and the sparkplug is also about 4-5 KOhms. The ignition lead is screwed into both the  ignition coil and the sparkplug cap. The coil and plug has what looks like a woodscrew poking out deep inside hidden in the coil or plug and you screw the ignition lead onto that point. The ignition lead cable can and will on older bikes have internal damage in its conductors near where the lead screws in if the cable is old. If you remove the sparkplug from the engine then click it back into the sparkplug cap then you should see about 25 KOhms from the centre electrode in the tip of the sparkplug back through to the primary coil (the primary and secondary are joined on one leg and it is only 1 ohm between the primary coil). If you do not then check the spark plug has about 4-5 KOhm resistance from its centre electrode in the tip to the small threaded end. If it doesn’t e.g. it is open circuit then replace that sparkplug and hopefully that is your only problem.

If it is OK then unscrew the ignition lead from the ignition coil secondary. Now measure the ignition coil secondary from the screw tip that you can see poking out to the primary coil tabs. If this is not about 17 KOhm but open circuit then you have a broken ignition coil but if it is a few KOhms then check the part is the same – secondary on ignition coils can be different. You really only care about shorts i.e. zero Ohms or open circuit i.e. infinite KOhms. Replace this if it is clearly broken.

If this is OK then measure from the ignition lead core wires (which you can now see on the end you unscrewed from the ignition coil) to the sparkplug cap.  It should be about 5 KOhm. If not then unscrew the sparkplug cap from the ignition cable. It has a similar woodscrew deep inside it that you screw the ignition lead onto. The cable is a multi-core of fine wire and it may have frayed and broken internally. Measure its resistance and it should be zero ohms. Wiggle the cable –  internal breaks can be felt as a soft section that more easily moves than the rest of the cable. If the cable is OK then measure the sparkplug cap and it should be 5KOhm. If it is not then replace this. If that is OK then you are disturbing the break that you originally detected and it is probably in the cable where it screws in to the coil or sparkplug cap. You may have enough spare lead to cut off the end to get to unfrayed core wires, if not then you need some new ignition cable.

Checks – CDI

In my case I did all that but it wouldn’t fire.  Now you will have to remove the bike body covering to get at the CDI. I won’t describe that but you basically remove any helmet carrier on the rear, remove the read handhold, unscrew the rear light cluster, license plate holder, undo all the little screws under the seat, the big screws towards the lower front near the feet-stands and then slide the body panel back as one big mass. The CDI is on the right hand side with a 6-pin cable plug.

Unclip this and do the following checks by poking your multimeter probes into the socket,

  • BLUE is Earth – make sure it is and is zero ohms to the YELLOW/BLACK
  • WHITE/PURPLE goes to the Ignition coil primary – check it is zero ohms to that coil and that when the RED/BLACK is removed from the coil primary, that there is no shorts to ground or the RED/BLACK socket (here)
  • RED/BLACK goes to the 12VDC keyed off the ignition same as the power to the coil – so should be zero ohms to the battery positive.
  • YELLOW/GRAY goes to one side of the TDC sensor coil – there should be about 240 Ohms resistance between this pin to the YELLOW/BLUE
  • YELLOW//BLUE goes to the other side of the TDC sensor coil – see the YELLOW/GRAY cable.
  • YELLOW/BLACK is Earth so should be zero ohms to the engine frame.

If all those seem to be right then you are pretty well  left with one conclusion and that is the CDI itself is not working. This is fully sealed and cannot be repaired. Your best bet is to buy one second hand. Make sure you get the exact DENSO part number.

In my case the faulty unit had the WHITE/PURPLE signal which goes to the ignition  coil primary was always on as a ground signal. It should never be always on but pulse a ground. I can only guess it was shorted out inside the CDI. All that happened was that the ignition  coil would heat up.

Checks – firing sparkplug out of engine (caution)

This is a more dangerous check but I’ll include it for completeness. You can see if the sparkplug is sparking as follows,

  • remove sparkplug from engine and click back into the sparkplug plug. Feed the ignition lead and sparkplug to the right-hand side of the bike away from the open engine sparkplug hole and so you can see the spark when you fire ignition switch
  • Ideally fit a spare sparkplug into the engine sparkplug hole BUT if you do not then you must do this testing outside because petrol mist will leave the engine so you want a lot of ventilation
  • use a jumperlead to connect the sparkplug screw thread to the engine body. I use a battery jumper lead as these are very low resistance.
  • turn on the ignition and try to crank engine. You should see a bright blue-white spark pulses even in daylight. If you do then your starting problem is not ignition but perhaps fuel. If you get only ONE spark when the ignition is turned on then you have my problem of a shorted out CDI. If you get NO sparks then assuming your test setup is fine and you have tested all the other components then it is the CDI with a faulty open circuit.

Enjoy your bike riding !

wp-super-cache stale cache due to Apache permissions

This may happen to you in that web pages for anonymous users (i.e. not logged on) stay stale even when you use “Delete Cache” in WordPress dashboard and clear the data from your browser. The page contents stay stale and menus (if they were changed) stay on the old layout.

If this happens to you and you are pulling your hair out in testing and unable to get the pages to display on the new content then ssh into your server and check the permissions (ownership) of the /wp-content/cache is actually owned by the web server and has not been changed..

After a Plesk/Parallels upgrade (automatic I think) the user that Apache ran in changed and this meant that files that were previously created by Apache using the old user account were now not able to be deleted by the new Apache account user (www-data). This is probably never going to be seen on shared hosting but could be seen on virtual or dedicated servers.

The WordPress site would have kept dishing out the old file not matter what I did because the old cache files couldn’t be deleted.

The fix is easy (assuming your Apache installation is going to remain stable) and that is to ssh shell into your account and delete using the file owner (or root) the contents of the /wp-content/cache directory (which will have a “meta” and  supercache” subdirectories.

You may also be able to use your FTP client to do the same but probably the cache directory won’t actually be visible at all.

Once you have deleted all of that old stuff then go back into the wp-super-cache plugin settings and remove and then re-enable the cache settings.

Non-logged on browsers will now correctly display the site and the supercache/www.example.com/… files correctly build up with the ownership being the Apache web server.

To test this I use Firefox and Opera: Firefox is logged in and Opera is used to display the web site as an anonymous user. Opera has a nice feature in Opera -> Settings -> Delete private data that you can quickly clear the browser cache of everything.

Using host file changes to migrate a site

The simplest way of migrating a web site from one IP to another and testing it before changing your DNS is to just change a local test PC host file.

It varies by operating system but if you change the host file and make the new IP address point at e.g. www.example.com then you can install your new content management system and add the content at your leisure by just referring to it by its normal URL.  Everyone else in the Internet gets the old site on the old IP but you (and only you) gets the new site on the new IP.

Upload your content, edit and test it as usual.

You can also test POP3 and SMTP in this same way by editing your test PC hosts file to point at the new IP address for the POP3 and SMTP addresses e.g. pop3.example.com or even webmail.example.com.

When you are ready then simply change the DNS (@) A (and AAAA) records to the new IP addresses.

Do this in two steps,

1) switch the www and similar Web site related IP addresses but keep the webmail and MX records on the OLD IP address. If the web site works as expected (remember to remove any “test” entries in your test PC hosts files) then…

2) at a suitably idle time change the Webmail and MX records. Now test the incoming and outgoing email works. On any test machines make sure that a ping to the relevant record e.g. mail.example.com or pop3.example.com returns the expected IP address.

If it is fine then after a suitably long delay you can decommission the old web site. Do this as follows,

a) backup all databases – mark them as the OLD SITE
b) backup all web site content (media etc) – mark them as the OLD SITE
c) backup any other OS specific configuration files – mark them as the OLD SITE
d) delete the old site. How you do this will vary (delete containers on VPS or reformat a server disk on standalone machines or delete the files via FTP or ssh) but never leave it hanging around.

 

Telnet to web server testing

Simple TCP based connectivity testing of a web site e.g. via Pandora FMS or Telnet is possible but Apache and IIS work differently.

With Apache you can (using telnet as the example) connect to the host on port 80 then type in GET / HTTP/1.0 and hit return twice and you will get a HTTP/1.1 200 OK message

You won’t on IIS but you will get a HTTP/1.1 400 Bad Request message. To get the 200 message from IIS you need to send,

HEAD / HTTP/1.1^M
Host: www.yourdomain.name^M
^M

where the ^M is the return or enter key.

 

Multiple domain name selections

As a minimum we buy the three TLD, .com, .net and .org for a domain name.

With most registrars you can forward the emails and web traffic from the two you don’t use to your main site at no extra cost.

The value of the extra domains becomes apparent when you start adding e-Commerce or company blogs or test or administration sites. Whilst your main public-facing domain can be on e.g. the .com you can host test and development sites on the .net or .org.

With Open Mutual we have our .net as our main public facing web site, this .org as a “blog” and the .com is used for client hosting and is used for our business continuity testing.

Most hosting providers allow you to have multiple TLD (usually up to 10) on the same host (shared hosting reseller account or a V-server)  as well as countless subsites so the cost of running multiple TLD is just the cost of the registry fees (say an extra USD 20 per annum) plus extra time in administration of these extra domains.

If the domains are on completely different infrastructure (different DNS and servers) then the administration site can be used to advertise service status for the live domain.

Done right, the administration costs are neutral because when you are planning your business continuity you can deploy your backups onto the other domain names and hosting accounts without interfering with your live system or, equally, you can install new versions of software on the other domains and test the impact by comparing the live and test systems.