Sending commands between Linux and Windows

I run all my X10 hardware on my PC, and alot of other applications on my dedicated Linux server (Fedora Core 3).

What I want to be able to do is have scripts run commands on the other machine in response to events. For instance, if my Apache server goes down, the Linux server tells the PC to ring an X10 chime and turn on a light. Or if I get frontdoor motion, the PC tells the Linux server to log the event in a secured web directory.

The problem is that, as obvious as the issue seems to be, I can find no solutions. I'm thinking something like rsh would do the trick, but I can't find any decent and free rsh stuff for Windows/XP. I found some choppy source codes for a Windows port of rshd that I couldn't compile, but I couldn't find any ready solution.

Does anybody have good solutions for this? And does anybody have a good rsh client and server for a Windows XP machine?

Thanks Curtis

Reply to
Renoir
Loading thread data ...

Well, if you don't mind learning a new scripting language, Tcl/Tk would fit the bill quite nicely. Scripts (for the most part) can be written so that they are portable across platforms. Communication between (for example) a script running under Linux and another running under Windows could be done with sockets. I do this between Windows systems all the time and, up until a couple of weeks ago when I "retired" an old Linux box, I had scripts running there which communicated with the Windows scripts. Check for an article I posted the beginning of April called "Scripting 101" for more information.

Dave

Reply to
Dave Harper

You could try using MH on Linux and Windows. One is the server the other a proxy. I've not tried it but I'm pretty sure it can be done. I'm afarid my thinking wouldn't be much help to you otherwise as I'm used to thinking in terms of Unix with it's daemons. Not well suite for Windows without extra tools such as Cgywin and a very different way of thinking.

Reply to
Neil Cherry

Don't use rsh, use ssh. I like putty.

sdb

Reply to
sylvan butler

Get cygwin for the windows box. And don't use rsh, use ssh instead as it's much more secure. No sense opening up your boxes to abuse when it's simple to avoid it from the get-go.

formatting link

-Bill Kearney

Reply to
Bill Kearney

Thanks, I'll try that. I might eventually try Dave's TCL method but that's a bigger learning curve.

Well, all this is my internal LAN: my Linux server is 10 feet from my PC, so security is not an issue. If cygwin has rexec and rexecd, that'd probably be the sweetest way to go.

BTW I accidentally reposted my question, sorry bout that guys.

Reply to
Renoir

The r utilities are notoriously insecure. If/when you ever have anything from the outside world connected (wifi, router, etc) you're asking for trouble. It's easy enough to use ssh so why set yourself up for the eventual security risks?

Reply to
Bill Kearney

If your X10 interface is a CM11A, consider running it on the Linux server instead of the Win XP machine and using Heyu

formatting link
to handle the X10 signals and run your scripts for you.

Regards, Charles Sullivan

Reply to
Charles Sullivan

It's not, I run the original Smarthome USB interface.

HOWEVER I have found a supercool way to send commands back and forth between a Linux server and a PC!

Web interfaces. It's easy enough to code a shellscript with a web frontend and run it in a secure directory. Use .htaccess to make it accept connections only from internal LAN addresses. I suppose you could even run a whole seperate web server process for that to make it even more secure, and run it on a random high port. If you wanted even more, you could run a whole seperate NIC interface dedicated to stuff like this.

On the PC side, check out this:

formatting link
I just copied the syntax of the URL to run command lines, made a wget script in Linux to authenticate against it, and boom. Could use Microsoft's tool from their developer's kit to run this as a system service easily enough.

Reply to
Renoir

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.