Finger: A Simple Directory Service

Chapter 6: Directory Services

---

6.2. Finger: A Simple Directory Service

Finger and
WHOIS are good examples of simple directory services. Finger exists
primarily to provide read-only information about the users of a
machine (although we'll see some more creative uses shortly).
Later versions of Finger, like the GNU Finger server and its
derivatives, expanded upon this basic functionality by allowing you
to query one machine and receive information back from all of the
machines on your network.

Finger was one of the first widely deployed directory services. Once
upon a time, if you wanted to locate a user's email address at
another site, or even within your own, the finger
command was the best option. finger
harry@hogwarts.edu would tell you whether Harry's
email address was harry,
hpotter, or something more obscure (along with
listing all of the other Harrys at that school). Though it is still
in use today, Finger's popularity has waned over time as web
home pages became prevalent and the practice of freely giving out
user information became problematic.

Using the Finger protocol from Perl
provides another good example of TMTOWTDI. When I first looked on
CPAN for something to perform Finger operations, there were no
modules available for this task. If you look now, you'll find
Dennis Taylor's Net::Finger module, which he
published six months or so after my initial search. We'll see
how to use it in a moment, but in the meantime, let's pretend
it doesn't exist and take advantage of this opportunity to
learn how to use a more generic module to talk a specific protocol
when the "perfect" module doesn't exist.

The Finger protocol itself is a very simple TCP/IP-based text
protocol. Defined in RFC1288, it calls for a standard TCP connect to
port 79. The client passes a simple CRLF-terminated[1] string over the connection. This string either requests
specific user information or, if empty, asks for information about
all users of that machine. The server responds with the requested
data and closes the connection at the end of the data stream. You can
see this in action by telnet ing to the Finger
port directly on a remote machine:

[1]Carriage return + linefeed, i.e., ASCII 13 + ASCII 10.

$ telnet kantine.diku.dk 79
Trying 192.38.109.142 ...
Connected to kantine.diku.dk.
Escape character is '^]'.
cola<CR><LF>
Login: cola                             Name: RHS Linux User
Directory: /home/cola                   Shell: /bin/noshell
Never logged in.
No mail.
Plan:

Current state of the coke machine at DIKU
This file is updated every 5 seconds
At the moment, it's necessary to use correct change. 
This has been the case the last 19 hours and 17 minutes

Column 1 is currently *empty*.
   It's been 14 hours and 59 minutes since it became empty.
   31 items were sold from this column before it became empty.
Column 2 contains some cokes.
   It's been 2 days, 17 hours, and 43 minutes since it was filled.
   Meanwhile, 30 items have been sold from this column.
Column 3 contains some cokes.
   It's been 2 days, 17 hours, and 41 minutes since it was filled.
   Meanwhile, 11 items have been sold from this column.
Column 4 contains some cokes.
   It's been 5 days, 15 hours, and 28 minutes since it was filled.
   Meanwhile, 26 items have been sold from this column.
Column 5 contains some cokes.
   It's been 5 days, 15 hours, and 29 minutes since it was filled.
   Meanwhile, 18 items have been sold from this column.
Column 6 contains some coke-lights.
   It's been 5 days, 15 hours, and 30 minutes since it was filled.
   Meanwhile, 16 items have been sold from this column.

Connection closed by foreign host.
$

In this example we've connected directly to kantine.diku.dk's Finger port. We
typed the user name "cola," and the server returned
information about that user.

I chose this particular host and user just to show you some of the
whimsy that accompanied the early days of the Internet. Finger
servers got pressed into service for all sorts of tasks. In this
case, anyone anywhere on the planet can see whether the soda machine
at the Department of Computer Science at the University of Copenhagen
is currently stocked. For more examples of strange devices hooked to
Finger servers, you may wish to check out Bennet Yee's
"Internet Accessible Coke Machines" and "Internet
Accessible Machines" pages; they are available online at
http://www.cs.ucsd.edu/~bsy/fun.html.

Let's take the network communication we just performed using a
telnet binary back to the world of Perl. With
Perl, we can also open up a network socket and communicate over it.
Instead of using lower-level socket commands, we'll use Jay
Roger's Net::Telnet module to introduce a
family of modules that handle generic network discussions. Other
modules in this family (some of which we use in other chapters)
include Eric Arnold's Comm.pl, Austin
Schutz's Expect.pm, and the venerable but
outdated and nonportable chat2.pl by Randal L.
Schwartz.

Net::Telnet will handle all of the connection
setup work for us and provides a clean interface for sending and
receiving data over this connection. Though we won't use them
in this example, Net::Telnet also provides some
handy pattern-scanning mechanisms that allow your program to watch
for specific responses from the other
server.

Here's a Net::Telnet version of a simple
Finger client. This code takes an argument of the form
user@finger_server. If the user name is omitted, a
list of all users considered active by the server will be returned.
If the hostname is omitted, we query the local host:

use Net::Telnet;

($username,$host) = split(/\@/,$ARGV[0]);
$host = $host ? $host : 'localhost';

# create a new connection
$cn = new Net::Telnet(Host => $host,
                      Port => 'finger');

# send the username down this connection
unless ($cn->print("$username")){ # could be "/W $username"
    $cn->close;              
    die "Unable to send finger string: ".$cn->errmg."\n";
}

# grab all of the data we receive, stopping when the 
# connection is dropped
while (defined $ret = $cn->get) {
    $data .= $ret;
}

# close the connection
$cn->close;                  

# display the data we collected
print $data;

RFC1288 specifies that a /W switch can be
prepended to the username sent to the server to request it to provide
"a higher level of verbosity in the user information
output," hence the /W comment above.

If you need to connect to another TCP-based text protocol besides
Finger, you'd use very similar code. For example, to connect to
a Daytime server (which shows the local time on a machine) the code
looks very similar:

use Net::Telnet;

$host = $ARGV[0] ? $ARGV[0] : 'localhost';

$cn = new Net::Telnet(Host => $host, 
                      Port => 'daytime');

while (defined $ret = $cn->get) {
    $data .= $ret;
}
$cn->close;                  

print $data;

Now you have a sense of how easy it is to create generic TCP-based
network clients. If someone has taken the time to write a module
specifically designed to handle a protocol, it can be even easier. In
the case of Finger, you can use Taylor's
Net::Finger to turn the whole task into a single
function call:

use Net::Finger;

# finger(  ) takes a user@host string and returns the data received
print finger($ARGV[0]);

Just to present all of the options, there's also the fallback
position of calling another executable (if it exists on the machine)
like so:

($username,$host) = split('@',$ARGV[0]);
$host = $host ? $host : 'localhost';

# location of finger executable, MacOS users can't use this method
$fingerex = ($^O eq "MSWin32") ? 
                 $ENV{'SYSTEMROOT'}."\\System32\\finger" :
                 "/usr/ucb/finger";  # (could also be /usr/bin/finger)

print `$fingerex ${username}\@${host}`

Now you've seen three different methods for performing Finger
requests. The third method is probably the least ideal because it
requires spawning another process.
Net::Finger will handle simple
Finger requests; for everything else, Net::Telnet
or any of its kin should work well for you.

---

6.1. What's a Directory?		6.3. The WHOIS Directory Service

---

Copyright © 2001 O'Reilly & Associates. All rights reserved.

Semaphores, Events, Messages, and Timers

10.5 Default Auditing

for Ru-Brd & DownSky size=+0> 10.5 Default Auditing As we mentioned earlier in this chapter, some actions will be stored to operating system files whether auditing is enabled or not. These actions are: Database startup Database shutdown Connection to the database from a privileged account Structural changes made to the database, like adding a tablespace datafile, etc. When the database is started up, a record is written automatically to an operating system file. If the database was started with either sys or internal, the user information will not be recorded. The information recorded is the operating system username of the process starting the database, the terminal identifier, the timestamp (date and time) when the database was started, and whether or not auditing was enabled. The purpose of writing this information is to create a record of anyone attempting to start the database and disable auditing in order to hide their actions. At the time of database startup, the database audit trail is not yet available, so the startup information is always written to an operating system audit file. In all of the auditing situations listed above, the information is recorded to an operating system log. If the operating system does not enable Oracle to access its audit facility, Oracle will record the information in a log in the same directory in which the background processes record their activities. 10.5.1 Auditing During Database Startup The first type of default auditing occurs during database startup. An example of operating system audit entries stored automatically for a Windows NT system running Oracle version 8.0.4 is shown here: Audit trail: ACTION : 'startup' OS_AUTHENT_PREFIX : OPS$. (3:55:41 a.m.) Audit trail: ACTION : `startup' AUDIT_TRAIL : none. (3:55:40 a.m.) Audit trail: ACTION : `connect INTERNAL' OSPRIV : OPER CLIENT USER: SYSTEM CLIENT TERMINAL: MLT-PC. (3:55:31 a.m.) These three entries were found in the Event Viewer, at the Start Programs Administrative Tools Event Viewer menu option on a Window NT system. There are three event logs — System, Security, and Application — into which anyone can insert an event. Oracle will log events in both the System and the Application event logs. The time notations in parentheses were added by us to show you more clearly the sequence of events. The first entry in the sequence above is actually the one listed last. This entry shows the initial connection made to the database in order to start it. Of special interest in the third entry is the notation of the client terminal from which the database was started — MLT-PC — and the system privilege used — OSPRIV. The three audit notations were present in the Windows NT Administrative Tools Event Viewer, in the Application log, after the database was started. As each of the individual detached processes (PMON, SMON, DBWR, LGWR, CKPT, RECO) was started, an individual entry was inserted in the event log. There was also an entry for the time at which the SGA was initialized. 10.5.2 Auditing During Database Shutdown The second form of default auditing that may occur is at the time of database shutdown. Each time the database is shut down, a record may be written to the audit trail indicating the operating system username, the user's terminal identifier, and the date and timestamp when the action occurred. The use of the words "may be" in the last sentence is intentional. Depending on the operating system involved, if a privileged user, like SYSDBA or SYSOPER, shuts the database down, the event might not be registered in the System event log. On a Windows NT version 4.0 system running Oracle8 version 8.0.4, if the database is shut down using the command: net stop OracleStart<db_name> no record of the database shutdown is made either to the Windows NT Application event log or to the database alert log. If your operating system/database automatically records the shutdown attempts performed by non-privileged users, you will find this information very valuable if you are investigating why your database unexpectedly shut down. The absence of an event entry for the shutdown could help you eliminate the fear that your database had been intentionally shut down by an outsider. 10.5.3 Auditing During Database Connection with Privileges The third default action recorded to the operating system audit trail occurs when a user connects to the database with administrative privileges. The operating system user information is recorded. This information is very valuable in helping you detect whether someone has managed to acquire privileges they should not have. 10.5.4 Auditing During Database Structure Modification When a command is issued from the database to modify the structure of the database, the command and its outcome are captured to the alert log for that database. This is the fourth default action. Some examples of commands that will be captured in the alert log follow: CREATE TABLESPACE <tablespace_name> ALTER TABLESPACE <tablespace_name> ADD DATAFILE ALTER TABLESPACE OFFLINE DROP TABLESPACE <tablespace_name> INCLUDING CONTENTS CREATE ROLLBACK SEGMENT <rollback_segment_name> In all of these commands, the successful completion of the command will in some way alter the structure of the database. for Ru-Brd & DownSky

Section 34.2.  Routing Table Initialization

34.2. Routing Table Initialization Routing tables are initialized with fib_hash_init, defined in net/ipv4/fib_hash.c. It is called by ip_fib_init, which initializes the IP routing subsystem, to create the ip_fib_main_table and ip_fib_local_table tables (see the section "Routing Subsystem Initialization" in Chapter 32). The first time fib_hash_init is called, it creates the memory pool fn_hash_kmem that will be used to allocate fib_node data structures. fib_hash_init first allocates a fib_table data structure and then initializes its virtual functions to the routines shown in Table 34-1. The function also clears the content of the bottom part of the structure (fn_hash), which, as shown in Figure 34-1, is used to distribute the routing entries on different hash tables based on their netmask lengths. Table 34-1. Initialization of the fib_table's virtual functions Method Routine used tb_lookup fn_hash_lookup tb_insert fn_hash_insert tb_delete fn_hash_delete tb_flush fn_hash_flush tb_select_default fn_hash_select_default tb_dump fn_hash_dump

5.9 Combined Observer-Controller

< Day Day Up >

---

5.9 Combined Observer-Controller

The next design step is to combine the observer and controller to form the compensator of Figure 5.1. Equation 5.5 shows the complete computation of the state estimate and the plant actuator commands u using the reference input r and sensor measurements y as inputs to the algorithm.

(5.5)

Note that in the configuration of Figure 5.1, the plant and the observer both receive the actuator commands directly. As a result, assuming the linear plant model ideally represents the real plant, the observer tracks the plant response to changes in the reference input r with zero error.

During controller startup, the state estimate vector should be initialized as accurately as possible. This will minimize transient estimator errors during the initial period of system operation.

Equation 5.5 requires the plant input vector u and the measured plant outputs y as inputs. In MATLAB state-space models, only the outputs (y vector elements) of a state-space component are available as inputs to a subsequent component. The input vector elements are not available to use as outputs, which creates a small problem.

The solution is to form an augmented plant output vector ỹ by appending the plant inputs to the output vector. This requires modification of the C and D matrices of the plant model. Equation 5.6 shows the format of the modified matrices.

(5.6)

With the result of Eq. 5.6, the closed-loop system equations consisting of the plant model and the observer-controller are written as follows.

(5.7)

Note

In Eqs. 5.6 and 5.7, 0 represents a zero matrix and I is an identity matrix. For a system with r inputs and n states, the 0 matrix in these equations has r rows and n columns and the I matrix has r rows and r columns.

Equation 5.7 is the mathematical formulation of the closed-loop system shown in Figure 5.1. The top two lines of Eq. 5.7 represent the behavior of the plant. The third line implements the observer, and the fourth line computes the actuator commands. These last two lines form the observer-controller.

The companion CD-ROM contains the MATLAB function ss_design(), which develops an observer-controller and feedforward gain for a SISO plant that using the pole placement method. The inputs to this command are the plant model and constraints for the locations of the closed-loop system and the observer poles. The form of ss_design() is shown here.

>> [n, ssobsctrl, sscl] = ss_design(ssplant, t_settle, ...
                                    damp_ratio, obs_pole_mult)

The input arguments are ssplant, the state-space plant model; t_settle, the closed-loop settling time requirement in seconds; damp_ratio, the damping ratio requirement; and obs_pole_mult, the multiplier used to determine the observer pole locations given the closed-loop pole locations. The select_poles() function is used internally to determine the closed-loop pole locations from the given specifications.

The outputs of ss_design() are the scalar feedforward gain n, the state-space observer-controller ssobsctrl, and a state-space model of the closed-loop system sscl. The ssobsctrl system requires the augmented plant output vector ỹ as its input and produces the term - as its output. The actuator command must be computed as shown in the last line of Eq. 5.7.

You can use plot_poles() (included on the CD-ROM) to display the pole locations of the closed-loop system sscl and verify that they satisfy the specifications.

>> plot_poles(sscl, t_settle, damp_ratio)