Sync with xenserver-release-8.4.0-18 #33

stormi · 2025-09-22T17:03:08Z

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

Signed-off-by: Yann Dirson <[email protected]>

Signed-off-by: Samuel Verschelde <[email protected]>

- 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 Signed-off-by: Samuel Verschelde <[email protected]>

stormi · 2025-09-22T17:06:19Z

SPECS/xcp-ng-release.spec

+# 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


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

The comment only apply to the 1st dep at:

27fd57a#diff-ff0cb122a768fd67f0299827b8f65762c64492394b3936e0cc649b64b556668aR115

Maybe a newline is missing just after SSL3

SPECS/xcp-ng-release.spec

ydirson

The upstream tgz is kept in the merge.

I'm a bit wary of making such changes now that 8.3 is LTS. We would likely want to make some rather extensive tests, but we don't have access to every type of change our users may have done. I feel almost certain that this is going to break on some machines.

SOURCES/0005-etc-rsyslog.d-xenserver.conf-mention-XCP-ng-in-addit.patch

ydirson · 2025-10-06T16:17:35Z

SPECS/xcp-ng-release.spec

+%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


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

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

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

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.

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...

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

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.

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

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

…r rsyslog

stormi · 2025-10-15T10:35:37Z

Pre-build towards v8.3-u-stormi2: https://koji.xcp-ng.org/taskinfo?taskID=91533

ydirson · 2025-10-17T09:00:45Z

SOURCES/0004-Sync-with-xenserver-release-v8.4.0-17.tar.gz.patch

+ # 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
+


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

rulesets (set of rules, but the example shows only actions, no selector - latest doc has one though), but we use none

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.

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 🤷

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.

@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__/ )

stormi · 2025-10-20T15:04:27Z

Converting to draft. There is no urgent change here and we'd like to better manage the rsyslog configuration management update. The associated commit in XAPI was reverted.

Xenserver's changes around rsyslog configuration have downsides and the packaging prefers the previous behaviour because there's no time to properly fix the behaviour before the next release. For the original change, see xapi-project#6328 Discussions on why the original change is dubious: xcp-ng-rpms/xcp-ng-release#33 Reverts commit 468eb75. Signed-off-by: Pau Ruiz Safont <[email protected]>

SPECS/xcp-ng-release.spec

For the record this has been verified by enabling debug mode # /etc/sysconfig/rsyslog: Enable logs with SYSLOGD_OPTIONS="-d" RSYSLOG_DEBUG="Debug" RSYSLOG_DEBUGLOG="/tmp/rsyslog.log" # Create dummy files touch /etc/rsyslog.d/aa-before-listen.conf touch /etc/rsyslog.d/uu-before-xenserver.conf touch /etc/rsyslog.d/zz-after-xenserver.conf # Reparse sudo systemctl restart rsyslog && grep '\.conf' /tmp/rsyslog.log : config parser: pushed file /etc/rsyslog.conf on top of stack : requested to include config file '/etc/rsyslog.d/zz-after-xenserver.conf' : config parser: pushed file /etc/rsyslog.d/zz-after-xenserver.conf on top of stack : requested to include config file '/etc/rsyslog.d/xenserver.conf' : config parser: pushed file /etc/rsyslog.d/xenserver.conf on top of stack : requested to include config file '/etc/rsyslog.d/uu-before-xenserver.conf' : config parser: pushed file /etc/rsyslog.d/uu-before-xenserver.conf on top of stack : requested to include config file '/etc/rsyslog.d/listen.conf' : config parser: pushed file /etc/rsyslog.d/listen.conf on top of stack : requested to include config file '/etc/rsyslog.d/aa-before-listen.conf' : config parser: pushed file /etc/rsyslog.d/aa-before-listen.conf on top of stack : config parser: reached end of file /etc/rsyslog.d/aa-before-listen.conf : config parser: resume parsing of file /etc/rsyslog.d/listen.conf at line 1 : config parser: reached end of file /etc/rsyslog.d/listen.conf : config parser: resume parsing of file /etc/rsyslog.d/uu-before-xenserver.conf at line 1 : config parser: reached end of file /etc/rsyslog.d/uu-before-xenserver.conf : config parser: resume parsing of file /etc/rsyslog.d/xenserver.conf at line 1 : config parser: reached end of file /etc/rsyslog.d/xenserver.conf : config parser: resume parsing of file /etc/rsyslog.d/zz-after-xenserver.conf at line 1 : config parser: reached end of file /etc/rsyslog.d/zz-after-xenserver.conf : config parser: resume parsing of file /etc/rsyslog.conf at line 36 : config parser: reached end of file /etc/rsyslog.conf Relate-to: xcp-ng-rpms/xcp-ng-release#33 (comment) Signed-off-by: Philippe Coval <[email protected]>

Xenserver's changes around rsyslog configuration have downsides and the packaging prefers the previous behaviour because there's no time to properly fix the behaviour before the next release. For the original change, see xapi-project#6328 Discussions on why the original change is dubious: xcp-ng-rpms/xcp-ng-release#33 Reverts commit 468eb75. Signed-off-by: Pau Ruiz Safont <[email protected]>

rzr · 2025-11-28T09:21:18Z

every type of change our users may have done.

Where exactly ? in new included files ? or in xenserver.conf (eg: removal of discarded rules) ?

For changes in rsylogs after last includes i am less concerned ( https://github.com/xcp-ng-rpms/xcp-ng-release/pull/33#discussion_r2570927813# backup)

Can you suggest any scenario to be tested ?

ydirson and others added 2 commits August 29, 2025 13:11

Import xenserver-release-8.4.0-17.xs8.src.rpm

27fd57a

Signed-off-by: Yann Dirson <[email protected]>

Import xenserver-release-8.4.0-18.xs8.src.rpm

39ea6a0

Signed-off-by: Samuel Verschelde <[email protected]>

stormi requested a review from psafont September 22, 2025 17:03

stormi force-pushed the 8.3-rebase-XS20250922 branch from 86e6fdf to b46d6f0 Compare September 22, 2025 17:04

stormi commented Sep 22, 2025

View reviewed changes

SPECS/xcp-ng-release.spec Show resolved Hide resolved

stormi commented Sep 22, 2025

View reviewed changes

SPECS/xcp-ng-release.spec Show resolved Hide resolved

stormi changed the title ~~8.3 rebase xs20250922~~ Sync with xenserver-release-8.4.0-18 Sep 22, 2025

stormi mentioned this pull request Sep 22, 2025

Rebase on xenserver-release-8.4.0-18.xs8.src.rpm xcp-ng/xcp-ng-release#51

Draft

ydirson requested changes Oct 6, 2025

View reviewed changes

fixup! Remove extraneous tarball, and update xenserver.conf header fo…

8987797

…r rsyslog

stormi requested a review from ydirson October 15, 2025 10:33

stormi marked this pull request as ready for review October 15, 2025 10:33

stormi requested a review from a team as a code owner October 15, 2025 10:33

psafont approved these changes Oct 16, 2025

View reviewed changes

ydirson reviewed Oct 17, 2025

View reviewed changes

stormi marked this pull request as draft October 20, 2025 15:04

rzr reviewed Nov 14, 2025

View reviewed changes

SPECS/xcp-ng-release.spec Show resolved Hide resolved

Sync with xenserver-release-8.4.0-18 #33

Are you sure you want to change the base?

Sync with xenserver-release-8.4.0-18 #33

Uh oh!

Conversation

stormi commented Sep 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ydirson left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stormi Oct 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stormi commented Oct 15, 2025

Uh oh!

ydirson Oct 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

how this config works

before this change

after an upgrade including this change

also to consider

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rzr Nov 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stormi commented Oct 20, 2025

Uh oh!

Uh oh!

rzr commented Nov 28, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

stormi commented Sep 22, 2025 •

edited

Loading

stormi Oct 15, 2025 •

edited

Loading

ydirson Oct 17, 2025 •

edited

Loading

rzr Nov 14, 2025 •

edited

Loading