This blog has been down for about four months.
The blog was hacked, the protection I had in place wasn’t strong enough it
My bad, I was told that Windows Server 2003 was vulnerable especially with an open blog (open as in readers could post comments) and the blog paid the price.
To remedy the problem I had to move the www.diy-computer-repair.net web site and this blog to a newer Operating System that had the protection, namely a add on called WebDav where I can specify who can or can not alter web pages.
Why did it take so long?
The www.diy-computer-repair.net uses what the programmers call “includes”, this is a special file with formatting used to place common lines of text or images in certain places on each page, this gives the web site a continuity in the appearance, such as the logo image is in the same place on each page, or say the menu navigation on the top or bottom of each page.
When I decided to go from Windows Server 2003 (which I am quite familiar
with) to Windows Server 2008 or 2012 I knew I would have a steep learning curve. These newer (relatively speaking, the newest is Server 2019) operating systems are closely related to Windows 7 and Windows 8.
Having used Windows 7 for a about six years, knowing that I don’t like the file system or a few other things I would have to figure out how to make the newer version of IIS (Internet Information Services) do what I needed for the www.diy-computer-repair.net web site to function as it did with the older IIS 6.
I picked Windows Server 2008 R2 because it was the closest to Windows Server 2003 and Windows 7. However I will learn that the programmers have moved from the old way of doing things to a new way, the improvements are not with out hassle nor are they easy to use.
So for three or more long months I worked on getting the web site to work, one of the things that caused me the most heartburn, frustration, and irritation was the move of a programming technique called SSI (Server Side Included) with IIS 6 and below this was an added function to the installation of the service. That is you could choose to use it on not use it, if you added it to the configuration then all you had to do is enable or “Allow” it to work. If you used one of the commands in a web page the service would read the command when the page was requested by a browser and then format the page with the command
The include command is a formatted text inserted in the document when the creator writes it, the command normally calls another page or snippet of formatting and places it in the page, thus every page has the same logo, menu’s, and other information on each page with out the creator manually adding it to each page. If say I need to change something on a menu (like a new page or category) then I change one page that will show up on each page instead of going through over 800 pages to make the change.
This SSI function is disabled in both IIS 6 and the newer versions of IIS, I am using IIS 7.5, so I had to figure out why the included on each page would not function and fill out the page with the formatting you see when you read the page.
For IIS 6 the SSI worked with out any additional programming or “scripts”, however IIS 7+ didn’t work. So I had to do a bit, no make that a lot, of research to find out why this command: #include would not work on IIS 7+.
There are a lot of opinions on the internet; there are a lot of solutions also. However none of them worked, I took each opinion/solution and tried it on the IIS installation, some of them would cause other problems, some caused the IIS to stop working totally.
After the first failure I decided to not reinstall the OS after each attempt at getting the #include instruction to work. I made an image of the OS partition (using a Multiboot setup saved me a few hours of extra work when the OS crashed!) and would over write the failed OS with the original install.
One day I was searching on why the #include would not run when I saw a small blurb (the text in the search return) that said the SSI would not run a #include on a .html formatted page it had to be a .shtml so I clicked on the link to read what the author had to say.
Basically the programmers took the easy/lazy way out and left out the coding in the IIS program that looked through the text of the requested document that the browser wanted displayed for the reader. This coding from the IIS 6 version would read through the page and when the SSI was activated by the #include (and other commands) it would get the document by the name such as doc2.shtml or would format the command as requested. The code was left out or changed and now the only way the #include will work is if the complete page is formatted with the .shtml extension instead of the normal .html.
So to test this theory I wrote a test page with only the #include then put it on the web site and browsed it, the SSI worked! WOW!
Ok, that was great, however that left me with two options:
1. Move all the #include statements to another programming language such as .asp or java scripts (neither are in my programming tool box…)
2. Rename all the pages on the web site from .html to .shtml and go through all the pages and change each link to the old .html page to the new .shtml page.
I took the easy way out; I renamed all the pages to the extension .shtml, then using a old program I am quite familiar with to change all the links.
All of this took time, a lot of it… Good thing I am retired, eh?
Thus ends the saga of what happed to the blog:
I could have put the www.diy-computer-repair.net web site on the new server and then worked on the SSI non function while the site was live, however that is not how I work nor would that have been a good idea, so I left the old Windows 2003 Server with IIS 6 running until I figured out how to make the Windows 2008 R2 IIS 7+ work properly for the SSI, so if you see any broken links or problems use the blog to send me a message by comment.
Thanks for bearing with me on the missing blog…