Redhat 7.2 and D3/Linux 7.2
mark buller
Are any of your redhat 7.2/d3 7.2.1 sites using nailed telnet?
After upgrading from 7.1 to 7.2 my "connected to specific d3 pib" nailed
telnet ports quit working. I was able to get them going by adding
"flags = NOLIBWRAP" and changing the wait setting from "yes" to "no" in
the /etc/xinetd.d directory for each d3 nailed telnet port entry. This
seems to be working but I am not sure if changing the wait option is
really a good idea. The d3 admin guide list the setting as being set to
"yes", and this worked for rh7.1. But other examples which have
in.telnetd as the server show it set to "no". Just wandering if you
have come across this problem?
Thanks
Mark Buller
Jonaco Machine.
Patrick Payne wrote:
> It must have been a different situation. I have 3 systems with redhat
> 7.2 d3/7.2.1 and have had no issues restoring from backups.
>
> The only real incompatiblity is in the setup script, requiring you to
> manually enter your disk entries in pick0
>
> (125 user d3 7.2.1 on redhat 7.2)
> (5 user d3 7.2.1 on redhat 7.2)
> (3 user d3 7.2.1 on redhat 7.2)
> (5 user d3 7.2.1 on redhat 7.2 running in a vmware session)
>
> No problems on any of them
>
> rafiq_c...@hotmail.com (rafiq) wrote in message news:<20b5ddb8.02080...@posting.google.com>...
>
>>I know that RainingDate does not officially support redhat 7.2.
>>
>>However, two months ago, with a client I installed redhat 7.2 and
>>D3/Linux.
>>I needed to do this because of better driver support in RedHat 7.2.
>>
>>It seems to be running successfully but I have just heard from another
>>site that when they did the same thing they could not restore D3 from
>>a backup!!
>>
>>Does anybody else have success or horror stories with this installion?
>>
>>Thanks
>>
>>Rafiq
>
Robert Burke
before accepting a new connection. This is the desired behavior when you want only one connection per socket as in
a nailed telnet. A regular telnet connection setup on port 23 would need the wait state set to 'no' or you would
only be able to get 1 connection in at a time.
Since we don't officially support D3 on Redhat 7.2, I don't have it running here in the office so I can't really
try to set this up and figure it out. You might try to load the A105 abs patch and play with the auto-xinet utility
that nails the telnets for you. Usage syntax is in dm,messages, auto-xinet.usage.
Robert Burke
Raining Data Technical Support
mark buller
Thanks for the response. I would have liked to stay on rh7.1 but my
scsi card was not behaving (adpatec 2100s). It appears to have much
better performance on rh7.2.
Anyway, fyi I had to change my xinetd.d entries to :
service d316030
{
disable = no
type = UNLISTED
flags = NOLIBWRAP
socket_type = stream
protocol = tcp
wait = no
server = /usr/sbin/in.telnetd
server_args = -L /usr/bin/d3net/16030
port = 16030
}
the flags = NOLIBWRAP was needed to get rid of this error:
Sep 17 16:45:22 jmi2 xinetd[1319]: warning: can't get client address:
Transport endpoint is not connected
Sep 17 16:45:22 jmi2 xinetd[1319]: libwrap refused connection to d316030
from 0.0.0.0
changing wait from yes to no was need to get rid of the service "loop":
Sep 17 16:45:22 jmi2 xinetd[784]: d316030 service was deactivated
because of looping
I understand what you are saying about the wait yes vs no but I have a
question. According to the man page for xinetd.conf, the flag actually
determines if the service is single-threaded or multi-threaded. The
actual server we are starting is in.telnet.d, which is a multi-threaded
server. in.telnet.d then starts d3 as its "logon" process. If another
telnet session tries to connect to port 16030 after one is logged on to
d3, you see the linux logon prompt. Then I assume d3 refuses the logon
because the pib is already in use, and the connection is "lost". Is this
a problem? The system still works the way you would want. Or am I
missing something?
At any rate I will investigate patch A105 and the auto-xinet utility
Thanks
Mark Buller
Jonaco Machine