Since I upgraded my GNU/Linux system to openSUSE Leap 15.0, I get the 
message "Invalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 
keyInvalid MIT-MAGIC-COOKIE-1 key" with every POV 3.7 or 3.8 render. 
This is annoying, but at least the scenes render. But whenever I test a 
scene file with POV 3.5 or 3.6, the render halts with the message:

------------------- [BEGIN MESSAGE] --------------------
Displaying...Xlib: connection to ":0.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
Slab Building Error:
The display ':0' is not a valid display,
-------------------- [END MESSAGE] ---------------------

The only way I can get any 3.5 or 3.6 renders is to suppress the display 
with -D; but this is impractical when I'm testing a single scene across 
multiple versions.

I've tried to learn about the MIT-MAGIC-COOKIE-1 thing, and have ended 
up entirely flummoxed.  I have tried various simple solutions I've found 
across the Web, and none of them work.  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.

Has anyone else had this problem, and what can I do to fix it?

OS: openSUSE Leap 15.0 (GNU/Linux)
Hardware: Dell Inspiron 17R 5720

Post a reply to this message

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> Since I upgraded my GNU/Linux system to openSUSE Leap 15.0, I get the
> message "Invalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1
> keyInvalid MIT-MAGIC-COOKIE-1 key" with every POV 3.7 or 3.8 render.
> This is annoying, but at least the scenes render. But whenever I test a
> scene file with POV 3.5 or 3.6, the render halts with the message:
>
> ------------------- [BEGIN MESSAGE] --------------------
> Displaying...Xlib: connection to ":0.0" refused by server
> Xlib: Invalid MIT-MAGIC-COOKIE-1 key
> Slab Building Error:
> The display ':0' is not a valid display,
> -------------------- [END MESSAGE] ---------------------
>
> The only way I can get any 3.5 or 3.6 renders is to suppress the display
> with -D; but this is impractical when I'm testing a single scene across
> multiple versions.
>
> I've tried to learn about the MIT-MAGIC-COOKIE-1 thing, and have ended
> up entirely flummoxed.  I have tried various simple solutions I've found
> across the Web, and none of them work.  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.
>
> Has anyone else had this problem, and what can I do to fix it?
>
> OS: openSUSE Leap 15.0 (GNU/Linux)
> Hardware: Dell Inspiron 17R 5720

Slackware systems have a 'mcookie(1)' program installed for the purpose (never
needed to use it though).  available from
ftp.kernel.org/pub/linux/utils/util-linux/.


regards, jr.

Post a reply to this message

Le 22/03/2019 à 16:35, Cousin Ricky a écrit :
> Since I upgraded my GNU/Linux system to openSUSE Leap 15.0, I get the
> message "Invalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1
> keyInvalid MIT-MAGIC-COOKIE-1 key" with every POV 3.7 or 3.8 render.
> This is annoying, but at least the scenes render. But whenever I test a
> scene file with POV 3.5 or 3.6, the render halts with the message:
> 
> ------------------- [BEGIN MESSAGE] --------------------
> Displaying...Xlib: connection to ":0.0" refused by server
> Xlib: Invalid MIT-MAGIC-COOKIE-1 key
> Slab Building Error:
> The display ':0' is not a valid display,
> -------------------- [END MESSAGE] ---------------------
> 
> The only way I can get any 3.5 or 3.6 renders is to suppress the display
> with -D; but this is impractical when I'm testing a single scene across
> multiple versions.
> 
> I've tried to learn about the MIT-MAGIC-COOKIE-1 thing, and have ended
> up entirely flummoxed.  I have tried various simple solutions I've found
> across the Web, and none of them work.  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.
> 
> Has anyone else had this problem, and what can I do to fix it?
> 
> OS: openSUSE Leap 15.0 (GNU/Linux)
> Hardware: Dell Inspiron 17R 5720

Are you running in local, directly on the linux pc's keyboard & screen ?
(or via a remote connection such as ssh ?)

If local, are you running in console or X11 display ?

you can disable preview (hence the need to open the X display) via
command line switch : -d
 as well as ini file: Display=Off

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.

Post a reply to this message

On 2019-03-22 12:13 PM (-4), jr wrote:
> 
> Slackware systems have a 'mcookie(1)' program installed for the purpose (never
> needed to use it though).  available from
> ftp.kernel.org/pub/linux/utils/util-linux/.

It's already installed on my computer.  I tried the suggested usage 
"xauth add :0 . `mcookie`", and it didn't work.  I got the exact same 
error message.

I don't know what else to do, as I have no freaking clue what's going on 
or what any of this means.

Post a reply to this message

On 3/22/19 12:45 PM, Le_Forgeron wrote:
> Le 22/03/2019 à 16:35, Cousin Ricky a écrit :
>> Since I upgraded my GNU/Linux system to openSUSE Leap 15.0, I get the
>> message "Invalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1
>> keyInvalid MIT-MAGIC-COOKIE-1 key" with every POV 3.7 or 3.8 render.
>> This is annoying, but at least the scenes render. But whenever I test a
>> scene file with POV 3.5 or 3.6, the render halts with the message:
>>
>> ------------------- [BEGIN MESSAGE] --------------------
>> Displaying...Xlib: connection to ":0.0" refused by server
>> Xlib: Invalid MIT-MAGIC-COOKIE-1 key
>> Slab Building Error:
>> The display ':0' is not a valid display,
>> -------------------- [END MESSAGE] ---------------------
>>
>> The only way I can get any 3.5 or 3.6 renders is to suppress the display
>> with -D; but this is impractical when I'm testing a single scene across
>> multiple versions.
>>
>> I've tried to learn about the MIT-MAGIC-COOKIE-1 thing, and have ended
>> up entirely flummoxed.  I have tried various simple solutions I've found
>> across the Web, and none of them work.  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.
>>
>> Has anyone else had this problem, and what can I do to fix it?
>>
>> OS: openSUSE Leap 15.0 (GNU/Linux)
>> Hardware: Dell Inspiron 17R 5720
> 
> Are you running in local, directly on the linux pc's keyboard & screen ?
> (or via a remote connection such as ssh ?)
> 
> If local, are you running in console or X11 display ?
> 
> you can disable preview (hence the need to open the X display) via
> command line switch : -d
>  as well as ini file: Display=Off
> 
> 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.
> 

I don't think it's a cookie file per se, although I don't know what that is.
I think the crux is "invalid display :0"
I see this sometimes if I ssh into a box.
My first test is always to see if xclock works.
I'd try like jr says, "-d"


-- 
dik
Rendered 1024 of 921600 pixels (0%)

Post a reply to this message

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.

> 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?

Post a reply to this message

On 2019-03-22 1:06 PM, dick balaska wrote:
> On 3/22/19 12:45 PM, 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 ?)
>>
>> If local, are you running in console or X11 display ?
>>
>> you can disable preview (hence the need to open the X display) via
>> command line switch : -d
>>   as well as ini file: Display=Off
>>
>> 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.
>>
> 
> I don't think it's a cookie file per se, although I don't know what that is.
> I think the crux is "invalid display :0"
> I see this sometimes if I ssh into a box.
> My first test is always to see if xclock works.

It works, but it also spits out "Invalid MIT-MAGIC-COOKIE-1 key" in the 
process.

> I'd try like jr says, "-d"

I don't want to use "-d"; it would defeat the purpose of my automated 
testing scripts.

Post a reply to this message

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.

Post a reply to this message

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,

Post a reply to this message

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.

The Web seems to tell me that this file is called .Xauthority.  I 
deleted that file, rebooted, and I got the same POV error.

Post a reply to this message

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> > If local, are you running in console or X11 display ?
> I'm using Konsole.  Whether that means console or X11 I don't know.

you could "ps aux | grep X", if you're running an X server it'll show in the
output.  also, a DISPLAY environment variable ought to exist.


regards, jr.

Post a reply to this message

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