New Tumbleweed snapshot 20180116 released!

classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: ssh -X failing in 20180116

H.Merijn Brand
On Thu, 18 Jan 2018 17:57:34 +0100, Martin Herkt <[hidden email]>
wrote:

> On Donnerstag, 18. Januar 2018 15:20:20 CET Petr Cerny wrote:
> > That said, please do not use X forwarding unless you really must even
> > after ten people told you this sentence. Every time someone uses X
> > forwarding, <insert your favourite kitten/baby cries/dies/starves
> > combination or whatever>.
> >
> > I strongly advocate using VNC (tunnelled through an ssh connection, if
> > you like) - quick guide: 1) start `Xnvc` (preferably through the
> > `vncserver`) - you'll need the xorg-x11-Xvnc package (on openSUSE); 2)
> > connect to it with a VNC client (e.g. tigervnc, but there are more). It
> > is also possible to attach to a running desktop session with x11vnc.  
>
> I second that. Note: There’s xrdp, too, which is compatible with Windows’
> built-in RDP client and also supports forwarding audio, clipboard and other
> things, and it can forward single application windows (rather than a full
> session). However, setup is unfortunately more complicated than sshd.
These are to take over a desktop, something IMHO seldom needed on
servers. Additionally, xrdp needs to run as a service, which will -
again - use server resources where I most of the time would need them
for server processing tasks.

FWIW the old rdesktop tool will not connect to recentish Windows
systems. You'll need xfreerdp for that, which - hate hate hate hate -
changed the option syntax to something very NOT unix/linux like ☠☠☠☠☠

Old (rdesktop):

rdesktop \
    -T windows \
    -u username -p - \
    -g 1600x1024 -a 24 -C -x l \
    -r clipboard:CLIPBOARD \
    -K -N -P \
    windows

New (xfreerdp):

xfreerdp \
    /t:windows \
    /u:username /from-stdin \
    /size:1600x1024 /bpp:32 \
    +clipboard \
    /cert-ignore \
    /nsc \
    /v:windows

And the worst thing there is that xfreerdb used to support the
old-style options and they removed that in favor of this windows-like
unremberable bullshit

--
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.27   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/        http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/

attachment0 (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ssh -X failing in 20180116

Bruce Ferrell
On 01/18/2018 09:43 AM, H.Merijn Brand wrote:

> On Thu, 18 Jan 2018 17:57:34 +0100, Martin Herkt <[hidden email]>
> wrote:
>
>> On Donnerstag, 18. Januar 2018 15:20:20 CET Petr Cerny wrote:
>>> That said, please do not use X forwarding unless you really must even
>>> after ten people told you this sentence. Every time someone uses X
>>> forwarding, <insert your favourite kitten/baby cries/dies/starves
>>> combination or whatever>.
>>>
>>> I strongly advocate using VNC (tunnelled through an ssh connection, if
>>> you like) - quick guide: 1) start `Xnvc` (preferably through the
>>> `vncserver`) - you'll need the xorg-x11-Xvnc package (on openSUSE); 2)
>>> connect to it with a VNC client (e.g. tigervnc, but there are more). It
>>> is also possible to attach to a running desktop session with x11vnc.
>> I second that. Note: There’s xrdp, too, which is compatible with Windows’
>> built-in RDP client and also supports forwarding audio, clipboard and other
>> things, and it can forward single application windows (rather than a full
>> session). However, setup is unfortunately more complicated than sshd.
> These are to take over a desktop, something IMHO seldom needed on
> servers. Additionally, xrdp needs to run as a service, which will -
> again - use server resources where I most of the time would need them
> for server processing tasks.
>
> FWIW the old rdesktop tool will not connect to recentish Windows
> systems. You'll need xfreerdp for that, which - hate hate hate hate -
> changed the option syntax to something very NOT unix/linux like ☠☠☠☠☠
>
> Old (rdesktop):
>
> rdesktop \
>      -T windows \
>      -u username -p - \
>      -g 1600x1024 -a 24 -C -x l \
>      -r clipboard:CLIPBOARD \
>      -K -N -P \
>      windows
>
> New (xfreerdp):
>
> xfreerdp \
>      /t:windows \
>      /u:username /from-stdin \
>      /size:1600x1024 /bpp:32 \
>      +clipboard \
>      /cert-ignore \
>      /nsc \
>      /v:windows
>
> And the worst thing there is that xfreerdb used to support the
> old-style options and they removed that in favor of this windows-like
> unremberable bullshit
>
Actually, if you're talking about RDP type protocols, you're talking about MS Windows. Saying "seldom needed on servers" is less than accurate. To pay my bills, I support many
enterprises that use MS Windows, including Fortune 500 level enterprises. It's not just common, but the only thing they know how to and/or allowed do... "Desktop" takeover of the
server via the windows native methods.

"Strongly" advocating VNC with or without tunnels, in all of it's fragmented forms, is simply not realistic either. Apple has it's flavor, then there are Tiger, Tight and Real. 
Sometimes they interoperate.  More and more often, they don't.

Sigh


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ssh -X failing in 20180116

H.Merijn Brand
On Thu, 18 Jan 2018 10:04:21 -0800, Bruce Ferrell
<[hidden email]> wrote:

> On 01/18/2018 09:43 AM, H.Merijn Brand wrote:
> > On Thu, 18 Jan 2018 17:57:34 +0100, Martin Herkt <[hidden email]>
> > wrote:
> >  
> >> On Donnerstag, 18. Januar 2018 15:20:20 CET Petr Cerny wrote:  
> >>> That said, please do not use X forwarding unless you really must even
> >>> after ten people told you this sentence. Every time someone uses X
> >>> forwarding, <insert your favourite kitten/baby cries/dies/starves
> >>> combination or whatever>.
> >>>
> >>> I strongly advocate using VNC (tunnelled through an ssh connection, if
> >>> you like) - quick guide: 1) start `Xnvc` (preferably through the
> >>> `vncserver`) - you'll need the xorg-x11-Xvnc package (on openSUSE); 2)
> >>> connect to it with a VNC client (e.g. tigervnc, but there are more). It
> >>> is also possible to attach to a running desktop session with x11vnc.  
> >> I second that. Note: There’s xrdp, too, which is compatible with Windows’
> >> built-in RDP client and also supports forwarding audio, clipboard and other
> >> things, and it can forward single application windows (rather than a full
> >> session). However, setup is unfortunately more complicated than sshd.  
> > These are to take over a desktop, something IMHO seldom needed on
> > servers. Additionally, xrdp needs to run as a service, which will -
> > again - use server resources where I most of the time would need them
> > for server processing tasks.
> >
> > FWIW the old rdesktop tool will not connect to recentish Windows
> > systems. You'll need xfreerdp for that, which - hate hate hate hate -
> > changed the option syntax to something very NOT unix/linux like __ __ __ __ __
> >
> > Old (rdesktop):
> >
> > rdesktop \
> >      -T windows \
> >      -u username -p - \
> >      -g 1600x1024 -a 24 -C -x l \
> >      -r clipboard:CLIPBOARD \
> >      -K -N -P \
> >      windows
> >
> > New (xfreerdp):
> >
> > xfreerdp \
> >      /t:windows \
> >      /u:username /from-stdin \
> >      /size:1600x1024 /bpp:32 \
> >      +clipboard \
> >      /cert-ignore \
> >      /nsc \
> >      /v:windows
> >
> > And the worst thing there is that xfreerdb used to support the
> > old-style options and they removed that in favor of this windows-like
> > unremberable bullshit  
>
> Actually, if you're talking about RDP type protocols, you're talking
> about MS Windows.
Unless one promotes xrdp, which is the server-side of this on Linux

> Saying "seldom needed on servers" is less than accurate.

Oh yes. I am sorry. I should have been accurate: Seldom needed on Linux
servers (or any Unix like HP-UX, AIX, Solaris, ...)

> To pay my bills, I support many enterprises that use MS Windows,
> including Fortune 500 level enterprises. It's not just common, but
> the only thing they know how to and/or allowed do... "Desktop"
> takeover of the server via the windows native methods.

I feel your pain. Same here.

> "Strongly" advocating VNC with or without tunnels, in all of it's
> fragmented forms, is simply not realistic either. Apple has it's
> flavor, then there are Tiger, Tight and Real. Sometimes they
> interoperate.  More and more often, they don't.
>
> Sigh

/o\

--
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.27   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/        http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/

attachment0 (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: xtables-addons: broken in snapshot 20180116

Arjen de Korte
In reply to this post by Arjen de Korte
Citeren Arjen de Korte <[hidden email]>:

> As a heads-up: if you're using xtables-addons, be aware that the  
> version shipped with snapshot 20180116 is broken for at least the  
> xt_geoip module (due to symbols that can't be resolved).

https://bugzilla.opensuse.org/show_bug.cgi?id=1076650

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ssh -X failing in 20180116

Andrei Borzenkov
In reply to this post by Roger Whittaker-2
18.01.2018 17:01, Roger Whittaker пишет:

> On Thu, Jan 18, 2018 at 11:46:07AM +0000, Roger Whittaker wrote:
>
>> The new openssh version 7.6p1-1.1 in 20180116 seems to break X
>> forwarding with ssh -X.
>>
>> Reverting to 7.2p2-6.2 fixed the problem.
>>
>> I haven't really investigated - I just reverted quickly because I use
>> this constantly.
>>
>> Is there something new about the configuration in 7.6p1-1.1 ?
>
> In case this is of use to anyone else: the system I was connecting to
> had ipv6 disabled, and in /etc/ssh/sshd_config had the default setting
>
> AddressFamily any
>
> With 7.2p2-6.2 I could ssh -X to it without problems.
>
> After the update to 7.6p1-1.1 I needed to set
>
> AddressFamily inet
>

> and the problem was then solved.
>

https://bugzilla.novell.com/show_bug.cgi?id=618068
https://bugzilla.mindrot.org/show_bug.cgi?id=1356
https://bugzilla.mindrot.org/show_bug.cgi?id=2143

The problem happens when IPv6 is disabled on host.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: plasma5 splash not going away, needs Mesa-dri installer, dependency issue (was: Re: [opensuse-factory] New Tumbleweed snapshot 20180116 released!)

Attila Vetesi
In reply to this post by Robert Kaiser
Hi,

Thanks for the hints, I had the same problem, and installing Mesa-dri
solved the problem.
Although, this makes me a bit concerned about how will I be informed
about "recommended" packages which are in fact required. As others
mentioned, I'm also using --without-recommends, mainly because
otherwise I'm offered with +600Mb of download of packages I'm not
interested in (most of them are which I've deselected at the first
installation from scratch).
I hope a solution can be found for these kind of situations, so that
the other TW users who don't read the mailing list aren't faced with
non-working systems and questions like: "ooh, you didn't know you have
to install X and Y package after today's dup to have a working
system?!" :)

Thanks again,
Best regards,
Attila.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: plasma5 splash not going away, needs Mesa-dri installer, dependency issue (was: Re: [opensuse-factory] New Tumbleweed snapshot 20180116 released!)

Frank Krüger
Am 18.01.2018 um 22:21 schrieb Attila Vetesi:

> Hi,
>
> Thanks for the hints, I had the same problem, and installing Mesa-dri
> solved the problem.
> Although, this makes me a bit concerned about how will I be informed
> about "recommended" packages which are in fact required. As others
> mentioned, I'm also using --without-recommends, mainly because
> otherwise I'm offered with +600Mb of download of packages I'm not
> interested in (most of them are which I've deselected at the first
> installation from scratch).
> I hope a solution can be found for these kind of situations, so that
> the other TW users who don't read the mailing list aren't faced with
> non-working systems and questions like: "ooh, you didn't know you have
> to install X and Y package after today's dup to have a working
> system?!" :)
>
> Thanks again,
> Best regards,
> Attila.
>
Agreed. I have experienced the same issue, puzzled.

Regards, Frank
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ssh -X failing in 20180116

Petr Cerny
In reply to this post by Peter Suetterlin-2
Peter Suetterlin wrote:
> Petr Cerny wrote:
>> I haven't mentioned starting a whole X session (I suppose you understand
>> it as fully fledged GNOME/KDE environment). What Xnvc/vncserver does is
>> a matter of configuration.
>
> Sure, it's still the X server plus some window manager.  With 20 users doing
> that on our server that might consume quite a part of its memory that is much
> better used for data processing...

My guess(!) is, that 20 users running X-forwarded terminals are going to
consume more resources than 20 users having regular ssh sessions with
occasional display to a Xvnc server. Interactions of the remote
application window with others (read expose events triggered when part
of a window is uncovered) can easily waste resources.

Window managers like open/fluxbox, icewm have low overhead. Actually, if
you only need to display one window (say matplotlib output spawned from
IPython), you might be better off without any window managers at all.

>> Speaking of console application that may open a X window, that is
>> actually easily done with VNC as well. Just ssh to the remote side,
>> export the DISPLAY environment variable pointing to a Xvnc server
>> running on that machine and you are all set up (you may need to export
>> XAUTHORITY as well).
>
> Yes.  It's possible.  But needs (quite some) configuration, opposite to the X
> forwarding.

Um, short script that gets executed by vncserver at startup that runs
whatever you want to get the X environment ready. For me it looks
something like (~/.vnc/xstartup):

    #!/bin/sh
    xrdb $HOME/.Xresources
    xsetroot -solid grey
    xterm -geometry 96x40+10+10 -ls &

None of those are actually needed to be able to display something on the
server.

> I guess my main issue is your general condemnation of forwarding.  For me, this
> largely depends on context.  Our main use of forwarding is an ssh -X login to a
> server, run computational-heavy stuff in languages like IDL or Python from the
> command line, and display results.  This in the local network.
>
> Your assumed application(?)

True, yet...

> rather is running something like a browser or IDE
> via forwarding.  I completely agree with you that for that purpose VNC is
> superior.  But X forwarding in ssh *does* have many reasonable applications.

... no. I'd put it this way: in some cases, the overhead of writing a
script that would make VNC as simple to use as ssh X11 forwarding (or
issuing 3 commands instead of just one) might seem unjustifiable.

> And I strongly believe that no cat is harmed by doing it :D
Well, you never know, which way the superposition is going to collapse
until you open the box... :)

Thanks
Cheers
        Petr
--
Petr Cerny
Mozilla/OpenSSH maintainer for SUSE Linux
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ssh -X failing in 20180116

Petr Cerny
In reply to this post by Jan Engelhardt-4
Jan Engelhardt wrote:

> On Thursday 2018-01-18 16:16, Petr Cerny wrote:
>>>> 1) security - application can only grab inputs it gets from its X
>>>>    server. If you run it in a Xvnc, it only gets input that it is
>>>>    sent by the VNC client.
>>>
>>> A legit reason, but somewhat void if on an internal network behind big
>>> firewalls
>>
>>The key word is "somewhat". The question is not whether there are
>>attackers on your network, but how many.
>
> But SSH's security mechanisms win over VNC.

It's not SSH's security mechanism, rather X11's - and that's exactly
where it starts to break apart. :(

> And running VNC through ssh
> -L gets into the realm of "more security means less usability". Hrrm -
> probably pick RDP over VNC?

Some VNCs can do encryption natively, and port forwarding isn't really
that big of an issue (with several users each running their own Xvnc it
might get a bit trickier).

Thanks
Cheers
        Petr
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ssh -X failing in 20180116

Cris70
In reply to this post by Petr Cerny
Hi Petr!


Petr Cerny wrote

> (...)
>> Doesn't sound convincing. What is the most current definitive guide for
>> not using X11 forwarding? What should I tell a newby when he/she asks
>> *WHY* it should not be used?
> (...)
> 2) speed - the X protocol is usually much more verbose when compared to
> VNC, since it carries requests to draw things, while VNC only transports
> bitmaps (compressed). Try running Firefox via ssh -X and through VNC.
> I've also seen things that just didn't work via SSH-forwarded X11.
> (...)

I've been following this discussion with a lot of interest, and I've been
learning a lot from it.

BTW, just out of curiosity: are you really saying that it is more "compact"
to send bitmaps through the network rather than sending plain text commands?
Because I have always thought to the contrary, and that that was one of the
great advantages of X forwarding.

Actually, I've always been experiencing bad results (talking about visual
quality here) with VNC unless on very fast and not-congested networks, while
X forwarding is just like running a local application.

I know that bitmaps can be compressed, but bitmaps are not very compressible
unless you want to lose on the quality of the image (i.e. lossy
compression). And as the network speed/congestion gets bad, so is the
quality of the image to the point where, sometimes, you cannot even clearly
read text.

On the other hand, even a very verbose *text* protocol can be very easily
compressed down to nearly nothing, and you always get perfect graphics
because they are rendered locally.
Also, there should be no overhead on the server, because the X11 protocol
works the same way when used locally or remotely. That's exactly why it can
be forwarded. At least that's what I learned back when I was in school, I
don't know what's the situation right now with compositors and all that
stuff.

That said, I use X forwarding only when I have to use the occasional GUI
application window; when I have to grab a whole remote desktop I usually use
current NoMachine's NX, which is a lot more reliable than VNC in my
experience (despite not being open source).
But that is usually because I have to grab the desktop of another user, not
because of efficiency considerations (with respect to X11 forwarding, I
mean).

I've been trying to use xrdp *server* too, but I find it too much unstable
in my experience. OTOH I use xfreerdp client all the time when I have to
connect to Windows server (due to my work) and I find it quite fast and
stable.

Just my 2c.

Cris




--
Sent from: http://opensuse.14.x6.nabble.com/opensuse-factory-f3292933.html
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

123