Re: flexfax: HylaFAX and RPM's

[Nico Garcia <raoul@cirl.meei.harvard.edu>]

-----BEGIN PGP SIGNED MESSAGE-----

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

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

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


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

More seriously, I probably edited it after signing it or somebody's
MTA garbled it.

>   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.

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

> 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-)

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

Now, it might make sense to modify "configure" to read
"config.$osname" as well as "config.site", so that funky locations for
different OS's can be automatically set for universal installations
from source code. This also could make the difficulty of adding
tests to "configure" for *every possible location* for fonts, binaries,
etc., less burdensome.

> ???????? 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. 

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

> But it's not firing up hfaxd. This one is a bit sticky, I have removed the 

Uh-Oh!

> 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.

Ack-tooie. Yeah, this could get crazy.

> 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?

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

This is merely opinion: others may be reluctant to hack up people's
/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.

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

> 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?

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

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

			Nico Garcia
			Senior Engineer, CIRL 
			Mass. Eye and Ear Infirmary
			raoul@cirl.meei.harvard.edu

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBNWst7z/+ItycgIJRAQF4EwP/eBd9FIuTzi20ye+qv5jOHYtRa8YM/N/m
re4ieBPOEz6LsHZn4XAEMLYTxSxLrgVzN4Mc+jqDAWxa56SUoC5lHGdvY9Enk5+c
dm5AmqObuRNtJF+HhwS5/YdY7XMAj3AjVTMQKj5SiSuW5mMgTISoAe6GNS9+4QQE
/rqNjimGEjE=
=EzyY
-----END PGP SIGNATURE-----