Task:	Printing (both client and server)
Group:	toby,neilb,johnb
Stage:	1

Description

An infrastructure for print servers and clients.

The aim of the DICE Printing Group is to investigate and develop the printing infrastructure for the new divisional computing environment. This involves adapting and improving the system currently in place throughout the three Informatics sites and implementing it division wide. The purpose of this report is to identify, plan and prioritise the work that will be required.

Report changes

2002-04-01

Changed estimated completion date to May 2002

2002-04-01

Added completed action for installing sybies.inf (print1.inf) as DICE 7.1 machine and new action for installing this as test print server

2002-03-13

Changed section relating to Actions to include conclusions on proposed authorisation system and also initial LDAP schema. Also added action for writing printcap interface program

2002-03-06

Added action item for Neil.

2002-03-04

Added further details on ongoing kerberos/LPRng and LDAP schema investigations.

2002-02-18

Added brief details under "Further Details on Actions" section summarising ongoing work in relation to LDAP schema and authorisation investigations.

2002-02-15

Added two actions resulting from discussions at 5/2 meeting.

Issues

All three sites within Informatics (referred to in this report as AI, CS and CogSci) use essentially the same printing system, with minor variations at each site. The print client and server software in use is LPRng, which is "an enhanced, extended, and portable implementation of the Berkeley LPR print spooler functionality." See http://www.lprng.com/ for more information. The version of this software currently used across Informatics is 3.6.12.

The current system based around LPRng has proved to be flexible, reliable and robust throughout the division and, with a little adaptation, will be used for the new printing infrastructure. As part of this initial implementation, we intend to upgrade to the latest version of LPRng (currently 3.8.5), with the option of falling back to the version currently in use should insurmountable problems arise.

For ease of maintenance and security, we will put all printers and print servers on the same subnet. This will be a new private DICE network, carried across VLANs at AI and CogSci. Print servers will have an additional interface onto a local subnet and will provide the only route from the other Informatics networks onto the new printing subnet.

There will be at least one print server located at each site and these servers will spool jobs for printers at that site. It will be possible to print to all Informatics printers from all sites - the correct print server to use for each individual printer will be determined dynamically. We currently estimate that there will be two print servers at CS, one at CogSci and two at AI (one each at South Bridge and Forrest Hill) although this can be revised if necessary. These machines will be DICE Linux machines.

The printing setup on legacy systems will need to be modified so that it sends jobs via the new print servers. In an ideal world we would maintain the legacy printing system as it is, keeping it separate from the DICE system. This is not possible however, due to the difficulties involved with more than one print server spooling to the same printer.

All Informatics print queues will be allocated a logical name, indicating site and location. It will be left up to the individual sites on whether to implement this for legacy systems.

Windows printing will remain under legacy systems for the moment. Within Informatics currently, all PC printing is done through samba servers hosted at the various sites - this basically calls the appropriate LPRng commands on behalf of the PC client.

Mac printing will need to be modified to print via the new DICE print servers - Mac users at CogSci currently print using Appletalk, completely bypassing LPRng. Appletalk networks will not be available under DICE. There are no Macs in use at CS and only one at AI, which will be gone by the time DICE is implemented.

It is a goal of the printing group that it will be possible under DICE to print to Informatics printers from all platforms that can print to lpd compatible print servers. We see no reason why this cannot be achieved.

The first stage of implementation is to obtain a DICE machine with LDAP and Kerberos support and set this up as a test print server on the new printing subnet, using the latest LPRng implementation. We will then investigate configurations for client machines in both DICE and legacy worlds. This stage will allow us to identify parts of the printing setup which do not function correctly under the new infrastructure. We expect to encounter the following fundamental major issues at this stage:

• The most recent version of LPRng is version 3.8.19. We intend to upgrade to this distribution as part of the initial implementation.
• We will need to develop a way of distributing printcap files to client machines. Ideally we would like to use LDAP for this purpose, but this will need to be investigated further. There is currently no LDAP schema defined for LPRng printcap files, but we believe that we will be able to implement a solution using LDAP. Currently printcap files in CS and AI are distributed using Hesiod, while CogSci has one central printcap file, visible to all machines.
• Print servers will need to access the resources of other machines in the LCFG database. Under LCFG currently, a print server discovers what printers it will be hosting by scanning through the LCFG database looking for printers that say they have this machine as their print server. We do not envisage this situation continuing in the DICE world (it seems more logical for this information to be associated directly with the server). However, one area that necessitates this information being available to the print server is that of the server determining the format and ppd used by the printer (e.g. What sort of printer is it - postscript or something else?) This information logically belongs in the LCFG entry for the printer itself. This requires that support for "spanning maps" be available under LCFG.
• Sending jobs to print queues served at other sites should also be considered here. In the current system at AI and CS, a lookup in the hesiod database is performed to find which print server runs the print queue for the requested printer. We hope to adopt a similar scheme, using LDAP instead of hesiod.
• Printing permissions are currently managed by Unix username, group and netgroup. We will have to ensure that this works under the new system. Getting LPRng to work with basic Kerberos authentication should be relatively trivial, but using groups and netgroups will require more work.
• The new printing subnet will not have Appletalk routed on it, which will lead to legacy Macs having to change the way in which they print, unfortunately losing some functionality in the process. This will require investigation into the best way for Macs to print to the new DICE print servers.

For planning purposes, the primary stage of implementation can be broken down into the following discrete tasks:

• Obtain DICE machine and set it up as a test print server. This is dependent on the printing subnet being established and also on obtaining a machine properly integrated into the DICE infrastructure (e.g. Kerberos and LDAP). Estimated time: 1-3 weeks.
• Set up and test configuration for DICE client machines, including printcap distribution method. Estimated time: 1-3 weeks.
• Adapt and test configuration for legacy client machines. Estimated time: 1-2 weeks.

Once a basic test server has been verified as working correctly under both the new infrastructure and legacy systems then we will need to look at the following issues:

• Standardisation of implementation differences between the three sites will need to be considered. These differences are relatively minor, but will need to be addressed nonetheless. These include issues such as management of printer PPD files and printer capability files and the standardisation of -Z options. Legacy systems will be spooling to the new servers as well, so this issue will obviously affect them too.
• At CS currently, all client machines are configured in such a way that they can use a locally attached printer. This issue will need to be addressed in the new system.
• We will need to ensure that in the DICE world, the printers are correctly allocated an IP address via DHCP at boot time. We don't expect this to present a significant difficulty.
• We will need to decide whether we are going to implement print quotas and if so, how this will be done. There are no quotas in place in CS or CogSci at the moment, although this fact is not advertised. Excessive use can be identified if suspected, as all printer usage is logged. In AI, a quota system is in operation, although it requires CO intervention to disallow a user from further printing - the software does not automatically do it. In the initial stages of DICE, all printer accounting information will continue to be logged, although decisions on how and whether to process this data are not a priority at this stage.

Once these issues have been resolved, we will be able to proceed with development of the printing system across all sites, including installation of print servers at each site.

Estimated time for secondary implementation issues: 2 weeks.

Issues described here are those which are not strictly required for the printing system to function effectively, but which would or could provide improvements to the system or be beneficial in some other way. These will be investigated subject to time constraints.

• It has been noted that the 'hpdriver' program which deals with printer network communication is difficult to use with certain printers. It does however work effectively with all newer HP printers, which make up the vast majority of the division printers. We would like to look into the possibilities of replacing this.
• The filtering system uses certain criteria to recognise the file type of each print job (so it can convert it to postscript before sending to the printer.) We would like to look at alternative ways of doing this, in order to address minor problems with the current system.

These are items which do not require action from the Printing Group, but which we should be aware of.

• We should be aware what version of ghostscript is installed on DICE machines and ensure it functions correctly with LPRng.

We would like to look into the possibility of using CUPS, instead of LPRng. "The Common UNIX Printing System ("CUPS") is a cross-platform printing solution for all UNIX environments. It is based on the "Internet Printing Protocol" and provides complete printing services to most PostScript and raster printers. CUPS is provided under the GNU GPL". See http://www.cups.org/ for more details. There is insufficient time at this stage of the DICE project to investigate this seriously, but it should be considered for future development.

It is difficult to accurately judge the timescales involved in this task because of the dependencies, variables and unknown factors. There doesn't seem to be any reason, however, why it should not be completed by May 2002.

Dependencies

• Kerberos infrastructure
• LDAP infrastructure
• Network (for printing subnet)

Actions

Current

2002-04-01

Set up sybies.inf as test Inf print server

2002-03-13

Write interface program to supply printcap information to LPRng from LDAP

2002-03-06

[Neil:] LCFGng-ify the existing DCS lpd component

Completed

2002-03-25

Install sybies.inf (cname print1.inf) as 7.1 DICE machine, on wire-m, to be used as test print server

2002-02-05

Initial investigation into whether the proposed authorisation system meets the needs of the printing group.

2002-02-05

First pass at LDAP schema required for printcap information.

Further Details on Actions

Integrating the permission scheme used in LPRng on a user level would appear to be fairly trivial. LPRng supports kerberos authentication and permissions can be specified for an authenticated kerberos principal, e.g. user@INF.ED.AC.UK. However, the issue of permissions defined by groups and netgroups is more complex as LPRng evaluates these by unix identity rather than by kerberos principal. It is also important to consider that only DICE systems will be making kerberos authenticated connections, so the authorisation scheme used in LPRng must also support standard non kerberos authenticated connections. These connections (e.g. from legacy machines) can be tested against different permission rules to those used for kerberos authenticated connections.

The authorisation system proposed under DICE offers three separate interfaces, including a netgroup style one. This might be the way in which permissions are checked for printing, although the permissions file used by LPRng can be specified as a program, allowing us flexibility in exactly how it is generated. Whether we have different permission rules specified for kerberos authenticated users is a matter for future debate, the important thing is that the system will be able to evaluate permissions for both kerberised and non-kerberised jobs.

In conclusion, there appears to be no reason why the proposed authorisation system would not satisfy the needs of the printing group. Requests can be subjected to permission checks whether they are kerberos authenticated or not.

Further investigation into kerberos support in LPRng has revealed a bug in the code relating to permissions checking when accepting a kerberos authenticated job transfer. This has been reported to the LPRng author and a fix is being incorporated into the next release (3.8.9).

We will need to define LDAP schema for the data needs of the printing system. There were two areas that we initially considered.

• We had looked at storing the permissions information in LDAP to ensure quick replication of any changes. However, the preferred option for this is to manage it through the roles systems.
• We will require an LDAP schema for printcap information.

After discussions between the printing and LDAP groups, we have defined a test LDAP schema for printcap information, which is included below. We decided that this schema should be relatively simple due to the large, and ever increasing, number of possible printcap options. We feel there is no real benefit to be gained from separating some printcap data out into separate attributes.

It is worth noting that, under our proposed system, the relationship between the queuename and print server name will be stored both in the LCFG entry for the server and in the printcap section of LDAP. This means that for a change of print server, changes must be made in two separate places. It is probably a good idea to use logical names for print servers, e.g. print1.inf.ed.ac.uk, to remove this redundancy.

Initial printcap LDAP schema:

# Depends upon core.schema and cosine.schema
# Created by Tim Colles <timc@dai.ed.ac.uk>
#   from a definition by Toby Blake <toby@cogsci.ed.ac.uk>

# OID Base is 1.3.6.1.4.1.4247.1.747.9999
#
# Syntaxes are under 1.3.6.1.4.1.4247.1.747.9999.3.125-149
# Attribute types are under 1.3.6.1.4.1.4247.1.747.9999.2.125-149
# Object classes are under 1.3.6.1.4.1.4247.1.747.9999.1.125-149

# Attribute Type Definitions

attributetype ( 1.3.6.1.4.1.4247.1.747.9999.2.125 NAME 'lpdServer'
        DESC 'Hostname of the print server'
        EQUALITY caseExactIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.4247.1.747.9999.2.126 NAME 'lpdServerPcap'
        DESC 'Printcap entry used by the print server'
        EQUALITY caseExactIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.4247.1.747.9999.2.127 NAME 'lpdClientPcap'
        DESC 'Printcap entry used by remote clients'
        EQUALITY caseExactIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

objectclass ( 1.3.6.1.4.1.4247.1.747.9999.1.125 NAME 'printcapEntry'
        SUP top STRUCTURAL
        DESC 'A client/server printcap entry for a printer'
        MUST ( cn $ lpdServerPcap )
        MAY ( lpdServer $ lpdClientPcap $ description ) )

objectclass ( 1.3.6.1.4.1.4247.1.747.9999.1.126 NAME 'printcap'
        SUP top STRUCTURAL
        DESC 'A group of printcap entries'
        MUST ( ou ) )

 : Deploy 

Please contact us with any comments or corrections. Unless explicitly stated otherwise, all material is copyright The University of Edinburgh