Re: [wlug] crossover office
Hi Wayne,
As the previous two responses have hit on you need to have X windows running.
However as far as I know you do not necessarily have to be root to install crossover office I have purchased the full version and it installed and ran from my user account without any problems whatsoever. So if you are just setting it up for personal use on your own workstation then don't bother with becoming root.
The reason that I am suggesting that you do not become root is that when you use su (or similar) to become root much of your environment (particularly the DISPLAY variable which tells programs where to find Xwindows) is lost and could be what is causing your error below.
On Mon, 4 Aug 2003, Wayne D. Garton wrote:
Hello , Wayne here .. absolute beginner! Somebody on this list suggested I use Crossover office to run Excel. However I need help. I have a 30 day trial of Crossover.
I have installed the file install-crossover-office-demo-2[1].0.1.sh in a folder downloads off home I typed sh install-crossover-office-demo-2[1].0.1.sh after pressing Ctrl Alt F3 and logging on as root.
The install for this product loads and then comes back to command prompt and says ... The diplay variable is not set. You should either login as root or use the command "su" with no flags, to make sure setup has an X display to use. What now?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The reason that I am suggesting that you do not become root is that when you use su (or similar) to become root much of your environment (particularly the DISPLAY variable which tells programs where to find Xwindows) is lost and could be what is causing your error below.
actually, the loss of DISPLAY isn't the problem, the loss of ~/.Xauthority is the problem :) (~ == /root not /home/mattb anymore)
- -- He who is known as an early riser need not get up until noon.
If you install as root all users on the machine can use it.
And the problem with su not transferring your environment is usually a problem with your pam config. On my RedHat 9 box:
[oliver] luna:~$ su - Password: [root] luna:~# echo $DISPLAY :0.0
Regards
On Mon, 2003-08-04 at 19:05, Matt Brown wrote:
Hi Wayne,
As the previous two responses have hit on you need to have X windows running.
However as far as I know you do not necessarily have to be root to install crossover office I have purchased the full version and it installed and ran from my user account without any problems whatsoever. So if you are just setting it up for personal use on your own workstation then don't bother with becoming root.
The reason that I am suggesting that you do not become root is that when you use su (or similar) to become root much of your environment (particularly the DISPLAY variable which tells programs where to find Xwindows) is lost and could be what is causing your error below.
On Mon, 4 Aug 2003, Wayne D. Garton wrote:
Hello , Wayne here .. absolute beginner! Somebody on this list suggested I use Crossover office to run Excel. However I need help. I have a 30 day trial of Crossover.
I have installed the file install-crossover-office-demo-2[1].0.1.sh in a folder downloads off home I typed sh install-crossover-office-demo-2[1].0.1.sh after pressing Ctrl Alt F3 and logging on as root.
The install for this product loads and then comes back to command prompt and says ... The diplay variable is not set. You should either login as root or use the command "su" with no flags, to make sure setup has an X display to use. What now?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
If you install as root all users on the machine can use it.
And the problem with su not transferring your environment is usually a problem with your pam config. On my RedHat 9 box:
[oliver] luna:~$ su - Password: [root] luna:~# echo $DISPLAY :0.0
redhat have a pam_xauth which deals with this, most other distros don't. (eg: debian)
- -- Straw? No, too stupid a fad. I put soot on warts.
[oliver] luna:~$ su - Password: [root] luna:~# echo $DISPLAY :0.0
You completely missed the point. The problem is not the missing DISPLAY (you can send your X packets to anywhere you like, including :0.0), the problem is the missing *AUTHORITY* to connect to the specified X server (in this case, :0.0). You can set DISPLAY until you're blue in the face if the X server tells you to get stuffed. And it will (on any decent setup).
su only changes your effective user ID but doesn't deal at all with any X stuff. sux is designed to do an su *as well* as carrying over the X connection authority and setting your DISPLAY.
Volker
PS You almost always want su -, and sux -, this should be default but I guess historic reasons bla bla. Just alias su to su - and sux to sux -.
You completely missed the point. The problem is not the missing DISPLAY (you can send your X packets to anywhere you like, including :0.0), the problem is the missing *AUTHORITY* to connect to the specified X server (in this case, :0.0). You can set DISPLAY until you're blue in the face if the X server tells you to get stuffed. And it will (on any decent setup).
su only changes your effective user ID but doesn't deal at all with any X stuff. sux is designed to do an su *as well* as carrying over the X connection authority and setting your DISPLAY.
No, as Oliver said if you use RH (and I presume many other distros *excluding* debian) su does deal with both DISPLAY and AUTHORITY via the pam_xauth.so PAM module.
Debian definatly do not use this module and I find it's one thing I really miss when using a debian desktop. I tend to ssh -X root@localhost on a debian box if I want to keep the authority and display working correctly. The xauth module seems to tidy this up somewhat.
It has been installed by default for su on RH since at least 7.1 and means that if you su to root, all authority and displays will be preserved.
Jamie
Debian definatly do not use this module and I find it's one thing I really miss when using a debian desktop. I tend to ssh -X root@localhost on a debian box if I want to keep the authority and display working correctly. The xauth module seems to tidy this up somewhat.
Alternatively; you can just run "xhost +" from an xterm, then log in as root and "export DISPLAY=:0" before running the installer.
.. unless your machine is on a 'hostile' network and/or you have untrusted local users ..
--- This email has been sent on 100% RECYCLED electrons!
You completely missed the point. The problem is not the missing DISPLAY (you can send your X packets to anywhere you like, including :0.0), the problem is the missing *AUTHORITY* to connect to the specified X server (in this case, :0.0). You can set DISPLAY until you're blue in the face if the X server tells you to get stuffed. And it will (on any decent setup).
You are absolutely correct. My response was quick and off the cuff. I wasn't thinking the problem through.
su only changes your effective user ID but doesn't deal at all with any X stuff. sux is designed to do an su *as well* as carrying over the X connection authority and setting your DISPLAY.
How handy. However RedHat doesn't come with sux. As Perry pointed out, RedHat uses pam_xauth instead to perform this function so it is transparent to the user.
Regards
-- Oliver Jones § Senior Software Engineer § Deeper Design Limited. oliver@deeper.co.nz § www.deeperdesign.com § +64 (21) 41-2238
participants (6)
-
Jamie Curtis -
Matt Brown -
Oliver Jones -
Perry Lorier -
Volker Kuhlmann -
zcat