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.

Bash has a feature that allows you to:
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/

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.

SNMP?

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

Then maybe it's time you post your requirements in full because first saying:
then adding:
and then saying:
shows me you haven't. Else it really doesn't make sense suggesting anything.


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

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.

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.

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

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.

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.

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.

Yep, sounds like SNMP alright.


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.

That is correct.

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.

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?

Look at ssh. It is simple, well documented, secure. Not sure what else you need. The client initiates an ssh to the server and either writes to a file or scp's over a file. The server has a daemon process watching and acts when the file shows up. Simple.

Heh, is that just an opinion or your practical experience actually having used SNMP? FWIW if you want "easy" then why not use a Netcat listener on the server and let the clients 'echo HELLO | nc server port' and be done with it? OTOH if you already use Xinetd (which you hinted at in one of your earlier posts) then a simple /etc/xinetd.d/ service could do as well. No need for added complexity in terms of libraries, daemons, user accounts and whatever else SSH would require.

Earler you said:
Maybe it's me, but as I get it, this doesn't add up. You've lost me there.
If it does add up, there must be some info missing about what it is exactly that you are trying to do. Or is it that you just want to create something that works over the network? (which can be a good argument imho)

To make it clear, I want to build a rcp/scp-based service, that sends files to remote users. To prevent constant polling, I need some kind of notification service for two possible situations:
1. The dispatcher sends a notification to the server after rcp/scp has returned with exit status 0. This notification starts a script on the server that immediately tries to forward the file to the receiver. If the receiver is not reachable, the server stops processing files and waits for the next external event.
2. The receiver wants to inform the server that he is now reachable and shall try again to forward the files he has stored.

I thought about using either netcat or rsh/ssh. Using rsh/ssh I could just call a remote method with the receiver name as argument.
SNMP would be a better solution, but with just a few weeks of shell programming experience maybe too complicated.

That's exactly why I already said "Then maybe it's time you post your requirements in full" in post #6...


Finally...


Isn't rcp / scp already exiting OK a sign the receiver already is reachable and available? In this situation you already got one channel of communication so why complicate things and add another? Doesn't make sense to me.


This really could be any sender / listener combo ranging from having a simple Xinetd listener and the client doing 'echo -en "READY\n"|nc sender_ip port;' to having snmptrapd listening and the client sending something like 'snmptrap -v2c sender_ip public '' .1.3.6.1.4.1.2789.2005.1 s "READY";'.


You might dislike Rational, RUP, Scrum, Agile, 6 Sigma, Lean or whatever but regardless of the methodology one choses to fsck things up with work with, regardless of the size and scope of a project and regardless if it being done instinctively or formally, there will be a stage at which a rough inventory of must haves / could haves / nice to haves gets converted to functional requirements which in turn get converted into technical requirements.
If it takes you a about a week to post "I want to build a rcp/scp-based service" then with all due respect SNMP being "maybe too complicated" is not the problem.

All messages are sent to a mediator server (that is supposed to be always reachable), that then sends them to the endpoint (that is supposed to be not always reachable), the final receiver. Basically the way most instant messengers work. I'm sorry for my incomplete description.

Thanks for the clarification. Kind of reminds me of the Blackberry "push" method. Since I notice you don't have any questions left I'll sign off and wish you good luck with your project.