Questions and Answers
I recently was given the task of handling our RISC6000's UNIX machines. The first task I would like to accomplish is system security. How do I get system logging working, audit trails, and recording various accesses to the system? Not all access but specified access logging. Example: Logging MUMPS access from remote locations, SU' access, failed attempts.
You have a very big task ahead of you. Start out by reading Garfinkel and Spafford's book Practical UNIX & Internet Security from O'Reilly. This will give you the basic understanding you need to undertake this huge task. As long as you are able to hang in and continue to work on this, you will be able to learn what you need, but you will also need to accept that you have a major learning curve ahead of you.
When running SCO Open Server 5.0, I have processes that return after rebooting the server. I cannot kill the processes and they always return as root processes. What are they, and why are they making my life miserable? Two of them have been recurring since January 8, 1998!
You are not describing what processes are causing your problem. There are a few essential processes that a modern UNIX system will not allow you to kill, or which will be immediately restarted, as the system cannot operate without them (init comes to mind a very good example of this). Apart from these very special cases, a kill -9 as root is always a sure kill with two specific exceptions: If a process is stuck in a device driver, for example, because a device has malfunctioned, then that process cannot be killed until it returns from the kernel space (and as it is stuck, it will never return and, therefore appears to be unkillable). The second case is defunct processes which are ghosts that are no longer there.
I have checked the /etc/services, however, it seems like port 81 is not in use. When I configure my Netscape enterprise server using port 81, it prompts me that it cannot bind. How should I go about changing to another inactive port?
the /etc/services file is a simple data file that is used to map port names (such as telnet) to port numbers (such as 23). The absence of an entry in the /etc/services file is a strong indication, but not a guarantee, that nobody is using that port. However, my guess is that you are not starting the server as root. In UNIX, all ports under 1024 are considered privileged ports. Only processes that are running as root are able to bind to those ports. Try to change your server to bind to an unprivileged port (port 8080 is a common choice for this), or start the server as root and see if that fixes the problem.
I am seeing messages like unable to qualify my own domain name using short name, my unqualified host name unknown; sleeping for retry. I see these messages even on telnet sessions. I have set defaultdomain, and installed the required patches. The OS is 2.5.1 and E6000. Any solutions?
This message is coming from Sendmail, which is trying to establish the domain name for the local host. If you start to use fully qualified host names in your host file, and also use the fully qualified host name when you assign a name to the machine, the problem will go away. This does not need to impact your users. In the host table, use the fully qualified host name as the first entry, followed by the unqualified host name, before any other aliases. Users can still continue to telnet or rlogin to the unqualified host name. An example of a single entry from the hostfile would look like this:
10.1.2.3 woody.my-domain.com woody
I am seeking information about a methodology or approach for representing multiple NFS cross mounts for multiple systems in a visually easy-to-understand way. We have six Sun production servers, each of which has multiple exports to one or more of the others and multiple mounts from one or more of the others. My attempts to document these relationships graphically (or even in a table) do not meet basic tests of clear expression (e.g., lots of line crossings). Any suggestions?
The only answer I honestly can give is to avoid cross mounts like the plague. NFS servers that are cross mounted will have trouble completing a reboot after a general reboot (for example, after a power outage). The reason is that there is a risk that each of the servers will not be able to complete its NFS mounts, and will therefore hang at that point, waiting for the other servers to complete their boot process. At that point, you have a deadlock that can only be resolved by booting each server's single-user, removing the NFS mounts from the mount table, and then completing the boot. After all the servers are up, you will then have to reintroduce the NFS mounts to the mount tables and manually mount those file systems (you cannot reboot, or you will be back in the rut). If you are using the automounter, you have a better chance of avoiding this, but reading between the lines of the question, that seemed not to be the case here.
I was setting up a chrooted environment for ftp accounts in UNIX and wanted to use a restricted shell (/usr/lib/rsh) as well as to prevent users from any cd .. completely. I discovered that rsh is the same binary as normal /usr/bin/sh. Where can I find rsh?
Some programs are written in such a way that the name will determine the way it will function. One well-known example is when Sendmail is called as mailq, it will report on the jobs waiting in the mail queue. It is the very same executable, only the name of the program makes it behave differently. The same is the case of older versions of rsh. However, be aware that the restricted shell is not necessarily a secure way to build a restricted environment. If you have a version of chroot that works correctly, you can set up a restricted environment that is much more difficult to break out of. Be aware that some older versions of chroot can be broken out of by typing cd .. until you are above the mount point and back in the usual environment.
About the Author
Bjorn Satdeva is the president of /sys/admin, inc., a consulting firm which specializes in large installation system administration. Bjorn is also co-founder and former president of Bay-LISA, a San Francisco Bay Area user's group for system administrators of large sites. Bjorn can be reached at firstname.lastname@example.org.