Re: [Emc-users] bigger problem

[Gene Heskett]

On Wednesday 21 September 2016 17:16:39 andy pugh wrote:

> > I have zero clue what has occurred, but the ini file for my G0704
> > seems to have reverted somehow to a mid July date.
> >
> > Maybe you just picked a different config?

No. I did fix it, I wound up renaming the backup directory in that 
configname so it didn't match the configname, restarted LCNC, and it was 
then converted without a single hiccup that I know of.  And it has since 
carved me a new insert for my Rikon 10-325 bandsaws table. I've a bit of 
lathe work to do on it yet as its sitting about 5 thou high. But I 
should be able to safely use it as a precision hacksaw sometime 
tomorrow.

Thanks Andy.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] bigger problem

[andy pugh]

> I have zero clue what has occurred, but the ini file for my G0704 seems
> to have reverted somehow to a mid July date.
>
> Maybe you just picked a different config?

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the especial use of mechanical geniuses, daredevils and lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916
--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] bigger problem

[Gene Heskett]

Greetings all;

I have zero clue what has occurred, but the ini file for my G0704 seems 
to have reverted somehow to a mid July date. IOW, it never got 
converted, except I know it did, and it ran just fine last week.  Now it 
shuts down at random points doing a 360 degree, z-0.300 p12, proclaiming 
I need to go fix my joints limits for axis 1 when its 2" from the limit 
in the ini file.

Not clue how it got reverted, but I obviously need a copy of Andy's joint 
conversion script so I can re-run it.

This machine, like all of them has been updated nightly for yonks.
 
Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Gene Heskett]

On Saturday 09 May 2015 07:58:46 Mark Wendt wrote:
> On Fri, May 8, 2015 at 7:06 PM, Gene Heskett  wrote:
> > Progress report:
> >
> > I copied all the 5i25.*.bit and 5i25.*.xml files from the zip
> > archive I had pulled from Peters site a week ago, into /lib
> > /firmware/hm2/5i25.
> >
> > Then I did the compile and install of the boot.comp, fired up the
> > latest 2.8.0-pre of linuxcnc, did the homing dance without a tool
> > mounted, then mounted the cutoff tool, ran it to the right side of
> > the previously started cutoff and touched z off at 0.000.  Measured
> > the OD of the piece in the chuck, did an x touch off to that/2 and
> > ran it till it exited, stopping to sharpen the tool when it got dull
> > from all the chattering due to this things rubber tool post.  Had to
> > stop & edit the code to comp for what I was sharpening off the tool
> > 3 or 4 times.
> >
> > Wash. rinse, repeat till the piece fell off.  About an hours running
> > time, no crashes.
> >
> > I've read here that there were a few things I would need to update
> > in the configs for the 2.8 upgrade, but these  were the configs in
> > effect for 2.6.7 when the drive signed off, and I had to reformat
> > and re-install the newer stuffs.  When I shut it down there were a
> > few msgs on the screen I ran it from.  Mostly saying it was using a
> > default for so & so that I probably need to add to the .ini or .hal
> > file.  They'll still be there when I next turn on the monitor.
> >
> > It appears that a G96 dxxx s100 over-rides the spindle speed as I
> > could not modify it from the axis spindle speed slider.  Is this a
> > bug, or intended behavior?  It was turning at a steady 200 +- about
> > 10 rpm.
> >
> > In the meantime the shops deck floor is about 14" from done & we
> > found a termite nest in the outside corner.  They ignored wasp
> > spray, and I am out of straight 2x6's till the sun dry's them and
> > straightens them by drying the tops faster than the bottoms (I hope
> > anyway). That will give me a chance to yell at Orkin.  The house &
> > attached garage is covered & under contract, but none of the other
> > buildings are included.
> >
> > As treated wood goes, its soaking wet, my pin meter said 26% water.
> > Heavy, soggy stuff to handle, Lowes apparently stores the bundle out
> > in the weather till they need it inside to sell.  A bit like Johnny
> > in the Rodeo song. :(
> >
> > To recap, nfs is working, ssh -Y is working and its beer thirty.
> > And I left Dee figuring out what we do for din-din.
> >
> > Cheers, Gene Heskett
> > --
>
> Most excellent!  Glad to hear you got 'er up and running again!
>
> Mark

Yeah, now I have some sump plumbing to make into 1.25" pvc, and some 
wiring too, I need to add another circuit to handle some of the utility 
stuff in the basement.

When everthing is running, my amprobe says 17 amps, on a 20 amp breaker, 
and its old wire, so that 12 ga romex is warm.  This place was built & 
wired before there was any NEC enforcement. :(

I figure a 2nd 20 amp breaker in the new 200 amp box ought to handle the 
2 dehumidifiers in the far end along with this sump pump without blinkin 
the lights.  Might even pickup the CoCo3's desk on the way by as it has 
a laser printer on it, hungry when running like most lasers.

The fun part will be drilling a hole below the music (was an attached 
garage in '74) room floor level from the new garage, where the transfer 
panel is, and finding a push rod shoved thru after removing a block 
thats already loose in the top of the basement wall where I had a small 
heat duct installed when I put a new 95% furnace in 8 or 9 years ago.

There are support studs going down to the old garage floor under the 
music room floor that are in the way, so it will be fun since the whole 
thing was blown full of CoCoon insulation when I redid that room with 
some new ceiling panelling with about a foot of CoCoon on top of it, 
took out a sliding patio door that was a barn door for a heat leak, 
filled in the 2 steps down in the floor to get to ground level and 
replaced it with some triple pane Pella windows, with 4" of blue styro, 
equ to r22, replacing anything that got opened up in the process.

The old house service is a 60 amp pushmatic, and full to the gills. 100 
amps too damned  small the day it was installed in '74.  So there's 
always something holding up its hand and doing the pee dance for me to 
do around this place.

And I still have 4 buckets of clay on the back porch to coax back out of 
the bucket & tamp down into the gas line ditch from putting in the 20kw 
standby a year ago.  Hard as rock by now I expect. I wasn't counting on 
putting a foot thru the shop's decking in the middle of all this. :(

Sometime I wonder if I'll last long enough to git-r-all-done. ;-)  Keeps 
me out of the bars though.  And if it helps entertain an otherwise 
technical list, you are welcome. :)

To put this back on topic, has a wiki page been composed yet that will 
guide me i

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Mark Wendt]

On Fri, May 8, 2015 at 7:06 PM, Gene Heskett  wrote:

>
>
> Progress report:
>
> I copied all the 5i25.*.bit and 5i25.*.xml files from the zip archive I
> had pulled from Peters site a week ago, into /lib /firmware/hm2/5i25.
>
> Then I did the compile and install of the boot.comp, fired up the latest
> 2.8.0-pre of linuxcnc, did the homing dance without a tool mounted, then
> mounted the cutoff tool, ran it to the right side of the previously
> started cutoff and touched z off at 0.000.  Measured the OD of the piece
> in the chuck, did an x touch off to that/2 and ran it till it exited,
> stopping to sharpen the tool when it got dull from all the chattering
> due to this things rubber tool post.  Had to stop & edit the code to
> comp for what I was sharpening off the tool 3 or 4 times.
>
> Wash. rinse, repeat till the piece fell off.  About an hours running
> time, no crashes.
>
> I've read here that there were a few things I would need to update in the
> configs for the 2.8 upgrade, but these  were the configs in effect for
> 2.6.7 when the drive signed off, and I had to reformat and re-install
> the newer stuffs.  When I shut it down there were a few msgs on the
> screen I ran it from.  Mostly saying it was using a default for so & so
> that I probably need to add to the .ini or .hal file.  They'll still be
> there when I next turn on the monitor.
>
> It appears that a G96 dxxx s100 over-rides the spindle speed as I could
> not modify it from the axis spindle speed slider.  Is this a bug, or
> intended behavior?  It was turning at a steady 200 +- about 10 rpm.
>
> In the meantime the shops deck floor is about 14" from done & we found a
> termite nest in the outside corner.  They ignored wasp spray, and I am
> out of straight 2x6's till the sun dry's them and straightens them by
> drying the tops faster than the bottoms (I hope anyway). That will give
> me a chance to yell at Orkin.  The house & attached garage is covered &
> under contract, but none of the other buildings are included.
>
> As treated wood goes, its soaking wet, my pin meter said 26% water.
> Heavy, soggy stuff to handle, Lowes apparently stores the bundle out in
> the weather till they need it inside to sell.  A bit like Johnny in the
> Rodeo song. :(
>
> To recap, nfs is working, ssh -Y is working and its beer thirty.
> And I left Dee figuring out what we do for din-din.
>
> Cheers, Gene Heskett
> --
>

Most excellent!  Glad to hear you got 'er up and running again!

Mark
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Gene Heskett]

On Friday 08 May 2015 11:44:46 Jon Elson wrote:
> On 05/08/2015 04:19 AM, Mark Wendt wrote:
> > On Thu, May 7, 2015 at 8:08 PM, Gene Heskett 
> > wrote:
> >
> >
> > Okay, the ssh logins are working correctly.  Now we have a Linuxcnc
> > problem.  Just to verify the ssh logins are working correctly, can
> > you bring up any other X applications, like gears, or the eyes?
>
> Yes, this is the acid test.  If glx-gears runs on the remote
> CPU and sends its screen to the local machine, then Axis
> should run fine. And, if it doesn't, then you know the ONLY
> problem is getting open-gl support on the local machine.
>
> Jon

Progress report:

I copied all the 5i25.*.bit and 5i25.*.xml files from the zip archive I 
had pulled from Peters site a week ago, into /lib /firmware/hm2/5i25.

Then I did the compile and install of the boot.comp, fired up the latest 
2.8.0-pre of linuxcnc, did the homing dance without a tool mounted, then 
mounted the cutoff tool, ran it to the right side of the previously 
started cutoff and touched z off at 0.000.  Measured the OD of the piece 
in the chuck, did an x touch off to that/2 and ran it till it exited, 
stopping to sharpen the tool when it got dull from all the chattering 
due to this things rubber tool post.  Had to stop & edit the code to 
comp for what I was sharpening off the tool 3 or 4 times.

Wash. rinse, repeat till the piece fell off.  About an hours running 
time, no crashes.

I've read here that there were a few things I would need to update in the 
configs for the 2.8 upgrade, but these  were the configs in effect for 
2.6.7 when the drive signed off, and I had to reformat and re-install 
the newer stuffs.  When I shut it down there were a few msgs on the 
screen I ran it from.  Mostly saying it was using a default for so & so 
that I probably need to add to the .ini or .hal file.  They'll still be 
there when I next turn on the monitor.

It appears that a G96 dxxx s100 over-rides the spindle speed as I could 
not modify it from the axis spindle speed slider.  Is this a bug, or 
intended behavior?  It was turning at a steady 200 +- about 10 rpm.

In the meantime the shops deck floor is about 14" from done & we found a 
termite nest in the outside corner.  They ignored wasp spray, and I am 
out of straight 2x6's till the sun dry's them and straightens them by 
drying the tops faster than the bottoms (I hope anyway). That will give 
me a chance to yell at Orkin.  The house & attached garage is covered & 
under contract, but none of the other buildings are included.

As treated wood goes, its soaking wet, my pin meter said 26% water.  
Heavy, soggy stuff to handle, Lowes apparently stores the bundle out in 
the weather till they need it inside to sell.  A bit like Johnny in the 
Rodeo song. :(

To recap, nfs is working, ssh -Y is working and its beer thirty.
And I left Dee figuring out what we do for din-din.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Mark Wendt]

On Fri, May 8, 2015 at 11:48 AM, Jon Elson  wrote:

> On 05/08/2015 07:15 AM, Mark Wendt wrote:
> > On Fri, May 8, 2015 at 7:49 AM, Gene Heskett  wrote:
> >
> >>> Okay, the ssh logins are working correctly.  Now we have a Linuxcnc
> >>> problem.  Just to verify the ssh logins are working correctly, can you
> >>> bring up any other X applications, like gears, or the eyes?
> >> xeyes and glxgears both work, albeit gears is a bit slow, 21 fps.
> >>
> > Good.  That may be network related, but with X, who knows?  May even be a
> > framebuffer issue.
> >
> >
> No, it probably means he's running Mesa, the SOFTWARE
> open-gl rendering module.
>
> Jon
>

Could very well be.

Mark
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Jon Elson]

On 05/08/2015 07:15 AM, Mark Wendt wrote:
> On Fri, May 8, 2015 at 7:49 AM, Gene Heskett  wrote:
>
>>> Okay, the ssh logins are working correctly.  Now we have a Linuxcnc
>>> problem.  Just to verify the ssh logins are working correctly, can you
>>> bring up any other X applications, like gears, or the eyes?
>> xeyes and glxgears both work, albeit gears is a bit slow, 21 fps.
>>
> Good.  That may be network related, but with X, who knows?  May even be a
> framebuffer issue.
>
>
No, it probably means he's running Mesa, the SOFTWARE 
open-gl rendering module.

Jon

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Jon Elson]

On 05/08/2015 04:19 AM, Mark Wendt wrote:
> On Thu, May 7, 2015 at 8:08 PM, Gene Heskett  wrote:
>
>
> Okay, the ssh logins are working correctly.  Now we have a Linuxcnc
> problem.  Just to verify the ssh logins are working correctly, can you
> bring up any other X applications, like gears, or the eyes?
>
>
Yes, this is the acid test.  If glx-gears runs on the remote 
CPU and sends its screen to the local machine, then Axis 
should run fine. And, if it doesn't, then you know the ONLY 
problem is getting open-gl support on the local machine.

Jon

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Gene Heskett]

On Friday 08 May 2015 08:31:14 Gene Heskett wrote:
> On Friday 08 May 2015 08:15:57 Mark Wendt wrote:
[...]
> > > So it appears I will have to reinvent that module as I had used
> > > something Jon suggested, with the pulses lengthened and a 2 or 3
> > > repeat loop added, its the powerup enable for his pwm driven servo
> > > amplifier, which I am using to drive the lathes spindle motor.
> > >
> > > I may have a copy of it on this machine, if I'd recognize it when
> > > I saw it.

And I found it, on that lathe machine, it was backed up and has now been 
recovered by amanda, as  boot.comp.

But by now I don't know what comp has been renamed to, halcompile 
perhaps.  Looks like the perp anyway.

Looks like c++ code, so I expect I'll need build-essential too.

Studying man page.  Back later, the coffee IV went dry.  As Jackie 
said, "what a revoltin development that is" ;-)

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Gene Heskett]

On Friday 08 May 2015 08:15:57 Mark Wendt wrote:
> On Fri, May 8, 2015 at 7:49 AM, Gene Heskett  wrote:
> > > Okay, the ssh logins are working correctly.  Now we have a
> > > Linuxcnc problem.  Just to verify the ssh logins are working
> > > correctly, can you bring up any other X applications, like gears,
> > > or the eyes?
> >
> > xeyes and glxgears both work, albeit gears is a bit slow, 21 fps.
>
> Good.  That may be network related, but with X, who knows?  May even
> be a framebuffer issue.
>
> > > Okay, this kinda goes back to the same error as above - the
> > > "BACKGROUND ." It keeps trying to invoke the 'image" command on
> > > something which doesn't exist.  Here's one workaround I found:
> > >
> > > "Workaround:
> > >
> > > Create ~/.Xresources plain text file with content:
> > >
> > > *.background: gray75
> > >
> > > then
> > > $xrdb -load ~/.Xresources"
> > >
> > >
> > > This may not set up the right color for the "BACKGROUND", but try
> > > it to see if the errors go away.
> >
> > You da man. But I think I just found an error, a file that has not
> > been included in my backups, bad dog, no biscuit.
> > The startup gui to select the machine config now shows up, but then
> > it dies.  Trace:
> > Found file:./my_LinuxCNC_machine2.hal
> > ./my_LinuxCNC_machine2.hal:12: Can't find module 'boot'
> > in /usr/realtime-3.4-9-rtai-686-pae/modules/linuxcnc
> > Shutting down and cleaning up LinuxCNC...
> > Running HAL shutdown script
> > LinuxCNC terminated with an error.  You can find more information in
> > the log:
> > /home/gene/linuxcnc_debug.txt
> > and
> > /home/gene/linuxcnc_print.txt
> > as well as in the output of the shell command 'dmesg' and in the
> > terminal
> >
> > So it appears I will have to reinvent that module as I had used
> > something Jon suggested, with the pulses lengthened and a 2 or 3
> > repeat loop added, its the powerup enable for his pwm driven servo
> > amplifier, which I am using to drive the lathes spindle motor.
> >
> > I may have a copy of it on this machine, if I'd recognize it when I
> > saw it.
>
> Normally that file is a user created file, however, some programs may
> create that automagically in your home directory.  Not sure if the
> install of Linuxcnc does that or not.  I'll have to check that on my
> machine at home.
>
> > Humm, tried to run a sim/axis/lathe, it asked me to allow a copy to
> > be made on my configs dir, I click yes, and the startup script baled
> > out:
> >
> > gene@lathe:~$ linuxcnc
> > LINUXCNC - 2.8.0-pre1-602-gfa8867a
> > Error in startup script: error
> > deleting "/home/gene/linuxcnc/nc_files/ngcgui_lib": directory not
> > empty while executing
> > "file delete $linkname"
> > (procedure "prompt_copy" line 69)
> > invoked from within
> > "prompt_copy $::inifile"
> > invoked from within
> > "if [ok_to_copy_config $::inifile] {
> > set copied_inifile [prompt_copy $::inifile]
> > if {$copied_inifile == ""} {
> > c..."
> > ("while" body line 6)
> > invoked from within
> > "while {1} {
> > focus $::tree
> > vwait ::choice
> >
> > if { $::choice == "OK" } {
> > if [ok_to_copy_config $::inifile] {
> > set copied_in..."
> > (file "/usr/lib/tcltk/linuxcnc/bin/pickconfig.tcl" line 806)
>
> Wonder why it's trying to delete an existing directory, with files in
> it? Since that's the case, rename the ncgui_lib directory to some
> other name and see if it will run.

Not life & death.  It should now Just Work once I get that boot module 
restored, and get 5i25.zip unpacked in the lib/firmware/hm2 tree.

But first, hook up the caffeine IV.
>
> > So I'll go see if I can find a local copy of that missing boot
> > module.  I also need to move a copy of 5i25.zip to there but until I
> > can make the nfs share mountpoint directory on this machine, thats
> > not going to work. sftp to the rescue for that.
> >
> > My nfs shares are all mounted at /net/machinename, but for some
> > reason I, nor sudo, cannot mkdir lathe, no permission.  For all I
> > know it could be this funkity drive.
>
> Nope, /net directories are controlled, I believe by autofs, and only
> autofs can make or destroy directories there.

That I did not know.  Thanks.
[...]
> > Exactly what I expected.  That will greatly facilitate making it all
> > fly again.  Now I better go & make us some starter fluid, aka
> > coffee.  Come to think of it, I had apt-get install the
> > nfs-kernel-server about an hour ago, on that machine because I
> > noticed it was missing from the /etc/init.d directory.  Duh.  Thats
> > what I get for doing all this without any morning caffeine.  The
> > damned dots don't connect. :(
>
> I can empathize.  I'm worthless till I hook up the caffeine IV.  ;-)

[...] :)

> > And that session of synaptic just caused x to log:
> > X Error: BadWindow (invalid Window parameter) 3
> >   Major opcode:  19
> >   Minor opcode:  0
> >   Resource id:  0x440004d
> >
> > But the wondow 

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Mark Wendt]

On Fri, May 8, 2015 at 7:58 AM, Gene Heskett  wrote:

> On Friday 08 May 2015 05:22:58 Mark Wendt wrote:
>
> > You can usually get the line number of the offending key in the
> > known_hosts file when ssh barfs on the login.  I use
> > vi/vim/whateverthehell line editor Linux uses these days.  Open vi,
> > type G, hit dd, hit esc, :wq and try again.  ;-)
> >
> > Mark
>
> nano works well for that too.
>
> Cheers, Gene Heskett
>

Can't help myself.  I'm a vi bigot.  ;-)

Mark
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Mark Wendt]

On Fri, May 8, 2015 at 7:49 AM, Gene Heskett  wrote:

>
> >
> > Okay, the ssh logins are working correctly.  Now we have a Linuxcnc
> > problem.  Just to verify the ssh logins are working correctly, can you
> > bring up any other X applications, like gears, or the eyes?
>
> xeyes and glxgears both work, albeit gears is a bit slow, 21 fps.
>

Good.  That may be network related, but with X, who knows?  May even be a
framebuffer issue.


>
>
>
> >
> > Okay, this kinda goes back to the same error as above - the
> > "BACKGROUND ." It keeps trying to invoke the 'image" command on
> > something which doesn't exist.  Here's one workaround I found:
> >
> > "Workaround:
> >
> > Create ~/.Xresources plain text file with content:
> >
> > *.background: gray75
> >
> > then
> > $xrdb -load ~/.Xresources"
> >
> >
> > This may not set up the right color for the "BACKGROUND", but try it
> > to see if the errors go away.
> >
> You da man. But I think I just found an error, a file that has not been
> included in my backups, bad dog, no biscuit.
> The startup gui to select the machine config now shows up, but then it
> dies.  Trace:
> Found file:./my_LinuxCNC_machine2.hal
> ./my_LinuxCNC_machine2.hal:12: Can't find module 'boot'
> in /usr/realtime-3.4-9-rtai-686-pae/modules/linuxcnc
> Shutting down and cleaning up LinuxCNC...
> Running HAL shutdown script
> LinuxCNC terminated with an error.  You can find more information in the
> log:
> /home/gene/linuxcnc_debug.txt
> and
> /home/gene/linuxcnc_print.txt
> as well as in the output of the shell command 'dmesg' and in the terminal
>
> So it appears I will have to reinvent that module as I had used something
> Jon suggested, with the pulses lengthened and a 2 or 3 repeat loop
> added, its the powerup enable for his pwm driven servo amplifier, which
> I am using to drive the lathes spindle motor.
>
> I may have a copy of it on this machine, if I'd recognize it when I saw
> it.
>

Normally that file is a user created file, however, some programs may
create that automagically in your home directory.  Not sure if the install
of Linuxcnc does that or not.  I'll have to check that on my machine at
home.


> Humm, tried to run a sim/axis/lathe, it asked me to allow a copy to be
> made on my configs dir, I click yes, and the startup script baled out:
>
> gene@lathe:~$ linuxcnc
> LINUXCNC - 2.8.0-pre1-602-gfa8867a
> Error in startup script: error
> deleting "/home/gene/linuxcnc/nc_files/ngcgui_lib": directory not empty
> while executing
> "file delete $linkname"
> (procedure "prompt_copy" line 69)
> invoked from within
> "prompt_copy $::inifile"
> invoked from within
> "if [ok_to_copy_config $::inifile] {
> set copied_inifile [prompt_copy $::inifile]
> if {$copied_inifile == ""} {
> c..."
> ("while" body line 6)
> invoked from within
> "while {1} {
> focus $::tree
> vwait ::choice
>
> if { $::choice == "OK" } {
> if [ok_to_copy_config $::inifile] {
> set copied_in..."
> (file "/usr/lib/tcltk/linuxcnc/bin/pickconfig.tcl" line 806)
>

Wonder why it's trying to delete an existing directory, with files in it?
Since that's the case, rename the ncgui_lib directory to some other name
and see if it will run.


>
> So I'll go see if I can find a local copy of that missing boot module.  I
> also need to move a copy of 5i25.zip to there but until I can make the
> nfs share mountpoint directory on this machine, thats not going to work.
> sftp to the rescue for that.
>
> My nfs shares are all mounted at /net/machinename, but for some reason I,
> nor sudo, cannot mkdir lathe, no permission.  For all I know it could be
> this funkity drive.
>

Nope, /net directories are controlled, I believe by autofs, and only autofs
can make or destroy directories there.


>
> example trace:
> WTF?  Now the directory already exists, and the mount is working.
>
> gene@coyote:/etc/apt$ cd /net
> gene@coyote:/net$ sudo mkdir lathe
> mkdir: cannot create directory `lathe': File exists
> gene@coyote:/net$ ls
> lappy  lathe  shop
> gene@coyote:/net$
> gene@coyote:/net$ ls -l /lathe
> ls: cannot access /lathe: No such file or directory
> gene@coyote:/net$ ls -l lathe
> total 108
> drwxr-xr-x   2 root   root  4096 May  6 13:18 bin
> drwxr-xr-x   2 root   root  4096 May  6 12:56 boot
> drwxr-xr-x   4 root   root  4096 May  6 12:56 dev
> drwxr-xr-x 130 root   root 12288 May  8 00:54 etc
> drwxr-xr-x   2 backup disk  4096 May  6 17:35 GenesAmandaHelper-0.61
> drwxr-xr-x   4 root   root  4096 May  6 21:40 home
> lrwxrwxrwx   1 root   root35 May  6 12:56
> initrd.img -> /boot/initrd.img-3.4-9-rtai-686-pae
> drwxr-xr-x  15 root   root  4096 May  6 13:15 lib
> drwx--   2 root   root 16384 May  6 12:05 lost+found
> drwxr-xr-x   3 root   root  4096 Jul  3  2014 media
> drwxr-xr-x   2 root   root  4096 Apr 19  2014 mnt
> drwxr-xr-x   2 root   root  4096 May  8 07:28 net
> drwxr-xr-x   2 root   root  4096 Jul  3  2014 opt

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Gene Heskett]

On Friday 08 May 2015 05:22:58 Mark Wendt wrote:
> On Thu, May 7, 2015 at 10:20 PM, Jon Elson  
wrote:
> > On 05/07/2015 01:01 PM, Gene Heskett wrote:
> > > "list" on lathe is totally differently formatted
> >
> > YES, I've noticed this!  They changed the format of the
> > .ssh/known_hosts file!
> > You can just erase the whole known_hosts file, and it will
> > just ask you to OK creating new entries when you attempt to
> > connect. Sometimes even just rebooting a machine will change
> > the ssh passwords and require the offending line to be
> > removed.  The new file format doesn't have human readable IP
> > addresses, so it is hard to know which line(s) belong to a
> > particular host.  Rebuilding a host at the same IP address
> > will guarantee the old known_hosts entry will be invalid,
> > and prevent the ssh connection.
> >
> > Jon
>
> You can usually get the line number of the offending key in the
> known_hosts file when ssh barfs on the login.  I use
> vi/vim/whateverthehell line editor Linux uses these days.  Open vi,
> type G, hit dd, hit esc, :wq and try again.  ;-)
>
> Mark

nano works well for that too.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Gene Heskett]

On Friday 08 May 2015 05:19:49 Mark Wendt wrote:
> On Thu, May 7, 2015 at 8:08 PM, Gene Heskett  wrote:
> > > On your first xauth on coyote, it looks like an IPv6 magic cookie.
> > >  Do you have IPv6 enabled?  This here:
> > > [fe80::21f:c6ff:fe62:fcbb]:0 looks suspiciously like some kind of
> > > local IPv6 address.  Try disabling IPv6 on coyote.  Ssh will
> > > automagically try to make it's connection on IPv6 and if it's not
> > > available, can either sit there till it times out, or cause other
> > > problems.
> >
> > Where would I tell it to skip the IPV6 stuffs?  AFAIK, there are no
> > ipv6 things enabled, and my little 8 port switch does not to my
> > knowledge even know what ipv6 is.  And ALL paths go thru that
> > switch.
> >
> > > You might try connecting with this string:  #ssh -4 -Y  > > -vvv
> > >
> > > the -4 tells ssh to skip the IPv6 attempt and go right to an IPv4
> > > connection.
> > >
> > > Mark
> >
> > I just moved my known_hosts to known_hosts.old, then reaccepted the
> > keys from both machines.  Still no luck.
> >
> > Logging into lathe and running linuxcnc returns:
> >
> > gene@coyote:~$ ssh -4 -Y lathe
> > The authenticity of host 'lathe (192.168.71.5)' can't be
> > established. RSA key fingerprint is
> > 1a:75:8f:b3:aa:d7:83:bd:7a:5e:d3:dc:82:76:9c:4f. Are you sure you
> > want to continue connecting (yes/no)? yes
> > Warning: Permanently added 'lathe,192.168.71.5' (RSA) to the list of
> > known hosts.
> > gene@lathe's password:
> > Linux lathe 3.4-9-rtai-686-pae #1 SMP PREEMPT Debian
> > 3.4.55-4linuxcnc i686
> >
> > The programs included with the Debian GNU/Linux system are free
> > software; the exact distribution terms for each program are
> > described in the individual files in /usr/share/doc/*/copyright.
> >
> > Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
> > permitted by applicable law.
> > Last login: Thu May  7 19:49:19 2015 from coyote.coyote.den
>
> Okay, so far, so good.
>
> > gene@lathe:~$ linuxcnc
> > LINUXCNC - 2.8.0-pre1-602-gfa8867a
> > Application initialization failed: unknown color name "BACKGROUND"
> > Error in startup script: can't invoke "image" command:  application
> > has been destroyed
> > while executing
> > "image create photo -file $f/$i.gif"
> > invoked from within
> > "if [file exists $f/$i.gif] {
> > return [image create photo -file $f/$i.gif]
> > }"
> > (procedure "linuxcnc::image_search" line 7)
> > invoked from within
> > "linuxcnc::image_search linuxcnc-wizard"
> > invoked from within
> > "set logo [linuxcnc::image_search linuxcnc-wizard]"
> > (file "/usr/lib/tcltk/linuxcnc/bin/pickconfig.tcl" line 31)
> > Application initialization failed: unknown color name "BACKGROUND"
>
> Okay, the ssh logins are working correctly.  Now we have a Linuxcnc
> problem.  Just to verify the ssh logins are working correctly, can you
> bring up any other X applications, like gears, or the eyes?

xeyes and glxgears both work, albeit gears is a bit slow, 21 fps.

> > Into shop, I get this:
> > gene@coyote:~$ ssh -4 -Y shop
> > The authenticity of host 'shop (192.168.71.4)' can't be established.
> > RSA key fingerprint is
> > 7a:b4:de:b0:7f:fa:73:24:83:7f:9f:cd:19:56:65:8a. Are you sure you
> > want to continue connecting (yes/no)? yes
> > Warning: Permanently added 'shop,192.168.71.4' (RSA) to the list of
> > known hosts.
> > gene@shop's password:
> > Linux shop 2.6.32-122-rtai #rtai SMP Tue Jul 27 12:44:07 CDT 2010
> > i686 GNU/Linux
> > Ubuntu 10.04.4 LTS
> >
> > Welcome to Ubuntu!
> >  * Documentation:  https://help.ubuntu.com/
> >
> > New release 'precise' available.
> > Run 'do-release-upgrade' to upgrade to it.
> >
> > Last login: Mon May  4 10:44:12 2015 from coyote.coyote.den
> >
> > gene@shop:~$ linuxcnc -l
> > LINUXCNC - 2.6.7
> > Machine configuration directory
> > is '/home/gene/linuxcnc/configs/my-mill-atom-3'
> > Machine configuration file is 'my-mill-atom-3.ini'
> > Starting LinuxCNC...
> > Traceback (most recent call last):
> >   File "/usr/bin/hal_manualtoolchange", line 62, in 
> > app = Tkinter.Tk(className="AxisToolChanger")
> >   File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 1646, in
> > __init__ self.tk = _tkinter.create(screenName, baseName, className,
> > interactive, wantobjects, useTk, sync, use)
> > _tkinter.TclError: unknown color name "BACKGROUND"
> > Traceback (most recent call last):
> >   File "/usr/bin/axis", line 121, in 
> > root_window = Tkinter.Tk(className="Axis")
> >   File "/usr/bin/axis", line 44, in __init__
> > OldTk.__init__(self, *args, **kw)
> >   File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 1646, in
> > __init__ self.tk = _tkinter.create(screenName, baseName, className,
> > interactive, wantobjects, useTk, sync, use)
> > _tkinter.TclError: unknown color name "BACKGROUND"
> > Shutting down and cleaning up LinuxCNC...
> > Traceback (most recent call last):
> >   File "/usr/bin/axis-remote", line 78, in 
> > t = Tkinter.Tk(); t

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Mark Wendt]

On Thu, May 7, 2015 at 10:20 PM, Jon Elson  wrote:

> On 05/07/2015 01:01 PM, Gene Heskett wrote:
> >
> > "list" on lathe is totally differently formatted
> YES, I've noticed this!  They changed the format of the
> .ssh/known_hosts file!
> You can just erase the whole known_hosts file, and it will
> just ask you to OK creating new entries when you attempt to
> connect. Sometimes even just rebooting a machine will change
> the ssh passwords and require the offending line to be
> removed.  The new file format doesn't have human readable IP
> addresses, so it is hard to know which line(s) belong to a
> particular host.  Rebuilding a host at the same IP address
> will guarantee the old known_hosts entry will be invalid,
> and prevent the ssh connection.
>
> Jon
>

You can usually get the line number of the offending key in the known_hosts
file when ssh barfs on the login.  I use vi/vim/whateverthehell line editor
Linux uses these days.  Open vi, type G, hit dd, hit esc, :wq
and try again.  ;-)

Mark
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Mark Wendt]

On Thu, May 7, 2015 at 8:08 PM, Gene Heskett  wrote:

>
> >
> > On your first xauth on coyote, it looks like an IPv6 magic cookie.  Do
> > you have IPv6 enabled?  This here: [fe80::21f:c6ff:fe62:fcbb]:0 looks
> > suspiciously like some kind of local IPv6 address.  Try disabling IPv6
> > on coyote.  Ssh will automagically try to make it's connection on IPv6
> > and if it's not available, can either sit there till it times out, or
> > cause other problems.
>
> Where would I tell it to skip the IPV6 stuffs?  AFAIK, there are no ipv6
> things enabled, and my little 8 port switch does not to my knowledge
> even know what ipv6 is.  And ALL paths go thru that switch.
> >
> > You might try connecting with this string:  #ssh -4 -Y  >
> > the -4 tells ssh to skip the IPv6 attempt and go right to an IPv4
> > connection.
> >
> > Mark
>
> I just moved my known_hosts to known_hosts.old, then reaccepted the keys
> from both machines.  Still no luck.
>
> Logging into lathe and running linuxcnc returns:
>
> gene@coyote:~$ ssh -4 -Y lathe
> The authenticity of host 'lathe (192.168.71.5)' can't be established.
> RSA key fingerprint is 1a:75:8f:b3:aa:d7:83:bd:7a:5e:d3:dc:82:76:9c:4f.
> Are you sure you want to continue connecting (yes/no)? yes
> Warning: Permanently added 'lathe,192.168.71.5' (RSA) to the list of
> known hosts.
> gene@lathe's password:
> Linux lathe 3.4-9-rtai-686-pae #1 SMP PREEMPT Debian 3.4.55-4linuxcnc
> i686
>
> The programs included with the Debian GNU/Linux system are free software;
> the exact distribution terms for each program are described in the
> individual files in /usr/share/doc/*/copyright.
>
> Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
> permitted by applicable law.
> Last login: Thu May  7 19:49:19 2015 from coyote.coyote.den
>

Okay, so far, so good.


>
> gene@lathe:~$ linuxcnc
> LINUXCNC - 2.8.0-pre1-602-gfa8867a
> Application initialization failed: unknown color name "BACKGROUND"
> Error in startup script: can't invoke "image" command:  application has
> been destroyed
> while executing
> "image create photo -file $f/$i.gif"
> invoked from within
> "if [file exists $f/$i.gif] {
> return [image create photo -file $f/$i.gif]
> }"
> (procedure "linuxcnc::image_search" line 7)
> invoked from within
> "linuxcnc::image_search linuxcnc-wizard"
> invoked from within
> "set logo [linuxcnc::image_search linuxcnc-wizard]"
> (file "/usr/lib/tcltk/linuxcnc/bin/pickconfig.tcl" line 31)
> Application initialization failed: unknown color name "BACKGROUND"
>

Okay, the ssh logins are working correctly.  Now we have a Linuxcnc
problem.  Just to verify the ssh logins are working correctly, can you
bring up any other X applications, like gears, or the eyes?


>
> Into shop, I get this:
> gene@coyote:~$ ssh -4 -Y shop
> The authenticity of host 'shop (192.168.71.4)' can't be established.
> RSA key fingerprint is 7a:b4:de:b0:7f:fa:73:24:83:7f:9f:cd:19:56:65:8a.
> Are you sure you want to continue connecting (yes/no)? yes
> Warning: Permanently added 'shop,192.168.71.4' (RSA) to the list of known
> hosts.
> gene@shop's password:
> Linux shop 2.6.32-122-rtai #rtai SMP Tue Jul 27 12:44:07 CDT 2010 i686
> GNU/Linux
> Ubuntu 10.04.4 LTS
>
> Welcome to Ubuntu!
>  * Documentation:  https://help.ubuntu.com/
>
> New release 'precise' available.
> Run 'do-release-upgrade' to upgrade to it.
>
> Last login: Mon May  4 10:44:12 2015 from coyote.coyote.den
>
> gene@shop:~$ linuxcnc -l
> LINUXCNC - 2.6.7
> Machine configuration directory
> is '/home/gene/linuxcnc/configs/my-mill-atom-3'
> Machine configuration file is 'my-mill-atom-3.ini'
> Starting LinuxCNC...
> Traceback (most recent call last):
>   File "/usr/bin/hal_manualtoolchange", line 62, in 
> app = Tkinter.Tk(className="AxisToolChanger")
>   File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 1646, in __init__
> self.tk = _tkinter.create(screenName, baseName, className,
> interactive, wantobjects, useTk, sync, use)
> _tkinter.TclError: unknown color name "BACKGROUND"
> Traceback (most recent call last):
>   File "/usr/bin/axis", line 121, in 
> root_window = Tkinter.Tk(className="Axis")
>   File "/usr/bin/axis", line 44, in __init__
> OldTk.__init__(self, *args, **kw)
>   File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 1646, in __init__
> self.tk = _tkinter.create(screenName, baseName, className,
> interactive, wantobjects, useTk, sync, use)
> _tkinter.TclError: unknown color name "BACKGROUND"
> Shutting down and cleaning up LinuxCNC...
> Traceback (most recent call last):
>   File "/usr/bin/axis-remote", line 78, in 
> t = Tkinter.Tk(); t.wm_withdraw()
>   File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 1646, in __init__
> self.tk = _tkinter.create(screenName, baseName, className,
> interactive, wantobjects, useTk, sync, use)
> _tkinter.TclError: unknown color name "BACKGROUND"
> Application initialization failed: unknown color name "BACKGROUND"
> LinuxCNC terminated

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Jon Elson]

On 05/07/2015 01:01 PM, Gene Heskett wrote:
>
> "list" on lathe is totally differently formatted
YES, I've noticed this!  They changed the format of the 
.ssh/known_hosts file!
You can just erase the whole known_hosts file, and it will 
just ask you to OK creating new entries when you attempt to 
connect. Sometimes even just rebooting a machine will change 
the ssh passwords and require the offending line to be 
removed.  The new file format doesn't have human readable IP 
addresses, so it is hard to know which line(s) belong to a 
particular host.  Rebuilding a host at the same IP address 
will guarantee the old known_hosts entry will be invalid, 
and prevent the ssh connection.

Jon

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Gene Heskett]

On Thursday 07 May 2015 15:54:49 Mark Wendt wrote:
> On Thu, May 7, 2015 at 2:01 PM, Gene Heskett  wrote:
> > On Thursday 07 May 2015 12:16:44 Jon Elson wrote:
> > > On 05/07/2015 02:20 AM, Gene Heskett wrote:
> > > > I have been able to export the x session to this box forever,
> > > > and it has worked nominally well, till now.
> > > >
> > > > But this machine now has debian 7.8 (wheezy) on it, and the
> > > > lathe just got its drive reformatted and has the
> > > > binary-hybrid.iso installed on it.
> > >
> > > Much easier than trying LinuxCNC, use xclock.  It will work,
> > > or not, hopefully give an error message, and only takes a
> > > second or so.  If xclock brings up your analog clock dial,
> > > then most of the X support is going to work.  The one other
> > > thing that is required is some kind of 3D rendering support,
> > > if you are going to use Axis.
> > >
> > > If xclock does NOT work, then your X server is rejecting the
> > > connection request from the LinuxCNC system.  This is
> > > STANDARD behavior!
> > >
> > > Here's a quote from my bag of tricks file:
> > >to allow remote systems to use your X screen
> > >  1. get your cookie with :
> > >  xauth
> > >list
> >
> > And get this:
> > xauth> list
> > coyote.coyote.den:0  MIT-MAGIC-COOKIE-1 
> > e7b9e1a766fdb4aa1d23f7ad305baf17 [fe80::21f:c6ff:fe62:fcbb]:0 
> > MIT-MAGIC-COOKIE-1
> > e7b9e1a766fdb4aa1d23f7ad305baf17
> > coyote/unix:0  MIT-MAGIC-COOKIE-1  e7b9e1a766fdb4aa1d23f7ad305baf17
> >
> > >  2.  copy the line with mouse
> >
> > which line, or the whole thing?
> >
> > >  3. on remote connection, do
> > >  xauth
> >
> > "list" on lathe is totally differently formatted
> > xauth> list
> > lathe/unix:0  MIT-MAGIC-COOKIE-1  384f881f7983355c1b2b3fe7dc8e8925
> > lathe/unix:11  MIT-MAGIC-COOKIE-1  2da267aca6bea446de8cc445ed10474c
> > lathe/unix:10  MIT-MAGIC-COOKIE-1  aa5cf4dbb7194605bdfc87a386f3c9f6
> > lathe/unix:12  MIT-MAGIC-COOKIE-1  9a6c36c2e37d080cf74e7bb9f47142de
> >
> > Which looks more sensible than the first paste from coyote above.
> >
> > Directions plz?
> >
> > >add 
> > >exit
> > >  and it should now allow the remote
> > >  system to connect to the X screen
> > >
> > > It seems like there was some other option that needed to be
> > > hacked in the X config file on some systems.
> > > See
> > > http://www.cyberciti.biz/faq/x11-connection-rejected-because-of-wr
> > >ong- authentication/ for some more things to check.  The last item
> > > there is the
> > > one I was thinking of.
> >
> > Thanks, Jon
> >
> > Humm, the last test item is running xeyes, and while it does report
> > the FOREGROUND and BACKGROUND colors are undefined, it works and
> > they are following the mouse as it moves.  What does that tell us?
> >
> > Cheers, Gene Heskett
>
> On your first xauth on coyote, it looks like an IPv6 magic cookie.  Do
> you have IPv6 enabled?  This here: [fe80::21f:c6ff:fe62:fcbb]:0 looks
> suspiciously like some kind of local IPv6 address.  Try disabling IPv6
> on coyote.  Ssh will automagically try to make it's connection on IPv6
> and if it's not available, can either sit there till it times out, or
> cause other problems.

Where would I tell it to skip the IPV6 stuffs?  AFAIK, there are no ipv6 
things enabled, and my little 8 port switch does not to my knowledge 
even know what ipv6 is.  And ALL paths go thru that switch.
>
> You might try connecting with this string:  #ssh -4 -Y 
> the -4 tells ssh to skip the IPv6 attempt and go right to an IPv4
> connection.
>
> Mark

I just moved my known_hosts to known_hosts.old, then reaccepted the keys 
from both machines.  Still no luck.

Logging into lathe and running linuxcnc returns:

gene@coyote:~$ ssh -4 -Y lathe
The authenticity of host 'lathe (192.168.71.5)' can't be established.
RSA key fingerprint is 1a:75:8f:b3:aa:d7:83:bd:7a:5e:d3:dc:82:76:9c:4f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'lathe,192.168.71.5' (RSA) to the list of 
known hosts.
gene@lathe's password: 
Linux lathe 3.4-9-rtai-686-pae #1 SMP PREEMPT Debian 3.4.55-4linuxcnc 
i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu May  7 19:49:19 2015 from coyote.coyote.den

gene@lathe:~$ linuxcnc
LINUXCNC - 2.8.0-pre1-602-gfa8867a
Application initialization failed: unknown color name "BACKGROUND"
Error in startup script: can't invoke "image" command:  application has 
been destroyed
while executing
"image create photo -file $f/$i.gif"
invoked from within
"if [file exists $f/$i.gif] {
return [image create photo -file $f/$i.gif]
}"
(procedure "linuxcnc::image_search" line 7)
invoked from within
"linuxcnc::image_search linuxcnc-wizard"
  

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Mark Wendt]

On Thu, May 7, 2015 at 2:01 PM, Gene Heskett  wrote:

> On Thursday 07 May 2015 12:16:44 Jon Elson wrote:
> > On 05/07/2015 02:20 AM, Gene Heskett wrote:
> > > I have been able to export the x session to this box forever, and it
> > > has worked nominally well, till now.
> > >
> > > But this machine now has debian 7.8 (wheezy) on it, and the lathe
> > > just got its drive reformatted and has the binary-hybrid.iso
> > > installed on it.
> >
> > Much easier than trying LinuxCNC, use xclock.  It will work,
> > or not, hopefully give an error message, and only takes a
> > second or so.  If xclock brings up your analog clock dial,
> > then most of the X support is going to work.  The one other
> > thing that is required is some kind of 3D rendering support,
> > if you are going to use Axis.
> >
> > If xclock does NOT work, then your X server is rejecting the
> > connection request from the LinuxCNC system.  This is
> > STANDARD behavior!
> >
> > Here's a quote from my bag of tricks file:
> >to allow remote systems to use your X screen
> >  1. get your cookie with :
> >  xauth
> >list
> And get this:
> xauth> list
> coyote.coyote.den:0  MIT-MAGIC-COOKIE-1  e7b9e1a766fdb4aa1d23f7ad305baf17
> [fe80::21f:c6ff:fe62:fcbb]:0  MIT-MAGIC-COOKIE-1
> e7b9e1a766fdb4aa1d23f7ad305baf17
> coyote/unix:0  MIT-MAGIC-COOKIE-1  e7b9e1a766fdb4aa1d23f7ad305baf17
>
> >  2.  copy the line with mouse
> which line, or the whole thing?
>
> >  3. on remote connection, do
> >  xauth
> "list" on lathe is totally differently formatted
> xauth> list
> lathe/unix:0  MIT-MAGIC-COOKIE-1  384f881f7983355c1b2b3fe7dc8e8925
> lathe/unix:11  MIT-MAGIC-COOKIE-1  2da267aca6bea446de8cc445ed10474c
> lathe/unix:10  MIT-MAGIC-COOKIE-1  aa5cf4dbb7194605bdfc87a386f3c9f6
> lathe/unix:12  MIT-MAGIC-COOKIE-1  9a6c36c2e37d080cf74e7bb9f47142de
>
> Which looks more sensible than the first paste from coyote above.
>
> Directions plz?
>
> >add 
> >exit
> >  and it should now allow the remote
> >  system to connect to the X screen
> >
> > It seems like there was some other option that needed to be
> > hacked in the X config file on some systems.
> > See
> > http://www.cyberciti.biz/faq/x11-connection-rejected-because-of-wrong-
> >authentication/ for some more things to check.  The last item there is
> > the
> > one I was thinking of.
> >
> Thanks, Jon
>
> Humm, the last test item is running xeyes, and while it does report the
> FOREGROUND and BACKGROUND colors are undefined, it works and they are
> following the mouse as it moves.  What does that tell us?
>
> Cheers, Gene Heskett
>


On your first xauth on coyote, it looks like an IPv6 magic cookie.  Do you
have IPv6 enabled?  This here: [fe80::21f:c6ff:fe62:fcbb]:0 looks
suspiciously like some kind of local IPv6 address.  Try disabling IPv6 on
coyote.  Ssh will automagically try to make it's connection on IPv6 and if
it's not available, can either sit there till it times out, or cause other
problems.

You might try connecting with this string:  #ssh -4 -Y http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Mark Wendt]

On Thu, May 7, 2015 at 1:45 PM, Gene Heskett  wrote:

> On Thursday 07 May 2015 10:41:55 Mark Wendt wrote:
> [...]
> > Can you post your sshd_config from the lathe machine, and also what
> > you see from ssh -Y -vvv ?
> >
> a copy paste, screen at a time of lathe/etc/ssh/sshd_config:
> 
> # Package generated configuration file
> # See the sshd_config(5) manpage for details
>
> # What ports, IPs and protocols we listen for
> Port 22
> # Use these options to restrict which interfaces/protocols sshd will bind
> to
> #ListenAddress ::
> #ListenAddress 0.0.0.0
> Protocol 2
> # HostKeys for protocol version 2
> HostKey /etc/ssh/ssh_host_rsa_key
> HostKey /etc/ssh/ssh_host_dsa_key
> #HostKey /etc/ssh/ssh_host_ecdsa_key
> #Privilege Separation is turned on for security
> UsePrivilegeSeparation yes
>
> # Lifetime and size of ephemeral version 1 server key
> KeyRegenerationInterval 3600
> ServerKeyBits 768
>
> # Logging
> SyslogFacility AUTH
> LogLevel INFO
>
> # Authentication:
> LoginGraceTime 120
> PermitRootLogin yes
> StrictModes yes
>
> RSAAuthentication yes
> PubkeyAuthentication yes
> #AuthorizedKeysFile %h/.ssh/authorized_keys
>
> # Don't read the user's ~/.rhosts and ~/.shosts files
> IgnoreRhosts yes
> # For this to work you will also need host keys in /etc/ssh_known_hosts
> RhostsRSAAuthentication no
> # similar for protocol version 2
> HostbasedAuthentication no
> # Uncomment if you don't trust ~/.ssh/known_hosts for
> RhostsRSAAuthentication
> #IgnoreUserKnownHosts yes
>
> # To enable empty passwords, change to yes (NOT RECOMMENDED)
> PermitEmptyPasswords no
>
> # Change to yes to enable challenge-response passwords (beware issues
> with
> # some PAM modules and threads)
> ChallengeResponseAuthentication no
> # Change to no to disable tunnelled clear text passwords
> #PasswordAuthentication yes
>
> # Kerberos options
> #KerberosAuthentication no
> #KerberosGetAFSToken no
> #KerberosOrLocalPasswd yes
> #KerberosTicketCleanup yes
>
> # GSSAPI options
> #GSSAPIAuthentication no
> #GSSAPICleanupCredentials yes
>
> X11Forwarding yes
> X11DisplayOffset 10
> PrintMotd no
> PrintLastLog yes
> TCPKeepAlive yes
> #UseLogin no
>
> #MaxStartups 10:30:60
> #Banner /etc/issue.net
>
> # Allow client to pass locale environment variables
> AcceptEnv LANG LC_*
>
> Subsystem sftp /usr/lib/openssh/sftp-server
>
> # Set this to 'yes' to enable PAM authentication, account processing,
> # and session processing. If this is enabled, PAM authentication will
> # be allowed through the ChallengeResponseAuthentication and
> # PasswordAuthentication.  Depending on your PAM configuration,
> # PAM authentication via ChallengeResponseAuthentication may bypass
> # the setting of "PermitRootLogin without-password".
> # If you just want the PAM account and session checks to run without
> # PAM authentication, then enable this but set PasswordAuthentication
> # and ChallengeResponseAuthentication to 'no'.
> UsePAM yes
>
> ==
>
> log out, log back in with all the -vvv's
>
> gene@coyote:~$ ssh -Y lathe -vvv
> OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 19: Applying options for *
> debug2: ssh_connect: needpriv 0
> debug1: Connecting to lathe [192.168.71.5] port 22.
> debug1: Connection established.
> debug1: identity file /home/gene/.ssh/id_rsa type -1
> debug1: identity file /home/gene/.ssh/id_rsa-cert type -1
> debug1: identity file /home/gene/.ssh/id_dsa type -1
> debug1: identity file /home/gene/.ssh/id_dsa-cert type -1
> debug1: identity file /home/gene/.ssh/id_ecdsa type -1
> debug1: identity file /home/gene/.ssh/id_ecdsa-cert type -1
> debug1: Remote protocol version 2.0, remote software version
> OpenSSH_6.0p1 Debian-4+deb7u2
> debug1: match: OpenSSH_6.0p1 Debian-4+deb7u2 pat OpenSSH*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2
> debug2: fd 3 setting O_NONBLOCK
> debug3: load_hostkeys: loading entries for host "lathe" from
> file "/home/gene/.ssh/known_hosts"
> debug3: load_hostkeys: found key type ECDSA in
> file /home/gene/.ssh/known_hosts:3
> debug3: load_hostkeys: loaded 1 keys
> debug3: order_hostkeyalgs: prefer hostkeyalgs:
> ecdsa-sha2-nistp256-cert-...@openssh.com,
> ecdsa-sha2-nistp384-cert-...@openssh.com,
> ecdsa-sha2-nistp521-cert-...@openssh.com
> ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug2: kex_parse_kexinit:
>
> ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
> debug2: kex_parse_kexinit:
> ecdsa-sha2-nistp256-cert-...@openssh.com,
> ecdsa-sha2-nistp384-cert-...@openssh.com,
> ecdsa-sha2-nistp521-cert-...@openssh.com
> ,ecdsa-sha2-nistp256,ecd

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Gene Heskett]

On Thursday 07 May 2015 12:16:44 Jon Elson wrote:
> On 05/07/2015 02:20 AM, Gene Heskett wrote:
> > I have been able to export the x session to this box forever, and it
> > has worked nominally well, till now.
> >
> > But this machine now has debian 7.8 (wheezy) on it, and the lathe
> > just got its drive reformatted and has the binary-hybrid.iso
> > installed on it.
>
> Much easier than trying LinuxCNC, use xclock.  It will work,
> or not, hopefully give an error message, and only takes a
> second or so.  If xclock brings up your analog clock dial,
> then most of the X support is going to work.  The one other
> thing that is required is some kind of 3D rendering support,
> if you are going to use Axis.
>
> If xclock does NOT work, then your X server is rejecting the
> connection request from the LinuxCNC system.  This is
> STANDARD behavior!
>
> Here's a quote from my bag of tricks file:
>to allow remote systems to use your X screen
>  1. get your cookie with :
>  xauth
>list
And get this:
xauth> list
coyote.coyote.den:0  MIT-MAGIC-COOKIE-1  e7b9e1a766fdb4aa1d23f7ad305baf17
[fe80::21f:c6ff:fe62:fcbb]:0  MIT-MAGIC-COOKIE-1  
e7b9e1a766fdb4aa1d23f7ad305baf17
coyote/unix:0  MIT-MAGIC-COOKIE-1  e7b9e1a766fdb4aa1d23f7ad305baf17

>  2.  copy the line with mouse
which line, or the whole thing?

>  3. on remote connection, do
>  xauth
"list" on lathe is totally differently formatted
xauth> list
lathe/unix:0  MIT-MAGIC-COOKIE-1  384f881f7983355c1b2b3fe7dc8e8925
lathe/unix:11  MIT-MAGIC-COOKIE-1  2da267aca6bea446de8cc445ed10474c
lathe/unix:10  MIT-MAGIC-COOKIE-1  aa5cf4dbb7194605bdfc87a386f3c9f6
lathe/unix:12  MIT-MAGIC-COOKIE-1  9a6c36c2e37d080cf74e7bb9f47142de

Which looks more sensible than the first paste from coyote above.

Directions plz?

>add 
>exit
>  and it should now allow the remote
>  system to connect to the X screen
>
> It seems like there was some other option that needed to be
> hacked in the X config file on some systems.
> See
> http://www.cyberciti.biz/faq/x11-connection-rejected-because-of-wrong-
>authentication/ for some more things to check.  The last item there is
> the
> one I was thinking of.
>
Thanks, Jon

Humm, the last test item is running xeyes, and while it does report the 
FOREGROUND and BACKGROUND colors are undefined, it works and they are 
following the mouse as it moves.  What does that tell us?

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Gene Heskett]

On Thursday 07 May 2015 10:41:55 Mark Wendt wrote:
[...]
> Can you post your sshd_config from the lathe machine, and also what
> you see from ssh -Y -vvv ?
>
a copy paste, screen at a time of lathe/etc/ssh/sshd_config:

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind 
to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for 
RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues 
with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

==

log out, log back in with all the -vvv's

gene@coyote:~$ ssh -Y lathe -vvv
OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to lathe [192.168.71.5] port 22.
debug1: Connection established.
debug1: identity file /home/gene/.ssh/id_rsa type -1
debug1: identity file /home/gene/.ssh/id_rsa-cert type -1
debug1: identity file /home/gene/.ssh/id_dsa type -1
debug1: identity file /home/gene/.ssh/id_dsa-cert type -1
debug1: identity file /home/gene/.ssh/id_ecdsa type -1
debug1: identity file /home/gene/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version 
OpenSSH_6.0p1 Debian-4+deb7u2
debug1: match: OpenSSH_6.0p1 Debian-4+deb7u2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "lathe" from 
file "/home/gene/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in 
file /home/gene/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: 
ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: 
ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: 
ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: 
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes25

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Jon Elson]

On 05/07/2015 02:20 AM, Gene Heskett wrote:
> I have been able to export the x session to this box forever, and it has
> worked nominally well, till now.
>
> But this machine now has debian 7.8 (wheezy) on it, and the lathe just
> got its drive reformatted and has the binary-hybrid.iso installed on it.
Much easier than trying LinuxCNC, use xclock.  It will work, 
or not, hopefully give an error message, and only takes a 
second or so.  If xclock brings up your analog clock dial, 
then most of the X support is going to work.  The one other 
thing that is required is some kind of 3D rendering support, 
if you are going to use Axis.

If xclock does NOT work, then your X server is rejecting the 
connection request from the LinuxCNC system.  This is 
STANDARD behavior!

Here's a quote from my bag of tricks file:
   to allow remote systems to use your X screen
 1. get your cookie with :
 xauth
   list
 2.  copy the line with mouse
 3. on remote connection, do
 xauth
   add 
   exit
 and it should now allow the remote
 system to connect to the X screen

It seems like there was some other option that needed to be 
hacked in the X config file on some systems.
See
http://www.cyberciti.biz/faq/x11-connection-rejected-because-of-wrong-authentication/
for some more things to check.  The last item there is the 
one I was thinking of.

Jon

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Gene Heskett]

On Thursday 07 May 2015 10:31:18 Mark Wendt wrote:
> On Thu, May 7, 2015 at 9:55 AM, Gene Heskett  wrote:
> > > Gene,
> > >
> > > Not sure why you had to do that in the ancient past either.  The
> > > -X or -Y handles the X connection, the -X setting your display
> > > variable on the machine, and subjecting the connection to the X11
> > > Security extensions by default.  The -Y enables trusted X11
> > > forwarding, and is less safe to use than the -X ssh connection
> > > since it does "not" subject the connection to the Security
> > > extensions.
> > >
> > > Either way, using the -X or -Y on the command line obviates the
> > > need for the xhost entries, since that's accomplished via the -X
> > > or -Y connection. Leaving the machine entries in the xhost list
> > > opens that machine to malicious attacks from any one of the
> > > machines listed.
> > >
> > > To troubleshoot ssh connections, try connecting with this next
> > > time: # ssh -X -vvv .  The -vvv will give you verbose
> > > debugging messages while you are trying to connect, and hopefully
> > > narrow down what is causing the ssh -X or ssh -Y to not connect.
> > >
> > > Do you have X11 forwarding enabled in the /etc/ssh/sshd_config?
> >
> > Humm.  Yes, on all machines.  By doing blink compares, the wheezy
> > based installs have this added line:
> >
> > HostKey /etc/ssh/ssh_host_ecdsa_key
> >
> > And the wheezy based machines have that key and a key.pub version of
> > it, that the 10.04-4 LTS version does not have.
> >
> > WTH is that?  More to the point, can I nuke that line ?  Commenting
> > it out and restarting the ssh daemon made no change.
> >
> > Cheers, Gene Heskett
>
> Depends on what protocols you are using.  Here at a US Gummint
> facility, we only use the rsa and dsa protocols. and ssh Protocol 2,
> with only very strong cipers and hmac-sha1.
>
> Here's the two HostKey lines we use:
>
> # HostKeys for protocol version 2
> HostKey /etc/ssh/ssh_host_rsa_key
> HostKey /etc/ssh/ssh_host_dsa_key
>
Those are both active.

> You have to be careful with the keywords used in the sshd_config. 
> Some affect the way other keywords work.  Also, some keywords in your
> ssh_config (system-wide ssh client file) may conflict with what is
> allowed in the sshd_config file, but can be overridden by the command
> line qualifiers.

I'll check those ssh_configs too.

Thanks Mark

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Mark Wendt]

On Thu, May 7, 2015 at 10:02 AM, Gene Heskett  wrote:

> >
> > I'm confused a bit.  Up above, you said you were having the problems
> > on the lathe machine, but in the paragraph just above this, the
> > problem is now on the mill machine?
> >
> > Mark
>
> When attempting run linuxcnc, yes, update-manager will run and remote its
> display on the shop,10.04-4 LTS machine, but not on the lathe which is
> the new binary-hybrid.iso install.
>
> This is the refusal to run update-manager of the lathe's install, from an
> ssh -Y session here:
>
> gene@lathe:~$ sudo update-manager
> X11 connection rejected because of wrong authentication.
> /usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:57: GtkWarning:
> could not open display
>   warnings.warn(str(e), _gtk.Warning)
> X11 connection rejected because of wrong authentication.
> [   ERROR:UpdateManager.BugHandler] No exception handler installed.
> Traceback (most recent call last):
>   File "/usr/bin/update-manager", line 37, in 
> app = Application(APP_NAME, LOCALE_DIR, frontend='Gtk')
>   File "/usr/lib/pymodules/python2.7/UpdateManager/Application.py", line
> 120, in __init__
> self._load_frontend(frontend)
>   File "/usr/lib/pymodules/python2.7/UpdateManager/Application.py", line
> 201, in _load_frontend
> "frontend", FrontendBase)
>   File "/usr/lib/pymodules/python2.7/UpdateManager/Application.py", line
> 240, in _load_meta
> obj = symbol(*module_args, **module_kwargs)
>
> File "/usr/lib/pymodules/python2.7/UpdateManager/Frontend/Gtk/__init__.py",
> line 59, in __init__
> gtk.init_check()
> RuntimeError: could not open display
>
> So WTH is this wrong authenification?
>
> The above was snapshoted after commenting out the extra line
> in /etc/ssh/sshd_config and restarting the ssh daemons on both machines.
>
> Cheers, Gene Heskett
>

Can you post your sshd_config from the lathe machine, and also what you see
from ssh -Y -vvv ?

Mark
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Mark Wendt]

On Thu, May 7, 2015 at 9:55 AM, Gene Heskett  wrote:

>
> >
> > Gene,
> >
> > Not sure why you had to do that in the ancient past either.  The -X or
> > -Y handles the X connection, the -X setting your display variable on
> > the machine, and subjecting the connection to the X11 Security
> > extensions by default.  The -Y enables trusted X11 forwarding, and is
> > less safe to use than the -X ssh connection since it does "not"
> > subject the connection to the Security extensions.
> >
> > Either way, using the -X or -Y on the command line obviates the need
> > for the xhost entries, since that's accomplished via the -X or -Y
> > connection. Leaving the machine entries in the xhost list opens that
> > machine to malicious attacks from any one of the machines listed.
> >
> > To troubleshoot ssh connections, try connecting with this next time: #
> > ssh -X -vvv .  The -vvv will give you verbose debugging
> > messages while you are trying to connect, and hopefully narrow down
> > what is causing the ssh -X or ssh -Y to not connect.
> >
> > Do you have X11 forwarding enabled in the /etc/ssh/sshd_config?
> Humm.  Yes, on all machines.  By doing blink compares, the wheezy based
> installs have this added line:
>
> HostKey /etc/ssh/ssh_host_ecdsa_key
>
> And the wheezy based machines have that key and a key.pub version of it,
> that the 10.04-4 LTS version does not have.
>
> WTH is that?  More to the point, can I nuke that line ?  Commenting it
> out and restarting the ssh daemon made no change.
>
> Cheers, Gene Heskett
>


Depends on what protocols you are using.  Here at a US Gummint facility, we
only use the rsa and dsa protocols. and ssh Protocol 2, with only very
strong cipers and hmac-sha1.

Here's the two HostKey lines we use:

# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

You have to be careful with the keywords used in the sshd_config.  Some
affect the way other keywords work.  Also, some keywords in your ssh_config
(system-wide ssh client file) may conflict with what is allowed in the
sshd_config file, but can be overridden by the command line qualifiers.

Mark
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Gene Heskett]

On Thursday 07 May 2015 09:17:37 Mark Wendt wrote:
> On Thu, May 7, 2015 at 9:10 AM, Gene Heskett  wrote:
> > On Thursday 07 May 2015 08:44:26 Gene Heskett wrote:
> > > On Thursday 07 May 2015 05:07:08 Mark Wendt wrote:
> > > > On Thu, May 7, 2015 at 3:20 AM, Gene Heskett 
> >
> > wrote:
> > > > > I have been able to export the x session to this box forever,
> > > > > and it has worked nominally well, till now.
> > > > >
> > > > > But this machine now has debian 7.8 (wheezy) on it, and the
> > > > > lathe just got its drive reformatted and has the
> > > > > binary-hybrid.iso installed on it.
>
> 
>
> > > ISTR I had to do that at some point back in the fog of ancient
> > > history. That should not be whats killing me now I would think. 
> > > It would be one heck of a regression if thats the case.  OTOH, I
> > > was never able to use ssh -X because of a similar error, and now
> > > even -Y only works for text terminal's?
> > >
> > > Thanks Mark.
> >
> > Slight correction, a different application that still uses an X
> > remote display, update-manager, still works from the 10.04-4 LTS
> > install thats on the milling machine, on this screen here.  So some
> > of it works.
> >
> > Cheers, Gene Heskett
>
> I'm confused a bit.  Up above, you said you were having the problems
> on the lathe machine, but in the paragraph just above this, the
> problem is now on the mill machine?
>
> Mark

When attempting run linuxcnc, yes, update-manager will run and remote its 
display on the shop,10.04-4 LTS machine, but not on the lathe which is 
the new binary-hybrid.iso install.

This is the refusal to run update-manager of the lathe's install, from an 
ssh -Y session here:

gene@lathe:~$ sudo update-manager
X11 connection rejected because of wrong authentication.
/usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:57: GtkWarning: 
could not open display
  warnings.warn(str(e), _gtk.Warning)
X11 connection rejected because of wrong authentication.
[   ERROR:UpdateManager.BugHandler] No exception handler installed.
Traceback (most recent call last):
  File "/usr/bin/update-manager", line 37, in 
app = Application(APP_NAME, LOCALE_DIR, frontend='Gtk')
  File "/usr/lib/pymodules/python2.7/UpdateManager/Application.py", line 
120, in __init__
self._load_frontend(frontend)
  File "/usr/lib/pymodules/python2.7/UpdateManager/Application.py", line 
201, in _load_frontend
"frontend", FrontendBase)
  File "/usr/lib/pymodules/python2.7/UpdateManager/Application.py", line 
240, in _load_meta
obj = symbol(*module_args, **module_kwargs)
  
File "/usr/lib/pymodules/python2.7/UpdateManager/Frontend/Gtk/__init__.py", 
line 59, in __init__
gtk.init_check()
RuntimeError: could not open display

So WTH is this wrong authenification?

The above was snapshoted after commenting out the extra line 
in /etc/ssh/sshd_config and restarting the ssh daemons on both machines.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Gene Heskett]

On Thursday 07 May 2015 09:11:44 Mark Wendt wrote:
> On Thu, May 7, 2015 at 8:44 AM, Gene Heskett  wrote:
> > > If you're using ssh -X or ssh -Y those are unnecessary xhost
> > > entries.
> > >
> > > Mark
> >
> > ISTR I had to do that at some point back in the fog of ancient
> > history. That should not be whats killing me now I would think.  It
> > would be one heck of a regression if thats the case.  OTOH, I was
> > never able to use ssh -X because of a similar error, and now even -Y
> > only works for text terminal's?
> >
> > Thanks Mark.
> >
> > Cheers, Gene Heskett
>
> Gene,
>
> Not sure why you had to do that in the ancient past either.  The -X or
> -Y handles the X connection, the -X setting your display variable on
> the machine, and subjecting the connection to the X11 Security
> extensions by default.  The -Y enables trusted X11 forwarding, and is
> less safe to use than the -X ssh connection since it does "not"
> subject the connection to the Security extensions.
>
> Either way, using the -X or -Y on the command line obviates the need
> for the xhost entries, since that's accomplished via the -X or -Y
> connection. Leaving the machine entries in the xhost list opens that
> machine to malicious attacks from any one of the machines listed.
>
> To troubleshoot ssh connections, try connecting with this next time: #
> ssh -X -vvv .  The -vvv will give you verbose debugging
> messages while you are trying to connect, and hopefully narrow down
> what is causing the ssh -X or ssh -Y to not connect.
>
> Do you have X11 forwarding enabled in the /etc/ssh/sshd_config?
Humm.  Yes, on all machines.  By doing blink compares, the wheezy based 
installs have this added line:

HostKey /etc/ssh/ssh_host_ecdsa_key

And the wheezy based machines have that key and a key.pub version of it,
that the 10.04-4 LTS version does not have.

WTH is that?  More to the point, can I nuke that line ?  Commenting it 
out and restarting the ssh daemon made no change.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Mark Wendt]

On Thu, May 7, 2015 at 9:10 AM, Gene Heskett  wrote:

> On Thursday 07 May 2015 08:44:26 Gene Heskett wrote:
> > On Thursday 07 May 2015 05:07:08 Mark Wendt wrote:
> > > On Thu, May 7, 2015 at 3:20 AM, Gene Heskett 
> wrote:
> > > > I have been able to export the x session to this box forever, and
> > > > it has worked nominally well, till now.
> > > >
> > > > But this machine now has debian 7.8 (wheezy) on it, and the lathe
> > > > just got its drive reformatted and has the binary-hybrid.iso
> > > > installed on it.
>




> >
> > ISTR I had to do that at some point back in the fog of ancient
> > history. That should not be whats killing me now I would think.  It
> > would be one heck of a regression if thats the case.  OTOH, I was
> > never able to use ssh -X because of a similar error, and now even -Y
> > only works for text terminal's?
> >
> > Thanks Mark.
>
> Slight correction, a different application that still uses an X remote
> display, update-manager, still works from the 10.04-4 LTS install thats
> on the milling machine, on this screen here.  So some of it works.
>
> Cheers, Gene Heskett
>


I'm confused a bit.  Up above, you said you were having the problems on the
lathe machine, but in the paragraph just above this, the problem is now on
the mill machine?

Mark
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Mark Wendt]

On Thu, May 7, 2015 at 8:44 AM, Gene Heskett  wrote:

>
> >
> > If you're using ssh -X or ssh -Y those are unnecessary xhost entries.
> >
> > Mark
>
> ISTR I had to do that at some point back in the fog of ancient history.
> That should not be whats killing me now I would think.  It would be one
> heck of a regression if thats the case.  OTOH, I was never able to use
> ssh -X because of a similar error, and now even -Y only works for text
> terminal's?
>
> Thanks Mark.
>
> Cheers, Gene Heskett
>

Gene,

Not sure why you had to do that in the ancient past either.  The -X or -Y
handles the X connection, the -X setting your display variable on the
machine, and subjecting the connection to the X11 Security extensions by
default.  The -Y enables trusted X11 forwarding, and is less safe to use
than the -X ssh connection since it does "not" subject the connection to
the Security extensions.

Either way, using the -X or -Y on the command line obviates the need for
the xhost entries, since that's accomplished via the -X or -Y connection.
Leaving the machine entries in the xhost list opens that machine to
malicious attacks from any one of the machines listed.

To troubleshoot ssh connections, try connecting with this next time: # ssh
-X -vvv .  The -vvv will give you verbose debugging messages while
you are trying to connect, and hopefully narrow down what is causing the
ssh -X or ssh -Y to not connect.

Do you have X11 forwarding enabled in the /etc/ssh/sshd_config?
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Gene Heskett]

On Thursday 07 May 2015 08:44:26 Gene Heskett wrote:
> On Thursday 07 May 2015 05:07:08 Mark Wendt wrote:
> > On Thu, May 7, 2015 at 3:20 AM, Gene Heskett  
wrote:
> > > I have been able to export the x session to this box forever, and
> > > it has worked nominally well, till now.
> > >
> > > But this machine now has debian 7.8 (wheezy) on it, and the lathe
> > > just got its drive reformatted and has the binary-hybrid.iso
> > > installed on it.
> > >
> > > Tonight, I am "ssh -Y shop" from this machine, and when I try to
> > > run linuxcnc -l from the logged in terminal, it now fails, as does
> > > a login to lathe.coyote.den by the same syntax.
> > >
> > > gene@shop:~$ linuxcnc -l
> > > LINUXCNC - 2.6.7
> > > Machine configuration directory
> > > is '/home/gene/linuxcnc/configs/my-mill-atom-3'
> > > Machine configuration file is 'my-mill-atom-3.ini'
> > > Starting LinuxCNC...
> > > Traceback (most recent call last):
> > >   File "/usr/bin/hal_manualtoolchange", line 62, in 
> > > app = Tkinter.Tk(className="AxisToolChanger")
> > >   File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 1646, in
> > > __init__ self.tk = _tkinter.create(screenName, baseName,
> > > className, interactive, wantobjects, useTk, sync, use)
> > > _tkinter.TclError: unknown color name "BACKGROUND"
> > > Traceback (most recent call last):
> > >   File "/usr/bin/axis", line 121, in 
> > > root_window = Tkinter.Tk(className="Axis")
> > >   File "/usr/bin/axis", line 44, in __init__
> > > OldTk.__init__(self, *args, **kw)
> > >   File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 1646, in
> > > __init__ self.tk = _tkinter.create(screenName, baseName,
> > > className, interactive, wantobjects, useTk, sync, use)
> > > _tkinter.TclError: unknown color name "BACKGROUND"
> > > Shutting down and cleaning up LinuxCNC...
> > > Traceback (most recent call last):
> > >   File "/usr/bin/axis-remote", line 78, in 
> > > t = Tkinter.Tk(); t.wm_withdraw()
> > >   File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 1646, in
> > > __init__ self.tk = _tkinter.create(screenName, baseName,
> > > className, interactive, wantobjects, useTk, sync, use)
> > > _tkinter.TclError: unknown color name "BACKGROUND"
> > > Application initialization failed: unknown color name "BACKGROUND"
> > > LinuxCNC terminated with an error.  You can find more information
> > > in the log:
> > > /home/gene/linuxcnc_debug.txt
> > > and
> > > /home/gene/linuxcnc_print.txt
> > > as well as in the output of the shell command 'dmesg' and in the
> > > terminal
> > >
> > > dmesg is silent as to cause
> > >
> > > xhost output on shop
> > > gene@shop:~$ xhost
> > > access control disabled, clients can connect from any host
> > > INET:coyote.coyote.den
> > > INET:lathe.coyote.den
> > > INET:shop.coyote.den
> > > SI:localuser:gene
> > >
> > > Dittos for here
> > > gene@coyote:~$ xhost
> > > access control disabled, clients can connect from any host
> > > INET:coyote.coyote.den
> > > INET:lathe.coyote.den
> > > INET:shop.coyote.den
> > > SI:localuser:gene
> > >
> > > and 'lathe' is another copy.
> > > The .ssh/known_keys have been updated too.
> > >
> > > Unknown color name BACKGROUND?
> > >
> > > Probaly something forehead slappable simple, so the first thing I
> > > checked was xhost.
> > >
> > > Where do I look & check next?
> > >
> > > Thanks.
> > >
> > >
> > > Cheers, Gene Heskett
> >
> > Gene,
> >
> > If you're using ssh -X or ssh -Y those are unnecessary xhost
> > entries.
> >
> > Mark
>
> ISTR I had to do that at some point back in the fog of ancient
> history. That should not be whats killing me now I would think.  It
> would be one heck of a regression if thats the case.  OTOH, I was
> never able to use ssh -X because of a similar error, and now even -Y
> only works for text terminal's?
>
> Thanks Mark.

Slight correction, a different application that still uses an X remote 
display, update-manager, still works from the 10.04-4 LTS install thats 
on the milling machine, on this screen here.  So some of it works.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Gene Heskett]

On Thursday 07 May 2015 05:07:08 Mark Wendt wrote:
> On Thu, May 7, 2015 at 3:20 AM, Gene Heskett  wrote:
> > I have been able to export the x session to this box forever, and it
> > has worked nominally well, till now.
> >
> > But this machine now has debian 7.8 (wheezy) on it, and the lathe
> > just got its drive reformatted and has the binary-hybrid.iso
> > installed on it.
> >
> > Tonight, I am "ssh -Y shop" from this machine, and when I try to run
> > linuxcnc -l from the logged in terminal, it now fails, as does a
> > login to lathe.coyote.den by the same syntax.
> >
> > gene@shop:~$ linuxcnc -l
> > LINUXCNC - 2.6.7
> > Machine configuration directory
> > is '/home/gene/linuxcnc/configs/my-mill-atom-3'
> > Machine configuration file is 'my-mill-atom-3.ini'
> > Starting LinuxCNC...
> > Traceback (most recent call last):
> >   File "/usr/bin/hal_manualtoolchange", line 62, in 
> > app = Tkinter.Tk(className="AxisToolChanger")
> >   File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 1646, in
> > __init__ self.tk = _tkinter.create(screenName, baseName, className,
> > interactive, wantobjects, useTk, sync, use)
> > _tkinter.TclError: unknown color name "BACKGROUND"
> > Traceback (most recent call last):
> >   File "/usr/bin/axis", line 121, in 
> > root_window = Tkinter.Tk(className="Axis")
> >   File "/usr/bin/axis", line 44, in __init__
> > OldTk.__init__(self, *args, **kw)
> >   File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 1646, in
> > __init__ self.tk = _tkinter.create(screenName, baseName, className,
> > interactive, wantobjects, useTk, sync, use)
> > _tkinter.TclError: unknown color name "BACKGROUND"
> > Shutting down and cleaning up LinuxCNC...
> > Traceback (most recent call last):
> >   File "/usr/bin/axis-remote", line 78, in 
> > t = Tkinter.Tk(); t.wm_withdraw()
> >   File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 1646, in
> > __init__ self.tk = _tkinter.create(screenName, baseName, className,
> > interactive, wantobjects, useTk, sync, use)
> > _tkinter.TclError: unknown color name "BACKGROUND"
> > Application initialization failed: unknown color name "BACKGROUND"
> > LinuxCNC terminated with an error.  You can find more information in
> > the log:
> > /home/gene/linuxcnc_debug.txt
> > and
> > /home/gene/linuxcnc_print.txt
> > as well as in the output of the shell command 'dmesg' and in the
> > terminal
> >
> > dmesg is silent as to cause
> >
> > xhost output on shop
> > gene@shop:~$ xhost
> > access control disabled, clients can connect from any host
> > INET:coyote.coyote.den
> > INET:lathe.coyote.den
> > INET:shop.coyote.den
> > SI:localuser:gene
> >
> > Dittos for here
> > gene@coyote:~$ xhost
> > access control disabled, clients can connect from any host
> > INET:coyote.coyote.den
> > INET:lathe.coyote.den
> > INET:shop.coyote.den
> > SI:localuser:gene
> >
> > and 'lathe' is another copy.
> > The .ssh/known_keys have been updated too.
> >
> > Unknown color name BACKGROUND?
> >
> > Probaly something forehead slappable simple, so the first thing I
> > checked was xhost.
> >
> > Where do I look & check next?
> >
> > Thanks.
> >
> >
> > Cheers, Gene Heskett
>
> Gene,
>
> If you're using ssh -X or ssh -Y those are unnecessary xhost entries.
>
> Mark

ISTR I had to do that at some point back in the fog of ancient history.  
That should not be whats killing me now I would think.  It would be one 
heck of a regression if thats the case.  OTOH, I was never able to use 
ssh -X because of a similar error, and now even -Y only works for text 
terminal's?

Thanks Mark.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Mark Wendt]

On Thu, May 7, 2015 at 3:20 AM, Gene Heskett  wrote:

> I have been able to export the x session to this box forever, and it has
> worked nominally well, till now.
>
> But this machine now has debian 7.8 (wheezy) on it, and the lathe just
> got its drive reformatted and has the binary-hybrid.iso installed on it.
>
> Tonight, I am "ssh -Y shop" from this machine, and when I try to run
> linuxcnc -l from the logged in terminal, it now fails, as does a login
> to lathe.coyote.den by the same syntax.
>
> gene@shop:~$ linuxcnc -l
> LINUXCNC - 2.6.7
> Machine configuration directory
> is '/home/gene/linuxcnc/configs/my-mill-atom-3'
> Machine configuration file is 'my-mill-atom-3.ini'
> Starting LinuxCNC...
> Traceback (most recent call last):
>   File "/usr/bin/hal_manualtoolchange", line 62, in 
> app = Tkinter.Tk(className="AxisToolChanger")
>   File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 1646, in __init__
> self.tk = _tkinter.create(screenName, baseName, className,
> interactive, wantobjects, useTk, sync, use)
> _tkinter.TclError: unknown color name "BACKGROUND"
> Traceback (most recent call last):
>   File "/usr/bin/axis", line 121, in 
> root_window = Tkinter.Tk(className="Axis")
>   File "/usr/bin/axis", line 44, in __init__
> OldTk.__init__(self, *args, **kw)
>   File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 1646, in __init__
> self.tk = _tkinter.create(screenName, baseName, className,
> interactive, wantobjects, useTk, sync, use)
> _tkinter.TclError: unknown color name "BACKGROUND"
> Shutting down and cleaning up LinuxCNC...
> Traceback (most recent call last):
>   File "/usr/bin/axis-remote", line 78, in 
> t = Tkinter.Tk(); t.wm_withdraw()
>   File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 1646, in __init__
> self.tk = _tkinter.create(screenName, baseName, className,
> interactive, wantobjects, useTk, sync, use)
> _tkinter.TclError: unknown color name "BACKGROUND"
> Application initialization failed: unknown color name "BACKGROUND"
> LinuxCNC terminated with an error.  You can find more information in the
> log:
> /home/gene/linuxcnc_debug.txt
> and
> /home/gene/linuxcnc_print.txt
> as well as in the output of the shell command 'dmesg' and in the terminal
>
> dmesg is silent as to cause
>
> xhost output on shop
> gene@shop:~$ xhost
> access control disabled, clients can connect from any host
> INET:coyote.coyote.den
> INET:lathe.coyote.den
> INET:shop.coyote.den
> SI:localuser:gene
>
> Dittos for here
> gene@coyote:~$ xhost
> access control disabled, clients can connect from any host
> INET:coyote.coyote.den
> INET:lathe.coyote.den
> INET:shop.coyote.den
> SI:localuser:gene
>
> and 'lathe' is another copy.
> The .ssh/known_keys have been updated too.
>
> Unknown color name BACKGROUND?
>
> Probaly something forehead slappable simple, so the first thing I checked
> was xhost.
>
> Where do I look & check next?
>
> Thanks.
>
>
> Cheers, Gene Heskett
>


Gene,

If you're using ssh -X or ssh -Y those are unnecessary xhost entries.

Mark
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Bigger problem, ssh -Y doesn't work, xhost says its allowed

[Gene Heskett]

I have been able to export the x session to this box forever, and it has 
worked nominally well, till now.

But this machine now has debian 7.8 (wheezy) on it, and the lathe just 
got its drive reformatted and has the binary-hybrid.iso installed on it.

Tonight, I am "ssh -Y shop" from this machine, and when I try to run 
linuxcnc -l from the logged in terminal, it now fails, as does a login 
to lathe.coyote.den by the same syntax.

gene@shop:~$ linuxcnc -l
LINUXCNC - 2.6.7
Machine configuration directory 
is '/home/gene/linuxcnc/configs/my-mill-atom-3'
Machine configuration file is 'my-mill-atom-3.ini'
Starting LinuxCNC...
Traceback (most recent call last):
  File "/usr/bin/hal_manualtoolchange", line 62, in 
app = Tkinter.Tk(className="AxisToolChanger")
  File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 1646, in __init__
self.tk = _tkinter.create(screenName, baseName, className, 
interactive, wantobjects, useTk, sync, use)
_tkinter.TclError: unknown color name "BACKGROUND"
Traceback (most recent call last):
  File "/usr/bin/axis", line 121, in 
root_window = Tkinter.Tk(className="Axis")
  File "/usr/bin/axis", line 44, in __init__
OldTk.__init__(self, *args, **kw)
  File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 1646, in __init__
self.tk = _tkinter.create(screenName, baseName, className, 
interactive, wantobjects, useTk, sync, use)
_tkinter.TclError: unknown color name "BACKGROUND"
Shutting down and cleaning up LinuxCNC...
Traceback (most recent call last):
  File "/usr/bin/axis-remote", line 78, in 
t = Tkinter.Tk(); t.wm_withdraw()
  File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 1646, in __init__
self.tk = _tkinter.create(screenName, baseName, className, 
interactive, wantobjects, useTk, sync, use)
_tkinter.TclError: unknown color name "BACKGROUND"
Application initialization failed: unknown color name "BACKGROUND"
LinuxCNC terminated with an error.  You can find more information in the 
log:
/home/gene/linuxcnc_debug.txt
and
/home/gene/linuxcnc_print.txt
as well as in the output of the shell command 'dmesg' and in the terminal

dmesg is silent as to cause

xhost output on shop
gene@shop:~$ xhost
access control disabled, clients can connect from any host
INET:coyote.coyote.den
INET:lathe.coyote.den
INET:shop.coyote.den
SI:localuser:gene

Dittos for here
gene@coyote:~$ xhost
access control disabled, clients can connect from any host
INET:coyote.coyote.den
INET:lathe.coyote.den
INET:shop.coyote.den
SI:localuser:gene

and 'lathe' is another copy.
The .ssh/known_keys have been updated too.

Unknown color name BACKGROUND?

Probaly something forehead slappable simple, so the first thing I checked 
was xhost.

Where do I look & check next?

Thanks.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users