Skip to content

Sync with xenserver-release-8.4.0-18 #33

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
stormi wants to merge 4 commits into
base: master
Choose a base branch
from
Draft

Sync with xenserver-release-8.4.0-18 #33

Show file tree
Hide file tree
Changes from 3 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
27fd57a
Import xenserver-release-8.4.0-17.xs8.src.rpm
ydirson Aug 29, 2025
39ea6a0
Import xenserver-release-8.4.0-18.xs8.src.rpm
stormi Sep 22, 2025
b46d6f0
Merge branch 'XS-8.3' into 8.3-rebase-XS20250922
stormi Sep 22, 2025
8987797
fixup! Remove extraneous tarball, and update xenserver.conf header fo…
stormi Oct 15, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
40 changes: 40 additions & 0 deletions SOURCES/0004-Sync-with-xenserver-release-v8.4.0-17.tar.gz.patch
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
From 0a3a6eb97a765438ae34fbec46fe62c9bcdf7a78 Mon Sep 17 00:00:00 2001
From: XenServer <[email protected]>
Date: Wed, 5 Mar 2025 22:31:00 +0000
Subject: [PATCH 4/5] Sync with xenserver-release-v8.4.0-17.tar.gz

* Thu Mar 13 2025 Gerald Elder-Vass <[email protected]> - 8.4.0-18
- CA-407370: Separate rsyslog configs for xenserver and customer

(yes, the tarball version doesn't match the changelog entry, but both
the tarball version and the SRPM release number are right)

Signed-off-by: Samuel Verschelde <[email protected]>
---
src/common/etc/rsyslog.d/xenserver.conf | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/common/etc/rsyslog.d/xenserver.conf b/src/common/etc/rsyslog.d/xenserver.conf
index be87229..d59c633 100644
--- a/src/common/etc/rsyslog.d/xenserver.conf
+++ b/src/common/etc/rsyslog.d/xenserver.conf
@@ -1,3 +1,8 @@
+# -- DO NOT EDIT THIS FILE --
+# xenserver.conf contains the XenServer specific logging configurations
+# Any remote forwarding should be configured in another file in /etc/rsyslog.d/
+# e.g. /etc/rsyslog.d/remote.conf
+
# Suppress duplicate messages and report "Last line repeated n times"
$RepeatedMsgReduction on

@@ -86,7 +91,3 @@ local1.* :omfile:$vmss_log
# xcp-rrdd-plugins (info and above) to local0
$outchannel xcp_rrdd_log,/var/log/xcp-rrdd-plugins.log,104857600,/etc/cron.daily/logrotate
local0.info :omfile:$xcp_rrdd_log
-
-# ignore default rules
-*.* ~
-
--
2.30.2

Comment on lines +31 to +40
Copy link
Contributor

@ydirson ydirson Oct 17, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This implies that rules ordering in the config is indeed significant in interpretation of the config and the impact of the change on ordering has not been been explained.
Analyzing this requires the full HTML doc matching the 8yo version we use (from rsyslogd-doc.rpm) as upstream website only seems to publish the latest, and manpage does not even mention $IncludeConfig.

There are "legacy" and "RainerScript" ways of configuring, the HTML doc seems to confirm my worries, as the config files we use essentially use legacy syntax:

RainerScript is easier to read and maintain, avoids side effects with include files

Be warned that legacy action format is hard to get right. It is recommended to use RainerScript-Style action format whenever possible!

To avoid any side effects, do a $ResetConfigVariables after the $IncludeConfig. It may also be a good idea to do a $ResetConfigVariables right at the start of the include, so that the module knows exactly what it does. Of course, one might specifically NOT do this to inherit parameters from the main file. As always, use it as it best fits...

how this config works

There are several kind of lines in those files:

  • manpage mentions:
    • Global directives (start with $)
    • Templates (we have none)
    • Output channels
    • Rules (selector + action), most of those we use being in legacy syntax
  • then HTML introduces

My understanding is that global directives are "last value written to a given directive wins", and output channel are "all apply, until a discard (~) action is triggered".

$IncludeConfig doc does not specify in which order the included files are processed.

before this change

we have the following files on a host:

  • rsyslog.conf, including rsyslog.d/*.conf
  • we ship
    • listen.conf (from systemd)
    • xenserver.conf, which finishes with a global discard rule, effectively neutralizing all rules in rsyslog.conf following the directive, and any coming from a file that would be included after it. That effectively neutralizes all of the directives in the default rsyslog.conf, but users could have uncommented some global directives there, and those would not be impacted by the global discard, as it is a Rules thing.

after an upgrade including this change

  • no more rule in rsyslog.conf
  • any global directive modified by the user after the $IncludeConfig gets lost
  • any rule coming from a file that would be included after xenserver.conf would get de-neutralized by the removal of the discard

also to consider

Current host-installer (and all versions published today for 8.x and 9.x) does not preserve any of those config files.

Copy link
Contributor

@ydirson ydirson Oct 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All in all, this change seems to:

  • allow a user config to include rules even if it gets included after xenserver.conf, neutralizing the effect the discard rule had on those files. But at the same time user configs do not seem to be promoted to "preserved on upgrade" status.
  • create that empty remote.conf file which Samuel showed is a dirty thing

So I'm not sure we really want that change after all 🤷

Copy link
Member Author

@stormi stormi Oct 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous situation is not a lot better. We have a xenserver.conf which can be modified by XAPI to add remote servers, but all changes are lost if any modification is made to the file in the RPM, as it is not %config(noreplace). It seems positive to me to move the contents that is under XAPI's responsibility to a separate remote.conf file.

If we were to refuse these changes in xcp-ng-release, then we would have to patch XAPI to come back to its old behaviour, which is not really good.

any global directive modified by the user after the $IncludeConfig gets lost

Except definitions of remote servers, which are migrated to remote.conf in %pre. And anyway I don't think xenserver.conf was ever supposed to be modified by users, given how . Thankfully, users rarely alter the rsyslog configuration for anything but remote forwarding, as far as I know.

So I'm not sure we really want that change after all 🤷

I agree that there are issues with the change, but there are also issues with not applying it, and I think the issues are going to be rare / easy to overcome. The worst I can foresee is someone losing changes made directly to rsyslog.conf, which is not supported.

But at the same time user configs do not seem to be promoted to "preserved on upgrade" status.

This is a good point that deserves considering for the upgrade to XCP-ng 9 (which will likely have a different configuration structure anyway for logging?), but not a new one given that xenserver.conf is not preserved either as far as I can see.

Copy link
Contributor

@rzr rzr Nov 14, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ydirson > $IncludeConfig doc does not specify in which order the included files are processed.

According to:
https://www.rsyslog.com/doc/configuration/global/options/rsconf1_includeconfig.html

"if multiple files are included, they are processed in ascending sort order of the file name"

We can use number prefixes to config files to force the ordering, and eventually propose users to use a range eg: [90-99]-*.conf ?

It looks like this feature is also available in the version shipped by xcp-ng (rsyslog-8.24.0-52.el7_8.2.x86_64)

[11:12 xcp-ng-pcl-11 ~]# lynx -dump  /usr/share/doc/rsyslog-8.24.0/html/configuration/global/options/rsconf1_includeconfig.html | grep -2 'if multiple files are included'
   the main file. As always, use it as it best fits...

   Note: if multiple files are included, they are processed in ascending
   sort order of the file name. We use the “glob()” C library function for

Extra note about loosing user changes in /etc, what about adding etc-keeper to distro (this tool track all changes in /etc in a local /etc/.git repo, I use it on most of my systems but it can grows over time, unsure there is a autosquash/garbage collector feature https://etckeeper.branchable.com/forum/_Any_suggestion_to_avoid_infinite_growth_of_.git___63__/ )

28 changes: 28 additions & 0 deletions SOURCES/0005-etc-rsyslog.d-xenserver.conf-mention-XCP-ng-in-addit.patch
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
From f34cd5acbe9b8e7292783b843ad4d167bbb8a259 Mon Sep 17 00:00:00 2001
From: Samuel Verschelde <[email protected]>
Date: Mon, 22 Sep 2025 18:32:10 +0200
Subject: [PATCH 5/5] /etc/rsyslog.d/xenserver.conf: mention XCP-ng in addition
to XenServer

I didn't completely replace XenServer with XCP-ng. After all, the file
is still named xenserver.conf, so that would be awkward.

Signed-off-by: Samuel Verschelde <[email protected]>
---
src/common/etc/rsyslog.d/xenserver.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/common/etc/rsyslog.d/xenserver.conf b/src/common/etc/rsyslog.d/xenserver.conf
index d59c633..0b65e65 100644
--- a/src/common/etc/rsyslog.d/xenserver.conf
+++ b/src/common/etc/rsyslog.d/xenserver.conf
@@ -1,5 +1,5 @@
# -- DO NOT EDIT THIS FILE --
-# xenserver.conf contains the XenServer specific logging configurations
+# xenserver.conf contains the XenServer/XCP-ng specific logging configurations
# Any remote forwarding should be configured in another file in /etc/rsyslog.d/
# e.g. /etc/rsyslog.d/remote.conf

--
2.30.2

3 changes: 3 additions & 0 deletions SOURCES/xenserver-release-v8.4.0-17.tar.gz
View file
Open in desktop
Git LFS file not shown
46 changes: 43 additions & 3 deletions SPECS/xcp-ng-release.spec
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,13 +11,13 @@
# XCP-ng: the globals below are not used. We only keep them as a reference
# from the last xenserver-release we (loosely) synced with
%global usver 8.4.0
%global xsver 15
%global xsver 18
%global xsrel %{xsver}%{?xscount}%{?xshash}
# This package is special since the package version needs to
# match the product version. When making a change to the source
# repo, only the release should be changed, not the version.

%global package_srccommit v8.4.0-15
%global package_srccommit v8.4.0-17
%define debug_package %{nil}
%define product_family CentOS Linux
%define variant_titlecase Server
Expand All @@ -38,14 +38,19 @@
%bcond_with build_py2
%endif

# XCP-ng: until we are ready to build with OpenSSL 3, we conditionnally disable spec file
# changes directly related to it.
# NOTE: once we support it, remove the condition altogether.
%bcond_with use_openssl3

#define beta Beta
%define dist .xcpng%{PRODUCT_VERSION_TEXT_SHORT}

%define _unitdir /usr/lib/systemd/system

Name: xcp-ng-release
Version: 8.3.0
Release: 32
Release: 33
Summary: XCP-ng release file
Group: System Environment/Base
License: GPLv2
Expand Down Expand Up @@ -110,6 +115,8 @@ Source0: https://github.com/xcp-ng/xcp-ng-release/archive/v%{version}/xcp
Patch1001: 0001-fix-curl-resolve-TLS-issue-caused-by-restrictive-con.patch
Patch1002: 0002-Sync-vm.slice-with-xenserver-release-v8.4.0-12.tar.g.patch
Patch1003: 0003-Sync-systemd-presets-with-xenserver-release-v8.4.0-1.patch
Patch1004: 0004-Sync-with-xenserver-release-v8.4.0-17.tar.gz.patch
Patch1005: 0005-etc-rsyslog.d-xenserver.conf-mention-XCP-ng-in-addit.patch

%description
XCP-ng release files
Expand Down Expand Up @@ -140,6 +147,15 @@ Obsoletes: xen-livepatch < 2.0-1.1
### xenserver-release-config is only included in real installs
#Requires: xenserver-config-packages
Requires: python3-xcp-libs

%if %{with use_openssl3}
# CA-401322: /sbin/update-issue calls openssl command which must link to
# compatible (or same version) openssl-libs. Here specify the require to
# ensure openssl-libs, openssl and %%name-config rpms to be updated in order.
Requires: openssl >= 3.0.9
Requires(pre): sed
Requires(pre): coreutils
Comment on lines +152 to +157
Copy link
Member Author

@stormi stormi Sep 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how this gets the packages updated in the order they want, but I haven't given it much thought.

Copy link
Contributor

@rzr rzr Nov 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment only apply to the 1st dep at:

27fd57a#diff-ff0cb122a768fd67f0299827b8f65762c64492394b3936e0cc649b64b556668aR115

Maybe a newline is missing just after SSL3

%endif
Requires(post): systemd xs-presets >= 1.4
Requires(preun): systemd xs-presets >= 1.4
Requires(postun): systemd xs-presets >= 1.4
Expand Down Expand Up @@ -259,6 +275,10 @@ rm -rf %{buildroot}
#### RULES ####
EOF

# Remove default rules from rsyslog.conf
# This is defined as everything after the "$IncludeConfig" line
sed -i '/$IncludeConfig/q' /etc/rsyslog.conf || true

%triggerin config -- setup
# Replace /etc/motd with our branded version
install -D -m 644 %{_sysconfdir}/motd.xs %{_sysconfdir}/motd
Expand Down Expand Up @@ -473,6 +493,12 @@ if [ -d /var/update/applied ]; then
done
fi

%pre config
# On first upgrade extract any log forwarding rules into remote.conf
if [ "$1" -eq "2" ] && [ -f %{_sysconfdir}/rsyslog.d/xenserver.conf ] && ! [ -f %{_sysconfdir}/rsyslog.d/remote.conf ] ; then
sed -n '/\*\.\*.*@/p' %{_sysconfdir}/rsyslog.d/xenserver.conf > %{_sysconfdir}/rsyslog.d/remote.conf
fi
Comment on lines +496 to +500
Copy link
Contributor

@ydirson ydirson Oct 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That "upgrade" logic is to create a rsyslog.d/remote.conf if one does not exist, and it will be empty for any case where no remote logging was configured. We may want to avoid the user removing it "just because it's empty" by prepending a comment in it.

Suggested change
%pre config
# On first upgrade extract any log forwarding rules into remote.conf
if [ "$1" -eq "2" ] && [ -f %{_sysconfdir}/rsyslog.d/xenserver.conf ] && ! [ -f %{_sysconfdir}/rsyslog.d/remote.conf ] ; then
sed -n '/\*\.\*.*@/p' %{_sysconfdir}/rsyslog.d/xenserver.conf > %{_sysconfdir}/rsyslog.d/remote.conf
fi
%pre config
# On first upgrade extract any log forwarding rules into remote.conf
if [ "$1" -eq "2" ] && [ -f %{_sysconfdir}/rsyslog.d/xenserver.conf ] && ! [ -f %{_sysconfdir}/rsyslog.d/remote.conf ] ; then
cat > %{_sysconfdir}/rsyslog.d/remote.conf <<EOF
# This file is intended to contain any log forwarding to a remote syslog.
# Do not remove, it will be recreated on next xcp-ng-release-config upgrade.
EOF
sed -n '/\*\.\*.*@/p' %{_sysconfdir}/rsyslog.d/xenserver.conf >> %{_sysconfdir}/rsyslog.d/remote.conf
fi

Copy link
Member Author

@stormi stormi Oct 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We must also check whether XAPI cares if remote.conf exists or not and might get confused by an empty remote.conf. I doubt it, but let's check.

CC @gthvn1

Copy link
Member Author

@stormi stormi Oct 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like XAPI doesn't read the file at all and only (over)writes it (or deletes it).

Copy link
Member Author

@stormi stormi Oct 15, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, a non-existing remote.conf is expected when no remote is configured. We don't need to create an empty file, but the script does so anyway. If the user removes it, no problem. When XAPI writes it, it does put a header telling you not to modify, so, although it would be nice to add a header for the initial remote.conf contents when migrated from rsyslog.conf, I think we can do without and remain in sync with XenServer's spec file on this.

Copy link
Member Author

@stormi stormi Oct 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What looks wrong, though, is that on every update of the RPM, the empty file will get re-created if it doesn't exist... And XAPI does delete it if you remove the remote forwarding configuration... This is a mess...

Copy link
Member Author

@stormi stormi Oct 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the best would be for XAPI not to delete the file when one removes the forwarding rule, but to empty it instead.

Copy link
Contributor

@rzr rzr Nov 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the best would be for XAPI not to delete the file when one removes the forwarding rule, but to empty it instead.

Yes I agrea, so I proposed this change upstream:

xapi-project/xen-api#6774

That said it should not be a blocker for x-n-r, should it be ?

Anyway et me also add a similar disclaimer (file "will be used for forwarding logging and not supposed to be edited") our side to enable a smooth transition.

Copy link
Member Author

@stormi stormi Nov 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That said it should not be a blocker for x-n-r, should it be ?

I don't think it's a blocker indeed.


%post config
%systemd_post move-kernel-messages.service
%systemd_post update-issue.service
Expand Down Expand Up @@ -615,6 +641,20 @@ systemctl preset-all --preset-mode=enable-only || :

# Keep this changelog through future updates
%changelog
* Mon Sep 22 2025 Samuel Verschelde <[email protected]> - 8.3.0-33
- Sync with xenserver-release-8.4.0-18
- Add 0004-Sync-with-xenserver-release-v8.4.0-17.tar.gz.patch
- Add 0005-etc-rsyslog.d-xenserver.conf-mention-XCP-ng-in-addit.patch
- *** Upstream changelog ***
* Thu Mar 13 2025 Gerald Elder-Vass <[email protected]> - 8.4.0-18
- CA-407370: Separate rsyslog configs for xenserver and customer
* Thu Mar 13 2025 Deli Zhang <[email protected]> - 8.4.0-17
- CP-50340: Revert "Obsolete unused packages for OpenSSL 3 upgrade"
* Fri Feb 07 2025 Deli Zhang <[email protected]> - 8.4.0-16
- CA-401322: Ensure openssl-libs, openssl and xenserver-release-config rpms to be updated in order
- CP-50340: Obsolete unused packages for OpenSSL 3 upgrade
- CP-50298: Move ssh config files to openssh.spec

* Thu May 08 2025 Andrii Sultanov <[email protected]> - 8.3.0-32
- Fix patches that weren't properly generated and included in the specfile:
- 0002-Sync-vm.slice-with-xenserver-release-v8.4.0-12.tar.g.patch
Expand Down