dun / munge Goto Github PK
View Code? Open in Web Editor NEWMUNGE (MUNGE Uid 'N' Gid Emporium) is an authentication service for creating and validating user credentials.
License: GNU Lesser General Public License v3.0
MUNGE (MUNGE Uid 'N' Gid Emporium) is an authentication service for creating and validating user credentials.
License: GNU Lesser General Public License v3.0
What steps will reproduce the problem?
The systemd-tmpfiles
munge.conf
needs to be excluded from older (hello SLES11) rpm builds in the spec file as it causes rpmbuild to fail.
aelwell@iTDS:~/compile> rpmbuild -ta ./munge-0.5.11.tar.bz2
What is the expected output? What do you see instead?
Requires(postun): /bin/sh
Requires: libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit)
Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/munge-0.5.11
error: Installed (but unpackaged) file(s) found:
/usr/lib/tmpfiles.d/munge.conf
RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/lib/tmpfiles.d/munge.conf
What version of the software are you using? On what operating system?
munge-0.5.11 on SLES11
Please provide any additional information below.
Reported by andrew.elwell in #11.
Original issue reported on code.google.com by chris.m.dunlap
on 19 Dec 2013 at 12:18
What steps will reproduce the problem?
Run munged on FreeBSD 8.2 or later.
What is the expected output? What do you see instead?
munged should consume negligible cpu when idle, and gracefully terminate upon receipt of a SIGTERM
. Instead, munged consumes an entire cpu and must be forcibly terminated with a SIGKILL
.
What version of the software are you using? On what operating system?
munge-0.5.10 on FreeBSD 8.2 & 9.0
Please provide any additional information below.
This bug was introduced by 501d7a1.
This behavior can be averted by running munged with --group-update-time=-1
.
Original issue reported on code.google.com by chris.m.dunlap
on 26 Sep 2012 at 12:21
I had munge working, basic tests across my machines worked. For some reason, it doesn't work any more and complains on ownership issues of the log file. Specifically,
/var/log/munge
is owned by munge and gives the following error
/etc/init.d/munge start
* Starting MUNGE munged
...fail!
munged: Error: Logfile is insecure: invalid ownership of "/var/log/munge"
if I change ownership to root, I get the following ,,,
* Starting MUNGE munged
...fail!
munged: Error: Failed to open logfile "/var/log/munge/munged.log": Permission denied
I am surprised as this used to work ... who should own /var/log/munge
?
What version of the software are you using? On what operating system?
0.5.11 on ubuntu 14.04
Original issue reported on code.google.com by hsundar
on 16 Oct 2014 at 10:13
What steps will reproduce the problem?
Boot a SLES 12 system with the munge service file enabled.
What is the expected output? What do you see instead?
Expected output is the munge service starting successfully.
What we see is munge fails to come up with
Oct 22 16:18:46 nid00002 munged[10601]: munged: Error: Failed to check pidfile dir "/var/run/munge": cannot canonicalize "/var/run/munge": No such file or directory
What version of the software are you using? On what operating system?
Munge 0.5.11 on SLES 12.
Please provide any additional information below.
In our environment systemd removes /var/run/munge
before starting services, so it's missing when munged tries to start. Using this as a guide:
https://blog.hqcodeshop.fi/archives/93-Handling-varrun-with-systemd.html
I added a few lines to munge.service to fix the problem.
PermissionsStartOnly=true
ExecStartPre=-/usr/bin/mkdir -m 0755 -p /var/run/munge
ExecStartPre=-/usr/bin/chown -R munge:munge /var/run/munge
Original issue reported on code.google.com by dcgloe
on 23 Oct 2014 at 8:23
We've found it useful in our environment to have munged lock its pages upon startup because our compute nodes are often subject to extreme memory and disk pressure. Without locking, munged sometimes gets swapped out and cannot respond to requests quickly enough. This causes the resource manager (slurm in our case) to believe that compute nodes are down when they really aren't.
I've written a patch (attached) that adds an option (-M
, --mlockall
) to munged so that it will lock pages on startup. It works well in our environment, so I thought it might be useful to others.
0001-Add-mlockall-option-to-munged.patch.gz
Original issue reported on code.google.com by michaelfenn87
on 22 Apr 2013 at 4:26
Attached is a patch against 0.5.11 which adds the possibility to specify the pid-file to used by munged. Our particular use-case is with Slurm when using different munge-keys (and consequently simultaneously running munged's) for the slurmdbd and the cluster-internal communication. Possibly it is useful for others as well.
munge-0.5.11-specify-pidfile.patch.gz
Original issue reported by Daniel Ahlin [email protected] on 2 Mar 2015
Hello,
Sorry if it's not the correct place to ask those kind of question.
I've got a slurm cluster using munge authentication with an associated "cluster" network. The master and submit node have a public network interface so that users can connect with ssh and submitting jobs. Everything is working fine.
I also have a bunch of external machines with only a public interface. Ultimately, I'd like people to have root access on them and still let them submit batch job on the cluster. Since they are root, they can create a local user with the same uid as valid user on the cluster and impersonate him. Obviously, this is not something we want.
I'm far from being a munge and slurm expert. From what I understand, I'd like to have some kind of ACL mechanisms within munged to express something like :
Or maybe having multiple munge keys with ACL regarding user information allowed to be requested with it (only the key is used as a valid token, no need to express ip restriction).
Maybe there a completely different solution or a simpler workaround I don't see ?
I would be interested to have your opinion on this.
What would be the right place for a solution for this problem ? Auth plugin within slurm ? Some
kind of ACLs in munge and/or multiple key mechanism ?
Hi,
the package bzip2-devel does not exist under openSUSE or SLES products. the package that contains the bzlib.h file is named libbz2-devel.
1] Some informations:
openSUSE# cat /etc/SuSE-release
openSUSE 11.2 (x86_64)
VERSION = 11.2
openSUSE# rpmbuilt -ta munge-0.5.9.tar.bz2
error: Failed build dependencies:
bzip2-devel is needed by munge-0.5.9-1.src
openSUSE# rpm -ql libbz2-devel
/usr/include/bzlib.h
/usr/lib64/libbz2.so
2] Here is the modification I made to munge.spec to have it build on openSUSE 11.2:
openSUSE# diff munge.spec.orig munge.spec
13d12
< BuildRequires: bzip2-devel
14a14,22
>
> %if 0%{?fedora_version}
> BuildRequires: bzip2-devel
> %endif
>
> %if 0%{?suse_version}
> BuildRequires: libbz2-devel
> %endif
>
It is not really an issue but it could help someone else running munge on SUSE systems... maybe a line in the README file could be sufficient.
Cheers,
Matthieu
Original issue reported on code.google.com by timhaute
on 2 Feb 2011 at 11:00
What new or enhanced feature are you proposing?
IPv6 support.
What goal would this enhancement help you achieve?
This would allow an IPv6 address for the credential origin to be stored in the metadata when the credential is encoded, and queried when the credential is decoded.
Please provide any additional information below.
Request from Tomas Kouba on 2013-02-06:
https://groups.google.com/forum/?fromgroups=#!topic/munge-users/dzqNuKT9uww
Original issue reported on code.google.com by chris.m.dunlap
on 11 Feb 2013 at 9:23
What steps will reproduce the problem?
Attempt to build an rpm from the 0.5.11 tarball:
$ rpmbuild -ta munge-0.5.11.tar.bz2
What is the expected output? What do you see instead?
rpmbuild fails with the following errors:
RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/lib/systemd/system/munge.service
/usr/lib/tmpfiles.d/munge.conf
What version of the software are you using? On what operating system?
munge-0.5.11 on RHEL7
Please provide any additional information below.
Reported by JERPoser in #8.
Possibly the same as #27.
Original issue reported on code.google.com by chris.m.dunlap
on 5 Aug 2014 at 12:04
We have an issue on Trinity with linking an application with both liblustreapi and libmunge. It turns out both libraries are exporting the strlcpy symbol. IMO neither library should be exporting a symbol that doesn't belong to the library.
Can you namespace all the symbols provided by libmissing? Maybe something like libmissing_strlcpy, libmissing_strlcat, etc. This will prevent future symbol conflicts. We do something similar in Open MPI. If function x is needed and not available we define opal_x and #define x opal_x in an internal header.
What new or enhanced feature are you proposing?
Add a --max-ttl
command-line option to munged.
What goal would this enhancement help you achieve?
This would allow munged to override the default maximum allowable time-to-live value (MUNGE_MAXIMUM_TTL
) for decoding a credential. Reducing the maximum allowable time-to-live will limit the maximum growth of munged's replay cache. This is viable if clocks within the MUNGE realm can be kept in sync with minimal skew.
Please provide any additional information below.
When munged decodes a credential, it must maintain this state until the credential has expired in order to prevent it from being replayed. Decoded credentials are stored in the replay cache. This is currently implemented as a chained hash. Expired credentials are purged every 60 seconds (MUNGE_REPLAY_PURGE_SECS
). If munged is decoding credentials at a sustained high rate, the replay cache will consume an increasing amount of memory with decreasing performance.
Original issue reported on code.google.com by chris.m.dunlap
on 6 Mar 2014 at 6:21
I am installing munge and cannot get it started on any of our worker nodes. It generates this error when attempting to run munged
Error: Logfile is insecure: "/var/log/munge/munged.log" should be owned by UID 0
I followed the install guide to set the correct permissions, however the error still persists. It does appear that this issue has been common previously, but none of the solutions fix the issue. Using --force produces the error
munged: Warning: Logfile is insecure: "/var/log/munge/munged.log" should be owned by UID 0 munged: Warning: Logfile is insecure: invalid ownership of "/var/log/munge"
Include is an authentication service for creating and validating credentials.
in the repo description so it shows up on third-party sites, like: https://code.gov/#/explore-code/agencies/DOE
Hello. I can't run the basic tests of munge as referred to in InstallationGuide
What steps will reproduce the problem?
munge -n
What is the expected output? What do you see instead?
No error should be displayed
Instead:
munge: Error: Failed to access "/usr/local/var/run/munge/munge.socket.2": No such file or directory
What version of the software are you using? On what operating system?
0.5.11. CentOS 6
Please provide any additional information below.
mycomputer:Munge username$ /etc/init.d/munge status
munged (pid 5937) is running...
Installation was done as root but then chown'd to my username.
Any suggestions for further debugging would be appreciated. I expect the defect is with the user rather than the system...
Thank you.
James
Original issue reported on code.google.com by jamesresearching
on 25 Nov 2014 at 9:38
What steps will reproduce the problem?
Create a group in /etc/group
with ~500 users.
What is the expected output? What do you see instead?
munged should be able to process groups without error. Instead, the following message is logged:
Error: Unable to query group info: Numerical result out of range
This error occurs when processing a group of 482 users on aztec. Further processing of the group file is halted at this point, resulting in subsequent groups being ignored.
What version of the software are you using? On what operating system?
munge-0.5.10
$ lsb_release -a
LSB
Version: :core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:
printing-4.0-amd64:printing-4.0-noarch
Distributor ID: RedHatEnterpriseServer
Description: Red Hat Enterprise Linux Server release 6.2 (Santiago)
Release: 6.2
Codename: Santiago
Please provide any additional information below.
The processing of group membership is done in _gids_hash_create()
. This routine iterates over the groups with xgetgrent()
which encapsulates getgrent_r()
. A buffer is dynamically allocated via xgetgrent_buf_create()
and passed to xgetgrent()
. The size of this buffer is determined by _xgetgrent_get_buf_size()
which calls sysconf(_SC_GETGR_R_SIZE_MAX)
. This particular system returns a sysconf value of 1024. In the past, this value proved insufficient for our systems so MINIMUM_GR_BUF_SIZE
was defined to set a minimum buffer size of 4096.
Group entries are obtained by repeatedly calling xgetgrent()
. This particularly large group causes xgetgrent()
to fail with ERANGE
("Numerical result out of range"). It requires a buffer size of at least 7424.
Original issue reported on code.google.com by chris.m.dunlap
on 7 Jun 2012 at 1:07
What new or enhanced feature are you proposing?
Allow messages logged by munged to be forwarded to syslog, and/or support specifying the minimum priority level for messages to be logged.
What goal would this enhancement help you achieve?
Syslog support would allow for logs to be forwarded to a centralized server. Specification of a minimum priority level would allow informational messages to be suppressed if so desired.
Please provide any additional information below.
Request from Graham Van Heule at LANL on 2012-03-27:
We're wondering if there is an option to reduce the logging level of munge or
have it send to syslog so that we can forward the logs to a diskful systems.
Original issue reported on code.google.com by chris.m.dunlap
on 28 Mar 2012 at 11:56
What new or enhanced feature are you proposing?
Support for transitioning to a new key.
What goal would this enhancement help you achieve?
Each munged currently supports a single cryptographic key. If a group of hosts needs to transition to a new key, there will be a time interval where some hosts have transitioned to the new key while other hosts are still using the old key. Support is needed to allow authentication between hosts during this time interval where both the old and new keys are valid. Furthermore, after this time interval has elapsed, the old key needs to be (automatically) marked invalid.
Requested by Flux: because signed jobs in the queue might sit there for a long time and be invalidated if we had to change the munge key.
Original issue reported on code.google.com by chris.m.dunlap
on 9 Jan 2013 at 8:42
It is the one below in ./src/munged/gids.c
log_msg (LOG_INFO,
"Failed to query password file entry for \"%s\"", user);
return (-1);
We use the same group file on every system, but only the subset of the users that needs access to the system appear in passwd, so this particular error causes a lot of output (~3.5MB/hour).
I'm just going to remove it and recompile, but it might be nice to have that error only output with a debug option or there be an option to disable info level logging or something else that seems reasonable to you. Thanks,
Stephen
Original issue reported on code.google.com by [email protected]
on 23 Oct 2013 at 7:05
Having installed the latest commit from master, which fixed a problem with the specs file, I installed munge, with make && make install
Next, I need to make an rpm, for xCAT to use in provisioning. So I ran
make dist-bzip2 PACKAGE=munge VERSION=0.5.11
This produces a tar.bz2 file, but when I try to run rpmbuild against it;
rpmbuild -tb --clean munge-0.5.11.tar.bz2
I get an error;
error: File /home/jbberry/slurm/munge/V0.5.11/munge-0.5.11.tar.xz: No such file or directory
What steps will reproduce the problem?
I installed (configure, make, make install) munge as admin, because it did not allow me to install it as non-admin user. Checked permission of /var/log/munge and /var/lib/munge - both of them are owned by 'root'.
When I try to start the daemon using /usr/sbin/munged as admin, it gives munged: Error: Logfile is insecure: "/var/log/munge/munged.log" should be owned by uid=0
, when tried as non-admin user it gives the following error, munged: Error: Cannot check logfile "/var/log/munge/munged.log": Permission denied
.
What should I do?
What version of the software are you using? On what operating system?
munge-0.5.10
Original issue reported on code.google.com by diamcode
on 3 Feb 2012 at 8:58
What is a brief explanation of the security vulnerability?
The use of memcmp
for HMAC validation can leak timing information, thereby allowing an adversary to iteratively try HMAC values, time the responses, and progressively deduce the correct HMAC value.
What is the impact, including how an attacker could exploit this?
The attack would allow for the forging of a single credential which must be completed within the credential's TTL (5 minutes by default). It would allow an adversary to rewrite the embedded UID/GID to enable privilege escalation via some other service using MUNGE for authentication. This attack would be more efficient than a brute-force attack against the entire key space.
What can be done to mitigate the attack?
Replace the memcmp
used for HMAC validation with an implementation that compares the two memory regions in an amount of time that is independent of their contents.
What version of the software are you using? On what operating system?
munge-0.5.10
Please provide any additional information below.
Attach any patches, proof-of-concept, or exploit code.
Reported by Jon Bringhurst.
Original issue reported on code.google.com by chris.m.dunlap
on 22 Jul 2013 at 10:12
I built RPMs from the latest release (0.5.10). When I tried to install them, it failed when trying to enable the service for startup. Manually trying to turn on the service, it also failed:
# chkconfig munge on
insserv: Script munge is broken: incomplete LSB comment.
insserv: missing `Default-Start:' entry: please add even if empty.
insserv: exiting now!
/sbin/insserv failed, exit code 1
The OpenSuSE packaging guide (https://en.opensuse.org/openSUSE:Packaging_init_scripts) implies that we need to add a Default-Start
and Default-Stop
line.
I'm not sure what the "defaults" should be, but adding something like:
# Default-Start: 2 3 5
# Default-Stop:
between the ### BEGIN INIT INFO
and ### END INIT INFO
lines seems to fix the problem.
Original issue reported on code.google.com by [email protected]
on 23 Aug 2011 at 7:34
It is possible to conveniently generate (root) munge creds from within the linux kernel using the kernel's request_key()
api.
One adds a line like this to /etc/request-key.conf
:
create user munge * |/usr/bin/munge
Then in the kernel calls:
key = request_key(&key_type_user, "munge", "");
...
It should be possible to generate munge creds for non-root users like this:
create user munge * |/usr/bin/munge --uid %u --gid %g
if munge grew those arguments. The /sbin/request-key
user mode helper runs as root, but the %u
and %g
macros are set to the fsuid
and fsgid
of the kernel context that called request_key()
.
I have two 9p-related uses for this feature:
I am going to implement a wrapper that parses those arguments, calls setregid
/setreuid
, then calls munge. If munge could do that directly for root only, there would be one less wrapper in the world.
Original issue reported on code.google.com by garlick.jim
on 11 Jul 2012 at 11:58
What steps will reproduce the problem?
Not consistently reproducible. This is occurring on a cluster of ~1944 nodes (sierra), of which <1% are exhibiting this behavior after boot. This reportedly started after upgrading the cluster to CHAOS 5.
What is the expected output? What do you see instead?
munged is expected to use minimal cpu time. Instead, top shows it consuming as much of a core as it can. Attaching to the process with strace shows repeated stat()s of /etc/group
:
13:50:27.956403 stat("/etc/group", {st_dev=makedev(0, 19), st_ino=8006,
st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096,
st_blocks=104, st_size=49948, st_atime=2012/05/21-13:05:58,
st_mtime=2012/05/21-11:05:01, st_ctime=2012/05/21-13:05:29}) = 0
13:50:27.956457 stat("/etc/group", {st_dev=makedev(0, 19), st_ino=8006,
st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096,
st_blocks=104, st_size=49948, st_atime=2012/05/21-13:05:58,
st_mtime=2012/05/21-11:05:01, st_ctime=2012/05/21-13:05:29}) = 0
13:50:27.956507 stat("/etc/group", {st_dev=makedev(0, 19), st_ino=8006,
st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096,
st_blocks=104, st_size=49948, st_atime=2012/05/21-13:05:58,
st_mtime=2012/05/21-11:05:01, st_ctime=2012/05/21-13:05:29}) = 0
What version of the software are you using? On what operating system?
munge-0.5.10
$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.2 (Santiago)
$ grep "model name" /proc/cpuinfo | sort -u
model name : Intel(R) Xeon(R) CPU X5660 @ 2.80GHz
$ uname -a
Linux sierra972 2.6.32-220.13.1.2chaos.ch5.x86_64 #1 SMP Thu Apr 19 12:15:29
PDT 2012 x86_64 x86_64 x86_64 GNU/Linux
Please provide any additional information below.
The LWP in question can be identified with either top
or ps
. After attaching to the running process with gdb
, info threads
identifies this LWP as the timer thread. Selecting this thread (thread 4
) and stepping through execution shows _gids_update()
(where the stat()
of /etc/group
occurs). At the end of _gids_update()
, a new timer is scheduled for 1 hour from now. Execution then returns to an inner loop of timer_thread()
that dispatches expired timer events. This inner loop continues while active timers exist that have expired. The current time (set in ts_now
immediately before this loop via timer_get_timespec()
which calls gettimeofday()
) is far in the future (year 2052!), so the next _gids_update()
timer is immediately dispatched, which sets a new _gids_update()
timer which is immediately dispatched, ad infinitum (or at least until sometime in 2052, at which point it may sort itself out).
(gdb) print ts_now
$1 = {tv_sec = 2604158256, tv_nsec = 519236000}
(gdb) print time(0)
$2 = 1337732647
A couple of other nodes in this state show ts_now.tv_sec
values of 2604574221 and 2604574458.
Original issue reported on code.google.com by chris.m.dunlap
on 23 May 2012 at 9:56
Built MUNGE 0.5.10 (and .9) on a CentOS 5 system. Ran the munged. The munge -n | unmunge
test results in lt-unmunge: Error: Invalid credential
Built MUNGE on an Ubuntu system, and copied it to the CentOS. Works fine. readelf
shows that the same libraries are being used in both cases.
I've tried different compilers to no avail.
Original issue reported on code.google.com by arroosen
on 18 Mar 2011 at 9:42
Hi
I was using Munge for my minicluster consisting of one head and 8 nodes. It was working fine with 3 nodes. then the other ones arrived and I have set them up.
Now i wanted to check if SLURM is working properly on all nodes. but somehow I cannot start MUNGE
* Starting MUNGE munged [fail]
munged: Error: Logfile is insecure: invalid ownership of "/"
when i change the log file chown to root it tells me it should be owned by uid=120, ok so changed it back with chown munge munge.log
I don't know what happened so that munge won't run, nothing munge relative has been changes.
log file is empty
Thanks in advance
Original issue reported on code.google.com by [email protected]
on 14 Apr 2014 at 9:11
I've compiled munge myself and there was no reported error during configuration, make or make install. I'm using an ubuntu virtual machine on VirtualBox. The host OS is Mac OS X.
When I try to test the installation using the command
munge -n
I get the following error:
munge: Error: Failed to access "/var/run/munge/munge.socket.2": No such file or directory
There is indeed no /var/run/munge/munge.socket.2
file, but I don't know what this file should be. Should it have been created by installing Munge? Or should I have created it myself and if the answer is yes, which command should I run to get it created?
Thanks in advance.
Erica
Original issue reported on code.google.com by ericaflriello
on 31 Jul 2014 at 8:09
What new or enhanced feature are you proposing?
Support for specifying which network interface munged will use when obtaining the origin IP address to embed within the credential metadata.
What goal would this enhancement help you achieve?
This would allow a client to obtain a credential from a multihomed host such that the embedded origin IP address is relevant to the credential recipient.
Original issue reported on code.google.com by chris.m.dunlap
on 18 Jul 2013 at 6:44
What steps will reproduce the problem?
Start munged on Ubuntu 14.04 without use of the --force
command-line option.
What is the expected output? What do you see instead?
munged should start with the default options. Instead, it fails and exits:
$ sudo service munge start
* Starting MUNGE munged [fail]
munged: Error: Logfile is insecure: group-writable permissions set on "/var/log"
What version of the software are you using? On what operating system?
munge-0.5.11 on Ubuntu 14.04
Please provide any additional information below.
Ubuntu 14.04 changes the /var/log
directory permissions from 0755 root:root to 0775 root:syslog. munged is warning of the group-writable permissions on /var/log
.
Running munged with either the --force
or --syslog
command-line option will override this warning:
--force
will override errors (turning them into warnings) for an existing local domain socket, a lack of entropy for the PRNG, and some potentially insecure file/directory permissions--syslog
will bypass the permission check on /var/log
since log messages will instead be routed to the syslog serviceThese command-line options can be specified in the OPTIONS
variable in /etc/default/munge
:
OPTIONS="--force"
https://bugs.launchpad.net/ubuntu/+source/munge/+bug/1287624
Original issue reported on code.google.com by chris.m.dunlap
on 29 May 2014 at 8:00
What version of the software are you using? On what operating system?
MUNGE 0.5.10
NetBSD i386 6_BETA
patch-config_x__ac__arch.m4.gz
patch-configure.gz
Original issue reported on code.google.com by [email protected]
on 19 Feb 2012 at 1:42
Hello,
I'm a total newbie an i need munge for testing slurm.
I installed munge according to the InstallationGuide with the the following command:
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var && make && make install
When i try to invoke the daemon the following error appears:
munged: Error: Logfile is insecure: invalid ownership of "/var/log/munge"
When i try to test the Installation with remunge or munge -n the following error appears:
munge: Error: Unable to access "/var/run/munge/munge.socket.2": No such file or directory
I'm using mung-0.5.10 and the OS i'm using is openSuse 11.3 on a Virtual Machine (VBox-Host: Win7)
Hope somebody can help me.
Original issue reported on code.google.com by MarcNowak83
on 11 May 2011 at 7:51
Hi related to #36 I am experiencing a similar issue :
On Centos 7.1.1503 I am trying to build an RPM package using the command
rpmbuild -tb --clean munge-0.5.11.tar.bz2
and it fails with the following :
error: Installed (but unpackaged) file(s) found:
/usr/lib/systemd/system/munge.service
/usr/lib/tmpfiles.d/munge.conf
RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/lib/systemd/system/munge.service
/usr/lib/tmpfiles.d/munge.conf
Is there any update on the 0.5.12 release please?
Cheers.
What steps will reproduce the problem?
Configure host to be IPv6-only and start munged.
What is the expected output? What do you see instead?
munged should work on hosts configured for IPv4 and/or IPv6. But on IPv6-only hosts, munged is unable to resolve its hostname:
# /etc/init.d/munge start
Starting MUNGE: mungedmunged: Error: Unable to resolve host "foo"
[FAILED]
What version of the software are you using? On what operating system?
munge-0.5.10
Please provide any additional information below.
All of the MUNGE communications are over a local Unix domain socket, and as such, are unaffected by IPv6.
But when munged starts, it calls gethostname()
to obtain the hostname, and gethostbyname()
to resolve its IPv4 address. This IPv4 address is embedded into the metadata when encoding credentials.
Since the IP address here is not strictly required for authentication, munged should treat a hostname resolution failure as a warning and continue its execution using an IPv4 address of 0.0.0.0.
Reported by Tomas Kouba on 2013-02-08.
Original issue reported on code.google.com by chris.m.dunlap
on 11 Feb 2013 at 8:01
What steps will reproduce the problem?
Have at least N clients (i.e., any user of libmunge
) block while writing to the MUNGE unix domain socket, where N is the number of worker threads spawned by munged (the default is 2).
What is the expected output? What do you see instead?
munged should respond to new client requests. But if enough clients block while sending request data (where "enough" is defined as the number of worker threads), munged will stop responding to requests while continuing to accept new client connections.
What version of the software are you using? On what operating system?
munge-0.5.9
chaos-release-4.3-1.ch4.3
Red Hat Enterprise Linux Server release 5.4 (Tikanga)
Please provide any additional information below.
A given client request is handled by a munged worker thread. The worker reads each client request in two parts: the request header (containing the length of the request body), followed by the request body. [src/libcommon/m_msg.c:m_msg_recv()
]
The read is performed by src/libcommon/fd.c:fd_read_n()
, which keeps reading until either n
bytes have been read or an error/eof occurs.
A timeout value needs to be specified for reading a client request.
Original issue reported on code.google.com by chris.m.dunlap
on 12 Jul 2010 at 10:55
What steps will reproduce the problem?
Add the following to /etc/passwd
(this would never exist in production, but is used to emulate the fact that ldap groups can have case insensitive users defined in them)
dummy1:x:9999:9999::/tmp:/bin/false
Dummy1:x:9999:9999::/tmp/bin/false
to /etc/group
dummy:x:9999:dumm1,Dummy1
What is the expected output? What do you see instead?
munge should run and not crash. Munge will crash.
What version of the software are you using? On what operating system?
I have tried EPEL 0.5.8 (x86_64) and self built 0.5.9 (x86_64,i386) with identical results under Centos 5.5.
Please provide any additional information below.
Munge was quitting without any warning after 1 hour of running. The only clue in the logs was when it started it spit out an ...
2010-10-27 20:21:21 Error: Unable to query group info: Permission denied
Tracing the source it became obvious that munge can not handle the possibility that the same uid is mapped to two different strings, including case insensitivity. The fix for the most obvious issues should be as simple as altering the user comparison to a stricmp, but that does not fix the silent crash of munge during some edge cases and a group info reload.
Original issue reported on code.google.com by ericew
on 28 Oct 2010 at 12:35
What steps will reproduce the problem?
killall -9 munged; munged
What is the expected output? What do you see instead?
After the old munged process has been killed, a new munged process should be able to run. Instead, the new munged process exits with the error Found existing socket "/var/run/munge/munge.socket.2"
.
What version of the software are you using? On what operating system?
munge-0.5.10
Please provide any additional information below.
This error occurs because the old process did not shutdown gracefully, and as such, did not unlink its unix domain socket. The new process finds the existing socket and exits since that socket could be in use by another munged process currently running.
There are several ways in which munged can be prevented from shutting down gracefully: a node could kernel panic, or be power-cycled via powerman, the BMC, or other means. If munged is invoked with the --force
command-line option (or if this option is specified in the DAEMON_ARGS
in /etc/{default,sysconfig}/munge), the old socket will be unlinked and a new socket will be created. But a new munged process should be capable of recovering from this situation without being "forced", while maintaining the ability to detect whether an existing socket is currently in use.
Reported by Don Albert at Bull.com on 2012-03-16.
Original issue reported on code.google.com by chris.m.dunlap
on 18 Mar 2012 at 4:48
I am trying to start munge daemon using /usr/sbin/munged
and it gives me the following error:
munged: Error: Found pid 13595 bound to socket "/var/run/munge/munge.socket.2"
I executed /usr/sbin/munged
once before this without any error, but on trying munge -n
in gave me the error:
munge: Error: Unable to access "/var/run/munge/munge.socket.2": No such file or directory
So, I executed /usr/sbin/munged
again and it gave me the first error mentioned.
I am using Fedora 20 on VirtualBox
Hope someone can help me solve this!
Original issue reported on code.google.com by marathe.monica
on 5 Nov 2014 at 9:39
What steps will reproduce the problem?
Add %define _prefix /opt/slurm
to munge.spec
and build with rpmbuild.
What is the expected output? What do you see instead?
Expected output is a set of RPMs built with /opt/slurm as the prefix. Actual output has this error:
[ 17s] RPM build errors:
[ 17s] File not found by glob:
/var/tmp/cray-munge-0.5.11/opt/munge/lib64/pkgconfig/*.pc
What version of the software are you using? On what operating system?
0.5.11 SLES 11 SP2
Please provide any additional information below.
I believe this is an error in src/etc/Makefile.am around this line:
if test -d "$(libdir)/pkgconfig"; then \
Following my example, /opt/slurm/lib64/pkgconfig
doesn't exist so the file never gets installed. The script should take this into account.
Original issue reported on code.google.com by sheepweevil
on 16 Oct 2013 at 10:09
What steps will reproduce the problem?
$ cd /tmp/foo
$ /home/dun/dvl/munge/configure --prefix=/tmp/munge
$ make -s install
What is the expected output? What do you see instead?
A successful installation into /tmp/munge is expected; instead, the following error occurs:
/usr/bin/install: cannot stat `/home/dun/dvl/munge/src/etc/munge.init': No such file or directory
What version of the software are you using? On what operating system?
munge-0.5.9
Debian squeeze/sid 2.6.32-5-amd64
Please provide any additional information below.
On Linux, the error is lost in the make output and installation continues. On OpenBSD, the error is fatal and installation terminates:
$ make -s install
Making install in src
Making install in etc
install: /home/dun/dvl/munge/src/etc/munge.init: No such file or directory
*** Error code 71
Stop in /tmp/foo/src/etc (line 458 of Makefile).
*** Error code 1
Stop in /tmp/foo/src/etc (line 313 of Makefile).
*** Error code 1
Stop in /tmp/foo/src (line 337 of Makefile).
*** Error code 1
Stop in /tmp/foo (line 378 of Makefile).
Original issue reported on code.google.com by chris.m.dunlap
on 14 Jan 2011 at 3:44
FYI,
You might want to also mention FreeBSD ports and pkgsrc on
https://github.com/dun/munge/wiki/Installation-Guide
On FreeBSD, munge can be installed with
pkg install munge
or
cd /usr/ports/security/munge && make install
On NetBSD:
pkgin install munge
cd /usr/pkgsrc/security/munge && make install
As pkgsrc is cross-platform, the last command can be used on just about any POSIX platform. I use pkgsrc to deploy munge and hundreds of other packages on CentOS.
Cheers,
Jason
When configuring munge with
./configure \
--prefix=/usr \
--sbindir=/usr/bin \
--localstatedir=/var \
--sysconfdir=/etc
the SystemD file residing under /usr/lib/systemd/system/munge.service still contains ExecStart=/usr/sbin/munged
Hi,
I'm trying to install munge on a centos 7 machine and get the following:
...
Requires(post): /bin/sh
Requires(postun): /bin/sh
Requires: libc.so.6()(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) rtld(GNU_HASH)
Processing files: munge-debuginfo-0.5.11-1.el7.centos.x86_64
Provides: munge-debuginfo = 0.5.11-1.el7.centos munge-debuginfo(x86-64) = 0.5.11-1.el7.centos
Requires(rpmlib): rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/vagrant/rpmbuild/BUILDROOT/munge-0.5.11-1.el7.centos.x86_64
error: Installed (but unpackaged) file(s) found:
/usr/lib/systemd/system/munge.service
/usr/lib/tmpfiles.d/munge.conf
RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/lib/systemd/system/munge.service
/usr/lib/tmpfiles.d/munge.conf
Any ideas there?
Thanks
Hello,
I accidentally tried to post to "User Discussion" google group. Sorry for that.
The problem is following: when I try to install munge to the empty prefix it fails with the following error below. Attached file highlights the problematic place in the build system. Currently munge searches systemd directory in the prefix and if there is no such directory it switches to the default /lib/systemd/system
which is not accessible for the regular user. Most of the prefix installations would be empty so this breaks them.
Installation error:
/usr/bin/install: cannot create regular file '/lib/systemd/system/munge.service': Permission denied
make[3]: *** [install-data-local] Error 1
make[3]: Leaving directory `/home/artpol/WORK/Development/SLURM/mpi_plugin/src/munge-patch/munge-0.5.11_old/src/etc'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory `/home/artpol/WORK/Development/SLURM/mpi_plugin/src/munge-patch/munge-0.5.11_old/src/etc'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/artpol/WORK/Development/SLURM/mpi_plugin/src/munge-patch/munge-0.5.11_old/src'
make: *** [install-recursive] Error 1
munge-0.5.11_prefix_install.patch.gz
Original issue reported on code.google.com by artpol84
on 10 Oct 2014 at 9:46
What new or enhanced feature are you proposing?
Defining a MUNGE SELinux security policy.
What goal would this enhancement help you achieve?
An SELinux security policy is missing from the munge rpm in Red Hat EPEL.
With an initial SELinux policy for defining a security domain, one can put that domain into permissive mode to see what is required to use the software.
This makes it possible to use MUNGE on an SELinux enabled system, as one can put a single domain into permissive mode to observe what permissions are required for the full functionality.
Please provide any additional information below.
With SELinux, each process runs in a domain which determines its access rights with respect to other domains. The policy defines a domain munge_t
in which the munge daemon as well as the user commands run (automatic domain transition on execution of the binaries), and provides minimal permissions the daemon needs to start. The working directories in /var/run belong to the domain munge_var_run_t
. This assumes that SELinux runs the Red Hat targeted policy.
munge.te.gz
munge.if.gz
munge.fc.gz
Contributed by Cezary Sliwa <[email protected]>.
References:
https://wiki.centos.org/HowTos/SELinux
Original issue reported on code.google.com by chris.m.dunlap
on 3 Apr 2014 at 5:52
What steps will reproduce the problem?
./configure --enable-debug CFLAGS='-DGIDS_DEBUG'
What is the expected output? What do you see instead?
CFLAGS
arising from --enable-debug
should be appended to those explicitly set at configure-time. In addition, NDEBUG
should not be defined.
$ egrep ^CFLAGS Makefile
CFLAGS = -DGIDS_DEBUG -Wall -Werror -pedantic -g
$ grep NDEBUG config/config.h
/* #undef NDEBUG */
Instead, CFLAGS
from --enable-debug
are omitted and NDEBUG
is defined.
$ egrep ^CFLAGS Makefile
CFLAGS = -DGIDS_DEBUG
$ grep NDEBUG config/config.h
#define NDEBUG 1
What version of the software are you using? On what operating system?
munge-0.5.9
Debian squeeze/sid 2.6.32-5-amd64
Original issue reported on code.google.com by chris.m.dunlap
on 6 Jan 2011 at 11:44
Hi,
When I run /usr/sbin/munged, it show error as below.
error while loading shared libraries: libmunge.so.2: cannot open shared object file: No such file or directory
br
Ring
Original issue reported on code.google.com by [email protected]
on 27 Jul 2011 at 2:00
I built and installed munge for SLES12 using the spec file. The install went fine, but when I went to start the service (prior to reboot) it failed due to:
purge-head12:~ # journalctl -xn | tail
May 27 14:37:46 datawarp-head12 munged[29102]: munged: Error: Failed to check
pidfile dir "/var/run/munge": cannot canonicalize "/var/run/munge": No such
file or directory
I believe this is a result of not doing the following (from https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines ):
If you expect this file / directory to be available after package installation
(and before reboot), remember to add in your package %post :systemd-tmpfiles --create /usr/lib/tmpfiles.d/<file_name>
Hi !
Attached are two files to allow munge to be started on systems using systemd.
munged.service.gz
munged-tmpfiles.conf.gz
munged.service starts the service.
munged-tmpfiles.conf takes care of creating the /var/run/munge directory.
In principal these can be shared across other distributions using systemd so it makes sense to ship them with munge itself.
Please could you add to a contrib directory or something.
Many Thanks
Steve.
(Fedora 17 will use these)
Original issue reported on code.google.com by s.traylen
on 5 Feb 2012 at 11:01
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.