Docker 23.0.2 has been released on March 28: https://github.com/moby/moby/releases/tag/v23.0.2 The Github advisory for the issue is here: https://github.com/moby/buildkit/security/advisories/GHSA-gc89-7gcr-jxqc But I don't know which piece of software it's referring to in its versions listed. I assume it's something that Docker/moby bundles.
Seems to be a security issue related to the docker build command part.
Status: NEW => ASSIGNED
Docker 23.0.2 has been released on April 4: https://github.com/moby/moby/releases/tag/v23.0.3 It fixes more security issues and references this advisory: https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw
Whiteboard: (none) => MGA8TOOSummary: docker new security issue CVE-2023-26054 => docker new security issues CVE-2023-26054 and CVE-2023-2884[0-2]Status comment: (none) => Fixed upstream in 23.0.3
Ping. Also good to update for functionality on par with other distros, such as user asking in https://forums.mageia.org/en/viewtopic.php?t=14941
CC: (none) => fri
https://github.com/moby/moby/releases/tag/v24.0.2 released last hour :)
@Bruno What do you think?
CC: (none) => yves.brungard_mageia
I think that it needs to be updated of course, but I already encountered issues with 23.0.2 with vendored content: ../../../../../src/vendor/github.com/docker/docker/daemon/config/config.go:16:2: use of vendored package not allowed And if you try to remove the vendored content you get another error :-( So I was stuck with that and didn't had enough time to dig more. And it won't happen till end of next week, sorry.
A new full docker stack is on its way to cauldron updates_testing. Would be great to have it tested so we can provide these updates very early in mga9 live. You'll have to install: docker-24.0.5-2.mga8.x86_64.rpm docker-containerd-1.7.3-1.mga8.x86_64.rpm opencontainers-runc-1.1.9-1.mga8.x86_64.rpm docker-logrotate-24.0.5-2.mga8.x86_64.rpm golang-github-mrunalp-fileutils-0.5.0-3.mga8.x86_64.rpm to test it. Much more details available at: https://brunocornec.wordpress.com/2023/08/17/docker-stack-updates-for-mageia-9/
Assignee: bruno => qa-bugs
Status comment: Fixed upstream in 23.0.3 => (none)
CC: (none) => bruno
Great news, thanks a lot. I was briefly playing around with it and I found out that 'docker compose' gives the result docker: 'compose' is not a docker command See 'docker --help' But the 'docker --version' command gives me the correct version of 24.0.5, build: ced099660009713e0e845eeb754e6050dbaa45d0 In this version compose should be already a docker command afaik. Not sure if I did something wrong here, or this is a bug.
CC: (none) => timoofone
docker-compose is a package, not a command. $ urpmq -i docker-compose|grep -e ^Source -e ^Summary|sort -u Source RPM : docker-compose-1.26.2-1.mga8.src.rpm Summary : Multi-container orchestration for Docker
CC: (none) => davidwhodgins
(In reply to Timo Netzer from comment #8) > Great news, thanks a lot. I was briefly playing around with it and I found > out that 'docker compose' gives the result > > docker: 'compose' is not a docker command > See 'docker --help' > > But the 'docker --version' command gives me the correct version of 24.0.5, > build: ced099660009713e0e845eeb754e6050dbaa45d0 > > In this version compose should be already a docker command afaik. > > Not sure if I did something wrong here, or this is a bug. It's the case if you also install the new docker-compose plugin which gives you the docker compose command with docker 24.0.5 *and* docker-compose-2 Tested here with success. For dave, moving from docker-compoe-1 to docker-compose-2 changes the way people have to invoke the composer: Before it was a python script called docker-compose. Now it's a docker go plugin installed and dynamically loaded by the docker compose command. Hoe that is clarifying stuff.
Now that Cauldron has transformed into Mageia 10, what is the status of this with regard to Mageia 9? According to drakrpm, Docker in Mageia 9 is version 20.10.22-1.mga9. Qarepo can't find any packages containing "docker" in the M9 update testing repos, and we have no M9 list here to work with.
CC: (none) => andrewsfarm
The package will need to be resubmitted to the build system as it is not in updates testing for m9.
Version: Cauldron => 9Keywords: (none) => feedback
I see on my mirror: 9/SRPMS/core/updates_testing/golang-github-mrunalp-fileutils-0.5.0-3.mga9.src.rpm 9/SRPMS/core/updates_testing/docker-24.0.5-2.mga9.src.rpm 9/SRPMS/core/updates_testing/docker-containerd-1.7.3-1.mga9.src.rpm 9/SRPMS/core/updates_testing/golang-1.21.0-1.mga9.src.rpm 9/SRPMS/core/updates_testing/opencontainers-runc-1.1.9-1.mga9.src.rpm We first need to have golang-1.21 validated *and* and updated on the build system so I can re-submit docker-compose v2 and docker-buildx which are not built without it. What request should I do on which ML to have the freeze push done ? Should QA test first that ?
Keywords: feedback => (none)
Check a mirror that is fully up-to-date such as http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/9/SRPMS/core/updates_testing/ It currently only has ... [DIR] media_info/ 2023-08-28 19:36 - [DIR] repodata/ 2023-08-28 19:36 - [ ] darktable-4.4.2-1.mga9.src.rpm 2023-08-28 10:23 5.8M [ ] gnucobol-3.2-1.mga9.src.rpm 2023-08-27 19:49 8.0M [ ] kernel-6.4.12-1.mga9.src.rpm 2023-08-28 13:38 136M [ ] kmod-virtualbox-7.0.10-26.mga9.src.rpm 2023-08-28 14:46 165K [ ] kmod-xtables-addons-3.24-42.mga9.src.rpm 2023-08-28 14:46 142K [ ] libdrm-2.4.116-1.mga9.src.rpm 2023-08-27 16:44 521K [ ] mesa-23.1.6-1.mga9.src.rpm 2023-08-27 18:45 18M [ ] mixxx-2.3.6-1.mga9.src.rpm 2023-08-28 19:36 38M [ ] systemd-253.8-1.mga9.src.rpm 2023-08-28 14:54 12M Note that all of the m9 updates testing repos were created as empty repos as part of the release process. Mirrors that have not been updated since the release still have things from cauldron updates testing, but don't have the final iso images. After golang has been pushed as a qa validated update, request that it be pushed to the build system on the dev and/or sysadmin-discuss ml.
Oops, sorry, I removed the --delete options to my mirror to avoid issues while mga9 was syncing and forgot to add it bacK; Indeded, they are now missing :-( So I pushed first golang on cauldron and 9 for updates_testing (seems the build farm has issues on ARM) I'll now pushed the other not depending on it, that QA will be able to test, and once it's ready the rest.
Mageia 8, x86_64 Installed updates. docker-24.0.5-2.mga8.x86_64.rpm docker-containerd-1.7.3-1.mga8.x86_64.rpm opencontainers-runc-1.1.9-1.mga8.x86_64.rpm docker-logrotate-24.0.5-2.mga8.x86_64.rpm golang-github-mrunalp-fileutils-0.5.0-3.mga8.x86_64.rpm Started docker daemon. Running Bruno's docker lab examples: $ docker run hello-world Hello from Docker! This message shows that your installation appears to be working correctly. .... $ docker run -it fedora:latest bash [root@6e92aa797427 /]# <in another terminal> $ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6e92aa797427 fedora:latest "bash" 27 seconds ago Up 27 seconds adoring_hermann 9c35fce8ed65 hello-world "/hello" 5 minutes ago Exited (0) 5 minutes ago romantic_lamarr a791ac49e724 fedora:latest "bash" 5 weeks ago Exited (0) 5 weeks ago blissful_williamson $ docker rm a791ac49e724 a791ac49e724 <continuing docker run> [root@6e92aa797427 /]# dnf install ruby Fedora 38 - x86_64 5.7 MB/s | 83 MB 00:14 [...] Install 11 Packages Total download size: 5.5 M Installed size: 19 M Is this ok [y/N]: y [...] Installed: ruby-3.2.2-180.fc38.x86_64 ruby-default-gems-3.2.2-180.fc38.noarch [...] Complete! [root@6e92aa797427 /]# dnf install irb Last metadata expiration check: 1:02:07 ago on Tue Sep 5 15:54:12 2023. Dependencies resolved. [...] Installed: rubygem-irb-1.6.2-180.fc38.noarch Complete! [root@6e92aa797427 /]# irb irb(main):001:0> require 'prime' e': cannot load such file -- prime (LoadError) from <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>: [...] <Pushing my luck there but the REPL works> [root@6e92aa797427 /]# exit $ docker run -it debian bash Unable to find image 'debian:latest' locally latest: Pulling from library/debian de4cac68b616: Pull complete Digest: sha256:b91baba9c2cae5edbe3b0ff50ae8f05157e3ae6f018372dcfc3aba224acb392b Status: Downloaded newer image for debian:latest root@5a32bd732037:/# ls /proc/sys abi debug dev fs fscache kernel net sunrpc user vm root@5a32bd732037:/# apt-get install -y cowsay fortune root@5a32bd732037:/# /usr/games/fortune | /usr/games/cowsay _________________________________________ < A day for firm decisions!!!!! Or is it? > ----------------------------------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || root@5a32bd732037:/# exit Have a vague memory that there is a command available to test mrunalp-fileutils. Apart from that, docker looks fine for Mageia 8.
CC: (none) => tarazed25
Whiteboard: MGA8TOO => MGA8TOO MGA8-64-OK
MGA9-64, Xfce, VirtualBox The following 88 packages are going to be installed: - appstream-util-0.8.0-2.mga9.x86_64 - autoconf-2.71-5.mga9.noarch - automake-1.16.5-3.mga9.noarch - autopoint-0.21.1-2.mga9.x86_64 - cgroup-0.41-5.mga9.x86_64 - cmake-rpm-macros-9-9.mga9.noarch - ctags-6.0.0-3.mga9.x86_64 - debugedit-5.0-5.mga9.x86_64 - docbook-style-dsssl-1.79-20.mga9.noarch - docbook-style-xsl-1.79.2-6.mga9.noarch - docbook-utils-0.6.14-24.mga9.noarch - docker-24.0.5-2.mga9.x86_64 - docker-containerd-1.7.3-1.mga9.x86_64 - docker-devel-24.0.5-2.mga9.x86_64 - docker-fish-completion-24.0.5-2.mga9.x86_64 - docker-logrotate-24.0.5-2.mga9.x86_64 - docker-nano-24.0.5-2.mga9.x86_64 - docker-zsh-completion-24.0.5-2.mga9.x86_64 - dwz-0.15-1.mga9.x86_64 - efi-srpm-macros-5-3.mga9.noarch - elfutils-0.189-1.mga9.x86_64 - fish-3.6.1-1.mga9.x86_64 - fonts-srpm-macros-2.0.5-6.mga9.noarch - gcc-12.3.0-3.mga9.x86_64 - gcc-c++-12.3.0-3.mga9.x86_64 - gcc-cpp-12.3.0-3.mga9.x86_64 - gcc-plugins-12.3.0-3.mga9.x86_64 - gdb-headless-12.1-7.mga9.x86_64 - gdb-minimal-12.1-7.mga9.x86_64 - glibc-2.36-49.mga9.x86_64 - glibc-devel-2.36-49.mga9.x86_64 - go-srpm-macros-3.2.0-1.mga9.noarch - golang-1.21.0-1.mga9.x86_64 - golang-bin-1.21.0-1.mga9.x86_64 - golang-src-1.21.0-1.mga9.noarch - gtk-doc-1.33.2-6.mga9.noarch - guile3.0-runtime-3.0.8-2.mga9.x86_64 - help2man-1.49.3-1.mga9.noarch - isl-0.24-2.mga9.x86_64 - kernel-userspace-headers-6.5.3-1.mga9.x86_64 - lib64babeltrace1-1.5.11-1.mga9.x86_64 - lib64cgroup1-0.41-5.mga9.x86_64 - lib64guile3.0_1-3.0.8-2.mga9.x86_64 - lib64ipt2-2.0.5-2.mga9.x86_64 - lib64isl23-0.24-2.mga9.x86_64 - lib64mpc3-1.3.1-1.mga9.x86_64 - lib64openjade0-1.3.3-0.pre1.27.mga9.x86_64 - lib64osp5-1.5.2-25.mga9.x86_64 - lib64pcre1-8.45-3.mga9.x86_64 - lib64pcre16_0-8.45-3.mga9.x86_64 - lib64pcre32_0-8.45-3.mga9.x86_64 - lib64pcreposix1-8.45-3.mga9.x86_64 - lib64source-highlight4-3.1.9-13.mga9.x86_64 - lib64xcrypt-devel-4.4.33-3.mga9.x86_64 - libgomp-devel-12.3.0-3.mga9.x86_64 - libstdc++-devel-12.3.0-3.mga9.x86_64 - libstdc++-python-devel-12.3.0-3.mga9.x86_64 - libtool-base-2.4.7-1.mga9.x86_64 - lua-srpm-macros-1-6.mga9.noarch - m4-1.4.19-2.mga9.x86_64 - make-4.4.1-1.mga9.x86_64 - ocaml-srpm-macros-7-1.mga9.noarch - opencontainers-runc-1.1.9-1.mga9.x86_64 - openjade-1.3.3-0.pre1.27.mga9.x86_64 - opensp-1.5.2-25.mga9.x86_64 - pcre-8.45-3.mga9.x86_64 - perl-Exporter-Tiny-1.6.0-1.mga9.noarch - perl-File-Slurp-9999.320.0-2.mga9.noarch - perl-List-MoreUtils-0.430.0-6.mga9.noarch - perl-List-MoreUtils-XS-0.430-5.mga9.x86_64 - perl-SGMLSpm-1.03ii-5.mga9.noarch - perl-srpm-macros-1-35.mga9.noarch - perl-YAML-1.300.0-3.mga9.noarch - perl-YAML-Tiny-1.730.0-4.mga9.noarch - python3-enchant-3.2.2-1.mga9.noarch - python3-file-magic-5.44-1.mga9.noarch - python3-pygments-2.13.0-1.mga9.noarch - python3-rpm-generators-12-9.mga9.noarch - rpm-build-4.18.0-7.mga9.x86_64 - rpm-mageia-setup-build-2.71-1.mga9.x86_64 - rpmlint-1.11-7.mga9.noarch - rpmlint-mageia-policy-0.2.29-8.mga9.noarch - rust-srpm-macros-24-1.mga9.noarch - source-highlight-3.1.9-13.mga9.x86_64 - spec-helper-0.31.24-1.mga9.noarch - xsltproc-1.1.38-1.mga9.x86_64 - zsh-5.9-3.mga9.x86_64 - zstd-1.5.5-1.mga9.x86_64 832MB of additional disk space will be used. $ docker --version Docker version 24.0.5, build ced099660009713e0e845eeb754e6050dbaa45d0 requires service to be running. That won't start: # systemctl restart docker Job for docker.service failed because the control process exited with error code. See "systemctl status docker.service" and "journalctl -xeu docker.service" for details. # systemctl status docker.service × docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; preset: disabled) Active: failed (Result: exit-code) since Sat 2023-09-16 11:17:57 CDT; 12s ago TriggeredBy: × docker.socket Docs: http://docs.docker.com Process: 2027 ExecStartPre=/usr/sbin/docker-network-cleanup (code=exited, status=0/SUCCESS) Process: 2030 ExecStart=/usr/sbin/dockerd $OPTIONS $DOCKER_STORAGE_OPTIONS $DOCKER_NETWORK_OPTIONS $INSECURE_REGISTRY (code=exited, status=1/FAILURE) Process: 2039 ExecStopPost=/usr/sbin/docker-network-cleanup (code=exited, status=0/SUCCESS) Main PID: 2030 (code=exited, status=1/FAILURE) CPU: 58ms Sep 16 11:17:57 localhost systemd[1]: docker.service: Scheduled restart job, restart counter is at 3. Sep 16 11:17:57 localhost systemd[1]: Stopped docker.service. Sep 16 11:17:57 localhost systemd[1]: docker.service: Start request repeated too quickly. Sep 16 11:17:57 localhost systemd[1]: docker.service: Failed with result 'exit-code'. Sep 16 11:17:57 localhost systemd[1]: Failed to start docker.service. # journalctl -xeu docker.service Sep 16 11:17:57 localhost systemd[1]: Stopped docker.service. ░░ Subject: A stop job for unit docker.service has finished ░░ Defined-By: systemd ░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel ░░ ░░ A stop job for unit docker.service has finished. ░░ ░░ The job identifier is 1894 and the job result is done. Sep 16 11:17:57 localhost systemd[1]: docker.service: Start request repeated too quickly. Sep 16 11:17:57 localhost systemd[1]: docker.service: Failed with result 'exit-code'. ░░ Subject: Unit failed ░░ Defined-By: systemd ░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel ░░ ░░ The unit docker.service has entered the 'failed' state with result 'exit-code'. Sep 16 11:17:57 localhost systemd[1]: Failed to start docker.service. ░░ Subject: A start job for unit docker.service has failed ░░ Defined-By: systemd ░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel ░░ ░░ A start job for unit docker.service has finished with a failure. ░░ ░░ The job identifier is 1894 and the job result is failed. ...skipping... Sep 16 11:17:57 localhost systemd[1]: Stopped docker.service. ░░ Subject: A stop job for unit docker.service has finished ░░ Defined-By: systemd ░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel ░░ ░░ A stop job for unit docker.service has finished. ░░ ░░ The job identifier is 1894 and the job result is done. Sep 16 11:17:57 localhost systemd[1]: docker.service: Start request repeated too quickly. Sep 16 11:17:57 localhost systemd[1]: docker.service: Failed with result 'exit-code'. ░░ Subject: Unit failed ░░ Defined-By: systemd ░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel ░░ ░░ The unit docker.service has entered the 'failed' state with result 'exit-code'. Sep 16 11:17:57 localhost systemd[1]: Failed to start docker.service. ░░ Subject: A start job for unit docker.service has failed ░░ Defined-By: systemd ░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel ░░ ░░ A start job for unit docker.service has finished with a failure. ░░ ░░ The job identifier is 1894 and the job result is failed. lines 305-327/327 (END) ------------ I'm not a docker user by default - but not working for me. Note: I'm using RPM and not DNF.
CC: (none) => brtians1Keywords: (none) => feedback
@Brian with reference to comment 21. Have I missed something? Have not seen golang-1.21 in testing yet. See comment 13. Was hanging back for a full package list for docker as well. Concerning starting the service: Have you added yourself to the docker group? Problem here before I did that. The service starts alright for docker version 20.10.22 and the hello-world check succeeds.
Mageia9 x86_64 Started docker service OK. Used this list to update: docker-24.0.5-2.mga9.x86_64 docker-containerd-1.7.3-1.mga9.x86_64 docker-devel-24.0.5-2.mga9.x86_64 docker-fish-completion-24.0.5-2.mga9.x86_64 docker-logrotate-24.0.5-2.mga9.x86_64 docker-nano-24.0.5-2.mga9.x86_64 docker-zsh-completion-24.0.5-2.mga9.x86_64 $ rpm -q golang golang-1.20.5-1.mga9 $ sudo systemctl restart docker Job for docker.service failed because the control process exited with error code. See "systemctl status docker.service" and "journalctl -xeu docker.service" for details. That confirms Brian's result, so we need that feedback (golang?).
Oops. Forgot: opencontainers-runc-1.1.9-1.mga9.x86_64.rpm golang-github-mrunalp-fileutils-0.5.0-3.mga9.x86_64.rpm Made no difference after they were installed.
@Bruno: This bug has been OKed for MGA8, but MGA9 appears to be stuck waiting for golang 1.21. Golang 1.21 is in updates_testing, but I don't find a bug associated with it aside from this one. Even with golang 1.21 installed, Brian couldn't get docker to work (comment 17). How much more time do you need to correct the MGA9 problems? If it would extend beyond the MGA8 EOL date, I would suggest we split this bug in two, this one for MGA8 (which could be pushed) and another for MGA9. What do you think?
This is a security issue. If fix is working on mga8, I suggest we ship it per this bug now, and open another bug for mga9. Anyhow we need an advisory proposal for mga8 (at least)
(In reply to Thomas Andrews from comment #21) > @Bruno: This bug has been OKed for MGA8, but MGA9 appears to be stuck > waiting for golang 1.21. Golang 1.21 is in updates_testing, but I don't find > a bug associated with it aside from this one. Even with golang 1.21 > installed, Brian couldn't get docker to work (comment 17). I don't see the relationship with golang here (which is needed to *build* docker not to run it). I'll try to update my mga9 machine to see whether I reproduce that or not. (don't have many yet). > How much more time do you need to correct the MGA9 problems? If it would > extend beyond the MGA8 EOL date, I would suggest we split this bug in two, > this one for MGA8 (which could be pushed) and another for MGA9. > > What do you think? I have no pb to split the BR so we can close for mga8. BUT: can we have a newer version for mga8 without having it for mga9. I think no :-( So I think we should keep that together, and me working to solve the mga9 report.
(In reply to Bruno Cornec from comment #23) > (In reply to Thomas Andrews from comment #21) > > @Bruno: This bug has been OKed for MGA8, but MGA9 appears to be stuck > > waiting for golang 1.21. Golang 1.21 is in updates_testing, but I don't find > > a bug associated with it aside from this one. Even with golang 1.21 > > installed, Brian couldn't get docker to work (comment 17). > > I don't see the relationship with golang here (which is needed to *build* > docker not to run it). I'll try to update my mga9 machine to see whether I > reproduce that or not. (don't have many yet). > It's just that it's been my understanding that it would be a no-no to use a tool/language to build a package for Mageia 9 that is a higher version than the one actually IN Mageia 9. Danger of needing an unavailable library, for example. But I'm not in any way a developer, so I guess I could be wrong about that. > > How much more time do you need to correct the MGA9 problems? If it would > > extend beyond the MGA8 EOL date, I would suggest we split this bug in two, > > this one for MGA8 (which could be pushed) and another for MGA9. > > > > What do you think? > > I have no pb to split the BR so we can close for mga8. > BUT: can we have a newer version for mga8 without having it for mga9. I > think no :-( So I think we should keep that together, and me working to > solve the mga9 report. Oh, yeah. Breaking the upgrade path. I didn't think about that one.
@Bruno, regarding comment 23. Sorry for the golang comment. I had not understood that docker had already been rebuilt with the newer golang, which I did not remember seeing in testing.
That version of docker changed the option to use when launching the dockerd daemon for storage from -g to --data-root(In reply to Bruno Cornec from comment #23) > (In reply to Thomas Andrews from comment #21) > > @Bruno: This bug has been OKed for MGA8, but MGA9 appears to be stuck > > waiting for golang 1.21. Golang 1.21 is in updates_testing, but I don't find > > a bug associated with it aside from this one. Even with golang 1.21 > > installed, Brian couldn't get docker to work (comment 17). > > I don't see the relationship with golang here (which is needed to *build* > docker not to run it). I'll try to update my mga9 machine to see whether I > reproduce that or not. (don't have many yet). > > > How much more time do you need to correct the MGA9 problems? If it would > > extend beyond the MGA8 EOL date, I would suggest we split this bug in two, > > this one for MGA8 (which could be pushed) and another for MGA9. > > > > What do you think? > > I have no pb to split the BR so we can close for mga8. > BUT: can we have a newer version for mga8 without having it for mga9. I > think no :-( So I think we should keep that together, and me working to > solve the mga9 report. That new version of docker has an incompatible change for the storage option management (from -g to --data-root in /etc/sysconfig/docker-storage). I had changed that on my stsems so that's why it worked for me and probably not for you if you didn't made that change on your side. I have now added an automatic substitution as post operation to help migrating more automatically. Let's see if these new packages work for you (they are on their way to updaets_testing for mga9). Cauldron also updated.
Mageia9, x64 Update list: docker-24.0.5-3.mga9.x86_64.rpm docker-containerd-1.7.3-1.mga9.x86_64.rpm docker-devel-24.0.5-3.mga9.x86_64.rpm docker-fish-completion-24.0.5-3.mga9.x86_64.rpm docker-logrotate-24.0.5-3.mga9.x86_64.rpm docker-nano-24.0.5-3.mga9.x86_64.rpm docker-zsh-completion-24.0.5-3.mga9.x86_64.rpm $ rpm -q docker docker-24.0.5-3.mga9 Could not start docker.service. Nov 06 01:17:24 yildun systemd[1]: docker.service: Start request repeated too quickly. Nov 06 01:17:24 yildun systemd[1]: docker.service: Failed with result 'exit-code'. ░░ Subject: Unit failed
/etc/sysconfig/docker-storage had not been modified so I edited it to use --data-root in docker-storage. That did the trick; docker.service now in play. Shall put it through its paces tomorrow, i.e. today, later.
Ran the dockerlab test, as in comment 16. $ docker run -it fedora:latest bash Unable to find image 'fedora:latest' locally latest: Pulling from library/fedora 315d8c5c1d7b: Pull complete Digest: sha256:8285246bd5fad4e76e17a71c88dee34c49e2f227dab4ce7df704b592f8e72d41 Status: Downloaded newer image for fedora:latest [root@cf10e0b67f62 /]# dnf install stellarium <262 packages downloaded and installed> Complete! [root@cf10e0b67f62 /]# stellarium qt.qpa.xcb: could not connect to display qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Available platform plugins are: vkkhrdisplay, eglfs, minimal, vnc, minimalegl, linuxfb, xcb, offscreen. Aborted (core dumped) <Maybe that was a bit ambitious> [root@cf10e0b67f62 /]# dnf remove stellarium ..... Transaction Summary ==================================================================================== Remove 257 Packages Freed space: 1.1 G Is this ok [y/N]: y Transaction Summary ==================================================================================== Remove 257 Packages Freed space: 1.1 G ...... Complete! [root@cf10e0b67f62 /]# exit $ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES cf10e0b67f62 fedora:latest "bash" 2 hours ago Exited (0) 42 seconds ago silly_wilson $ docker run -it debian bash Unable to find image 'debian:latest' locally latest: Pulling from library/debian 8457fd5474e7: Pull complete Digest: sha256:fab22df37377621693c68650b06680c0d8f7c6bf816ec92637944778db3ca2c0 Status: Downloaded newer image for debian:latest root@5a32bd732037:/# ls /proc/sys abi debug dev fs fscache kernel net sunrpc user vm root@0703d0e9d117:/# apt-get install -y cowsay fortune Reading package lists... Done Building dependency tree... Done Reading state information... Done E: Unable to locate package cowsay E: Unable to locate package fortune root@0703d0e9d117:/# exit exit $ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 0703d0e9d117 debian "bash" 3 minutes ago Exited (100) About a minute ago admiring_montalcini cf10e0b67f62 fedora:latest "bash" 2 hours ago Exited (0) 5 minutes ago silly_wilson $ docker remove 0703d0e9d117 0703d0e9d117 Looks like it is working normally. Leaving status as it is until the configuration issue is automated.
(In reply to Bruno Cornec from comment #10) > (In reply to Timo Netzer from comment #8) > > Great news, thanks a lot. I was briefly playing around with it and I found > > out that 'docker compose' gives the result > > > > docker: 'compose' is not a docker command > > See 'docker --help' > > > > But the 'docker --version' command gives me the correct version of 24.0.5, > > build: ced099660009713e0e845eeb754e6050dbaa45d0 > > > > In this version compose should be already a docker command afaik. > > > > Not sure if I did something wrong here, or this is a bug. > > It's the case if you also install the new docker-compose plugin which gives > you the docker compose command with docker 24.0.5 *and* docker-compose-2 > > Tested here with success. > > For dave, moving from docker-compoe-1 to docker-compose-2 changes the way > people have to invoke the composer: > > Before it was a python script called docker-compose. Now it's a docker go > plugin installed and dynamically loaded by the docker compose command. > > Hoe that is clarifying stuff. maybe I'm wrong but to be able to use teh new "docker compose" I had to download Docker Compose v2 from https://github.com/docker/compose/tree/main#linux and as suggest into the installation steps Rename the binary docker-compose-linux-x86_64 to docker-compose and copy it to $HOME/.docker/cli-plugins and make it executable
CC: (none) => saveurlinux
Are the updates for mga8 OK, to push now before EOL?
...and of course we need to pus at least same version level on mga9...
For mga8, indeed it should be ok as validated by Len. For mga9 I've pushed a new tagged version which should fix the launch option issue. If that could be tested that would be great. For dockcer-compose, we need the build nodes to be udpated to mga9, or I need to push golang 1.21 to mga8 so they benefit from it and can build the new compose correctly.
Mageia9, x86_64 Looked for the latest version of docker in testing and updated using this list: docker-24.0.5-4.mga9.x86_64.rpm docker-devel-24.0.5-4.mga9.x86_64.rpm docker-fish-completion-24.0.5-4.mga9.x86_64.rpm docker-logrotate-24.0.5-4.mga9.x86_64.rpm docker-nano-24.0.5-4.mga9.x86_64.rpm docker-zsh-completion-24.0.5-4.mga9.x86_64.rpm docker-containerd-1.7.3-1.mga9.x86_64.rpm already in place. Restarted docker service. # systemctl status docker ● docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled; preset: > Active: active (running) since Sun 2023-11-26 15:47:02 GMT; 12s ago Docs: http://docs.docker.com Process: 1246703 ExecStartPre=/usr/sbin/docker-network-cleanup (code=exited> Main PID: 1246706 (dockerd) Passed installation check alright: $ docker run hello-world .................. Hello from Docker! This message shows that your installation appears to be working correctly. $ docker run -it ubuntu bash Unable to find image 'ubuntu:latest' locally latest: Pulling from library/ubuntu aece8493d397: Pull complete Digest: sha256:2b7412e6465c3c7fc5bb21d3e6f1917c167358449fecac8176c6e496e5c1f05f Status: Downloaded newer image for ubuntu:latest root@a28c8e50ef7e:/# ls bin dev home lib32 libx32 mnt proc run srv tmp var boot etc lib lib64 media opt root sbin sys usr root@a28c8e50ef7e:/# exit exit $ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a28c8e50ef7e ubuntu "bash" 6 minutes ago Exited (0) 6 minutes ago kind_lewin 73cdcd590e7f hello-world "/hello" 10 minutes ago Exited (0) 10 minutes ago magical_kapitsa cf10e0b67f62 fedora:latest "bash" 2 weeks ago Exited (0) 2 weeks ago silly_wilson $ docker run -it fedora:latest bash [root@6de5cb1f43a7 /]# dnf install ruby ...... Complete! [root@6de5cb1f43a7 /]# dnf install ruby-devel .... [root@6de5cb1f43a7 /]# dnf install ruby-irb .... [root@6de5cb1f43a7 /]# irb irb(main):001:0> a = (1..21).to_a => [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21] irb(main):002:0> b = a.inject(&:+) => 231 irb(main):003:0> exit [root@6de5cb1f43a7 /]# exit exit $ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 4e93a977713e debian "bash" 3 minutes ago Exited (127) 7 seconds ago hardcore_fermat 6de5cb1f43a7 fedora:latest "bash" 2 hours ago Exited (0) 4 minutes ago elegant_dirac a28c8e50ef7e ubuntu "bash" 2 hours ago Exited (0) 2 hours ago kind_lewin 73cdcd590e7f hello-world "/hello" 2 hours ago Exited (0) 2 hours ago magical_kapitsa cf10e0b67f62 fedora:latest "bash" 2 weeks ago Exited (0) 2 weeks ago silly_wilson $ docker remove 4e93a977713e 4e93a977713e $ docker remove 6de5cb1f43a7 cf10e0b67f62 6de5cb1f43a7 cf10e0b67f62 $ Good enough.
Whiteboard: MGA8TOO MGA8-64-OK => MGA8TOO MGA8-64-OK MGA9-64-OK
Removing the feedback flag, and validating. @Bruno: Could you help Marja out with advisories?
Keywords: feedback => validated_updateCC: (none) => sysadmin-bugs
(In reply to Thomas Andrews from comment #35) > Removing the feedback flag, and validating. > > @Bruno: Could you help Marja out with advisories? Thanks for asking that, TJ, my brain is struggling to process all information in this bug report. Is this correct: Only one SRPM, docker-24.0.5-4.mga9 Description: This update fixes several security issues and also solves some other issues: - manage change of launch option earlier in post process - Automatically convert -g option to --data-root in installed /etc/sysconfig/docker-storage - Fix CVE-2023-26054 and CVE-2023-2884[0-2] in mga#31733 About the references, in the comments above, I found those: https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw https://github.com/moby/buildkit/security/advisories/GHSA-gc89-7gcr-jxqc https://github.com/moby/moby/releases/tag/v23.0.2 https://github.com/moby/moby/releases/tag/v23.0.3 https://github.com/moby/moby/releases/tag/v24.0.2 https://brunocornec.wordpress.com/2023/08/17/docker-stack-updates-for-mageia-9/ Should the github links for all releases after docker-20.10.22 up to and including docker-24.0.5 be added? Or can the github links above be replaced with just: https://github.com/moby/moby/releases
CVE: (none) => CVE-2023-26054, CVE-2023-28840, CVE-2023-28841, CVE-2023-28842CC: (none) => marja11
This is the advisory I thought was best (not showing all intermediate releases, only the one with those 3 security fixes and all the 24.0.* ones) I don't understand in which docker release CVE-2023-26054 was fixed. and I don't understand the link between https://github.com/moby/buildkit/security/advisories/GHSA-gc89-7gcr-jxqc and docker. Suggested advisory: type: security subject: Updated docker packages fix security vulnerabilities and bugs CVE: - CVE-2023-26054 - CVE-2023-28840 - CVE-2023-28841 - CVE-2023-28842 src: 9: core: - docker-24.0.5-4.mga9 description: | This update fixes several security issues and also solves some other issues: - manage change of launch option earlier in post process - Automatically convert -g option to --data-root in installed /etc/sysconfig/docker-storage - Fix CVE-2023-26054 and CVE-2023-2884[0-2] references: - https://bugs.mageia.org/show_bug.cgi?id=32733 - https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw - https://github.com/moby/buildkit/security/advisories/GHSA-gc89-7gcr-jxqc - https://github.com/moby/moby/releases/tag/v24.0.5 - https://github.com/moby/moby/releases/tag/v24.0.4 - https://github.com/moby/moby/releases/tag/v24.0.3 - https://github.com/moby/moby/releases/tag/v24.0.2 - https://github.com/moby/moby/releases/tag/v24.0.1 - https://github.com/moby/moby/releases/tag/v24.0.0 - https://github.com/moby/moby/releases/tag/v23.0.3 Bruno, is the above correct?
It is only now that I see that this report is also about Mageia 8, and that it is about more SRPMs than docker alone: (In reply to Bruno Cornec from comment #7) > A new full docker stack is on its way to cauldron updates_testing. Would be > great to have it tested so we can provide these updates very early in mga9 > live. > > You'll have to install: > docker-24.0.5-2.mga8.x86_64.rpm > docker-containerd-1.7.3-1.mga8.x86_64.rpm > opencontainers-runc-1.1.9-1.mga8.x86_64.rpm > docker-logrotate-24.0.5-2.mga8.x86_64.rpm > golang-github-mrunalp-fileutils-0.5.0-3.mga8.x86_64.rpm > > to test it. > Much more details available at: > https://brunocornec.wordpress.com/2023/08/17/docker-stack-updates-for-mageia- > 9/ I assumed docker in Mageia 8 wasn't updated, that's why I didn't add it to the advisory. The last Mageia 8 docker changelog mail that I received isn't about docker-24.0.5-2.mga8 but about docker-20.10.22-1.mga8, which was pushed to updates on January 24. and : $ mgarepo rpmlog 8/docker | head * Fri Dec 30 2022 bcornec <bcornec> 20.10.22-1.mga10 + Revision: 1927972 - Fix CVE-2022-3920, CVE-2022-29153 and CVE-2022-36109 by updating to upstream docker 20.10.22 - mga#30834d - Fix a starting error for docker due to URL change with new containerd (I don't know why the first line says mga10, but it is mga8)
(In reply to Marja Van Waes from comment #37) > Suggested advisory: [...] > Bruno, is the above correct? Looks very fine to me !
(In reply to Marja Van Waes from comment #38) > The last Mageia 8 docker changelog mail that I received isn't about > docker-24.0.5-2.mga8 but about docker-20.10.22-1.mga8, which was pushed to > updates on January 24. > > and : > > $ mgarepo rpmlog 8/docker | head > * Fri Dec 30 2022 bcornec <bcornec> 20.10.22-1.mga10 > + Revision: 1927972 > - Fix CVE-2022-3920, CVE-2022-29153 and CVE-2022-36109 by updating to > upstream docker 20.10.22 - mga#30834d > - Fix a starting error for docker due to URL change with new containerd > > (I don't know why the first line says mga10, but it is mga8) Doing svn log -v in the extraced docker mga8 dir gives: r1927972 | bcornec | 2022-12-30 02:14:38 +0100 (ven. 30 déc. 2022) | 1 ligne Chemins modifiés : M /updates/8/docker/current/SOURCES/sha1.lst M /updates/8/docker/current/SPECS/docker.spec Fix CVE-2022-3920, CVE-2022-29153 and CVE-2022-36109 by updating to upstream docker 20.10.22 - mga#30834d No mga10 on this side, don't know why it's mention through mgarepo. Rest is fine.
(In reply to Bruno Cornec from comment #39) > (In reply to Marja Van Waes from comment #37) > > Suggested advisory: > [...] > > Bruno, is the above correct? > > Looks very fine to me ! Thanks :-) And I'll add docker-containerd-1.7.3-1.mga9 to the SRPMs, because it is still in updates_testing and Len tested that one, too.
Whiteboard: MGA8TOO MGA8-64-OK MGA9-64-OK => MGA9-64-OK
Keywords: (none) => advisory
(In reply to Marja Van Waes from comment #41) > (In reply to Bruno Cornec from comment #39) > > (In reply to Marja Van Waes from comment #37) > > > Suggested advisory: > > [...] > > > Bruno, is the above correct? > > > > Looks very fine to me ! > > Thanks :-) > > And I'll add docker-containerd-1.7.3-1.mga9 to the SRPMs, because it is > still in updates_testing and Len tested that one, too. But neoclust must just have run his move-updates-script, because a kernel update was pushed to updates an hour ago. But this update wasn't moved and I do not see what is wrong with either the advisory https://svnweb.mageia.org/advisories/31733.adv?revision=15303&view=markup or with this report. @ Dave Hodgins Sorry to ask you for help again. I do probably see what I expect to see instead of what is really there.
I think it was the extra trailing line, which I've removed. If that's not it, then it's the issues: line where the trailing colon will have to be removed. The script doesn't like trailing lines, or trailing spaces on any line. I'm not sure if the trailing colon is an issue or not. I always removed them, just in case.
(In reply to Dave Hodgins from comment #43) > I think it was the extra trailing line, which I've removed. Thanks, Dave :-) > > If that's not it, then it's the issues: line where the trailing colon will > have to be removed. The script doesn't like trailing lines, or trailing > spaces on any line. I'm not sure if the trailing colon is an issue or not. > I always removed them, just in case. I just removed it to be sure. This is a security update and I don't want to cause it lingering in updates_tesing any longer.
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2023-0329.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED