                     LLPPRRnngg PPoorrttaabbiilliittyy TTeessttiinngg aanndd IInnssttaallllaattiioonn
                         PPaattrriicckk PPoowweellll <<ppaappoowweellll@@ssddssuu..eedduu>>
                      DDeepptt.. EElleeccttrriiccaall aanndd CCoommppuutteerr EEnnggiinneeeerriinngg
                   SSaann DDiieeggoo SSttaattee UUnniivveerrssiittyy,, SSaann DDiieeggoo,, CCAA 9922118822

                                      AABBSSTTRRAACCTT
          This  is  a  detailed set of procedures for installing the LPRng
          software and testing it for portability.  The _I_n_t_r_o_d_u_c_i_t_o_n docu-
          ment  provides  a detailed description of the LPRng software and
          the _T_u_t_o_r_i_a_l document provides details on the management  proce-
          dures.   The  various  _m_a_n  pages provide details on each of the
          LPRng components.


                                    IInnttrroodduuccttiioonn
             The LPRng software is a descendent of the Berkeley LPR  soft-
          ware, with the same general functionality.  The source distribu-
          tion has the structure shown in Table 1.

                                OOrrddeerr ooff AAccttiivviittiieess
             I recommend the following steps, each of  which  is  detailed
          below.
          1.  Generate the test version of the LPRng software.
          2.  Check the various portability issues.
          3.  Check the printcap and filters for existing devices.



















          ------------------------------------------------------------------
                    configure       configuration script
                    CHANGES         change log (major changes only)
                    DOC/*           docmentation
                    INFORMATION     a short overview of LPRng
                    INSTALL         Gnu Autoconf installation information
                    TESTSUPPORT     Test LPR system
                    README          This document
                    man/*           man pages for the major components.
                    src/*           source code
                    src/Makefile    Makefile for executables
                    src/lpd         LPRng server
                    src/lpr,lpr,lprm,lpc    LPRng clients
                    src/checkpc     LPRng checkout and test
                                         TTaabbllee 11:  Distribution


     LLPPRRnngg -- PPoorrttaabbiilliittyy TTeessttiinngg aanndd IInnssttaallllaattiioonn                    11






     LLPPRRnngg PPoorrttaabbiilliittyy


By convention, in the following discussion files  are  refer-
enced with respect to the root of the LPRng distribution.

                     CCOOMMPPIILLAATTIIOONN
LPRng is written in ANSI C and uses the GNU Make program.  If
you do not have an ANSI C compiler you can try using the  unpro-
to5.shar.gz  software  in  the  UTIL  directory.   This software
valiantly tries to convert ANSI C to K&R C;  most  of  the  code
will  translate  directly  but the VARARGS routines will require
special consideration.  The GNU Make program can be obtained  by
FTP  from ftp://prep.ai.mit.edu/pub/gnu, or from many other mir-
ror sites.
The LPRng executables are the lpd server program, lpr for job
submission,  lpq  for displaying status, lprm for removing jobs,
and checkpc which performs test and checkout functions.
First, run the configure script in the distribution root  di-
rectory;  the INSTALL file contains a description of configure's
options.  The configure script will  check  for  various  system
configuration  options, and generate the various Makefiles and a
config.h file.  By default, the executables will be generated in
the src subdirectory.
To  generate executables in the $MYBIN directory, starting in
the distribution root do the following commands:
SRC=`pwd`
cd $MYBIN
$SRC/configure --srcdir=$SRC
make
The configure script is produced by the GNU autoconf and  au-
toheader  program,  using the configure.in and acconfig.h files.
If you regenerate the configure script, use  the  2.1  or  later
version  of  autoconf,  and  run the autoheader program as well.
See the autoconf documentation for details on these programs.
Once configure finishes, you can then do make TESTVERSION=YES
all or cd src; make TESTVERSION=YES all to generate the executa-
bles.
The TESTVERSION flag causes a test and debugging  version  of
the  software  to  be  generated.   This  version  will read the
LPD_CONF environment variable for the name  of  a  configuration


















     22                    LLPPRRnngg -- PPoorrttaabbiilliittyy TTeessttiinngg aanndd IInnssttaallllaattiioonn






                                                     LLPPRRnngg PPoorrttaabbiilliittyy


     file,  whose  contents  can  override the compile time defaults.
     This is a blatant  security  loophole  especially  running  SUID
     root;  see  Security Considerations later in the document.  Only
     the defaults.o file uses this flag for compilation.  After test-
     ing  the  installation  you can delete defaults.o and remake the
     distribtion.  PORTABILITY AND TESTING VERSION
        Once you have generated the test version using make  TESTVER-
     SION=YES, you should set up a user version of the LPRng software
     by using the files in the TESTSUPPORT directory.  This  requires
     the following steps.
      cd TESTSUPPORT

      setenv USER `whoami`
      setenv HOST _f_u_l_l_y _q_u_a_l_i_f_i_e_d _d_o_m_a_i_n _n_a_m_e
      setenv LPD_CONF /tmp/LPD/lpd.conf
      set path=( /tmp/LPD $path )
      OORR
      USER=`whoami`; export USER
      HOST= _f_u_l_l_y _q_u_a_l_i_f_i_e_d _d_o_m_a_i_n _n_a_m_e; export HOST
      PATH=/tmp/LPD $path:$PATH
      LPD_CONF=/tmp/LPD/lpd.conf; export LPD_CONF

      make
        The  test  files  and  executables  will  be installed in the
     /tmp/LPD directory.  This target directory  can  be  changed  by
     modifying the TESTSUPPORT/Makefile.
        During  testing,  the  environment variables should be set in
     the .cshrc or .profile initialization files.

                            PPOORRTTAABBIILLTTYY TTEESSTTIINNGG
        If your system is not listed in the README.ports file, it  is
     strongly  recommended that you check the installation for porta-
     bility.  These tests use the TESTSUPPORT version,  installed  as
     detailed in the previous section.  The executables are placed in
     /tmp/LPD.
        The checkpc program has several portablility tests  that  are
     run by using the checkpc -T flag.  You will need to be superuser
     for some of these tests; this is only for testing that the  SUID
     functionality  is working.  In the directory where you generated
     the checkpc executable, execute the following command, where _s_e_-
     _r_i_a_l is the pathname of a serial port.
      checkpc -T _s_e_r_i_a_l
     SSUUIIDD TTeesstt
        The  first test involves SUID checking.  This test can be de-
     layed until installation time,  but  must  be  done  before  in-
     stalling a production version.  If checkpc is not run as ROOT or
     as a SETUID ROOT program, this test is skipped.
        To create a SETUID ROOT checkpc program and  run  the  tests,
     carry  out the following steps.  Delete the SETUID after finish-
     ing the tests!
      cd /tmp/LPD
      su              become root
      chown root checkpc  change ownership
      chmod 4111 checkpc  make SETUID ROOT


     LLPPRRnngg -- PPoorrttaabbiilliittyy TTeessttiinngg aanndd IInnssttaallllaattiioonn                    33






     LLPPRRnngg PPoorrttaabbiilliittyy


      exit            (become regular user)
      checkpc -T _s_e_r_i_a_l   run tests
          (check test results)
      su              become root
      chmod 755 checkpc
      chown `whoami` checkpc
      exit             (become regular user)
        If the setuid test succeeds, then a success message  will  be
     printed  out.  If it fails, then rerun the test with diagnostics
     enabled as shown below and save the output to a file.   A  study
     of  the  output  should  provide  detailed information as to the
     cause of failure.
      checkpc -D9 -T _s_e_r_i_a_l
     BBIIDDIIRREECCTTIIOONNAALL PPIIPPEESS
        A bidirectional pipe is used for inter-filter  communication.
     If  this test fails, then you should enable RWSOCKETS_CFLAGS op-
     tion in the src/Makefile and regenerate rw_pipe.o.  This  option
     implements  bidirectional  pipes  by using a socket based mecha-
     nism.
     SSEERRIIAALL DDEEVVIICCEE OOPPEENN AANNDD LLOOCCKK
        The next test checks to see if the Checkwrite() and  Lock_de-
     vice()  routines  open and lock a serial device.  Device locking
     is done by using the TIOCEXCL ioctl() call.  If  locking  fails,
     set -D4 and determine which lock method is being used.
        See the LOCK_DEVS_CFLAGS variable description in src/Makefile
     and comments in src/common/lockfile.c on how to select the fall-
     back locking method.  Once selected, You will need to regenerate
     lockfile.o and the executables and reinstall them  in  the  test
     location.
     FFIILLEE OOPPEENN AANNDD LLOOCCKK
        The next set of tests check that file locking works.  If they
     fail, then try using an  alternative  locking  method  with  the
     STATFS_CFLAGS variable in the src/Makefile.  See the comments in
     src/common/lockfile.c as well.   You  will  need  to  regenerate
     lockfile.o and the executables.
     SSTTTTYY FFUUNNCCTTIIOONNSS
        The  next  test checks the stty (set serial line characteris-
     tics) capabilities.  In order to do as system independent opera-
     tions  as possible, line status is displayed using the stty com-
     mand.  You should check the output of this command to make  sure
     that the requested STTY operations did take place.
        If  a  stty  operation failes, using the checkpc -D9 flag and
     examine the diagnostic output for the cause of failure.  See the
     STTY_CFLAGS  section  of src/Makefile on how to select an alter-
     natve STTY interface function if the one selected  by  configure
     is not suitable.  You will need to regenerate stty.o and the ex-
     ecutables.
     PPRROOCCTTIITTLLEE
        The setproctitle() function modifies the  process  status  so
     that  the  ps(1)  command will display the process activity.  If
     this test fails, then you might want to see if  you  can  modify
     the src/proctitle.c code so that it works.  Otherwise, just mod-
     ify the SETPROCTITLE_CFLAGS variable in src/Makefile and  recom-
     pile.


     44                    LLPPRRnngg -- PPoorrttaabbiilliittyy TTeessttiinngg aanndd IInnssttaallllaattiioonn






                                                     LLPPRRnngg PPoorrttaabbiilliittyy


                              FFiilltteerr TTeessttiinngg
        You  should  test  the  filters for your existing printers by
     first using the test version.  You can simply copy the  existing
     printcap  entry  to the test printcap file, and modify the entry
     so that it uses the test setup directories.
        Next, try running a job through the filters, and  see  if  it
     works  correctly.  Some filters rreeqquuiirree root permissions as they
     perform operations such as opening  sockets  in  the  privileged
     port range.  If this is the case, you will probably need to read
     the warnings about running  filters  as  ROOT,  and  enable  the
     source compilation flag to allow this to be done.  You MUST read
     the warnings in the src/Makefile before this can be  done.   You
     must also use the following in the printcap file:
     :if=ROOT /bin/....
        This  has  been done deliberately to make it difficult to ig-
     nore the serious security problems this will open.
        By default, the LPD server passes files to filters by using a
     pipe.   This allows the server to monitor the progress of print-
     ing.  However, some filters require direct access  to  the  file
     for  doing  fseek  and other operations.  To allow this, set the
     :direct_read: printcap flag.

                               IInnssttaallllaattiioonn
        Once you have finished testing, you can perform a  final  in-
     stallation.  The following steps should be followed.
     1.  First,  compile  the  non-test version and install it in the
         default locations.
      rm src/default.o
      su   _m_a_y _n_e_e_d _r_o_o_t _p_e_r_m_s _t_o _i_n_s_t_a_l_l
      make install
     2.  Next, if you are performing an initial installation, a  sim-
         ple  set of lpd.conf and lpd.perms files are available.  You
         can install these by using the Makefile in the distribution.
      make default
     3.  Next,  you  should  stop the current lpd daemon and save the
         existing printcap file.  If you are installing software on a
         Sun  Microsystems Solaris system,  see the detailed descrip-
         tion in the README.solaris file  in  the  distribution.   On
         most other systems, you can do:
      ps -axu | grep lpd
      kill _l_p_d _p_i_d
     4.  If you need to, copy the new printcap file to /etc/printcap.
         Use checkpc to ensure that the current printcap file is cor-
         rect.
      cp /etc/printcap /etc/printcap.old
      checkpc
      checkpc -f _i_f _n_e_c_e_s_s_a_r_y _t_o _f_o_r_c_e _c_o_r_r_e_c_t _p_e_r_m_i_s_s_i_o_n_s
     5.  Start the lpd daemon and check its operation.
      lpd
      exit  _r_e_t_u_r_n _t_o _u_s_e_r
      lpq
     6.  Edit  the  print spooler startup commands in the appropriate
         rc.local or other startup file to use /usr/local/bin/lpd.
     7.  Reboot system to ensure that server is started correctly.


     LLPPRRnngg -- PPoorrttaabbiilliittyy TTeessttiinngg aanndd IInnssttaallllaattiioonn                    55






     LLPPRRnngg PPoorrttaabbiilliittyy


                           PPeerriiooddiicc MMaaiinntteennaannccee
        It is recommended that the checkpc program be run periodical-
     ly  to  remove  aborted  jobs and to truncate various log files.
     This can be done by putting the following entry in  the  _c_r_o_n_t_a_b
     for root.
      15 5 * * * /usr/local/lib/cleanlog
        The cleanlog script can be used to clean and/or truncate var-
     ious files.  The following is a typical script.
      #!/bin/sh
      trunc () {
          tail $1 >/tmp/$$
          cat /tmp/$$ >$1
          rm /tmp/$$
      }

      FILES="/usr/spool/lpd/log* /usr/spool/lpd/accnt"
      for i in $FILES do
          echo $i
      done





































     66                    LLPPRRnngg -- PPoorrttaabbiilliittyy TTeessttiinngg aanndd IInnssttaallllaattiioonn




