Dear HartmutFirst of all thanks very much for the great work you have done. I was running the beta2 version for around two weeks and now the beta3 for the second day without real problems.

I run a copy of your “get-all-updates.bash” as “get-my-updates.bash” with my changes as a cron job (which runs 30 to 35 minutes). My minor problem is that only every second day it will check my updates, because the time stamps difference is exactly 24 hours. I changed line 87 in the timestamps.bash to: local -i time_interval="${2:-84000}" # use less than 24 hours as default to allow Crown runs every day (84000=23h 20 min)I believe you are planning with “time_interval_input_files=86400” an easier possibility………

I check also the result of the crown job with logcheck as an email, with stripping all “common” lines. Due to sorting from logcheck, an easy possibility to see which command causes some abnormalities and/or which files are downloaded, I had to add the command line information to the 20-start-logging.bash (log_message "command: $command_line"), because your info-block has the same information, but without date and time and get sorted in a block at the end of the email.

Hi,First of all much thanks for the great work that has been done. As a frequent but not regularly user of the WSUSoffline Tool I was curious to see that there is finally a new attempt for a linux version of the tool doing the downloading stuff, perfect. This looks like a welcome solution to maintain an up-to-date source of windows patches and service packs on a linux hosted file server with a lot of windows clients in our small office. So, I saw it today and directly thought to give it a try. I did the following on a Ubuntu virtual machine (ubuntu 14.04LTS 64bit) hosted on my Win7 pc:1.

In your description there is no mention of the files from the windows version of WSUS Offline Update. Are you aware that the new linux scripts still requirethe presence of the files from the windows version?

Sorry for being so dumb,I was not aware of the necessity of the complete original zip archive for the wiondows version. After redoing it (first get the zip archive in the current version, unpack it) performing teh steps as described above now works fine. Much thanks for your quick clue and alerting me to do the right thing. Now I am getting the "selection menu" and can procede in testing.

The Linux download scripts still need the configuration files from the WSUS Offline Update installation. These are the files in the directories static, exclude, client/static, and client/exclude. The Linux scripts also need the XSLT transformation files from the directory xslt, to calculate superseded and dynamic updates.

The Windows script DownloadUpdates.cmd is checked once, to get the exact version of WSUS Offline Update. This is a simple grep and does not execute anything. It is implemented in the function set_wou_version as:

Also, the Linux download scripts can only replace the download part. To install anything, you definitely need the UpdateInstaller.exe and all the other files in the client subdirectory.

Actually, this is mentioned in the Quick Installation Guide. It says: "Download the archive and the hashes file to the directory wsusoffline. This is the directory, where the Windows utility UpdateGenerator.exe resides."

But maybe it should be pointed out more clearly, that the archive for WSUS Offline Update needs to be downloaded first.

So, the situation is quite similar to Debian, as could be expected. In recent versions of both Debian and Ubuntu, the package hashdeep should be used, with md5deep offered as a dummy package for an easy upgrade.

which returned 4.2 !? Ignoring this and hoping/expecting no probs from the correctly downloaded file ...

At this point you should have tried hashdeep, which is also installed by the package md5deep. Actually, these binaries are all copies of the same file, but they behave differently, depending on how they are called. In Debian 7 Wheezy I got the following display:

much thanks for your thorough clarification and all the effort you are putting in. I guess it might not be a bad idea to point out a bit more the fact that the WSUS Offline Update needs to be downloaded first. Though it is clearly writen as you highlighted to put the files to that directory - honestly I read this but I did not think too much about it and it did not ring a bell.

With the current versions of WSUS Offline Update (10.9.2) and the Linux scripts (1.0-beta-3), it is necessary to download and unpack the wsusoffline archive first. This will change with the next versions:

WSUSUpdateAdmin has already replaced the old Linux script DownloadUpdates.sh with the new Linux scripts in changeset 866, so they will be included in the next release of WSUS Offline Update:

The new Linux scripts regularly check for new versions of WSUS Offline Update, and can download and install them. The script 50-check-wsusoffline-version.bash just assumes, that there is a file ../static/StaticDownloadLink-this.txt, which indicates the currently installed version. With small changes around this part, the same script could also do an initial download of the wsusoffline archive.

It actually works with the version 1.0-beta-3, but you would need to create a dummy file ../static/StaticDownloadLink-this.txt first:

Info: Searching for new versions of WSUS Offline Update...Info: A new version of WSUS Offline Update is available:- Installed version: unavailable- Available version: wsusoffline1092Info: Do you want to install the new version now?---------------------------------------------------------------------------Note: This question automatically selects "No" after 30 seconds, to skipthe pending self-update and let the script continue. This is also thedefault answer, if you simply hit return.---------------------------------------------------------------------------[y|N]: y

Just type "y" to confirm the update and it will download and install the wsusoffline archive itself.

This beta script is working well for me. However, I'm wondering if there is a way to pass multiple options to the download-updates script? I read in the Manual that multiple languages need to be downloaded in turn, but what about updates for multiple versions of Windows? I am supporting a team with very poor internet and 6 different versions of Windows: 32-bit & 64-bit versions of Win 7, 8, and 10. Unfortunately, I have no control over what OSes they run. I would like to be able to choose multiple versions of Windows simultaneously from the update-generator script, or at least find out if I can pass multiple version options to the command line. Thanks.

n8marti wrote:I would like to be able to choose multiple versions of Windows simultaneously from the update-generator script, or at least find out if I can pass multiple version options to the command line. Thanks.

Such multiple options are not supported, at least for now. I wanted to keep these scripts simple, and I didn't want to make everything different than the Windows version. The Windows script DownloadUpdates.cmd also handles only one Windows version per run.

If you have different Windows versions to support, you could compile a small script of your own to run these downloads. The included script get-all-updates.bash may serve as a template. I use this script to compare the results on Windows and Linux with a standard download set, but it is also meant for customization.

This does not really affect the performance over slow Internet connections: There are some common tasks for all Windows versions, like wsus, win, and the optional downloads cpp, dotnet, msse, and wdefs. But these tasks are evaluated only once each day. The new Linux script uses timestamps, to keep track of these tasks: If one task has already been done in the past 24 hours, the complete processing will be skipped.

If one task could not be completed successfully, its timestamp will not be updated, and then it is rerun immediately. This could happen with the virus definition files sometimes, although I made the download of these files more robust.

I might someday implement a list for the languages, though, because this could prevent some unneeded processing. But then there should also be a user interface to select multiple languages. I once created a mockup for the old Linux script to show, how this could look like with dialog: viewtopic.php?f=9&t=4061

The old Linux script DownloadUpdates.sh had some integrated lists for all Windows versions or all Office versions, but it was poorly implemented: The script DownloadUpdates.sh would recursively call itself for every update. This didn't achieve anything, as it didn't make the script run faster. But it broke repeatedly, because the script sometimes failed to find its own installation directory, for example:viewtopic.php?f=9&t=4469 , viewtopic.php?f=9&t=5298 , viewtopic.php?f=9&t=5314 , viewtopic.php?f=9&t=5346

The obsolete script DownloadUpdates.sh and related files will be deleted, if they are found in the same directory as the new Linux scripts

The new Linux scripts are included in the WSUS Offline Update archive since changeset 866 http://trac.wsusoffline.net/changeset/866 . They are installed into the directory wsusoffline/sh. But then the old scripts in the same directory, if present, should be removed.

The Linux scripts can do an initial installation of WSUS Offline Update

The Linux scripts need the configuration files of a WSUS Offline Update installation, to calculate static and dynamic downloads. Also, the new Linux download scripts can only replace the download part of WSUS Offline Update, namely the application UpdateGenerator.exe and the script DownloadUpdates.cmd. The client directory with the application UpdateInstaller.exe will be needed for the installation of the updates on Windows.

The Linux scripts already included a script to search for new versions of WSUS Offline Update and to download and install them on demand. The same script can now do an initial installation of the wsusoffline archive, if none is installed.

To use this approach, you should create an enclosing directory "wsusoffline" first, which will contain both the new Linux scripts and the contents of the wsusoffline archive. Change to the directory "wsusoffline" and download and unpack the Linux scripts to this directory. Change to the new directory "wsusoffline/sh-new-1.0-beta-4" and run the script update-generator.bash. It will download and unpack the wsusoffline archive outside of the directory sh-new-1.0-beta-4, but inside the enclosing directory wsusoffline.

This may not be the usual way to unpack an archive, but the Linux scripts need to be in the wsusoffline directory, not the other way round. Don't complain, if you litter your home directory with lots of new files and directories.

The next release of WSUS Offline Update will already include the new Linux download scripts, and then this approach will not be necessary anymore, but it was a small addition to an existing file, and so it was implemented anyway.

The integrity of the WSUS catalog file wsusscn2.cab is tested with cabextract

The test with cabextract -t ensures, that all files in the archive can be extracted. This should detect damaged archives, which are sometimes found in the Microsoft content delivery network after the official patch day on the second Tuesday each month. These files can be successfully downloaded, without any error indicated by wget. But the verification of the digital file signature with Sysinternals Sigcheck may still fail. Usually, these problems disappear by itself after a few days.

Testing a damaged file with cabextract typically finds errors at the end of the file. An example result is shown below. The warning about "extra bytes at end of file" can be ignored, though.

The download part of WSUS Offline Update only uses the second file in this archive, package.cab, and this file seems to be okay. This could explain, why even a damaged archive wsusscn2.cab seems to work fine for the download part of WSUS Offline Update: The file package.cab (and then package.xml) can still be extracted and used for the calculation of superseded and dynamic downloads. But the installation will probably fail, if the file wsusscn2.cab is damaged.

Security updates can be verified by comparing the SHA-1 hashes, which are embedded into the filenames, with the values, which are calculated by hashdeep.

The file package.xml is only extracted from the cabinet file wsusscn2.cab, if this file changes. Otherwise, a cached copy of the file package.xml in the new directory wsusoffline/cache will be used.

The file package.xml contains just one long line without any line breaks. This is the most compact form of XML files and similar formats like JSON. In this form, it can be parsed by applications, but it cannot be displayed in a text editor nor searched with grep. For convenience, the script also creates a pretty-printed copy of the file with the name package-formated.xml. This is mostly for development, though.

The same_day function uses three different time intervals for different tasks

The same_day function is used to prevent a repeated evaluation of the same tasks in adjacent runs of the download script. For example, the directory client/win contains common downloads for all Windows versions. Similarly, the directory client/ofc contains common files for all Office versions. If different Windows or Office versions are downloaded in turn, then the downloads for win and ofc should only be processed once.

The same_day function uses timestamp files, to keep track of the downloads, which have already been done. The file modification date of the timestamp file is then compared to the current date.

The first implementation of the same_day function used the output of the command "date" in the form "2017-05-09", which is known as ISO 8601 ( https://xkcd.com/1179/ ). If the file modification date of the timestamp file and the current date were on the same day, then the same_day function returned "true" and the download task would be skipped.

The next implementation in version 1.0-beta-2 actually calculated the time difference in seconds. The same_day function returned true, if the difference between the file modification date and the current date was less than 24 hours.

This approach has now been improved: the same_day function uses three different time intervals for different tasks:

The four virus definition files change every two hours. It may be useful, to check these files more often, for example every four hours.

Configuration files are checked once daily as before. This includes new versions of WSUS Offline Update and the Linux scripts, updates of the configuration files for WSUS Offline Update, and the WSUS catalog files wsusscn2.cab.

If these configuration files change, then most or all of the remaining updates will be rescheduled by deleting their timestamp files.

The remaining updates all depend on the configuration files. If the configuration files don't change, then these updates cannot change either. These are the updates for Windows, Office, .Net frameworks, and Visual C++ runtime libraries.

The time interval for these dependent updates is set to a safe value of two days.

Actually, these updates could be postponed forever. They will be rescheduled immediately, if one of the configuration files changes. This would result in an event-driven evaluation of the updates, rather then recalculating everything everyday.

The interval length must take into account the time needed to process the task: check the consistency of existing downloads, calculate static and dynamic download links, fetch all files (if they don't exist yet), and calculate new hashes for the download directory. The timestamp will be updated after successfully completing the task.

An initial download, for example of the Windows 10 updates, may take several hours, depending on the speed of the Internet connection. Therefore, "four hours" are calculated as 3:20 hours, "one day" is now 21 hours, and "two days" are 45 hours. Of course, these are only guesses, which can be adjusted as needed in the file timestamps.bash.

Languages can be linked to a comma-separated list on the command line

One goal in the development of the Linux scripts was to use unified language settings: The second parameter should always be a real language like "deu" or "enu", and then this language would be used, wherever a language selection is needed. This worked well for a single language, but if several languages were needed, they had to be downloaded in turn.

In this version, language parameters can be joined to a comma-separated list. Instead of:

This makes the processing of Windows Vista, Windows 7, .NET Frameworks and Microsoft Security Essentials much faster, because it avoids unneeded iterations of these tasks.

The downloads for Microsoft Office are still calculated separately for each language, and they won't gain the same acceleration.

The general approach to language settings stays the same: there is no distinction between default languages, custom languages and update languages. Only languages, which are given on the command-line, will be included.

Unfortunately, the setup script update-generator.bash doesn't support multiple selections yet. It uses the built-in command "select" of the bash to create simple dialogs, but these dialogs don't allow multiple selections. This may be implemented later with "dialog", as once suggested for the old Linux scripts ( viewtopic.php?f=9&t=4061 ).

See the example script get-all-updates.bash for more examples. It is meant as a template for customization.

Windows Server 2008 is still supported, in both 32-bit and 64-bit versions.

Therefore, the download part of WSUS Offline Update didn't really change much: The selections for w60 and w60-x64 are still there, but they now refer to Windows Server 2008 only.

Most changes will be in the installation part of WSUS Offline Update: The application UpdateInstaller.exe distinguishes between all supported Windows versions, and it won't probably support Vista any longer.

If you like to get the latest available updates for Windows Vista, you can combine this version of the Linux scripts with WSUS Offline Update 10.9.2 and just select "Windows Server 2008" from the selection dialog. Then you should save the wsusoffline installation, or at least the client directory, to a tar archive, to preserve the current state.

For a short time, the available updates for Windows Vista and Server 2008 may stay the same. Windows Server 2008 will continue to get new updates, but these may not be installable on Vista anymore. New updates may still replace (supersede) old updates, and then some updates, which could be installed on Windows Vista, might be missing.

This would be a similar situation as with Windows XP: The embedded version of Windows XP still gets updates, but they can't be installed in a regular Windows XP Home Edition or Windows XP Professional. Still, these updates for Windows XP embedded replace the updates for the regular versions, so that these updates are now missing. They are still available on the server, but WSUS Offline Update with its calculation of superseded updates may not download them anymore.

unzip is copied to the client directory

unzip.exe is copied from the directory ../bin/ to ../client/bin/, because it is needed for the installation of two updates for Windows 7. This was pointed out by "wuttztfz" in viewtopic.php?f=9&t=6627 .