Highlighted
Super Contributor.
Super Contributor.
2823 views

Failed upgrade from 2014 to 2018 and sles 11 to 12

I tried to upgrade the first of 3 mobile servers in our network last night. Sles 11 sp3 to sles 12 upgrade went OK, no errors. I followed the instructions to upgrade the mobility server software, it looked like it ran correctly. THer server came up and I got a login page, logging in threw an error about an illegal opertation. I never got in. I had to roll back the entire upgrade.

The install prompts where not easy to follow. On thing in particular, the installer asked about Groupwise admin resources and ldap even though we use eDir as an LDAP user source in the current deployment. Would this indicate a failure to update the postgress db?

Any insights?

Thanks All,

Rob A
Labels (1)
Tags (1)
0 Likes
19 Replies
Highlighted
Knowledge Partner
Knowledge Partner

are you sill in the installation workflow or already on the webfrontend? did you grab a trace (ldap dstrace on the target)?
as i understand it you've build a fresh sles12sp2 box and are trying to install a fresh gms2018 on it. correct?
If you like it: like it.
0 Likes
Highlighted
Super Contributor.
Super Contributor.

Yes, I'm on a hew VM trying a fresh install. I've left myself in the installation routine at the point of failure while I did research.

While I can run a trace, my sense is I need to get at least one of my server to accept insecure connections and/or replace an internal certificate for ldaps for one or more of my ldap servers.

It strikes me odd that it would be fine for the 2014 serrvers and fail on the 2018.

Thanks again.


mathiasbraun;2476374 wrote:
are you sill in the installation workflow or already on the webfrontend? did you grab a trace (ldap dstrace on the target)?
as i understand it you've build a fresh sles12sp2 box and are trying to install a fresh gms2018 on it. correct?
0 Likes
Highlighted
Absent Member.
Absent Member.

Where exactly is the install failing. If it is right after where you enter the GW admin host, are you using an IP or hostname? We found that the certificate verification that the gms install calls is ignorning the IP addr in the certs subject alternative names. Try using the GW server hostname instead.

--morris

raronson;2476410 wrote:
Yes, I'm on a hew VM trying a fresh install. I've left myself in the installation routine at the point of failure while I did research.

While I can run a trace, my sense is I need to get at least one of my server to accept insecure connections and/or replace an internal certificate for ldaps for one or more of my ldap servers.

It strikes me odd that it would be fine for the 2014 serrvers and fail on the 2018.

Thanks again.
0 Likes
Highlighted
Super Contributor.
Super Contributor.

I select ldap over groupwise as the user source, enter my ldap server info and get the following
Exception - {'info': u'error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain)', 'desc': u"Can't contact LDAP server"}
Try again.

If I try an insecure connect over port 389 I'm stopped because I can't open an authenticated, insecure connection
Exception - {'desc': u'Confidentiality required'}

My options are, switch to groupwise as a user source, open my ldap server for insecure connections, figure out how to import a trusted root for this system or get a commercial certificate for my ldap connections. My current certification solution is based on wildcard certs. I suspect that won't be sufficient.
0 Likes
Highlighted
Absent Member.
Absent Member.

oh.. you can temporarily allow unsecured ldap connections in iManager. Go to the Ldap Group object of the server you're connecting to. Then unselect "Require TLS for Simple Binds with Password". Turn it back on when you are through.

--Morris
0 Likes
Highlighted
Super Contributor.
Super Contributor.

That was what I needed. Now that I'm through the install I'm trying to find out how to change the device certificate. Is it with keytool?
0 Likes
Highlighted
Super Contributor.
Super Contributor.

Skip that last comment. I forgot about using DSapp to manage certificates.
0 Likes
Highlighted
Super Contributor.
Super Contributor.

As an afterthought,

We migrated our Sles 11 servers last month by creating new systems with the same configurations except for host names. I couldn't reuse the host names, my boss wanted me to move them gradually. To move the user we changed the host account info on the iDevice or android. Many of the accounts required additional work, resyncing, removing and re-adding the accounts and on a couple using dsapp to completely remove the db info for the accounts.

One oddity I found was on the POAs some of the users were registered for soap notifications from the original servers. I think that caused a lot of the problems we experienced. I had to manually remove the events and the event notifications for the old hostnames.

The other issues we hit were with shared folders/shared address books. Specifically when our post offices were in branch offices, up til this point all the traffic had been local. We hadn't configured firewall policies to allow connections across our vpns.

Hopefully we're through with this episode of crisis and can move on to new and even more bizzare problems.

Thanks all
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.