
                      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 pro-
          cedures.   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
          software,  with the same general functionality.  The source dis-
          tribution 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.
            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
          unproto5.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

          _________________________________________________________________
                    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


     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
     directory;   the   INSTALL   file   contains  a  description  of
     configure's  options.  The configure script will check for vari-
     ous  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 auto-
     header program, using the configure.in and acconfig.h files.  If
     you  regenerate  the configure script, use the 2.1 or later ver-
     sion  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 execut-
     ables.
       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
     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.
       Some  systems  such as SUNOS 4.1.1 do not have function proto-
     types  for all the system functions; you will get a large number
     of  spurious  warning  messages.   The following is a sed script
     which can strip out various warnings.
      #!/bin/sh
      # stripjunk - strip out meaningless errors
      # example: make 2>errs ; stripjunk errs
      sed \
      -e '/^gcc/d' \
      -e '/implicit dec.* `fprintf'/d' \
      -e '/implicit dec.* `bzero/d'' \
      -e '/implicit dec.* `getpeername/d'' \
      -e '/At top level:/d' \
       "$@"

                      PPOORRTTAABBIILLIITTYY AANNDD TTEESSTTIINNGG VVEERRSSIIOONN

       Once   you   have   generated  the  test  version  using  make
     TESTVERSION=YES,  you  should set up a user version of the LPRng
     software  by using the files in the TESTSUPPORT directory.  This


     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


     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 instal-
     ling  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
      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


     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


     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 mechan-
     ism.
     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_device()  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 ex-
     amine  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
     modify  the  SETPROCTITLE_CFLAGS  variable  in  src/Makefile and
     recompile.

                              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


     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


     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 need to set the
     filters  executables SUID ROOT and executable only by group dae-
     mon.
      chown root $filter
      chgrp daemon $filter
      chmod 4010 $filter

                               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.
      make default
     3.  Next,  you  should  stop the current lpd daemon and save the
         existing printcap file.
      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
         correct.
      cp /etc/printcap /etc/printcap.old
      checkpc
      checkpc -f  _i_f _n_e_c_e_s_s_a_r_y
     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.

                           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 periodically
     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 vari-
     ous files.  The following is a typical script.
      #!/bin/sh
      trunc () {
         tail $1 >/tmp/$$
         cat /tmp/$$ >$1
         rm /tmp/$$
      }


     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


      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
