Re: flexfax: HylaFAX and RPM's

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

FYI, I believe you to be an imposter ;-) What have you done with the real Nico?

===============
WARNING: Bad signature, doesn't match file contents!

Bad signature from user "raoul@cirl.meei.harvard.edu".
Signature made 1998/05/26 14:21 GMT using 1024-bit key, key ID 9C808251

WARNING:  Because this public key is not certified with a trusted
signature, it is not known with high confidence that this public key
actually belongs to: "raoul@cirl.meei.harvard.edu".
================

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

  NG> On Tue, 26 May 1998, Mr. Arlington Hewes wrote:

  MA> The correct way is to create a right ./config.site file and run a clean
  MA> ./configure for the target system and ...

  +> I'm not so sure . . . I don't think I can fault the following though:

  +> ./configure --with-DIR_BIN=/usr/bin --with-DIR_SBIN=/usr/sbin            \
  +> --with-DIR_LIBEXEC=/usr/sbin                                             \

  NG> [ etc., etc. ]

  NG> Oh, man. *I* can fault it. That long set of parameters should live
  NG> in a text-based config.site file, maybe one symbolically linked to
  NG> "config.linux" or something.

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.

Bottom line, I'd rather generate config in-situ, rather than exclude a file 
which I'll have to generate myself now and again.

I'm willing to be convinced, but you and Matthias have not shown me a single 
reason for using config.site versus passing params to configure. In terms of 
making it clear exactly what's going on, and allowing the luser to do their 
own tweaks, I like the configure approach. It also does not break with a new 
distribution, so it's less work for me ;-) And finally, it's OBVIOUS, and 
elegant use of 'configure'. Your turn 8-)

  MA> ... this should also fix all problems in etc/hylafax script (because it
  MA> is created by the configure from etc/hylafax.in). If not one should send
  MA> mods for a better etc/hylafax.in (e.g. with hooks for platform dependent
  MA> scripts).

  +> I will do so if warranted. As you say, the existing script should be fine,
  +> at least it always has been for me.

  NG> If you can fix it, I would be pleased. The location of the script is
  NG> incorrect for Linux (it should go in /etc/rc.d/init.d/hylafax), and
  NG> the use of port numbers versus port names is a bit inconsistent and
  NG> will confuse any sites that use alternative port numbers in their
  NG> /etc/services file to duck firewalls.

???????? 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. 
But it's not firing up hfaxd. This one is a bit sticky, I have removed the 
hard-wired running of hfaxd from inetd. . . but when the punter runs faxsetup 
and chooses either standalone (default) or inetd operation, the configure 
script will not reflect this choice. And I'm not sure how to handle that, to 
be honest. Get faxsetup to add/remove the bit from /etc/rc.d/init.d/hylafax as 
appropriate???? Seems a bit hacky, and I'd rather leave faxsetup vanilla, if 
possible.

As for the use of port . . . well, are you proposing I rewrite hfaxd? From the 
man page at least:

HYLAFAX (NEW) CLIENT-SERVER PROTOCOL SUPPORT
       If  hfaxd  is  started  with the -i option it will service
       clients using the (new)  HylaFAX  client-server  protocol.
       This  protocol  is  strongly  related to the Internet File
       Transfer Protocol (FTP); so  much  so  in  fact  that  FTP
       client  programs  that  include  support for ``quoted com-
       mands'' may be used to communicate with  hfaxd  using  the
       new  protocol.

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

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.

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?

  +> There are actually very few glaring problems in the RPM at the moment.
  +> I'm adding the housekeeping, and removing a few of the more adventurous
  +> and controversial departures from HylaFAX convention, though I am leaving
  +> the xferfaxstats stuff in (and have fixed faxcron).

  NG> Thank you, kind sir, for your efforts. You might also add others of the
  NG> patches I've put at http://cirl.meei.harvard.edu/hylafax/patches/. The
  NG> HTML patches, in particular, will straighten out most of the manpage
  NG> references for local documentation. And the "hosts" patch will help
  NG> keep the man pages straightened out for new users ($SPOOL/etc/hosts for
  NG> HylaFAX vs. /etc/hosts)

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.

I wonder if the big bad spirit of the mailing list is going to bounce my mail this time? *cringe*

-Darren