SP3 install removes slapd
This is a copy of the call I opened for this problem. I was actually
very pleased that the upgrade process was going that smooth, and very
fast too... until I found out that my ldap server was removed *sigh*
A lot of configuration gets lost too (after altering the script so it
doesn't remove the slapd ofcourse): changes made to platform.conf, all
finetuning done to the jvm, rewrite rules, gateway configuration, ...
The public_html and all the templates get overwritten too..
The main reason I was upgrading to SP3 was because of the tcp
connections in CLOSE_WAIT that didn't go away... at least that's solved.
I hope the reason they didn't release SP3 yet is because they're still
testing it...
Cheers,
Fred
CASE ID 413356 DETAILS
Priority: P2: Severe Impact Created: JUL 23 2001
09:38 PST
Product & Version: Portal Server 3.0 SP2
Hardware Platform & OS Version: Sun Solaris 8
Support Person: TSE: q_emea_webapp
Contact: Frederik Willems
Summary Description: SP3 installation script problem (RFE?)
Details: We tried an upgrade of portal server 3.0 SP2 to
SP3, but during the installation
the entire ldap server was removed and no new one was
installed...
This is why:
In the GetLocalHost function (+- line 734) of the
ipsinstall script we
see:
HOSTNAME=`hostname`
# snipped some irrelevant code
if [ "$SUBDOMAIN" = "" ]; then
LOCALHOST="$HOSTNAME.$DOMAIN"
else
LOCALHOST="$HOSTNAME.$SUBDOMAIN.$DOMAIN"
fi
In the 'main' part of the script (line 3150) we see:
if [ "$PS_HOST" = "$LOCALHOST" ]; then
DS_UPGRADE="y"
print "`$GETTEXT 'Updating attributes.'`"
UpdateAttributes
print ""
print "`$GETTEXT 'Saving current attributes.'`"
DumpAttributes $WORK_DIR/attributes-preSP3
$TMP_DIR/attributes-preSP3
print ""
fi
where the $PS_HOST is set in the GetPlatformConf function
(+- line 1109)
and retrieved from the SP2 configuration.
In no way can you ever be sure that $LOCALHOST equals
$PS_HOST
(theoraticly there is no reason why they should), and in a
clustered
environment this will very rarely be the case. Resulting in
not backing
up the current ldap server and even the removal of the ldap
server !!
We got around this by hardcoding the LOCALHOST variable to
match
PS_HOST. (after having to restore our entire system first
ofcourse!)
For some reason it looks strange to me that this got past
the testing of the
product. Can I log an RFE for this?
--
Siemens Business Services
Ministerie van de Vlaamse Gemeenschap - S3 Internet/Intranet
Boudewijngebouw Kamer 7B13 - Boudewijnlaan 30 - 1000 Brussel
Tel: +32 (0)2 553 5268 -- Fax: +32 (0)2 553 5295
[3012 byte] By [
] at [2007-11-25 4:28:30]
Thank you for this post. We had the same thing happen, but thankfully we
had backed up everything, and because of your post, we knew right where
to look.
Frederik Willems wrote:
> This is a copy of the call I opened for this problem. I was actually
> very pleased that the upgrade process was going that smooth, and very
> fast too... until I found out that my ldap server was removed *sigh*
>
> A lot of configuration gets lost too (after altering the script so it
> doesn't remove the slapd ofcourse): changes made to platform.conf, all
> finetuning done to the jvm, rewrite rules, gateway configuration, ...
>
> The public_html and all the templates get overwritten too..
>
> The main reason I was upgrading to SP3 was because of the tcp
> connections in CLOSE_WAIT that didn't go away... at least that's solved.
>
> I hope the reason they didn't release SP3 yet is because they're still
> testing it...
>
> Cheers,
>
> Fred
>
> CASE ID 413356 DETAILS
>
> Priority: P2: Severe Impact Created: JUL 23 2001
> 09:38 PST
>
> Product & Version: Portal Server 3.0 SP2
>
> Hardware Platform & OS Version: Sun Solaris 8
>
> Support Person: TSE: q_emea_webapp
>
> Contact: Frederik Willems
>
> Summary Description: SP3 installation script problem (RFE?)
>
> Details: We tried an upgrade of portal server 3.0 SP2 to
> SP3, but during the installation
> the entire ldap server was removed and no new one was
> installed...
>
> This is why:
>
> In the GetLocalHost function (+- line 734) of the
> ipsinstall script we
> see:
>
> HOSTNAME=`hostname`
>
> # snipped some irrelevant code
>
> if [ "$SUBDOMAIN" = "" ]; then
>LOCALHOST="$HOSTNAME.$DOMAIN"
> else
>LOCALHOST="$HOSTNAME.$SUBDOMAIN.$DOMAIN"
> fi
>
>
>
> In the 'main' part of the script (line 3150) we see:
>
> if [ "$PS_HOST" = "$LOCALHOST" ]; then
>DS_UPGRADE="y"
>print "`$GETTEXT 'Updating attributes.'`"
>UpdateAttributes
>print ""
>print "`$GETTEXT 'Saving current attributes.'`"
>DumpAttributes $WORK_DIR/attributes-preSP3
> $TMP_DIR/attributes-preSP3
>print ""
> fi
>
> where the $PS_HOST is set in the GetPlatformConf function
> (+- line 1109)
> and retrieved from the SP2 configuration.
>
> In no way can you ever be sure that $LOCALHOST equals
> $PS_HOST
> (theoraticly there is no reason why they should), and in a
> clustered
> environment this will very rarely be the case. Resulting in
> not backing
> up the current ldap server and even the removal of the ldap
> server !!
>
> We got around this by hardcoding the LOCALHOST variable to
> match
> PS_HOST. (after having to restore our entire system first
> ofcourse!)
>
> For some reason it looks strange to me that this got past
> the testing of the
> product. Can I log an RFE for this?
>
>
>
>
at 2007-6-29 2:30:31 >
