12:09 p.m.
After logging into X (KDE) I start x0vncserver. I tried several options
(-display=:0) but none seem to resolve my issue. From a remote (or the
local system) I try to connect to the server using vncviewer hostname:0, I
get Connection refused. I can telnet hostname 5998 and get a responce. I
have googled around and found nothing. I am missing something just not sure
what? How do I connect to a VNC server?
I am finding I can not connect to any VNC session (not even :1 after
starting it) yet I can telnet to the port. Any input would be greatly
appreciated.
--
Jamie Bohr
12:41 p.m.
Jamie Bohr wrote:
After logging into X (KDE) I start x0vncserver. I tried several
options
(-display=:0) but none seem to resolve my issue. From a remote (or the
local system) I try to connect to the server using vncviewer hostname:0, I
get Connection refused. I can telnet hostname 5998 and get a responce.
I
have googled around and found nothing. I am missing something just not
sure what? How do I connect to a VNC server?
Port 5998 is non-standard for VNC. You would have to specify the port
rather than a display number. For example:
vncviewer hostname::5998
I am finding I can not connect to any VNC session (not even :1 after
starting it) yet I can telnet to the port. Any input would be greatly
appreciated.
Do you have a firewall enabled? Have you looked at the vnc log file to
verify it started? Can you telnet to port 5901?
--
William Hooper
4:41 p.m.
Interesting, I don't know VNC very well I guess. The help section of
x0vncserver (x0vncserver -h) says 5998 is the default. I tried that, I did
not realize I needed to add a double colon (hostname::port). I was using a
single colon. Completely my fault.
On 11/17/06, William Hooper <whooperhsd3(a)earthlink.net> wrote:
Jamie Bohr wrote:
> After logging into X (KDE) I start x0vncserver. I tried several options
> (-display=:0) but none seem to resolve my issue. From a remote (or the
> local system) I try to connect to the server using vncviewer hostname:0,
I
> get Connection refused. I can telnet hostname 5998 and get a responce.
> I
> have googled around and found nothing. I am missing something just not
> sure what? How do I connect to a VNC server?
Port 5998 is non-standard for VNC. You would have to specify the port
rather than a display number. For example:
vncviewer hostname::5998
> I am finding I can not connect to any VNC session (not even :1 after
> starting it) yet I can telnet to the port. Any input would be greatly
> appreciated.
Do you have a firewall enabled? Have you looked at the vnc log file to
verify it started? Can you telnet to port 5901?
--
William Hooper
--
fedora-list mailing list
fedora-list(a)redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
--
Jamie Bohr
5:31 p.m.
Another silly question: where do I put x0vncserver so it will start up when
a user logs into KDE and/or gnome and die when they log out?
- Jamie
On 11/17/06, Jamie Bohr <jamiebohr(a)gmail.com> wrote:
Interesting, I don't know VNC very well I guess. The help section of
x0vncserver (x0vncserver -h) says 5998 is the default. I tried that, I did
not realize I needed to add a double colon (hostname::port). I was using a
single colon. Completely my fault.
On 11/17/06, William Hooper <whooperhsd3(a)earthlink.net> wrote:
>
>
> Jamie Bohr wrote:
> > After logging into X (KDE) I start x0vncserver. I tried several
> options
> > (-display=:0) but none seem to resolve my issue. From a remote (or
> the
> > local system) I try to connect to the server using vncviewer
> hostname:0, I
> > get Connection refused. I can telnet hostname 5998 and get a
> responce.
> > I
> > have googled around and found nothing. I am missing something just
> not
> > sure what? How do I connect to a VNC server?
>
> Port 5998 is non-standard for VNC. You would have to specify the port
> rather than a display number. For example:
>
> vncviewer hostname::5998
>
> > I am finding I can not connect to any VNC session (not even :1 after
> > starting it) yet I can telnet to the port. Any input would be greatly
> > appreciated.
>
> Do you have a firewall enabled? Have you looked at the vnc log file to
> verify it started? Can you telnet to port 5901?
>
> --
> William Hooper
>
> --
> fedora-list mailing list
> fedora-list(a)redhat.com
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
>
--
Jamie Bohr
--
Jamie Bohr
5:39 p.m.
On Fri, 2006-11-17 at 16:31 -0700, Jamie Bohr wrote:
Another silly question: where do I put x0vncserver so it will start
up
when a user logs into KDE and/or gnome and die when they log out?
Don't you want to add the vnc module to your xorg.conf file instead
of running x0vncserver these days?
--
Les Mikesell
lesmikesell(a)gmail.com
7:24 p.m.
No Xvnc is too hard to manage for 100+ users. We would have to set up the
password file for each user that a system is assigned to. Then if another
user logs into that system they will not be able to get to it remotely. I
would like Vnc to act more like terminal services for M$ Windows. For
example, if no one is logged in then allow a remote connection using the
users account password (NIS, LDAP, ...), if someone is logged in then the
password entered must match the password of the user logged in.
Thank you for the suggestion,
Jamie
On 11/17/06, Les Mikesell <lesmikesell(a)gmail.com> wrote:
On Fri, 2006-11-17 at 16:31 -0700, Jamie Bohr wrote:
> Another silly question: where do I put x0vncserver so it will start up
> when a user logs into KDE and/or gnome and die when they log out?
Don't you want to add the vnc module to your xorg.conf file instead
of running x0vncserver these days?
--
Les Mikesell
lesmikesell(a)gmail.com
--
fedora-list mailing list
fedora-list(a)redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
--
Jamie Bohr
8:26 p.m.
On Fri, 2006-11-17 at 19:24, Jamie Bohr wrote:
No Xvnc is too hard to manage for 100+ users. We would have to set
up
the password file for each user that a system is assigned to. Then if
another user logs into that system they will not be able to get to it
remotely. I would like Vnc to act more like terminal services for M$
Windows. For example, if no one is logged in then allow a remote
connection using the users account password (NIS, LDAP, ...), if
someone is logged in then the password entered must match the password
of the user logged in.
Do you really want it to serve the console screen at all? It
isn't necessary - you can let xinetd fire up new connections
on demand to any number of different people at once. The
k12ltsp repackage of fedora has this set up by default. I'm
not sure if the configuration is a stand-alone RPM package
that you can load on a stock fedora or not. The users each
get their own independent session.
--
Les Mikesell
lesmikesell(a)gmail.com
10:04 p.m.
This is for engineers at work. They want to be able to connect to their
consoles remotely. We are using RHEL 3 WS, the tool is only supported on
this platform. The idea is the same as it would be in Fedora though. Start
an X application when the users logs in and kill it when they log out. I
don't mind being pointed to a how to or even KDE/Gnome documentation. I was
able to get KDE to start the process, it just won't die when the user logs
out.
On 11/17/06, Les Mikesell <lesmikesell(a)gmail.com> wrote:
On Fri, 2006-11-17 at 19:24, Jamie Bohr wrote:
> No Xvnc is too hard to manage for 100+ users. We would have to set up
> the password file for each user that a system is assigned to. Then if
> another user logs into that system they will not be able to get to it
> remotely. I would like Vnc to act more like terminal services for M$
> Windows. For example, if no one is logged in then allow a remote
> connection using the users account password (NIS, LDAP, ...), if
> someone is logged in then the password entered must match the password
> of the user logged in.
Do you really want it to serve the console screen at all? It
isn't necessary - you can let xinetd fire up new connections
on demand to any number of different people at once. The
k12ltsp repackage of fedora has this set up by default. I'm
not sure if the configuration is a stand-alone RPM package
that you can load on a stock fedora or not. The users each
get their own independent session.
--
Les Mikesell
lesmikesell(a)gmail.com
--
fedora-list mailing list
fedora-list(a)redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
--
Jamie Bohr
10:39 p.m.
On Fri, 2006-11-17 at 22:04, Jamie Bohr wrote:
This is for engineers at work. They want to be able to connect to
their consoles remotely. We are using RHEL 3 WS, the tool is only
supported on this platform. The idea is the same as it would be in
Fedora though. Start an X application when the users logs in and kill
it when they log out. I don't mind being pointed to a how to or even
KDE/Gnome documentation. I was able to get KDE to start the process,
it just won't die when the user logs out.
If they want to run a single application, they can just
ssh in and start it by typing its name. The ssh internal
port forwarding magic will forward the window display to the
local desktop. From newer versions of ssh you may need to
use the -X or -Y options to enable X forwarding.
If you want the whole desktop, you can use native X by
enabling XDMCP logins. From any other machine, start the
local display with 'X -query remote_host' and you will get
a graphic login prompt followed by a desktop session running
on the remote by displayed local to you. This works best on
a fast local LAN and is cross-platform with the free Cygwin
windows version or Xming.
After XDMCP sessions are working you can also let vnc start
sessions on demand. K12ltsp does it something like this:
Add entries to /etc/services like:
vnc-1024x768x16 5900/tcp
vnc-800x600x16 5901/tcp
..etc.. mapping ports to display types
Screen :0 will be port 5900 to vnc, :1 is 5901, etc.
Add a file named /etc/xinetd.d/vncts with entries like:
service vnc-1024x768x16
{
disable = no
socket_type = stream
wait = no
user = nobody
group = tty
server = /usr/bin/vncts
server_args = -geometry 1024x768 -depth 16
}
service vnc-800x600x16
{
disable = no
socket_type = stream
wait = no
user = nobody
group = tty
server = /usr/bin/vncts
server_args = -geometry 800x600 -depth 16
}
And add /usr/bin/vncts:
#!/bin/sh
VNCTSOPTIONS=""
[ -f /etc/sysconfig/vncts ] && . /etc/sysconfig/vncts
exec
${XVNC:-/usr/bin/Xvnc} ${VNCTSOPTIONS} ${1+"$@"}
And restart xinetd. This makes a vnc connection start
up an X session which will go away when you disconnect.
--
Les Mikesell
lesmikesell(a)gmail.com
8:14 a.m.
The remote systems are Windows. The company VPN client does not support
Linux too well and a majority (99.9%, especially labtops) of the systems are
running MS Windows. The engineers want and need to see their consoles
remotely.
I appreciate all the suggestions, please don't think I don't. I have talked
with the engineers about all the solutions mentioned, none will work because
they involve stopping an already running appication and fireing up vncserver
(by what ever means) and then starting the application again. They want to
be able to see their already running desktop remotely.
On 11/17/06, Les Mikesell <lesmikesell(a)gmail.com> wrote:
On Fri, 2006-11-17 at 22:04, Jamie Bohr wrote:
> This is for engineers at work. They want to be able to connect to
> their consoles remotely. We are using RHEL 3 WS, the tool is only
> supported on this platform. The idea is the same as it would be in
> Fedora though. Start an X application when the users logs in and kill
> it when they log out. I don't mind being pointed to a how to or even
> KDE/Gnome documentation. I was able to get KDE to start the process,
> it just won't die when the user logs out.
If they want to run a single application, they can just
ssh in and start it by typing its name. The ssh internal
port forwarding magic will forward the window display to the
local desktop. From newer versions of ssh you may need to
use the -X or -Y options to enable X forwarding.
If you want the whole desktop, you can use native X by
enabling XDMCP logins. From any other machine, start the
local display with 'X -query remote_host' and you will get
a graphic login prompt followed by a desktop session running
on the remote by displayed local to you. This works best on
a fast local LAN and is cross-platform with the free Cygwin
windows version or Xming.
After XDMCP sessions are working you can also let vnc start
sessions on demand. K12ltsp does it something like this:
Add entries to /etc/services like:
vnc-1024x768x16 5900/tcp
vnc-800x600x16 5901/tcp
..etc.. mapping ports to display types
Screen :0 will be port 5900 to vnc, :1 is 5901, etc.
Add a file named /etc/xinetd.d/vncts with entries like:
service vnc-1024x768x16
{
disable = no
socket_type = stream
wait = no
user = nobody
group = tty
server = /usr/bin/vncts
server_args = -geometry 1024x768 -depth 16
}
service vnc-800x600x16
{
disable = no
socket_type = stream
wait = no
user = nobody
group = tty
server = /usr/bin/vncts
server_args = -geometry 800x600 -depth 16
}
And add /usr/bin/vncts:
#!/bin/sh
VNCTSOPTIONS=""
[ -f /etc/sysconfig/vncts ] && . /etc/sysconfig/vncts
exec ${XVNC:-/usr/bin/Xvnc} ${VNCTSOPTIONS} ${1+"$@"}
And restart xinetd. This makes a vnc connection start
up an X session which will go away when you disconnect.
--
Les Mikesell
lesmikesell(a)gmail.com
--
fedora-list mailing list
fedora-list(a)redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
--
Jamie Bohr
11:19 a.m.
Jamie Bohr wrote:
The remote systems are Windows. The company VPN client does not
support
Linux too well and a majority (99.9%, especially labtops) of the systems
are running MS Windows. The engineers want and need to see their
consoles remotely.
I appreciate all the suggestions, please don't think I don't. I have
talked with the engineers about all the solutions mentioned, none will
work because they involve stopping an already running appication and
fireing up vncserver (by what ever means) and then starting the
application again. They want to be able to see their already running
desktop remotely.
Try x11vnc. There is an rpm in the Dries RPM repository for FC4 that
works on my FC6 system. Though it would probably be a good idea to
rebuild it from the source rpm.
Cheers,
Raman
1:56 p.m.
On Sat, 2006-11-18 at 08:14, Jamie Bohr wrote:
The remote systems are Windows. The company VPN client does not
support Linux too well and a majority (99.9%, especially labtops) of
the systems are running MS Windows. The engineers want and need to
see their consoles remotely.
OK, I was confused by your earlier comment about different
users logging in and assumed they wanted to start different
sessions.
I appreciate all the suggestions, please don't think I don't.
I have
talked with the engineers about all the solutions mentioned, none will
work because they involve stopping an already running appication and
fireing up vncserver (by what ever means) and then starting the
application again. They want to be able to see their already running
desktop remotely.
There is one other option to consider, especially if the
application doesn't normally take a lot of interaction. You
can run vncserver in the first place to start a session
not connected to any console, connect to it with a viewer
and start the app. After that you can disconnect at
any time and reconnect from other places. The password
used to connect is assigned specifically for vnc and
doesn't have to be related to the user running the
session.
But, if you want to connect to the real console screen you
are back to either x0vncserver or the X vnc module.
I believe the latter is more efficient but will require one
restart of X to get the module loaded. Basically you
edit your XF86Config or xorg.conf file to include:
Load "vnc"
in the "Module" section and
Option "passwordfile" "/path/to/passwd"
in the "Screen" section and it will act as I described
for vncserver except you connect to screen :0.
While I'm rambling, I might as well mention one other thing
that might be an option, again depending on the nature of
the app. You could run the whole server as a virtual
machine under the free VMWare server. The product includes
a separate console viewer that works more or less like
vnc and works cross-platform between linux and windows
and again it would not be tied to a real screen but you
could connect and run fullscreen from there if you wanted
to make it look that way.
--
Les Mikesell
lesmikesell(a)gmail.com
5:16 p.m.
We run Windows on the Linux workstation in VMWare server. Works pretty
good, there are issues when we copy an exsisting vm session to another
system, but that is another story.
The application is very graphic and CPU intensive, running it on a VM
doesn't work. Good idea though.
Can I assume there is no functionality built into KDE & Gnome to start a
process when a person logs in (I am able to do this) and stop it when they
log out (this seems to be the problem)?
On 11/18/06, Les Mikesell <lesmikesell(a)gmail.com> wrote:
On Sat, 2006-11-18 at 08:14, Jamie Bohr wrote:
> The remote systems are Windows. The company VPN client does not
> support Linux too well and a majority (99.9%, especially labtops) of
> the systems are running MS Windows. The engineers want and need to
> see their consoles remotely.
OK, I was confused by your earlier comment about different
users logging in and assumed they wanted to start different
sessions.
> I appreciate all the suggestions, please don't think I don't. I have
> talked with the engineers about all the solutions mentioned, none will
> work because they involve stopping an already running appication and
> fireing up vncserver (by what ever means) and then starting the
> application again. They want to be able to see their already running
> desktop remotely.
There is one other option to consider, especially if the
application doesn't normally take a lot of interaction. You
can run vncserver in the first place to start a session
not connected to any console, connect to it with a viewer
and start the app. After that you can disconnect at
any time and reconnect from other places. The password
used to connect is assigned specifically for vnc and
doesn't have to be related to the user running the
session.
But, if you want to connect to the real console screen you
are back to either x0vncserver or the X vnc module.
I believe the latter is more efficient but will require one
restart of X to get the module loaded. Basically you
edit your XF86Config or xorg.conf file to include:
Load "vnc"
in the "Module" section and
Option "passwordfile" "/path/to/passwd"
in the "Screen" section and it will act as I described
for vncserver except you connect to screen :0.
While I'm rambling, I might as well mention one other thing
that might be an option, again depending on the nature of
the app. You could run the whole server as a virtual
machine under the free VMWare server. The product includes
a separate console viewer that works more or less like
vnc and works cross-platform between linux and windows
and again it would not be tied to a real screen but you
could connect and run fullscreen from there if you wanted
to make it look that way.
--
Les Mikesell
lesmikesell(a)gmail.com
--
fedora-list mailing list
fedora-list(a)redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
--
Jamie Bohr
9:02 p.m.
On Sat, 2006-11-18 at 17:16, Jamie Bohr wrote:
We run Windows on the Linux workstation in VMWare server. Works
pretty good, there are issues when we copy an exsisting vm session to
another system, but that is another story.
The application is very graphic and CPU intensive, running it on a VM
doesn't work. Good idea though.
You probably aren't going to like it much under VNC either
then, unless it is just for an occassional remote check on
progress.
Can I assume there is no functionality built into KDE & Gnome to
start
a process when a person logs in (I am able to do this) and stop it
when they log out (this seems to be the problem)?
All processes normally stop when you log out unless they
do something to dissociate from the terminal. Connecting
with vnc and disconnecting don't count as logins, though.
Can you be more specific about what you want to happen?
--
Les Mikesell
lesmikesell(a)gmail.com
9:13 p.m.
Please see comments below.
On 11/18/06, Les Mikesell <lesmikesell(a)gmail.com> wrote:
On Sat, 2006-11-18 at 17:16, Jamie Bohr wrote:
> We run Windows on the Linux workstation in VMWare server. Works
> pretty good, there are issues when we copy an exsisting vm session to
> another system, but that is another story.
>
> The application is very graphic and CPU intensive, running it on a VM
> doesn't work. Good idea though.
You probably aren't going to like it much under VNC either
then, unless it is just for an occassional remote check on
progress.
Yes, occassional use but on the fly. Say an Engineer is working on a
project and then leaves for home. They stay logged into their workstation.
Now say they want to work from home on the same project, the very one they
have up. They want to be able to connect to their display remotely.
Can I assume there is no functionality built into KDE & Gnome to
start
> a process when a person logs in (I am able to do this) and stop it
> when they log out (this seems to be the problem)?
All processes normally stop when you log out unless they
do something to dissociate from the terminal. Connecting
with vnc and disconnecting don't count as logins, though.
Can you be more specific about what you want to happen?
The Engineer stay logged in.
I'm off on vacation this week but when I get back in the office I will try
the x11VNC that was suggested. It sounds more along the lines of what I
need.
--
Les Mikesell
lesmikesell(a)gmail.com
--
fedora-list mailing list
fedora-list(a)redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
--
Jamie Bohr
6:34 p.m.
Finally getting to this and am having difficulties.
If I read the man page on x11vnc it tells me to use -unixpw but it never
lists it as a valid option. The FAQ locate
here<http://www.karlrunge.com/x11vnc/#faq-userlogin>indicates that I
should run "x11vnc -unixpw -display WAIT:cmd=/tmp/display"
(where /tmp/display finds the current display name, script was copied from
the page mentioned above) but I get an error indicating -unixpw is not a
valid option, see below:
...
19/01/2007 17:19:38 x11vnc version: 0.8.2 lastmod: 2006-07-12
19/01/2007 17:19:38 initialize_screen: fb_depth/fb_bpp/fb_Bpl 24/32/2560
19/01/2007 17:19:38 *** unrecognized option(s) ***
19/01/2007 17:19:38 [1] -unixpw
19/01/2007 17:19:38 For a list of options run: x11vnc -opts
19/01/2007 17:19:38 or for the full help: x11vnc -help
....
x11vnc -help mentions -unixpw as an option but does not state it as one. Am
I missing something? I am trying to run this at the command line so I can
test it.
Thank you for your help,
Jamie Bohr
On 11/18/06, Jamie Bohr <jamiebohr(a)gmail.com> wrote:
Please see comments below.
On 11/18/06, Les Mikesell <lesmikesell(a)gmail.com> wrote:
>
> On Sat, 2006-11-18 at 17:16, Jamie Bohr wrote:
> > We run Windows on the Linux workstation in VMWare server. Works
> > pretty good, there are issues when we copy an exsisting vm session to
> > another system, but that is another story.
> >
> > The application is very graphic and CPU intensive, running it on a VM
> > doesn't work. Good idea though.
>
> You probably aren't going to like it much under VNC either
> then, unless it is just for an occassional remote check on
> progress.
Yes, occassional use but on the fly. Say an Engineer is working on a
project and then leaves for home. They stay logged into their workstation.
Now say they want to work from home on the same project, the very one they
have up. They want to be able to connect to their display remotely.
> Can I assume there is no functionality built into KDE & Gnome to start
> > a process when a person logs in (I am able to do this) and stop it
> > when they log out (this seems to be the problem)?
>
> All processes normally stop when you log out unless they
> do something to dissociate from the terminal. Connecting
> with vnc and disconnecting don't count as logins, though.
> Can you be more specific about what you want to happen?
The Engineer stay logged in.
I'm off on vacation this week but when I get back in the office I will try
the x11VNC that was suggested. It sounds more along the lines of what I
need.
--
> Les Mikesell
> lesmikesell(a)gmail.com
>
>
> --
> fedora-list mailing list
> fedora-list(a)redhat.com
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
>
--
Jamie Bohr
--
Jamie Bohr
12:39 a.m.
On Saturday 18 November 2006 18:16, Jamie Bohr wrote:
Can I assume there is no functionality built into KDE & Gnome to start a
process when a person logs in (I am able to do this) and stop it when they
log out (this seems to be the problem)?
In kde : programs are started if they are put in ~/.kde/env
and programs in ~/.kde/shutdown are run when you log out.
If this helps ...
6299
days inactive
6363
days old
16 comments
5 participants
participants (5)
-
Genes MailLists -
Jamie Bohr -
Les Mikesell -
Raman Gupta -
William Hooper