Conversation
execution order. dbd, agentless, and csyslog only start after everything else, but I did not concern myself with the execution order of those 3.
I have no doubts the logic can improve, but I want to get a PoC in place.
systemd know when to start these programs.
actually start the daemons
src/init/ossec-server.sh
Outdated
| ## XXX - system paths and exact execution are probably wrong. | ||
| if [ X`uname` == "XLinux" ]; then | ||
| if [ -x /sbin/systemctl ]; then | ||
| /sbin/ssytemctl start ossec-server.service |
There was a problem hiding this comment.
ssytemctl
Think this might need to be systemctl
|
Fixed the ssytemctl typo. |
…into systemd_combined
…stemd_combined
Add the same stuff for ossec-agent
…s/git/github/ddpbsd/ossec-hids into systemd_control
|
I'm lightly testing the agent bits on Ubuntu 16.whatever LTS. Seems to be going well-ish so far. |
actually in /bin. Try to make it less location dependent.
|
I think restart isn't working. Will test later and update. |
| [Unit] | ||
| Description=OSSEC Execd | ||
| PartOf=ossec-agent.target | ||
| Before=ossec-ossec-syscheckd.service ossec-agentd.service ossec-logcollector.service |
There was a problem hiding this comment.
typo here ? should be ossec-syscheckd
There was a problem hiding this comment.
Thanks for spotting those mistakes. They should be corrected now.
src/init/ossec-server.sh
Outdated
| ${SYSTEMCTL} stop ossec-server.target | ||
| fi | ||
| exit 0 | ||
| if |
|
@ddpbsd I'm not sure if you want this kind of behavior: if one of the member services (such as execd, syscheckd, etc) is killed/crashed by some reason, the server/agent target should be stopped. |
|
And also there is one concern in this part of signal handle code: If the exit code is always 1, then service's Active state is always failed instead of 'inactive (dead)' if we use 'systemctl stop' to stop the target or any service. client-syscheckd.service - OSSEC syscheckd
Loaded: loaded (/usr/lib/systemd/system/client-syscheckd.service; static; vendor preset: disabled)
Active: failed (Result: exit-code) since Thu 2018-08-23 09:06:30 CEST; 39s ago
Process: 5235 ExecStart=/usr/bin/env ${DIRECTORY}/bin/ossec-syscheckd -f (code=exited, status=1/FAILURE)
Process: 5225 ExecStartPre=/usr/bin/env ${DIRECTORY}/bin/ossec-syscheckd -t (code=exited, status=0/SUCCESS)
Main PID: 5235 (code=exited, status=1/FAILURE)
|
|
For the reload option in ossec-control.sh, you can apply the same thing in systemd using below option https://www.freedesktop.org/software/systemd/man/systemd.unit.html#PropagatesReloadTo= However, it is applied for systemd version 235 and later only. |
| Description=OSSEC syscheckd | ||
| PartOf=ossec-server.target | ||
| After=ossec-maild.service ossec-execd.service ossec-analysisd.service ossec-remoted.service | ||
| Before=ossec-agentless.service ossec-csyslog.service ossec-dbd.service ossec-monitord.service ossec-remoted.service |
There was a problem hiding this comment.
ossec-remoted has been in "After" section
| [Unit] | ||
| Description=OSSEC remoted | ||
| PartOf=ossec-server.target | ||
| After=ossec-maild.service ossec-execd.service ossec-analysisd.service ossec-logcollector |
Requires/includes PR #894
This should allow ossec-control to utilize systemd to manage the ossec processes. Also untested, and kind of unsure if I finished it.
This change is