Description of problem: In GSS 3.1u3, resources limits for core are set for every user which prevents from further user based changing. Version-Release number of selected component (if applicable): Red Hat Gluster Storage Server 3.1 Update 3 RHEL 7.3 and 6.8 both layered and on-premise installation How reproducible: always Steps to Reproduce: 1. Modify limit for core so that it is different to unlimited 2. Let a non-root user log in Actual results: -bash: ulimit: core file size: cannot modify limit: Operation not permitted Expected results: <no error reported> Additional info: Actually, unlimited core for every user is set twice: directly in /etc/security/limits.conf: * - core unlimited # added by Gluster and then in /etc/profile.d/gluster-env.sh: ulimit -c unlimited This does not look like a good practice. If it is required for pam-driven sessions, an entry in /etc/security/limits.d should be created instead of changing limit.conf. This configuration is supported since RHEL 6. If it is for an interactive session only, /etc/profile.d/gluster-env.sh can be used, in that case no pam entry however. The value should not be set at two places, and should be limited for the user who requires it, i. e. root, or restrict modification of core for some cases only. Also, changing the soft value only should be under consideration. In RHEL 7, even modification in the service unit file can be used. Current default settings break user modification of the core resources limit.
Zdenek, please provide the name of the RPM that installed the /etc/profile.d/gluster-env.sh file. $ rpm -qf /etc/profile.d/gluster-env.sh This file does not seem to be part of the glusterfs package, it must come from somewhere else. This bug can then be moved to the right component. Thanks!
Niels, I am sorry for misrouting: the file is in this package: redhat-storage-server-3.1.2.1-1.el7rhgs from repo rh-gluster-3-for-rhel-7-server-rpms Both for layered and on-premise install. Similarly for RHEL 6 based installations.
Atin, We definitely can take this in for RHGS 3.3.0
With build: redhat-storage-server-3.2.0.2-1.el7rhgs.noarch a) There exists two files "/etc/security/limits.conf" and "/etc/profile.d/gluster-env.sh" b) /etc/profile.d/gluster-env.sh is provided by package "redhat-storage-server" c) ulimit -c still shows unlimited even when the core value is set to 2 under /etc/security/limits.conf d) login via non-root user, it throws the bash warning as -bash: ulimit: core file size: cannot modify limit: Operation not permitted bash-4.3$ ssh rahul.43.4 rahul.43.4's password: Last login: Mon Aug 7 16:53:25 2017 from 10.67.116.39 -bash: ulimit: core file size: cannot modify limit: Operation not permitted [rahul@dhcp43-4 ~]$ With build: redhat-storage-server-3.3.0.2-1.el7rhgs.noarch a) Only one file exists "/etc/security/limits.conf" [rahul@dhcp42-79 ~]$ ls /etc/security/limits.conf /etc/security/limits.conf [rahul@dhcp42-79 ~]$ [rahul@dhcp42-79 ~]$ ls /etc/profile.d/gluster-env.sh ls: cannot access /etc/profile.d/gluster-env.sh: No such file or directory [rahul@dhcp42-79 ~]$ b) ulimit -c still shows value 2 if the value is set to 2 under /etc/security/limits.conf [rahul@dhcp42-79 ~]$ ulimit -c 2 [rahul@dhcp42-79 ~]$ tail -1 /etc/security/limits.conf * - core 2 # added by Gluster [rahul@dhcp42-79 ~]$ c) login via non-root user, does not throw any error bash-4.3$ ssh rahul.42.79 rahul.42.79's password: [rahul@dhcp42-79 ~]$ Moving this bug to verified state.
Thanks, This looks like the problem is fixed. However, I think two of the points raised in the bugzilla description should be considered again: - an entry in /etc/security/limits.d should be created rather than changing limit.conf owned by the system - the core size limit should be changed for the user root who only requires the change Certainly, providing any change like this does not affect any existing scripts/checks/other subsystems etc. It's not that important, just looks more like a "good practice." Not setting needinfo neither doing any other intervention in the bugzilla process, thank you for understanding.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2774