Re: [Emc-users] bigger problem
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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