LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Programming (http://www.linuxquestions.org/questions/programming-9/)
-   -   Shell script remote notifications (http://www.linuxquestions.org/questions/programming-9/shell-script-remote-notifications-4175437615/)

a2326 11-17-2012 05:30 PM

Shell script remote notifications
 
Hello forum,
I'm looking for a method to send fast and reliable notifications to a remote server within a trusted LAN via shell script, but I haven't found any way to use UDP with shell script commands. Is that possible? If not, I could only use rsh and then execute a remote command that sends a signal to some process or does anyone know a better option? Thank you.

Some further questions:
Which privileges are appropriate for the user who executes the rsh command? The rsh is executed from within a shell script, that several users are allowed to execute. The target of the rsh connection is always the same server.

Hko 11-18-2012 05:43 AM

Bash has a feature that allows you to:
Code:

echo "this" > /dev/tcp
REPLY=$(cat /dev/udp)

Unfortunately some distributions seem to have chosen to disable this at compile time. So you cannot rely on it for your script to run on every system.

Another option would be to use "netcat" (a.k.a. "nc").
See http://www.binarytides.com/netcat-tu...for-beginners/

a2326 11-18-2012 08:22 AM

That sounds interesting, but it seems that this doesn't allow multiple client connections at the same time.

My goal is to implement a notification service, that enables the client to notify the server immediately after he has sent him a file. When the server has received the notification, he shall read and process this file.

unSpawn 11-18-2012 10:02 AM

Quote:

Originally Posted by a2326 (Post 4831621)
I'm looking for a method to send (..) notifications to a (..) server

SNMP?

a2326 11-18-2012 10:45 AM

Might also be an option, but I don't know how to use it in conjunction with xinetd.

unSpawn 11-18-2012 12:16 PM

Then maybe it's time you post your requirements in full because first saying:
Quote:

Originally Posted by a2326 (Post 4831621)
(..) send (..) notifications to a remote server (..) via shell script

then adding:
Quote:

Originally Posted by a2326 (Post 4831975)
(..) allow multiple client connections at the same time.

and then saying:
Quote:

Originally Posted by a2326 (Post 4832057)
(..) use it in conjunction with xinetd.

shows me you haven't. Else it really doesn't make sense suggesting anything.


BTW this doesn't add up:
Quote:

Originally Posted by a2326 (Post 4831621)
(..) reliable notifications (..) use UDP

because the "U" in UDP may not officially stand for "unreliable" but UDP doesn't keep state and it doesn't guarantee delivery.

a2326 11-18-2012 01:01 PM

OK, this has been not very precise. Basically, I would like to have some simple service that allows me to send small notifications from multiple clients to a server. The notifications don't have to contain any significant data, because they shall be used as signals. All this should work in a small LAN with less than 10 hosts and it doesn't have to be scalable. However, I am quite unsure which option I should follow, because I can't evaluate the pros and cons very well, but maybe in a small network with just a few connections, TCP's "heaviness" doesn't become a real issue.

Hko 11-18-2012 01:24 PM

Quote:

Originally Posted by a2326 (Post 4831975)
My goal is to implement a notification service, that enables the client to notify the server immediately after he has sent him a file. When the server has received the notification, he shall read and process this file.

The Linux kernel has a mechanism called "inotify" to signal a process asynchronously when something specific happens on a specific part of the filesystem. Using that you would not need a networked mechanism, just a daemon on the server that runs some script, or sends a signal if a file is created in some specific directory. Debian and ubuntu ship a daemon called "inoticoming" to do just that. I bet other distro's have the same or something similar as well.

a2326 11-18-2012 01:51 PM

Thanks. Can "inotify" be used without making use of C or C++ and can incoming notifications be queued?

Hko 11-19-2012 03:14 AM

There are command line tools and daemons ("services") written in C/C++, that make it possible to use inotify in all kinds of programming languages and shell scripts.

For shell scripts, the easiest to use is probably "inotifywait" from the
"inotify-tools". I think (never tried it) it can not be used asynchronously, if you need that try: http://inotify.aiken.cz/?section=inc...=about&lang=en. Or of course "inoticoming" I already linked to in my previous post.

a2326 11-19-2012 05:13 AM

If I am right, inotify only reacts to local (in this case server-side) file changes, but it can't be used if the event arises from the client. I think that in this case I am better off with netcat, though I don't know how to find the right port that netcat should use. This script should only be used in a LAN, so I think I can use TCP here. Important is, that the server-side script listens constantly, so that any client can inform him at any time.
The client should then be able to execute one single command on the server, but for this task, rsh/ssh might be a better choice.

bradvan 11-19-2012 08:49 AM

As a236 suggested, I think using ssh will be your simplest option. Set up authentication from your "clients" to your server. Designate a directory for them to write to (and make sure the permissions are correct). Then when a client needs to inform the server, ssh server "echo '1' > /my/place/client" or you can scp a file to the location. Then on the server, have a daemon watching the directory an process accordingly when it finds a file.

unSpawn 11-19-2012 09:18 AM

Quote:

Originally Posted by a2326 (Post 4832473)
Important is, that the server-side script listens constantly, so that any client can inform him at any time.

Yep, sounds like SNMP alright.


Quote:

Originally Posted by a2326 (Post 4832473)
The client should then be able to execute one single command on the server, (..)

SNMP has been around for ages, is well-documented and by using traps allows for complete separation: no interactive service, no shell account or login necessary. Of course you're free to blithely re-invent the wheel regardless.

Hko 11-20-2012 03:44 AM

Quote:

Originally Posted by a2326 (Post 4832473)
If I am right, inotify only reacts to local (in this case server-side) file changes [..]

That is correct.

Quote:

Originally Posted by a2326 (Post 4832473)
[..] but it can't be used if the event arises from the client.

If the server receives a file from a client over the network over scp, sftp, ftp, nfs, or whatever, you can use inotify to trigger some action. It is local to the server indeed, but the change in the file or directory can very well arise from a client over the network. If I understood you right, that is what you were looking for.

a2326 11-20-2012 04:19 AM

I need notifications that are initiated by the client, independent of incoming files. SNMP seems to be a good option, but it's usage seems to be quite complicated.

Which is the best place for a server-side script that should be accessible from multiple clients to be located?


All times are GMT -5. The time now is 11:31 PM.