You are the administrator of a server connected to the Internet. When you try to log in with your user ID (after all, you don't log in as root, but su to root), you find that you cannot log in.

Perhaps the problem is as simple as you mistyped your password. In this case, a simple second attempt at logging in will fix the problem. Of course if that were the problem, you wouldn't be reading this book.

Perhaps you forgot your password. This is a common error, especially when a password has just been changed.

If it was a forgotten password, you could simply log in as root (or get the system administrator) and change the password.

Perhaps someone logged on to your system, as you, and changed your password. How would you know this? This is one of the places where logs come in handy. Certain logs can be examined, depending upon the information needed. Probably the first file to check is the login.access file.

login.access

The login.access file is used to control login access (hence, its name). The file is nothing more than a table that is checked each time a person attempts to log in. The table is scanned for the first entry that matches the user/host or user/tty combination. The table is a colon-delimited list of permissions, users, and origins (host or tty).

The permission is either a plus sign (+) or a minus sign (-). A plus sign indicates that the user has permission to access, and a minus sign indicates that the user does not have permission to access.

The user is the user ID of the person either being restricted or allowed access to the machine from that location. The option ALL would indicate all users. The ALL option can be used in conjunction with the EXCEPT option. The EXCEPT option allows for certain users to be excluded from the ALL option. Groups can also be included as valid users. This would be a way of restricting or allowing access to the system for users who have similar job functions. The group file is searched only when the name does not match the user logged in. An interesting twist to this is that it does not check primary groups, but instead checks secondary groups in the /etc/groups file.

The origin is where the user is logging in from. The option ALL would indicated all locations. The ALL option can be used in conjunction with the EXCEPT option to allow exceptions to the ALL option.

This file is used many times to restrict access to the console. Following are some examples of allowing access and denying access to various groups. The first example is used to restrict access to the console to all but a few accounts:

-:ALL EXCEPT admin shutdown sync:console

The next example disallows nonlocal logins to the privileged accounts in the group wheel:

-:wheel:ALL EXCEPT LOCAL

The following is an example of disallowing certain accounts to log in from anywhere:

-:bertw timp wess lorenl billh richb chrisb chrisn:ALL

This last example would allow all other accounts to log in from anywhere.

Other Files That Deny or Allow Users or Hosts

Another file that will deny hosts from accessing the computer is the /etc/hosts.deny file. The hosts.deny file describes the names of the hosts that are not allowed to use the local INET services. These INET services are defined by the /usr/sbin/tcpd server.

The /etc/hosts.lpd file describes the names of the hosts that are considered "equivalent" to the current host. This "equivalence" means that the hosts listed are trusted enough to allow rsh commands. Typically a system that is directly connected to the Internet has only an entry of localhost.

syslog

The syslog is a good file to check on a regular basis. Although most of the information should be standard repeats for your system, you aren't looking for these. What you are looking for are anomalies. Anomalies are things that show when the system noticed something out of the ordinary. The following example comes from a fictitious syslog. The bolded items are the ones that I would be curious about:

Aug  8 19:51:53 shell sendmail[333]: gethostbyaddr(268.266.81.253) failed: 1

Aug  8 19:51:53 shell sendmail[333]: gethostbyaddr(268.266.81.254) failed: 1

Aug  8 19:52:56 shell mountd[324]:

ÂUnauthorized access by NFS client 208.206.80.2.

Aug  8 19:52:56 shell mountd[324]:

ÂBlocked attempt of 268.266.80.2 to mount /var/spool/mail

Aug  8 19:52:57 shell mountd[324]:

ÂUnauthorized access by NFS client 268.266.80.2.

Aug  8 19:52:57 shell mountd[324]:

ÂBlocked attempt of 268.266.80.2 to mount /home

Aug  8 19:54:19 shell in.qpopper[371]:

Âwarning: can't get client address: Connection reset by peer

Aug  8 19:54:52 shell mountd[324]:

ÂUnauthorized access by NFS client 268.266.80.2.

Aug  8 19:54:52 shell mountd[324]:

ÂBlocked attempt of 268.266.80.2 to mount /home

Aug  8 20:00:30 shell inetd[410]: execv /usr/sbin/nmbd: No such file or directory

Aug  8 20:00:30 shell inetd[319]: /usr/sbin/nmbd: exit status 0x1

Aug  8 20:00:42 shell last message repeated 11 times

Aug  8 20:01:56 shell last message repeated 23 times

Aug  8 20:02:37 shell last message repeated 15 times

Aug  8 20:04:23 shell inetd[319]: /usr/sbin/nmbd: exit status 0x1

Aug  8 20:05:21 shell last message repeated 11 times

Aug  8 20:13:39 shell sendmail[577]: gethostbyaddr(268.266.80.11) failed: 1

Aug  8 20:13:39 shell sendmail[577]: gethostbyaddr(268.266.80.12) failed: 1

In this portion of the syslog, the bolded lines show where some system tried to access certain files by mounting the filesystems to its machine. Now, this could very well be a case where a legitimate user was trying to mount certain files, but it might not be. This is where a familiarity of the particular system helps. Is the IP of the system trying to mount the filesystems a known IP? If it is a known IP, perhaps it is just an error; if it is not, then it might be indicative of an attempted security breach. (See Chapter 20, "System Security," for more on this topic.)

There are many other logs that can be made active to give you more information. Many of these files are defined in the /etc/login.defs file. This file controls the configuration definitions for login. They include setting the location for failed logins (/var/log/faillog), whether to enable additional passwords for dial-up access (/etc/dialups), whether to allow time restrictions to logins (/etc/porttime), defining the superuser log (/var/log/sulog), and many other configurations. It is up to you as the system administrator to decide which, if any, of these functions to turn on. Actually, the "if any" part of the previous statement is not true. There are many configurations within the /etc/login.defs file that are mandatory. One such example is the location for the mail queue (/var/spool/mail).

The point is, this is one powerful file. Take a few minutes to get acquainted with it and understand how it works (it is well documented). It will save you a lot of time when you know that the /var/log/lastlog file contains the information on the last person logged in to the system.

Wine—Accessing Windows Applications
Under Linux

The most common way to access applications under Linux is with the product called Wine. Wine is both a program loader and an emulation library that enables UNIX users to run MS Windows applications on an x86 hardware platform running under some UNIXes. The program loader will load and execute an MS Windows application binary, while the emulation library will take calls to MS Windows functions and translate these into calls to UNIX/X, so that equivalent functionality is achieved.

MS Windows binaries will run directly; there will be no need for machine-level emulation of program instructions. Sun has reported better performance with their version of WABI than is actually achieved under MS Windows, so theoretically the same result is possible under Wine.
There is a great discussion as to what Wine stands for. The two most common rumors are that it stands for Windows emulator, or that it stands for Wine is not an emulator.