Very Computer

Hello,

After doing a serious upgrade of my system via cvsup (4.1 to 4.3
stable) some software I was running required a new license code
entering before I could use it again.

I contacted the author and got a new code but this solution isn't very
satisfactory if I upgrade with any regularity.

The guy who gave me the code told me it's a standard unix protection
system which is used to register the software but he didn't know much
about it.

The software used to run on SCO Xenix/Unix and got re-jigged to run on
FreeBSD v2.2.x.

Is there any way around this problem?

Jim.

Did you install the compat22 distribution?

Those who run mission critical operations apply upgrades in a
disciplined manner -- in response to requirements,  with a
thorough understanding of the effects of the upgrade.  Yes,
kernel and base system and ports changes often break existing
applications and systems software.

I would think that it depends on how it knows that it is working on a
new system.  Maybe it uses the uname command to figure this out.  You
could keep the old uname, and somehow fool the program into using the
old one (maybe passing it some different $path variable).

--
Stephen Montgomery-Smith

http://www.math.missouri.edu/~stephen

On Wed, 25 Jul 2001 17:20:48 -0700, Michael Sierchio

Yes I had to install this to run the program in the first instance.
There was a newer version of compat22 though. Could this be it?

Jim.

On Thu, 26 Jul 2001 00:32:05 GMT, Stephen Montgomery-Smith

I've re-configured to use my own kernel instead of the generic one
previously without encountering this problem. If uname was the key I
think I would have encountered the problem earlier.

I'm told that it's a "standard" unix protection system not just his
own proprietary protection.

Jim.

Hello,

Quote:> I'm told that it's a "standard" unix protection system not just his
> own proprietary protection.

Conventional unix license management solutions make use of the
machine's host ID (look at the command 'hostid'), which is normally
generated from the MAC address of the primary ethernet card. So, if
you didn't change your ethernet card this shouldn't have caused a
problem, unless hostid itself has changed its implementation as part
of your upgrade.

HTH,

John...

Quote:>Hello,

>> I'm told that it's a "standard" unix protection system not just his
>> own proprietary protection.

>Conventional unix license management solutions make use of the
>machine's host ID (look at the command 'hostid'), which is normally
>generated from the MAC address of the primary ethernet card. So, if
>you didn't change your ethernet card this shouldn't have caused a
>problem, unless hostid itself has changed its implementation as part
>of your upgrade.

I tried man hostid but there's no manual entry.

Incidentally, when I started using this software a few years ago it
was on a sco xenix system and that didn't have an ethernet card, just
bank after bank of serial ports. The licensing system is the same now
as it was then.

Jim.

Yep. There's no such command in FreeBSD.  You may want
to look at 'sysctl kern.hostid' which is by default set to 0.

Quote:> Incidentally, when I started using this software a few years ago it
> was on a sco xenix system and that didn't have an ethernet card, just
> bank after bank of serial ports. The licensing system is the same now
> as it was then.

Quote:>After doing a serious upgrade of my system via cvsup (4.1 to 4.3
>stable) some software I was running required a new license code
>entering before I could use it again.

>I contacted the author and got a new code but this solution isn't very
>satisfactory if I upgrade with any regularity.

>The guy who gave me the code told me it's a standard unix protection
>system which is used to register the software but he didn't know much
>about it.
>The software used to run on SCO Xenix/Unix and got re-jigged to run on
>FreeBSD v2.2.x.
>Is there any way around this problem?

Not until we no more about the software in question. I've seen many
different methods used on many different aps on SCO.  There has
never been a 'standard unix protection system' per se. There are
many different licensing schemes in use.

--

Then it could be almost anything.  I support a lot of SCO Xenix
systems years ago.   Some depended on an inode of a particular file
when installed as the license encoded that into it.  Other looked
a checksums.  

--