Data Center Hub

Internet Data Center and Hosting News and Views

Installing CartIt and PERL modules on Windows IIS 6.0

Filed under: Servers — Bill Laakkonen at 10:12 pm on Thursday, April 26, 2007

On Windows Server 2003 with IIS 6.0 when trying to run a perl CGI (cartit.cgi) which has

use Crypt::SSLeay;

I get the error: “Can’t load ‘C:/Perl/site/lib/auto/Crypt/SSLeay/SSLeay.dll’ for module Crypt::SSLeay: load_file: access is denied” in the web browser after first installing Crypt-SSLeay.
I had already installed a precompiled Crypt-SSLeay package for Windows from: http://theoryx5.uwinnipeg.ca/ppmpackages/

Testing the script from a command prompt gave expected results with no error messages but it refused to run from IIS.

It seemed as if this was a permissions issue, however, based on my solution- it may be the source was linked to some dependency of OpenSSL as it was a requisite for the machine which compiled the Crypt-SSLeay Perl module I am using.

This one had me going around for a bit. Here is what I found. You must install the binary OpenSSL for Windows before installing Crypt-SSLeay otherwise the results will not be what you expect. So if you installed Crypt-SSLeay without FIRST installing the OpenSSL
binary version, you will need to remove the package in PPM. You should then install OpenSSL from a source listed here: http://www.openssl.org/related/binaries.html and finally reinstall Crypt::SSLeay from command prompt as below:

C:\ppm install http://theoryx5.uwinnipeg.ca/ppms/Crypt-SSLeay.ppd

I uninstalled the PPM, installed the OpenSSL binary version, and finally reinstalled Crypt-SSLeay again. Now at the command prompt when I run the script I get a dialog box stating:
“MSVCR71.dll was not found. Reinstalling the application may fix the problem.”

At which point I went to dll-files.com and downloaded the msvcr71.dll file and placed it in a folder that is in the path (Thanks dll-files.com!). Now the script works from the IIS web server as well as the command prompt.

Saving a dying or damaged hard drive

Filed under: Servers — Bill Laakkonen at 6:52 am on Wednesday, April 25, 2007

There are times when drives start to kick out hard read errors. On FreeBSD and most UNIX-like operating systems, you get the errors logged so you have a heads-up before the drive simply dies. With the exception of power surges, ESD, and lightning strikes, hard drives seldom die instantly. They most often carp warnings on errors while continually reallocating data to good sectors silently for days or weeks before giving up completely. Once you see hard error messages though, it is time to replace the drive. Don’t reboot the system if it is running and complaining; rather instead get your new drive prepared by doing a base install of the same version OS with similar partitioning and slices of equal size or greater. Then shut down the system. I usually do not try to fsck the drive if the system has not crashed (in the case of hard errors the drive can no longer tell the good sectors of the disk from the bad sectors -so don’t run fsck as it worsens the data loss). After the new drive is prepared in a new machine, you should be ready to try copying the data over from the old. The information here covers rescuing a FreeBSD system but the basic steps should apply to any OS. It’s not meant to be a step-by-step howto but rather a general overview of the process with some details omitted. If you’re attempting to save a drive, you should already have some detailed knowledge of the process involved so take your steps carefully to avoid data loss. When the machine is still running (and it’s a UNiX-like OS) you may want to try a dump of the file systems over the network to a machine with sufficient capacity for the job. For speed however, copying locally seems to be much faster.

I tend to use dd for saving damaged drives by copying the contents of the old drive to a new one. If you have had a serious amount of errors (and lots of time) you can also try the spinrite program to recover data but if you have hard errors you should simply try to get data off drive as fast as possible using dd to do a sector by sector copy.

We use the dd switch ‘conv=noerror’ to prevent it from dieing on errors and ’sync’ to pad input block to the input buffer size. Don’t specify a block size (bs) with no conversion values other than ‘noerror’, ’sync’, and ‘ntrunc’ and you should have no aggregation of short (empty) blocks which might be safer for copying partitions.

  1. Do a base install of target OS so you have the partitions ready first or manually create partitions.
  2. Boot in single user mode. (boot –s) freebsd
  3. Use dd if=/src of=/dest conv=noerror,sync where src is for example /dev/ad0s1g

Mounting and fscking a bad FS seems to only make the drive worse. Move off data ASAP and then tend to the bad/missing files.

Data transfer from IDE to IDE proceeded for me at about 1.9 MB per second with the bad drive in place so copying 60G of data may take a full workday to copy this way.

Other things to try (Linux):

http://www.garloff.de/kurt/linux/ddrescue/

http://www.kalysto.org/utilities/dd_rhelp/index.en.html A front end for dd_rescue

http://www.simplicidade.org/notes/archives/2005/02/recover_day.html a dd_rescue story

Also you can try this:

Install the new drive in the computer either with the existing drvie as the master or do a fresh base install of the new OS same version as you are replacing.

Boot single user at: ok boot –s

Hit enter for /bin/sh shell, fsck –yp, mount –u / , mount –a , swapon –a

Run sysinstall from /stand/sysinstall or /usr/sbin/

Go to Configure-> Fdisk and add the new drive device. (eg ad2 for secondary master)

In fdisk chose A for auto defaults for entire disk, enter Q to quit

Install standard boot manager when prompted

Returning to sysinstall choose Label for disklabel

Copy the label as closely as possible from the original fstab in /etc/fstab

Create your new partitions on the new drive and use M to re-label / (eg /dev/ad2s1a) only mount point to /mnt and all others as regular /var, swap, and /usr. Type Q to quit and exit sysinstall

Now mount the new file systems eg:

mount /dev/ad2s1a /mnt

mount /dev/ad2slf /tmp

mount /dev/ad2s1g /usr

mount /dev/ad2s1e /var

copy the existing filesystem using tar

# tar –cfk - –one-file-system –ignore-failed-read –C / –exclude=’mnt/*’. | tar –xpvf – C /mnt

# tar –cfk - –one-file-system –ignore-failed-read –C /usr . | tar –xpvf – C /mnt/usr

# tar –cfk - –one-file-system –ignore-failed-read –C /var –exclude=’mnt/*’. | tar –xpvf – C /mnt/var

Shutdown and remove the old drive. Boot the new one single user and fsck it fsck –p and mount it. Reboot and all should be well again.

Generating Directions from Google maps on a website

Filed under: SEO — Bill Laakkonen at 9:18 pm on Tuesday, April 17, 2007

I was asked by a customer today to add driving directions to live classes listed on their website.

It seemed a job tailor made for the Google Maps API so I went ahead and got an API key to start developing a test page. While the API offers many features, the one I needed- routing and driving directions- is not part of the actual API (correct me if I’m wrong).
It turns out to be dead simple to implement driving directions by simply creating a form which does a GET to maps.google.com/maps and having the form open a new window using target=”_blank” (yes, I know this is deprecated but on a production site you sometimes must “engineer” a solution which works even if not 100% standards compliant).

For my client’s site, all the class locations are already in a database and the pages are generated from there so all I needed to do was write a few lines of code.

Of course if you only need one destination address such as your office you can simply hard code the value into the destination address (named daddr) field.

Here is an example of how to get to the Saint Lucie County Fairgrounds.

Show me directions to the Saint Lucie County Fairgrounds in Fort Pierce, FL (Opens a new window).

Here is the live site where I implemented Google Maps driving directions:

http://www.educationprograms.com/safefood/store/index.php

The code is not the prettiest around but it does work. You should be able to view the source to quickly see how the form works.

Ciphertext does not begin with a valid header for ’salt’ header mode at ./verify_install.cgi line 621

Filed under: Servers — Bill Laakkonen at 7:20 am on Friday, April 13, 2007

Installing OpenSRS RCL Version 2.95 gives the following error:

Ciphertext does not begin with a valid header for ’salt’ header mode at ./verify_install.cgi line 621

This occurs because CRYPT CBC 2.17 and higher use salt by default. The OpenSRS scripts need to use randomiv headers.

Solution: edit your CBC.pm file to use randomiv as the default header.

In the CBC version 2.2 CBC.pm change line 55 to use randomiv instead of salt as the default.
50 # header mode
51 my %valid_modes = map {$_=>1} qw(none salt randomiv);
52 my $header_mode = $options->{header};
53 $header_mode ||= ‘none’ if exists $options->{prepend_iv} &
& !$options->{prepend_iv};
54 $header_mode ||= ‘none’ if exists $options->{add_header} &
& !$options->{add_header};
55 $header_mode ||= ’salt’; # default

new line 55 should read:

55 $header_mode ||= ‘randomiv’; # default

and of course you should now find this error resolved. Hopefully you don’t have others as well. :-)

Limiting Brute force SSH attempts with denyhosts

Filed under: Servers — Bill Laakkonen at 7:12 am on Friday, April 13, 2007

I sometimes tire of the constant amateur brute force attempts to break into my machines. One of the ways to limit these attempts in FreeBSD 6.X and PC-BSD as well as other UNIX like OS machines is by using denyhosts from within tcpwrappers in inetd. denyhosts can be configured to automatically deny SSH or ALL services to a particular host which is busily banging away at an attempt to break into your machine. Naturally, good strong passwords are the best way to limit the possibility of brute force breakins. But denyhosts also has the benefit of simply cutting them off and I like that.
On PCBSD you have denyhosts already set up for use except for changing the name of the default config file. On standard FreeBSD you’ll need to add denyhosts from ports or packages (see further down). Depending on your Linux distro you may already have it. You’ll have to research that on your own and remember the file locations here are for FreeBSD.
cp /usr/local/share/denyhosts/denyhosts.cfg-dist /usr/local/share/denyhosts/denyhosts.cfg

then

vi /usr/local/share/denyhosts/denyhosts.cfg

to check the defaults. I allowed mine to fetch data from the sync server

# To enable synchronization, you must uncomment the following line:
#SYNC_SERVER = http://xmlrpc.denyhosts.net:9911

then /usr/local/etc/rc.d/denyhosts.sh start

[root@PCBSD /usr/ports/lang/php5]# tail -f /var/log/auth.log
Apr 13 08:30:54 PCBSD sshd[84345]: Failed password for root from 69.15.145.108 port 55955 ssh2
Apr 13 08:30:55 PCBSD sshd[84347]: Failed password for root from 69.15.145.108 port 55986 ssh2
Apr 13 08:30:56 PCBSD sshd[84353]: Failed password for root from 69.15.145.108 port 56017 ssh2
Apr 13 08:30:57 PCBSD sshd[84355]: Failed password for root from 69.15.145.108 port 56048 ssh2
Apr 13 08:30:57 PCBSD sshd[84357]: Failed password for root from 69.15.145.108 port 56079 ssh2
Apr 13 08:30:58 PCBSD sshd[84359]: Failed password for root from 69.15.145.108 port 56110 ssh2
Apr 13 08:30:59 PCBSD sshd[84361]: Failed password for root from 69.15.145.108 port 56140 ssh2
Apr 13 08:31:00 PCBSD sshd[84367]: Failed password for root from 69.15.145.108 port 56173 ssh2
Apr 13 08:31:01 PCBSD sshd[84369]: Failed password for root from 69.15.145.108 port 56203 ssh2
Apr 13 08:31:01 PCBSD sshd[84371]: twist 69.15.145.108 to /bin/echo “Server sshd denied from 69.15.145.108″

as you can see from the logs- it stopped an attempt within seconds.

denyhosts contains the deamon log entries.

[root@PCBSD /usr/ports/lang/php5]# tail /var/log/denyhosts
2007-04-13 10:36:38,269 - denyhosts : INFO send daemon process a TERM signal to terminate cleanly
2007-04-13 10:36:38,269 - denyhosts : INFO eg. kill -TERM 92229
2007-04-13 10:36:38,272 - denyhosts : INFO monitoring log: /var/log/auth.log
2007-04-13 10:36:38,273 - denyhosts : INFO sync_time: 3600
2007-04-13 10:36:38,274 - denyhosts : INFO daemon_purge: 600
2007-04-13 10:36:38,275 - denyhosts : INFO daemon_sleep: 30
2007-04-13 10:36:38,276 - denyhosts : INFO purge_sleep_ratio: 20
2007-04-13 10:36:38,276 - denyhosts : INFO denyhosts synchronization disabled
2007-04-13 10:46:38,310 - denyfileutil: INFO purging entries older than: Fri Apr 13 10:26:38 2007
2007-04-13 10:46:38,313 - denyfileutil: INFO num entries purged: 0

this is configured by /etc/hosts.allow - make sure you have these entries:

# denyhosts
sshd : /etc/hosts.deniedssh \
: severity auth.info \
: twist /bin/echo “Server %d denied from %h”
: deny
sshd : ALL : allow

If you’re not familiar with twist, it is part of tcpwrappers. The twist directive replaces the requested
service with some other actions. You can also expand with this directive to include the daemon process (%d) and host name (%h)

See the docs at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/tcpwrappers.html
for more details.

On standard FreeBSD 6.x you should find denyhosts in /usr/ports/security/denyhosts or you may add it as a package with
pkg_add -r - you’ll still need to rename the dist config file as above.

Good luck and may your log files now be shorter.