Bug 998737

Summary: /var/spool/hylafax has incorrect ownership and other hylafax+ RPM problems
Product: [Fedora] Fedora Reporter: Raman Gupta <rocketraman>
Component: hylafax+Assignee: Lee Howard <faxguy>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 28CC: faxguy, praiskup
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: hylafax+-5.5.5-1.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-05-28 19:35:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1101325    
Bug Blocks:    

Description Raman Gupta 2013-08-20 00:15:59 UTC
First of all, its great that hylafax+ is now available as an RPM in Fedora. However, I had some issues actually using it, and thought I would report them here.

1) The hfaxd service seems to require the "uucp" user to be created in /etc/passwd even though the RPM seems to create an "adm" user. If the "uucp" user does not exist in /etc/passwd, then hfaxd reports:

Aug 19 19:39:53 x HylaFAX[29439]: No fax user "uucp" defined on your system!

and fails to start. A "standard" way of creating this user on Fedora is to install the "uucp" package, but I think hfaxd and faxd should be consistent, and not depend on the "uucp" user.

2) /var/spool/hylafax is created by the RPM with root:root ownership.

When starting the faxq service, these permissions do not allow faxq to create the FIFO. The message.log shows:

Aug 19 19:13:10 x FaxQueuer[28515]: Could not create FIFO: Permission denied.

Doing chown -R adm /var/spool/hylafax resolves the issue. HOWEVER, once the "uucp" user is created (see #1 above), now faxq wants uucp as well. So chown -R uucp /var/spool/hylafax is then needed.

3) The hylafax+ RPM does not install any faxgetty service. Since I understand why it might not since it may be system-specific, a README.fedora file would be useful in /usr/share/doc/hylafax+-*/ to indicate the necessary step of creating the faxgetty service.

Thanks!

Comment 1 Lee Howard 2014-04-24 17:36:37 UTC
Adding uucp to both Requires and BuildRequires will resolve #1 and #2.  I've committed the change to master, and a release is upcoming.  I agree that a dependency on uucp is a bit deprecated, however, to overcome that dependency HylaFAX+ will need modification upstream.  Such a change is not something that I want to do in the Fedora package only within the RPM (but rather within the HylaFAX+ source code proper).  Unfortunately, I am not able to prioritize that development at the moment (contributions welcome), and so the uucp dependency must remain.

As for #3... it would be possible to modify the hylafax+ startup script to also start faxgettys for each configured modem.  This is how it is done in the Debian package.  I'm not a fan of the exact method that Debian followed in doing that - as I'd prefer it to use inittab/upstart/systemd instead of simply daemonizing faxgetty (since the auto-restart done by init/upstart/systemd is often useful and preferred).  However, this amounts to a feature request more than a bug report, and again, as I am not able to prioritize that development (contributions welcome), I'll need to leave this as-is.

Comment 2 Fedora Update System 2014-05-28 15:44:57 UTC
hylafax+-5.5.5-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/hylafax+-5.5.5-1.fc19

Comment 3 Fedora Update System 2014-05-28 15:46:04 UTC
hylafax+-5.5.5-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/hylafax+-5.5.5-1.fc20

Comment 4 Fedora Update System 2014-05-28 15:46:55 UTC
hylafax+-5.5.5-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/hylafax+-5.5.5-1.el5

Comment 5 Fedora Update System 2014-05-28 15:47:33 UTC
hylafax+-5.5.5-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/hylafax+-5.5.5-1.el6

Comment 6 Fedora Update System 2014-05-28 18:02:10 UTC
Package hylafax+-5.5.5-1.el5:
* should fix your issue,
* was pushed to the Fedora EPEL 5 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing hylafax+-5.5.5-1.el5'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1517/hylafax+-5.5.5-1.el5
then log in and leave karma (feedback).

Comment 7 Fedora Update System 2014-06-10 03:05:10 UTC
hylafax+-5.5.5-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 8 Fedora Update System 2014-06-10 03:07:19 UTC
hylafax+-5.5.5-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 9 Fedora Update System 2014-06-12 23:34:55 UTC
hylafax+-5.5.5-1.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 10 Fedora Update System 2014-06-12 23:35:40 UTC
hylafax+-5.5.5-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 11 Pavel Raiskup 2018-01-30 16:12:22 UTC
(In reply to Raman Gupta from comment #0)
> First of all, its great that hylafax+ is now available as an RPM in Fedora.
> However, I had some issues actually using it, and thought I would report
> them here.
> 
> 1) The hfaxd service seems to require the "uucp" user to be created in
> /etc/passwd even though the RPM seems to create an "adm" user. If the "uucp"
> user does not exist in /etc/passwd, then hfaxd reports:
> 
> Aug 19 19:39:53 x HylaFAX[29439]: No fax user "uucp" defined on your system!

Whould this be solved by..

  Requires(pre): uucp

?

I'm asking because I'm thinking about dropping the %ghost [1] hack
in uucp.spec.  That comes from bug 1101325.
 
[1] https://src.fedoraproject.org/rpms/uucp/c/c58bea626ec9be1e96ca00ae3c3faa46a61eea4c

I'm bit afraid that it could bring regression if things in hylafax+ stayed
as-is.

Comment 12 Lee Howard 2018-01-30 17:59:45 UTC
You've reopened a 3+ year-old bug.

Is there a problem with "Requires: uucp" and "BuildRequires: uucp" ?

Why do you consider %ghost to be a hack, and why do you feel inclined to drop it?  Why change something that is working?

Comment 13 Pavel Raiskup 2018-01-31 13:46:11 UTC
(In reply to Lee Howard from comment #12)
> You've reopened a 3+ year-old bug.

Yes I know, sorry, but IMO that's the best I can do in such situations.
 
> Is there a problem with "Requires: uucp" and "BuildRequires: uucp" ?

It doesn't _guarantee_ you that your %pre scriptlet will have uucp
installed.  That's matter of "luck" basically.
 
> Why do you consider %ghost to be a hack, and why do you feel inclined to
> drop it?  Why change something that is working?

Good question, thanks.  I think I was inspired by lockdev package, and
I'm inclined to consider it is hack because it goes against the guidelines
on [1].  I'm not sure, some additional observation is needed.  After the
time, I'm not sure how these two bugs are actually related...

[1] https://fedoraproject.org/wiki/Packaging:Tmpfiles.d

Comment 14 Fedora End Of Life 2018-02-20 15:30:00 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Comment 15 Ben Cotton 2019-05-02 22:04:48 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 16 Ben Cotton 2019-05-28 19:35:00 UTC
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.