Re: flexfax: HylaFAX and RPM's

["Mr. Arlington Hewes" <tpcadmin@info.tpc.int>]

>>>>> On Tue, 26 May 1998, "NG" == Nico Garcia wrote:

  NG> I've locked him in the basement for my master, Moo-ha-ha.

8-)

  +> I'm still not sure I agree. I think this is a very straightforward way
  +> of doing things which takes advantage of the power of a well-written
  +> config script. Burying defs in a config.site will, aside from requiring
  +> the rpm build to be done once interactively to generate this, be a MUCH
  +> less obvious way of configging. Anyone looking at the SRPM will have to
  +> look pretty hard before twigging that HylaFAX can use a config.site,
  +> whereas using commandline args to configure is very obvious. I'm not keen
  +> on having to patch up a new config.site file every time a new patchlevel
  +> comes out, and unless a new param is added to configure I am unlikely to
  +> need to change this part of the RPM at all.

  NG> OK, I find the excessively long list of arguments to "configure" to be
  NG> really awkward to work with. That's what "config.site" is *for*.

Awkward for whom? I've not edited it, and may never have to. And I'll be 
dishing out RPMs all over the shop ;-) Sorry, I just don't see the advantage 
to config.site - I could equally say that that's what configure's ability to 
take commandline args is *for*. It's automated - set and forget, and it'll 
cope with new releases without modification. Not so with config.site.

You're not making any headway at convincing me.

  NG> Repetitive Stress Injuries, and typos. The list of flags for configure
  NG> is *SO* long, it almost has to be scripted anyway. If you're scripting
  NG> it, why not put it in the config.site, which can be saved for future
  NG> compilations?

??? Maybe you're just not familiar with RPM? This lives in the .spec file, 
which is the heart of the SRPM. It automates the packaging . . . In this file 
lives that lonnnnnnnnnnnnnnnnnnng configure line. Set and forget, I'll never 
touch it again. Nor will anyone else if their building the RPM locally from 
the SRPM. I don't have to include a config.site you see. New HylaFAX release I 
will not have to modify this section of the SRPM, whereas I _would_ have to 
generate a new config.site.

  +> ???????? If course it should go in /etc/rc.d/init.d/hylafax. And the
  +> version I inherited did already, as well as adding it to the appropriate
  +> runlevels.

  NG> Cool. I don't believe the v4.0pl2 source code had this correct for RedHat
  NG> Linux.

Erm, no, addition to SysVinit runlevels wasn't done, nor was moving the init 
script . . . is just lurked in hylafax-v4.0pl2/etc/ after the build


  +> it appears that it's meant to be invoked as hfaxd -i hylafax. How do you
  +> propose to start up hfaxd without using ports?

  NG> No, I mean that the hylafax script uses both ports and port numbers.  It
  NG> should address all ports by name, so that someone can edit /etc/services
  NG> and have hfaxd running for the new port names.

That's a good point.

  NG> This is merely opinion: others may be reluctant to hack up people's
  NG> /etc/services setups.

  +> While we're at it, I propose to remove the default '-o 4557' flag handed
  +> to hfaxd in the configure-generated etc/hylafax rc script, because it's
  +> nasty, evil and insecure and is just a bad choice for a default 8-)
  +> Not sure why nobody moans about this, although the startup script is
  +> a bit "less than obvious" and I have seen a lot of people just adding
  +> faxgetty, hfaxd and faxq to rc.local, so maybe most of us/you miss out
  +> on it altogether. If you object to this move, shout now please. I don't
  +> know anyone who would need the old (evil) protocol who isn't capable of
  +> tweaking the startup script.

  NG> Some of the older tools (such as MacFlex, I believe) still use 4557.

Then people can add it. Running it by default is irresponsible. I can compile 
an old flaxfax sendfax client and send faxes through such a server. As well as 
check your queue etc. It's not the least bit secure, and it needs to be off.

Please call me on this if anyone has serious objections. I think this should 
be considered for the next patchlevel of HylaFAX . . . the time is passing 
when the -o protocol is needed, and it's a really large security liability 
unless you're firewalled.

  +> Oh, while we're at it . . . should SNPP be on by default as well? A much
  +> stronger case for it, I would think, but unnecessary for many?

  NG> Can't say. I've had difficulty with local SNPP, due to my incredibly lame
  NG> pager company (no SNPP for number-only pagers, GRUMBLE!)

Well, opinions from others solicited here. Is it useful to default to enabled 
snpp? Are there security implications?

  +> I'll have a look at this carefully - I am not a fan of hosts.fax, if
  +> that's what you're proposing. As far as html docs, I'm not installing
  +> them in the /home/httpd directory, as they have no right being served
  +> by apache - they can be read locally from /usr/doc and installed by
  +> hand if they must be remotely available. So they're presently in
  +> /usr/doc/hylafax-v4.0pl2/html. Though I have pulled the patches I have
  +> _not_ read them yet. Thanks for the lively debate . . . as long as my poor
  +> fingers can keep up the pace I believe these things should be discussed
  +> here, and agreed upon in this forum, before I proceed.

  NG> I think this works. One of the things I also did was write up a "fixhtml"
  NG> script that let you install the source HTML pages, then run the script to
  NG> correct the $HTMLPATH and $CGIPATH settings.

Erm, can you send this to me? Thanks!

-Darren