- Bdi4emc-help - lists.ourproject.org

Re: consequences of new OpenSSH...
by Kent A. Reed 27 Dec '05

27 Dec '05

Paul wrote: > Message: 2 Date: Sat, 24 Dec 2005 12:57:52 +0000 From: Paul > <bdi-emc(a)ntlworld.com> Subject: [Bdi4emc-help] Re: consequences of new > OpenSSH... To: "Help and advice for BDI-4 users." > <bdi4emc-help(a)lists.ourproject.org> Message-ID: > <200512241257.52408.bdi-emc(a)ntlworld.com> Content-Type: text/plain; > charset="iso-8859-1" Hi Gene & Kent The basic BDI-4 installation > already uses a post-install script to tweak > >certain settings and to correctly configure a couple of essential packages. >To add another section to the script would be possible, but as has been >pointed out, an upgrade to ssh could overwrite the X11Forwarding option and >then we would have complaints of a broken ssh package. My personal preference >is to keep auto-scripted tweaks to an absolute minimum and document >additional tweaks rather than forcing them on to everyone. > > >Regards, Paul. > > > This is my personal preference too, Paul. I was just getting overly enthusiastic in my reply. What one really wants are scripts that test the ability to communicate between two or more hosts and makes intelligent suggestions if the tests fail. Although I can imagine what the scripts would look like because similar things have been done with CORBA ORBs I've used, I know that maintaining the scripts becomes yet another maintenance problem. BDI Wiki pages will do fine for documenting additional tweaks as they are discovered, and I'm happy to do my share in creating them. Regards, Kent

1 0

Re: Install Help please
by Kent A. Reed 27 Dec '05

27 Dec '05

Arthur wrote: >Message: 1 >Date: Fri, 23 Dec 2005 23:36:45 +0000 >From: Arthur Butler <arthurbutler(a)otters.ndo.co.uk> >Subject: [Bdi4emc-help] Install Help please >To: bdi4emc-help(a)lists.ourproject.org >Message-ID: <43AC8A0D.1050608(a)otters.ndo.co.uk> >Content-Type: text/plain; charset=us-ascii; format=flowed > >Hi. > >Thank you for working on these programs. Unfortunately I'm having >trouble installing the BDI 4.30 version. I'm not a complete newby, have >used Redhat, and now Debian on other PC's. I've checked the md5sum of >the iso downloaded, and of the CD itself. I've turned "detect virus by >trend" off in the bios, and am using LBA mode for the 40G hard drive, >and reburnt the CDRW to a CDR just incase, all as suggested in the FAQ. >The install starts fine, all packages are then installed, but when the >screen saying "post install config" or something pops up it crashes. The >PC I'm trying to install on is a 500MHz AMD K6II processor, with 128MB >RAM. I think there was a problem with BDI on K6 processors, but think >newer versions of BDI are OK. I'm trying to use LVM too, with my own >partitioning scheme, based on that I've used on my desktop PC. I'm ><<<stuff deleted>>> >I'm wondering about trying either a minimal install with lvm, or running >the upgrade script on the partially working version. > > > I doubt that the AMD K6 is the problem, although there is always plenty of room for error with the variety of motherboards and BIOSes out there. Over the last 4 years, I have installed various versions of Red Hat and Fedora Core Linux on a no-name 600 MHz AMD K6 machine with absolutely no difficulty. When I get a chance later this week, I'll try installing BDI-4.30 to it just to be sure. Note that 128MB of RAM isn't very much memory. If you're unlucky the system will start paging to disk with an attendant hit in performance. I have no experience whatever with LVM (although I've used the equivalent functionality on Silicon Graphics' commercial version of Unix known as IRIX) but when I search Google on combinations like "lvm install debian" and "lvm problem debian" I get plenty of hits. Since the BDI is based on the Debian kernel and packaging, I'd try to reduce the problem to its simplest form by first doing a trial install of the latest stable version of the Debian distribution to make sure I could get it running over LVM2 and only then try installing the BDI with LVM2. I suppose it is possible that the real-time extensions added to support EMC could interfere with LVM, but Paul's already pointed out a more likely possibility. It's just my 2-cents worth, but I think EMC should run on its own dedicated host, in which case I'm not sure LVM buys you much anyway. Regards, Kent

1 0

Re: Emc-users digest, Vol 1 #933 - 4 msgs
by Kent A. Reed 24 Dec '05

24 Dec '05

On Saturday, Gene wrote to the emc-users list >Message: 1 >Date: Sat, 17 Dec 2005 12:36:08 -0500 >From: Gene Heskett <gene.heskett(a)verizon.net> >Subject: Re: [Emc-users] fresh install of emc2 question >To: emc-users(a)lists.sourceforge.net >Organization: None, usuallly detectable by casual observers >Reply-To: emc-users(a)lists.sourceforge.net > ><<<blah blah blah>>> > > >That was in that boxes /etc/ssh/sshd_config, where X11Forwarding was >set to no, changed it to yes, restarted the sshd daemon and up pops >the gif & tkemc. Great! Maybe bdi-4.31 can have that fixed? hint, >hint :-) > > > Gene and Paul: I think the remedy here is to create a post-installation script that checks for the proper setting. My experience with distributing customized versions of open-source software is that maintenance become a big headache as new versions of software components get downloaded and installed asynchronously by users. (Given the frequency of security-related fixes, this happens a lot even on 'stable' systems.) To use this specific case as an example, I'd rather be able to overwrite an existing version of openssh with a new version---including possibly new configuration files that accomodate new variables---and then change the appropriate variables using the script, than have to remember to save off a customized configuration file, install the new version openssh, and then roll back the old configuration file with my fingers crossed that it still works with the new version of openssh. >And its running, but obviously with the motor power turned off since I >can't see it from here. :( Too bad I can't set my movie camera up and >run a firewire cable into here, about 110 feet & watch it in kino says >me, thinking out loud. But I haven't checked the max distance for a >firewire 400 cable. And I've never seen an extension cable for >firewire, has anyone else? > > > Cool idea. The IEEE 1394 (aka firewire) standard says 4.5m between nodes is the maximum. I've heard of active extension cables that work with powered hubs but I've never seen one. The descriptions make it sound like you still have to string together 15-foot units. You'd probably be better off streaming video through ethernet---10baseT has a 100m limit---or using an IEEE 1294-to-fiber transceiver arrangement, which can work over very long distances but starts sounding like real money ($600/pair of transceivers plus the price of the optical fiber). Still, a cool idea. Regards, Kent

2 1

Re: Bdi4emc-help Digest, Vol 1, Issue 7
by bdi4emc-help＠lists.ourproject.org 18 Dec '05

18 Dec '05

bdi4emc-help-request(a)lists.ourproject.org [aka Gene!] wrote: >Date: Fri, 16 Dec 2005 11:36:17 -0500 >From: bdi4emc-help(a)lists.ourproject.org >Subject: Re: [Bdi4emc-help] Install probs, bdi-4.30 >To: bdi4emc-help(a)lists.ourproject.org >Message-ID: <200512161136.17511.gene.heskett(a)verizon.net> >Content-Type: text/plain; charset=us-ascii > > >... >This makes it very hard if not impossible to see who is talking to >whom. Can this be fixed? > > > Let's hope so! > The trouble with e2fsck is that it apparently has to be compiled with > or without the 'extended attributes' because the RH version of 1.35 > cannot check a debian file system, and vice versa, but they both say > they are the same version. Yeah, pigs fly too. I already ran into that > earlier when I was trying to get FC4 to run on that box. Then I found > out FC4 doesn't run on anything, the installer is busted. But I wasted > a week trying :( Now I have the images for an unofficial FC4.2 thats > suppose to have al the fixes and about 2GB of updates already > incorporated in it. But I gave them to a friend so I need to burn > another set & see if I can make it run on this box someday. When I > find that round tuit probably. :) It looks like I've finally run into someone who has tried more Linux distributions than I have :-) Since the BDI is my first Debian-based install, I'm learning from you what works and what doesn't. A long time ago, I used Tom's rtbt Linux-on-a-diskette (http://www.toms.net/rb/) to deal with a balky system. More recently, I had a student-employee at work who did some cool things with Knoppix Linux running from a CDROM (http://www.knopper.net/knoppix/index-en.html) I don't know if it works against Debian file systems. I've also been told that the Gentoo LiveCD and its cousin the SystemRescueCD (http://www.sysresccd.org/) are good tools for fixing broken systems, but I've never had the need to try them (knock on wood!). Frankly, I got cold feet with Fedora Core as it jumped from FC1 to FC2 to FC3 because it seemed to be spinning out of control (I haven't even bothered to read the release notes for FC4). Instead, I paid for Red Hat Enterprise Linux to run my key servers at work and kept copies of previous versions of RH around for play. I'm slowly throwing them out as the security patches stop coming. Now that I've entered my seventh decade of life and my fifth decade of computing, I seem to be less willing to fool around with different distributions just because they are there. I'd rather play with interesting new applications and middleware. That's why I'm thrilled that Paul put together the BDI. I see in other messages that you finally gave up and reinstalled. Oy weh! That's usually the remedy I recommend for intransigent MS Windows problems. The stories I could tell you..., but no, I forget myself. It's the old farts who are compelled to bore everyone with "there I was..." stories and I can't be an old fart, can I? Good luck. Regards, Kent

1 1

Re: [Bdi4emc-help] Install probs, bdi-4.30
by bdi4emc-help＠lists.ourproject.org 16 Dec '05

16 Dec '05

"...text mode...[s]o the only thing to do is tap the reset button...graphical install...freezes the box." When it rains, it pours!. There's a legion of Linux haters out there who gave up when they ran into seemingly insurmountable problems like this. I'm not going to be an apologist for the Linux folks, but I will say I've had my share of balky installs with all sorts of O/Ses, not just Linux. I had no difficulty installing BDI-4.30 on two very different boxes, one an HP8776c running a 1GHz AMD T-bird Athlon CPU, one a Dell XPS T450 running a 450 MHz Intel PIII, so I don't have any learning experience to drawn from for advice. As I said in my first email, for me it "doesn't get any better than this." I'll be interested to hear what you decide is the source of your difficulties and what you did about it. Good luck, Gene. Regards, Kent

1 2

Install probs, bdi-4.30
by bdi4emc-help＠lists.ourproject.org 15 Dec '05

15 Dec '05

Hi all; 2 things, first I put a 40 watt light bulb in the box for heat, along with a thermostat that shuts it down at about 60F. Then I just made 3 passes at re-installing bdi-4.30, without formatting the /usr partition. First and second times I did it in text mode, and found what I'd consider a major bug in that procedure. In text mode, after everything has been installed, it pops up the x config screen to see howto configure x. Unforch, by then, the keyboard mapping is foo'd, bar'd & maybe even bazzed. Keystrokes are shown on screen, exactly as they come out of the cable. No mouse of course. So the only thing to do is tap the reset button Figuring it had re-installed grub by then, I removed the cd before I hit the reset button. It rebooted, started a very low res X screen and brought up a login requestor after advising me that root logins were disallowed. Which is fine I guess, but if root logins are disallowed, why hadn't it asked me for a regular user and his passwd yet? Obviously, since it hadn't yet set that up, there was no valid user, and with root disabled, it was 3 finger time & re-install the 2nd time. Same scenario at the end, no keyboard mapping when it asked me for the screen setup. Just semi garbled, 3 or 4 chars per keypress mess onscreen. Reset time again, only this time let it do a graphical install, which goes all the way till nearly the end where its installing the kde windows manager, which gets to 50% and freezes the box. I'll try it again tomorrow after memtest86 has run for a bit. But the text installer should setup a username & passwd before it gets totally lost. That way, if it upchucks again, I could simply login, su -, and get to fixing the problems. Sensibly it seems like this should be the next step after configuring the network interface, but its not. This motherboard, a Mach Speed, has a minimum cpu speed I guess, I cannot slow it down in the bios enough to make it say the cpu is a 1400. So it logs in on the post screen as a 1600 mhz athlon & I have NDI how much faster it might be able to run. On the old mobo before it upchucked, it did run at 1400 ok. And its running about 80F cooler on this board than it ever ran when it was on the old board. -- Cheers, Gene People having trouble with vz bouncing email to me should use this address: <gene.heskett(a)verizononline.net> which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

1 1

Mounting pen drives
by bdi4emc-help＠lists.ourproject.org 14 Dec '05

14 Dec '05

On Monday 12 December 2005 03:34, bdi4emc-help(a)lists.ourproject.org wrote: > Hi group, > I'm going to be using BDI-4 pretty soon as my mill is completed, with > Jon Elson's UPC. I have 4.30 running on the computer installed in the > electronics cabinet right now. The computer is somewhat buried in the > cabinet so I was planning on using a USB flash drive to transfer files. > I tried doing this today and I wasn't able to figure out how to mount > it. Is there a way to get it to auto-mount when I plug it in? > Thanks, > Michael Hi Michael Note: I do not have any USB pen drives to test this with, so much of the following is drawn from google searches and memories of setting up a USB ZIP drive. Add the following two lines to /etc/modules usbcore usb-storage (run "sudo modprobe usb-storage" to save having to reboot) With the modules loaded, a mount point needs to be created. The prefered point is in /media, so run "sudo mkdir /media/pen" to create it. An entry in /etc/fstab is also required if you want to avoid cryptic command lines to mount the pen drive. This would look something like: /dev/sda1 /media/pen vfat user,noauto 0 0 To use the pen drive, you should now be able to plug it in to the USB port and mount it with: mount /media/pen And before unplugging it, unmount with: umount /media/pen Once you have confirmed the device can be mounted, accessed, and unmounted, you can create a desktop icon to perform the mount/unmount operations. Right click on an empty spot on the desktop and navigate to 'Create New'->'Device'->'MO Device'. Fill in the boxes and you should be set to go. Setting the system up to support hotplugging is not as straight forward and may well interfere with the running of EMC should you insert/remove a pen drive. Regards, Paul.

1 2

Re: consequences of new OpenSSH...
by bdi4emc-help＠lists.ourproject.org 13 Dec '05

13 Dec '05

Paul: wrote >Distilled the info down to it's minimum and confirmed it works on a fresh >BDI-4 install. I did notice that the setting of DISPLAY was not needed as the >-X flag should automatically set the variable. > > Just to make sure we're on the same wavelength, I spoke of two different approaches: (1) forwarding X11 communication through ssh, in which case one does *not* need to set up *either* the local xhost list (which will be ignored because the X11 channel isn't being used) or the remote DISPLAY variable (which is set automagically by the remote sshd during the logon handshake to a pseudodisplay number; on my BDI-4.30 machine it's DISPLAY=localhost:10.0; your mileage may vary). (2) normal X11 communication via the X11 channel, in which case one needs to set up *both* the local xhost list (otherwise the remote X11 client will be ignored) and the remote DISPLAY variable (so the X11 client knows who to talk to). If you're invoking ssh -X or ssh -Y you're using the first approach, which is preferred for security reasons. I spoke of the second approach to help those who couldn't get X11Forwarding to work for their EMC installation because of the untrusted X11 client problem. Regards, Kent

1 0

Re: Wiki layout, g-codes, usb sticks
by bdi4emc-help＠lists.ourproject.org 13 Dec '05

13 Dec '05

Gentle persons: (Paul) Any organizational principle is better than none. However, call me cynical if you like (everybody at work does!) but I figure if this site is successful it will get disorganized over time just because lots of people will feel compelled to contribute and, like it or not, they'll add to it wherever they see fit because the whole purpose of theWiki approach is to let them do exactly that. I don't know the ins and outs of the ISO/DIN 66025. The US ANSI doesn't admit to having an English language version available. The DIN itself (http://www.din.de/) offers English language versions of DIN 66025-1 (1982) and DIN 66025-2 (1988) for 74.40 EUR, about $88, each. Since they're more than a decade old, I'd guess they are delivered in paper-copy form (or scanned pdf if you're lucky). MachineMate has a list of codes that they call "NC Programming as per ISO (DIN 66025) and RS274" (http://www.machinemate.com/StandardCodes.htm) but I have no idea how carefully they prepared it. I'm not sure what you mean by transcribing Tom Kramer's paper. It is available in pdf and html format. What needs to be transcribed? (By the way, you might want to email Tom directly about both his paper and DIN 66025. You can search his email address on the NIST site). (Michael) I've never used a memory stick with a Linux box but a quick Google search suggests lots of people struggle to get them working. Have you looked at http://www.debianhelp.org? I found this article "Using USB Flash Drives in Debian" (http://www.debianhelp.org/Article3529.html) which looks useful. I also found a follow-up thread (http://www.debianhelp.org/module-pnForum-viewtopic-topic-10425.html) As an aside, I'm happy to see another user of Jon Elson's products. I have just received a USC board from him and have only had time to test that it can communicate with my PC. Regards, Kent

1 2

consequences of newer OpenSSH on remote X11 displays
by bdi4emc-help＠lists.ourproject.org 12 Dec '05

12 Dec '05

Gentle persons: This note applies if you are running BDI-4.30 (see footnote) and want to run EMC or other X11 applications through a secure ssh channel from another computer. For example, I have my BDI-host in a basement utility room and sometimes want to run X11 applications (including EMC in simulation mode) on it from a Windows host in my office or a Linux (sometimes Red Hat, sometimes Fedora Core) host in my rec room. These hosts are interconnected via wired and wireless ethernet. The Debian distribution that is part of BDI-4.30 includes version 3.8 of OpenSSH compared to version 3.6 on my other Linux hosts (but version 4.2 in my up-to-date Cygwin installation on my Windows host). With this newer version, the OpenSSH folks changed the configuration so that X11Fowarding is disabled by default (for security reasons). Thus, connecting to my BDI-host from another box using the shell command "ssh -X bdi_ip_or_hostname" and then invoking an X11 application on the BDI-box, e.g., xeyes, will result in an error message instead of causing a new X window (with the xeyes "eyes" for example) to open on my local host as I have come to expect. A remedy is to edit the /etc/ssh/sshd_config file on the BDI host to enable X11Forwarding (change the line "X11Forwarding no" to "X11Forwarding yes") and then restart sshd (for example, from the console, find the sshd process identification pid using ps -ax and send it a hangup signal, "kill -HUP pid") to force it to reread its configuration file. Now simple X11 applications like xeyes and xclock will open new windows fresh as paint. However, newer versions of OpenSSH also differentiate between untrusted and trusted X11 clients and consider all clients to be untrustworthy by default. It turns out that both EMC and EMC2 try to read information from the X11 server in a manner which isn't permitted of an untrusted X11 client. Hence, with my CygwinX installation, I have to invoke ssh with the -Y option rather than the -X option to create a secure channel that will work with EMC. (This -Y option doesn't exist in older versions of OpenSSH.) I'm still figuring out how to force behavior equivalent to -Y using configuration or environment settings. (From the amount of whinging I've seen on various mail lists and boards, this isn't a problem only with EMC, so you may well find you have other X11 applications that fail to run properly as untrusted clients.) Note that one can avoid all this by running X11 using the insecure X11 communications protocol just as MIT designed it (strongly not recommended unless all the hosts involved are behind a *really* good firewall; sooner or later the bad guys find every crack!). To set this up, one does things the old-fashioned way 1. on the local host, declare the remote host to be trusted by the local X11 server: "xhost +bdi_ip_address/bdi_hostname" 2. ssh to the remote host 3. on the remote host, set the DISPLAY environment variable to point to the local host's X11 server. The syntax for this varies with the shell in use. In the bash shell, one can invoke "export DISPLAY=the_remote_ip_or_hostname:0.0". Note that it is commonplace to assume that the display number will be 0.0, and it usually will be, but it should always be confirmed for the X11 server in question. Steps 1 and 3 are totally unnecessary when X11 forwarding via ssh is working. Regards, Kent footnote: this note may apply to previous versions of the BDI but I don't have them and can't say.

1 4