|
RestrictQ
RestrictQ for AIX
Table of contents:
I Restrictq product description
II Will restrictq work for me?
III Installing restrictq
IV Configuring restrictq
V Using restrictq - diagnosing any trouble
VI 30-day evaluation copy
VII Pricing and support information
I Restrictq Product Description
Restrictq is a filter which can be inserted into the AIX virtual
printer subsystem on any system running AIX 3.2, 4.1, 4.2, 4.3,
and 5.1. Its function is to give the system administrator
control of whether or not specific users or groups of users are
allowed to print to a certain print queue. This can prevent
problems such as reports being submitted to print queues which
contain checks or expensive forms. It can also be useful to
prevent users or groups that typically print large jobs from
sending them to slower printers or restricting users to printing
to printers in their department, building, city, etc.
II Will Restrictq work for me?
Since restrictq is inserted as a filter into a virtual printer, a
prerequisite to using restrictq for a print queue is that the
queue in question must have an associated virtual printer. This
means restrictq will not work for standard filtering remote queues
on AIX 3.2.x, it will not work on queues which use PSF for AIX. It
will work for locally attached serial and parallel printers, for
remote queues on AIX 4.X, HP JetDirect attached queues, Lexmark
MarkNet and LexLink queues, and network queues using TCPrint from
LAIX. To check whether or not restrictq will work for a queue on
your system, run the command "lsvirprt" and if a print
queue shows up on the list of queues then restrictq will work with it.
III Install restrictq
Restrictq consists of several files archived together in a single
tar file. You may receive this tar file on a floppy diskette, or via
modem or ftp. If you receive the software on diskette, simply extract
the file from the diskette as follows:
tar -xvf /dev/fd0
If you received the files via another means such as from our web site,
the tar file will be stored on your system in the location you have
placed it during retrieval. For example, if the file was downloaded
into your /tmp filesystem from our web site and the file is named
restrict.tar, you would extract the file as follows:
tar -xvf /tmp/restrict.tar
In either event, the files are placed into the appropriate destination
location by full path name.
The files extracted from the tar are explained below:
/usr/lpp/restrictq/bin/restrictq The filter program that
determines if a user is or
is not allowed to print to
a particular queue.
/usr/lpp/restrictq/bin/parseconfig Parses a restrictq config
file to ensure that it is
syntactically correct.
/usr/lpp/restrictq/data/sample.config A sample configuration file
that shows how to allow or
disallow access to a print
queue to users or groups of
users.
/usr/lpp/restrictq/restrictq.readme The newest documentation
for the restrictq filter.
If you are installing a 30-day evaluation copy of restrictq,
remember that if you don't register the software then thirty
days from the time you first use the software, it will cease
to deny anyone access to the queue and the queue will continue
to function as it did before the installation of restrictq.
IV Configuring restrictq
Once restrictq has been installed onto an AIX system the system
there are two steps that must be performed before restrictq can
be used to perform restrictions to queue access:
1) Configure your existing functional print queue to
call restrictq as part of its processing.
2) Build a configuration file for the print queue
1) Calling restrictq from a virtual printer
Restrictq operates as a filter called by AIX's piobe facility.
First you will need to decide on a few options that will
passed to restrictq as command-line arguments. All of the
options can be individually included or left out. The list of
allowed parameter flags and their function are detailed below:
-c CopyDir Copies print jobs REJECTED from printing to
this queue to the directory specified by
CopyDir. If neither -c nor -C is used,
rejected print jobs are simply discarded.
-C CopyDir Copies ALL print jobs to the directory specified
by CopyDir. Useful to archive copies of print
jobs. If neither -c nor -C is used, rejected
print jobs are simply discarded and authorized
print jobs are allowed to print without being
copied.
-d # Controls the level of detail in the messages written
to the log file. The default value if -d is not
specified is 0. The recognized values are:
-d0 Write brief message to log for rejected jobs
-d1 Write brief message to log for each job
-d2 More detail about what restrictq is doing
-d3 Complete detail used for diagnosing problems
-f DataFile Used to specify which file contains the information
about which users are or are not allowed to print to
this particular print queue. If -f DataFile option
is NOT given, the default configuration file is
/usr/lpp/restrictq/data/QNAME.config
The -f option is useful if you would like multiple
print queues to share a common configuration file.
Be sure the DataFile you specify is readable by all
users.
-l LogFile Specifies where the logging output is sent to. If
this option is not given, logging output is
discarded. If you wish to get debugging output by
using -d# you must specify where to place the output
with -l LogFile. BE SURE THAT THE PERMISSIONS ON
YOUR LOGFILE ARE SUCH THAT ANYONE CAN WRITE TO IT.
-m Sends user that submitted the print job an e-mail
message if their print job is rejected. The mail
message includes the location of where a copy of
their print job can be found if the -c or -C flag
was used. If -m flag is not present, the user
receives no notification that their print job is
not going to print.
-M MailFile E-mails the user the contents of MailFile when
their print job is rejected. This allows a system
administrator to customize what the user sees if
their job is rejected, giving them control over
whether or not the user even knows a copy of their
job was saved if the -c or -C option was used.
The MailFile may also contain certain macros that
will be expanded by restrictq:
%COPY% File where job copy is stored
%JOB% The print job number
%QNAME% The print queue name
%TITLE% The print job title
%USER% The user who submitted the job
The options may be provided in any order and options which take a
parameter do not care whether there is a space between the flag and
the parameter (eg -cCopyDir is equivalent to -c CopyDir). However,
options requiring a parameter MUST have that parameter. For example,
using -c without giving a CopyDir is not a valid command.
Certain combinations of flags do not make sense (such as using both
-c AND -C, or using -m AND -M) but are accepted by restrictq.
The order in which flags appear is irrelevant.
To change your virtual printer to call restrictq you
can do either of the following two actions:
lsvirprt
Select the queue
f=g
fg=/usr/lpp/restrictq/bin/restrictq
or
chvirprt -q <qname> -d <devicename> -a "f=g" -a \
fg="/usr/lpp/restrictq/bin/restrictq "
The above two methods perform the exact same function.
As an example suppose you have a print queue configured in
/etc/qconfig named "pcl" that prints to a device
lp0. I want to use restrictq and I want logging to go to /tmp/lp0
with a verbosity level of 2. I don't want to make copies of
rejected jobs into any directory but I want to send users the default
mail message when their job is rejected.
I could run:
lsvirprt
Select the number corresponding to "pcl" from the list
f=g
fg=/usr/lpp/restrictq/bin/restrictq -l /tmp/lp0 -d2 -m
or:
chvirprt -q pcl -d lp0 -a "f=g" -a \
"fg=/usr/lpp/restrictq/bin/restrictq -l/tmp/lp0 -d2 -m"
If I wanted to make copies of rejected jobs to an EXISTING
DIRECTORY /tmp/pcl_rejected_jobs I could change the fg= in
either of the above two commands to:
fg=/usr/lpp/restrictq/bin/restrictq -l/tmp/lp0 -d2 -m -c/tmp/pcl_rejected_jobs
If I didn't want any logging I could change the LOGFILE name from
/tmp/lp0 to /dev/null, or simply leave out the -l and use the default
value of /dev/null.
If after making the above changes, your print queue shows a status
of UNKNOWN when you do an lpstat, or your queues show READY but
your print jobs aren't printing, you will need to stop and restart
the AIX qdaemon. This is not a problem with restrictq but rather a
limitation of the AIX qdaemon. To stop and restart the qdaemon, run
the command:
stopsrc -cs qdaemon ; startsrc -s qdaemon
This will not affect other print jobs currently running on your
system. A fix for the UNKNOWN queue status is available from IBM:
AIX 3.2.5 IX62875
AIX 4.1.X IX62876
AIX 4.2.X IX62877
If you wish to remove restrictq from use - use either of the
two methods above to blank the f attribute: f=
2) CREATING A CONFIGURATION FILE FOR RESTRICTQ
After completing step one, your queue will continue to function
normally without a restrictq data file... All jobs queued to the
queue will be allowed to be printed. In order for restrictq to
do any useful work, a configuration file needs to be created for
the queue telling restrictq exactly which users or groups of users
are allowed or not allowed to submit jobs to this print queue.
The configuration file should be placed into the directory:
/usr/lpp/restrictq/data and the file name should be of the format
queuename.config or it will not be used by restrictq unless you
specify -f ConfigFileName option for restrictq. If you wish to
have multiple print queues share a common config file, the -f flag
may be helpful.
For example, in step 1 a queue named "pcl" was configured to use
restrictq so the default configuration file for this queue would be:
/usr/lpp/restrictq/data/pcl.config
A sample file /usr/lpp/restrictq/data/sample.config is provided
to show the correct allowed syntax of the configuration file.
The allowable lines in the .config file are:
1) Blank lines
2) Comment lines which being with a #
3) Lines containing a user name, the word user, and a + or a -
4) Lines containing a group name, the word group, and a + or a -
5) Lines containing the word "default" and a + or a -
1) Blank lines are ignored by the restrictq program
2) Comment lines are ignored by the restrictq program
3) Lines containing a user name, the word user, and a + or a -
are used to determine if that specific user is allowed to
print to this queue. For example, the line:
user root +
Says the user root is allowed to print to this queue. The line:
user root -
Says the user root is not allowed to print to this queue.
The order of the 3 fields is not important. The following
lines all have equivalent meaning:
user root +
user + root
root + user
root user +
+ user root
+ root user
If a user is specifically allowed or denied access by a user
line in the .config file that line will take precedence over
a group or default entry in the configuration file as the
most specific match for a user is used.
User lines may also contain system names or domain names
such as:
user root@headquarters +
user spy@head.quarters.com -
and it may also contain wildcards:
group financ* +
user b?b -
user roo*@remote.site -
Note that an entry without a wildcard takes precedence over
any entry without a wildcard in it. For example, if your config
file contains these two lines:
user roo? +
user root -
user root would not be allowed to print.
4) Lines containg the word group, a group name, and a + or a -
are used to determine if users in that specific group are
allowed to print to this queue. For example, the line:
group system +
States that users in the group system are allowed to print
to this queue, UNLESS they are specifically restricted from
doing so by a user entry for their specific user name or a
wildcard matching their user name. Again, the most specific
matching entry from the configuration file is used. A user
entry takes precedence over a group entry which in turn takes
precedence over a default entry. Only a user's primary group
is used in the check. For example, if you run the command "id root"
you will see the output:
uid=0(root) gid=0(system) groups=2(bin),3(sys),7(security) ...
So only group lines regarding "system" will affect root's
ability to print. This avoids any conflicts that arise if a
user is a member of two groups, one of which is allowed to
print and one of which is not. Using user entries in the
.config file or changing a user's primary group, it is still
possible to achieve any granularity of restriction needed.
When print jobs are received from a remote system restrictq has no
means to determine what groups a user is a member of on the other
system and perhaps the other system does not even have the concept
of a group if the client is not a UNIX system.
5) Lines containing the word "default" and a + or a - are used
to determine whether or not users who don't have a user or a
group line elsewhere in the .config file are allowed to print.
If the .config file contains the entry:
default -
then users not specifically given access to print to this queue
with either a user or a group line containing a + elsewhere in
the .config file will not be allowed to print to this queue. If
a "default" entry does NOT exist and a user or their primary
group is not specifically mentioned in another line of the
config file, then the user is allowed to print. In other words
if "default -" isn't added to the config file, then it is
assumed users are allowed to print unless you deny them or their
primary group.
Using the above five rules we can construct the config file below:
default +
group system -
user root +
The order of the three lines within the .config file is not important
but from these three lines we can gather a lot of information about
the access restrictions placed on this particular queue:
1) Users in the group "system" are not allowed to print
2) Users not in the group "system" are allowed to print
3) User "root" though a member of the "system" group is allowed
to print.
The sample configuration file /usr/lpp/restrictq/data/sample.config
shows many examples of restricting queue access.
Be sure that the owner and group of your configuration file are
root and printq respectively and that your configuration file's
permissions are such that it can be updated by root and/or users in
the group printq, and may be read by all users. Permissions of
644 and owner and group of root and printq are recommended. For
example, an ls -l of our newly created pcl.config file should
look something like:
-rw-r--r-- 1 root printq 85 Oct 26 19:46 qname.config
If it does not:
chown root:printq /usr/lpp/restrictq/data/FILENAME
If only root should be able to update the .config file:
chmod 644 /usr/lpp/restrictq/data/FILENAME
Or if users in the printq group should be able to administer
changes to the .config file:
chmod 664 /usr/lpp/restrictq/data/FILENAME
After constructing your config file as desired, you may wish to run
/usr/lpp/restrictq/bin/parseconfig qname.config
The config file parser will examine your config file and point out
any syntax errors or entries it does not understand. This is a good
way to ensure the contents of your config file are intact. The
parseconfig utility can also be used in a number of ways:
Shows and interprets all entries within the config file
parseconfig /usr/lpp/restrictq/data/qname.config
Show only lines with syntax errors, discard information about
valid entries:
parseconfig /usr/lpp/restrictq/data/qname.config 1>/dev/null
Show only valid entries in the config file:
parseconfig /usr/lpp/restrictq/data/qname.config 2>/dev/null
Put good entries into one file and invalid entries into another:
parseconfig /usr/lpp/restrictq/data/qname.config 1>file1 2>file2
Also note that if a user's print job is rejected by restrictq an
e-mail message will be delivered to the user informing them that
their job was rejected from the queue if -m or -M flag is used.
The mail message comes from the user running restrictq. For remote
clients, this will be from the user "lpd" but if the job is submitted
by a local user, the mail message will come from the user to themselves.
This can be changed so that the mail comes from whichever effective user
runs the program. For example:
chown daemon /usr/lpp/restrictq/bin/restrictq
chmod u+s /usr/lpp/restrictq/bin/restrictq
Will cause the mail message to come from "daemon" instead. This has
however not been implemented by default in order to avoid any unforeseen
security questions that may arise by allowing a user to run a program
as though they were another user.
V USING RESTRICTQ
Once the queue has been created and restrictq set up as a filter
but before a .config file has been created, all jobs sent to the
queue will print as before, but a log entry will be made into
the restrictq log file if -l LogFile option is used.
Suppose a job is queued to the queue configured in step IV:
enq -Ppcl /etc/motd
The print job prints to the printer and the logfile /tmp/lp0
gets an entry similar to the following appended to it (assuming that
your VERBOSITY level is set to 2 in your virtual printer.
-----------------------------------------------------------------------------
Job 162: /etc/motd submitted by root to queue pcl
restrictq: Unable to read data file /usr/lpp/restrictq/data/pcl.config
Allowing anyone to print.
Sending data to the printer
-----------------------------------------------------------------------------
If such an entry does not appear in your log, ensure that the queue is
READY and not DOWN and that permissions on the logfile are such that
anyone can write to it.
Now I create a config file /usr/lpp/restrictq/data/pcl.config that
looks like this:
# This is the restrictq config file for
# the queue pcl that prints to lp0
default -
group system +
user root -
And submit the job again:
enq -Ppcl /etc/motd
The log file entry now looks like this:
-----------------------------------------------------------------------------
Job 163: /etc/motd submitted by root to queue pcl
The primary group of root is system
By default users are not allowed to print
Found group system is allowed to print
User root not allowed to print
Sent mail to user root warning they can't print to this queue
-----------------------------------------------------------------------------
Three relevant pieces of information are:
1) By default users are NOT allowed to print
2) Users in the group system are allowed to print
3) User root is not allowed to print
Since the job was submitted as root, the user root line is the most
specific match for the person who submitted the job and therefore
the job is rejected. Any user in the group system other than
root would have been able to print since no user-specific entry
preventing them from doing so.
The following mail message was delivered to root:
Message 1:
From root Sat Nov 9 16:37:35 1996
Date: Sat, 9 Nov 1996 16:37:34 -0600
From: root
To: root
restrictq: You do not have permission to send jobs to the print
queue pcl
Next, leaving the configuration file as is, changing the virtual
printer filter entry using lsvirprt to set
fg = /usr/lpp/restrictq/bin/restrictq -l /tmp/lp0 -c /tmp -m -d2
So that rejected jobs will be copied to /tmp, and then resubmitting
the same job:
enq -Ppcl /etc/motd
The log entry looks very similar:
-----------------------------------------------------------------------------
Job 164: /etc/motd submitted by root to queue pcl
The primary group of root is system
Found by default users are allowed to print
Found group system is allowed to print
User root not allowed to print
Sent mail to user root warning they can't print to this queue
Storing job copy to /tmp/164.root_motd
-----------------------------------------------------------------------------
but a copy of the job queued is stored in /tmp/164.root_motd which is
the print job number, a period, the userid of the user that submitted
the job, an underscore, and the original filename that was queued up
(with the leading full path removed).
This isn't very useful with /etc/motd, but if this was a report
that took hours to generate or could not easily be reproduced,
the user would be mailed a message telling me where my rejected job
could be found:
Message 1:
From root Sat Nov 9 16:42:43 1996
Date: Sat, 9 Nov 1996 16:42:43 -0600
From: root
To: root
restrictq: You do not have permission to send jobs to the print queue pcl
A copy of the job will be stored in /tmp/164.root_motd
Administrators should make sure that:
1) Filesystem you are sending job copies to have permission so
that anyone can write a job copy to that directory when a
queued job gets rejected.
2) The filesystem containing the directory you place your copies
into does not fill with rejected jobs. An administrator could
use a utility such as find to remove old entries from the copy
directory:
find /copy/directory -mtime +30 -exec rm {} \;
Would remove all files older than 30 days from /copy/directory.
Be sure nothing else resides in your copy directory that should
not be removed. For this reason, a directory dedicated exclusively
for copied print jobs is desirable.
VI 30-day evaluation copy
A 30-day evaluation copy of restrictq is available. It is a fully functional
version of the software but 30-days from the time the first print job is
sent to a restrictq queue, the software ceases to prevent restricted users
from printing to the queue, making the queue operate as it did before the
installation of restrictq. The 30-day free evaluation copy is a great
way to try out restrictq to see if it meets your specific needs without
cost or obligation. This 30-day evaluation copy may be freely distributed
to anyone. Registered copies of the software (those not having a 30-day
expiration period) may not be distributed outside of the purchaser's company
or organization. See terms and licensing information for full details. If
you purchase Restrictq simply extract the tar archive of the registered copy
to replace the evaluation copy. No further reconfiguraton is required. The
Restrictq software will continue to function without change.
VII Pricing and support information
Restrictq is available for $199. This price is for site-wide access meaning
that the software can be installed on any system within your company or
organization without additional charge. Reseller inquiries regarding
volume discounts are welcome. The software is backed by a 90-day money back
guarantee however, our liability shall not exceed the purchase price of the
software. Please see enclosed licensing agreement for full details. To
order submit payment to:
LAIX Software Consulting
PO Box 1001
Derby, KS 67037-1001
Orders within the U.S. may be made by faxing a purchase order to:
800-558-5249
Or you may order online
LAIX Software Consulting is not affiliated with IBM.
AIX is a registered trademark of IBM Corporation
LAIX Software Consulting
(800) 558-LAIX
PO Box 1001 Derby, KS 67037-1001
laixsoft@flash.net
http://www.flash.net/~laixsoft
Terms and licensing information for Restrictq for AIX
Important: Read this before using the product.
Acceptance:
Use of this product indicates acceptance of the licensing terms
outlined below:
Rights:
The software contained herein is subject to a "site-wide" licensing agreement.
Purchase of this product constitutes the owner's right to copy and to use the
product on any system within the purchaser's company or organization regardless
of location, but not to distribute the product outside of that organization.
The product may not be transferred in possession to another company or
organization. You may not sub-license or lease this product to another company
or organization. The product may be modified or customized by the owner, or
used by the owner in a manner other than that described in the documentation.
The registered version of this software in its original or in a modified state,
may not be transferred, sold, or used in whole or in part outside of the
purchasing organization or company. Diskettes labeled with "30-day evaluation
copy" which actually contain the 30-day evaluation version of this software may
be freely distributed.
Warranty:
The software is included under a limited warranty. LAIX Software Consulting
warrants for a period of ninety (90) days from the date of purchase that the
diskette on which the software is recorded and the software is free of defects
and will function substantially as documented in the enclosed documentation.
Limitation on Liability:
LAIX Software Consulting assumes no liability for damages, loss of profit, loss
of data or information of any kind or for consequential, special, indirect,
incidental, punitive, or other damages caused by the use of this product.
Should the owner find that the product does not function as described in the
documentation, the product may be returned within a period of ninety (90) days
of purchase for a full refund of the purchase price. Upon request of a refund,
the purchasers agrees to destroy or return all copies of the software in their
company or organization's possession.
Support:
Technical assistance with the installation, configuration, and usage of the
enclosed software shall be free of charge for a period of thirty (30) days
from the date of purchase. Requests for technical assistance may be submitted
by telephone or fax to (800) 558-LAIX or by e-mail to laixsoft@flash.net.
No response time criteria is guaranteed but LAIX Software Consulting will do its
best to assist in a timely fashion. Support for this product may be withdrawn
at any time after 30 days from the date of purchase.
Trademarks:
AIX is a registered trademark of IBM Corporation
LAIX Software Consulting has no affiliation with IBM Corporation.
|
