Bug#1058720: slurm-wlm: CVE-2023-49933 CVE-2023-49935 CVE-2023-49936 CVE-2023-49937 CVE-2023-49938
Ciao Salvatore,
On Sun, Jan 28, 2024 at 11:37:34AM +0100, Salvatore Bonaccorso wrote:
> Reviewing your uploaded changes, the changelog mentions
> CVE-2023-49935, but believe his was not affecting 22.05.8. Let's
> still release with that in the changelog, the security-tracker should
> be already correct on that.
Sorry about that, I also forgot to build and upload the contrib package
(check #1062264) I have uploaded at the same url and attached the debdiff.
https://people.debian.org/~oliva/slurm-wlm-22.05.8-4+deb12u2
> Do you have any progress for unstable/trixie so we do not have a
> regression once after the DSA is released?
I'm working on it this week end. It is a major release upgrade. I hope
to release it at the beginning of next week.
Best regards,
--
Gennaro Oliva
diff -Nru slurm-wlm-contrib-22.05.8/debian/changelog
slurm-wlm-contrib-22.05.8/debian/changelog
--- slurm-wlm-contrib-22.05.8/debian/changelog 2023-10-14 02:11:20.0
+0200
+++ slurm-wlm-contrib-22.05.8/debian/changelog 2024-02-03 10:52:11.0
+0100
@@ -1,3 +1,10 @@
+slurm-wlm-contrib (22.05.8-4+deb12u2) bookworm-security; urgency=medium
+
+ * Fix CVE-2023-49933, CVE-2023-49935, CVE-2023-49936, CVE-2023-49937,
+CVE-2023-49938 (Closes: #1062264)
+
+ -- Gennaro Oliva Sat, 03 Feb 2024 10:52:11 +0100
+
slurm-wlm-contrib (22.05.8-4+deb12u1) bookworm-security; urgency=medium
* Fix CVE-2023-41914
diff -Nru
slurm-wlm-contrib-22.05.8/debian/patches/CVE-2023-49933-49935-49936-49937-49938
slurm-wlm-contrib-22.05.8/debian/patches/CVE-2023-49933-49935-49936-49937-49938
---
slurm-wlm-contrib-22.05.8/debian/patches/CVE-2023-49933-49935-49936-49937-49938
1970-01-01 01:00:00.0 +0100
+++
slurm-wlm-contrib-22.05.8/debian/patches/CVE-2023-49933-49935-49936-49937-49938
2024-02-03 10:50:40.0 +0100
@@ -0,0 +1,717 @@
+Description: Fix CVE-2023-49933/49935/49936/49937/49938
+ Fix improper enforcement of message integrity during transmission in a
+ communication channel that allows attackers to modify RPC traffic in a way
that
+ bypasses message hash checks. Fix a NULL pointer dereference that leads to
denial of
+ service. Fix a double free that allows attackers to cause a denial of service
or
+ possibly execute arbitrary code. Fix incorrect access control that can enable
+ an attacker to modify their extended group list that is used with the sbcast
+ subsystem, and open files with an unauthorized set of extended groups.
+Author: Tim Wickberg
+Last-Update: 2023-12-25
+
+diff --git a/src/common/pack.c b/src/common/pack.c
+index b7e048b02d..75238188a9 100644
+--- a/src/common/pack.c
b/src/common/pack.c
+@@ -521,17 +521,16 @@ void pack16_array(uint16_t *valp, uint32_t size_val,
buf_t *buffer)
+ */
+ int unpack16_array(uint16_t **valp, uint32_t *size_val, buf_t *buffer)
+ {
+- uint32_t i = 0;
+-
+- if (unpack32(size_val, buffer))
+- return SLURM_ERROR;
+-
+- *valp = xmalloc_nz((*size_val) * sizeof(uint16_t));
+- for (i = 0; i < *size_val; i++) {
+- if (unpack16((*valp) + i, buffer))
+- return SLURM_ERROR;
+- }
++ *valp = NULL;
++ safe_unpack32(size_val, buffer);
++ safe_xcalloc(*valp, *size_val, sizeof(uint16_t));
++ for (uint32_t i = 0; i < *size_val; i++)
++ safe_unpack16(&(*valp)[i], buffer);
+ return SLURM_SUCCESS;
++
++unpack_error:
++ xfree(*valp);
++ return SLURM_ERROR;
+ }
+
+ /*
+@@ -555,17 +554,16 @@ void pack32_array(uint32_t *valp, uint32_t size_val,
buf_t *buffer)
+ */
+ int unpack32_array(uint32_t **valp, uint32_t *size_val, buf_t *buffer)
+ {
+- uint32_t i = 0;
+-
+- if (unpack32(size_val, buffer))
+- return SLURM_ERROR;
+-
+- *valp = xmalloc_nz((*size_val) * sizeof(uint32_t));
+- for (i = 0; i < *size_val; i++) {
+- if (unpack32((*valp) + i, buffer))
+- return SLURM_ERROR;
+- }
++ *valp = NULL;
++ safe_unpack32(size_val, buffer);
++ safe_xcalloc(*valp, *size_val, sizeof(uint32_t));
++ for (uint32_t i = 0; i < *size_val; i++)
++ safe_unpack32(&(*valp)[i], buffer);
+ return SLURM_SUCCESS;
++
++unpack_error:
++ xfree(*valp);
++ return SLURM_ERROR;
+ }
+
+ /*
+@@ -588,17 +586,16 @@ void pack64_array(uint64_t *valp, uint32_t size_val,
buf_t *buffer)
+ */
+ int unpack64_array(uint64_t **valp, uint32_t *size_val, buf_t *buffer)
+ {
+- uint32_t i = 0;
+-
+- if (unpack32(size_val, buffer))
+- return SLURM_ERROR;
+-
+- *valp = xmalloc_nz((*size_val) * sizeof(uint64_t));
+- for (i = 0; i < *size_val; i++) {
+- if (unpack64((*valp) + i, buffer))
+- return SLURM_ERROR;
+- }
++ *valp = NULL;
++ safe_unpack32(size_val, buffer);
++ safe_xcalloc(*valp, *size_val, sizeof(uint64_t));
++ for (uint32_t i = 0; i < *
Bug#1058720: slurm-wlm: CVE-2023-49933 CVE-2023-49935 CVE-2023-49936 CVE-2023-49937 CVE-2023-49938
Dear Salvatore, I prepared an updated version of the slurm-wlm package for bookworm in response to CVE-2023-49933/49935/49936/49937/49938 The package can be found here: https://people.debian.org/~oliva/slurm-wlm-22.05.8-4+deb12u2 debdiff attached. A new package for sid in under preparation. Please let me know if I can be of any further help. I take this opportunity to wish you and to all the security team members a successful and prosperous new year. Best regards, -- Gennaro Oliva On Fri, Dec 15, 2023 at 06:21:05AM +0100, Salvatore Bonaccorso wrote: > Source: slurm-wlm > Version: 23.02.6-1 > Severity: grave > Tags: security upstream > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > > Hi Gennaro, > > The following vulnerabilities were published for slurm-wlm. > > CVE-2023-49933[0]: > | An issue was discovered in SchedMD Slurm 22.05.x, 23.02.x, and > | 23.11.x. There is Improper Enforcement of Message Integrity During > | Transmission in a Communication Channel. This allows attackers to > | modify RPC traffic in a way that bypasses message hash checks. The > | fixed versions are 22.05.11, 23.02.7, and 23.11.1. > > > CVE-2023-49935[1]: > | An issue was discovered in SchedMD Slurm 23.02.x and 23.11.x. There > | is Incorrect Access Control because of a slurmd Message Integrity > | Bypass. An attacker can reuse root-level authentication tokens > | during interaction with the slurmd process. This bypasses the RPC > | message hashes that protect against undesired MUNGE credential > | reuse. The fixed versions are 23.02.7 and 23.11.1. > > > CVE-2023-49936[2]: > | An issue was discovered in SchedMD Slurm 22.05.x, 23.02.x, and > | 23.11.x. A NULL pointer dereference leads to denial of service. The > | fixed versions are 22.05.11, 23.02.7, and 23.11.1. > > > CVE-2023-49937[3]: > | An issue was discovered in SchedMD Slurm 22.05.x, 23.02.x, and > | 23.11.x. Because of a double free, attackers can cause a denial of > | service or possibly execute arbitrary code. The fixed versions are > | 22.05.11, 23.02.7, and 23.11.1. > > > CVE-2023-49938[4]: > | An issue was discovered in SchedMD Slurm 22.05.x and 23.02.x. There > | is Incorrect Access Control: an attacker can modified their extended > | group list that is used with the sbcast subsystem, and open files > | with an unauthorized set of extended groups. The fixed versions are > | 22.05.11 and 23.02.7. > > > If you fix the vulnerabilities please also make sure to include the > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2023-49933 > https://www.cve.org/CVERecord?id=CVE-2023-49933 > [1] https://security-tracker.debian.org/tracker/CVE-2023-49935 > https://www.cve.org/CVERecord?id=CVE-2023-49935 > [2] https://security-tracker.debian.org/tracker/CVE-2023-49936 > https://www.cve.org/CVERecord?id=CVE-2023-49936 > [3] https://security-tracker.debian.org/tracker/CVE-2023-49937 > https://www.cve.org/CVERecord?id=CVE-2023-49937 > [4] https://security-tracker.debian.org/tracker/CVE-2023-49938 > https://www.cve.org/CVERecord?id=CVE-2023-49938 > > Regards, > Salvatore > -- Gennaro Oliva diffstat for slurm-wlm-22.05.8 slurm-wlm-22.05.8 changelog|7 patches/CVE-2023-49933-49936-49937-49938 | 717 +++ patches/series |1 3 files changed, 725 insertions(+) diff -Nru slurm-wlm-22.05.8/debian/changelog slurm-wlm-22.05.8/debian/changelog --- slurm-wlm-22.05.8/debian/changelog 2023-10-12 20:09:40.0 +0200 +++ slurm-wlm-22.05.8/debian/changelog 2023-12-25 09:26:16.0 +0100 @@ -1,3 +1,10 @@ +slurm-wlm (22.05.8-4+deb12u2) bookworm-security; urgency=medium + + * Fix CVE-2023-49933, CVE-2023-49935, CVE-2023-49936, CVE-2023-49937, +CVE-2023-49938 (Closes: #1058720) + + -- Gennaro Oliva Mon, 25 Dec 2023 09:26:16 +0100 + slurm-wlm (22.05.8-4+deb12u1) bookworm-security; urgency=medium * Fix CVE-2023-41914 diff -Nru slurm-wlm-22.05.8/debian/patches/CVE-2023-49933-49936-49937-49938 slurm-wlm-22.05.8/debian/patches/CVE-2023-49933-49936-49937-49938 --- slurm-wlm-22.05.8/debian/patches/CVE-2023-49933-49936-49937-49938 1970-01-01 01:00:00.0 +0100 +++ slurm-wlm-22.05.8/debian/patches/CVE-2023-49933-49936-49937-49938 2023-12-25 09:26:16.0 +0100 @@ -0,0 +1,717 @@ +Description: Fix CVE-2023-49933/49935/49936/49937/49938 + Fix improper enforcement of message integrity during transmission in a + communication channel that allows attackers to modify RPC traffic in a way that + bypasses message hash checks. Fix a NULL pointer dereference that leads to denial of + service. Fix a d
Bug#1036718: unblock: slurm-wlm-contrib/22.05.8-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: oliv...@na.icar.cnr.it Please unblock package slurm-wlm-contrib This release provide the same version level of the free package slurm-wlm [ Reason ] This package has no change, this transition is only needed to align its version to the main version of the package in in the free section. [ Impact ] There is no impact [ Tests ] The usual test I do before releasing were successfully conducted. [ Risks ] I see no risk in upgrading this package. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock slurm-wlm-contrib/22.05.8-4 -- Gennaro Oliva
Bug#1036717: unblock: slurm-wlm/22.05.8-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: oliv...@na.icar.cnr.it
Please unblock package slurm-wlm
This release simply fix Breaks/Replaces deps and reintroduce a
configuration file removed accidentally
[ Reason ]
This release will ensure a smoother update from bullseye
[ Impact ]
No impact is expected
[ Tests ]
Although there are no changes in the packages code, but only
dependencies are better specified, I did the usual tests I make for
every release of the package.
[ Risks ]
I see no risks
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock slurm-wlm/22.05.8-4
--
Gennaro Oliva
diff -Nru slurm-wlm-22.05.8/debian/changelog slurm-wlm-22.05.8/debian/changelog
--- slurm-wlm-22.05.8/debian/changelog 2023-02-08 07:50:18.0 +0100
+++ slurm-wlm-22.05.8/debian/changelog 2023-05-10 00:14:41.0 +0200
@@ -1,3 +1,11 @@
+slurm-wlm (22.05.8-4) unstable; urgency=medium
+
+ * Fix Breaks/Replaces dependencies (Closes: #1034950,
+#1034955, #1034978, #1034987, #1034992)
+ * Restore plugstack.conf (Closes: #1035562)
+
+ -- Gennaro Oliva Wed, 10 May 2023 00:14:41 +0200
+
slurm-wlm (22.05.8-3) unstable; urgency=medium
* Source only upload for testing
diff -Nru slurm-wlm-22.05.8/debian/control slurm-wlm-22.05.8/debian/control
--- slurm-wlm-22.05.8/debian/control2023-02-08 07:49:20.0 +0100
+++ slurm-wlm-22.05.8/debian/control2023-05-09 23:27:05.0 +0200
@@ -307,6 +307,8 @@
${shlibs:Depends},
${misc:Depends},
slurm-wlm-basic-plugins (= ${binary:Version})
+Breaks: slurm-wlm-basic-plugins (<< 22.05.7-1), slurm-client (<< 22.05.7-1)
+Replaces: slurm-wlm-basic-plugins (<< 22.05.7-1), slurm-client (<< 22.05.7-1)
Description: Slurm HDF5 plugin
The Slurm Workload Manager is an open-source cluster resource management and
job scheduling system that strives to be simple, scalable, portable,
@@ -371,8 +373,8 @@
${shlibs:Depends},
${misc:Depends},
slurm-wlm-basic-plugins (= ${binary:Version})
-Breaks: slurm-wlm-basic-plugins-dev (<< 22.05.7-1)
-Replaces: slurm-wlm-basic-plugins-dev (<< 22.05.7-1)
+Breaks: slurm-wlm-basic-plugins (<< 22.05.7-1)
+Replaces: slurm-wlm-basic-plugins (<< 22.05.7-1)
Description: Slurm InfluxDB plugin
The Slurm Workload Manager is an open-source cluster resource management and
job scheduling system that strives to be simple, scalable, portable,
@@ -404,8 +406,8 @@
${shlibs:Depends},
${misc:Depends},
slurm-wlm-basic-plugins (= ${binary:Version})
-Breaks: slurm-wlm-basic-plugins-dev (<< 22.05.7-1)
-Replaces: slurm-wlm-basic-plugins-dev (<< 22.05.7-1)
+Breaks: slurm-wlm-basic-plugins (<< 22.05.7-1)
+Replaces: slurm-wlm-basic-plugins (<< 22.05.7-1)
Description: Slurm RRD plugin
The Slurm Workload Manager is an open-source cluster resource management and
job scheduling system that strives to be simple, scalable, portable,
@@ -437,8 +439,8 @@
${shlibs:Depends},
${misc:Depends},
slurm-wlm-basic-plugins (= ${binary:Version})
-Breaks: slurm-wlm-basic-plugins-dev (<< 22.05.7-1)
-Replaces: slurm-wlm-basic-plugins-dev (<< 22.05.7-1)
+Breaks: slurm-wlm-basic-plugins (<< 22.05.7-1)
+Replaces: slurm-wlm-basic-plugins (<< 22.05.7-1)
Description: Slurm Elasticsearch job-completion plugin
The Slurm Workload Manager is an open-source cluster resource management and
job scheduling system that strives to be simple, scalable, portable,
@@ -470,8 +472,8 @@
${shlibs:Depends},
${misc:Depends},
slurm-wlm-basic-plugins (= ${binary:Version})
-Breaks: slurm-wlm-basic-plugins-dev (<< 22.05.7-1)
-Replaces: slurm-wlm-basic-plugins-dev (<< 22.05.7-1)
+Breaks: slurm-wlm-basic-plugins (<< 22.05.7-1)
+Replaces: slurm-wlm-basic-plugins (<< 22.05.7-1)
Description: Slurm JWT authentication plugins
The Slurm Workload Manager is an open-source cluster resource management and
job scheduling system that strives to be simple, scalable, portable,
diff -Nru slurm-wlm-22.05.8/debian/slurm-wlm-basic-plugins.install
slurm-wlm-22.05.8/debian/slurm-wlm-basic-plugins.install
--- slurm-wlm-22.05.8/debian/slurm-wlm-basic-plugins.install1970-01-01
01:00:00.0 +0100
+++ slurm-wlm-22.05.8/debian/slurm-wlm-basic-plugins.install2023-05-09
23:27:05.0 +0200
@@ -0,0 +1 @@
+debian/plugstack.conf etc/slurm
Bug#1029360: unblock: slurm-wlm/22.05.7-1
Hi Sebastian, On Wed, Jan 25, 2023 at 10:00:23PM +0100, Sebastian Ramacher wrote: > Feasible yes, but with the caveat that mpich is a key package. So if > there are any issues with the transition, we'll ask for a revert. sure. > Gennaro, please go ahead. thanks! Best regards, -- Gennaro Oliva
Bug#984928: Acknowledgement (slurmctld: fails to start on reboot)
Hi David, sorry for getting back to you so late. Thanks to your valuable contribution I managed to find a working solution. On Fri, Aug 06, 2021 at 11:01:48AM -0300, David Bremner wrote: > I think (one) underlying problem is that the systemd unit file for > slurmctld is incorrect. The details are in [1], but it seems like > network.target is not correct (I think it very rarely is a useful > target). I added the following > > # /etc/systemd/system/slurmctld.service.d/override.conf > [Unit] > After=network-online.target munge.service > Wants=network-online.target Yes this change is now part of the service file. > I've switched to systemd-networkd on the hosts in question, so I can't > easily test how this works with ifupdown, but I notice ifupdown provides > > /lib/systemd/system/ifupdown-wait-online.service > > which (guessing based on the name) should provide similar functionality > to those documented in [1] for NetworkManager and systemd-networkd. > > [1]: https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ Unfortunately using ifupdown-wait-online didn't help if I use ifupdown and allow-hotplug interfaces, but I did not tested it thoroughly since I want a solution that works out of the box. Therefore I decided to patch the slurm code that is failing in order to retry getaddrinfo before giving up starting daemons. Best regards, -- Gennaro Oliva
Bug#991940: unblock: munge/0.5.14-6
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package munge
[ Reason ]
* Cherry-pick upstream patch to allow to upgrade from buster to bullseye
[ Impact ]
Remove some minor tests to fix kfreebsd builds and a useless check for
the daemon when starting
[ Tests ]
All tests passed
[ Risks ]
It's low risk because:
the change only avoid a useless check that the libgcrypt shared object
linked at runtime is the same the daemon was compiled against [1] and
some minor tests (removed upstream) to fix kfreebsd builds.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
diffstat for munge-0.5.14 munge-0.5.14
changelog | 14 +
patches/0005-Sharness-Remove-tests-to-from-invalid-files.patch| 93
+
patches/0006-Sharness-Set-IFNAME-prereq-if-network-ifname-found.patch | 102
++
patches/0007-Remove-GCRYPT_VERSION-from-gcry_check_version.patch | 36
+++
patches/series|3
5 files changed, 248 insertions(+)
debdiff attached
unblock munge/0.5.14-6
[1] https://github.com/dun/munge/commit/0c37cc03b649d8861c2d9e8d172bff736bfd9ea4
--
Gennaro Oliva
diff -Nru munge-0.5.14/debian/changelog munge-0.5.14/debian/changelog
--- munge-0.5.14/debian/changelog 2021-02-25 17:08:19.0 +0100
+++ munge-0.5.14/debian/changelog 2021-08-06 09:40:42.0 +0200
@@ -1,3 +1,17 @@
+munge (0.5.14-6) unstable; urgency=medium
+
+ [Chris Dunlap]
+ * Remove GCRYPT_VERSION from gcry_check_version (Closes: #991875)
+
+ -- Gennaro Oliva Fri, 06 Aug 2021 09:40:42 +0200
+
+munge (0.5.14-5) unstable; urgency=medium
+
+ [Chris Dunlap]
+ * Fix kfreebsd builds
+
+ -- Gennaro Oliva Mon, 22 Mar 2021 02:00:52 +0100
+
munge (0.5.14-4) unstable; urgency=medium
[Chris Dunlap]
diff -Nru
munge-0.5.14/debian/patches/0005-Sharness-Remove-tests-to-from-invalid-files.patch
munge-0.5.14/debian/patches/0005-Sharness-Remove-tests-to-from-invalid-files.patch
---
munge-0.5.14/debian/patches/0005-Sharness-Remove-tests-to-from-invalid-files.patch
1970-01-01 01:00:00.0 +0100
+++
munge-0.5.14/debian/patches/0005-Sharness-Remove-tests-to-from-invalid-files.patch
2021-08-05 23:56:30.0 +0200
@@ -0,0 +1,93 @@
+Description: Sharness: Remove tests to/from invalid files
+ On FreeBSD (12.1, 11.4, 11.3) and NetBSD (9.0, 8.1, 7.2), the following
+ test fails when run with "root=/tmp/munge-test-$$":
+ 0012-munge-cmdline.t 24 - munge --input from invalid file
+ This test attempts to read data for a credential payload from the file
+ "." -- i.e., a directory, and not a regular file. It is expected
+ to fail, and on most platforms it does. However, it unexpectedly
+ succeeds if the input file is on a FreeBSD ufs or NetBSD ffs filesystem
+ (where it uses the directory file contents as the payload data),
+ but fails if the input file is on an nfs or tmpfs filesystem on
+ those platforms. Note that this test fails as expected on OpenBSD
+ ffs and nfs filesystems.
+ This passed testing for 0.5.14 because the test suite ran in an
+ nfs directory. But recent testing with "root=/tmp/munge-test-$$"
+ uncovered the failure since the "root" variable moved the input file
+ to a different filesystem.
+ Since the munge and unmunge client executables do not explicitly
+ check whether the input or output files are regular files, remove the
+ sharness checks that test for an expected failure when specifying an
+ invalid input, metadata, or output file.
+Author: Chris Dunlap
+Origin: upstream,
https://github.com/dun/munge/commit/cfbb14558ceda9dd42b23a2e4c166a07b73a3223
+Last-Update: 2020-10-14
+Forwarded: not-needed
+
+--- a/t/0012-munge-cmdline.t
b/t/0012-munge-cmdline.t
+@@ -109,10 +109,6 @@ test_expect_success 'munge --input from /dev/null' '
+ test ! -s out.$$
+ '
+
+-test_expect_success 'munge --input from invalid file' '
+-test_must_fail "${MUNGE}" --socket="${MUNGE_SOCKET}" --input=.
+-'
+-
+ test_expect_success 'munge --input from missing file' '
+ test_must_fail "${MUNGE}" --socket="${MUNGE_SOCKET}" \
+ --input=missing.file.$$
+@@ -141,10 +137,6 @@ test_expect_success 'munge --output to /dev/null' '
+ test ! -s out.$$
+ '
+
+-test_expect_success 'munge --output to invalid file' '
+-test_must_fail "${MUNGE}" --socket="${MUNGE_SOCKET}" --no-input --output=.
+-'
+-
+ for OPT_LIST_CIPHERS in '-C' '--list-ciphers'; do
+ test_expect_success "munge ${OPT_LIST_CIPHERS}" '
+ "${MUNGE}" "${OPT_LIST_CIPHERS}" |
+diff --git a/t/0013-unmunge-cmdline.t b/t/0013-unmunge-cmdline.t
+index c034109..07ce8eb 100755
+---
Bug#981436: src:slurm-wlm: autopkgtest hickups
Hi Samuel, On Sun, Jan 31, 2021 at 10:51:08AM +0100, Samuel Thibault wrote: > It seems like the slurm-wlm package gets some autopkgtest hickups: > > https://ci.debian.net/packages/s/slurm-wlm/testing/ppc64el/ > > shows failures which seem unrelated to package updates, and sometimes > spuriously blocks package migrations (that used to block hwloc, but a > rebuild fixed it). autopkgtest sometimes fails upon mariadb installation: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977114 Best regards, -- Gennaro Oliva
Bug#979181: Britney should not test old autopkg when renaming source
Package: release.debian.org User: release.debian@packages.debian.org Usertags: britney Severity: normal Britney should avoid testing old autopkg when the source package is renamed and the new package takes over all binary packages. This bug is a reminder to look into this behaviour as emerged here: https://lists.debian.org/debian-release/2020/12/msg00187.html and patch Britney if it's the case or document how to handle this kind of situations. Best regards, -- Gennaro Oliva
Bug#977117: RM: slurm-llnl -- ROM; renamed to slurm-wlm
Package: ftp.debian.org Severity: normal Hi ftp-master, please remove src:slurm-llnl because the package was renamed to src:slurm-wlm. The authors of the software are no longer affiliated with the Lawrence Livermore National Laboratory (llnl) and all the binary packages were already renamed. Starting from version 20.02.6-1 the suffix is also purged from the configuration directories. Best regards, -- Gennaro Oliva
Bug#977114: mariadb-server doesn't start in the ppc64el autopkgtest environment
Package: mariadb-server-10.5 Version: 1:10.5.8-3 When I install mariadb-server and mariadb-client in the autopkgtest environment on the ppc64el architecture, the mariadb service fails to start. Please see this failed test log: https://ci.debian.net/data/autopkgtest/testing/ppc64el/s/slurm-wlm/8577097/log.gz This doesn't happen for any other architecture: https://qa.debian.org/excuses.php?package=slurm-wlm Best regards, -- Gennaro Oliva
Bug#954272: Missing mpi_pmix.so
Hi, On Fri, Nov 27, 2020 at 02:41:16PM +0100, Lars Veldscholte wrote: > After updating, the interface between SLURM and MPI broke again... > > This time, it looks like pmix support is completely missing. Yes, thanks for pointing this out. > It appears that SLURM is looking for `mpi_pmix.so`, which does not exist. > Has this been moved to a different package maybe? No, it's a wrong option passed to configure, as Alastair pointed out. It should be: --with-pmix=/usr/lib/$(DEB_HOST_MULTIARCH)/pmix2 because without this option, the configure script doesn't detect pmix and doesn't build the corresponding plugin. I'm fixing this. Thank you both for your report. Best regards, -- Gennaro Oliva
Bug#954272: slurmd: SLURM not working with OpenMPI
Hi Lars, On Thu, Mar 19, 2020 at 03:16:15PM +0100, Lars Veldscholte wrote: > A simple test like `srun hostname` works, even on multiple cores. However, > when trying to use MPI, it crashes with the following error message: > > *** An error occurred in MPI_Init > *** on a NULL communicator > *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort, > ***and potentially your MPI job) > > This happens even in the most simple "Hello World" case, as long as the > program is MPI-enabled. > > I am trying to use OpenMPI (4.0.2) from the Debian repositories. `srun --mpi > list` returns: > > srun: MPI types are... > srun: openmpi > srun: pmi2 > srun: none > > I have tried all options, but the result is the same in all cases. > > Maybe this is user error, as this is my first time setting up SLURM, but I > have not been able to find any possible causes/solutions and I am kind of > stuck at this point. I don't know why srun doesn't execute openmpi directly, and I'll try to investigate this issue but as a workaround you can use both sbatch and salloc as in [1]: salloc -n 4 mpirun mympiprogram ... or sbatch -n 4 mympiprogram.sh where mympiprogram.sh is something like: #!/bin/sh mpirun mympiprogram ... Notice you don't need to specify the number of processes to mpirun, as it takes it from SLURM. [1] https://www.open-mpi.org/faq/?category=slurm Best regards, -- Gennaro Oliva
Bug#948008: Please consider packaging PMIx plugin
Hi Paul, On Fri, Jan 03, 2020 at 10:39:04AM +0100, Paul Jähne wrote: > please consider packaging the PMIx library with SLURM similar to #840404. > See also: https://pmix.org/support/how-to/slurm-support/. this will be available in version 19.05.5-1. On Fri, Jan 03, 2020 at 09:49:48AM +, Alastair McKinstry wrote: > Just to note: pmix is already packaged in Debian, but needs to be enabled. Thanks for pointing this out Alastair. Best regards, -- Gennaro Oliva
Bug#941121: upgrade to debian 9.11 removes config entry
Hi Alois,
On Wed, Sep 25, 2019 at 09:41:40AM +0200, Alois Schlögl wrote:
> [remark: this might be a problem of systemd, I'm not sure whether this
> is an issue of slurm or of systemd.]
>
> When upgrading from debian 9.10 to 9.11 [2], a configuration entry in
> /etc/systemd/system/multi-user.target.wants/slurmd.service
> got lost.
>
> In order to address an issue ("Cannot allocate memory" when running mpi
> jobs under slurm, it is described in [1]) we had to add in
> /etc/systemd/system/multi-user.target.wants/slurmd.service
This file is a symbolic link to /lib/systemd/system/slurmd.service that
is managed by the package.
> this entry
>
> [Service]
> ...
> LimitMEMLOCK=1
According to systemd documentation you need to add this entry to:
/etc/systemd/system/slurmd.service
or inside a file under:
/etc/systemd/system/slurmd.service.d
man systemd.unit(5) for details.
Best regards,
--
Gennaro Oliva
Bug#929600: slurm-llnl: FTBFS on 32-bit architectures
Hi Andreas, I have updated the package to fix the bug number in the changelog and it's now available at the same url: https://people.debian.org/~oliva/slurm-llnl-16.05.9-1+deb9u4/ new debdiff attached, diffstat follows: changelog |6 -- patches/CVE-2019-6438 | 11 --- 2 files changed, 17 deletions(-) Regards, -- Gennaro Oliva diff -Nru slurm-llnl-16.05.9/debian/changelog slurm-llnl-16.05.9/debian/changelog --- slurm-llnl-16.05.9/debian/changelog 2019-05-27 09:48:30.0 +0200 +++ slurm-llnl-16.05.9/debian/changelog 2019-02-12 23:34:26.0 +0100 @@ -1,9 +1,3 @@ -slurm-llnl (16.05.9-1+deb9u4) stretch-security; urgency=medium - - * Fix build regression on 32-bits architecture (Closes: #929600) - - -- Gennaro Oliva Mon, 27 May 2019 09:48:30 +0200 - slurm-llnl (16.05.9-1+deb9u3) stretch-security; urgency=high * Fix CVE-2019-6438 by adding mitigation for a potential diff -Nru slurm-llnl-16.05.9/debian/patches/CVE-2019-6438 slurm-llnl-16.05.9/debian/patches/CVE-2019-6438 --- slurm-llnl-16.05.9/debian/patches/CVE-2019-6438 2019-05-27 09:07:56.0 +0200 +++ slurm-llnl-16.05.9/debian/patches/CVE-2019-6438 2019-02-12 23:32:08.0 +0100 @@ -65,14 +65,3 @@ void *slurm_try_xmalloc(size_t , const char *, int , const char *); void slurm_xfree(void **, const char *, int, const char *); void *slurm_xrealloc(void **, size_t, bool, const char *, int, const char *); slurm-llnl-16.05.9.orig/contribs/perlapi/libslurm/perl/slurm-perl.h -+++ slurm-llnl-16.05.9/contribs/perlapi/libslurm/perl/slurm-perl.h -@@ -17,7 +17,7 @@ - #endif - - extern void slurm_xfree(void **, const char *, int, const char *); --extern void *slurm_xmalloc(size_t, bool, const char *, int, const char *); -+extern void *slurm_xmalloc(uint64_t, bool, const char *, int, const char *); - - extern void slurm_api_clear_config(void); -
Bug#929600: slurm-llnl: FTBFS on 32-bit architectures
Hi Andreas, On Mon, May 27, 2019 at 03:23:45PM +0200, Andreas Beckmann wrote: > On 2019-05-27 11:23, Gennaro Oliva wrote: > > I have prepared an updated version of the package available here: > > > > https://people.debian.org/~oliva/slurm-llnl-16.05.9-1+deb9u4/ > > I can confirm that it builds locally in a pbuilder stretch/i386 > environment :-) thank you very much for testing it! It also builds locally under armel, armhf, mips and mipsel using sbuild. Best regards, -- Gennaro Oliva
Bug#929600: slurm-llnl: FTBFS on 32-bit architectures
Hi Andreas, On Sun, May 26, 2019 at 10:31:14PM +0200, Andreas Beckmann wrote: > the stretch update of slurm-llnl FTBFS on the 32-bit architectures: thank you very much for filing this bug report. I have prepared an updated version of the package available here: https://people.debian.org/~oliva/slurm-llnl-16.05.9-1+deb9u4/ debdiff attached, diffstat follows: changelog |6 -- patches/CVE-2019-6438 | 11 --- 2 files changed, 17 deletions(-) Best regards, -- Gennaro Oliva diff -Nru slurm-llnl-16.05.9/debian/changelog slurm-llnl-16.05.9/debian/changelog --- slurm-llnl-16.05.9/debian/changelog 2019-05-27 09:48:30.0 +0200 +++ slurm-llnl-16.05.9/debian/changelog 2019-02-12 23:34:26.0 +0100 @@ -1,9 +1,3 @@ -slurm-llnl (16.05.9-1+deb9u4) stretch-security; urgency=medium - - * Fix build regression on 32-bits architecture (Closes: #92960) - - -- Gennaro Oliva Mon, 27 May 2019 09:48:30 +0200 - slurm-llnl (16.05.9-1+deb9u3) stretch-security; urgency=high * Fix CVE-2019-6438 by adding mitigation for a potential diff -Nru slurm-llnl-16.05.9/debian/patches/CVE-2019-6438 slurm-llnl-16.05.9/debian/patches/CVE-2019-6438 --- slurm-llnl-16.05.9/debian/patches/CVE-2019-6438 2019-05-27 09:07:56.0 +0200 +++ slurm-llnl-16.05.9/debian/patches/CVE-2019-6438 2019-02-12 23:32:08.0 +0100 @@ -65,14 +65,3 @@ void *slurm_try_xmalloc(size_t , const char *, int , const char *); void slurm_xfree(void **, const char *, int, const char *); void *slurm_xrealloc(void **, size_t, bool, const char *, int, const char *); slurm-llnl-16.05.9.orig/contribs/perlapi/libslurm/perl/slurm-perl.h -+++ slurm-llnl-16.05.9/contribs/perlapi/libslurm/perl/slurm-perl.h -@@ -17,7 +17,7 @@ - #endif - - extern void slurm_xfree(void **, const char *, int, const char *); --extern void *slurm_xmalloc(size_t, bool, const char *, int, const char *); -+extern void *slurm_xmalloc(uint64_t, bool, const char *, int, const char *); - - extern void slurm_api_clear_config(void); -
Bug#885759: Use /var/run as a statedir, and not /var/run/slurm-llnl
Hi Met, thank you for this bug report. On Fri, Mar 01, 2019 at 12:48:20AM +0100, n...@sucha.eu wrote: > What happened is that config files (slurm.conf, slurmdbd.conf) still > contain pid paths in /run/slurm-llnl/. Note: not /var/run/slurm-llnl/ but > /run/slurm-llnl in my case. The intention was to modify the location specified in the slurm-wlm-configurator.html and not every possible location. This because for any reason you can keep your pid file elsewhere and create the service file accordingly as you did. Anyway, since /var/run is only a symbolic link to /run I modified the post installation script to handle also this option, as in your case, in the next package release. > Hint: maybe a wrong regex to match paths? Maybe only /var/run but not /run > is updated? the last hypothesis was the right one. > Since the pid is hardcoded in systemd unit configs, then imo it is better > to remove the pid file entries altogether from slurm config files. I don't think this is appropriate because, if a system administrator decide to keep the pid file in another place and create a new service file accordingly, removing the pid file entry in the configuration would make services fail to start. Best regards, -- Gennaro Oliva
Bug#922930: stretch-pu: package slurm-llnl/16.05.9-1+deb9u2
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
I'd like to update slurm-llnl in the next stable point release to
fix a security vulnerability (CVE-2019-6438) on 32-bit systems that
would potentially allow heap-overflow.
debdiff attached, diffstat follows:
changelog |7 +
patches/CVE-2019-6438 | 67 ++
patches/series|1
3 files changed, 75 insertions(+)
Thanks
--
Gennaro Oliva
diff -Nru slurm-llnl-16.05.9/debian/changelog
slurm-llnl-16.05.9/debian/changelog
--- slurm-llnl-16.05.9/debian/changelog 2018-07-23 12:00:49.0 +0200
+++ slurm-llnl-16.05.9/debian/changelog 2019-02-21 17:24:53.0 +0100
@@ -1,3 +1,10 @@
+slurm-llnl (16.05.9-1+deb9u3) stretch; urgency=medium
+
+ * Fix CVE-2019-6438 by adding mitigation for a potential
+heap-overflow on 32-bit systems (Closes: #920997)
+
+ -- Gennaro Oliva Thu, 21 Feb 2019 17:24:53 +0100
+
slurm-llnl (16.05.9-1+deb9u2) stretch-security; urgency=high
* Fix CVE-2018-10995 caused by mishandling user names (aka user_name
diff -Nru slurm-llnl-16.05.9/debian/patches/CVE-2019-6438
slurm-llnl-16.05.9/debian/patches/CVE-2019-6438
--- slurm-llnl-16.05.9/debian/patches/CVE-2019-6438 1970-01-01
01:00:00.0 +0100
+++ slurm-llnl-16.05.9/debian/patches/CVE-2019-6438 2019-02-21
17:19:14.0 +0100
@@ -0,0 +1,67 @@
+Description: Add mitigation for a potential heap-overflow on 32-bit systems
+ Force intermediate values to uint64_t to catch the potential overflow
+ This patch was adapted from the changes of the 17.11 upstream branch
+Author: Gennaro Oliva
+Bug-Debian: https://bugs.debian.org/920997
+Origin:
https://github.com/SchedMD/slurm/commit/750cc23edcc6fddfff21d33bdaf4fb7deb28cfda
+Forwarded: no
+Last-Update: 2019-02-12
+
+--- a/src/common/xmalloc.c
b/src/common/xmalloc.c
+@@ -72,13 +72,17 @@ static void malloc_assert_failed(char *,
+ * clear (IN) initialize to zero
+ * RETURN pointer to allocate heap space
+ */
+-void *slurm_xmalloc(size_t size, bool clear,
++void *slurm_xmalloc(uint64_t size, bool clear,
+ const char *file, int line, const char *func)
+ {
+ void *new;
+ size_t *p;
+ size_t total_size = size + 2 * sizeof(size_t);
+
++
++ if (size > 0x)
++ fatal("attempt at overflow");
++
+ if (clear)
+ p = calloc(1, total_size);
+ else
+--- slurm-llnl-16.05.9.orig/src/common/xmalloc.h
slurm-llnl-16.05.9/src/common/xmalloc.h
+@@ -76,6 +76,8 @@
+ #ifndef _XMALLOC_H
+ #define _XMALLOC_H
+
++#include
++
+ #if HAVE_SYS_TYPES_H
+ # include
+ #endif
+@@ -83,13 +85,13 @@
+ #include "macros.h"
+
+ #define xmalloc(__sz) \
+- slurm_xmalloc (__sz, true, __FILE__, __LINE__, __CURRENT_FUNC__)
++ slurm_xmalloc ((uint64_t) __sz, true, __FILE__, __LINE__,
__CURRENT_FUNC__)
+
+ #define xmalloc_nz(__sz) \
+- slurm_xmalloc (__sz, false, __FILE__, __LINE__, __CURRENT_FUNC__)
++ slurm_xmalloc ((uint64_t) __sz, false, __FILE__, __LINE__,
__CURRENT_FUNC__)
+
+ #define try_xmalloc(__sz) \
+- slurm_try_xmalloc(__sz, __FILE__, __LINE__, __CURRENT_FUNC__)
++ slurm_try_xmalloc((uint64_t) __sz, __FILE__, __LINE__, __CURRENT_FUNC__)
+
+ #define xfree(__p) \
+ slurm_xfree((void **)&(__p), __FILE__, __LINE__, __CURRENT_FUNC__)
+@@ -109,7 +111,7 @@
+ #define xsize(__p) \
+ slurm_xsize((void *)__p, __FILE__, __LINE__, __CURRENT_FUNC__)
+
+-void *slurm_xmalloc(size_t, bool, const char *, int, const char *);
++void *slurm_xmalloc(uint64_t, bool, const char *, int, const char *);
+ void *slurm_try_xmalloc(size_t , const char *, int , const char *);
+ void slurm_xfree(void **, const char *, int, const char *);
+ void *slurm_xrealloc(void **, size_t, bool, const char *, int, const char *);
diff -Nru slurm-llnl-16.05.9/debian/patches/series
slurm-llnl-16.05.9/debian/patches/series
--- slurm-llnl-16.05.9/debian/patches/series2018-06-22 09:53:34.0
+0200
+++ slurm-llnl-16.05.9/debian/patches/series2019-02-21 17:19:14.0
+0100
@@ -5,3 +5,4 @@
CVE-2017-15566
CVE-2018-10995
CVE-2018-7033
+CVE-2019-6438
Bug#922319: Build libpam-slurm-adopt package for Slurm
Hi Martijn, On Thu, Feb 14, 2019 at 03:25:34PM +0100, Martijn Kruiten wrote: > Slurm includes an alternative to libpam-slurm, called libpam-slurm- > adopt. According to the SchedMD documentation libpam-slurm-adopt is > "highly recommended for most installations" [1]. Thank you for pointing this out, I think you are right and that we need to add this pam module to the Debian package as soon as possible. > I created a merge > request for it [2], but it's a bit behind. I think Debian should > include this package. More information is available at SchedMD [3]. Thanks for your work, I'm sorry I didn't see the merge request. The patch looks fine although I haven't tested it yet. Unfortunately there is not enough time to include this feature in buster. I will add it right after buster is released. Best Regards, -- Gennaro Oliva
Bug#909653: New upstream 18 available
Hi Yuri, thanks for using the slurm package. On Wed, Sep 26, 2018 at 01:06:10PM +0200, Yuri D'Elia wrote: > Dear maintaner, it would be nice to have the new slurm 18 version > available in Debian. I'm working on it. Best regards, -- Gennaro Oliva
Bug#887924: slurm-drmaa FTBFS with slurm-llnl 17.11.2-1
Hi Dominique, Steve and Adrian, On Mon, Apr 16, 2018 at 04:34:54PM -0400, Dominique Belhachemi wrote: > The bug is also in Debian's slurm-llnl package. The location of the header > files is not consistent anymore. thank you for looking into this issue; the forthcoming release of slurm-llnl will fix it. Best regards -- Gennaro Oliva
Bug#882033: libpmi2-0-dev,libpmix-dev: error when trying to install together: both ship libpmi2.so
Hi Alastair, On Wed, Nov 22, 2017 at 10:20:17AM +, Alastair McKinstry wrote: > Yes, this would be my preferred solution. Shipping: > libpmi-pmix-dev > libpmi-slurm-dev > > and then providing alternatives. great! Shouldn't we provide alternatives for the library package too? They does not conflict at the moment, but they could in the future. $ apt-file list libpmi2-0 | grep libpmi2.so libpmi2-0: /usr/lib/x86_64-linux-gnu/libpmi2.so.0 libpmi2-0: /usr/lib/x86_64-linux-gnu/libpmi2.so.0.0.0 $ apt-file list libpmix2 | grep libpmi2.so libpmix2: /usr/lib/x86_64-linux-gnu/libpmi2.so.1 libpmix2: /usr/lib/x86_64-linux-gnu/libpmi2.so.1.0.0 What do you think? Regards -- Gennaro Oliva
Bug#882033: libpmi2-0-dev,libpmix-dev: error when trying to install together: both ship libpmi2.so
Hi Alastair, On Wed, Nov 22, 2017 at 08:36:00AM +, Alastair McKinstry wrote: > I was unfortunately not aware of pmi2 from slurm when packaging pmix2 > from openmpi. thanks for packaging pmix. > Possible solutions include: > (1) pmix splitting its conflictng files into another package > libpmix-pmi-dev ? (name?) > (2) Shipping only one pmi-dev package ? what about using alternatives? By doing so, every resource manager and mpi library can install it's own implementation. Best regards -- Gennaro Oliva
Bug#878477: linitian problem when using dh --with autotools-dev
Hi Niels, On Sat, Oct 14, 2017 at 06:39:00AM +, Niels Thykier wrote: > Indeed; my recommendation for you would be to remove the "--with > autotools-dev" and rely on the dh_update_autotools_config helper. This > would avoid the warning from lintian and satisfy Policy as well. thanks for your help. I saw #870829 only after filing this, that's why I mergerd the bugs. My apologies for this useless report. Best regards -- Gennaro Oliva
Bug#878477: linitian problem when using dh --with autotools-dev
Package: lintian Version: 2.5.55 Hi, I'm trying to build the new version of my package (munge) and I added "--with autotools-dev" to dh in order to comply with the paragraph 4.3 of the policy (version 4.1.1). When I check the package with lintian I get the following error: missing-build-dependency-for-dh-addon autotools_dev => autotools-dev But if I add the autotools-dev dependency to the Build-Depends I get the following warning: useless-autoreconf-build-depends autotools-dev This problem is very similar to #869541 Best regards -- Gennaro Oliva
Bug#785256: libpam-slurm: pam_slurm.so installed as libpam_slurm.so
Hi Jason,
On Fri, May 15, 2015 at 10:53:02AM -0400, Jason Riedy wrote:
> > root@pequin:~# aptitude purge libpam-slurm
> > The following packages will be REMOVED:
> > libpam-slurm{p} libslurm27{u}
> > 0 packages upgraded, 0 newly installed, 2 to remove and 7 not upgraded.
> > Need to get 0 B of archives. After unpacking 1,414 kB will be freed.
> > Do you want to continue? [Y/n/?]
> > (Reading database ... 284440 files and directories currently installed.)
> > Removing libpam-slurm (14.03.9-5) ...
> > (Reading database ... 284434 files and directories currently installed.)
> > Removing libslurm27 (14.03.9-5) ...
> > Processing triggers for libc-bin (2.19-18) ...
> >
> > root@pequin:~# ls -l /lib/x86_64-linux-gnu/security/*slurm*
> > ls: cannot access /lib/x86_64-linux-gnu/security/*slurm*: No such file or
> > directory
> > root@pequin:~# aptitude install libpam-slurm
> > The following NEW packages will be installed:
> > libpam-slurm libslurm27{a}
> > 0 packages upgraded, 2 newly installed, 0 to remove and 7 not upgraded.
> > Need to get 469 kB of archives. After unpacking 1,414 kB will be used.
> > Do you want to continue? [Y/n/?]
> > Get: 1 http://ftp.debian.org/debian/ stable/main libslurm27 amd64 14.03.9-5
> > [450 kB]
> > Get: 2 http://ftp.debian.org/debian/ stable/main libpam-slurm amd64
> > 14.03.9-5 [19.1 kB]
> > Fetched 469 kB in 0s (474 kB/s)
> > Selecting previously unselected package libslurm27.
> > (Reading database ... 284428 files and directories currently installed.)
> > Preparing to unpack .../libslurm27_14.03.9-5_amd64.deb ...
> > Unpacking libslurm27 (14.03.9-5) ...
> > Selecting previously unselected package libpam-slurm.
> > Preparing to unpack .../libpam-slurm_14.03.9-5_amd64.deb ...
> > Unpacking libpam-slurm (14.03.9-5) ...
> > Setting up libslurm27 (14.03.9-5) ...
> > Setting up libpam-slurm (14.03.9-5) ...
> > Processing triggers for libc-bin (2.19-18) ...
> >
> > root@pequin:~# ls -l /lib/x86_64-linux-gnu/security/*slurm*
> > -rw-r--r-- 1 root root 14360 Nov 12 2014
> > /lib/x86_64-linux-gnu/security/libpam_slurm.so
>
> So something in the multi-arch renaming incorrectly moves it to
> libpam_slurm.so.
did you experienced this bug in a more recent version of libpam-slurm?
I was never able to reproduce it.
Best regards
--
Gennaro Oliva
Bug#869991: jessie-pu: package slurm-llnl/14.03.9-5
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
I'd like to update slurm-llnl in the next oldstable point release to
address a vulnerability in how the slurmd daemon informs users of
a Prolog failure on a compute node. That vulnerability could allow a
user to assume control of an arbitrary file on the system. Any
exploitation of this is dependent on the user being able to cause or
anticipate the failure (non-zero return code) of a Prolog script that
their job would run on (CVE-2016-10030).
debdiff is attached. The diffstat is:
changelog |7 +
patches/CVE-2016-10030 | 198 +
patches/series |1
3 files changed, 206 insertions(+)
Thanks
--
Gennaro Oliva
diff -Nru slurm-llnl-14.03.9/debian/changelog
slurm-llnl-14.03.9/debian/changelog
--- slurm-llnl-14.03.9/debian/changelog 2014-11-12 12:07:35.0 +0100
+++ slurm-llnl-14.03.9/debian/changelog 2017-07-28 10:52:47.0 +0200
@@ -1,3 +1,10 @@
+slurm-llnl (14.03.9-5+deb8u1) jessie-security; urgency=high
+
+ * Fix security issue caused by insecure file path handling triggered by
+the failure of a Prolog script (CVE-2016-10030)
+
+ -- Gennaro Oliva <oliv...@na.icar.cnr.it> Fri, 28 Jul 2017 10:06:41 +0200
+
slurm-llnl (14.03.9-5) unstable; urgency=medium
[ Roland Fehrenbacher ]
diff -Nru slurm-llnl-14.03.9/debian/patches/CVE-2016-10030
slurm-llnl-14.03.9/debian/patches/CVE-2016-10030
--- slurm-llnl-14.03.9/debian/patches/CVE-2016-100301970-01-01
01:00:00.0 +0100
+++ slurm-llnl-14.03.9/debian/patches/CVE-2016-100302017-07-28
10:03:53.0 +0200
@@ -0,0 +1,198 @@
+Description: FIX CVE-2016-10030
+ Fix security issue caused by insecure file path handling triggered by
+ the failure of a Prolog script. To exploit this a user needs to
+ anticipate or cause the Prolog to fail for their job.
+Author: Tim Wickberg <t...@schedmd.com>
+
+---
+Origin:
https://github.com/SchedMD/slurm/commit/465c98ccff9f1e0018e6a0e6e86ee485ae480ae6
+Bug:
+Bug-Debian: https://bugs.debian.org/850491
+Last-Update: 28-07-2017
+
+--- slurm-llnl-14.03.9.orig/src/slurmd/slurmd/req.c
slurm-llnl-14.03.9/src/slurmd/slurmd/req.c
+@@ -155,6 +155,7 @@ static int _kill_all_active_steps(uint3
+ static void _note_batch_job_finished(uint32_t job_id);
+ static int _step_limits_match(void *x, void *key);
+ static int _terminate_all_steps(uint32_t jobid, bool batch);
++static int _receive_fd(int socket);
+ static void _rpc_launch_tasks(slurm_msg_t *);
+ static void _rpc_abort_job(slurm_msg_t *);
+ static void _rpc_batch_job(slurm_msg_t *msg, bool new_msg);
+@@ -214,6 +215,7 @@ static void _add_job_running_prolog(uint
+ static void _remove_job_running_prolog(uint32_t job_id);
+ static int _compare_job_running_prolog(void *s0, void *s1);
+ static void _wait_for_job_running_prolog(uint32_t job_id);
++static int _open_as_other(char *path_name, batch_job_launch_msg_t *req);
+
+ /*
+ * List of threads waiting for jobs to complete
+@@ -1275,9 +1277,8 @@ _prolog_error(batch_job_launch_msg_t *re
+ else
+ snprintf(path_name, MAXPATHLEN, "/%s", err_name_ptr);
+
+- if ((fd = open(path_name, (O_CREAT|O_APPEND|O_WRONLY), 0644)) == -1) {
+- error("Unable to open %s: %s", path_name,
+-slurm_strerror(errno));
++ if ((fd = _open_as_other(path_name, req)) == -1) {
++ error("Unable to open %s: Permission denied", path_name);
+ return;
+ }
+ snprintf(err_name, sizeof(err_name),
+@@ -5306,4 +5307,155 @@ done:
+ slurm_send_rc_msg(msg, rc);
+ }
+
++/* pass an open file descriptor back to the parent process */
++static void _send_back_fd(int socket, int fd)
++{
++ struct msghdr msg = { 0 };
++ struct cmsghdr *cmsg;
++ char buf[CMSG_SPACE(sizeof(fd))];
++ memset(buf, '\0', sizeof(buf));
++
++ msg.msg_iov = NULL;
++ msg.msg_iovlen = 0;
++ msg.msg_control = buf;
++ msg.msg_controllen = sizeof(buf);
++
++ cmsg = CMSG_FIRSTHDR();
++ cmsg->cmsg_level = SOL_SOCKET;
++ cmsg->cmsg_type = SCM_RIGHTS;
++ cmsg->cmsg_len = CMSG_LEN(sizeof(fd));
++
++ memmove(CMSG_DATA(cmsg), , sizeof(fd));
++ msg.msg_controllen = cmsg->cmsg_len;
++
++ if (sendmsg(socket, , 0) < 0)
++ error("%s: failed to send fd: %m", __func__);
++}
+
++/* receive an open file descriptor from fork()'d child over unix socket */
++static int _receive_fd(int socket)
++{
++ struct msghdr msg = {0};
++ struct cmsghdr *cmsg;
++ int fd;
++ msg.msg_iov = NULL;
++ msg.msg_iovlen = 0;
++ char c_buffer[256];
++ msg.msg_control = c_buffer;
++ msg.msg_controllen = sizeof(c_buffer);
++
++ if (recvmsg(socket, , 0) < 0) {
++ error("%s: failed to recei
Bug#850891: Additional patch, to cover slurmdbd's duplicate code
tags 850891 + wontfix Hi Rémi and Karl, since the discussion about this possible feature is over I'm tagging this old bug with wontfix. Thanks for your contribution -- Gennaro Oliva
Bug#855905: slurmd: Restarting slurmd kills all running jobs
Hi Frederik, On Thu, Feb 23, 2017 at 09:38:15AM +0100, Frederik Himpe wrote: > When the slurmd is updated and the service is stopped and started, all > running jobs are killed. This is not supposed to happen. > > I found this bug: > https://bugs.schedmd.com/show_bug.cgi?id=2095 > which leads to this commit fixing this problem when slurmd is running > via systemd: > https://github.com/SchedMD/slurm/commit/508f866ea10e4c359d62d443279198082d587107 Thank you very much for reporting this. > Debian's slurmd.service is indeed missing the option > KillMode=process This will be in the next package release, toghether with the other changes in the upstream version. > Maybe Debian should use the upstream slurmd.service.in instead of > maintaining its own slurmd.service? I prefer to adapt the upstream copy because there can be some difference (e.g. EnvironmentFile) but indeed I need to check upstream more regularly. Thanks again for your help -- Gennaro Oliva
Bug#850891: Additional patch, to cover slurmdbd's duplicate code
Hi Rémi and Karl, On Wed, Jan 11, 2017 at 09:23:14PM +, Karl Kornel wrote: > If I would play devil’s advocate, then I would say this: “An action > like this seems inappropriate to place into a package that does not > clearly indicate why it is needed. Instead, you should create a > slurm-common package, and have the user creation happen there.” This is the reason because we didn't include this change into Debian: I understand that repeating code is not so smart, but decoupling the action of creating user from the packages that actually need it, in my opinion is worst since it hides the reasons behind the user creation. > I would be OK with that: I am fine putting together a patch to create > a “slurm-common” package that does the user creation. Some common > documentation could also be moved to that package. But, I did not > know if that was appropriate, so I submitted the simpler change first! I think that a package for the user creation is a bit excessive. Best regards, -- Gennaro Oliva
Bug#851103: slurm account's UID conflicts with a user -- Allow setting a different ID at install time
Hi Karl, thanks for your interest in the slurm Debian package. On Thu, Jan 12, 2017 at 01:30:40AM +, Karl Kornel wrote: > We are in the process of setting up a new cluster, which will be > available to many Stanford people. As part of setting it up, I > discovered that UID 64030 (which is normally used for SLURM) is > already in use by a previous student! > ... > The easiest thing to do would be to make a local modification to the > existing preinst script, replacing “64030” with a different UID (I > already have one allocated). But, I think the better way to do it is > to make the preinst script prompt the user for an ID, and then use > that! As you can read in the Debian policy manual [1] the range 6-64999 is "globally allocated by the Debian project, but only created on demand. The ids are allocated centrally and statically, but the actual accounts are only created on users' systems on demand." When I packaged slurm for Debian, I explicitly asked for a free UID in that range (check bug #12) and 64030 was given. I preferred to use this approach because it avoids manual configuration and needs of synchronization among nodes. That range 6-64999 of UID should be avoided for regular users on a Debian System. > Here’s how things work: > > 1) If an account called “slurm” already exists, and a group called > “slurm” already exists, then the package install takes place. This is > actually a break from previous behavior. > 2) Ask the user to provide an ID. If no ID is provided (because the > user cleared the field, because a noninteractive install is happening, > etc.), then default to ID 64030. > 3) Check for non-numeric characters in the response. If any are > found, notify the user and mark an error. > 4) Check if the ID is already in use, either for a user or a group. > If the ID is in use, notify the user and mark an error. > 5) If no errors were found, go to the next step. If there have been > three failed attempts, then error out the install/upgrade. Otherwise, > increase the priority of the query, and go back to Step 2. > 6) Add the user/group, as a system account, and without a home directory. Regarding your script, in chapter 6 "Best Packaging Practices" of the "Debian Developer's Reference" [2] it's clearly stated that "All prompting or interactive configuration should be kept to a minimum." Without considering the use of automatic configuration tools this proposed patch would require the administrator to enter the slurm ID on all the cluster nodes. > As I mentioned, the biggest change between the original script, and my > proposal, is that two previous checks have been removed: > > * There was a check to see if the slurm account had a home directory; > if it did, then (under certain conditions) the home directory is > changed to “/nonexistent”. This is still required since previous version of the package added user without specifying "/nonexistent", therefore when updating from those releases we need to modify this information. [1] https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2.2 [2] https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-debian-maint-scripts Best regards -- Gennaro Oliva
Bug#849140: slurm-llnl: Please add --enable-multiple-slurmd
Hi Ryan, On Thu, Dec 22, 2016 at 02:02:52PM -0800, Ryan Lovett wrote: > Please pass > --enable-multiple-slurmd to the first dh_auto_configure line. multiple slurmd support will be added in the next upcoming release of the package. Best regards -- Gennaro Oliva
Bug#848625: Please drop openssl-blacklist dependency
Hi Chirstian, On Mon, Dec 19, 2016 at 03:23:06AM +0100, Christian Hofstaedtler wrote: > Please drop the dependency on openssl-blacklist, if possible. > As outlined in #833245, it's usefulness is probably over. thank you for your comment; openssl dependency will be dropped in the next upcoming release of the package. Best regards -- Gennaro Oliva
Bug#847342: slurm-wlm-torque: qstat does not work until libswitch-perl is installed
Hi Frederik, On Wed, Dec 07, 2016 at 12:27:40PM +0100, Frederik Himpe wrote: > I needed to install libswitch-perl to make qstat work. thanks for pointing this out. I will include this dependency in the next package release. Best regards -- Gennaro Oliva
Bug#845268: slurmd restart points to a non-existent readme: /usr/share/doc/slurmd/README.Debian
Hi Gyozo, thanks for pointing this out! On Mon, Nov 21, 2016 at 11:11:07PM +0100, Harka Gyozo wrote: > "Please follow the instructions in /usr/share/doc/slurmd/README.Debian" > But no such file or directory The README.Debian is provided by the slurm-wlm package under: /usr/share/doc/slurm-wlm/README.Debian please find it attached for your convenience. I will make the slurmd binary package provide a copy of the README.Debian in the next release. Best regards -- Gennaro Oliva Configuration Instructions == In order to use SLURM you need a proper configuration file for your cluster that need to be stored under /etc/slurm-llnl/slurm.conf on every node. You can point your browser to file:///usr/share/doc/slurmctld/slurm-wlm-configurator.html for an automatic configuration tool. Please leave red fields untouched and change green field to fit your cluster configuration. You can also find a simple sample configuration that provides a control machine to run the Slurm's central management daemon and a single node for job execution under /usr/share/doc/slurmctld/examples/slurm.conf.simple.gz
Bug#792370: slurm-wlm-basic-plugins: Missing ext_sensors_rrd plugin
Hi Mario, On Tue, Jul 14, 2015 at 11:06:07AM +0200, Mario Lang wrote: According to slurm.conf(5), external sensor plugin ext_sensors_rrd is documented as follows: ExtSensorsType Identifies the plugin to be used for external sensors data collection. Slurmctld calls this plugin to collect external sensors data for jobs/steps and hardware components. In case of node sharing between jobs the reported values per job/step (through sstat or sacct) may not be accurate. See also man ext_sensors.conf. Configurable values at present are: ext_sensors/noneNo external sensors data is collected. ext_sensors/rrd External sensors data is collected from the RRD database. However, the ext_sensors/rrd plguin does not ship with slurm-llnl in Debian: $ dpkg -L slurm-wlm-basic-plugins | grep rrd no output This is due to a missing build depends on librrd-dev. Thank you very much for this report! Best regards -- Gennaro Oliva -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#792368: slurm-wlm-basic-plugins: Missing acct_gather_energy_ipmi plugin
Hi Mario, On Tue, Jul 14, 2015 at 10:23:53AM +0200, Mario Lang wrote: However, the acct_gather_energy/ipmi plguin does not ship with slurm-llnl in Debian: $ dpkg -L slurm-wlm-basic-plugins | grep energy /usr/lib/i386-linux-gnu/slurm/acct_gather_energy_none.so /usr/lib/i386-linux-gnu/slurm/acct_gather_energy_rapl.so This is due to a missing build depends on libipmimonitoring-dev. Thank you very much for this report! Regards -- Gennaro Oliva -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#788785: munge: logrotate errors if removed but not purged
Hi Jan, On Mon, Jun 15, 2015 at 01:48:00AM +0200, Jan Braun wrote: Thank you for maintaining munge. Thank you for reporting and for the patch. Regards -- Gennaro Oliva -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785256: libpam-slurm: pam_slurm.so installed as libpam_slurm.so
Hi Jason, thanks for your report. On Wed, May 13, 2015 at 04:47:20PM -0400, Jason Riedy wrote: Somehow, the file intended for /lib/multiarchbit/security/pam_slurm.so ends up being named libpam_slurm.so. The libpam-slurm.list entry is correctly lacking the lib part, but the file's name is not. Uninstalling does remove libpam_slurm.so. The filename contained in the deb package is /lib/security/pam_slurm.so as you can see here: https://packages.debian.org/jessie/amd64/libpam-slurm/filelist (Separately, it still does not seem to work, but that could be user error. Adding the debug option outputs nothing I can find. I haven't straced sshd yet.) Please let me know, if you find out why it is not working or help me to replicate your situation. Best regards -- Gennaro Oliva -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764441: sinfo and slurm-client: error when trying to install together
Hi Gaudenz, thanks for the upload! On Sat, Oct 11, 2014 at 11:58:36PM +0200, Gaudenz Steinlin wrote: But I would still like to hear from the slurm maintainers and from I personally agree with Mehdi about the fact that it's too late to find a stable name in time for Jessie and confirm our will to find a better solution for the next release. Best regards, -- Gennaro Oliva -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753643: munge: diff for NMU version 0.5.11-1.1
Dear Ana and Remi, On Wed, Sep 17, 2014 at 11:26:30PM +0200, Ana Guerrero Lopez wrote: I've prepared an NMU for munge (versioned as 0.5.11-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. this patch is perfect for me. Thanks for your help -- Gennaro Oliva -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752814: Perl 5.20 transition imminent
Hi Dam, On Mon, Jul 28, 2014 at 11:37:17PM +0300, Damyan Ivanov wrote: We plan to start doing NMUs to DELAYED/5 of all the packages which have a patch attached on or about 2nd of August, but a maintainer upload would be warmly appreciated. package is on a transition for a newname. I have already incorporated the patch in the new source, but I still need some days to release the new version. Best regards -- Gennaro Oliva -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749945: slurm-llnl: Need separate packages for slurmd and slurmctld
Hi Riedy, On Fri, May 30, 2014 at 03:03:35PM -0400, Riedy wrote: With slurm, slurmd runs on compute notes and slurmctld runs on controller nodes. Those nodes are separate. The current package installs and tries to run both at once. This requires a bit of trickery to make installation think it's successful. SLURM init script run whatever daemon is specified in the configfile: if hostname matches ControlMachine it will run slurmctld and if it matches NodeName it will run slurmd. Splitting slurm-llnl into slurmd-llnl and slurmctld-llnl would be incredibly helpful. slurm-llnl is a 25M package, I do not think it's worth it. Best regards -- Gennaro Oliva -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703529: slurm-llnl: Even newer versions, new upstream location.
Hi Jason, On Wed, Mar 20, 2013 at 12:45:45PM -0400, Jason Riedy wrote: FYI, slurm has moved to http://www.schedmd.com, and the latest stable version actually is 2.5.4 with a beta version of 2.6.0. Still under the GNU GPL v2. thank you for notifying this. However a new version of the package is already in the upload queue as you can see from this page: https://ftp-master.debian.org/new.html Any new upload will remain there until Wheezy is out. Best regards -- Gennaro Oliva -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625886: lintian: false positive spelling-error-in-manpage
Package: lintian Version: 2.5.0~rc3 Severity: important Hi, in a manual page of my package there is this sentence: The number of microseconds that the slurmctld daemon requires to process an epilog completion message from the slurmd dameons. and lintian complain about: slurm-llnl: spelling-error-in-manpage usr/share/man/man5/slurm.conf.5.gz requires to requires one to I think that the sentence is correct even if I'm not a native English speaker so I may be wrong. Thanks -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (800, 'testing'), (700, 'stable'), (600, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-vserver-686-bigmem (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lintian depends on: ii binutils 2.21.0.20110327-3 The GNU assembler, linker and bina ii diffstat 1.54-1produces graph of changes introduc ii dpkg-dev 1.16.0.2 Debian package development tools ii file 5.04-5+b1 Determines file type using magic ii gettext0.18.1.1-3GNU Internationalization utilities ii intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf ii libapt-pkg-perl0.1.24+b1 Perl interface to libapt-pkg ii libclass-accessor-perl 0.34-1Perl module that automatically gen ii libemail-valid-perl0.184-1 Perl module for checking the valid ii libipc-run-perl0.89-1Perl module for running processes ii libparse-debianchangel 1.2.0-1 parse Debian changelogs and output ii libtimedate-perl 1.2000-1 collection of modules to manipulat ii liburi-perl1.58-1module to manipulate and access UR ii locales2.11.2-11 Embedded GNU C Library: National L ii man-db 2.6.0.2-1 on-line manual pager ii perl [libdigest-sha-pe 5.10.1-19 Larry Wall's Practical Extraction ii unzip 6.0-4 De-archiver for .zip files lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarchnone (no description available) ii libhtml-parser-perl 3.68-1 collection of modules that parse H ii libtext-template-perl 1.45-2 Text::Template perl module ii man-db2.6.0.2-1 on-line manual pager -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575822: [PATCH] SLURM Perl modules Torque wrappers packaging
Hi Julien, thank you very much for your parch. -- Gennaro Oliva On Fri, Mar 18, 2011 at 04:16:55PM +0100, Julien-externe BLACHE wrote: tags 575822 + patch thanks Hi, The attached patch adds binary packages for the Perl modules and Torque wrappers. Patch is against 2.2.1-1 from Sid. Thanks, JB. -- Consultant INTM - Debian Developer - TMI Calibre EDF - DSP - CSP IT - ITS Rhône Alpes - C4S - CCNPS 04 69 65 68 56 Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message. Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus. This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. E-mail communication cannot be guaranteed to be timely secure, error or virus-free. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617697: FTBFS twice in a row
The problem of building the package more than once have been fixed, but I'm not closing the bug till I don't overhaul the package as suggested. Thanks for your help -- Gennaro Oliva On Thu, Mar 10, 2011 at 06:40:17PM +0100, Julien BLACHE wrote: Source: slurm-llnl Version: 2.2.1-1 Severity: serious Hi, slurm-llnl cannot be built from source twice in a row. Looks like the upstream build system fails to properly clean the tree when running make distclean. The package would also greatly benefit from an overhaul of the packaging scripts with an emphasis on making proper use of debhelper. Thanks, JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606691: slurm-llnl-slurmdbd: package purge (after dependencies removal) fails
Hi, On Sat, Dec 11, 2010 at 12:27:18AM +0100, Lucas Nussbaum wrote: /var/lib/dpkg/info/slurm-llnl-slurmdbd.postrm: 1: ucf: not found dpkg: error processing slurm-llnl-slurmdbd (--purge): subprocess installed post-removal script returned error exit status 127 Errors were encountered while processing: slurm-llnl-slurmdbd this problem was definitely fixed in version 2.1.11-1squeeze3 that has already been uploaded to testing-proposed-updates. Check #604207. Thanks for your report. Best Regards -- Gennaro Oliva -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604207: Bug#605726: unblock: slurm-llnl/2.1.11-1squeeze2
Hi Adam, On Thu, Dec 02, 2010 at 07:27:11PM +, Adam D. Barratt wrote: The fix for that bug looks wrong (or at least incomplete) - the report is about a problem purging the package due to ucf not being available and the chosen solution is to add a dependency on ucf; however, as ucf is not essential, the postrm cannot rely on it being available during purge even with the dependency. A new packages that fix this bug has been prepared and is about to be uploaded. Thank you very much for your feedback. Best regards -- Gennaro Oliva -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576075: mrtg-rrd should depend on rrdtool
Hi Sven, sorry for the late answer. On Sun, Apr 11, 2010 at 11:52:34AM +0200, Sven Hoexter wrote: ok second try: You're using mrtg with LogFormat: rrdtool and haven't read man 1 mrtg-rrd which states [...] MRTG needs access to both the RRDtool perl module RRDs.pm and to the rrdtool executable. [...] and now you're receiving every 5min a mail from the mrtg cronjob which tells you that it couldn't find the rrdtool binary. Yes, this is the case. I don't believe that a man page is the best place to state that and moreover the simplest solution (install the mrtg package) is not explained. Maybe you should consider to write an advice in the Debian.README (the first file anybody reads when trying to configure a new package) where you clearly state that you need the mrtg package if you want the LogFormat: rrdtool. Best regards -- Gennaro Oliva -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576075: mrtg-rrd should depend on rrdtool
Package: mrtg-rrd Version: 0.7-3 Severity: grave Justification: renders package unusable mrtg-rrd should depend on the package rrdtool because it cannot work without it. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (800, 'testing'), (700, 'stable'), (600, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686-bigmem (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mrtg-rrd depends on: ii librrds-perl 1.4.2-1+b1 time-series data storage and displ ii mrtg 2.16.2-5 multi router traffic grapher ii perl 5.10.1-11 Larry Wall's Practical Extraction mrtg-rrd recommends no packages. mrtg-rrd suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552836: slurm-llnl: FTBFS: scontrol.c:193: error: conflicting types for 'getline'
Hi, thanks for the detailed bug report. On Wed, Oct 28, 2009 at 11:36:27AM +0100, Lucas Nussbaum wrote: In eglibc = 2.9, getline was only defined if _GNU_SOURCE was defined. In eglibc 2.10, getline is always defined (since it became a standard in POSIX2008). The problem is that your package already has a function named getline(), which now conflicts with glibc's. You need to rename your function to something else. This problem will be fixed in release 2.0.8 that should be available in a week. I'm waiting for it since it also fix some other warnings. Regards -- Gennaro Oliva -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552257: slurm-llnl: Please add support for BLCR
Hi Robert, On Sat, Oct 24, 2009 at 01:46:19PM -0600, Robert LeBlanc wrote: Debian now includes packages for BLCR and Slurm can be built to support it. BLCR is a checkpooint and recovery tool for processes. I built backported packages of slurm-llnl from Squeeze to Lenny by adding binary dep blcr-util, build-dep libcr-dev and then adding --with-blcr=/usr/lib to the ./configure line in debian/rules. I was already planning to add this feature in the next release. Thank you -- Gennaro Oliva -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541252: slurm-llnl: Incorrect runlevels and dependencies in init.d LSB header
Hi, thanks for your patch it will be included in the next package release. -- Gennaro On Fri, Sep 18, 2009 at 09:19:06PM +0200, Petter Reinholdtsen wrote: Hi. Any hope of having this fixed soon? Let me know if I should not NMU to get a fix into the archive. Note that some code is probably needed in the postinst to correct runlevel links on existing installations. Something like this from the lprng package would probably work. # Those using dependency based boot sequencing with sysv-rc and installing # lprng before version 3.8.A-2.2 would miss the runlevel 4 symlink. # Recover from this. if [ $1 = configure ] dpkg --compare-versions $2 le 3.8.A-2.2 \ [ -f /etc/rc2.d/[SK][0-9][0-9]lprng ] [ -f /etc/rc4.d/K[0-9][0-9]lprng ] then update-rc.d -f lprng remove fi Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
