RH 7.4 upgrade issues

Latest response

With 7.4 hitting General Availability I'm trying 7.3 --> 7.4 upgrades on a few test servers. So far I've run into the following issues:

(1) CDN availability of kernel-3.10.0-693.el7.x86_64 has been erratic so far today. I copied the RPM out of the DVD ISO download and persevered.

(2) gedit wants libpeas-gtk-1.0.so.0() which apparently isn't provided by libpeas-1.20.0-1.el7.x86_64 anymore. I evaded that and some other unresolved dependency conflicts by:

  yum remove totem gedit gnome-dictionary gucharmap eog

As an emacs kind of guy I can live with that for a while, but I will have some unhappy users if I start upgrading production machines before this gets resolved.

(3) Samba stopped working. I have samba --> pam+krb5+sssd, sssd --> AD 2008R2; the sssd part seems to be fine. A different AD forest with 2016 also broke samba. I'm still reading the release notes to see what might be different in the samba --> sssd (not winbind) relationship.

James Leinweber's picture

Responses

I'm seeing a dependency loop upgrading RHEL 7.3 Workstation to RHEL 7.4. Seems to be involving libgtk, libgdk, and libnotify.

(Later) Mostly worked out, still seeing problems with Xfce (my preferred GUI): libxfce4util.x86_64 0:4.10.1-2.el7 vs. libxfce4util.x86_64 0:4.12.1-2.el7 Pretty much toe-to-toe action in the Mighty Marvel Manner.

Hi James,

Just came across your post ... well, I'm afraid that upgrading in this case might not be a trivial thing, especially regarding the GUI related packages. Too much has changed since the release of GNOME version 3.14, which was included in RHEL 7 before. GNOME 3.22 which comes with RHEL 7.4 is four (!) versions later. You may want to check out the matching discussion I started yesterday : https://access.redhat.com/discussions/3133621 Maybe it can help you to decide what to do now ... anyway, I wish you good luck !

Cheers :)
Christian

Actually by 24 hours after GA the kernel package was reliably showing up, solving (1); and the missing (new) RPM libpeas-gtk-1.20.0-1.el7.x86_64 became available plus they evidently added the missing dependency, which got my 7.3 servers into an upgradable state and let me re-install gedit on the ones I'd taken it off of, solving (2).

I still have to figure out what's wrong with my Samba shares, though.

We also have samba issues. It just stopped working. We have Winbind joined to an Active Directory. The problem seems to be in krb5 ? I have downgraded samba and krb5 and the kernel but no go. We will keep searching.

Our winbind implementation is broke as well, as of booting up on RHEL 7.4 from RHEL 7.3. Root SSH logins are taking 2 -3 minutes, while winbind process is up, but if winbind is shutdown, root login times are normal.

Is it only the root user that is affected by slow login? Are you able to login with winbind users from AD?

Regular users were not able to login at all. Looks like there were two issues.. originally the servers were updated along with a bunch of other patches using a satellite channel, I think caused some dependency issues. Winbind would start and we saw the issue referenced above. However, I rolled a server back and updated only using the RHEL 7.4 media/cd. In this case Winbind would not even start, due to a config issue. "main: FATAL: Invalid idmap backend rid configured as the default backend!" After updating smb.conf to reference our trusted domain rather than *, winbind starts and users are able to login normally. Thanks!

I discussed item 3 (Samba/SSSD issues) in a thread here: https://access.redhat.com/discussions/3147951

I'm fairly confident all the sssd/realm/winbind issues are related to the kde-libs dependency not being correctly identified which I have described in the above link (with link to a related bugzilla).

I have also since found that if you join the domain in the 'broken' state with the older library, you will need to remove the keytab and re-join after you have upgraded kde-libs as they keytab appears to end up in an unreliable state which breaks the startup of SSSD (SSSD child exits with code 3).

We tried with krb5-libs-1.15.1-8.el7.x86_64 but no luck. Even a clean 7.4 install has problems.

What problem are you seeing specifically? Is it in SSSD? Samba? logins?

Do you have anything from logs?

When we try to join a machine with net ads join we get a timeout. The errors in the logfiles are : failed to verify domain membership after joining: The request is not supported. It just hangs. A clean install or a upgrade to 7.4 and we have it every time. 7.3 without problems. It just looks like the AD servers cannot be reached or some encryption that does not work anymore.

Richard,

What version of Windows are your DCs? Have you turned on debug level logging in SSSD to (hopefully) provide more insight?

Add the following to the global section of your sssd.conf

debug_level = 9

Lastly, have you tried using 'realm' to join? I believe it uses 'net' under the hood for the join, but it may provide you with some more details about why it's failing.

Our upgrade included krb5-libs-1.15.1-8.el7.x86_64 as well and are still having issues, we are not currently using SSSD.

I have opened a case at technical support. I will let you know the solution.

The biggest impact to us: openSSH has moved from 6.6 to 7.4.

Some of our legacy code (old Perl modules, etc) will not work with new openSSH server.

Interested to understand this issue. Is it due to cipher deprecation? What errors do you get from the perl modules that are attempting to connect?

We are experiencing exactly this issue:

http://www.perlmonks.org/?node_id=1144748

The root cause is a very old Perl module that hasn't really been maintained on CPAN at all. We are currently evaluating alternatives (Net::OpenSSH so far is winning).

We are seeing that the default nfs mount behavior is to start with trying nfs vers=4.1, which none of our nas storage allows. The concerning part, is that rather than trying 4.0 after failing on 4.1, rhel 7.4 fails down to nfs 3. This also causes problems on some of servers that use a different nas storage which doesn't allow nfs 3. If we force vers=4.0, the mounts works fine across the board.

There is hope for the sssd+samba problem! After opening a support case per https://access.redhat.com/solutions/3143951, redhat was eventually able to supply me with test builds of the sssd packages (version 1.15.2-50.el7_4.3.1) which restored samba functionality.

Was this helpful?

We appreciate your feedback. Leave a comment if you would like to provide more detail.
It looks like we have some work to do. Leave a comment to let us know how we could improve.
Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.