Security fixes
- Groups on items and nodes are ignored after the RBAC migration until the next restart (CTR-2757)
-
Groups were not available on items after the RBAC migration until the next restart. Customers either experienced a lack of permissions or an increase depending on the their permission configuration strategy (either adding more permissions in folders or to filter roles).
With this fix, groups are available on items without the need of a manual restart.
Known issues
- Version 4.0 or higher of .NET Framework is required to launch controller or agents on Windows services
-
Starting from this release, .NET Framework 2.0 doesn’t work for launching CloudBees controller or agents as Windows services. Microsoft.NET Framework 4.0 or above is now required for using the default service management features.
This release also upgrades Windows Service Wrapper (WinSW) from 2.3.0 to 2.9.0 and replaces the bundled binary from .NET Framework 2.0 to 4.0. There are many improvements and fixes in these versions, big thanks to NextTurn and all other contributors. You can find the full WinSW changelog here, just a few highlights important to CloudBees users:
-
Prompt for permission elevation when administrative access is required. Now CloudBees users do not need to run the agent process as Administrator to install the agent as a service from GUI.
-
Enable TLS 1.1/1.2 in .NET Framework 4.0 packages on Windows 7 and Windows Server 2008 R2.
-
Enable strong cryptography when running .NET Framework 4.0 binaries on .NET 4.6.
-
Support security descriptor string in the Windows service definition.
-
Support 'If-Modified-Since' and proxy settings for automatic downloads.
-
Fix Runaway Process Killer extension so that it does not kill wrong processes with the same PID on startup.
-
Fix the default domain name in the
serviceaccount
parameter (JENKINS-12660) -
Fix archiving of old logs in the
roll-by-size-time
mode.
-
- Use-cases affected by .NET Framework 2.0 support removal
-
If you use .NET Framework 2.0 to run the CloudBees Windows services, the following use cases are likely to be affected:
-
Installing the CloudBees controller as a Windows service from Web UI. The official MSI Installer supports .NET Framework 2.0 for the moment, but it will be changed in future versions.
-
Installing agents as Windows services from GUI. This feature is provided by the Windows Agent Installer Module from the Jenkins core.
-
Installing agents over Windows Management Instrumentation (WMI) via the WMI Windows Agents plugin
-
Auto-updating of Windows service wrappers on agents installed from GUI.
-
- Upgrade guidelines
-
If all of your CloudBees controller and agent instances already use .NET Framework 4.0 or above, there are no special upgrade steps required.
If you run the CloudBees controller as a Windows Service with .NET Framework 2.0, this instance will require an upgrade of .NET Framework to version 4.0 or above. .NET Framework 4.6.1 or above is recommended because this .NET version provides many platform features by default (e.g. TLS 1.2 encryption and strong cryptography), and Windows Service Wrapper does not have to apply custom workarounds.
If you want to continue running some of your agents with .NET Framework 2.0, the following extra upgrade steps are required:
-
Disable auto-upgrade of Windows Service Wrapper on agents by setting the
-Dorg.jenkinsci.modules.windows_slave_installer.disableAutoUpdate=true
flag on the CloudBees controller side. -
Upgrade agents with .NET Framework 4.0+ by downloading the recent Windows Service Wrapper 2.x version from WinSW GitHub Releases and manually replacing the wrapper ".exe" files in the agent workspaces.
-
Upgrade notes
If upgrading from a rolling release older than 2.401.2.6, customers may experience technical difficulties. CloudBees ensures compatibility only between supported versions of the product and recommends upgrading early and often to avoid these difficulties. If you are having difficulties upgrading, contact CloudBees Support for assistance. |
Revisions
- Revision 2 (2020-11-20)
-
In some cases, a bug in the Jenkins Pipeline: Nodes and Processes plugin prevents users with the Job/Discover permission from being able to see the build status in the build executor widget on the side panel of the Jenkins dashboard. In place of the build status, the “angry Jenkins” icon appears. (FNDJEN-3297)
The following versions of CloudBees' Jenkins-based products are affected:
-
2.249.1.1
-
2.249.1.2
-
2.249.2.1
-
2.249.2.2
-
2.249.2.3
-
2.249.2.4
-
2.249.3.1
-
2.249.3.2
-
2.249.3.3
The following is an example Jenkins log file entry for this issue:
2020-10-06 09:13:14.910+0000 [id=1305202] WARNING h.i.i.InstallUncaughtExceptionHandler#handleException: Caught unhandled exception with ID 50acb1fe-4052-420f-b3f8-147648dbb9bd org.apache.commons.jelly.JellyTagException: jar:file:/var/jenkins_home/war/WEB-INF/lib/jenkins-core-2.259.jar!/hudson/model/View/sidepanel.jelly:75:50: <st:include> org.apache.commons.jelly.JellyTagException: jar:file:/var/jenkins_home/war/WEB-INF/lib/jenkins-core-2.259.jar!/lib/hudson/executors.jelly:75:28: <j:otherwise> Please login to access job <masked> at org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:726)
To fix this issue, apply this update.
As a workaround in the meantime, this problem will disappear if you remove the Job/Discover permission from all users and groups. This permission is only intended for configurations that grant Overall/Read permission to anonymous users and has very little benefit in other configurations.