1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353
|
Sendpage
What this tool does
-------------------
Sendpage is designed to speak SNPP on one end and TAP (or UCP) on the
other. It gets pages from the network via SNPP, and then uses a modem
or a direct serial connection to deliver the pages to a Paging Central
(or "paging terminal"). Sendpage requires, for modem use, that you know
your PC's access number (which is not usually advertised by your paging
provider), and you need to know the PINs of the pagers you want to deliver
pages to. All of this information is known by your paging provider.
If you ARE a paging provider, your job is much easier. ;)
Quick Start (for RPM-based Linux distro)
----------------------------------------
Why are you reading this README? Just run "rpmbuild -ta inkscape-*.tar.gz"
There is a .spec file included for easy building. :) I've only tested it
on SuSE 9.2, so please send me patches if you uncover problems with other
distros.
Quick Start (for non-RPM Linux distro)
--------------------------------------
Requirements.
- Net::SNPP (part of the libnet Perl module bundle)
- Device::SerialPort version 1.02+ (or Win32::SerialPort, untested)
- MailTools (provides Mail::Send)
Installation.
- run the following commands:
perl Makefile.PL
make
make install
- copy 'sendpage.cf' into /etc, and edit to your needs
- copy 'email2page.conf' into /etc, and edit to your needs
- copy 'snpp.conf' into /etc, and edit to your needs
- if you use SysV-style init scripts, you can use "sendpage.init"
to start and stop sendpage. Copy it to where you keep your rc
files.
- create the user "sendpage"
- figure out which group ID can write to your locks directory
(usually "uucp" can write in "/var/lock")
- figure out which group ID can write to your modem device
(usually "tty" can write to "/dev/ttyS0")
- make the queue area:
mkdir -p /var/spool/sendpage
chown sendpage /var/spool/sendpage
chmod og-rwx /var/spool/sendpage
- start the sendpage daemon as the root user (it will change
user id to 'sendpage'):
sendpage -bd
- go check your /var/log/messages for the syslog line saying
that sendpage started up:
starting Queue Manager and SNPP listener (sendpage vX.X.X)
- you can also use the "sendpage.init" file for SysV-style init
script control.
- make sure you have an entry in /etc/services for "snpp", which
should be port 444.
Sending a page.
- run the "snpp" command to send yourself a test page:
snpp -d -f me@yourdomain.org -m 'hi there!' yourPIN@yourPC
- if you want to write pages directly to the paging queue instead of
using SNPP, you can use "sendpage" itself, but you must be root:
sendpage -f me@place.org -m 'hello again!' yourPIN@yourPC
the sendpage daemon must be running for this to actually be delivered.
Long Version
------------
Sendpage (the C program) was originally written in 1995 almost entirely
by Mark Fullmer. Version "7" was when I became aware of it picked up
the code, since Mark didn't want to maintain it any more. I developed
a "configure" script to make compiling easier, started working on merging
some features that other people had written, and stomping out a few bugs.
I released a series called "0.8", which still had a bunch of problems,
but seemed to mostly work for most people. Then after not looking at the C
code for about a year, it was getting rather dusty. I was about to
work on porting it up to RedHat 6.1 and realized it would be easier to
redesign it from scratch. I decided to use Perl because of all the great
modules I could use to help me get my job done. And then I could spread
the blame around when things didn't work right. ;)
And at this point I'd like to apologize here for my sloppy Perl modules.
I was new to writing *modules* under Perl, so I fear that I've violated
module and CPAN specs left and right. I will try to correct any of these
problems as I learn about them. My final goal is to produce a set of
modules that would be useful to any other packages that need to send
pages directly, and could be installed via CPAN.
To get it started you'll need the following Perl modules installed:
- a serial port module. Either
Device::SerialPort (for POSIX (unix))
-or-
Win32::SerialPort (for Windoze)
- Mail::MailTools
- Net::SNPP
You can get these from http://cpan.perl.org/
Now, build sendpage itself. Right now, just do:
cd sendpage-X.X.X
perl Makefile.PL
make
make install
to install this package. The important man page (sendpage's) is done.
The others are mostly just overviews. I need to finish those. If you
want to put the files somewhere besides where Perl wants to put them,
you can always create the Makefile is "perl Makefile.PL PREFIX=/usr/local"
or where ever you want the files to be forced to go.
Make sure you create a sendpage user, and identify the group who has
write access to /var/lock, and the group who has write access to your
modem device.
Once that's working, take a look at "sendpage.cf", and configure it
for your modem, paging central, etc. Turn on the debugging if you're
interested. Note that "sendpage.cf" needs to live in /etc, or where ever
you run "sendpage -C" with. Please note, that you can safely ignore any
"Attempt to free unreferenced scalar." messages you get while shutting
down sendpage if you have debugging turned on. This is just Perl
complaining about the paging centrals for some reason. Hopefully these
should be gone now.
Install and edit the "email2page.conf" file for the email-to-page
converting tool. Documentation is in the conf file for that one right now.
Install and edit the "snpp.conf" file for the snpp's default
server. Documentation is in the conf file for that one right now.
Now there is the "sendpage" daemon itself. Run (as root) the command:
sendpage -bd
to start up the daemon mode. (Make sure that "sendpage" is in the PATH
for the root user.) The SNPP server connections and Paging Centrals will
lose root privs when the fork, so that should be safe. "sendpage -bs" will
stop sendpage. The file "sendpage.init" has been included to run it as a
SysV-style init script, which takes "start" and "stop" arguments. This
script assumes that sendpage is installed in /usr/bin, so be sure to
change it if you need to.
To put a page into the queue, run "snpp RECIP" where RECIP is either a
valid alias "recip" section in /etc/sendpage.cf, or has the form PIN@PC,
where the PC is a valid "pc" section in /etc/sendpage.cf. It will deliver
directly to the named PIN. "snpp" will read from STDIN for the message,
unless you use the '-m' flag. To use "snpp" from other networked machines,
you'll need to edit sendpage.cf to bind snpp to "0.0.0.0" or some other
network interface, and then use "snpp -s SERVER" from the remote client.
Be sure to read and set at least one "snpp-acl" line so that your remote
machine will have permission to connect to the SNPP server.
To force a queue run immediately, run (as root) "sendpage -q". If you have
debugging turned on, it should be flooding your syslog with lots of fun
information while delivering the pages.
Look in the "docs" and "examples" directories for various misc information
files, including the TAP specifications, the SNPP RFC, and a list of
the known paging centrals in the file "PagingCentrals.txt". See if the
PCs for your area are listed. If not, and you locate them, you should
email them to me, and I'll update this list. There is also a searchable
database of these available at the website below. For an example
of how to set up sendpage as an email gateway, read "sendmail.txt".
For an example of how to make a web page to send pages, look at the
"sendpage.php" PHP script. Also in this directory is the beginnings of
my official "Sendpage Manual" in LyX format.
Logging
-------
By default, sendpage uses syslog facility "daemon" to do it's reporting,
with all messages set to "info" or higher. This should be seen by any
sanely configured syslog daemon.
For myself, I wanted to keep my sendpage syslogs out of my general syslog
file ("/var/log/messages"), and I wanted debugging to be reported at
the syslog level "debug". I changed the facility to "local6", and the
minimum level to "debug" with the following lines in my sendpage.cf:
syslog-facility = local6
syslog-minlevel = debug
and changed my /etc/syslog.conf looks like this:
*.info;mail.none;news.none;authpriv.none;local6.none /var/log/messages
local6.* /var/log/sendpage
local6.=debug /var/log/sendpage.debug
local6.info /var/log/sendpage.info
This way "messages" doesn't get anything from "local6" (sendpage), and I
can watch the sendpage output in three ways: either everything going to
local6 ("/var/log/sendpage"), JUST the stuff *at* the "debug" level
("/var/log/sendpage.debug"), or everything "info" and higher
("/var/log/sendpage.info").
Compatibility
-------------
Linux: This tool (and Device::SerialPort) was written and tested under
Linux. There really shouldn't be any compatibility issues under
Linux.
Solaris: Some headers under Solaris don't behave very well, so I had
to define "__sparc" explicitly in my patch to Device::SerialPort.
Also, under Solaris, many of the "make test" tests for
Device::SerialPort seem to hang and/or fail. Most of these
seem safe to ignore as far as using sendpage with Device::SerialPort,
as the test failures seem to be with timings and/or flushes.
Most of that is unreliable anyway under Linux, so sendpage has
already worked around these bugs.
From the following URL:
http://www.stokely.com/unix.serial.port.resources/tutorials.html
DTR Delay Problems: By default, Suns have a three second
delay in toggling dtr. If your Sun has a zs serial port you
can set the variable default_dtrlow to control the number of
seconds of the delay. If the variable is set to zero, dtr
can be toggled many times a second. For example, in
/etc/system add the line "set zs:default_dtrlow=1" to have
a 1 second delay.
If your workstation has an se serial port, the /etc/system
line should be "set se:se_default_dtrlow = 1". However, in
initial versions of the se driver, the delay was the value
of (se_default_dtrlow + 1) seconds. If you have this version
of the se driver, don't set the value to -1 in /etc/system or
the port will hang on open. If you need to toggle dtr quickly,
you can still set the value to -1 after the terminal is
opened by using adb to set the variable manually.
All this is Sun bugid 4230310, fixed by patch 105924-09 or
higher. The patch makes se_default_dtrlow behave like
default_dtrlow (i.e. setting se_default_dtrlow to 0 will allow
rapid toggling of dtr instead of once per second).
So, since I have zs serial ports on my Sun, I added the line:
set zs:default_dtrlow=0
so I could toggle the DTR rapidly.
Also, I've seen trouble using Syslog correctly under Solaris.
Once again, this appears to be Perl's fault. If it breaks
("Your vendor has not defined the Sys::Syslog macro _PATH_LOG")
then just edit KeesLog.pm and remove the calls to "setlogsock".
AIX: Tested with 4.3.2, and works fine, some modem lines don't work.
*BSD: Tested. Carrier detection works after Sendpage 0.9.13.
HPUX: Untested so far...
SCO7: Install notes from Pat Gunn:
Removed system perl first (MUST happen before installing skunkperl
or perl will become messed up)
Then installed skunkperl from skunkware
(stage.caldera.com/uw7/Packages/)
Used CPAN module to upgrade prerequisites (didn't allow it to
rebuild Perl itself. I have GCC and other gnu tools installed)
Installed Device::Serialport (after these mods, it might work through
CPAN, but you're better off doing it by hand so you can troubleshoot
problems more easily)
Installed sendpage.
Created sendpage user, created /var/lock, set its group to uucp and
changed its mode to 775, created sendpage spool directory, configured
sendpage.conf and snpp.conf. Note that syslog does not appear to work
with sendpage's logging component, so it's probably better to log to
stderr. Change snpp.conf accordingly. It might be possible to fix
this with some tinkering, but I'm not interested enough to take the
time.
The modem device on my system (serial port A) is /dev/term/00m,
although I made a symlink to there from /dev/modem, and put
/dev/modem in the configfile.
Porting Device::SerialPort
--------------------------
If you're trying to get Device::SerialPort to work on an untested platform,
please take a look at "configure.ac" for the list of files being included.
Basically, SerialPort.pm needs the following constants from .h files to
operate correctly:
Must have these:
TIOCM_RTS
TIOCM_DTR
TIOCMBIS
TIOCMBIC
TIOCMGET
Optional: I have only found these on OpenBSD (and are required for OpenBSD):
TIOCSDTR
TIOCCDTR
Optional: I have only found *both* of these under Linux:
TIOCINQ
TIOCOUTQ
Optional: I have only found this one under Linux:
TIOCSERGETLSR
Once you get SerialPort.pm running happily (you can set $DEBUG=1
near the top), try modifying (from the sendpage package) the script
"modemtest" in the "examples" directory to use your serial port with
a modem attached. This script will try to examine all the possible
settings for your vendor's serial port, and will try to talk to the
modem using Device::SerialPort. If you can get this script talking to
the modem, sendpage should operate just fine.
Misc
----
The TODO file lists a large number of things I still want to have done.
For further information, check out the sendpage web site at:
http://sendpage.org/
For CVS updates, check out the sourceforge project at:
http://sourceforge.net/projects/sendpage
Thanks for using sendpage!
-Kees Cook
kees@outflux.net
# $Id: README 316 2008-01-03 20:21:19Z keescook $
|