Page 1 of 2 12 LastLast
Results 1 to 10 of 15

Thread: Yast Remote Admin (VNC) module - multiple issues/questions

  1. #1
    Join Date
    Aug 2008
    Location
    Brazil
    Posts
    2,640

    Default Yast Remote Admin (VNC) module - multiple issues/questions

    Hi,

    KDE desktop.

    I want to access a LEAP 42.3 box in the LAN (ethernet, CAT5) from another box (oS 13.2) in the same LAN. I don't want to allow remote connection outside the LAN. I want a full remote desktop to run software in the LEAP box from the oS 13.2 box, if possible with copy/paste between boxes.

    LEAP box:

    There's a VNC module in Yast that AFAIU allow activation of a VNC server. In this module I can select "Allow remote admin", with or without "session management", but the Firewall configuration in the same dialog say the firewall is disabled. However the Firewall module say it is being executed. Why?

    The LEAP box ethernet interface is configured as external zone (it was unassigned at first). I did include VNC on the firewall allowed services, but the VNC module still say firewall is disabled. I haven't yet try to connect with a client.

    After selecting any of the two "Allow remote admin etc..." on exiting the module the LEAP box drop to the first terminal (ALT+CTRL+F1). The graphics (ALT+CTRL+F1) terminal is just a black screen with a blinking cursor IIRC. All others except F1 are pure black, no cursor. I can log to root, but "reboot" does nothing, and appear to freeze the terminal. "reboot -h now" works after maybe 20-30 seconds. Then the box powers up normally to KDE.

    This drop to terminal also happened on the first run of the module after it installed a xorg-x11 package that pulled a number of dependencies:

    >rpm -qa --last | grep "19 Set 2017"
    proxymngr-1.0.4-4.1.x86_64 Ter 19 Set 2017 19:06:10 -03
    xwud-1.0.4-14.1.x86_64 Ter 19 Set 2017 19:06:09 -03
    xwininfo-1.1.3-10.1.x86_64 Ter 19 Set 2017 19:06:09 -03
    xtrap-1.0.2-14.2.x86_64 Ter 19 Set 2017 19:06:09 -03
    xprehashprinterlist-1.0.1-14.1.x86_64 Ter 19 Set 2017 19:06:09 -03
    xplsprinters-1.0.1-14.1.x86_64 Ter 19 Set 2017 19:06:09 -03
    xfsinfo-1.0.5-7.1.x86_64 Ter 19 Set 2017 19:06:09 -03
    xf86dga-1.0.3-14.1.x86_64 Ter 19 Set 2017 19:06:09 -03
    xdpyinfo-1.3.2-4.3.x86_64 Ter 19 Set 2017 19:06:09 -03
    showfont-1.0.5-6.1.x86_64 Ter 19 Set 2017 19:06:09 -03
    libXprintUtil1-1.0.1-15.3.x86_64 Ter 19 Set 2017 19:06:09 -03
    lbxproxy-1.0.3-10.1.x86_64 Ter 19 Set 2017 19:06:09 -03
    fstobdf-1.0.6-6.1.x86_64 Ter 19 Set 2017 19:06:09 -03
    fslsfonts-1.0.5-6.1.x86_64 Ter 19 Set 2017 19:06:09 -03
    xwd-1.0.6-10.1.x86_64 Ter 19 Set 2017 19:06:08 -03
    xvinfo-1.1.3-4.1.x86_64 Ter 19 Set 2017 19:06:08 -03
    xvidtune-1.0.3-12.1.x86_64 Ter 19 Set 2017 19:06:08 -03
    xstdcmap-1.0.3-10.1.x86_64 Ter 19 Set 2017 19:06:08 -03
    xsm-1.0.3-10.1.x86_64 Ter 19 Set 2017 19:06:08 -03
    xsetpointer-1.0.1-14.1.x86_64 Ter 19 Set 2017 19:06:08 -03
    xsetmode-1.0.0-14.1.x86_64 Ter 19 Set 2017 19:06:08 -03
    xscope-1.4.1-6.1.x86_64 Ter 19 Set 2017 19:06:08 -03
    xrx-1.0.4-14.1.x86_64 Ter 19 Set 2017 19:06:08 -03
    xrestop-0.4-14.1.x86_64 Ter 19 Set 2017 19:06:08 -03
    xrefresh-1.0.5-8.3.x86_64 Ter 19 Set 2017 19:06:08 -03
    xpr-1.0.4-14.1.x86_64 Ter 19 Set 2017 19:06:08 -03
    xmore-1.0.2-14.1.x86_64 Ter 19 Set 2017 19:06:07 -03
    xman-1.1.4-6.1.x86_64 Ter 19 Set 2017 19:06:07 -03
    xmag-1.0.6-4.2.x86_64 Ter 19 Set 2017 19:06:07 -03
    xlsfonts-1.0.5-4.1.x86_64 Ter 19 Set 2017 19:06:07 -03
    xlsclients-1.1.3-9.1.x86_64 Ter 19 Set 2017 19:06:07 -03
    xlsatoms-1.1.2-4.1.x86_64 Ter 19 Set 2017 19:06:07 -03
    xlogo-1.0.4-13.1.x86_64 Ter 19 Set 2017 19:06:07 -03
    xload-1.1.2-10.2.x86_64 Ter 19 Set 2017 19:06:07 -03
    xkill-1.0.4-9.2.x86_64 Ter 19 Set 2017 19:06:07 -03
    xkbutils-1.0.4-10.1.x86_64 Ter 19 Set 2017 19:06:07 -03
    xkbprint-1.0.4-4.1.x86_64 Ter 19 Set 2017 19:06:07 -03
    xkbevd-1.1.4-4.1.x86_64 Ter 19 Set 2017 19:06:07 -03
    xinput-1.6.1-10.1.x86_64 Ter 19 Set 2017 19:06:07 -03
    xgc-1.0.5-6.1.x86_64 Ter 19 Set 2017 19:06:06 -03
    xgamma-1.0.6-4.1.x86_64 Ter 19 Set 2017 19:06:06 -03
    xfwp-1.0.3-10.1.x86_64 Ter 19 Set 2017 19:06:06 -03
    xfs-1.1.4-8.2.x86_64 Ter 19 Set 2017 19:06:06 -03
    xfontsel-1.0.5-9.1.x86_64 Ter 19 Set 2017 19:06:06 -03
    xfindproxy-1.0.4-6.1.x86_64 Ter 19 Set 2017 19:06:06 -03
    xfd-1.1.2-9.1.x86_64 Ter 19 Set 2017 19:06:06 -03
    xeyes-1.1.1-13.1.x86_64 Ter 19 Set 2017 19:06:06 -03
    xev-1.2.2-4.1.x86_64 Ter 19 Set 2017 19:06:06 -03
    xedit-1.2.2-6.1.x86_64 Ter 19 Set 2017 19:06:06 -03
    xditview-1.0.4-6.1.x86_64 Ter 19 Set 2017 19:06:06 -03
    xdbedizzy-1.1.0-14.1.x86_64 Ter 19 Set 2017 19:06:06 -03
    xcursorgen-1.0.6-6.1.x86_64 Ter 19 Set 2017 19:06:05 -03
    xcompmgr-1.1.7-6.1.x86_64 Ter 19 Set 2017 19:06:05 -03
    xcmsdb-1.0.5-6.1.x86_64 Ter 19 Set 2017 19:06:05 -03
    xclock-1.0.7-9.1.x86_64 Ter 19 Set 2017 19:06:05 -03
    xclipboard-1.1.3-10.2.x86_64 Ter 19 Set 2017 19:06:05 -03
    xcalc-1.0.6-6.2.x86_64 Ter 19 Set 2017 19:06:05 -03
    xbiff-1.0.3-12.1.x86_64 Ter 19 Set 2017 19:06:05 -03
    xbacklight-1.2.1-8.1.x86_64 Ter 19 Set 2017 19:06:05 -03
    x11perf-1.6.0-4.1.x86_64 Ter 19 Set 2017 19:06:05 -03
    viewres-1.0.4-9.1.x86_64 Ter 19 Set 2017 19:06:05 -03
    twm-1.0.9-6.2.x86_64 Ter 19 Set 2017 19:06:05 -03
    smproxy-1.0.6-6.1.x86_64 Ter 19 Set 2017 19:06:05 -03
    rstart-1.0.5-8.1.x86_64 Ter 19 Set 2017 19:06:05 -03
    rendercheck-1.5-4.1.x86_64 Ter 19 Set 2017 19:06:04 -03
    oclock-1.0.3-14.1.x86_64 Ter 19 Set 2017 19:06:04 -03
    mkcomposecache-1.2.1-12.1.x86_64 Ter 19 Set 2017 19:06:04 -03
    listres-1.0.3-13.1.x86_64 Ter 19 Set 2017 19:06:04 -03
    libXxf86dga1-1.1.4-8.3.x86_64 Ter 19 Set 2017 19:06:04 -03
    libXTrap6-1.0.1-12.3.x86_64 Ter 19 Set 2017 19:06:04 -03
    libXp6-1.0.3-4.3.x86_64 Ter 19 Set 2017 19:06:04 -03
    liblbxutil1-1.1.0-15.3.x86_64 Ter 19 Set 2017 19:06:04 -03
    libFS6-1.0.7-4.3.x86_64 Ter 19 Set 2017 19:06:04 -03
    libdmx1-1.1.3-8.3.x86_64 Ter 19 Set 2017 19:06:04 -03
    ico-1.0.4-12.1.x86_64 Ter 19 Set 2017 19:06:04 -03
    fonttosfnt-1.0.4-14.1.x86_64 Ter 19 Set 2017 19:06:04 -03
    editres-1.0.6-11.1.x86_64 Ter 19 Set 2017 19:06:04 -03
    bitmap-1.0.8-6.1.x86_64 Ter 19 Set 2017 19:06:04 -03
    xorg-x11-7.6_1-19.3.noarch Ter 19 Set 2017 19:06:03 -03
    xorg-scripts-1.0.1-15.1.noarch Ter 19 Set 2017 19:06:03 -03
    xcursor-themes-1.0.4-9.1.noarch Ter 19 Set 2017 19:06:03 -03
    beforelight-1.0.5-12.1.x86_64 Ter 19 Set 2017 19:06:03 -03
    bdftopcf-1.0.5-4.3.x86_64 Ter 19 Set 2017 19:06:03 -03
    appres-1.0.4-9.1.x86_64 Ter 19 Set 2017 19:06:03 -03
    I'd like to use oS native VNC server instead of installing another one, if that makes sense.

    So, my issues/questions are:

    LEAP box:

    1) Is the "firewall disabled" info on VNC module relevant? I haven't installed a client in the other box yet (see below).

    2) Any way to fix this drop-to-terminal thing, or is it worth a bug report?

    3) Is there a better/safer way to set the server for LAN user, using another program, perhaps?

    oS 13.2 box:

    4) What client should I use? There are a number of clients in oS 13.2 repos, like GTK-vnc, novnc, etc. Or another one?

    Thanks,


    Bruno

  2. #2
    Join Date
    Nov 2013
    Location
    Kamloops, BC, Canada
    Posts
    2,723

    Default Re: Yast Remote Admin (VNC) module - multiple issues/questions

    Make sure TigerVNC and x11VNC are installed on both machines.

    By far the best method, IMHO, is to use that combination and to do so through SSH, so it is completely secure. You do not have to turn Remote Administration (VNC) on in Yast. I have it turned off on my machines and I am connecting just fine.

    All you need to know is a login name and the related password on the other PC, you do not have to open any Ports in an external router if you are staying within the LAN, so leaving those closed will give you tighter security.

    To access one machine from the other, the User on the machine you are accessing should be logged in. (It can be done without the User logged in, but an additional step is required, and I do not want to confuse the instructions here.)

    Now, on the machine you want to use to access the other, open a terminal and issue:
    Code:
    ssh -t -L 5900:localhost:5900 YourUser@xxx.xxx.xxx.x 'x11vnc -localhost -nolookup -nopw -display :0'
    Where YourUser is the signed-in user on the machine you want to access and the xxx.xxx... is the LAN IP address of that remote machine.

    This creates a secure SSH connection to that machine and ties it to your localhost on the machine you are connecting from.

    You will see some minor errors mentioned, ignore them.

    Now, open a second terminal window, not the same one you did the above. In that second terminal, issue:
    Code:
    vncviewer
    A little dialogue window will pop up.

    In the VNC server box, enter:
    Code:
    localhost:0
    then click on the Connect button.

    You might notice that there is a message that the connection is not secure ... ignore that. It actually is secure because the connection is in an SSH tunnel.
    -Gerry Makaro
    Fraser-Bell Info Tech
    Solving Tech Mysteries since the Olden Days!
    ~~~~~
    If I helped you, consider clicking the Star at the bottom left of my post.

  3. #3
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    8,222

    Default Re: Yast Remote Admin (VNC) module - multiple issues/questions

    I'd highly recommend reading and following the community openSUSE documentation on this topic

    https://doc.opensuse.org/documentati...e/cha.vnc.html

    Looks like it's undergone a radical re-write recently, IMO with mixed results. Some important details like the vnc server configuration file is a bit more prominent now, but it's less clear exactly how the vnc server is set up and can be modified... And it's different than how it was set up for many years up to a few ago.

    Unless you have a reason to configure persistent session management, I'd recommend you set that aside at first.
    More importantly, you should know that when you install using the YaST Remote Administration module, the "One Time VNC Session" configuration is set up by default.

    I do not recommend installing VNC by any other way, otherwise you will not be guaranteed to have a known standard configuration when you post in these Forums, and additionally I feel strongly that setting up vnc server to use /etc/xinetd.d/vnc is better than allowing clients to try to pass display variables.

    I've set up a few 42.3 VNC servers and haven't seen the problems you're describing.
    Did you update your system before you tried to run the YaST Remote Administration module? Run the following if you haven't already...
    Code:
    zypper update
    TSU
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

  4. #4
    Join Date
    Nov 2013
    Location
    Kamloops, BC, Canada
    Posts
    2,723

    Default Re: Yast Remote Admin (VNC) module - multiple issues/questions

    I am running the setup I showed.

    I have never had any problems, have used this for a long time.

    I am currently using it in my own network connecting flawlessly, quickly, and securely back and forth between PCs running 13.1, 42.1, 42.2, and 42.3, no issues, quick and slick.

    Connections are not persistent, and this is a widely-used method (even covered in the openSUSE documentation).
    -Gerry Makaro
    Fraser-Bell Info Tech
    Solving Tech Mysteries since the Olden Days!
    ~~~~~
    If I helped you, consider clicking the Star at the bottom left of my post.

  5. #5
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    8,222

    Default Re: Yast Remote Admin (VNC) module - multiple issues/questions

    Quote Originally Posted by Fraser_Bell View Post
    I am running the setup I showed.

    I have never had any problems, have used this for a long time.

    I am currently using it in my own network connecting flawlessly, quickly, and securely back and forth between PCs running 13.1, 42.1, 42.2, and 42.3, no issues, quick and slick.

    Connections are not persistent, and this is a widely-used method (even covered in the openSUSE documentation).
    I'm sure your setup can run fine, and it has many of the characteristics how I used to set up VNC for many years.

    Just saying... There's nothing necessarily bad about running your own system the old way if you feel comfortable with it, but there is a better, more "enterprise" way to do it today that's more modular and is centrally managed from the VNC Server.

    And, if you have problems with your setup,
    Deviating from standard documentation means that you'll have to be very detailed in your description(or provide a reference for what you did)
    but if your setup is consistent with known documentation, then it's a known scenario.

    TSU
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

  6. #6
    Join Date
    Nov 2013
    Location
    Kamloops, BC, Canada
    Posts
    2,723

    Default Re: Yast Remote Admin (VNC) module - multiple issues/questions

    Quote Originally Posted by tsu2 View Post
    but if your setup is consistent with known documentation, then it's a known scenario.

    TSU
    ... which it is.
    https://en.opensuse.org/SDB:VNC_usag...re_VNC_session
    -Gerry Makaro
    Fraser-Bell Info Tech
    Solving Tech Mysteries since the Olden Days!
    ~~~~~
    If I helped you, consider clicking the Star at the bottom left of my post.

  7. #7
    Join Date
    Aug 2008
    Location
    Brazil
    Posts
    2,640

    Default Re: Yast Remote Admin (VNC) module - multiple issues/questions

    Fraser and TSU, thank you for your insight and links.

    On further thought I may have jumped the gun, so to speak, orienting my question by VNC, when it should have been more generic in terms of what I'm trying to accomplish.

    The LEAP (server) and the 13.2 (client) boxes are in the same room. The LEAP box dual-boot with w10, so, ideally, both OSes would use the same server protocol so there is only one client application. Also the connection should be simple (like for lazy people like me ). Since w10 is in the equation I thought of rdp, which led to KDE's implementation of. I'm aware that it's no big deal to install a vnc server in windows, I just tend to try the native solutions first. And krfb/krdc have simple, easy to use GUIs.

    The SDB linked by Fraser warns that
    As of SuSE11.0 and 11.1 the KDE apps krfb and krdc are broken. In particular krfb does not serve up a valid rendering of the display and it is badly corrupted with false color blocks and dual images. KRDC will often crash and lock up regardless of what type of server it is connecting to. Both problems have been reported but there appears to be very little activity happening to get these tools repaired.. See below on how to use x11vnc to establish a VNC connection to a live remote desktop for some alternate methods.
    This appear to have changed somewhat since 11.x, since I could connect to krfb on LEAP with krdc on oS 12.3 using vnc, but not using rdp (some issue with authentication a bit over my head).

    The issues with krfb/krdc were mouse lag/jumping and constant high bandwidth usage at approx 10.5 MB/s (85 Mb/s), probably capped by the server (configured for LAN) as the LAN is gigabit.

    Another thing that occurred to me is if I'm not complicating issues unnecessarily. The LEAP box currently is connected to a 1280 x 1024 monitor, and the client have two 1920 x 1200 screens, and using vnc, even in the full screen scaled mode I get a letterboxed remote desktop, and I'd like it to be true fullscreen on the second monitor, so I could get more real state to run the server applications (windows-only structural analysis software, basically).

    Since X is a server, wouldn't it be possible to start a desktop session directed at the client screen? The server local monitor need not be connected to the user's session, cloning the display. I'm not sure I'm being clear here.

    What do you think?

    Quote Originally Posted by tsu2 View Post
    Did you update your system before you tried to run the YaST Remote Administration module? Run the following if you haven't already...
    Code:
    zypper update
    TSU
    Indeed I have, earlier the same day. Only three packages if memory serves. KDE updater (or whatever the name is) is active.

    Thank you,

  8. #8
    Join Date
    Aug 2008
    Location
    Brazil
    Posts
    2,640

    Default Re: Yast Remote Admin (VNC) module - multiple issues/questions

    P.S.: Perhaps nomachine is an option. And the arch wiki is an interesting read too.

  9. #9
    Join Date
    Nov 2013
    Location
    Kamloops, BC, Canada
    Posts
    2,723

    Default Re: Yast Remote Admin (VNC) module - multiple issues/questions

    You could also check out Teamviewer. It has both Linux and Windows versions, and can be set to allow connections like you want.

    It is free for non-commercial use, but quite powerfull.

    ... and, yes, several people here use it, as well.
    -Gerry Makaro
    Fraser-Bell Info Tech
    Solving Tech Mysteries since the Olden Days!
    ~~~~~
    If I helped you, consider clicking the Star at the bottom left of my post.

  10. #10
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    8,222

    Default Re: Yast Remote Admin (VNC) module - multiple issues/questions

    Any User can use whatever might work as long as the setup is described in detail when/if you ask for help.

    I'd still recommend the current openSUSE docs in this case (IMO openSUSE docs on this topic are fairly good).
    The referenced SDB was originally created in 2010, and describes how things had to be set up then.
    But, that is then and today there have been improvements which you might or might not want to take advantage of (AFAIK hardly any VNC "old way" doesn't still work).

    An important concept to notice in the SDB is that a main purpose was to set up a specific type of connection... Shared Desktop, for instance as a Help Desk tool so that the local User can see what the remote Admin is doing on the machine. If you want this kind of connection, it's called "Persistent Connections" in the openSUSE docs. For simply connecting to a remote machine and <not> sharing a Desktop, you would use the much simpler "One-time VNC Sessions"

    As for encrypting the connection,
    As the openSUSE docs describe, today this is supposed to happen automatically and is default unless there is a missing or faulty configuration.
    Sure, you can still wrap the VNC session in SSH if you wish, but only if you wish to do so.

    As for performance...
    I haven't had to test VNC over a low bandwidth connection for many, many years so I can't be sure how well it works today but I'm
    unaware that the VNC internal graphics architecture has changed since early development.
    When I did run VNC over telco dialup (yes, that long ago), several things were noticeable...
    - I had to drop down to 16-bit color
    - I had to run VGA (640x480)

    And so, in those days I preferred connecting specifically to MSWindows machines over slow links using rdp protocol apps because
    - System graphics were integrated into the OS in those days. Today, this is the default in Linux as well.
    - Perhaps related to the kernel mode graphics, the data stream was much less, perhaps also related to caching and use of differential rendering which AFAIK is still not implemented in VNC today.

    The reason why I described the above is that although much likely has changed over time, some or many of those rdp "advantages" may still exist. Then again, if you have enough bandwidth and with today's much more powerful machines those differences might not show up so often. And even the rdp advantages I described would be apparent only when connecting to a MSWindows machine.

    Bottom line is that there may not be a "one size fits all" answer to your situation, you may have to test various remote Desktop apps.

    And don't overlook passing X over SSH, I find that to be very, very performant connecting to Linux today. On openSUSE, all you need to do is to install the VNC Remote Administration server using YaST and you'll be all set up to accept X over SSH connections. If you're connecting to a Windows box, of course SSH isn't native, but you could install a special X server (but I'd generally recommend an rdp app instead).

    HTH,
    TSU
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •