SCO 5.0.7 re-branding after Edge recovery
Don Yakubowski
license. Have been evaluating Microlite Edge
01.02.04 with it and did a recovery using RecoverEdge to re-load system onto
a repl hard drive. As Edge can't deal with the
nodelock and related licensing files during the recovery to reproduce a
licensed system, I now need to re-brand or re-license
this repl hard drive.On startup, the /etc/sco_pmd licensing daemon complains
"can't open nodelock database" . In Single User
mode , the "brand -L" won't list any license info, and likewise any attempt
to re-brand the system returns an error
"brand:Error:could not open nodelock file ( -50 )" .
Man page on brand has no ref to return code (-50).
Any ideas as to how to re-brand this system or why nodelock file is
inaccessible?
--
Don Yakubowski
Tri-Comp Systems Ltd.
KDF11-A
Don,
I too am seeing a similar problem. I have written an automation
script that I use to install SCO on many machines. This script
then rebadges the system with the newly chosen uname/license
number/license data/etc. This has worked beautifully in the past
on as many as 100 5.0.6 systems, but I'm getting the same errors
you are with a 5.0.7 machine.
I'm posting this reply so that folks know it's not only a MicroLite
problem. Maybe a few more eyebrows will raise because of it.
Any help from anyone would be greatly appreciated.
Thanks in advance,
Shawn Breeden
--
Posted via http://dbforums.com
Guy Goodman
We did a fresh install of 5.0.7 and policy manager works
ps -ef|grep pmd shows it is running and
we can stop it /etc/sco_pmd -s
and we can start it /etc/sco_pmd
But when we create a root and boot and full cpio of the fresh system
and then
do a full restore from it. Then reboot to our new restored system the
sco_pmd fails to start and we get the message that " SEVERE no
nodelock database"
and "ERROR Failed to build license list"
We are unable to start /etc/sco_pmd manually and we are unable to run
scoadmin license ( it fails with message).
#cd /usr/lib/netls/conf
#ls -l licmap.db nodelock
indicates that the symbolic links are there as
licmap.db -> /var/opt/K/SCO/Unix/5.0.7Hw/pmd/licmap.db
nodelock -> /var/opt/K/SCO/Unix/5.0.7Hw/pmd/nodelock
and doing a
#ls -lL licmap.db nodelock
indicates that the files are owned correctly as root:root with
permissions 664
It seems that the restore process impacts the symbolic links wwhere
sco_pmd goes to find nodelock and licmap.db. Basically nodelink and
licmap.db cannot be found and so /etc/sco_pmd fails to start.
In a fresh system you can ( with care) copy nodelock from
/usr/lib/netls/conf to root. and also rename it within the
/usr/lib/netls/conf directory and then run
/etc/sco_pmd and it will fail. Since nodelock is not where it is
supposed to be , it cannot start and you get the same errors as above
.
But you can start it using the -N option. /etc/sco_pmd -N /nodelock
forces it to find the nodelock file in / .
But this is on a fresh install that was working anyway.
On the restored server, sco_pmd is unable to find the nodelock file
via its symbolic links and so never starts. I tried copying nodelock
to / and tried the -N option but it still failed. Tried several
restores on different systems and had no luck. Reported the issue to
sco support.
Will keep others informed.
Guy Goodman
MPA Systems - Australia
KDF11-A <membe...@dbforums.com> wrote in message news:<2883967.1...@dbforums.com>...
KDF11-A
Guy,
Thanks for the very informative reply. I've pretty much tried
everything you have with the same results. It's acting almost like
Window$ XP does with new hardware... even though the hardware may
not be new. If memory serves me correctly, cpio in 5.0.6 had some
bugs in it. I wonder if the same problem exists in 5.0.7 and we're
seeing the ramifications of it. When running integrity on the
system nothing really seems out of place or wrong.
I would greatly appreciate any info you pass on from SCO... unless
they're too busy to answer with all the lawsuits they're going for. :o)
Thanks again,
Guy Goodman
It is indeed an issue within the sco_pmd operation.
And not with the cpio as you indicaed ( well I dont think so ).
SCO Tech support are aware of it.
SCO Support are releasing a new forthcoming SLS that will resolve the
issue.
Our engineers tested the restore from a root/boot and full cpio of a
system
that had this test SLS applied to the kernel and the restored server
was able to start /etc/sco_pmd without failure.
I believe that they will be also publishing a new Technical Article
(TA) advising customers of this error and that work is in progress on
an SLS to address this issue. I am not able to pass on the SLS that I
tried as it is yet untested and unreleased by SCO. My hands are tied.
For others that read this - please note that while the sco policy
manager rarely fails there can be potentially other reasons why the
/etc/sco_pmd may fail to start and the reasons should be thoroughly
investigated before you presume it be related to the symptoms
described in these notes.
In fact openserver 5.0.7 policy manager is much stronger than ealier
versions and everyone should read the latest release notes at Late
News at http://www.sco.com/support/docs/openserver/ before attempting
to do a fresh install of 5.0.7 via an upgrade /trade-in licensing
path. See the notes relating to upgrade licenses.
Happy to help,
Guy Goodman
KDF11-A
Guy,
You are correct. While further looking into this myself, I found
that the sco_pmd file was having trouble.
I appreciate your passing the good news on to all of us from SCO.
KDF11-A
Don/Guy,
Have you heard any more on this issue?
Just thought I'd check in.
Thanks,
Shawn
Don Yakubowski
TA# 120624 is there now that suggests ksl.disable may be the root of the
problems, but
no solution is yet available.
I have been away from the issue for awhile and now am redoing the same Edge
Recovery testing I started way back,and will re-verify the Edge recovery
behaviour and the resulting sco license problem.
If editing /etc/default/boot will fix it, great. Unitl we get a proper SLS
for it.
Don Yakubowski
"KDF11-A" <membe...@dbforums.com> wrote in message
news:2982111.1...@dbforums.com...
KDF11-A
Don,
I can't find that TA# on SCO's site (although I'm not surprised...
I couldn't find oss656a on there today either). Could you post the
article, or the URL to the article if possible?
Thanks a bunch,
Shawn
Originally posted by Don Yakubowski
> I wasn't aware of Guy's post back in May about the sco_pmd
> problem. I see a
> TA# 120624 is there now that suggests ksl.disable may be the
> root of the
> problems, but
> no solution is yet available.
>
> I have been away from the issue for awhile and now am redoing the
> same Edge
> Recovery testing I started way back,and will re-verify the Edge
> recovery
> behaviour and the resulting sco license problem.
> If editing /etc/default/boot will fix it, great. Unitl we get a
> proper SLS
> for it.
>
> Don Yakubowski
>
> "KDF11-A" wrote in message
> news:2982111.1...@dbforums.com"]news:2982111.1055188530@d-
> bforums.com[/url]...
> > Don/Guy,
> > Have you heard any more on this issue?
> > Just thought I'd check in.
> > Thanks,
> > Shawn
> > --
> Posted via
http://dbforums.com/http://dbforums.com
D. Thomas Podnar
The disaster recovery / replication issue lies in 5.0.7.
SCO has been working hard to provide a patch for this issue
and we've worked with them to test it.
It is called OSS656B and I would consider it a mandatory install
on every 5.0.7 system installed. Note that this will replace
OSS656A which is not the right patch for this issue.
SCO has assured me that it should will be placed on their ftp
site within a very short period of time.
After installing OSS656B, the next system backup will be
OK for disaster recovery or site replication. There is no need to
regenerate your RecoverEDGE or other DR media.
Note for BackupEDGE users.
==========================
BackupEDGE SS release 01.02.04 is the first release that supports
OSR 5.0.7. Users that have done an in-place update of a previous
release of OpenServer may not be aware of this. You'll need to
update to 01.02.04 (or later if you are searching news at a later
date) and regenerate your RecoverEDGE media to protect your systems
properly.
--
Best Regards,
Tom
---
D. Thomas Podnar - President t...@microlite.com
Microlite Corporation 724-375-6711 Voice
2315 Mill Street 724-375-6908 Fax
Aliquippa PA 15001-2228 888-257-3343 Toll Free Sales
+-----------------------------------------------------------+
| Makers of |
| BackupEDGE SS - Data Archiving Software For UNIX & Linux |
| RecoverEDGE - Network-Enabled Smart Disaster Recovery |
| for Linux, Open UNIX 8, UnixWare 7.1, |
| and OpenServer 5.0.x. |
|http://www.microlite.com ftp://ftp.microlite.com|
|Now Supporting: Tape Drives, Autoloaders and Libraries |
|CD-R, CD-RW, DVD-RAM, DVD-R, DVD+R, DVD-RW and DVD+RW |
+-----------------------------------------------------------+
Don Yakubowski
http://support.caldera.com/rn_cgi/partneronline.cfg/php/enduser/std_adp.php?p_sid=ReEL3aMg&p_lva=119803&p_faqid=120624&p_created=1054914912&p_sp=cF9zcmNoPTEmcF9ncmlkc29ydD0mcF9yb3dfY250PTE5JnBfc2VhcmNoX3RleHQ9NS4wLjcmcF9zZWFyY2hfdHlwZT0zJnBfcHJvZF9sdmwxPTMwJnBfcHJvZF9sdmwyPX5hbnl_JnBfY2F0X2x2bDE9fmFueX4mcF9zb3J0X2J5PWRmbHQmcF9wYWdlPTE*&p_li=
Although I don't think this is the solution to the behaviour I am seeing. I
am betting there is something else buried in SCO that ties the nodelock to
the hard drive, and it can't just be copied(restored). Perhaps someone more
knowledgeable can chime in.( Hi Bela!)
Don
"KDF11-A" <membe...@dbforums.com> wrote in message
news:3023671.1...@dbforums.com...
Don Yakubowski
thanks for letting us all know the problem seems to have been identified
and a fix is imminent.We will all keep an eye out for OSS656B.
Don Yakubowski
"D. Thomas Podnar" <t...@microlite.com> wrote in message
news:3EF30E84...@microlite.com...
Bela Lubkin
That URL doesn't work; and I'm appalled at the garbage URLs being
generated by our New Improved TA search setup. :-(
I eyeball-extracted the key bit, "p_faqid=120624", and fed it to the old
URL scheme:
http://stage.caldera.com/cgi-bin/ssl_reference?120624
and that worked. It actually redirected me to:
http://support.sco.com/rn_cgi/partneronline.cfg/php/enduser/std_adp.php?p_faqid=120624
which is apparently the new minimal URL for a given TA.
In private discussions before the new Knowledge Center went online, a
repeated request was for the search results to produce small URLs that
can easily be communicated from one user to another. That's because the
person asking (I think it was JPR) knew that people _will_ search the
database and send each other pointers into it. When that pointer is 343
characters long _and_ doesn't work, that's a bad thing.
The machine name "stage.caldera.com" is supposed to be going away.
Presumably the machine name "support.sco.com" is supposed to stick
around for a while. What I'd like to see is a _really_ short URL that
gets you a specific TA, like one of these:
http://kb.sco.com/120624
http://ta.sco.com/120624
http://support.sco.com/kb/120624
http://support.sco.com/ta/120624
(We should choose one and only one of the above, implement it, and stick
to it. I vote for the first, <http://kb.sco.com/120624>.)
I don't care if it's implemented as a redirect to a 343-character URL
(or an 86-char URL) as long as the short, easily-remembered one works.
Then, search results from the Knowledge Base search engine ought to be
presented in the short form, so that when you look something up and
capture the resulting URL for your friend, it's managable.
I would like to think the 343-char URL stuff is just a startup glitch
that we will repair...
> Although I don't think this is the solution to the behaviour I am seeing. I
> am betting there is something else buried in SCO that ties the nodelock to
> the hard drive, and it can't just be copied(restored). Perhaps someone more
> knowledgeable can chime in.( Hi Bela!)
This is all supposed to be corrected in SLS oss656b; which is supposed
to be on the FTP site soon. You'll understand if I do not wish to get
into the details of the node-locking mechanism.
BTW, it's really rather annoying to be "invoked" like that in a
question. The implication is that you assume I'm the only one who can
answer it, and furthermore, that I'm obligated to do so. In truth there
are many people who know more than I do about specific aspects of Unix,
even SCO OpenServer (the guy who knows All About OSR5 licensing -- and
created oss656b -- is currently on vacation). And I'm not at all
obligated to answer anything, I do this for my own amusement and the
benefit of SCO users, not because it's my job (it isn't). (It almost
was, at some points in the past, but that didn't come to pass except for
the brief period in 1997 when I was telecommuting from Russia &
elsewhere, during my honeymoon, and SCO paid for my connectivity to keep
posting...)
>Bela<
to...@aplawrence.com
>Don Yakubowski wrote:
>That URL doesn't work; and I'm appalled at the garbage URLs being
>generated by our New Improved TA search setup. :-(
>I eyeball-extracted the key bit, "p_faqid=120624", and fed it to the old
>URL scheme:
> http://stage.caldera.com/cgi-bin/ssl_reference?120624
>and that worked. It actually redirected me to:
> http://support.sco.com/rn_cgi/partneronline.cfg/php/enduser/std_adp.php?p_faqid=120624
>which is apparently the new minimal URL for a given TA.
>In private discussions before the new Knowledge Center went online, a
>repeated request was for the search results to produce small URLs that
>can easily be communicated from one user to another. That's because the
>person asking (I think it was JPR) knew that people _will_ search the
>database and send each other pointers into it. When that pointer is 343
>characters long _and_ doesn't work, that's a bad thing.
>The machine name "stage.caldera.com" is supposed to be going away.
So what happened to the idea that old links that refer to
stage.caldera.com/cgi-bin/ssl_reference? will continue to
be redirected to the appropriate spot?
I can certainly write a script to fix the few hundred such references
on my pages, but what about the thousands to be found in Google
archives and other parts of the web? Doesn't SCO understand that
it's to their advantage that people easily find solutions to SCO
OS problems?
--
to...@aplawrence.com Unix/Linux resources: http://aplawrence.com
Inexpensive phone/email support
Download Free SCO Skills Test: http://pcunix.com/skilltests.html
Skot
> Don Yakubowski wrote:
>
>
>>Here it is:
>>http://support.caldera.com/rn_cgi/partneronline.cfg/php/enduser/std_adp.php?p_sid=ReEL3aMg&p_lva=119803&p_faqid=120624&p_created=1054914912&p_sp=cF9zcmNoPTEmcF9ncmlkc29ydD0mcF9yb3dfY250PTE5JnBfc2VhcmNoX3RleHQ9NS4wLjcmcF9zZWFyY2hfdHlwZT0zJnBfcHJvZF9sdmwxPTMwJnBfcHJvZF9sdmwyPX5hbnl_JnBfY2F0X2x2bDE9fmFueX4mcF9zb3J0X2J5PWRmbHQmcF9wYWdlPTE*&p_li=
>
>
> That URL doesn't work; and I'm appalled at the garbage URLs being
> generated by our New Improved TA search setup. :-(
I must agree, the old www.sco.com/ta was much nicer, maybe it's to
crowded by now though. Every search I tried in the last week returned a
lot more than I was expecting and nothing that I was looking for.
> database and send each other pointers into it. When that pointer is 343
> characters long _and_ doesn't work, that's a bad thing.
Truely nasty.
> The machine name "stage.caldera.com" is supposed to be going away.
> Presumably the machine name "support.sco.com" is supposed to stick
> around for a while. What I'd like to see is a _really_ short URL that
> gets you a specific TA, like one of these:
>
> http://kb.sco.com/120624
> http://ta.sco.com/120624
> http://support.sco.com/kb/120624
> http://support.sco.com/ta/120624
How about http://sco.com/ta?120624
>
> (We should choose one and only one of the above, implement it, and stick
> to it. I vote for the first, <http://kb.sco.com/120624>.)
From personal experience, I've been away from SCO products since
Caldera took over, now I'm back. It was, and would be again, a pain in
the butt to type in the old, friendly /ta and expect a search engin for
Technical Articles and get a search engin for Caldera pages. Why does
Caldera want to make it such a pain, didn't your fathers teach you the
KISS theory?
> I don't care if it's implemented as a redirect to a 343-character URL
> (or an 86-char URL) as long as the short, easily-remembered one works.
> Then, search results from the Knowledge Base search engine ought to be
> presented in the short form, so that when you look something up and
> capture the resulting URL for your friend, it's managable.
There is a good plan.
> I would like to think the 343-char URL stuff is just a startup glitch
> that we will repair...
I hope you attitude is catching there. :)
Bela Lubkin
> Bela Lubkin <be...@sco.com> wrote:
> >The machine name "stage.caldera.com" is supposed to be going away.
>
> So what happened to the idea that old links that refer to
> stage.caldera.com/cgi-bin/ssl_reference? will continue to
> be redirected to the appropriate spot?
I may have misstated that. The _machine_ that used to be
stage.caldera.com is going away (may already be gone). The redirect is
there right now. Do I trust that it'll be there Forever? Do you?
> I can certainly write a script to fix the few hundred such references
> on my pages, but what about the thousands to be found in Google
> archives and other parts of the web? Doesn't SCO understand that
> it's to their advantage that people easily find solutions to SCO
> OS problems?
Since the company's name is now officially SCO, I suspect there will
eventually be pressure to get rid of anything labeled Caldera.
Meanwhile, we already only have one of two redirects in place that ought
to exist. Before they were "stage.caldera.com/cgi-bin/ssl_reference",
the Technical Articles lived at "www.sco.com/cgi-bin/ssl_reference".
google finds 312 USENET and 26 web references to the "stage" address,
vs. 1460 USENET and 32 web references to the "www.sco.com" version. Yet
"http://www.sco.com/cgi-bin/ssl_reference?120624" gets me nothing
useful.
The "stage" redirect should continue to work. A "www.sco.com" redirect
should be added. Yet neither of these is entirely satisfactory. A new,
easy, mnemonic redirect should also be created, like
"kb.sco.com/120624". Something that will last as long as "*.sco.com" is
associated with these products, and is trivial to remember.
>Bela<
KDF11-A
Tom,
Thanks a lot for letting me know what oss to look for. I installed
it, and it seems to have done the trick. Too bad it won't fix a
bad backup though. It gave a new error when installed on a system
restored from a non-patched backup, but still is dead in the water.
Thanks again,
Don Yakubowski
No offence was meant by naming you in earlier postings, but rather to try
and gain some
knowledge from someone whose postings I have come to trust and respect. I
understand
it is not your job, and that you are never in any way obligated to post any
responses.Same applies to the rest of
us. It has been my experience in using this group over the years that one
can tell over time who knows what
they are talking about, and who is posting fud. I would consider your
postings to this group
as trustworthy and reliable, and prefer to get answers from such sources.
Don
"Bela Lubkin" <be...@sco.com> wrote in message
news:20030620204...@sco.com...
Bela Lubkin
Don --
Please understand that I was only mildly annoyed at you. The point of
of my complaint was directed at a long series of such "invocations" over
time. I appreciate that you (and others in the past) think I know
everything, but it isn't true! It's embarrassing to be called upon to
answer all questions when in fact my knowledge is limited like anyone
else's.
You trust and respect my postings precisely because I only try to
comment on things about which I have something useful to say. If I
don't know anything about a topic, I leave it alone.
>Bela<
KDF11-A
You're right Tom. SCO hasn't made this patch public yet as it's still
in Beta release.
Thanks again,
Shawn
Originally posted by D. Thomas Podnar
> This is a multi-part message in MIME format.
> --------------E80F5FC76EA581D2F4E53BEF
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> KDF11-A wrote:
> >
> > Tom,
> > Thanks a lot for letting me know what oss to look for. I
> installed
> > it, and it seems to have done the trick. Too bad it won't
> fix a
> > bad backup though. It gave a new error when installed on a
> system
> > restored from a non-patched backup, but still is dead in
> the water.
> >
> > Thanks again,
> >
> > Shawn
> >
> > --
> > Posted via
> http://dbforums.com/http://dbforums.com
>
> I don't see OSS656B posted to the SCO web site yet. If you found it,
> where? Note that OSS656A will not solve the problem.
> --
> Best Regards,
> Tom
> ---
> D. Thomas Podnar - President t...@microlite.com
> Microlite Corporation 724-375-6711 Voice
> 2315 Mill Street 724-375-6908 Fax
> Aliquippa PA 15001-2228 888-257-3343 Toll Free Sales
> +-----------------------------------------------------------+
> | Makers of |
> | BackupEDGE SS - Data Archiving Software For UNIX & Linux |
> | RecoverEDGE - Network-Enabled Smart Disaster Recovery |
> | for Linux, Open UNIX 8, UnixWare 7.1, |
> | and OpenServer 5.0.x. |
> |http://www.microlite.com/http://www.microlite.com
> ftp://ftp.microlite.comftp://ftp.microlite.com|
> |Now Supporting: Tape Drives, Autoloaders and Libraries |
> |CD-R, CD-RW, DVD-RAM, DVD-R, DVD+R, DVD-RW and DVD+RW |
> +-----------------------------------------------------------+
> --------------E80F5FC76EA581D2F4E53BEF
> Content-Type: text/x-vcard; charset=us-ascii;
> name="tom.vcf"
> Content-Transfer-Encoding: 7bit
> Content-Description: Card for D. Thomas Podnar
> Content-Disposition: attachment;
> filename="tom.vcf"
>
> begin:vcard
> n:Podnar;D Thomas
> tel;fax:724-375-6908
> tel;work:724-375-6711
> x-mozilla-html:FALSE
> url:www.microlite.com
> org:Microlite Corporation
> adr:;;2315 Mill Street;Aliquippa;PA;15001-2228;USA
> version:2.1
> email;internet:t...@microlite.com
> title:President
> note:Developers of Microlite BackupEDGE SS
> fn:Podnar, Tom
> end:vcard
>
--------------E80F5FC76EA581D2F4E53BEF--
Rob S
wrote:
-
-I don't see OSS656B posted to the SCO web site yet. If you found it,
-where? Note that OSS656A will not solve the problem.
I'm now concerned, as I've installed 4 systems with 5.0.7 and Edge 1.02.04.
Is there any way to get notified of this (or other) updates by email rather than
remembering to check comp.unix.sco.announce?
-Rob
robatwork at mail dot com
D. Thomas Podnar
Sorry for the shouting.
OSS656B for SCO OpenServer 5.0.7 is now available on the SCO ftp site:
ftp://ftp.sco.com/pub/openserver5/oss656b/
This is a MANDATORY patch for anyone using a disaster recovery product
(which should be everybody) or doing site replication.
In the case of BackupEDGE SS / RecoverEDGE, the first full system backup
made after installing this supplement will work fine for disaster
recovery.
There is no need to re-make your boot media.
All registered BackupEDGE SS owners using 5.0.7 will
be notified via the company they bought our product from.
--
Best Regards,
Tom
---
D. Thomas Podnar - President t...@microlite.com
Microlite Corporation 724-375-6711 Voice
2315 Mill Street 724-375-6908 Fax
Aliquippa PA 15001-2228 888-257-3343 Toll Free Sales
+-----------------------------------------------------------+
| Makers of |
| BackupEDGE SS - Data Archiving Software For UNIX & Linux |
| RecoverEDGE - Network-Enabled Smart Disaster Recovery |
| for Linux, Open UNIX 8, UnixWare 7.1, |
| and OpenServer 5.0.x. |
|http://www.microlite.com ftp://ftp.microlite.com|
|Now Supporting: Tape Drives, Autoloaders and Libraries |
|CD-R, CD-RW, DVD-RAM, DVD-R, DVD+R, DVD-RW and DVD+RW |
+-----------------------------------------------------------+