Hope this email finds you well.
I need your advice with something if you can help out.
I have an RC serer (selenium rc) which is running on a centos 5.2 and another on a 5.4 machine. if i run it through X server, in other words if i run the server while connected to VNC. it works fine. but if i run it through ssh, it will start normally though upon test execution it will fail with the following error:
11:05:01.571 INFO - Preparing Firefox profile... Error: no display specified 11:05:21.818 ERROR - Failed to start new browser session, shutdown browser and clear all session data java.lang.RuntimeException: Timed out waiting for profile to be created!
11:05:21.833 INFO - Got result: Failed to start new browser session: Error while launching browser on session null
any idea how i can solve this?
Thanks,
--Roland
Roland RoLaNd wrote:
Hope this email finds you well.
I need your advice with something if you can help out.
I have an RC serer (selenium rc) which is running on a centos 5.2 and another on a 5.4 machine. if i run it through X server, in other words if i run the server while connected to VNC. it works fine. but if i run it through ssh, it will start normally though upon test execution it will fail with the following error:
11:05:01.571 INFO - Preparing Firefox profile... Error: no display specified 11:05:21.818 ERROR - Failed to start new browser session, shutdown browser and clear all session data java.lang.RuntimeException: Timed out waiting for profile to be created!
11:05:21.833 INFO - Got result: Failed to start new browser session: Error while launching browser on session null
any idea how i can solve this?
try ssh -X or ssh -Y . man ssh and man ssh_config (search for "forward")
On 03/28/2011 05:58 AM Roland RoLaNd wrote:
Hope this email finds you well.
I need your advice with something if you can help out.
I have an RC serer (selenium rc) which is running on a centos 5.2 and another on a 5.4 machine. if i run it through X server, in other words if i run the server while connected to VNC. it works fine. but if i run it through ssh, it will start normally though upon test execution it will fail with the following error:
11:05:01.571 INFO - Preparing Firefox profile... Error: no display specified 11:05:21.818 ERROR - Failed to start new browser session, shutdown browser and clear all session data java.lang.RuntimeException: Timed out waiting for profile to be created!
11:05:21.833 INFO - Got result: Failed to start new browser session: Error while launching browser on session null
any idea how i can solve this?
Thanks,
--Roland
Like the error says, you need to specify the display. I.e., on the remote machine you must set the environmental variable "DISPLAY"... something like
(export DISPLAY=192.168.1.42:0.0 & firefox)
Though this may work, this may well reveal another, different error, one having to do generally with permissions. But we'll take them one at a time.
hth.
On 3/28/2011 2:31 PM, ken wrote:
I need your advice with something if you can help out.
I have an RC serer (selenium rc) which is running on a centos 5.2 and another on a 5.4 machine. if i run it through X server, in other words if i run the server while connected to VNC. it works fine. but if i run it through ssh, it will start normally though upon test execution it will fail with the following error:
11:05:01.571 INFO - Preparing Firefox profile... Error: no display specified 11:05:21.818 ERROR - Failed to start new browser session, shutdown browser and clear all session data java.lang.RuntimeException: Timed out waiting for profile to be created!
11:05:21.833 INFO - Got result: Failed to start new browser session: Error while launching browser on session null
any idea how i can solve this?
Thanks,
--Roland
Like the error says, you need to specify the display. I.e., on the remote machine you must set the environmental variable "DISPLAY"... something like
(export DISPLAY=192.168.1.42:0.0& firefox)
Though this may work, this may well reveal another, different error, one having to do generally with permissions. But we'll take them one at a time.
Ssh should take care of exporting the correct tunneled DISPLAY if you specified the -Y option when connecting. However, with firefox you have to be careful that the same user does not already have a copy displaying elsewhere. If so, it will try to open a new window in that session instead of starting a new one. I don't think that's the problem in this case or you wouldn't get the 'no display' error, but when it does happen it can be confusing.
Les Mikesell wrote:
On 3/28/2011 2:31 PM, ken wrote:
I need your advice with something if you can help out.
I have an RC serer (selenium rc) which is running on a centos 5.2 and another on a 5.4 machine. if i run it through X server, in other words if i run the server while connected to VNC. it works fine. but if i run it through ssh, it will start normally though upon test execution it will fail with the following error:
11:05:01.571 INFO - Preparing Firefox profile... Error: no display specified 11:05:21.818 ERROR - Failed to start new browser session, shutdown browser and clear all session data java.lang.RuntimeException: Timed out waiting for profile to be created!
11:05:21.833 INFO - Got result: Failed to start new browser session: Error while launching browser on session null
<snip> Two things: first, I assume X is running. Second, did you ssh in with ssh -X?
mark
On Mon, 28 Mar 2011, ken wrote:
Like the error says, you need to specify the display. I.e., on the remote machine you must set the environmental variable "DISPLAY"... something like
(export DISPLAY=192.168.1.42:0.0 & firefox)
Though this may work, this may well reveal another, different error, one having to do generally with permissions. But we'll take them one at a time.
Do *not* follow this advice. It's bad practice, insecure, and actually more work than being secure, and more likely not to work. Plenty of X servers are configured to not listen on your network interface for example.
ssh -X / -Y is your friend, as others have suggested.
jh
On 3/29/11 4:45 AM, John Hodrien wrote:
On Mon, 28 Mar 2011, ken wrote:
Like the error says, you need to specify the display. I.e., on the remote machine you must set the environmental variable "DISPLAY"... something like
(export DISPLAY=192.168.1.42:0.0& firefox)
Though this may work, this may well reveal another, different error, one having to do generally with permissions. But we'll take them one at a time.
Do *not* follow this advice. It's bad practice, insecure, and actually more work than being secure, and more likely not to work. Plenty of X servers are configured to not listen on your network interface for example.
ssh -X / -Y is your friend, as others have suggested.
Although if you regularly run GUI programs remotely, you might want to set up freenx and use the NX client - at least for situations where you want the whole desktop and/or need to work over connections with high latency where normal remote or tunneled X is slow. You don't have to be running X on the remote side's console to use it.
On 03/29/2011 05:45 AM John Hodrien wrote:
On Mon, 28 Mar 2011, ken wrote:
Like the error says, you need to specify the display. I.e., on the remote machine you must set the environmental variable "DISPLAY"... something like
(export DISPLAY=192.168.1.42:0.0 & firefox)
Though this may work, this may well reveal another, different error, one having to do generally with permissions. But we'll take them one at a time.
Do *not* follow this advice. It's bad practice, insecure, and actually more work than being secure, and more likely not to work. Plenty of X servers are configured to not listen on your network interface for example.
ssh -X / -Y is your friend, as others have suggested.
jh
John,
Whether or not it's "more work" is highly subjective. And it's not inherently insecure; people often *make* it insecure by lazily setting permissions to allow *any* server to have access. Even ssh can be insecure if it's not configured properly.
More importantly, I was replying to what the OP posted. The error message pointed to the DISPLAY variable not being set. My reply and response were to that situation. While using ssh tunneling is a great solution in a lot of situations (I've used it myself quite a bit), and it might be a good method for the OP to use, perhaps even in the OP's current situation. Or perhaps s/he's under restrictions you and I aren't privy to which necessitate him/her using something else than what we'd first recommend. So, me, I prefer to work the problem as presented. Others can certainly use other methods.
On Wed, 30 Mar 2011, ken wrote:
John,
Whether or not it's "more work" is highly subjective. And it's not inherently insecure; people often *make* it insecure by lazily setting permissions to allow *any* server to have access. Even ssh can be insecure if it's not configured properly.
You can secure it by other means, but the basic fact is you're sending this over the network in the clear. Yes you could be running a VPN between these two machines, but it's really not a habit worth getting into. So it's not insecure in the same way rsh/rlogin/telnet aren't insecure.
More importantly, I was replying to what the OP posted. The error message pointed to the DISPLAY variable not being set. My reply and response were to that situation. While using ssh tunneling is a great solution in a lot of situations (I've used it myself quite a bit), and it might be a good method for the OP to use, perhaps even in the OP's current situation. Or perhaps s/he's under restrictions you and I aren't privy to which necessitate him/her using something else than what we'd first recommend. So, me, I prefer to work the problem as presented. Others can certainly use other methods.
ssh -Y *does* deal with the situation presented, since it will set the DISPLAY environment variable. It's less work because most of us use ssh already, and this is either a single argument or a default you can set in a config file (automatically matching per host should you wish). It also nests, so I can ssh -Y to one machine, and from there ssh -Y to another and expect X to work. Unless you've not got ssh access to the remote host, what's the downside?
On CentOS the X server is configured by default to not listen on tcp, so setting the DISPLAY variable as you describe would not work if you were trying to connect to a CentOS 5 X server. I'd think that was highly relevent.
But I stand by what I said. You need a reason *not* to tunnel your X traffic between machines. Your method is more prone to failure (due to default X behaviour these days being to not listen on a tcp socket), more fiddly (xhost +machinename, ssh to remote host then set a DISPLAY variable vs "ssh -Y machine"), and less secure (unencrypted traffic).
But feel free to choose a solution appropriate to your needs,
jh
On Wed, Mar 30, 2011 at 7:39 AM, ken gebser@mousecar.com wrote:
On 03/29/2011 05:45 AM John Hodrien wrote:
On Mon, 28 Mar 2011, ken wrote:
Like the error says, you need to specify the display. I.e., on the remote machine you must set the environmental variable "DISPLAY"... something like
(export DISPLAY=192.168.1.42:0.0 & firefox)
Though this may work, this may well reveal another, different error, one having to do generally with permissions. But we'll take them one at a time.
Do *not* follow this advice. It's bad practice, insecure, and actually more work than being secure, and more likely not to work. Plenty of X servers are configured to not listen on your network interface for example.
ssh -X / -Y is your friend, as others have suggested.
jh
John,
Whether or not it's "more work" is highly subjective. And it's not inherently insecure; people often *make* it insecure by lazily setting permissions to allow *any* server to have access. Even ssh can be insecure if it's not configured properly.
The lack of encryption is automatically insecure, and anyone who can start an X program with the 'DISPLAY' set on the remote server can access the X session. I've used this to run 'xroach' on people's systems who refused to secure their X sessions properly. I actually got in trouble for all the screaming.
It's also hideous practice to hardcode that X server in the .bashrc, because logins from home or another system will push the X sessions to that hardcoded X server. Really, it's a bad practice from 20 years ago by people who didn't understand X and who just wanted things to work now. It should *never* be replicated these days, except under the most deranged of circumstances (such as wanting everybody's X programs to pop up on a single, shared X server for public display.)
-
John Hodrien -
ken -
Les Mikesell -
m.roth＠5-cent.us -
Nico Kadel-Garcia -
Nicolas Thierry-Mieg -
Roland RoLaNd