[CentOS] Failed to start new browser session: Error while launching browser on session null

John Hodrien J.H.Hodrien at leeds.ac.uk
Wed Mar 30 11:54:17 UTC 2011


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



More information about the CentOS mailing list