I feel that I should be posting this in the Unix for Dummies Forum and will probably wish I'd created an account and done just that - but here goes anyway.
I have two identical servers both Dell R430's both running RedHat Enterprise Server 7.4 and the same kernel, both have the same network config although they are located at different sites - all good so far!
During the setup of the servers we run a script which has the following command line entry;
There's nothing configured at either end, there is a .rhosts on the target server - the problem has to lie with the second server as I have just shy of 1800 unix servers of various flavours all working. This is the only one not working, I'm completely flummoxed having spent a couple of hours looking at it now.
I've checked that the ports are open and that they are available all the way between the site - I have several hundred servers on each of the two sites and they are all working.
Just confused at the moment, going to have a think about this and will return to it later on.
On some systems, rsh is a "remote" shell. On other systems, rsh is a "restricted" shell. On SunOS, I think you'll find that depending on how $path (if you are using a csh derivative shell) or $PATH (if you are using a Bourne shell ( sh ) derivative) is set in your environment, rsh may be a link to sh (and treated as a restricted shell) instead of being a link to ssh (and treated as a remote shell).
What shell are you using as your login shell for the account that is having problems on SunOS? What output do you get from the command:
The problem isn't on the Solaris (Whole Root Zone) server, all the other Unix servers can execute the command without issue.
This Redhat 7.4 server is the only one on the estate exibiting a problem, the rsh action fails only when a parameter like uname is passed. A simple rsh to the box works fine - I know that this uses rlogin and have been investigating further this morning.
I will spend more time on this today and will go through the earlier posts to check what people have suggested, here's your request;
So, if i get that right: rsh hangs until you press CTRL-C when called from a script (?) but works when issued manually, from the commandline.
First suspicion is that there is a difference in the environment of the script and your interactive enivronment, so how about dumping the respective environments (via an inserted set > /some/file ) and cast a diff on them? Also - as this will not be shown by this method - check for eventual alias es and the like. This is basically the same idea as Don Cragun had, but generalised to other settings than PATH.
Or - you will have to test that - does it always not work for the first time and work for the second (and subsequent) time(s)? Such behavior usually results from something being loaded/configured "on demand" but not completely being able to fulfill the current sessions request - the current session will fail but any subsequent session will work. (Sorry for being so vague but i don't know your system well enough to come up with any more concrete ideas).
I said at the begining of this thread that it should have been posted in the Unix for Dummies section and as it transpired that was correct.
When we build servers like these there is a process, it is a bit convoluted - but it delivers the desired end result. But that would appear to be when one person works on it.
The problem turned out to be the firewall had been turned back on by one of our offshore people, I had already stopped the service as per the build standard and created all the support users, one of them had - whilst setting up his environment decided to have a look around the server and contrary to what he was supposed to do. He started the firewall because he assumed that the server would need it!
Turning off the firewall resolved the problem, but didn't get me back the missing day!
Many thanks for all the suggestions and assistance on this.
Hi Gull04,
I'm glad to hear that you found the problem and got it fixed.
However, note the part of your $PATH setting marked in red above...
First, you don't need /usr/bin in $PATH twice. Having it there twice will only serve to slow down starting up any utility that is not found in /usr/bin or whatever directory you shell assumes is specified by have two <colon>s together in $PATH .
And, maybe more importantly, the standards don't say what happens when you have two <colon>s together in $PATH . The unspecified directory denoted by the two adjacent <colon>s between the first two instances of /usr/bin in your path could be treated as an error (silently ignored but slowing down starting up any utility that is not found in /usr/bin ), could be treated as a request to use the current working directory (effectively moving . from the end of your $PATH setting to instead be in second position), or as a request to use / at that position (with the effect varying greatly depending on what is being executed and what utility is being invoked). My (unsupported by any experimentation) guess would be that using / might be the most likely action a shell might take and the most likely to cause hard to track down intermittent anomalies at some point in your future. Any or all of the effects listed above could also vary from shell to shell.
I strongly suggest that you find out what is setting $PATH this way and fix it. I wish you good luck in finding the cause.
In addition to what Don Cragun already said: how on earth can a user get the privileges necessary to turn on the firewall?? In a long (and rather depressing) life as a systems administrator i learned that admins should be like gods: i am your root - thou shalt have no others besides me!
In AIX there is a file /etc/nologin , which, when in place, prevents any login. (It is deleted automatically upon reboot, so it can't be forgotten.) Maybe there is something alike in RHEL, which you could incorporate to your deployment process to prevent these things? If not: how about killing getty instead? That would also prevent new logins until a final reboot, which should perhaps be the last step in a customisation process anyway.
Thanks for the pointer regarding the path, it has now been amended and the build script has been corrected on the Satellite Server.
As to the "root" access problem @Bakunin, as a contractor I'm kind of stuck with what I'm given and during the build phase there is a standard root password set. This is changed before the server is handed over to the support teams, I don't particularly like the way that the servers are built - but if the client says to stack boxex in the corner. Then I'll point out that he'd be better putting them in the cupboard, but because he's paying I'll stack them in the corner if he doesn't see sense.
