HylaFAX HylaFAX+ Code Repository

This adds some debugging messages to help in situations where a modem isn't being assigned a job as expected.

Follow-up to the last commit. We need to define type tiff_offset_t.

This data type was missed in the updates libtiff v4.

This was from Thomas Jarosch who posted at:

http://bugs.hylafax.org/show_bug.cgi?id=958

Allow JobHostID configuration to re-use user login credentials.

Disconnect from the job host at logout.

Further JobHostID enhancement...
This enhances JobHostID to permit configuration for other job hosts and transparent hfaxd chain-connection to the configured remote job hosts.

We need to check that tagField[0] exists before using it.

This fixes a segfault that occurs if tagField is empty. This problem was introduced in 5.5.5 in the alignment feature addition.

Job priority needs to be passed to the proxy server.

This adds the JobHostID feature.

This merely prepends job id numbers with any configured JobHostID in all communications with the client. It does not affect job ids internally, and it does not add them to notification e-mails, etc. This only deals with the client-server communication.

This is done for a client to be able to distinguish between jobs submitted on one host from jobs submitted on another host by way of the client-viewed job id number.

This may seem a little silly at this point, but the intention is to subsequently develop the ability for hfaxd to act as a proxy-client to other HylaFAX servers when a client attempts to operate on a job which actually exists on a different server.

Consider a "cluster" of HylaFAX servers that all share a single DNS hostname, "fax.mydomain.org". If a client submits a job to the "clustered" name, how will it know which of the servers in the cluster actually took the job? Furthermore, if it needs to subsequently delete or modify the job, how will it know which host to contact? That is the purpose of JobHostID.

Upcoming development in turning hfaxd into a proxy-client for other hosts in the cluster is to permit the client to perform job operations subsequent to the submission on the "cluster" hostname rather than needing to understand the codification of the individual servers in the job id.

Fix instances where a NULL return from crypt() is being ignored.

This follows a bug report made at Debian (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754587) that was appropriately upstreamed to hylafax.org (http://bugs.hylafax.org/show_bug.cgi?id=957).

The code modified by the patch in the bug report from Dr. Tilo Levante stems from a commit made in 2007 in the hylafax.org codebase (http://git.hylafax.org/HylaFAX?a=commitdiff;h=f56311b06ba6451cfd9ad1eac63edff474e155d6). This code did not migrate to HylaFAX+, but the modification in the hylafax.org codebase was merely replicating other cases where a NULL return from crypt() was being ignored.

This changes those other instances so that NULL is no longer ignored and passed-on to strcmp() or streq().

The crypt() man page states that NULL will be returned in the event of an error by crypt(). This condition probably represents other problems on the system and isn't likely to be triggered in production systems that have already been in-use.