[MDEV-22638] Provide updateinfo.xml repository info for yum / dnf Created: 2020-05-19 Updated: 2023-11-27 Resolved: 2021-04-09 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Platform RedHat, Platform SUSE, Upgrades |
| Fix Version/s: | N/A |
| Type: | Task | Priority: | Major |
| Reporter: | Hartmut Holzgraefe | Assignee: | Alexey Bychko (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Attachments: |
|
| Description |
|
yum / dnf package managers can provide information about available package updates if an updateinfo.xml information file is available in a yum repository, and it is also possible to filter the retrieved information to eg. show only "security" or "CVE" related updates. Feature request: provide such updateinfo information in MariaDB yum/dnf repositories. |
| Comments |
| Comment by Sergei Golubchik [ 2020-06-09 ] | ||||||||||||||||||||||||||||||||||||||
|
It won't make any practical difference. Currently we release quarterly, after Oracle CPU. That is every MariaDB release is a security release. It can happen that MariaDB-server contains, for example, security fixes, but MariaDB-client, for example, doesn't. And MariaDB-common, basically, never does. But because of inter-package dependencies one cannot update just the server anyway. In other words if one will filter to show only "security" or "CVE" releases it will still show all releases. | ||||||||||||||||||||||||||||||||||||||
| Comment by Hartmut Holzgraefe [ 2020-07-08 ] | ||||||||||||||||||||||||||||||||||||||
|
But if we don't add the information then yum updateinfo list updates --security would never include MariaDB packages in its output, and user may be under false impression that there's no need to upgrade MariaDB as it is still fine security wise. | ||||||||||||||||||||||||||||||||||||||
| Comment by Hartmut Holzgraefe [ 2020-08-25 ] | ||||||||||||||||||||||||||||||||||||||
|
Current status is "need feedback", but I'm not sure feedback from whom it is waiting for? | ||||||||||||||||||||||||||||||||||||||
| Comment by Alexey Bychko (Inactive) [ 2021-04-01 ] | ||||||||||||||||||||||||||||||||||||||
|
need to try then. who will be maintaining the list of fixed issues? | ||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Golubchik [ 2021-04-01 ] | ||||||||||||||||||||||||||||||||||||||
|
it seems (I can be wrong) that it doesn't need a complete list of fixed issues, it could just have one issue "fixed security issues", with the reference url https://mariadb.com/kb/en/library/security/, marked as security release in metadata. That should be enough for yum/dnf to list it as a "security relevant upgrade" | ||||||||||||||||||||||||||||||||||||||
| Comment by Alexey Bychko (Inactive) [ 2021-04-02 ] | ||||||||||||||||||||||||||||||||||||||
|
script example: https://github.com/vmfarms/generate_updateinfo | ||||||||||||||||||||||||||||||||||||||
| Comment by Alexey Bychko (Inactive) [ 2021-04-05 ] | ||||||||||||||||||||||||||||||||||||||
|
seems centos doesn't support yum-security plugin to list the CVE's | ||||||||||||||||||||||||||||||||||||||
| Comment by Alexey Bychko (Inactive) [ 2021-04-05 ] | ||||||||||||||||||||||||||||||||||||||
|
schema for updateinfo https://github.com/openSUSE/libzypp/blob/master/zypp/parser/yum/schema/updateinfo.rnc | ||||||||||||||||||||||||||||||||||||||
| Comment by Alexey Bychko (Inactive) [ 2021-04-05 ] | ||||||||||||||||||||||||||||||||||||||
|
from my side i see no way to simply generate the updateinfo . we need to have the list of issues, links to jira and so on. I will attach examples. from my side it's wontfix, but serg may have another view | ||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Golubchik [ 2021-04-05 ] | ||||||||||||||||||||||||||||||||||||||
|
This — updateinfo.xml Something remotely similar for our repos could look like
| ||||||||||||||||||||||||||||||||||||||
| Comment by Alexey Bychko (Inactive) [ 2021-04-06 ] | ||||||||||||||||||||||||||||||||||||||
|
the RH way to generate updateinfo is: 1 - generate errata.xml with issues, links to bugzilla, etc but we have no errata.xml, so we may try to generate simplified updateinfo with some predefined values and some missing values in hope it will work. | ||||||||||||||||||||||||||||||||||||||
| Comment by Alexey Bychko (Inactive) [ 2021-04-06 ] | ||||||||||||||||||||||||||||||||||||||
|
seems RH schema is not the same as Suse | ||||||||||||||||||||||||||||||||||||||
| Comment by Alexey Bychko (Inactive) [ 2021-04-06 ] | ||||||||||||||||||||||||||||||||||||||
|
I'm not sure that Scientific linux example is a really example for RHEL/Centos and SLES. EPEL updateinfo differs in details. serg <package src=...> attribute is a name of src.rpm in your example and full URL to downloadable package in RHEL/Fedora/Centos. | ||||||||||||||||||||||||||||||||||||||
| Comment by Alexey Bychko (Inactive) [ 2021-04-06 ] | ||||||||||||||||||||||||||||||||||||||
|
ok, seems it works for me at least on centos-7.
| ||||||||||||||||||||||||||||||||||||||
| Comment by Alexey Bychko (Inactive) [ 2021-04-06 ] | ||||||||||||||||||||||||||||||||||||||
|
first version is here https://github.com/mariadb-corporation/MariaDBE-CI/blob/ci-scripts/gen-updateinfo.sh | ||||||||||||||||||||||||||||||||||||||
| Comment by Alexey Bychko (Inactive) [ 2021-04-06 ] | ||||||||||||||||||||||||||||||||||||||
|
dbart could you please test it on staging and let me know if it's OK or not?
to check if added repo has properly built updateinfo:
| ||||||||||||||||||||||||||||||||||||||
| Comment by Alexey Bychko (Inactive) [ 2021-04-06 ] | ||||||||||||||||||||||||||||||||||||||
|
attached generated updateinfo | ||||||||||||||||||||||||||||||||||||||
| Comment by Daniel Bartholomew [ 2021-04-06 ] | ||||||||||||||||||||||||||||||||||||||
|
Added updateinfo to the 10.5.9-6 staging repositories. Using the commands:
And repeated the above for RHEL 7, SLES 12, and SLES 15. I wasn't sure if "--platform-name" needed to be something specific so I just used "SLES" for SLES 12 and 15. I then uploaded the updated repositories to staging and force-synced them to the CDN. To test I started up my RHEL 8 test VM and set up the ES repos with 10.5.8-5 and installed MariaDB-server and MariaDB-client. Then I switched to the newly updated 10.5.9-6 staging repositories and tested the `dnf updateinfo ...` command. If you'd like to do it yourself, here are the exact commands I ran (you'll need to set token to your token):
The output from the `dnf updateinfo ...` command was:
Not sure why the MariaDB severity is listed as "Unknown". In my run of the gen-updateinfo.sh script I didn't change it from the script's default of "moderate". Does capitalization matter? | ||||||||||||||||||||||||||||||||||||||
| Comment by Daniel Bartholomew [ 2021-04-06 ] | ||||||||||||||||||||||||||||||||||||||
|
On SLES 15 I ran the same tests, I just needed to modify the install steps to use zypper and change the repo_file to the correct location. Like so:
I ran into some install issues related to openssl, but that is probably because my SLES 15 test VM is running 15.0 instead of the latest version. So I just forced it to install MariaDB anyway. Also, when I updated the repositories I neglected to update the repomd.xml.asc signature file, so zypper complained about it (RHEL didn't seem to care for some reason). The output of the `zypper list-patches ...` command was:
Here the severity seems to be set properly. Also interesting that it lists SLES's own repo versions of MariaDB, but with a "not needed" tag. | ||||||||||||||||||||||||||||||||||||||
| Comment by Alexey Bychko (Inactive) [ 2021-04-06 ] | ||||||||||||||||||||||||||||||||||||||
|
dbart perhaps capitalization does matter for RedHat. you may use --severity Moderate additional option when you're creating the updateinfo for RHEL. from EPEL updateinfo file I see
perhaps yes, RHEL has coded it in different way | ||||||||||||||||||||||||||||||||||||||
| Comment by Daniel Bartholomew [ 2021-04-06 ] | ||||||||||||||||||||||||||||||||||||||
|
Specifying "Moderate" instead of "moderate" does indeed work for RHEL 8:
And SLES doesn't mind the capitalization, so we can stick with "Moderate" as our default, unless we're in a situation where we're making a special release for a critical update, in which case we can specify that instead. So I will move forward with updating my automation to automatically add updateinfo.xml files to all our rpm repositories for future ES releases. One final question: I'm guessing we want the same for CS releases? | ||||||||||||||||||||||||||||||||||||||
| Comment by Daniel Bartholomew [ 2021-04-06 ] | ||||||||||||||||||||||||||||||||||||||
|
Additional test on CentOS 7 and it works just fine:
| ||||||||||||||||||||||||||||||||||||||
| Comment by Alexey Bychko (Inactive) [ 2021-04-07 ] | ||||||||||||||||||||||||||||||||||||||
|
ok, changed the default to Moderate. | ||||||||||||||||||||||||||||||||||||||
| Comment by Alexey Bychko (Inactive) [ 2021-04-07 ] | ||||||||||||||||||||||||||||||||||||||
|
one more detail: from support issue I see:
I'm wondering if it's just to list MariaDB in security updates OR it's about putting the details on security fix to xml. latter is more complicated and involving doc team. example from RedHat:
| ||||||||||||||||||||||||||||||||||||||
| Comment by Alexey Bychko (Inactive) [ 2021-04-07 ] | ||||||||||||||||||||||||||||||||||||||
|
discussed the issue with serg, need to adjust the script to use it for both CS & ES. and maybe we need to move my script to mariadb.org-tools repository | ||||||||||||||||||||||||||||||||||||||
| Comment by Alexey Bychko (Inactive) [ 2021-04-08 ] | ||||||||||||||||||||||||||||||||||||||
|
updated according to serg's comments. dbart please re-test and put the script to mariadb.org-tools repository if it's OK | ||||||||||||||||||||||||||||||||||||||
| Comment by Daniel Bartholomew [ 2021-04-09 ] | ||||||||||||||||||||||||||||||||||||||
|
Ran another test and things look OK. Added the script to the mariadb.org-tools repository. | ||||||||||||||||||||||||||||||||||||||
| Comment by Daniel Bartholomew [ 2021-04-09 ] | ||||||||||||||||||||||||||||||||||||||
|
I've also updated my prep scripts so that this new script is run automatically when I create the repositories (for both regular and Enterprise MariaDB releases) | ||||||||||||||||||||||||||||||||||||||
| Comment by Daniel Bartholomew [ 2021-04-12 ] | ||||||||||||||||||||||||||||||||||||||
|
ralf.gebhardt@mariadb.com All I'm doing is running the gen-updateinfo.sh script for each rpm-based distribution and applying the generated updateinfo.xml file to the repo metadata: https://github.com/MariaDB/mariadb.org-tools/blob/master/release/mkrepo-yum.sh#L722-L754 This happens during repository creation, so it will be there for every release. As serg says, there won't be individual CVEs in the xml file. What is there is enough for the `yum updateinfo list --security` command to notify users that the new MariaDB release has security fixes and display a link to https://mariadb.com/kb/en/security/ where users can view the CVEs. | ||||||||||||||||||||||||||||||||||||||
| Comment by Sascha Glade [ 2021-05-08 ] | ||||||||||||||||||||||||||||||||||||||
|
On Centos 7.9 I get the following error since yesterday:
Upon checking the XML, line 3 isn't valid:
The brackets around the e-mail address should be escaped with
and
| ||||||||||||||||||||||||||||||||||||||
| Comment by Vince Z [ 2021-05-08 ] | ||||||||||||||||||||||||||||||||||||||
|
+1 for Sascha's comment.
Centos 7.9 and started happening yesterday. I use:
| ||||||||||||||||||||||||||||||||||||||
| Comment by Daniel Bartholomew [ 2021-05-08 ] | ||||||||||||||||||||||||||||||||||||||
|
Working on fixing updateinfo.xml in the repositories... | ||||||||||||||||||||||||||||||||||||||
| Comment by Daniel Bartholomew [ 2021-05-08 ] | ||||||||||||||||||||||||||||||||||||||
|
The 10.2.38, 10.3.29, 10.4.19, and 10.5.10 yum repositories have all been updated with fixed updateinfo.xml files. Where they exist (not all of these exist for all MariaDB versions), the list of repositories updated includes:
The repositories on yum.mariadb.org and downloads.mariadb.com are live with the fix now. If you're using a repository from a 3rd-party mirror then the fix will not show up until that mirror next pulls from the primary mirror. | ||||||||||||||||||||||||||||||||||||||
| Comment by Sascha Glade [ 2021-05-08 ] | ||||||||||||||||||||||||||||||||||||||
|
Confirming the issue is solved for me with the fix. | ||||||||||||||||||||||||||||||||||||||
| Comment by Vince Z [ 2021-05-09 ] | ||||||||||||||||||||||||||||||||||||||
|
Same for me. Thank you |