Make OS integration leaner about goprobe HOT 2 CLOSED

Currently, OS integration is not up to date with the latest changes, e.g. the goprobe.service systemd script executes lots of pre/post tasks, which are unnecessary within systemd (no PID file is required, systemd takes care of that by itself), plus we don't have any shared libraries anymore, hence the LD_LIBRARY_PATH stuff is unneeded as well.
For me, this simple file works splendidly:

[Unit]
Description=Network Traffic Monitoring
After=network.target syslog.target

[Service]
ExecStart=/bin/goProbe -config /opt/ntm/goProbe/etc/goprobe.conf
StandardOutput=syslog
Restart=on-failure

[Install]
WantedBy=multi-user.target
Alias=goprobe.service

This is the leanest and easiest part of the whole endeavor. I suggest that you simply change the current systemd file and push a commit. Then the first step is already covered.

Now, obviously there is one issue with that: The socket file (which might remain stale). However, I don't think we should handle that in the init script (as it is OS specific and just "cleans up" a mess that shouldn't even be there). Plus, systemd doesn't support custom service verbs (our current "info" verb doesn't work), so the whole socket interaction doesn't hold properly within that concept anyways. There's other considerations that bother me with the current Socket / info concept:

• We depend on netcat, which strongly differs for each OS
• We depend on perl, just to interact with the daemon and get a status information (OMG!)

This can be eliminated in a heartbeat, even if the socket approach is still used. We can write our own statusline package and get rid of the perl script. I actually already have the code lying around (with 100% test coverage).

• Sockets are fun, but not very 2018 (let's face it, it's in there for OSAG)
• On several occasions, the info target locks up on some machines (it's sporadic, but sometimes it takes minutes until I get even the header line), so stability is an issue as well

I have the following proposals:

• We remove the whole socket logic and provide an HTTP endpoint instead on lo. This can be parsed / extracted by any script / tool on any OS and will get rid of all other dependencies. Plus, go is made for that shit. Plus, we can extend it with more functionality in the future (as per your suggestion), to e.g. allow querying as well.

That would be prudent, since it greatly simplifies the socket handling functions in the main of goProbe. Instead of the gigantic switch statement, we'd simply register new handlers for each target. This would also be so much easier to extend than the other mess. 👍

What I do recommend though is to make the server configurable on each system. So unless specifically enabled in the config file, it will not run. Since we cannot assume whether a certain port is bound on a given system, we need to support a Server:IP:Port clause in the config.

• We provide an additional option to the goProbe binary (e.g. -info) that just queries that endpoint and prints the information (obviously not doing anything else, just exiting right away). That way we ensure that "info" can be called on any machine where goProbe is actually running without any additional dependencies / tools / whatever.

As a result, we would massively simplify OS integration, make the dependency stack much smaller (which is even more important now that we can just "go get", sucks a little that in the end the user figures out that there's a huge list of additional dependencies just to get it running).

@els0r , I'd be interested in your thoughts about this...

Fully agree on all points. To summarize how we can approach this leanly:

1. replace the systemd target with your simpler script – you
2. have goProbe do the statusline magic (remove perl) – me
3. run an HTTP server (best with chained handlers for authentication, special logging, etc.) – you/me

from goprobe.

@fako1024 : 1. and 2. are done (see 0171b7d), 3. would make the whole socket handling far easier.

from goprobe.