gushi: (Default)

We've got a customer, actually a decent friend of mine too, who is getting plesk (one of those all-in-one hosting management tools). Except because he uses frontpage, he needs an older version of Plesk.

I get to installing it, and the installer complains "you have perl 5.008006 installed, you need perl 5.008007".

Okay, um...

I try looking for perl 5.8.7 -- the current version is 5.8.8, and the one that came with the OS is 5.8.6. For a VERY SHORT while there was a 5.8.7 available. The installer doesn't like 5.8.8 (grr!!).

I try modifying the installer -- to tell it "you want 5.8.8". No good. The installer has an embedded checksum -- and it breaks my head as to how to even CREATE a file that has an embedded checksum, since changing the checksum CHANGES THE FILE, and thus CHANGES THE CHECKSUM.

I look on the FreeBSD archive mirror (where old releases are kept in their entirety (linux could learn something from this)) -- and I find a perl 5.8.7 tarball here:

ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/6.0-RELEASE/packages/lang/perl-5.8.7.tbz

Except that when I install it, it dies a horrible death because it's a 6.0 package, and doesn't have the right library links.

Okay, fine. Cracks Knuckles

I go cruising through the FreeBSD cvsweb repository, find the exact date that things got upped from 5.8.7 to 5.8.8, then I unleash this:


cvs co -D '12/23/2005' ports/lang/perl5.8
cvs server: Updating ports/lang/perl5.8
U ports/lang/perl5.8/Makefile
U ports/lang/perl5.8/Makefile.man
U ports/lang/perl5.8/distinfo
U ports/lang/perl5.8/pkg-descr
U ports/lang/perl5.8/pkg-message
U ports/lang/perl5.8/pkg-plist
cvs server: Updating ports/lang/perl5.8/files
U ports/lang/perl5.8/files/patch-MM_Unix.pm
U ports/lang/perl5.8/files/patch-SDBM-errno-fix
U ports/lang/perl5.8/files/patch-freebsd.sh
U ports/lang/perl5.8/files/patch-perl.c
U ports/lang/perl5.8/files/perl-after-upgrade
U ports/lang/perl5.8/files/use.perl

Oh, Hello, Newman. I cd into the directory, build, kill of any previous versions, and install.

I take somewhat pride in the fact that nobody else, period, could have done this. We've got one other tech with possibly the skill, but there's more BSD-centric knowledge required.

gushi: (Default)

We've got a customer, actually a decent friend of mine too, who is getting plesk (one of those all-in-one hosting management tools). Except because he uses frontpage, he needs an older version of Plesk.

I get to installing it, and the installer complains "you have perl 5.008006 installed, you need perl 5.008007".

Okay, um...

I try looking for perl 5.8.7 -- the current version is 5.8.8, and the one that came with the OS is 5.8.6. For a VERY SHORT while there was a 5.8.7 available. The installer doesn't like 5.8.8 (grr!!).

I try modifying the installer -- to tell it "you want 5.8.8". No good. The installer has an embedded checksum -- and it breaks my head as to how to even CREATE a file that has an embedded checksum, since changing the checksum CHANGES THE FILE, and thus CHANGES THE CHECKSUM.

I look on the FreeBSD archive mirror (where old releases are kept in their entirety (linux could learn something from this)) -- and I find a perl 5.8.7 tarball here:

ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/6.0-RELEASE/packages/lang/perl-5.8.7.tbz

Except that when I install it, it dies a horrible death because it's a 6.0 package, and doesn't have the right library links.

Okay, fine. Cracks Knuckles

I go cruising through the FreeBSD cvsweb repository, find the exact date that things got upped from 5.8.7 to 5.8.8, then I unleash this:


cvs co -D '12/23/2005' ports/lang/perl5.8
cvs server: Updating ports/lang/perl5.8
U ports/lang/perl5.8/Makefile
U ports/lang/perl5.8/Makefile.man
U ports/lang/perl5.8/distinfo
U ports/lang/perl5.8/pkg-descr
U ports/lang/perl5.8/pkg-message
U ports/lang/perl5.8/pkg-plist
cvs server: Updating ports/lang/perl5.8/files
U ports/lang/perl5.8/files/patch-MM_Unix.pm
U ports/lang/perl5.8/files/patch-SDBM-errno-fix
U ports/lang/perl5.8/files/patch-freebsd.sh
U ports/lang/perl5.8/files/patch-perl.c
U ports/lang/perl5.8/files/perl-after-upgrade
U ports/lang/perl5.8/files/use.perl

Oh, Hello, Newman. I cd into the directory, build, kill of any previous versions, and install.

I take somewhat pride in the fact that nobody else, period, could have done this. We've got one other tech with possibly the skill, but there's more BSD-centric knowledge required.

gushi: (Default)

Okay, at work one of our biggest requests is in dealing with customers who are having routing issues to their servers.

In order to diagnose this, we use a program called traceroute (as defined in RFC 1393)

I.e. to get from point A to Z, packets may GO A-B-C-D-Z, and might return a completely different way, like Z-Y-X-B-A. BOTH matter, since bidirectional communication is important. I.e. a delay in EITHER direction will cause problems, and it's difficult to diagnose whether the problem is in sending, or receiving.

When a customer submits a support request, While it's a trivial task to find out what their IP is, and do a trace OUT to them, more often than not that gives us only half the picture. To be accurate, we need to see what way packets are flying in BOTH directions.

So I came up with a neat idea, but I can't find the component I need.

Put the traceroute IN the browser, so that when a client goes to submit a trouble ticket, the system loads a CLIENT SIDE traceroute app, and on-the-fly, gets a traceroute from the customer's view, IN...and then also does a server-side traceroute, outbound.

The problem is, I can't find a java/javascript/activeX traceroute tool that I think is workable. Anyone else have any ideas?

-Dan

gushi: (Default)

Okay, at work one of our biggest requests is in dealing with customers who are having routing issues to their servers.

In order to diagnose this, we use a program called traceroute (as defined in RFC 1393)

I.e. to get from point A to Z, packets may GO A-B-C-D-Z, and might return a completely different way, like Z-Y-X-B-A. BOTH matter, since bidirectional communication is important. I.e. a delay in EITHER direction will cause problems, and it's difficult to diagnose whether the problem is in sending, or receiving.

When a customer submits a support request, While it's a trivial task to find out what their IP is, and do a trace OUT to them, more often than not that gives us only half the picture. To be accurate, we need to see what way packets are flying in BOTH directions.

So I came up with a neat idea, but I can't find the component I need.

Put the traceroute IN the browser, so that when a client goes to submit a trouble ticket, the system loads a CLIENT SIDE traceroute app, and on-the-fly, gets a traceroute from the customer's view, IN...and then also does a server-side traceroute, outbound.

The problem is, I can't find a java/javascript/activeX traceroute tool that I think is workable. Anyone else have any ideas?

-Dan

May 2017

S M T W T F S
  123456
78910111213
14151617181920
21222324252627
28293031   

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 26th, 2017 02:31 am
Powered by Dreamwidth Studios