3.3 Uplink configuration file
The uplink configuration file is a perl script executed during uplink startup. The beta version of uplink will not report syntax errors on this file, so be careful when editing it, and check by yourself if the syntax is correct:
# perl uplink.cf
This script makes no more than initialize some variables that control uplink behaviour. The ultimate reference for these variables is the uplink.cf file itself.
Some of these variables specify the available ISPs. For each ISP, a nickname must be chosen, that will be used to refer that ISP through the ISP command. Unless you use qmail, the nicknames will also be also used to specify per-isp sendmail.cf files. Then a corresponding entry on %CHATSCRIPT or %DN must be defined. For instance, if the ISPs nicknames are "myisp" and "fast", the configuration file will need to refer things like
$CHATSCRIPT{'myisp'} = '/etc/ppp/pppchat.myisp';
$CHATSCRIPT{'fast'} = '/etc/ppp/pppchat.fast';
Or perhaps
$CHATSCRIPT{'myisp'} = '/etc/ppp/pppchat.myisp';
$DN{'fast'} = '1234567';
Note that for each ISP you'll create only the %CHATSCRIPT or only %DN entry, depending on if there is a chatscript available for that ISP, or only the dial number is informed. The chatscripts (if any) must be manually written. For all ISPs you'll normally write a chatscript, but if PAP authentication is used, it may suffice only to define the dial number. In this case, the script used will be
"" ATZ OK ATDnumber CONNECT
When using PAP, the authentication info must be correctly put on the place that pppd will look for it, as explained earlier.
The faxmodem init string used for sending faxes may be very specific to your faxmodem. Follow the manufacturer's recommendations (if any). You'll find useful hints on the mgetty+sendfax documentation. Read also the "modem initialization section" on the efax man page.
The configuration file will be dinamically re-read every time a
RECONFIG command is issued. The reconfig may interfere with
running FETCH commands. A SIGHUP will have the same effect as
RECONFIG, but may provoke other side-effects on running commands.
The command-line uplink client allows to issue individual
commands, and may be used by at or cron
jobs. Examples:
Once started, uplink listen connections on TCP port
2345. The command interface was designed to allow control
uplink through a telnet session. So just type:
Where host denotes the DCS. A bunch of commands are
then available, please check the reference . To
make sure that the configuration of all communication components
is OK, you'll probably need to test most commands. Most of the
warnings generated by those components will be forwarded to you
by uplink, making easier to diagnose problems. For
instance:
The messages generated by uplink are classified by numeric
codes (103, 104, 200 above). A complete reference
of these codes is available.
Win32 support allows to control uplink and to submit faxes
through samba. These operations are performed using a
simple C application specially designed for that. In fact, the
fax submission is performed through other applications, like word
processors or web browsers, using theirs standard print
features. The print job is addressed for a print queue managed by
samba on the DCS. Then the lpd filter will
move the fax to the fax spool. At this point, uplink will
detect the job and will ask the user for the recipient(s)
number(s). Then, the uplink app will be focused on the
windows desktop, and the user will be invited to inform the
recipient(s) number(s).
Currently the application menus and messages are presented in
brazilian portuguese, but an english version is in the plans for
the first public release. The menus and buttons allow to issue a
limited portion of the commands available from the text
interface, but offer graphical fax preview. A highway-style
animation on the top right informs the user if there is or not a
data connection to the ISP.
The installation of the win32 client is very easy. Just copy the
executable file uplink.exe to the desired directory (for
instance C:\UPLINK), together with the uplink.ini file
provided in the distribution, any windows bitmap file black-and-white
with resolution 216x269, and 5 animation frames (road?.bmp). Two such
files are provided by the uplink distribution: penguin.bmp (a
Linux penguin) and tiger.bmp (yes, the ghostscript
tiger). This file must be renamed to uplink.bmp. So the
installation process is:
The windows print queues will need to be created. This trivial
operation must be done after the creation of the print queues on
the DCS. By now, uplink offers no windows print
drivers, so you'll need to obtain one from elsewhere. The print
job must be submitted to the DCS in postscript
format. The standard win95 driver for the HP5 printer is
known to work fine with uplink. Before using this or other
postscript commercial driver, one needs to check if this
usage will not infringe its license terms.
At this point, the DCS must be configure in order to work
as smtp/pop/imap server to the LAN. The smtp server
must deliver local email immediately, and must queue emails with
external recipients. Both sendmail and qmail may be
configured in order to offer this behaviour.
The usual behaviour of sendmail includes two
characteristics that are undesirable for a dialup server:
DNS lookups are performed during initial SMTP
steps, and queue processing is automatic. Both need to be
disabled.
Basically you'll need a sendmail.cf file specially
prepared. One such sendmail.cf is provided by the
uplink package. It does not provoke DNS lookups,
and disables queue processing by specifying that the major relay
must not be connected because it is "expensive". It must be
edited in order to specify the correct relay (the smtp server of
your ISP).
Be aware that the provided sendmail.cf is derived from earlier
sendmail distributions, and does not comply with recent features
like those for span avoidance or usage of the virtual user
table. As soon as we can, a more up-to-date sendmail.cf will be
provided.
Once you have a sendmail.cf, put it on the right place
(probably /etc), and change your boot scripts in order to
sendmail be started without the -q switch. Now
you're ready for internal email processing. All internal emails
will be instantly delivered by sendmail, and those with
external (Internet) recipients will be queued.
Most installations use more than one ISP. As the ISP smtp server
is specified by the sendmail.cf file, you'll need one such
file for each ISP. The naming scheme required by uplink is
to put an .ISP extension on the sendmail.cf. For
instance, if you use the ISPs "myisp" and "fast", create copies
of the basic sendmail.cf:
And edit the copies putting on the DR and CR
clauses the name of each ISP smtp server (currently you'll need
to make that even if only one ISP is defined!). An example of how
to proccess the email queue is given on the section on testing
the MTA.
The qmail distribution is source-code only, so there are
no binaries ready to run. The installation is not hard. Download
the sources and follow the instructions (a good place to start is
www.qmail.org ). You'll need to deal
with some details, but if you're using qmail I suspect
you're aware of them. Please install ucspi-tcp and
serialmail too.
At this point qmail will hopefully be able to deliver
local email. Emails to external (Internet) recipients will need
to be redirected to an special user, say,
Now all non-local emails will be put on the same place until
maildirsmt is invoked to deliver them to your ISP
smtp server. An example of the invocation of
maildirsmtp is given on the section on testing the
MTA.
Basically one needs to send emails using the DCS as
smtp server. A good way to make that is by hand, using a
telnet client, because it'll be easier to diagnose
problems like a broken IP connectivity, server inactive or client
unauthorized (authorization may depend on the packet filters
being used, on wrappers like tcpd, or on native MTA
features).
But if you prefer not to issue manually the smtp commands
(you'll not learn here how to make that), emails can also be sent
by any true email client (see the next section for details on how
to configure them). In any case, emails with local recipient(s),
with external recipient(s), and with local and external
recipients mixed must be sent to the DCS in order to test
it.
Local recipients must receive immediately the emails sent, and
emails with external recipients must be queued (even on the mixed
case). In all cases, no delay must occur (other than a minimun
one, say, two or three seconds, required for the client generate
headers, convert file formats and transfer the whole thing to the
DCS).
In order to check if the emails with external recipients are or
not queued, use mailq for sendmail, or check the
mailbox of the ppp alias for qmail, if configured
as explained above. In order to check if local email was
delivered or not, check directly the mailboxes on the filesystem,
or try to fetch them emails using one email client (see the next
section for details on how to configure it).
The queue processing will be performed by uplink by
exec-ing a sendmail -q (when the MTA is
sendmail) or a maildirsmtp (when the MTA is
qmail). These commands may be manually issued (we strongly
recommend you to make that, in order to confirm if it's
everything working). To make that, connect to one ISP and execute
one of the following:
(please change isp by the name of the ISP you're currently
connected to).
(please change smtpserver by the ISP smtp server name,
like smtp.foo.com).
The effect of that will be to transfer all queued emails to the
ISP smtp server, that will deliver them to the final
recipients. The last step is to check if the emails really
arrived there...
Perhaps you're asking why the DCS MTA does not deliver the
emails directly to the final recipients. The answer is that it's
usually faster to transfer them first to the ISP smtp
server (because it's nearer than the final recipient). The ISP
smtp server will also deal with temporary failures on the
final recipient mx host, scheduling the delivery for
later, avoiding the need for many dials to send the email.
Once your MTA (sendmail or qmail) is
configured as described above, all email clients on the LAN will
need to be configured to use the DCS as smtp
server. You'll also want to configure it as POP/IMAP
server.
This is just a matter of know how to configure each email
client. Windows clients sometimes must be specifically configured
to access the smtp/pop/imap through the LAN, and
not through the modem, and sometimes it's not "intuitive" how to
configure that.
Of course the DCS will need to have a working
pop/imap server. If your email client cannot retrieve
email from the DCS please check if a pop/imap
server compatable with the MTA mailbox format is installed
and active.
If someone intends to read or write email directly on the
DCS, clients that don't rely on smtp or
pop/imap (like Mail or others) may be used. Most
clients that rely on smtp or pop/imap can also
operate (when used on the DCS) without these protocols,
for instance exec-ing sendmail directly or reading email
directly from the filesystem.
A first example of a fetchmail configuration file is
The forcecr clause will force carriage returns (the
MTA may require CRs, if unsure, please don't remove the
forcecr). Other examples may be found on the
fetchmailrc man page.
Every time you run fetchmail, it will read the
configuration file (~/.fetchmailrc by default) and try to
fetch the emails as specified:
More than one configuration file may be used. The FETCH
command without arguments will refer always the
.fetchmailrc file on the home directory of the
uplink process owner (root). The
mirroring facilities of uplink (that will be
discussed later) are an easy way to deal with various (perhaps
per-user) fetchmail configuration files. In this case, an
argument must be specified to the FETCH command. This
argument must be an object or group name as configured on the
uplink.mc file.
Of course uucp would be a nice solution, but the email
support currently available on uplink is more general, and
compatable with almost any ISP and virtual domain hosting
services. When possible, an alternative configuration of
uplink based on uucp will be available.
The fax server will deliver fax jobs submitted from the LAN. It's
possible to receive faxes if dialin mode is enabled, but
currently uplink will not handle directly the received
faxes (that is, uplink will not register these faxes on
the fax database and operations like preview or print will not be
available for them).
As a first step, it's important to make tests in order to make
sure that your environment (hardware, operating system and line)
allows reliable fax operation. If the fax delivery is not
reliable, try to change (when possible) one piece at a time
(line, faxmodem) in order to detect the source of the
problems. The sendfax documentation contains many
brand-specific hints.
In order to make tests you'll need to know the faxmode device
name (say, /dev/cua2) and the the classes supported by your
faxmodem (check its manual, or issue an AT+FCLASS=?
command using any communication software). Once the delivery
tests are OK, you'll be able to finish the fax server
installation and configuration.
This section will tell you how uplink sends a fax using
efax. Then, you will be able to make tests manually, in
order to diagnose probles or to perform fine-tuning.
The commands below generate a high-resolution tiffg3 file from a
(small) text source by efix, a companion of the
efax package (if you're using version 0.8a of efax
on a recent linux box, maybe you want to try the fixed binary
included in the uplink distribution. That file is then
delivered to 123456:
If the input file is not small, there will be more than one
output page, and you'll need to specify a list of files to
efax. In this case use:
Before reproducing this test, change the serial port device
dev/cua2 and the fax class 1 as required. Change
also, of course, the recipient number.
The sendfax support on the current uplink
development version is broken. Please use efax instead, when
possible.
Fax jobs are generally submitted through standard lpd
print queues. Because of this, print queues must be created on
the DCS. Most platforms provide native tools to create and
maintain print queues. If this is your case, use them. The
directions below apply to those systems that use a
printcap file.
Two queues must be created. One for high resolution (204x196 dpi)
faxes and another for low resolution (204x98) faxes. The entries
on printcap must look like these:
Currently the names of the queues must be psfax-hi
and psfax-lo, and the name of the filters must be
fp_psfax-hi and fp_psfax-lo. The other parameters
may differ from the example. Note that the device is
/dev/null, because the filter itself will move the job to
the fax spool. The filters are links to the fillpipe
program, part of the uplink distribution, so you'll
proceed as follows:
Please be aware that the fillpipe binary will run with
root privileges, because of the setuid above. You can avoid this
if in your system the filter is executed by lpd with the
required privileges to write on the fax spool.
The fax spool is pooled by uplink, that searches new fax
jobs there. Each job is composed by at least two files, a
control file and a data file (in some cases more
than one data file may be present), linked by a common key that
is part of the filename. The control file is that generated by
the print spool, with fields P, N, J, etc
(see lpd(8)). Two additional fields are supported: R, for
remote fax number, and Q, for fax quality. The
distribution provides examples for the cf file.
Currently the data file may be submitted in any one of three
formats: text (iso), postscript or tiffg3. So to send a fax is
just a matter of copy to the fax spool the control and data
files. This operation is called direct submission of
faxes. Of course this copy must be done carefully in order to
preserve data integrity. The rules are:
Examples of direct submission:
Direct submission is mostly useful to integrate uplink to
your existing administrative software. So if you add to your
system the ability of generate the control and data files as
required by your needs, the fax delivery becomes a very simple
task (just copy the files to the right place).
Of course the print server lpd may be used to generate the
control and data files as required by uplink. In fact,
uplink was designed in order to allow an easy integration
with the print system. The print filter, in this case, will
convert postscript to tiffg3, copy the control file (generated by
the print subsistem) and the tiffg3 pages to the fax spool.
Note that when the control file is generated by the print
subsystem, the R field that informs the fax recipient is
absent. In this case, uplink will mark the fax as having
unknown delivery information, and will try to ask this
information to the client that submitted the job. Currently this
requires two things: (1) the client IP number must be known and
(2) the client must be running an uplink client with a
TCP connection established with uplink itself.
This method creates a problem hard to deal with, to known, a
truly multiuser computer cannot be used as a client, because all
users share the same IP number. By now there is no
solution for this problem other than restrict fax submission to
those computers with monouser OSes, or to workstations with
multiuser OSes but that in practice are used by only one user at
a time.
MS-Windows clients are able to submit fax jobs using the
print facility provided by most windows applications. When
samba exports the print queues, these jobs may be directed
to samba, that will redirect them to lpd. The
temporary file created by samba contains the original
client hostname, so the field N of the control file may be
used to deduce the client IP number.
So when a job is submitted from a windows application,
uplink will be able to contact the uplink client
running on that client, in order to ask the recipient number. At
this point, the win32 client distributed as part of the
uplink package, will gain focus and will display a message
asking the user to enter the recipient number. The number
informed will be sent to uplink through an FAXR
command.
Two problems remain when using windows clients. The first one is
that samba versions currently used for uplink
development (1.9) truncate the client name to its prefix of size
6. So uplink will not be able to identify clients with
long names unless their prefixes of size 6 are also registered on
the LAN nameserver. The second problem is that multiuser
NT machines (Citrix, or the NT terminal server)
will not be able to act as uplink clients, as explained
before.
In some cases it's possible to test fax delivery without a
telephone line. It's very useful, for instance when
Just connect the DCS faxmodem (the one that will be used
for fax delivery) with the other faxmodem or with the fax
machine, using a standard telephone cable (with RJ-11 connectors
on both sides). You must use the "wall" (or "telco" or whatever
name the manufacturer chose) connectors on both sides, and not
the "phone" connectors, used to extend the line. Now try to adapt
one of the following example for your environment:
[from Zoltrix v32 Rockwell-based (efax) to Sportster 33k
(efax)]
Both modems are at /dev/ttyS2, on different machines. The
test worked both for starting first the sender process or the
recipient process. Sender process:
Where 'doc.fax' is a tiffg3 input file (see the section on testing efax ). Recipient process:
[from Sportster 33k (sendfax) to Zoltrix v32 Rockwell-based
(efax)]
Both modems are at /dev/ttyS2, on different machines. This
test worked fine starting the sender process before the recipient
process. The sendfax documentation contains important
information on using USR modems for faxing. Sender process:
Where doc.fax is a raw fax file (don't use a tiffg3
file). The recipient process is:
[from Zoltrix v32 Rockwell-based (efax) to Samsung FX40 fax
machine]
The modem is at /dev/ttyS2. This test worked fine pressing
the fax machine START button before firing up the sender process:
[from Samsung FX40 fax machine to Zoltrix v32 Rockwell-based
(efax)]
The modem is at /dev/ttyS2. This test worked fine starting
the recipient process before pressing the fax machine START
button. Recipient process:
[using simulfax]
Finally, if you're a developer and want to debug or change
uplink code, a fax delivery simulator is available. It's
name is simulfax. Please configure it as the fax delivery
agent. It'll not try to use the faxmodem device. It'll only wait
a (small) random amount of seconds and return a random-generated
answer about the delivery final status (success or failure).
The mirroring features have two major applications: (1)
periodically refresh web pages (for instance news pages) on the
local cache, making them available to the LAN clients, and (2)
manage large downloads during off hours (for instance download a
30 megabyte archive along two nights).
From the various web proxy servers currently available,
wwwoffle is a very interesting choice for networks with a
dialup connection to the Internet. It allows to browse the cached
pages when disconnected, in a transparent way, as if you were
connected, and provides a very nice administration interface. For
details, check
http://www.gedanken.demon.co.uk/wwwoffle/ .
In order to activate the uplink support for
wwwoffle, you need to inform the machine:port
specification required by wwoffle when a online of
offline notification is performed. For instance:
Then uplink will notify wwwoffle every time the
link becomes up or down. The mirroring facilities of
uplink may also benefit from the features of
wwwoffle, please see the example in the next section.
The web pages and files to be mirrored are specified on the
/etc/uplink.mc file. This file is a perl script executed
by uplink during startup. Every time the status of some
entry changes, uplink rewrites this file. Each 6 entries
of the @FETCH list are a 6-field "object" specification. The
commands FETCH/CHANGE/INVAL/DELETE may refer an object or a group
of objects. The descriptions of the fields follow:
Example:
Note that the FETCH/INVAL/IGNORE/DELETE commands does not specify
if the argument must be considered as an object name or as a
group name. One same string may occur both as object name and
group name, and one same string may be used as object name for
more than one object. Each command will affect all objects to
which the argument is its name or occurs within its grouplist.
The uplink script itself does not provide schedule
facilities, but rely on the OS for that. Unix-like systems have
at and cron commands, that may be used to issue
commands to uplink at given days or times, once or
periodically. For instance, you can instruct cron to execute
Every night in order to make the DCS mirror the entries
from the group offhours. If these include large downloads,
the better solution is to issue this command every 30 or 60
minutes, in order to prevent yourself from modem hangups. The
command
Will stop fetching, and may be issued automatically by
cron on morning.
The current strategy used by uplink dialin support is to
fire up a preconfigured getty process every time the line
becomes idle, and kill it when someone on the LAN requests the
line for data or fax.
This method offers a simple way to use the line for incoming
data, fax or voice calls, yet the input from the call (e.g. a fax
or a voice message) will not be automatically handled by
uplink.
Whether the system will handle or not each type of call (data,
fax and voice), simultaneously or not, will depend on the
getty capabilities. By now our examples include
uugetty, for data-only, and vgetty, for
data/fax/voice.
In order to enable dialin, the $GETTY variable must contain a
working getty command, and the $DIALIN variable must
contain 1. The $DIALIN variable may be dinamically changed
through the DIALIN command. The sections that follow show
examples on how to configure $GETTY.
For data-only incoming calls, uugetty is a good
choice. The simplest configuration would be
Where uugetty.upl is a configuration file put on the
uugetty default directory for configuration files (this is
platform dependent), and ttyS0 is the modem device. The contents
for uugetty.upl could be
This configuration will make uugetty answer the call after
the first ring (note that the answer command will be issued bu
uugetty, and not automatically by the modem). Depending on
your modem defaults, may be useful to customize the init
string. Other commands you'll probably want to add are M0
for silently operation, and S7=<n> to avoid collect
calls.
Using vgetty it's possible to answer data, fax and voice
calls. Hopefully, each type of call will be correctly recognized,
and the modem and the computer will act as required. The default
configuration will play a message, will try data and fax
connections, and record a message from remote. An alternative is
to write an answering script based on DTMF tones
recognized by the modem.
Faxing will require a class-2 modem. Voice requires a voice
modem. The minimal configuration could be
Where ttyS2 is the device, and 3 rings will be required
before answer the call. You'll need also customize the
vgetty configuration file. Please refer the vgetty
docs. You'll find there information on the vgetty
configuration file, and on vgetty behaviour when answering
a call and detecting data, fax or voice calls. There is also
documentation on how to write customized scripts. In the near
future we'll try to put here some examples.
To be able to run uplink, a platform must run at least the
communication components desired (pppd, getty,
etc). Most unix-like platforms run all components supported by
uplink, so it'll not be hard to use them. Currently
Linux is the development platform. The author uses
uplink on Linux and FreeBSD boxes. Yet some
of the communication components run on win32, the server
was not tested till now on non-unix systems.
Very careful programming was performed in order to make
uplink stable and secure. There are basically some
details, however, that must be worked on:
Hopefully, all these problems will be solved till the first public
release of uplink.
As we're not up-to-date with these nice softwares, it's better to
check their homepages to confirm their current state:
The commands currently supported by uplink and theirs
arguments follows. The command names may be issued in uppercase
or lowercase. The command names may be abbreviated to any prefix
that will identify it uniquely (e.g. "H BL" instead of "HELP
BLOCK").
3.4 Command-line client
$ uplcmd servername 2345 'send'
$ uplcmd servername 2345 'fetch'
3.5 Text-based uplink client
# telnet host 2345
$ telnet hal 2345
Trying 192.168.0.1...
Connected to hal.home.unet.
Escape character is '^]'.
103 hal.home.unet [192.168.0.1] joined us as client 0
103 uplink v0.9e ready!
UP
103 UP request
104 Jan 31 12:40:26 hal pppd[1457]: pppd 2.3.3 started by root, uid 0
104 Dialling your ISP...
104 ATDP61918262
104 CARRIER 28800
104 PROTOCOL: LAP-M
104 CONNECT
104 Connected, now logging in ...
104 Logged in OK
104 Jan 31 12:40:58 hal pppd[1457]: Serial connection established.
104 Jan 31 12:40:59 hal pppd[1457]: Using interface ppp0
104 Jan 31 12:40:59 hal pppd[1457]: Connect: ppp0 <--> /dev/ttyS0
200 local IP is 200.245.169.143
201 remote IP is 200.245.169.3
3.6 Win32 uplink client
C:\DISTDIR\> MKDIR \iplink
C:\DISTDIR\> COPY UPLINK.EXE C:\UPLINK
C:\DISTDIR\> COPY SOME.BMP C:\UPLINK\UPLINK.BMP
C:\DISTDIR\> COPY ROAD?.BMP C:\UPLINK\
4. The Email server
4.1 Configuring sendmail
# cd /etc
# cp sendmail.cf sendmail.cf.myisp
# cp sendmail.cf sendmail.cf.fast
4.2 Installation and Configuration of qmail
# echo ":alias-ppp" > /var/qmail/control/virtualdomains
# /var/qmail/bin/maildirmake ~alias/pppdir
# echo "./pppdir/" > ~alias/.qmail-ppp-default
4.3 MTA test procedures
# sendmail -C/etc/sendmail.cf.isp -q
# maildirsmtp ~alias/pppdir alias-ppp- smtpserver 'hostname'
4.4 Configuring and testing email clients
4.5 Configuring fetchmail
poll mail.myisp.com proto pop3
user bozo with pass bozopass is bozo here forcecr
user sales with pass salespass is joe here forcecr
# fetchmail -a
This is just what uplink will do every time it receives a
FETCH command. If the operation is successfull, the emails
on the remote mailboxes will be put on local mailboxes for the
LAN clients. Many servers and mailboxes may be specified in one
configuration file.
4.6 What about uucp?
5. The Fax Server
5.1 Testing efax
$ efix doc.txt >doc.fax
$ efax -d /dev/cua2 -o 1 -t 123456 doc.fax
$ efix -n "doc.%d" doc.txt
$ efax -d /dev/cua2 -o 1 -t 123456 doc.001 doc.002 ...
5.2 Testing sendfax
5.3 Creating the DCS print queues
psfax-hi:\
:sd=/var/spool/lpd/psfax-hi:\
:mx#0:\
:sh:\
:lp=/dev/null:\
:if=/usr/local/sbin/fp_psfax-hi:
psfax-lo:\
:sd=/var/spool/lpd/psfax-lo:\
:mx#0:\
:sh:\
:lp=/dev/null:\
:if=/usr/local/sbin/fp_psfax-lo:
# cc -o fillpipe fillpipe.c
# cp fillpipe /usr/local/sbin
# cd /usr/local/sbin
# chmod a+s fillpipe
# ln -s fillpipe fp_psfax-hi
# ln -s fillpipe fp_psfax-lo
5.4 Submitting fax jobs directly
# copy cfdoc1.txt /var/spool/uplfax
# copy dfdoc1.txt /var/spool/uplfax/dfdoc1.txt.tmp
# cd /var/spool/uplfax
# mv dfdoc1.txt.tmp dfdoc1.txt
# copy cfdoc2.txt /var/spool/uplfax
# copy dfdoc2.003 /var/spool/uplfax/dfdoc2.003
# copy dfdoc2.002 /var/spool/uplfax/dfdoc2.002
# copy dfdoc2.001 /var/spool/uplfax/dfdoc2.001.tmp
# cd /var/spool/uplfax
# mv dfdoc2.001.tmp dfdoc2.001
5.5 Submitting fax jobs through lpd
5.6 Submitting jobs from windows
5.7 How to test fax delivery without a telephone line
Of course you'll need a second faxmodem or a fax machine to act
as the sender or recipient. The procedure described below will
not work for all combinations of faxmodem or fax machines brands
(don't ask me why). You'll need to manually control both sides.
# efax -o 1 -i "&D2&K6X3" -d /dev/ttyS2 -t 1 doc.fax
# efax -o 0 -i "&D2&H3X3" -d /dev/ttyS2
# sendfax -l ttyS2 -m X3 1 doc.fax
# efax -o 1 -i "&D2&K6X3" -d /dev/ttyS2
# efax -o 1 -i "&D2&K6X3" -d /dev/ttyS2 -t 1 doc.fax
# efax -o 1 -i "&D2&K6X3" -d /dev/ttyS2
6. Mirroring files and web pages from the Internet
6.1 Enabling wwwoffle
$WWWOFFLE_SRV = "192.168.0.1:8081";
6.2 Specifying objects to mirror
@FETCH = (
'freshmeat',
'',
'incomplete',
'?',
'wwwoffle www.freshmeat.net -gSifs -p webproxy:8080',
'',
'bobmail',
'mail',
'refresh',
'0',
'fetchmail -a -f ~bob/.fetchmailrc',
''
);
6.3 Scheduling the mirror procedures
uplcmd host 2345 'fetch offhours'
uplcmd host 2345 'down'
7. Dialin support
7.2 Enabling dialin support
7.2 Configuring uugetty
$GETTY = "uugetty -d uugetty.upl ttyS0 38400";
INITLINE=ttyS0
TIMEOUT=60
INIT="" \d+++\dATH0\r OK\r\n AT\s&F\sE1\sX4\sS0=0\r OK\r\n
WAITFOR=RING
CONNECT="" ATA\r CONNECT\s\A
DELAY=1
7.3 Configuring vgetty
$GETTY = "vgetty -n 3 ttyS2";
8. Miscellaneous
8.1 TODO list
8.2 Portability
8.3 Notes on Security and Robustness
8.4 Related Software
8.5 Reference of commands