Le 22/03/2019 à 18:09, Cousin Ricky a écrit :
> On 2019-03-22 12:45 PM (-4), Le_Forgeron wrote:
>> Le 22/03/2019 à 16:35, Cousin Ricky a écrit :
>>
>> Are you running in local, directly on the linux pc's keyboard & screen ?
>> (or via a remote connection such as ssh ?)
> 
> I'm just using my laptop.
> 
>> If local, are you running in console or X11 display ?
> 
> I'm using Konsole.  Whether that means console or X11 I don't know.
> 
Ok, as elsewhere you talked about xclock, it's X11 (mouse & graphic),
not a bare console of pure text.

Good.

>> you can disable preview (hence the need to open the X display) via
>> command line switch : -d
>>   as well as ini file: Display=Off
> 
> I don't want to disable the preview.  I do expect the OS to allow the
> software to work properly.
> 
>> As you upgraded, it is possible the old cookie remains and is no more
>> valid for the new server (such cookie is in a file in your home, a
>> hidden dot file, and is created by the logging process but ONLY if it
>> does not exist). Basic test: find the cookie file, nuck the cookie file,
>> disconnect, reconnect.
> 
> What would be the name of this file?

Have a look there:
https://stackoverflow.com/questions/37157097/how-does-x11-authorization-works-mit-magic-cookie

>
https://stackoverflow.com/questions/37157097/how-does-x11-authorization-works-mit-magic-cookie

For my system:
- cookie file is ~/.Xauthority
- it was created at the day and hour I logged in.
- it contains a single entry for my display.

jerome@krynn:~$ xauth list
krynn/unix:0  MIT-MAGIC-COOKIE-1  c81a816f0a1c24bcc3dce3aed7d8c746
jerome@krynn:~$ ls -l .Xauthority
-rw------- 1 jerome jerome 50 mars  22 17:16 .Xauthority
jerome@krynn:~$


Notice the rights on the file: User only. As stated in first line of
answer, mess with them and you are in for a party of problems.

you can use xauth as interactive command interpreter, as in the provided
link, by calling it without parameter.

It will show the location, then wait for commands like:
* list
* info
* quit

good luck.

Post a reply to this message

On 2019-03-22 2:43 PM (-4), Le_Forgeron wrote:
> Le 22/03/2019 à 18:09, Cousin Ricky a écrit :
>> On 2019-03-22 12:45 PM (-4), Le_Forgeron wrote:
>>
>>> As you upgraded, it is possible the old cookie remains and is no more
>>> valid for the new server (such cookie is in a file in your home, a
>>> hidden dot file, and is created by the logging process but ONLY if it
>>> does not exist). Basic test: find the cookie file, nuck the cookie file,
>>> disconnect, reconnect.
>>
>> What would be the name of this file?
> 
> Have a look there:
>
https://stackoverflow.com/questions/37157097/how-does-x11-authorization-works-mit-magic-cookie
> 
>>
https://stackoverflow.com/questions/37157097/how-does-x11-authorization-works-mit-magic-cookie

As it turns out, this is one of the pages I found during my searches. 
It is way over my head, and I don't know how I can use this info to fix 
the damn problem.

> For my system:
> - cookie file is ~/.Xauthority
> - it was created at the day and hour I logged in.
> - it contains a single entry for my display.
> 
> jerome@krynn:~$ xauth list
> krynn/unix:0  MIT-MAGIC-COOKIE-1  c81a816f0a1c24bcc3dce3aed7d8c746
> jerome@krynn:~$ ls -l .Xauthority
> -rw------- 1 jerome jerome 50 mars  22 17:16 .Xauthority
> jerome@krynn:~$

I get the same thing on my system.

> Notice the rights on the file: User only. As stated in first line of
> answer, mess with them and you are in for a party of problems.
> 
> you can use xauth as interactive command interpreter, as in the provided
> link, by calling it without parameter.
> 
> It will show the location, then wait for commands like:
> * list
> * info
> * quit
> 
> good luck.

Post a reply to this message

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> I get the same thing on my system.

one other thing to try (perhaps ;-))

xhost +local:

to allow localhost access to your desktop.


regards, jr.

Post a reply to this message

On 3/22/19 3:33 PM, jr wrote:
> hi,
> 
> Cousin Ricky <ric### [at] yahoocom> wrote:
>> I get the same thing on my system.
> 
> one other thing to try (perhaps ;-))
> 
> xhost +local:
> 
> to allow localhost access to your desktop.
> 
> 
> regards, jr.

Everything I read about xhost is that it's a security risk.  Can I be 
assured that my computer won't be made vulnerable?

Post a reply to this message

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 3/22/19 3:33 PM, jr wrote:
> > one other thing to try (perhaps ;-))
> > xhost +local:
> > to allow localhost access to your desktop.

> Everything I read about xhost is that it's a security risk.  Can I be
> assured that my computer won't be made vulnerable?

yes.  you grant access from 127.* only.  you can (perhaps) in addition start
your server with the "-nolisten tcp" option, if you are really concerned.


regards, jr.

Post a reply to this message

On 2019-03-22 3:49 PM (-4), jr wrote:
> hi,
> 
> Cousin Ricky <ric### [at] yahoocom> wrote:
>> On 3/22/19 3:33 PM, jr wrote:
>>> one other thing to try (perhaps ;-))
>>> xhost +local:
>>> to allow localhost access to your desktop.
> 
>> Everything I read about xhost is that it's a security risk.  Can I be
>> assured that my computer won't be made vulnerable?
> 
> yes.  you grant access from 127.* only.  you can (perhaps) in addition start
> your server with the "-nolisten tcp" option, if you are really concerned.

That worked; thanks!

I also figured out how to turn it off:

   xhost -LOCAL:

Post a reply to this message

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> >>> xhost +local:
> That worked; thanks!

glad it works.

> I also figured out how to turn it off:
>
>    xhost -LOCAL:

:-)

of course this fix only masks the problem.  I'm wondering, if you 'ls -l' the
POV-Ray executable, is it actually owned by 'root'?  I ask because (a) I've
never had a permission problem with POV-Ray, and (b) I use xhost -local: when I
am logged in (in a xterm) as a different user and want that user to run graphics
stuff on "my" desktop.  if the program is not root owned "chown" it and you
should not need (fingers crossed :-)) to use xhost.


regards, jr.

Post a reply to this message

On 3/22/19 1:34 PM, Cousin Ricky wrote:
> On 2019-03-22 1:18 PM (-4), clipka wrote:
>> Am 22.03.2019 um 16:35 schrieb Cousin Ricky:
>>
>>> One I haven't tried requires my local hostname or IP address.  I 
>>> don't know what the former means, and the latter is unreasonable with 
>>> dynamically assigned IP addresses.
>>
>> You can always use `127.0.0.1` to address the local machine.
> 
> Already tried 'export DISPLAY=127.0.0.1:0'.  I got:
> 
> The display '127.0.0.1:0' is not a valid display,

i'm running leap as well and haven't had that issue... when i do echo 
$DISPLAY it returns :0

Post a reply to this message

On 2019-03-22 5:15 PM (-4), jr wrote:
> 
> Cousin Ricky <ric### [at] yahoocom> wrote:
>>>>> xhost +local:
>> That worked; thanks!
> 
> glad it works.
> 
>> I also figured out how to turn it off:
>>
>>     xhost -LOCAL:
> 
> :-)
> 
> of course this fix only masks the problem.  I'm wondering, if you 'ls -l' the
> POV-Ray executable, is it actually owned by 'root'?  I ask because (a) I've
> never had a permission problem with POV-Ray, and (b) I use xhost -local: when I
> am logged in (in a xterm) as a different user and want that user to run graphics
> stuff on "my" desktop.  if the program is not root owned "chown" it and you
> should not need (fingers crossed :-)) to use xhost.

ricky@linux-dc58:/usr/local/bin> ls -l povray*
-rwxr-xr-x 1 root root 2672528 Nov 30  2013 povray
-rwxr-xr-x 1 root root 3242336 Feb 22  2013 povray-3.5
-rwxr-xr-x 1 root root 2971828 Feb 22  2013 povray-3.6
-rwxr-xr-x 1 root root 2672528 Nov 30  2013 povray-3.7
-rwxr-xr-x 1 root root 2672528 Nov 30  2013 povray-3.7.0
-rwxr-xr-x 1 root root 3018992 Jun 25  2017 povray-3.7.1
-rwxr-xr-x 1 root root 2993904 Mar 13  2017 povray-3.7.1.b4
-rwxr-xr-x 1 root root 2993904 Mar 28  2017 povray-3.7.1.b5
-rwxr-xr-x 1 root root 2998000 May  8  2017 povray-3.7.1.b6
-rwxr-xr-x 1 root root 2998000 May 20  2017 povray-3.7.1.b7
-rwxr-xr-x 1 root root 3018992 Jun 25  2017 povray-3.7.1-rc1
-rwxr-xr-x 1 root root 3836504 Feb 19 00:37 povray-3.8
-rwxr-xr-x 1 root root 3918456 Jan 16 21:38 povray-3.8.0-a10013324
-rwxr-xr-x 1 root root 3836504 Feb 19 00:37 povray-3.8.0-a10064268
-rwxr-xr-x 1 root root 3777112 Oct 25 21:54 povray-3.8.0-a9893777
-rwxr-xr-x 1 root root 3777112 Nov 30 16:37 povray-3.8.0-a9945627

Post a reply to this message

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2019-03-22 5:15 PM (-4), jr wrote:
> > ...  I'm wondering, if you 'ls -l' the POV-Ray executable,
> > is it actually owned by 'root'?  ...

> ricky@linux-dc58:/usr/local/bin> ls -l povray*
> -rwxr-xr-x 1 root root 2672528 Nov 30  2013 povray

not that, then.  the only other thing I can think of are the
'hosts.{allow,deny}' files.  mine read:

jr@crow:2:~$ head /etc/hosts.{allow,deny}
==> /etc/hosts.allow <==
ALL:LOCAL, 192.168.1.

==> /etc/hosts.deny <==
ALL:ALL


they're used by the xauth mechanism too, iirc.


regards, jr.

Post a reply to this message