dbaccess & hosts.equiv
A DBA running Informix 11.70.FC7 on Solaris used /etc/hosts.equiv to let scheduled dbaccess scripts on a central app server connect trusted to many remote DB servers, but wanted an alternative (they lacked root to maintain that file). Several respondents pointed to the ONCONFIG parameter REMOTE_SERVER_CFG, which lets you place a file with the same syntax elsewhere (e.g. $INFORMIXDIR/etc) affecting only Informix; sqlhosts s=2/s=3 options were also mentioned. The poster confirmed REMOTE_SERVER_CFG solved it.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi we are running Informix 11.70.FC7 on Solaris.
We have many scripts running via a scheduler from a central application
server and uses dbaccess to connect to many different DB servers on remote
servers. Historically, we have used hosts.equiv to allow the apps server
to connect to the db servers. This method has raised some issues and
concerns lately. Is there another way/method to set things up so that the
scripts can still run using dbaccess and won't rely on hosts.equiv for the
DB connection?
Thank You,
--Dave
--94eb2c1b5038f6a8f7054b68679b
Use REMOTE_SERVER_CFG and create your own hosts.equiv instead of using the
OS one ?
Cheers
Paul
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Informix DBA
Sent: Thursday, March 23, 2017 11:31 AM
To: ids@iiug.org
Subject: dbaccess & hosts.equiv [38795]
Hi we are running Informix 11.70.FC7 on Solaris.
We have many scripts running via a scheduler from a central application
server and uses dbaccess to connect to many different DB servers on remote
servers. Historically, we have used hosts.equiv to allow the apps server
to connect to the db servers. This method has raised some issues and
concerns lately. Is there another way/method to set things up so that the
scripts can still run using dbaccess and won't rely on hosts.equiv for the
DB connection?
Thank You,
--Dave
--94eb2c1b5038f6a8f7054b68679b
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
https://www.ibm.com/support/knowledgecenter/en/SSGU8G_11.70.0/com.ibm.admin.doc/
ids_admin_1407.htm
Check this link. The system-wide hosts.equiv can be moved in INFORMIX/etc or
another location to not allow
rsh/rlogin to take the same rights (although everybody should have banned
these products ...).
Also check out the sqlhosts manual regrading the parameters s=2/s=3, which can
modify the trust behaviour.
The location can be modified with REMOTE_SERVER_CFG parameter.
Marcus Haarmann
Von: "Informix DBA" <in4mixdba@gmail.com>
An: "ids" <ids@iiug.org>
Gesendet: Donnerstag, 23. März 2017 17:31:21
Betreff: dbaccess & hosts.equiv [38795]
Hi we are running Informix 11.70.FC7 on Solaris.
We have many scripts running via a scheduler from a central application
server and uses dbaccess to connect to many different DB servers on remote
servers. Historically, we have used hosts.equiv to allow the apps server
to connect to the db servers. This method has raised some issues and
concerns lately. Is there another way/method to set things up so that the
scripts can still run using dbaccess and won't rely on hosts.equiv for the
DB connection?
Thank You,
--Dave
--94eb2c1b5038f6a8f7054b68679b
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
I guess you're talking about /etc/hosts.equiv ? An easy and Informix-only alternative nowadays is having a very similar=20 file (same syntax) in $INFORMIXDIR/etc and the REMOTE=5FSERVER=5FCFG onconf= ig=20 parameter holding this file's name. HTH, Andreas
Yes. There is an Informix specific file with the same format and effect as
/etc/hosts.equiv but it is restricted in effect to the Informix engine
only. The file is identified by the path listed in the ONCONFIG
variable REMOTE_SERVER_CFG.
This is discussed in the Administrator's Guide and the variable is listed
in the Administrator's Reference Manual. Or you can look up these in the
Informix Knowledge Center.
Art
Art S. Kagel, President and Principal Consultant
ASK Database Management
www.askdbmgt.com
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on the IIUG, nor any other organization with which I am
associated either explicitly, implicitly, or by inference. Neither do
those opinions reflect those of other individuals affiliated with any
entity with which I am affiliated nor those of the entities themselves.
On Thu, Mar 23, 2017 at 12:31 PM, Informix DBA <in4mixdba@gmail.com> wrote:
> Hi we are running Informix 11.70.FC7 on Solaris.
>
> We have many scripts running via a scheduler from a central application
> server and uses dbaccess to connect to many different DB servers on remote
> servers. Historically, we have used hosts.equiv to allow the apps server
> to connect to the db servers. This method has raised some issues and
> concerns lately. Is there another way/method to set things up so that the
> scripts can still run using dbaccess and won't rely on hosts.equiv for the
> DB connection?
>
> Thank You,
>
> --Dave
>
> --94eb2c1b5038f6a8f7054b68679b
>
>
> ************************************************************
> *******************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--94eb2c0d738ea10967054b68982d
Can you elaborate on the concerns raised by the use of hosts.equiv? But
yes, there are other options. Let us know what are the concerns please.
On Thu, Mar 23, 2017 at 4:31 PM, Informix DBA <in4mixdba@gmail.com> wrote:
> Hi we are running Informix 11.70.FC7 on Solaris.
>
> We have many scripts running via a scheduler from a central application
> server and uses dbaccess to connect to many different DB servers on remote
> servers. Historically, we have used hosts.equiv to allow the apps server
> to connect to the db servers. This method has raised some issues and
> concerns lately. Is there another way/method to set things up so that the
> scripts can still run using dbaccess and won't rely on hosts.equiv for the
> DB connection?
>
> Thank You,
>
> --Dave
>
> --94eb2c1b5038f6a8f7054b68679b
>
>
> ************************************************************
> *******************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
--94eb2c19e8c8e40ff3054b68ae2b
Hi All,
Thank you very much. Yes for now the REMOTE_SERVER_CFG suggestion resolves
the issue. The challenge was related to not having root access to
modify/maintain the /etc/hosts.equiv.
Thank you,
--Dave
On Thu, Mar 23, 2017 at 12:51 PM, Fernando Nunes <domusonline@gmail.com>
wrote:
> Can you elaborate on the concerns raised by the use of hosts.equiv? But
> yes, there are other options. Let us know what are the concerns please.
>
> On Thu, Mar 23, 2017 at 4:31 PM, Informix DBA <in4mixdba@gmail.com> wrote:
>
> > Hi we are running Informix 11.70.FC7 on Solaris.
> >
> > We have many scripts running via a scheduler from a central application
> > server and uses dbaccess to connect to many different DB servers on
> remote
> > servers. Historically, we have used hosts.equiv to allow the apps server
> > to connect to the db servers. This method has raised some issues and
> > concerns lately. Is there another way/method to set things up so that the
> > scripts can still run using dbaccess and won't rely on hosts.equiv for
> the
> > DB connection?
> >
> > Thank You,
> >
> > --Dave
> >
> > --94eb2c1b5038f6a8f7054b68679b
> >
> >
> > ************************************************************
> > *******************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --
> Fernando Nunes
> Portugal
>
> http://informix-technology.blogspot.com
> My email works... but I don't check it frequently...
>
> --94eb2c19e8c8e40ff3054b68ae2b
>
>
> ************************************************************
> *******************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--001a114739585e8899054b695aeb