Sharing discs between Unix systems 1

[pjw001]

I am hoping someone can point me in the right direction. We have 2 old Unix machines and there are 2 problems.

The first is that logging in takes about 2 minutes before the initial prompt is output. Does anyone have ideas why?

The second is rather more serious. The login scripts (.profile etc) on one of the machines seem to have disappeared. I suspect that these scripts are actually on the other machine and that the 'links' have been lost. If someone could point me in the direction of how to set up these links again I would be very grateful.

Thanks.

 

[Annihilannic]

Which flavour of Unix is it?

Two possible reasons I can think of for slow login are:

[ul][li]/var/adm/wtmp file too big - this is the file used to store historical information about who has logged in to the system... if it gets very large (hundreds of megabytes) the login process can be slowed down significantly. You can "flatten" the file to 0 bytes by simply typing >/var/adm/wtmp at the shell prompt.[/li]
[li]reverse DNS lookups timing out - when you log in the system tries to identify where you are logging in from, say IP address 1.2.3.4, by looking up the host name associated with that IP address. If that takes a long time, it can slow down the login. Usually this indicates a problem with your DNS server. Check the contents of your /etc/resolv.conf to see if your system is even configured to use DNS.[/li][/ul]

For the second issue... are you certain these two servers share disks somehow? If so, do you know how they are connected? Are there any NFS mounts configured in /etc/fstab (look for any with a "hostname:/path" in the device column, the first column in that file) on the machine where the links have been lost.

How many login scripts are missing?

Annihilannic.

 

[pjw001]

Hi Annihilannic,

Thanks for the reply.

One machine is 'Sun Microsystems Inc. SunOS 5.6' and the other is 'SCO UnixWare 7.1.1'.

The wtmp file is only a few hundred bytes on the SCO box and does not exist on the other.

It looks like the resolv.conf file was the problem with the login delay on the SCO system but not the other. I will look further. (Some time ago I had to put an entry in the hosts file for my pc so that I could log in at all, so I may change that as well.)

On the disc sharing, I am as certain as I can be that the 2 systems shared discs. It is the Sun box that is missing the files. I will check the files you mentions.

How many login scripts are missing. Not sure, but it is probably the same number as there are users. We have(had) a fairly complex set of login files that set up the environment. They would all (almost certianly have only been on the SCO box with links from the Sun box.

Many thanks. Reducing the login time from a few minutes to a few seconds is a great relief.

 

[Annihilannic]

Sun Solaris uses the updated /var/adm/wtmpx format if I recall... also it uses /etc/vfstab instead of /etc/fstab.

If you run an ls -la in one such user's home directory, can you see any symbolic links such as .profile -> /some/other/location?

What shell do the users typically use (check last field in /etc/passwd file for the users in question)?

Normally if you were applying a system wide custom profile you wouldn't do it in each individual user's directory, but in the /etc/profile file, which applies to everyone, so it might be worth checking that one over as well.

Annihilannic.

 

[pjw001]

There does not seem to be a wtmpx file.

I have found vfstab and it seems to have the missing links. Two example lines are:

/dev/dsk/c0t0d0s7 /dev/rdsk/c0t0d0s7 /tasc1 ufs 2 yes
-
macbeth:/usr2/develop - /develop nfs - yes -

The users home folders do not exist, probably because they are, for example, in '/develop' which no longer shows if I use 'df -k'.

Is the vfstab file supposed to be executed automatically, or do I need to do something to make it happen, or am I on completely the wrong track here?

My use of the word profile was a bit loose. Many users will have the same .profile defined in the passwd file. This is based on what that user is expecting to be doing based on whether the user name implies they will be developing in a specific environment. At one stage we had many Unix machines all used for the same purpose except that different machines were used to tast and build the software for different customers. All these machines shared the same source code areas and had the same look and feel. That is why I am sure that all the files are on shared drives.

Again, many thanks for your assistance.

 

[Annihilannic]

Ah, so your SCO server is the one named after The Scottish Play (my wife worked in theatre, so I'm not allowed to utter that unlucky word in this house!).

When you type df -k, does it complete quickly, or does it hang temporarily when it is trying to access /develop?

If you type dfshares m.....h, does it still list /develop as an available share?

You could try unmounting and remounting it from the Sun system:

umount /develop
mount /develop

The /etc/vfstab file is a lookup table - it is never "executed" as such, however it is read by the boot-time scripts and any filesystems listed in it should normally be mounted automatically. It is also read by the mount command (as used above) to determine which device or network resource it should be mounting on the specified mount point.

Annihilannic.

 

[pjw001]

df -k responded immediately.

dfshares did not list /develop.

Here is what happened with the other commands:

othello:/> umount /develop
umount: warning: /develop not in mnttab
umount: /develop not mounted
othello:/> mount /develop
nfs mount: m**b*th: : RPC: Unknown host

I feel that this last line may be a bit of a clue.

(And now you know the name of the other machine.)

I guess I could try putting the Scottish Play and its IP address in the hosts file. (Not pretty but it would probably work.) Or I could ask our IT support to fix the underlying problem with, I suspect, the DNS.

Or I could find out what our nameserver is and put it in the reolv.conf file.

Unless you say otherwise I shall probably edit the hosts file - its quicker.

I feel I have learnt a lot today - but probably not enough to stop being dangerous when given the root password.

 

[KenCunningham]

Following on from the excellent (as usual) advice from Annihilanic, I'd agree that the host file sounds like the probable culprit - has the IP address changed at all? This from another site might help:

The unknown host Error. The following message indicates that the host name of the server on the client is missing from the hosts table.
nfs mount: sserver1:: RPC: Unknown host

To solve the unknown host error condition, verify the host name in the hosts database that supports the client node. Note – The preceding example misspelled the node name server1 as sserver1

Good luck.

The internet - allowing those who don't know what they're talking about to have their say.

 

[pjw001]

I have now put an entry in the hosts machine and mounted the drives and it all seems to be fine again.

Thank you very much.