Re: Emc-users digest, Vol 1 #933 - 4 msgs
On Saturday, Gene wrote to the emc-users list
Message: 1 Date: Sat, 17 Dec 2005 12:36:08 -0500 From: Gene Heskett <[email protected]> Subject: Re: [Emc-users] fresh install of emc2 question To: [email protected] Organization: None, usuallly detectable by casual observers Reply-To: [email protected]
<<<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
Hi Gene & Kent On Thursday 22 December 2005 00:04, Kent A. Reed wrote:
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.
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.
participants (2)
-
Kent A. Reed -
Paul