Example for healtchcheck command?

[hihp]

wsdd is great work, thanks a lot!

One question: Like probably quite a lot of other people, I prefer to run software like this in a docker container, which actually works fine (I use this image: https://hub.docker.com/r/jonasped/wsdd ). I like to equip my docker containers with a healthcheck so that the docker ps list shows me if a container has stopped working.

"Has stopped working" would mean in this case that the daemon for whatever reason is still running, but has stopped to respond. (if the process has ended, the container would die and docker would restart it as I told it so.)

Testing that would therefore best be done by sending some sort of http request to the TCP listening port of wsdd. If a reply comes back within a certain timeframe, the container would be considered to still be operatin,g if not, then not.

My idea would be to use either a curl request (using the --fail option) or a wget request (using the --spider option) of some sort. But quite frankly, I am not even sure I got the start right - as a test, I wanted to try a telnet connection to wsdd, but it would refuse to even open a connection. Is 5357 not the correct port to use?

Apart from that: Any ideas what would be best as a simple http request to wsdd to seer whether it is still responding? I don't think any parsing of wsdd's replies are necessary.

[christgau]

My idea would be to use either a curl request (using the --fail option) or a wget request (using the --spider option) of some sort. But quite frankly, I am not even sure I got the start right - as a test, I wanted to try a telnet connection to wsdd, but it would refuse to even open a connection. Is 5357 not the correct port to use?

Port 5357 is correct, but you won't be able to connect to wsdd via localhost because wsdd never binds to localhost as that wouldn't make sense and there may be a technical reason for it too which I do not remember right now.

Apart from that: Any ideas what would be best as a simple http request to wsdd to seer whether it is still responding? I don't think any parsing of wsdd's replies are necessary.

A quick and dirty solution would be that one: curl -X POST http://$(host $(hostname) | head -n1 | rev | cut -f1 -d' ' | rev):5357/$(uuidgen --sha1 --namespace @dns --name $(hostname)).

Here is some rationale behind that "monster":

• You must issue a request with POST method type if you want to talk to the HTTP server
• As stated above, connecting to localhost won't work. Thus, we use the IP that is returned by the (local) DNS server for the local machine. I don't know whether this works in a docker container. It is also not reliable as it may return global IPv6 addresses to which wsdd never binds as well.
• The UUID stuff in the URL ensures you actually access the correct resource. Otherwise you will get an 404.

Using the above requests returns a 400 with "Invalid Content-Type". This actually originates from the wsdd logic so it may be used as indicator for a working wsdd instance. If you want to do more and want a 200 as return code (I think, curl would return an error otherwise with --fail), you need to post a full SOAP request, like this one (assumed to be stored in get_req.xml in the following):

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
  <soap:Header>
    <wsa:To>urn:uuid:ffffffff-ffff-ffff-ffff-ff0000000000</wsa:To>
    <wsa:Action>http://schemas.xmlsoap.org/ws/2004/09/transfer/Get</wsa:Action>
    <wsa:MessageID>urn:uuid:027bec45-c37c-466c-936c-68f648abe2bb</wsa:MessageID>
    <wsa:ReplyTo>
      <wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
    </wsa:ReplyTo>
    <wsa:From>
      <wsa:Address>urn:uuid:49e131df-351a-4ece-9a6f-6a862d31cffa</wsa:Address>
    </wsa:From>
  </soap:Header>
  <soap:Body></soap:Body>
</soap:Envelope>

Note that the wsa:To URN is actually invalid here, because it does not refer to the wsdd host, and wsdd apparently does not check it. This may change in future versions, so you would be safe if you pass the correct uuid here (see above for code to derive it). You also should use a new MessageID for each message you send. Finally, that one would be some kind of heartbeat request:

curl -v -d@get_req.xml -H "Content-Type: application/soap+xml" ... # URL part as above

HTH

[christgau]

Besides some (personal) style issues in the script, there is a functional one: You are doing an inplace change of wsd.xml, replacing the placeholder (too much "places" in this sentence) with the UUID. This will work only once. You either need to write the output somewhere else, IMO ideally in a temporary file or use are heredoc which would be my approach. The following would be my solution (note the hard-coded IP address):

#!/bin/bash

host_ip="192.168.2.81"
host_uuid="$(uuidgen --sha1 --namespace @dns --name $(hostname))"
msg_uuid="$(uuidgen)"
src_addr="$(uuidgen)"

curl --silent --fail --header "Content-Type: application/soap+xml" --data @- http://${host_ip}:5357/${host_uuid} > /dev/null <<EOF
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
  <soap:Header>
    <wsa:To>urn:uuid:${host_uuid}</wsa:To>
    <wsa:Action>http://schemas.xmlsoap.org/ws/2004/09/transfer/Get</wsa:Action>
    <wsa:MessageID>urn:uuid:${msg_uuid}</wsa:MessageID>
    <wsa:ReplyTo>
      <wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
    </wsa:ReplyTo>
    <wsa:From>
      <wsa:Address>urn:uuid:${src_addr}</wsa:Address>
    </wsa:From>
  </soap:Header>
  <soap:Body></soap:Body>
</soap:Envelope>
EOF
exit $?

curl ... || exit 1 would also work if the exit code has to be 1 in case of an error.

You mentioned that it would be adviseable to change the MessageID every time. Do you have a suggestion for how to do that? Probably somehow including the current date/time would be a good idea, but...

... a freshly generated UUID (version 4) would be sufficient 😉

[hihp]

The "functional" issue you mentioned is not one in this case, I think - I am fully aware that that is only going to work upon the first run, but since the hostname is not supposed to be changing, that one could theoretically be static (but it is not too easy to pre-calculate it in the process of creating a docker image, so I chose to do it in the healthcheck script).

The IP address of the host, however, might not be static - that's why I liked your idea of obtaining it on the fly, I just chose nslookup because using the "host" command would require to install additional packages in the container image ^^

I knew that having the XML template in the script file was somehow possible, but as I say, my script-fu is not nearly as good as yours :-D

In addition, since I want to publish this as a docker container (I actually already did - https://hub.docker.com/r/hihp/wsdd and https://github.com/hihp/wsdd ), I would like to make it a bit easier to read...

This is just because personally I always like it when other people's containers are easy to read. I have a certain amount of distrust for "non-official" docker images, so when I use one, I like to understand what's going on to decide whether I want to use somebody else's container ^^ That is also the reason why I went for the long option names instead of the short ones (e.g. "--silent" instead of "-s" for curl) - makes it easier to understand for someone who doesn't know the options by heart. Also, that is why I put comments in...

But I'll try it out your style as soon as I can. Just using variables is, after all, quite a bit faster than using sed three times, plus it actually might be the easier-to-understand solution anyway, because it neither requires an additional file nor knowledge of sed (which I think one could write a full book about).

As for the MessageID: I am aware that it should be a UUID ;-) I just have no experience with uuidgen. But from what I can take from the documentation, I assume it should be as easy as the following, right?

msguuid="$(uuidgen --time)"

[christgau]

The "functional" issue you mentioned is not one in this case, I think - I am fully aware that that is only going to work upon the first run, but since the hostname is not supposed to be changing, that one could theoretically be static (but it is not too easy to pre-calculate it in the process of creating a docker image, so I chose to do it in the healthcheck script).

Ok, but you loose your template when doing the replacement. Nevertheless, I guess it would be "restored" when the container is rebuild/restarted.

The IP address of the host, however, might not be static - that's why I liked your idea of obtaining it on the fly, I just chose nslookup because using the "host" command would require to install additional packages in the container image ^^

Yeah, yeah. Just use the tools you like...

I knew that having the XML template in the script file was somehow possible, but as I say, my script-fu is not nearly as good as yours :-D

Nah, you never stop learning and so do I. 😉

This is just because personally I always like it when other people's containers are easy to read. I have a certain amount of distrust for "non-official" docker images.

I absolutely agree.

But I'll try it out your style as soon as I can.

Again, feel free to use what do you like and works best for you.

As for the MessageID: I am aware that it should be a UUID ;-) I just have no experience with uuidgen. But from what I can take from the documentation, I assume it should be as easy as the following, right?

msguuid="$(uuidgen --time)"

Any UUID would work. There is, AFAIK, no need on the WSD protocol side for any special semantic behind the UUID. At least, wsdd does not care about the UUID version. Thus, you can just issue uuidgen as in my solution to get a message UUID. By the way, a version 4 UUID is completely (pseudo)random and would just work.

[hihp]

Alright, I think I have it working. Added a new environment variable "DEBUG" which will make the script output some more. All can be found here: https://github.com/hihp/wsdd

Thank you very much :-)

[christgau]

You're welcome.

Would you mind to mark the discussion as answered?