Re: concept to execute small jobs on a remote machine
From: Michael W. Cocke (cocke_at_catherders.com)
Date: 02/18/04
- Next message: Rick Jones: "Re: max udp datagram size"
- Previous message: Andy Fraser: "Re: Linux has a long way to go before it becomes the major OS"
- In reply to: Ekkard Gerlach: "concept to execute small jobs on a remote machine"
- Next in thread: Michael W. Cocke: "Re: concept to execute small jobs on a remote machine"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 17 Feb 2004 18:55:36 -0500
On Tue, 17 Feb 2004 14:34:21 +0000 (UTC), Ekkard Gerlach
<egerlach@aiai.de> wrote:
>In a SOHO-area (small office, 1 server, about 4 linux clients)
>I need a concept to execute small jobs on remote machines,
>mostly the server. The jobs are like purging printer
>queues (CUPS, LPD), changing some configuration file of a
>commercial program, manipulating some text in mails of user
>accounts of the mail server, etc. The jobs have to be
>executed automatically, there's no manual login possible.
>
>Can you propose some concepts? Some pointers to search
>with google may be enough.
>
>My concept so far:
>==================
>This is my concept realised successfully two times so far:
>Install user "dummy" and group "dummy" on any server and
>any client. The normal users may ssh to user dummy of
>other PC's (ssh-keys are exchanged, no passphrase) and
>user dummy is allowed to execute some skripts defined in
>/etc/sudoers. The ssh connection just executes these
>jobs. Thats all. It's working! But are there some better
>concepts?
>
>thx
>Ekkard
Fair warning - this idea is fairly half-baked. I came up with it some
years back when I had to queue jobs on an unattended remote OS/2
server that I couldn't just use telnet on for some unremembered
reason. It's fairly straightforward and just needs some shell
scripting...
Write a script that waits 60 seconds (or whatever interval works for
you) then checks for the existance of a file. If the file exists,
read a line from it and execute the contents of the line. Just write
whatever command you need executed into the file.
This has advantages and disadvantages over the ssh approach you
mention... for starters, you don't need ssh - you can do it with
regular telnet, or even bury it in a CGI on a web server, if that
suits your circumstances... Just set your permissions tightly and
bury the file. On the other hand, it's kludgy and there's no chance
for feedback - it's only good for batch commands.
Mike-
Mornings: Evolution in action. Only the grumpy will survive.
-----------------------------------------------------
Please note - Due to the intense volume of spam, we have
installed site-wide spam filters at catherders.com. If
email from you bounces, try non-HTML, non-encoded,
non-attachments.
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
- Next message: Rick Jones: "Re: max udp datagram size"
- Previous message: Andy Fraser: "Re: Linux has a long way to go before it becomes the major OS"
- In reply to: Ekkard Gerlach: "concept to execute small jobs on a remote machine"
- Next in thread: Michael W. Cocke: "Re: concept to execute small jobs on a remote machine"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]