The PeoplePages™ product is software that provides books (databases) for InPerson™ users. When the PeoplePages application starts up, private and public books appear as icons in the PeoplePages application window. Clicking on a book opens it to display icons and associated records for other users on the network. Users can drag the icons to use with InPerson, or read the records for more information on the user. With the PeoplePages application, users can also modify private books and edit their own records in public books.
Public books are supplied by a PeoplePages server and database on a network host. The network host runs the ppagesd server program and exports the public book as an NFS directory. ppagesd also listens for new InPerson users on the network, and adds them to the public database if they are not already there.
This document is written for the system or network administrator responsible for the setup and maintenance of PeoplePages software on your network. It consists of the following sections:
To run PeoplePages on your network, install the server software on the network host you have chosen to be the PeoplePages server, and install the PeoplePages application on network clients (refer to your PeoplePages release notes and to the Software Installation Administrator's Guide for installation instructions). This network host should have sufficient space to house the PeoplePages database, and should be configured as an NFS™ server (refer to the NFS Administration Guide for information on configuring NFS.)
Configure the PeoplePages server as described in this document. When you have the server configured, start the PeoplePages server as described in the section “Starting the PeoplePages Server”.
 | Note: The clients running the PeoplePages application must be running automount(1M) and must be able to mount the PeoplePages database directory from the server. (Refer to the NFS Administration Guide for information on configuring NFS for automounting.) |
The PeoplePages network daemon, ppagesd(1M), runs on a network host. It listens for messages from the InPerson application, and it multicasts information about an PeoplePages database. The following sections describe how PeoplePages books are created, and how the server provides them to the client's PeoplePages application. (Refer to the InPerson Setup and Administration Guide for a discussion of multicasting.)
When a user starts an InPerson application, InPerson multicasts a basic set of information about the user which contains the user's ID number (UID), login name (for example, fred), fully qualified hostname (for example, bedrock.engr.widgets.com), and full name (for example, Fred Smith). ppagesd determines if a data record for the user exists in the database that it maintains. If a data record for the user exists, no further action is taken. If no record for the user exists, ppagesd creates a record that contains the information from the InPerson multicast message. The record is added to the database and ownership is assigned to the user.
If two ppagesd daemons are listening on separate servers on the network, both servers add the new data record to their separate databases. The PeoplePages application notifies you if there are duplicate servers, because only one PeoplePages server and database is recommended per network name.
The database is an NFS filesystem, usually exported with global read/write permission and the sticky bit set, for example:
# chmod 1777 directory |
This makes the records writable by their owners, and restricts the right to delete records to the owner of the record (see chmod(1)).
This exported directory is automounted by network clients that run the PeoplePages application. Each data record is a file in the exported filesystem. The database directory appears as a book to the PeoplePages user, and the data record files appear as Information Cards.
| Note: Ownership of the data record is assigned to the user. If you give the exported directory read/write permission, you allow users to modify (for example, expand and update) the information contained in their own records. (This assumes that user IDs are consistent throughout the network, for example in a network using NIS to serve password files.) If you are concerned about allowing users to write to an exported directory, or you want to maintain the data records yourself, export the directory with read-only permission. Users are then unable to modify their records. Any changes you make to the records must be made with the PeoplePages application. |
When the network host with ppagesd is booted, ppagesd starts. ppagesd reads the file /etc/config/ppagesd.options for a one-line entry that contains two arguments —the pathname of the exported NFS filesystem that contains the PeoplePages data records, and a name to be used for the database. A typical /etc/config/ppagesd.options file might look like this:
/usr/local/inperson InPerson |
This specifies that /usr/local/inperson is the NFS directory (PeoplePages database) exported by the host, and that the book name “InPerson” is to be used for it. ppagesd then multicasts a message that includes the pathname and the book name of the PeoplePages database. The pathname is in the form:
/hosts/hostname/pathname
where hostname is the mount point on which the automounter mounts various network hosts, and pathname is the location on the host where the database records are stored. For the example ppagesd.options file shown above on a host name engr1, the pathname multicast by ppagesd would be /hosts/engr1/usr/local/inperson.
You can customize both the name and the cover of your book as shown on the book-selection button at the top of the PeoplePages application main window. Put the name in the file .label in the database directory[1] .
Two cover images in either XPM (X Pixmap) or RGB (standard SGI) format are required. XPM format is recommended because it allows you to tag the predominant background color of the pixmap. The images should be 44 by 32 pixels. These images go in the files .cover-closed and .cover-open in the database directory. The image in .cover-closed is displayed when the book is closed, and the image in .cover-open is displayed when the book is opened for reading.
To tag the background (if you use an XPM format image) add s background at the end of the line specifying the predominant background color. For example the line
% c #848484 |
becomes
% c #848484 s background |
If you have two PeoplePages databases on the network, you could edit the /etc/config/ppagesd.options file of the second server host to look like this:
/usr/local/ppages/engineering Engineering |
In this case, ppagesd on the second host does not add records for new InPerson users because it listens only for packets with the database name “Engineering,” and the InPerson application broadcasts the name “InPerson.” This allows you to provide multiple books on the same network without duplicating data records. Note, however, that any additions to databases with a name other than “InPerson” must be performed “manually” by you or the individual users with the PeoplePages application.
When the PeoplePages application is started by a user, it sends out a query on the network for a ppagesd. When ppagesd receives the query, it responds with the same pathname and book name message that it multicasts at startup.
The PeoplePages application then displays a book icon with the book name supplied by ppagesd. When this book is accessed, PeoplePages attempts to read the path /hosts/hostname/pathname supplied by ppagesd, which automounts the directory if it is not already mounted.
Figure 1 illustrates the PeoplePages network environment. In the figure, InPerson applications multicast user information, which is received and evaluated by the ppagesd process running on a network host. The host supplies database information to a PeoplePages application running on the network.
When you have installed the server software and configured your system, reboot to start the PeoplePages server.
After the system reboots, chkconfig(1) should show the configuration flag ppagesd set to “on,” for example:
% chkconfig | grep ppagesd ppagesd on |
If it is set to “off,” set it to “on” with the command (as root):
# chkconfig ppagesd on |
Make the changes take effect by rebooting your system, or enter:
# /etc/init.d/ppagesd start |
When ppagesd starts, it reads /etc/config/ppagesd.options for the absolute pathname of the database directory. If ppagesd does not find a one-line record with the absolute pathname and the book name arguments, it exits and logs error messages with syslogd(1M). If the directory does not exist, ppagesd attempts to create it. Look in your system log if ppagesd is immediately exiting at boot time. Use chkconfig(1M) to verify that ppagesd is set to “on” if the daemon is not starting at boot time.
If ppagesd is not updating the database with new InPerson user records, check to see that the database directory is writable by ppagesd.
If client PeoplePages applications do not display the book for the database exported by the server host, be sure that the database directory is exported in /etc/exports, the NFS permissions are set properly, and that the client can automount the directory. For example, on the client system, you should be able to access the directory with a standard ls(1) command:
% ls /hosts/hostname/pathname |
If the PeoplePages information cards (ppagesd database records) are not writable by the users, make sure the database directory is exported with read/write permissions.
[1] The book name in the /etc/config/ppagesd.options file is a logical name used by ppagesd. The public name of the book which is stored in the .label file of the database directory is the name seen by PeoplePages users, and it can be different than the logical name.