When things don't work as they used to...

    Once upon a time I did set up a script (something like “yum –assumeno update” but to just filter out package names) on my Fedora machines to automatically send me an report about the updates that need to be applied nightly and since Fedora is an development distribution the emails should be daily (or at least weekly), but for some reason last couple weeks have been rather quiet…

    So digging in the internet a little and what do I found out – Fedora 31 EOL was 24 of November 2020… Another thing that happened on the midst of chaos that the year has been so far… So I have to upgrade several PC’s to the next release… I know Fedora 32 is not the latest version to upgrade to, but I like the stability of being 1 release behind the latest version as it has most likely been fixed from the bugs that sometimes creep into the latest releases. Also I don’t run the latest and greatest hardware so I don’t have the need for the latest kernel drivers so I usually don’t need the bleeding edge software...

    It has been a while since I had to dist upgrade my fedora machines (I usually do it one or twice a year as the EOL time nears, but seems that in the midst of all the chaos that is year 2020 I forgot to do another upgrade cycle until it already was past EOL for some time. Oh well – time to plan one night for downloading a lot of updates… I usually don’t have any issues with upgrades as the process for doing it is pretty much the same as it was 10 years ago. Yes it has gotten simpler and easier in years as the yum/dnf framework has evolved and I think the last mishap of dist upgrade going wrong was with Fedora 19 and that upgrade was long time ago. I just love the simplicity of the process in the midst of things. Windows people would say to that that the system is slow and cluttered and you should re-install windows regularly to keep the clutter and legacy software away, but this is Linux – you don't get all sorts of extra dll’s and who knows what… Yes in time some software is obsoleted and replaced with new, but still… One of the laptops I use regularly has been upgrades since Fedora 7 and now its running 32 and most likely will go to run even newer versions…


    Enough of rambling – the procedure I used to upgrade from F31 to F32 or to do a dist upgrade on my machines is this:

“dnf clean all”

“dnf –releasever=32 update”

“dnf –releasever=32 –downloadonly –skip-broken upgrade“

    This can be done remotely over ssh or from graphical environment and it just cleans out the F31 repository data and downloads the F32 meta-data and packages (I have slow internet so it took a while). I usually don’t have million repositories enabled so I don’t have a lot of package conflicts that need resolving. But now I recommend to switch to the terminal to do the actual upgrade so “Ctrl+Alt+F2” (yes I have done the upgrade over ssh and from the graphical environment, but I have had mishaps where you have 3000 packages upgraded and just when it is time to start uninstalling the previous version packages some script gives an error and the upgrade crashes and you are a left with 7000 installed packages just because some dependency is missing in the graphical environment).

“dnf –releasever=32 --skip-broken upgrade”

    And usually that’s all that is needed to do dist upgrade. Well not this time – this time I was left with packages that have an F32 version available but for some reason would not upgrade and the message was cryptic:


WARNING Modular dependency problems:

Problem 1: conflicting requests

- nothing provides module(platform:f31) needed by module gimp:2.10:3120191106095052:f636be4b-0.x86_64

Problem 2: conflicting requests

- nothing provides module(platform:f31) needed by module libgit2:0.27:3120190407181414:f636be4b-0.x86_64

    So it seems that Gimp and libgit2 need something that was in F31 and is no more in F32… Great… Google was also not particularly helpful as there were bug reports about this message but no real answer. After digging some more I found out that dnf has some new features where packages can have some sort of modules that they require in “/etc/dnf/modules.d/” and well after upgrade the version they were searching was not there any more… Again after some searching that the removal of package was not enough to remove and the only way would be to manually edit each offending module to add “state=disabled” to the file.

    Well… As I don’t have anything that is this module specific I found an easier way:

“dnf module reset '*'”


No more annoying modules :D

And when I now run “dnf upgrade” I end up with

Upgraded:

apache-commons-codec-1.13-2.fc32.noarch apache-commons-io-1:2.6-8.fc32.noarch apache-commons-lang3-3.11-1.fc32.noarch apache-commons-logging-1.2-20.fc32.noarch apache-commons-net-3.6-8.fc32.noarch hawtjni-runtime-1.17-2.fc32.noarch jansi-1.18-3.fc32.noarch jansi-native-1.8-2.fc32.x86_64 jsch-0.1.54-11.fc32.noarch jzlib-1.1.3-12.fc32.noarch slf4j-1.7.30-2.fc32.noarch xalan-j2-2.7.2-2.fc32.noarch xerces-j2-2.12.0-4.fc32.noarch xml-commons-apis-1.4.01-29.fc32.noarch xml-commons-resolver-1.2-29.fc32.noarch

    So… I don’t know why those modules are good for but I don’t need them and resetting them let me to finally upgrade the system…



Until next time I guess...

WSUS broken from start...

Today (well 5 days ago actually) I hit a problem... with Windows Server 2019 and WSUS. Maybe it is just a luck thing, or may be it is just an issue with Linux expert trying to fiddle in the windows world, but my goal was to set up an WSUS server and the first thing after adding a WSUS role to it - well the initial configuration failed to complete.

The WSUS content directory is not accessible.
System.Net.WebException: The remote server returned an error: (503) Server Unavailable.
   at System.Net.HttpWebRequest.GetResponse()
   at Microsoft.UpdateServices.Internal.HealthMonitoring.HmtWebServices.CheckContentDirWebAccess(EventLoggingType type, HealthEventLogger logger)

To start from the beginning - working on one project I was asked to setup WSUS (Windows Server Update Services) because the Windows updates were wreaking havoc and people were pretty pissed off on the management about it.
Right...
Linux guy starting to administer Windows...
That's like asking for trouble...
As I was the only one who had even heard of it, I said "How hard can it be"...
Big mistake...

I'm not in any way certified to administer windows - I poke it with a long stick from as far as I can, but I take this "experiment" as a learning experience, so I try it at least. On a positive note - the server manager with its role based "installation" feature is kind of nice try to make things as simple as possible (if it works). Like windows loves to do, the next.. next.. next... and we are installing. Great I thought - if it really is that simple, then in about some time later we should have a working update server and all the update fuss can be done like once a month or as needed or... (I have never used it so I really don't know how its supposed to work - all I know that when WSUS is added to the domain and all PC's report to it no updates will be installed if they are not "approved" in there".

And then the problems started... The error above... The first thing I saw was that the initial configuration (script?) failed to complete. Well this is great... Fresh clean install of Windows Server 2019 - only role installed was WSUS and it failed. I had a bad feeling it could not go that smoothly from the start, but I hoped for the best. What can I do now - I guess google will have a quick solution for it?

Well - yes and no - after searching for hours I finally found a thing that was wrong in my installation. It seems that some kind of connection limit is set to 0 so IIS won't accept any connections (even from the initial configuration script?).
So to remedy the problem:
1) open  IIS manager
2) navigate to wsus administration
3) on the right under browse website go advanced settings
4) under limits if max connections is 0 change to 2

That at least fixed the problem for me, so that the initial configuration script would setup the WSUS service and allowed me to select the software collections to sync.

As I'm writing it postmortem from notes scribbled on a peace of paper I don't have the original link where I found the solution, but it seems like it is a common problem that has not been fixed for a long time and it may reoccur with updates.

To be continued...