Re: HELP: iAS Display /etc/hosts settings?

"AF" <af_at_nospam.com> writes:

> Help Please:
> Version: iAS902 on Redhat LINUX 7.3
>
> Problem:
> Seems to be a conflict in the settings required by ORACLE and LINUX.
> Need help properly configuring the settings.
>
> Description:
> The docs for iAS and iDB require that DISPLAY be set to the name of the
> Machine. For the example we will use the machine tahati.oracle.com
> export DISPLAY=tahati.oracle.com:0.0
>
> Redhat sets up the /etc/hosts:
> 127.0.0.1 tahati.oracle.com tahati localhost.localdomain localhost
>
> This setting will cause problems with the Intelligent Agent And I assume
> other problems with iAS as well. The install notes for the agent (and
> iDB9.2) states that the /etc/hosts file must be changed to:
> 127.0.0.1 localhost.localdomain localhost
> 148.87.9.74 tahati.oracle.com tahati
>
> With /etc/hosts and DISPLAY set to the required ORACLE settings all X
> applications will not work because of xhost. Executing xhost +tahati allows
> it to work but now I have what can only be described as inconsistent
> behavior.
>
> Is it correct to set DISPLAY=localhost for iAS startup (after install is
> complete)?
> Does any part of the system like forms, reports or em, use the DISPLAY env
> var while running?
>
> Thanks for any help
>

I think your main problem here stems from insufficient X windows information. Once you understand this, it should become pretty straight forward. I would suggest you consult some of the X documentation and HOWTO docs from the Linux Documentation Homepage (www.ldp.org I think).

Assuming IP numbers are correct etc, the correct format for your /etc/hosts is
127.0.0.1 localhost.localdomain localhost 148.87.9.74 tahati.oracle.com tahati

I think the default way redhat does the /etc/hosts file is not strictly correct and they do it because they have a large number of uses who are not connected to a LAN and only connect to the internet via dial-up.

Avoid using xhost if you are at all concerned about security - xhost is an insecure and outdated access control method for X windows. Instead, read about xauth. Xauth is a more secure "magic cookie" based access control mechanism for X windows. I'm pretty sure RedHat (and most other linux distributions) are configured to use xauth by default - they certainly all support it. Under this approach, you have an .Xauthority file created when you log in. any user which wants to display output on your terminal must have the cookie from the .Xauthority file. So, if I wanted to run an X application on a remote host, I simply need to merger the cookie from my local .Xauthority file into the remote .Xauthority file, set the DISPLAY variable on the remote host and then run the remote X application. The problem with xhost authentication is that it is host based - you don't just give access to a user+host to access your X display, you give access to any user on the host you add with the xhost command. Of course, this is not always a problem - especially if the host you are adding does not have multiple users. I think Oracle only reference the xhost option because its simpler to use/understand and therefore will require less support.

With respect to display variables, you usually have a couple of possibilities. If you are running X apps on the local system and they will be displayed on the local terminal, you should be able to get away with only setting display to just :0.0 or localhost:0.0 or host.domain.com:0.0

A full host:display.screen specification is usually only necessary if you want the X output displayed on a non-local terminal etc.

As long as you set and export the display variable before any X application runs (e.g. in a parent process), you *should* be able to use either DISPLAY=:0.0 or DISPLAY=localhost:0.0 - however, check the X documentation for the X server version you are running - there was a minor problem in X DISPLAY variable settings, but I think this has been fixed. From memory, I think it worked with just the ":0.0" setting, but didn't work for some apps if you used a "localhost:0.0" setting.

Tim Received on Tue Jul 23 2002 - 19:06:18 CDT