The configuration files for this version (and later versions) of the AIXLink/X.25 product are:
Allows an AIX host user connected through X.25 and X.29 to select the initial application. The criteria that must be met are configurable and based on the X.25 calling address. Only a highly privileged user (such as a network administrator) can configure the relevant data that resides on the AIX host.
Three kinds of initial applications can be started upon acceptance of an incoming X.25 call packet using the X.29 protocol ID:
| logged user | AIX login is done in the normal way and conventional password validation and security processing are performed. There can be multiple "logged users" per X.25 calling address.
This kind of initial application processing is started based on the following:
|
| trusted user | AIX login is done so that it circumvents login ID and password validation. There is only one "trusted user" per X.25 calling address.
This initial application processing is started when the X.25 calling address is configured as "trusted" in the x29access configuration file. Note: The x29d daemon must be restarted so that the x29access file will be re-read. The system requires that /etc/security/user and /etc/security/login.cfg files be configured for trusted users. This can also be done through the System Management Interface Tool (SMIT). A "trusted user" has a non-default TTY-X.29/X.3 profile set if the x29access data for the X.25 calling address is configured to reference a valid profile set. For more information, see "Selectable Profile". Note: The "trusted user" method is simpler than that used in Version 1.1.2. Since there is only one "trusted user" per X.25 calling address and no login is supplied for the AIX login process, selection of a profile set is based on the X.25 calling address. This does not prevent a "trusted user" from selecting an initial profile set by other means. |
| selective user | Starts an application preconfigured in the x29access configuration file. The application is responsible for security arrangements.
Additional criteria linked to the X.25 calling address may need to be satisfied before the initial application is started and the "selective user" actually exists. The criteria are specified in the x29access file on a per-X.25 calling address basis. The X.25 calling address must match one in the x29access file. For each X.25 calling address in the x29access file, there is an access_class field that specifies one of the following values:
|
Notes:
- A TTY-X.29/X.3 profile set has the following two components:
- Ambiguity is possible in X.25 calling addresses that contain variable-matching (wildcard) characters. The algorithm for searching the x29access file defines a match as the first address in the file that matches the one from a call packet. Consequently, if there are similar addresses in the x29access file, the order in which they must be arranged is from those with the most rigid matching conditions to those with the least rigid conditions.
The selectable profile mechanism allows for the selection of non-default profiles.
For outgoing PAD application connections (X.28/X.25), new functionality allows non-default X.28/X.3 parameter profiles to be selected by a name or a CCITT-defined profile number.
For incoming X.29/X.25 connections, both non-default X.29/X.3 profiles and TTY parameter profiles (TTY-X.29/X.3 profile sets) can be selected. TTY-X.29/X.3 profile sets are selected based on data extracted from the X.25 call packet and a variety of configuration data located in the x29access and x29user files on the AIX host.
The method for selecting non-default TTY-X.29/X.3 profile sets is quite different for "logged users" versus other kinds of users (for example, "trusted" and "selective" users).
Depending on how the data in the x29access and x29user files is configured and the user's AIX login, there are several ways a "logged user" can select non-default TTY-X.29/X.3 profile sets. In all cases, a member-type profile must be referenced in order to select a non-default profile set. The x29parm file contains members of the X.29/X.3 parameter-type, and the x29tty file contains members of the TTY characteristic-type. A profile set is composed of an X.29/X.3 parameter profile and a TTY characteristic profile.
Non-default TTY/X.3 profile sets are selected based on the following:
This is only possible if the X.25 calling address is in x29access. If so, the tty_profile field or the x3_profile field of the corresponding data set reference the profile set, and the referenced members are in the x29tty and x29parm files.
The tty_profile field can contain the name or the alias of a TTY characteristic profile in the X.29/TTY profile file. If tty_profile is not set, the default TTY characteristic profile is selected.
The x3_profile field may contain the name or number designating an X.29/X.3 parameter profile in the X.29/X.3 profile file. If x3_profile is not set, the default X.29/X.3 parameter profile is selected.
This is only possible if the login supplied is in the x29user file. If so, the tty_profile or x3_profile fields for the corresponding data set reference the profile set, and the referenced members are in the x29tty and x29parm files.
This is only possible if the X.25 calling address is in the x29access file, and the AIX login supplied is in the x29user file. For example, the login must be supplied by the "logged user" rather than extracted from the x29access file. If so, the tty_profile or x3_profile fields for the corresponding data sets reference the same profile set, and the referenced members are in the x29tty and x29parm files.
The multiple references to the same TTY-X.29/X.3 profile set must be resolved. Both the x29access and x29user files contain tty_priority and x3_priority fields for exactly this purpose. The priority fields can be initialized to -1, which means they are not to be used. The basic algorithm is as follows:
If both the x29access and x29user priority are not -1
If the x29access priority < x29user priority,
Use the reference in x29access.
Else
Use the reference in x29user.
Else
If the x29access priority is not -1,
Use the reference in x29access.
Else
Use the reference in x29user.
This means if no priority is specified
the reference in x29user automatically has priority.
Notice that the lower the numerical value the higher the priority. Also, the algorithm is executed independently for TTY characteristic and X.29/X.3 parameter profiles. Finally, once the references are resolved, the tty_profile and x3_profile fields function the same as specified above.
In this case, there is no X.25 calling address in the x29access file and no login in the x29user file. Consequently, there is no choice but to use the default TTY-X.29/X.3 profile set.
The "trusted" and "selective" users can select the TTY-X.29/X.3 profile sets when the tty_profile field or x3_profile field in the x29access file reference a profile set member in the x29tty or x29parm files, respectively.
If the tty_profile field or the x3_profile field in the x29access file references a profile set member in the x29tty file or the x29parm file, the non-default profile members are selected.
The tty_profile and x3_profile fields used in the x29access and x29user files have the following syntax:
tty_profile = [NAME]
Where NAME can be the name or alias for a profile in the x29tty file, and it must be a printable ASCII string. If NAME is not specified, there is no profile reference.
x3_profile = [NAME | NUMBER]
Where NAME is the name of a profile in the x29parm file and must be a printable ASCII string not beginning with a : (colon) or # (number sign). NUMBER is the numerical identifier of a profile in the x29parm file and consists of the # (number sign) character followed by a string of ASCII characters 0 through 9. If neither is specified, there is no profile reference.
The PAD application can select a non-default initial X.28/X.3 profile in three ways:
The available profiles are all stored in the x28parm file.
All of the X.28/X.3 parameter profiles are stored in the x28parm file. However, the xspad command does not directly extract profiles from the x28parm file.
Before any profile selection occurs, the X.28 STREAMs module is pushed on X.25. At that time, all the profiles in the x28parm file are downloaded to the X.28 STREAMs module. This is necessary because a new non-initial profile can be selected at a later stage of xspad execution.
The x28parm file contains all the X.3 parameter profiles and is used to configure the characteristics of outgoing X.28/X.25 PAD sessions.
The x29parm file, which contains all the X.3 parameter profiles, and the x29tty file, which contains all the TTY characteristic profiles, are used to configure the characteristics of incoming X.29/X.25 sessions.
Note: The x29d daemon must be restarted so these files will be read in the outgoing case.
Both the x28parm and the x29parm files have the same format. Each profile contains all 22 of the standard CCITT X.3 parameters, descriptive information, and optionally some network-specific parameters. Each profile has a unique name and numerical identifier.
All the fields must be present even if they are not used. The fields can be in any order, although it is recommended that they be kept in increasing X.3 numerical order. An exception is the x3_11_dte_speed parameter, because it is a read-only parameter and ignored.
A syntax enhancement allows the profiles to be referenced both by name and standardized CCITT numeric profile identifiers:
NUMBER:NAME
Where NUMBER is the numerical profile identifier represented as a contiguous string of ASCII characters 0 through 9, and NAME is a descriptive profile identifier and a string of printable ASCII characters not beginning with a : (colon) or # (number sign) character:
90:ccitt_default_profile
The following new fields have been added:
The x29tty file contains TTY characteristic profiles. Each profile has a unique name and possibly an alias name. The field names are similar to those used in the normal AIX TTY structures, and the semantics are the same. It is easy to specify TTY characteristics, because almost all TTY characteristics can be enabled or disabled by setting the corresponding field to ON or OFF. All the fields must be present, but the order is optional.
To allow aliases, use the following syntax:
NAME:[ALIAS]
Where NAME and ALIAS are descriptive profile names consisting of printable ASCII characters beginning with either the : (colon) or # (number sign) character.
cooked_profile:default
Some fields that represent a character have the following syntax:
FIELD_NAME = CHAR_VALUE
Where FIELD_NAME is a printable ASCII string without white space, and CHAR_VALUE is either a single ASCII character or an ASCII character prefixed with the "^" character:
erase = @ kill = ^H
Note: The TTY characteristics specified by the tab0_tabs , eof_vmin_min , and eol_vtime_time fields are context-dependent.
Security for outgoing X.28/X.25 PAD sessions is on a per-user basis and is implemented by restricting the X.25 addresses to which a particular user can connect.
Security for incoming X.29/X.25 sessions depends on the user's X.29 access category:
The following packages must be installed to use PAD printing:
Note: The printers.hpJetDirect.attach package is important because rather than X.25 PAD creating its own pioin and pioout applications, it uses the standard that comes with this package.
PAD printing can be accomplished by one of the following methods:
Both methods require an X.25/X.29 connection between the AIX host and the PAD to which the remote printer is attached.
The AIX host needs substantial configuration and some software modules to support either PAD printing method.
There are two categories of configuration data. The first describes remote printer attributes, such as speed, and the second associates NUAs and AIX printer queues with actual remote printers.
The software functionality specific to the host-initiation method is the establishment of an X.25/X.29 connection.
The software functionality specific to the remote-initiation method is as follows:
The software functionality specific to both PAD printing methods is:
The printer must query the AIX host for print jobs. Printing is initiated when a remote PAD transmits an X.25/X.29 call to the AIX host. Upon reception of the call, the AIX host uses preconfigured data to identify a specific printer queue associated with the X.25 destination subaddress.
Since the PAD and printer have the same X.25 source address, use the X.25 destination sub-address to identify the printer. This does not affect the criteria for validating the X.25 source address.
Once the X.25/X.29 connection is complete and the printer queue is identified, any jobs on the queue are transmitted to the printer. The X.25/X.29 connection is then cleared.
This kind of printing is used when a printer does not have its own NUA or the network configuration makes establishment of a VC between the AIX host and printer unfeasible. Printing is usually triggered when the printer is turned on. At this point, an X.25/X.29 call is sent to the AIX host. After the connection is complete, the PAD routes data from the host to the port to which the PAD is attached. The port must be configured with the X.3/X.28 attributes to automatically place an X.25 call.
The AIX host must have mechanisms for "listening" for calls that have a destination subaddress corresponding to the remote printer queues, that map the subaddresses to the right queue, detect print jobs on the queues, and transmit data over the X.25 connection from the remote printer. Some commercial products do this by first setting up "plumbing" to the right queue, replacing AIX pioout with a proprietary program, and finally transmitting the queued print jobs.
When a print job is queued for the remote printer, the AIX host sends it regardless of how the job was queued. When the host detects a job on the remote printer's queue, it initiates an X.25/X.29 connection using the destination address of the remote PAD to which the printer is attached. There must be a preconfigured mapping between the remote printer queue and the NUA at the AIX host. The initial request for the print job may or may not originate at the PAD to which the printer is attached. If the request originated at the PAD, the printer must have a different X.25 subaddress than other devices attached to the PAD.
When the X.25/X.29 connection is complete, the AIX host transmits the print job and clears the connection. This kind of printing requires that the printer have a unique NUA. Also, it must be likely that the attempts by the AIX host to establish a VC to the printer will succeed at any time, since print jobs can be queued at any time.
PAD printing is triggered when a call with the appropriate NUA is received. The PAD then completes the X.25/X.29 connection and routes data from the AIX host to the port to which the printer is attached. The port must be configured with the appropriate X.3/X.28 parameters and configured to accept incoming calls.
Printing is triggered at the AIX host when a job is placed on the print queue of a remote printer. This is achieved by some products by replacing AIX pioout with a proprietary program with the ability to make X.25/X.29 connections and the ability to send the print job without overrunning the remote printer.
The two processes that interact with the printer qdaemon to accomplish pad printing are:
For both remote and local printing, piox25 is started indirectly each time the qdaemon removes a job from a particular print queue. Then, the job is piped from piobe (the printer queue backend) to piox25 that transmits it to the network through an X.25 connection. Pacing and formatting are handled by piobe; therefore, the printers.hpJetDirect.attach fileset needs to be installed.
The piox25start process is used only in the case of remote printing and interacts with x29d, as well as piox25.
The X.25 calling address of the printer needs to be configured in the /etc/sx25pad/x29access file as follows:
pad_q: device = hp@stocks hp@stocks: file = /var/spool/lpd/pio/@local/dev/hp@stocks#hpJetDirect header = never trailer = never access = both backend = /usr/sbin/piox25remote pad_q
When x29d receives an X.25/X.29 call from the specified X.25 calling address indicating the criteria was satisfied, it spawns piox25start.
The piox25start process does two things:
When the printer qdaemon receives the enq request to activate a particular queue, it enables scheduling of print jobs on that queue. When the qdaemon schedules a print job, it spawns piox25 as follows:
The steps for eliciting another job while the connection is established are:
The cycle of running the piox25start and the piox25 commands, alternately, continues until the print queue is empty or the network connection is lost. At that point, the piox25 command fails to receive SIGUSR1, then exits; and the network connection is closed.
The steps for configuring for local printing are as follows:
QNAME LDEVICE DESTWhere QNAME is a print queue name; LDEVICE is a logical device name, such as sx25al ; and DEST is the X.25 called address of the hardware PAD to which the local printer is connected (for example, 32154123). In most cases, the X.25 called address contains a sub-address corresponding to the hardware PAD port to which the printer is connected.
Note: This data is used to derive the line number and X.25 calling address from the ODM.
pad_q: device = hp@stocks hp@stocks: file = /var/spool/lpd/pio/@local/dev/hp@stocks#hpJetDirect header = never trailer = never access = both backend = /usr/sbin/piox25local pad_q
A job is removed from the print queue by invoking piox25 as follows:
Both local and remote printing share the same job transmission logic. Data read from piobe is sent to the network until EOF is encountered. Since it is possible for transmissions to the network to be blocked, new data is only read from piobe when no other transmission is in progress.
On occasion, it may seem that the print job takes some time. In some cases, such as remote initiation, the connection must be established, the printer queue must be set up, the converting of the data from X.25 to printable ASCII must be done, and lastly, the transmission of the job through the printer commands must be completed.