Wednesday, December 12, 2007

Paranoia is a sign of insanity

Actually, I find the requirement for an eight character password for blogger very tedious to remember. Why on earth Google should insist on such a long password is beyond my understanding. This is just a blog after all. Who the heck would want to hack into someone's blog?

When users ask me for security to prevent fraud with real money - they are always satisfied with a four-character password. When they forget their password no-one is able to recover it. No one of our users, that is. What I am saying is that a 'weak' password is a good enough deterrent for most applications. Blogger is not a bank.

For this reason, and also because blogspot.com is not my own domain, I have moved 'Dear User' to a new server. From now on all updates to Dear User will be at:
http://dearusr.shoso.com

Friday, November 9, 2007

Slow reboot

Support: Reboot the computer
User: Ok
User: It says no signal
Support: Ok that's normal when it starts rebooting
User: Ok
...after a while...
Support: Has it rebooted yet?
User: No, it still says no signal
Support: How did you get it to reboot?
User: I pushed the button in front of the computer
Support: Well, push the same button again to turn the computer on.

Thursday, November 1, 2007

Data loss due to backup

Here's a new one. A user calls reporting that she cannot get into her program. The error message indicates that the data cannot be found. Doing a search of the server computer proves that the files do not exist - not even in the recycle bin.

The user explains to me what happened: "I did a backup last night and it took for ages so I left it to run over night. This morning it asked if I wanted to delete the files and I said 'yes'."

I don't know what program was used to make the 'backup', but I just hope that the CD onto which the data was copied can be restored.

Tuesday, September 18, 2007

Too much to read

Support: This new program is quite different, I will email the instructions to you.
(later)
User: I received the instructions, but is still doesn't work.
Support: Did you read the instructions?
User: No, I printed them out but there are six pages.

Selective hearing

Support: Type the two words, net use, and press enter.
User: Is net use one word or two?

Thursday, September 13, 2007

Blissful trust

I received an email from one of my users the other day. It said: "We have just realized that we do not make back-ups every night. Please confirm what we must do to back-up every day - after hours."

This is from a company that has been relying on our software for inventory and accounting for many years, keeping track of about R25m worth of jewellery. I know that they were doing backups in the early days because I set up an automatic backup for them. But as time passed, workstations changed and so did the confidence level in the computer system. I doubt that anyone at the company has been taking responsibility for securing the data - the email seemed to prove that.

I used to worry about data backup, and frequently send messages to all our users reminding them of the importance of a daily backup. But I know that only a few actually did do the daily ritual. Most did it only once per month. A few never made a backup at all. But, thank goodness, progress is enabling me to effectively eliminate the risk.

All our bigger users, and some of the smaller ones, are now installing Linux servers and have ADSL connection to the Internet. So now, as a service to our users, we keep a backup of their data on our servers - automatically updated every night. If the user does not want to pay for this service, that is all right - we offer to restore their lost data for a fee, or they can pay a fixed monthly amount and get the restores for free. Strangely, not one of our users seems concerned that I have access to all of their data.

In response to the aforementioned email, I replied with assurance that I am doing nightly off-site backups, and offered her, free of charge, a daily email showing the backup job statistics as confirmation of each job.

The response to my email surprised even me. It said: "Thanks !!! It is not necessary to send me the Log every day. I am sure it will be ok."

Monday, September 3, 2007

Fairy tale support

The following is a true story. Only the facts are speculative. The user relates the story:

Friday, 31st August 2007, 6 pm. It is month-end again. I must run the month-end process on the computer so that the program will allow transactions dated 1 September. The program reminds me that I must be sure to have a backup before I run the month-end process, but it is not worth the trouble. In 15 years I have never needed to use a backup and anyway I have the software support agreement which includes repairing corrupted data.

I have been running this system for over 15 years, Norman has always looked after the program, I can rely on him. But this old computer network - it seemed fast 15 years ago but now it seems slower - takes several minutes to run the month-end process. work on another program on the spare workstation while waiting.

I realised immediately that the other workstation was still busy when I absent-mindedly restarted the server. After allowing the server to come up, a check proved that the process had been interrupted. The program will not allow entry into September and it will not allow the month-end process to be run again. Oops! But thank goodness I pay a monthly fee for software support, that's my insurance against problems like these, so it is not a serious problem. I'll just call Norman.

Hello Norman, I did a stupid thing and rebooted the server while the monthend was being run and now it won't let me do anything. Backup? No I didn't make a backup. Ok, I'll leave the modem on.

Saturday, 1st September 2007, 8:30am. I see the computer is all right now. Norman must have fixed the problem like I thought he would. I knew I didn't need a backup."

End of story. Start of lesson.

Repairing the aborted month-end run requires intimate knowledge of the program, as well as access to the data by modem and enough time. It is a lot quicker and safer to restore from backup than to mend half-updated files. And what if the hard drive had to fail? The best way to teach the importance of backups is to let the user lose some data - even a day's worth of new data lost would be remembered for a long time.

For a few hours I thought the above repair would be impossible and I was concerned about how to handle the situation because I was unable to connect to the client for more than a minute at a time without the dialup connection being dropped. Fortunately after midnight I was able to stay connected, made a backup onto a temporary directory (I always do that before starting a repair in case I make a mistake), repaired the database and reran the month-end process. Then completed the repair of the database to correct files that were updated twice. Being satisfied that everything was now correct, I disconnected at about 2 am. I was lucky and I was sure that the user will think the good elves had fixed the program while he slept.