Lector de Feeds

hs-esslingen.de

← Older revision Revision as of 00:33, 27 June 2025 Line 27: Line 27:  | [http://ftp.nluug.nl/pub/os/Linux/distr/mageia/ https://ftp.nluug.nl/]|| NLUUG || Groningen || ftp-admin || ftp-admin [AT] nluug [DOT] nl ||   | [http://ftp.nluug.nl/pub/os/Linux/distr/mageia/ https://ftp.nluug.nl/]|| NLUUG || Groningen || ftp-admin || ftp-admin [AT] nluug [DOT] nl ||    |- |- −| [https://mirror.math.princeton.edu/pub/mageia/ https://mirror.math.princeton.edu/]|| Princeton || Princeton || Benjamin Rose || benrose [AT] math [DOT] princeton [DOT] edu || 1st tier mirror+| [https://mirror.math.princeton.edu/pub/mageia/ https://mirror.math.princeton.edu/]|| Princeton || Princeton || Benjamin Rose || benrose [AT] math [DOT] princeton [DOT] edu || 1st tier mirror    |- |-  | [https://ftp.snt.utwente.nl/pub/os/linux/mageia/ https://ftp.snt.utwente.nl/] || Twente ||  Twente ||ftpcom || ftpcom [AT] snt [DOT] utwente [DOT] nl || | [https://ftp.snt.utwente.nl/pub/os/linux/mageia/ https://ftp.snt.utwente.nl/] || Twente ||  Twente ||ftpcom || ftpcom [AT] snt [DOT] utwente [DOT] nl ||  +|-  +| [https://ftp-stud.hs-esslingen.de/pub/Mirrors/Mageia/ https://ftp-stud.hs-esslingen.de/] || Esslingen || Esslingen a.N. ||  ||  || [https://ftp-stud.hs-esslingen.de/info/status.php4?details=77 sync log]  |} |} Danf

Kernels, binrepo/, log/

← Older revision Revision as of 20:39, 26 June 2025 Line 4: Line 4:  These collect chroots under /home/iurt/chroot_tmp/iurt/. The longest possible build as of this writing will take 2 days, so running '''find /home/iurt/chroot_tmp/iurt/ -xdev -maxdepth 1 -type d -mtime +7''' will show some candidate directories to delete. Make sure to unmount anything mounted in those chroots first, like procfs (check '''mount'''). While you're cleaning up, unmount any stale nfs mounts for these chroots from /run/netns/chroot_cauldron.*. These collect chroots under /home/iurt/chroot_tmp/iurt/. The longest possible build as of this writing will take 2 days, so running '''find /home/iurt/chroot_tmp/iurt/ -xdev -maxdepth 1 -type d -mtime +7''' will show some candidate directories to delete. Make sure to unmount anything mounted in those chroots first, like procfs (check '''mount'''). While you're cleaning up, unmount any stale nfs mounts for these chroots from /run/netns/chroot_cauldron.*.    −== binrepo ==+== binrepo/ ==  This holds all the source archives for packages alongside the spec files (which are in svn). Deleting files from here means that it becomes impossible to submit a package to the build system that requires that binary archive to build. We need to be able to rebuild from source for currently-supported releases to apply security patches. There are also legal requirements to retain source code for a period under some Open Source licenses (e.g. GPL). Don't just delete files wantonly. This holds all the source archives for packages alongside the spec files (which are in svn). Deleting files from here means that it becomes impossible to submit a package to the build system that requires that binary archive to build. We need to be able to rebuild from source for currently-supported releases to apply security patches. There are also legal requirements to retain source code for a period under some Open Source licenses (e.g. GPL). Don't just delete files wantonly.     Source RPMs also contain the binrepo files, so if a file is removed from binrepo it can be recovered from the associated .src.rpm (assuming we have it around in a long-term archive). So, if a file was in a src.rpm for an obsolete mga release, if we can recover it if needed, and if it is no longer used in cauldron or any current mga release, then it should be fine to remove it. Source RPMs also contain the binrepo files, so if a file is removed from binrepo it can be recovered from the associated .src.rpm (assuming we have it around in a long-term archive). So, if a file was in a src.rpm for an obsolete mga release, if we can recover it if needed, and if it is no longer used in cauldron or any current mga release, then it should be fine to remove it.    −== distrib ==+Individual file removal is easiest performed with the '''mgarepo del <path>''' command, which doesn't have to be done on the binrepo server.  +   +== distrib/ ==  This holds all RPMs and metadata for all supported releases. When this fills, nobody can build any more packages. One strategy to free space is to hard link identical RPMs between bootstrap and mirror for cauldron. Another is to remove obsolete and unsupported releases, although you must first ensure the files are available elsewhere in case we need to fulfill any obligations under the GPL (and other licenses) to provide source code (this responsibility may not actually apply, but you need to be sure about that before deleting). This holds all RPMs and metadata for all supported releases. When this fills, nobody can build any more packages. One strategy to free space is to hard link identical RPMs between bootstrap and mirror for cauldron. Another is to remove obsolete and unsupported releases, although you must first ensure the files are available elsewhere in case we need to fulfill any obligations under the GPL (and other licenses) to provide source code (this responsibility may not actually apply, but you need to be sure about that before deleting).    −== log ==+== log/ ==  If the log partition (/var/log/) is filling up, there are a few things that can be done to make space. Running '''journalctl --vacuum-size=500M''' (with an appropriate size) will make some room immediately by deleting enough older logs so the remainder fit in the given space. Permanently reducing journal log sizes can be done by changing /etc/systemd/journald.conf for the host in puppet. If the log partition (/var/log/) is filling up, there are a few things that can be done to make space. Running '''journalctl --vacuum-size=500M''' (with an appropriate size) will make some room immediately by deleting enough older logs so the remainder fit in the given space. Permanently reducing journal log sizes can be done by changing /etc/systemd/journald.conf for the host in puppet.    −If other logs which are rotated by logrotate are getting too large, the logrorate settings may need to be tweaked. Logs are normally rotated monthly, so changing that to weekly will compress the log files much more often leaving more free space. This can be done by changing the logrotate settings for a service in puppet, possibly using a <% if @hostname == 'HOST' %> conditional. When changing the log rotation period, make sure to also change the number of logs to keep around (the ''rotate'' value); e.g. if changing from monthly to weekly, the maximum number will need to be increased by a factor of 4 to keep around the same log history available.+If other logs which are rotated by logrotate are getting too large, the logrorate settings may need to be tweaked. Logs are normally rotated monthly, so changing that to weekly will compress the log files much more often leaving more free space. This can be done by changing the logrotate settings for a service in puppet, possibly using a'' <% if @hostname == 'HOST' %>'' conditional (see [https://gitweb.mageia.org/infrastructure/puppet/commit/?id=a39a332671b7cb8e99c3ecf8954aeb20223eff14 this commmit] for an example). When changing the log rotation period, make sure to also change the number of logs to keep (the ''rotate'' value); e.g. if changing from monthly to weekly, the maximum number will need to be increased by a factor of 4 to keep around the same log history available.  +   +== Kernels ==  +Servers can often accumulate large, obsolete kernel packages over time that aren't automatically removed when new kernels are installed. Run '''rpm -qf /boot/vmlinuz*''' to see how many such packages there are. Run the '''remove-old-kernels'' program to remove unused kernel packages to free space.     == Expanding partitions == == Expanding partitions == Danf

Publication date: 25 Jun 2025
Type: security
Affected Mageia releases : 9
CVE: CVE-2025-6191 , CVE-2025-6192 Description Integer overflow in V8. (CVE-2025-6191) Use after free in Profiler. (CVE-2025-6192) References

• https://bugs.mageia.org/show_bug.cgi?id=34386
• https://chromereleases.googleblog.com/2025/06/stable-channel-update-for-desktop_17.html
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-6191
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-6192

SRPMS 9/tainted

• chromium-browser-stable-136.0.7103.113-3.mga9.tainted