Hylafax review issues

Toshio Kuratomi a.badger at gmail.com
Sat May 31 20:10:27 UTC 2008


Jason L Tibbitts III wrote:
> One of the oldest review tickets still open is
> https://bugzilla.redhat.com/show_bug.cgi?id=188542, for the fax server
> hylafax.  Earlier this month I picked this up an attempt to try and
> shepherd it through the process, but I'm stuck on a couple of issues
> and the submitter does not seem to be willing to address them
> satisfactorily.  Maybe I should just say "hell no" and drop the
> review, but I guess my objections could be wrong so I figured I'd try
> to start some discussion.
> 
> Issue one is the name: There are multiple pieces of software claiming
> to be hylafax.  There's the software at hylafax.org, and then there's
> the package at hylafax.sourceforge.net, where it is called
> "hylafax+".  I quote:
>   The "+" means that it is better.
> 
> There's also an "enterprise" version from ifax.com.  The second
> version, which upstream calls itself "hylafax+" is the one being
> submitted, but the submitter argues against using that name (see
> comment 38):
>   However, my suggestion would follow what I've said above about the
>   Apache http server.  The distinction of the "+" will mean very
>   little to Fedora users (and in-fact may make the package
>   more-difficult to identify) unless there is more than one HylaFAX
>   package being distributed by Fedora (say, for example, separate
>   "hylafax+" and "hylafax.org" packages).
> 
> Anyone else agree with that reasoning?  What about using
>   Provides: hylafax 
> until the hylafax.org package makes it into the distro (assuming
> someone actually wants to submit it)?
> 
 From reading the review top to bottom I think Lee is willing to name 
the Fedora package hylafax+, just not the upstream tarball.  I don't 
know why he hasn't done that yet except perhaps no one has said, "yes 
please do it that way".

I would okay the Provide: hylafax as long as there's no other hylafax in 
the distro.  Once there is we'd have to decide what to do -- 
alternatives for postfix uses full paths to binaries, MTA,server(smtp), 
smtpd, smtpdaemon.  "sendmail" is not provided.  Perhaps hylafax.org 
could be added as hylafax.org similar to xorg and openoffice.org and 
"hylafax" can be equivalent to sendmail's generic provides.

> The second issue is an FHS violation: several directories are
> installed under /var/spool which contain things that aren't really in
> the spirit of /var/spool.  There's a /var/spool/hylafax/bin directory
> which, you guessed it, contains executables, a
> /var/spool/hylafax/config directory containing config files, and
> /var/spool/hylafax/etc containing other, different config files.
> 
> Here's what the submitter has to say (see comment 83):
>   While the vast majority of HylaFAX binaries and their respective
>   configuration files are installed outside of /var/spool/hylafax,
>   those three directories (etc, bin, and config) are configuration
>   files and configuration utility scripts, etc., that control how the
>   spools are handled.
> 
>   Due to the way that HylaFAX daemons operate it would be extremely
>   cumbersome (if not impossible - as in the case of a chroot) for
>   these to be elsewhere.  They're very much like the configuration
>   files that LPRng had under /var/spool/lpd.
> 
>   So, that's my argument.  I hope that it's acceptable.  But if it's
>   not...  unfortunately there's not much that I am willing to do about
>   it.
> 
> Now, lprng isn't in the distro and I really don't think it would have
> passed review like that, so I can't buy that as an argument.
> "cumbersome", well, too bad I guess.  I'm not sure about a chroot.  I
> mean, just fix the code to look elsewhere.  How hard could it be?
> 
This one's much harder.  It must be fixed.  I took a look at the Debian 
package (they have hylafax.org and not hylafax+) and they do a copy on 
startup of the config files. that's not ideal but it's similar to the 
symlink idea.  The Debian package doesn't mention the binaries so I 
assume they remain in /var/spool.

This only addresses one concern of the FHS, though: that config files 
have a canonical place on the filesystem for users to find them.

Three other programs I know we ship that have chroot operation are 
postfix, scponly, and bind:

postfix does not ship with a chroot configuration in Fedora.  In order 
to enable the chroot, you have to change the configuration file.  The 
instructions will place the chroot in the /var/spool/postfix directory. 
  You have to copy the files that the programs need to operate in the 
chroot jail yourself and maintain them as updates come out.

scponly is similar.  It doesn't have any specific directory by default 
so you can set the chroot to be any set of directories on the system but 
you still have to build and maintain the chroot yourself.

bind has a package bind-chroot that sets up in /var/named/chroot.  It 
includes a new copy of the conf files, data directories, etc.  These are 
separate from the files that come with the normal bind package.

Based on these existing packages the right thing to do in Fedora seems 
to be: follow the FHS even if it prevents chroots.  If the author of the 
package wants chroots for Fedora, supply a subpackage or a script that 
sets up and maintains the chroot.

> But even if, it's too hard to fix, what about a few symlinks?  (To
> somewhere under /usr/libexec for the bin stuff, and somewhere under
> /etc for for config and etc directories.)  Do three symlinks violate
> the FHS significantly enough to cause issues?  My understanding is
> that this should be OK with chroots (as long as the links are
> relative.)  And how does all of this square with selinux?
> 
Yeah, need an SELinux person to weigh in here.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080531/a9b4865a/attachment.sig>


More information about the fedora-devel-list mailing list