Re: [Emc-users] bigger problem

2016-09-21 Thread 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


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

2015-05-09 Thread Mark Wendt
On Fri, May 8, 2015 at 7:06 PM, Gene Heskett ghesk...@wdtv.com 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

2015-05-09 Thread Gene Heskett


On Saturday 09 May 2015 07:58:46 Mark Wendt wrote:
 On Fri, May 8, 2015 at 7:06 PM, Gene Heskett ghesk...@wdtv.com 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 in updating my .ini  .hal files to get rid of a slew of 
the using defaults messages I see on the 

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

2015-05-08 Thread Mark Wendt
On Thu, May 7, 2015 at 8:08 PM, Gene Heskett ghesk...@wdtv.com 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 machine? -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?



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

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

2015-05-08 Thread Mark Wendt
On Thu, May 7, 2015 at 10:20 PM, Jon Elson el...@pico-systems.com 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 line-numberG, 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

2015-05-08 Thread 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 http://geneslinuxbox.net:6309/gene

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

2015-05-08 Thread Jon Elson
On 05/08/2015 04:19 AM, Mark Wendt wrote:
 On Thu, May 7, 2015 at 8:08 PM, Gene Heskett ghesk...@wdtv.com 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

2015-05-08 Thread Mark Wendt
On Fri, May 8, 2015 at 11:48 AM, Jon Elson el...@pico-systems.com wrote:

 On 05/08/2015 07:15 AM, Mark Wendt wrote:
  On Fri, May 8, 2015 at 7:49 AM, Gene Heskett ghesk...@wdtv.com 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

2015-05-08 Thread Jon Elson
On 05/08/2015 07:15 AM, Mark Wendt wrote:
 On Fri, May 8, 2015 at 7:49 AM, Gene Heskett ghesk...@wdtv.com 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

2015-05-08 Thread 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 ghesk...@wdtv.com
  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 http://geneslinuxbox.net:6309/gene

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

2015-05-08 Thread Mark Wendt
On Fri, May 8, 2015 at 7:58 AM, Gene Heskett ghesk...@wdtv.com 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 line-numberG, 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

2015-05-08 Thread Gene Heskett
On Friday 08 May 2015 08:15:57 Mark Wendt wrote:
 On Fri, May 8, 2015 at 7:49 AM, Gene Heskett ghesk...@wdtv.com 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 looked normal.  Sigh...

 I think that has something to do with a bad exit code from KDE/Gnome
 etc. I've seen that message before.  It's no big deal.  Some places
 have said that if you use shutdown from a terminal rather than either
 an init 6 

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

2015-05-08 Thread Gene Heskett
On Friday 08 May 2015 05:22:58 Mark Wendt wrote:
 On Thu, May 7, 2015 at 10:20 PM, Jon Elson el...@pico-systems.com 
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 line-numberG, 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 http://geneslinuxbox.net:6309/gene

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

2015-05-08 Thread Gene Heskett


On Friday 08 May 2015 05:19:49 Mark Wendt wrote:
 On Thu, May 7, 2015 at 8:08 PM, Gene Heskett ghesk...@wdtv.com 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 machine?
   -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 module
  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 module
  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 module
  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 

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

2015-05-08 Thread Mark Wendt
On Fri, May 8, 2015 at 7:49 AM, Gene Heskett ghesk...@wdtv.com 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
 drwxr-xr-x   2 root   root  4096 Apr 19  2014 proc
 drwx--   8 root   root  4096 May  7 02:29 root
 drwxr-xr-x   2 root   root  4096 May  6 13:08 

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

2015-05-07 Thread Mark Wendt
On Thu, May 7, 2015 at 3:20 AM, Gene Heskett ghesk...@wdtv.com 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 module
 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 module
 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 module
 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


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

2015-05-07 Thread Mark Wendt
On Thu, May 7, 2015 at 1:45 PM, Gene Heskett ghesk...@wdtv.com 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 lathe_machine?
 
 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,
 

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

2015-05-07 Thread 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 paste mouse line here
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 http://geneslinuxbox.net:6309/gene

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

2015-05-07 Thread Mark Wendt
On Thu, May 7, 2015 at 2:01 PM, Gene Heskett ghesk...@wdtv.com 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 paste mouse line here
 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 machine? -vvv

the -4 tells ssh to skip the IPv6 attempt and go right to an IPv4
connection.

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

2015-05-07 Thread 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 lathe_machine?

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: 

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

2015-05-07 Thread Gene Heskett
On Thursday 07 May 2015 15:54:49 Mark Wendt wrote:
 On Thu, May 7, 2015 at 2:01 PM, Gene Heskett ghesk...@wdtv.com 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 paste mouse line here
  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 machine? -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

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 

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

2015-05-07 Thread Gene Heskett


On Thursday 07 May 2015 05:07:08 Mark Wendt wrote:
 On Thu, May 7, 2015 at 3:20 AM, Gene Heskett ghesk...@wdtv.com 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 module
  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 module
  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 module
  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 http://geneslinuxbox.net:6309/gene

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

2015-05-07 Thread 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 ghesk...@wdtv.com 
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 module
   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 module
   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 module
   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 http://geneslinuxbox.net:6309/gene

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

2015-05-07 Thread Mark Wendt
On Thu, May 7, 2015 at 8:44 AM, Gene Heskett ghesk...@wdtv.com 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 machine.  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

2015-05-07 Thread 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

2015-05-07 Thread Gene Heskett
On Thursday 07 May 2015 09:11:44 Mark Wendt wrote:
 On Thu, May 7, 2015 at 8:44 AM, Gene Heskett ghesk...@wdtv.com 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 machine.  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 http://geneslinuxbox.net:6309/gene

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

2015-05-07 Thread Gene Heskett
On Thursday 07 May 2015 09:17:37 Mark Wendt wrote:
 On Thu, May 7, 2015 at 9:10 AM, Gene Heskett ghesk...@wdtv.com 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 ghesk...@wdtv.com
 
  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.

 snippage

   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 module
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 http://geneslinuxbox.net:6309/gene

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

2015-05-07 Thread Mark Wendt
On Thu, May 7, 2015 at 9:10 AM, Gene Heskett ghesk...@wdtv.com 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 ghesk...@wdtv.com
 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.


snippage


 
  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

2015-05-07 Thread Mark Wendt
On Thu, May 7, 2015 at 10:02 AM, Gene Heskett ghesk...@wdtv.com 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 module
 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 lathe_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

2015-05-07 Thread 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 paste mouse line here
   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

2015-05-07 Thread Mark Wendt
On Thu, May 7, 2015 at 9:55 AM, Gene Heskett ghesk...@wdtv.com 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 machine.  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

2015-05-07 Thread Gene Heskett


On Thursday 07 May 2015 10:31:18 Mark Wendt wrote:
 On Thu, May 7, 2015 at 9:55 AM, Gene Heskett ghesk...@wdtv.com 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 machine.  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 http://geneslinuxbox.net:6309/gene

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