Bug 12925

from Fedora rsyncd@.service:

[Unit]
Description=fast remote file copy program daemon
ConditionPathExists=/etc/rsyncd.conf

[Service]
EnvironmentFile=/etc/sysconfig/rsyncd
ExecStart=/usr/bin/rsync --daemon --no-detach "$OPTIONS"
StandardInput=socket

Version: Cauldron => 4

Fixed in rsync-3.1.0-6.mga5 and rsync-3.1.0-4.1.mga4.

Advisory:
----------------------------------------

The rsyncd service for running an rsync server, as shipped in the Mageia 4
rsync package, is controlled by a systemd socket-activated unit, rsync.socket.
It was not working correctly due to the package not containing another
needed component.  This has been corrected.

----------------------------------------
Updated packages in core/updates_testing:
----------------------------------------
rsync-3.1.0-4.1.mga4

from rsync-3.1.0-4.1.mga4.src.rpm

CC: (none) => luigiwalser
Hardware: x86_64 => All
Assignee: bugsquad => qa-bugs

The initial mailing list report cited by Frank:
https://ml.mageia.org/l/arc/discuss/2014-03/msg00003.html

Checked rsync-3.1.0-4.1.mga4 on x86_64. The missing file now does exists, rsyncd is correctly started if the rsyncd.socket had already been started when the package is installed / upgraded.

But when rsync-3.1.0-4.1 is installed from scratch (no rsyncd socket active at the time of the install), it does not automatically start rsyncd, and access to rsync from another machine then fails. The spec file probably lacks a post install clause that enables/starts the socket.

CC: (none) => juergen.harms

(In reply to Juergen Harms from comment #4)
> Checked rsync-3.1.0-4.1.mga4 on x86_64. The missing file now does exists,
> rsyncd is correctly started if the rsyncd.socket had already been started
> when the package is installed / upgraded.
> 
> But when rsync-3.1.0-4.1 is installed from scratch (no rsyncd socket active
> at the time of the install), it does not automatically start rsyncd, and
> access to rsync from another machine then fails. The spec file probably
> lacks a post install clause that enables/starts the socket.

It's not missing, not all users will want the rsyncd service enabled just because the rsync package is installed, and in fact, most won't.  As long as the service works when you enable rsyncd.socket, it's working as expected.  Thanks for testing.

Whiteboard: (none) => MGA4-64-OK

I see your point - essentially a difference between installing rsync for use as a client, and for having a rsync server that does not require a permanent daemon.

But, nevertheless, it is not satisfactory to have command-line activation as the only way for activating such an rsync server - this kind of "light service" is precisely the charm of the socket approach, and should become frequently required in small domestic LANs. The normal user does not even realise that this alternative exists.

I see 2 easy alternatives: make the socket option accessible in a drakxx component (probably enhance drakservice with socket buttons), or add a small package - say "rsync-server" - that makes the socket operational. I would prefer the 2nd solution: to keep sockets as transparent components that come with packages and are not visible and do not require user interaction is a good concept.

This is OT with repect to this bug. I think my test was thorough enough to serve as a QA OK. I will, later this day, install an i586 partion with where I can make the same test for i586.

Well, for some socket-activated services, drakxservices should expose them the same way it does with xinetd-based services, so it should allow you to enable rsyncd.socket (and *not* rsyncd.service) just as it used to when it ran through xinetd.  I'm not sure exactly what the logic would be, as it shouldn't expose every .socket unit.

Confirmed that the updated package works correctly on Mageia 4 i586.  This one can be validated.

> 2014-03-04 09:16:22 CET (Juergen Harms comment 6):  will, later this day, install an i586 partion where I can make the same test for i586

> 2014-03-04 13:54:32 CET  (David Walser comment 8): Confirmed that the updated package works correctly on Mageia 4 i586.  This one can be validated.

I have - 2 hour later - obtained the same result.

This is precisely the principal reason why I stopped working for QA: even if it is only an hour to download the i586 iso, to install a system, to do the tests, it is an hour I had to steal elsewhere, and to insert into a tight schedule - and it is a demonstration that teamwork needs organisation and goodwill. Stop complaining that QA is short of people willing to contribute or that people walk away! Accidents - as bugs - will happen, but each kind should only happen once and than be fixed.

Again OT, but needs to be said.

No, it did not need to be said.  The fact that I also tested it does not invalidate your testing.  Furthermore, since I'm the packager for this update, per QA policy I can't mark it as validated based on my testing alone.  Your testing allows me to add the tag, so it was still helpful.

Whiteboard: MGA4-64-OK => MGA4-64-OK MGA4-32-OK

(In reply to Juergen Harms from comment #9)
> I have - 2 hour later - obtained the same result.
>
> This is precisely the principal reason why I stopped working for QA

Well, 1 person per arch to test an update is hardly enough. We don't enforce more in our policy because that would not be sustainable, but it is clearly not a loss of time when an extra tester confirms it works (or finds bugs the other tester hasn't found).

CC: (none) => stormi

(In reply to Juergen Harms from comment #9)
> > 2014-03-04 09:16:22 CET (Juergen Harms comment 6):  will, later this day, install an i586 partion where I can make the same test for i586
> 
> > 2014-03-04 13:54:32 CET  (David Walser comment 8): Confirmed that the updated package works correctly on Mageia 4 i586.  This one can be validated.
> 
> I have - 2 hour later - obtained the same result.
> 
> This is precisely the principal reason why I stopped working for QA: even if
> it is only an hour to download the i586 iso, to install a system, to do the
> tests, it is an hour I had to steal elsewhere, and to insert into a tight
> schedule - and it is a demonstration that teamwork needs organisation and
> goodwill. Stop complaining that QA is short of people willing to contribute
> or that people walk away! Accidents - as bugs - will happen, but each kind
> should only happen once and than be fixed.
> 
> Again OT, but needs to be said.


Perhaps we should all do the same thing then, and stop testing stuff until you can sort things out for us Juergen.

Advisory added to svn. Validating the update.

Someone from the sysadmin team please push 12925.adv to updates.

Keywords: (none) => validated_update
Whiteboard: MGA4-64-OK MGA4-32-OK => MGA4-64-OK MGA4-32-OK advisory
CC: (none) => davidwhodgins, sysadmin-bugs

Update pushed:
http://advisories.mageia.org/MGAA-2014-0076.html

Status: NEW => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED