From Mageia 4 to Mageia 5 file glusterd.service is now missing - it has obviously intentionally been removed from the glusterfs-server package with Revision 697392. However I could not find any way to automatically start the necessary glusterd daemon. The glusterfsd.service file refers to the file glusterd.service which is missing: ---------------------- [Unit] Description=GlusterFS brick processes (stopping only) After=network.target glusterd.service ... ---------------------- I tried to find a way through several bugreports but in the end I had to give up and I copied the glusterd.service file from a backup of my Mageia 4 partition which fixed the issue instantly.
Thomas, is the Mageia 5 package missing the last fixes that you made in glusterfs-3.4.1-1.2.mga4 in Bug 15473?
Assignee: bugsquad => thomas
I need to do some checking. It may be a typo in the glusterfsd.service file
Status: NEW => ASSIGNED
Gunther: Thank you for reporting this bug and the solution. I think what happened is, we were in release freeze and I forgot about it after the mga5 release. The file glusterd.service is needed. In file glusterfsd it states: # glusterd starts the glusterfsd processed on-demand # /bin/true will mark this service as started, RemainAfterExit keeps it active The bug is now fixed by removing the lines that removed glusterd.service and adding them to the files section and the %post and %preun services. I also cleaned the %files fuse section, it was in there twice. The following files are in mga5 updates_testing: glusterfs-3.5.2-8.1.mga5.src.rpm glusterfs-3.5.2-8.1.mga5.x86_64.rpm lib64glusterfs0-3.5.2-8.1.mga5.x86_64.rpm lib64glusterfs-devel-3.5.2-8.1.mga5.x86_64.rpm lib64api-devel-3.5.2-8.1.mga5.x86_64.rpm glusterfs-regression-tests-3.5.2-8.1.mga5.x86_64.rpm glusterfs-cli-3.5.2-8.1.mga5.x86_64.rpm glusterfs-client-3.5.2-8.1.mga5.x86_64.rpm glusterfs-fuse-3.5.2-8.1.mga5.x86_64.rpm glusterfs-server-3.5.2-8.1.mga5.x86_64.rpm glusterfs-api-3.5.2-8.1.mga5.x86_64.rpm glusterfs-extra-xlators-3.5.2-8.1.mga5.x86_64.rpm glusterfs-geo-replication-3.5.2-8.1.mga5.x86_64.rpm glusterfs-debuginfo-3.5.2-8.1.mga5.x86_64.rpm assigning it to qa
CC: (none) => thomasAssignee: thomas => qa-bugs
Source RPM: (none) => glusterfs
Wanting to try Mageia 5 x64. Please can you say whether the fault (before the update) should happen with a straight install of glusterfs, or is it specific to the upgrade from Mageia 4? And @Gunther: are we talking # systemctl service glusterfs start (or whatever)? Advice please on how to check whether the installed then updated package does not, or does, provide the necessary file glusterd.service It appears that this is the essential point of the update.
CC: (none) => lewyssmith
The fault happens also on a fresh install. I noticed that instantly because one of my file systems resides on a gluster volume. glusterfs depends on glusterd so it tries to start glusterd - which failes. To check if the update works, just check if you find the service glusterd in the mageia control center. If glusterd.service does not exist, the service is not listed in the MCC
(In reply to Gunther Hartmann from comment #5) > The fault happens also on a fresh install. I noticed that instantly because > one of my file systems resides on a gluster volume. > > glusterfs depends on glusterd so it tries to start glusterd - which failes. > > To check if the update works, just check if you find the service glusterd in > the mageia control center. If glusterd.service does not exist, the service > is not listed in the MCC I am not quite sure what you are trying to achive. As the bug report says, glusterfs doesn't start because the glusterd.service was missing. It's missing regardless if you update or do a fresh install. You need to install the package in mga5 updates_testing.That will start since the missing glusterd.service has been added. Let me know if you still have a problem.
(In reply to Thomas Spuhler from comment #6) > (In reply to Gunther Hartmann from comment #5) > > The fault happens also on a fresh install. I noticed that instantly because > > one of my file systems resides on a gluster volume. > > > > glusterfs depends on glusterd so it tries to start glusterd - which failes. > > > > To check if the update works, just check if you find the service glusterd in > > the mageia control center. If glusterd.service does not exist, the service > > is not listed in the MCC > > I am not quite sure what you are trying to achive. As the bug report says, > glusterfs doesn't start because the glusterd.service was missing. It's > missing regardless if you update or do a fresh install. You need to install > the package in mga5 updates_testing.That will start since the missing > glusterd.service has been added. Let me know if you still have a problem. Sorry hit the wrong button, was in reply to Lewis comment#4.
A CVE has been requested for a security issue in glusterfs: http://openwall.com/lists/oss-security/2015/08/18/7 Could we look into fixing that too?
Yea, I can apply the small patch. How far are we with testing?
(In reply to Thomas Spuhler from comment #9) > Yea, I can apply the small patch. How far are we with testing? Nowhere! We are overwhelmed. But I am picking this up. I intend to do no more than see whether the update causes glusterd service to be started. For info: one of the files in question is provided by package: glusterfs-server as: /usr/lib/systemd/system/glusterfsd.service I imagine one can look for the missing glusterd.service file in the same place. Testing MGA5 x64 BEFORE Installed from normal repos all except devel pkgs: glusterfs-geo-replication-3.5.2-8.mga5 glusterfs-server-3.5.2-8.mga5 glusterfs-3.5.2-8.mga5 glusterfs-regression-tests-3.5.2-8.mga5 glusterfs-api-3.5.2-8.mga5 glusterfs-extra-xlators-3.5.2-8.mga5 glusterfs-fuse-3.5.2-8.mga5 lib64glusterfs0-3.5.2-8.mga5 glusterfs-cli-3.5.2-8.mga5 glusterfs-client-3.5.2-8.mga5 The glusterfs-server package 'Files' included /usr/lib/systemd/system/glusterfsd.service but *not* glusterd.service. In MCC System/Services & Daemons, glusterfsd, alone, was shown - not running, but to start at boot; but it could be started. AFTER (without re-booting): Updated from Updates Testing: glusterfs-3.5.2-8.1.mga5 glusterfs-server-3.5.2-8.1.mga5 glusterfs-geo-replication-3.5.2-8.1.mga5 glusterfs-fuse-3.5.2-8.1.mga5 glusterfs-regression-tests-3.5.2-8.1.mga5 lib64glusterfs0-3.5.2-8.1.mga5 glusterfs-cli-3.5.2-8.1.mga5 glusterfs-api-3.5.2-8.1.mga5 glusterfs-extra-xlators-3.5.2-8.1.mga5 glusterfs-client was not in the update packgages list; and after the update seems to have been removed. Is this intentional? The glusterfs-server package 'Files' include both: /usr/lib/systemd/system/glusterd.service /usr/lib/systemd/system/glusterfsd.service In MCC System/Services & Daemons, both glusterd & glusterfsd were shown - not running; glusterd was *not*shown to start at boot, but glusterfsd was (as previously). Both services could be started. I am going to re-boot to see what happens.
Continued from above (MGA5 x64), after re-boot. -rwxr-xr-x 1 root root 300 Aws 6 01:55 /usr/lib/systemd/system/glusterd.service* -rw-r--r-- 1 root root 544 Med 5 2014 /usr/lib/systemd/system/glusterfsd.service Are these permissions OK? MCC System/Services & Daemons shows: - glusterd suspended and not marked for starting at boot. Can be started (slow). - glusterfsd running and marked to be started at boot. Are these observations what is intended? If Gunther/Thomas are happy with this outcome, please mark the Whiteoard MGA4-64-OK. Except that it looks as if another update is on its way (Comments 8/9).
(In reply to Lewis Smith from comment #11) > Continued from above (MGA5 x64), after re-boot. > -rwxr-xr-x 1 root root 300 Aws 6 01:55 > /usr/lib/systemd/system/glusterd.service* > -rw-r--r-- 1 root root 544 Med 5 2014 > /usr/lib/systemd/system/glusterfsd.service > Are these permissions OK? > > MCC System/Services & Daemons shows: > - glusterd suspended and not marked for starting at boot. Can be started > (slow). I have seen that glusterd needs to be enabled manually, and then started. It will start then with re-boot. > - glusterfsd running and marked to be started at boot. > Are these observations what is intended? > > If Gunther/Thomas are happy with this outcome, please mark the Whiteoard > MGA4-64-OK. > Except that it looks as if another update is on its way (Comments 8/9). First of all, I have not access anymore to the svn, so no new work until this is fixed.
(In reply to Thomas Spuhler from comment #12) > (In reply to Lewis Smith from comment #11) > > Continued from above (MGA5 x64), after re-boot. > > -rwxr-xr-x 1 root root 300 Aws 6 01:55 > > /usr/lib/systemd/system/glusterd.service* I don't think that execution-bits need to be set. Systemd should not need them. > > -rw-r--r-- 1 root root 544 Med 5 2014 > > /usr/lib/systemd/system/glusterfsd.service > > Are these permissions OK? > > > > MCC System/Services & Daemons shows: > > - glusterd suspended and not marked for starting at boot. Can be started > > (slow). > I have seen that glusterd needs to be enabled manually, and then started. It > will start then with re-boot. > > - glusterfsd running and marked to be started at boot. > > Are these observations what is intended? > > > > If Gunther/Thomas are happy with this outcome, please mark the Whiteoard > > MGA4-64-OK. > > Except that it looks as if another update is on its way (Comments 8/9). > First of all, I have not access anymore to the svn, so no new work until > this is fixed. If you install gluster it should not be necessary to start glusterd manually after the installation as you might want to start configuring the gluster server which requires glusterd to run. However this is a minor issue I think.
(In reply to Gunther Hartmann from comment #13) > (In reply to Thomas Spuhler from comment #12) > > (In reply to Lewis Smith from comment #11) > > > Continued from above (MGA5 x64), after re-boot. > > > -rwxr-xr-x 1 root root 300 Aws 6 01:55 > > > /usr/lib/systemd/system/glusterd.service* > > I don't think that execution-bits need to be set. Systemd should not need > them. > > > > -rw-r--r-- 1 root root 544 Med 5 2014 > > > /usr/lib/systemd/system/glusterfsd.service > > > Are these permissions OK? > > > > > > MCC System/Services & Daemons shows: > > > - glusterd suspended and not marked for starting at boot. Can be started > > > (slow). > > I have seen that glusterd needs to be enabled manually, and then started. It > > will start then with re-boot. > > > - glusterfsd running and marked to be started at boot. > > > Are these observations what is intended? > > > > > > If Gunther/Thomas are happy with this outcome, please mark the Whiteoard > > > MGA4-64-OK. > > > Except that it looks as if another update is on its way (Comments 8/9). > > First of all, I have not access anymore to the svn, so no new work until > > this is fixed. > > If you install gluster it should not be necessary to start glusterd manually > after the installation as you might want to start configuring the gluster > server which requires glusterd to run. However this is a minor issue I think. I agree, but I am currently not able to work on any package. The svn system lock me out from home and working this things outside of my home on a small netbook is no fun. There will be a security update anyway after this, so let's release this if testing goes OK.
(In reply to David Walser from comment #8) > A CVE has been requested for a security issue in glusterfs: > http://openwall.com/lists/oss-security/2015/08/18/7 > > Could we look into fixing that too? I haven't seen the CVE?
I fixed the permission I added missing %_post_service glusterd to %post server section I added a patch to fix the security issue listed in comment 8 (no CVE # available yet) The following packages are now in 5/updates_testing: glusterfs-3.5.2-8.2.mga5.src.rpm glusterfs-3.5.2-8.2.mga5.x86_64.rpm ib64glusterfs0-3.5.2-8.2.mga5.x86_64.rpm lib64glusterfs-devel-3.5.2-8.2.mga5.x86_64.rpm lib64api-devel-3.5.2-8.2.mga5.x86_64.rpm glusterfs-regression-tests-3.5.2-8.2.mga5.x86_64.rpm glusterfs-cli-3.5.2-8.2.mga5.x86_64.rpm glusterfs-client-3.5.2-8.2.mga5.x86_64.rpm glusterfs-fuse-3.5.2-8.2.mga5.x86_64.rpm glusterfs-server-3.5.2-8.2.mga5.x86_64.rpm glusterfs-api-3.5.2-8.2.mga5.x86_64.rpm glusterfs-extra-xlators-3.5.2-8.2.mga5.x86_64.rpm glusterfs-geo-replication-3.5.2-8.2.mga5.x86_64.rpm glusterfs-debuginfo-3.5.2-8.2.mga5.x86_64.rpm and corresponding i586 packages
Indeed the CVE request hasn't received a reply (and it may not any time soon). Whether we add another bug report is up to you, we can, but it's not strictly necessary. We can only assign one bug to QA for the same update, and we can have a different advisory for Mageia 4 and Mageia 5 in the same bug.
Testing MGA5 x64 Updated packages from those shown in Comment 3 (8.1) to: glusterfs-3.5.2-8.2.mga5 glusterfs-api-3.5.2-8.2.mga5 glusterfs-cli-3.5.2-8.2.mga5 glusterfs-extra-xlators-3.5.2-8.2.mga5 glusterfs-fuse-3.5.2-8.2.mga5 glusterfs-geo-replication-3.5.2-8.2.mga5 glusterfs-regression-tests-3.5.2-8.2.mga5 glusterfs-server-3.5.2-8.2.mga5 lib64glusterfs0-3.5.2-8.2.mga5 and re-booted. > I fixed the permission [OK] -rw-r--r-- 1 root root 300 Aws 20 02:19 /usr/lib/systemd/system/glusterd.service -rw-r--r-- 1 root root 544 Med 5 2014 /usr/lib/systemd/system/glusterfsd.service > I added missing %_post_service glusterd to %post server section In MCC System/Services & Daemons: - glusterd is still shown suspended, & not marked for starting at boot; but it can be started manually, and marked for starting at boot. - glusterfsd is running, and marked to be started at boot. This is the same as previously. I wondered whether the % scripts were meant to ensure that glusterd is started without intervention. If so, perhaps the update from 8.1 rather than 8 affected this outcome. I await comment on this.
I think for the Time being we should go with the fix now and not postpone any more. Gluster is not an easy to use software so the user should have the skills to manually start the necessary servers.
(In reply to Gunther Hartmann from comment #19) > I think for the Time being we should go with the fix now and not postpone > any more. Gluster is not an easy to use software so the user should have the > skills to manually start the necessary servers. glusterfs is packaged so the services are enabled and it will start after a reboot or if a user (as root) will manually start it. I think this is a reasonable approach. BTW Fedora does it the same way.
@Gunther OK. It needs to be understood that the user must start and enable 'start at boot' for glusterd. @Thomas What you say is true for glusterfs, but ot glusterd. I am OK'ing this.
Whiteboard: (none) => MGA5-64-OK
Summary: Glusterd does not start after upgrade from Mageia 4 to Mageia 5 => Glusterd does not start under Mageia 5
(In reply to Lewis Smith from comment #21) > @Gunther > OK. It needs to be understood that the user must start and enable 'start at > boot' for glusterd. > > @Thomas > What you say is true for glusterfs, but ot glusterd. Look at the spec file, both are enabled, but none started. > > I am OK'ing this.
Component: RPM Packages => Security
On mga-5-32 Installed release packages: libglusterfs0-3.5.2-8.mga5 glusterfs-server-3.5.2-8.mga5 glusterfs-cli-3.5.2-8.mga5 glusterfs-3.5.2-8.mga5 glusterfs-client-3.5.2-8.mga5 glusterfs-extra-xlators-3.5.2-8.mga5 glusterfs-fuse-3.5.2-8.mga5 glusterfs-geo-replication-3.5.2-8.mga5 glusterfs-api-3.5.2-8.mga5 # systemctl start glusterd Failed to start glusterd.service: Unit glusterd.service failed to load: No such file or directory. Installed from testing: glusterfs-extra-xlators-3.5.2-8.2.mga5 glusterfs-fuse-3.5.2-8.2.mga5 glusterfs-3.5.2-8.2.mga5 libglusterfs0-3.5.2-8.2.mga5 glusterfs-cli-3.5.2-8.2.mga5 glusterfs-api-3.5.2-8.2.mga5 glusterfs-client-3.5.2-8.2.mga5 glusterfs-server-3.5.2-8.2.mga5 glusterfs-geo-replication-3.5.2-8.2.mga5 After a reboot: [root@mga-5-32 ~]# systemctl status glusterfsd â glusterfsd.service - GlusterFS brick processes (stopping only) Loaded: loaded (/usr/lib/systemd/system/glusterfsd.service; enabled) Active: active (exited) since Sat 2015-08-29 11:58:44 IST; 4min 25s ago Process: 1453 ExecStart=/bin/true (code=exited, status=0/SUCCESS) Main PID: 1453 (code=exited, status=0/SUCCESS) CGroup: /system.slice/glusterfsd.service [root@mga-5-32 ~]# systemctl status glusterd â glusterd.service - GlusterFS, a clustered file-system server Loaded: loaded (/usr/lib/systemd/system/glusterd.service; disabled) Active: inactive (dead) [root@mga-5-32 ~]# systemctl start glusterd [root@mga-5-32 ~]# systemctl status glusterd â glusterd.service - GlusterFS, a clustered file-system server Loaded: loaded (/usr/lib/systemd/system/glusterd.service; disabled) Active: active (running) since Sat 2015-08-29 12:04:03 IST; 3s ago Process: 17140 ExecStart=/usr/sbin/glusterd -p /run/glusterd.pid (code=exited, status=0/SUCCESS) Main PID: 17141 (glusterd) CGroup: /system.slice/glusterd.service ââ17141 /usr/sbin/glusterd -p /run/glusterd.pid Which indicates the glusterd.service needs to be started manually. However, I've OK'd this update for mga-5-32, since the missing service file is now available.
Whiteboard: MGA5-64-OK => MGA5-64-OK MGA5-32-OK
Proposed advisory; ******************************* Updated glusterfs packages fix security vulnerability and restore missing service file. There were cases where setuid() could fail even when the caller is UID 0 The glusterd.service file was ommitted from the glusterfs package This update resolves both of these issues. References: https://bugs.mageia.org/show_bug.cgi?id=16469 http://openwall.com/lists/oss-security/2015/08/18/7 Source rpm: glusterfs-3.5.2-8.2.mga5 ************************************
We have not tested that the security issued has been fixed. Is there a way to do so or can we validate this update without explicitly testing that fix?
I've just realised that I did not check the permissions (bug #16619) -rw-r--r-- 1 root root 300 Aug 20 01:21 /usr/lib/systemd/system/glusterd.service -rw-r--r-- 1 root root 544 Sep 5 2014 /usr/lib/systemd/system/glusterfsd.service Which looks OK I'll provide an amended proposed advisory.
Actually I think the proposed advisory in comment #24 is probably adequate, since glusterd.service was not present in the release package.
I've validated the update. (I hope that's OK; see comment #25.) The advisory in comment #24 needs to be uploaded to SVN and the update can then be pushed to updates.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Advisory uploaded.
Whiteboard: MGA5-64-OK MGA5-32-OK => MGA5-64-OK MGA5-32-OK advisory
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGASA-2015-0332.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
URL: (none) => http://lwn.net/Vulnerabilities/656223/