-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Package request: Wazuh-agent #1
Comments
Huzzuh! (Wazuh?) Ok so yea, I think I mentioned already that I'm also learning Nix as I go here. What command are you running to manually start the service? |
Right now, after the |
5125b09 should make the Wazuh service build successfully. My VM ran out of space so I'll try again tomorrow |
Tested it this morning. It builds but does not start. After getting it up and running the manual way yesterday, I reverted back to setting it up in configuration.nix to test. For clarity, I'm sourcing the
Here is the error:
It is upset trying to change directories so I'll be looking at that next. |
It might be related to this? I don't think this line is important anyways
Yeah I think it's trying to |
Yea, I think that makes sense. I added some debugging statements and they don't ever run so its definitely like preStart isn't actually running. I'm going to try killing that line. I got mixed up for a bit by my system config too. Forgot to run |
That did the trick, kind of. Now the
|
Weird. Guess I'll have to wipe my VM and start fresh with debugging |
Starting from a fresh VM on a NixOS host, removing the
|
I'm getting the same error. I also made a small change to my fork that alleviated permission errors. It uses systemd.tmpfiles.rules. So the issue seems to that wazuh-control can't sort out the pid of wazuh-execd in the context of the systemd service since starting the binary manually works. And each attempt to start the service results in another instance of wazuh-execd. |
I read up on systemd tempfiles a bit, sounds like a worthy solution for the state directory permission issues you were having. I suppose we can consider the state directory volatile then? Seems like the appropriate debugging to narrow down the cause of |
The info on the implementation of tempfiles seems a bit vague and poorly documented. I came across a number of posts where people used them just fine for a persistent state directory and said it persists on reboot. Downside is if you manually deleted it, restarting the service doesn't restore it and from what I can tell neither does running So I've just been using Looking at number of times it iterated, i'm pretty sure it is some sort of race condition and the insertion of extra statements gave it enough breathing room to work. |
LOL wow nice job! I have no idea how |
Well not |
Well if you'd like, definitely recommend eventually putting an issue up on https://github.com/wazuh/wazuh/issues. If anything, just to get them aware of this weird behavior and what their input is. |
That is pretty odd. This is my current preStart which I updated today. Took some trial and error but replaced the debugging statements with sleep statements that seem to have kept it working. I also checked out that file on my machine and no such issues.
|
I still find it kinda funny that adding more sleep statements have been making this work knowing that wazuh-control already has sleep statements in that same loop lol. I tried to replicate with your previous working iteration, but I'll try with your new iteration. FWIW, I'm now using a NixOS host and building VMs declaratively referencing this article: https://nix.dev/tutorials/nixos/nixos-configuration-on-vm.html Script I'm running: rm -rf ./result nixos.qcow2 # the VM automatically creates the qcow disk to persist state
nix-build '<nixpkgs/nixos>' \
-A vm \
-I nixpkgs=$PWD/nixpkgs \ # point this to your nixpkgs repo path
-I nixos-config=./configuration.nix \ # see below for example config
--show-trace && \ # debugging flag, optional
./result/bin/run-nixos-vm -nographic && \ # run the QEMU VM
reset # reset the terminal after the VM shuts off Example VM config: { config, pkgs, ... }:
{
boot.loader.systemd-boot.enable = true;
boot.loader.efi.canTouchEfiVariables = true;
# Wazuh stuff I added
services.wazuh.agent.enable = true;
services.wazuh.agent.managerIP = "192.168.2.11";
users.users.joe = { # change as desired
isNormalUser = true;
extraGroups = [ "wheel" ]; # Enable ‘sudo’ for the user.
packages = with pkgs; [
git
];
initialPassword = "password"; # change as desired
};
system.stateVersion = "23.11";
} Seems like a proper, immutable testing environment instead of dealing with manual VM stuff. The VM build doesn't take long either. |
Nice, that seems like a solid approach. I have a flake based setup which is spread across multiple files. I'm using my remote git repo as the source for my nixpkgs at the moment.
And then I have the configuration.nix which has the Wazuh services setup. So after I push to remote repo, I just run a rebuild. Only downside to that is that I have to push everything to remote so it means a lot more commits and pushes. But once you get tisi running, we need to decide what is next to get this to a minimum level of functionality. My gut says we need to start assessign what default Wazuh checks do and don't work on a NixOS system. I have a feeling that in a lot instances, they will work since NixOS often symlinks to the nix store from the normal locaiton for a file so Wazuh will still find things. |
Awesome! Yeah for sure. I can't remember if I posted a related comment, but I agree, we do need to look through the Wazuh default config (it's currently set up for debian/common FHS) and make sure we're linking stuff properly. Still waiting on journald support from Wazuh, that's the big blocker for that task. I believe it's going through their QA currently? Edit: |
I believe I've identified the root cause of I was able to narrow it down to our usage of the systemd path option. Specifying systemd.services.wazuh-agent = mkIf cfg.agent.enable {
path = [
"/run/current-system/sw"
];
...
} View the last commit with the fixes here: |
I'm putting the branch up for review in this PR: Should allow it to be globally available for others to test and work with while we wait for Wazuh to implement journald support. |
Good work! We should definitely keep it globally available. I don't see a compelling reason to wait for journald support. Yes, it does limit some of the functionality of the agent but there are other ways to ship journald logs to Wazuh. The Wazuh manager is also a SIEM so in the meantime, someone could ship the journald logs using something like fluent-bit/fluentd or filebeat. |
I noticed the build is failing on that PR. I'm getting the same error testing on my machine. Looking into a bit this morning, will update if I find anything. |
Fixed it: #2 |
Interesting, wasn't getting that error, but that makes sense to me. Thanks for spotting it! |
Ok, new issue. The way we are handling the My guess is that this is because of the |
That is a big design flaw, good catch. Ideally we do want a mutable |
I got it to work here: #3 While it is possible to take a declarative approach to client.keys, I don't think that makes sense. If someone wanted to use the same config on multiple machines, they would need someway to register dynamically plus in a large environment you wouldn't want to basically manually register them all. In my opinion, this is a good approach for any dynamically created files that we want to have persistence which shouldn't be many since the manager is responsible for storage of actual data. Long term, I think we will have to just wait and see what breaks and update the service as needed, either using that same rsync command or something else, to protect those files. |
Today I tested the group functionality. So I created a I verified that it pushed to my machine then reverified its presence after both a reboot and rebuild. Since I didn't protect that file in anyway, my assumption is that the manager likely replaced it as soon as it saw it was missing. That said, I think we don't have to worry too much about most of the files in there since the Manager will likely fix those issues. Time will tell though! On another note, what do we have left to actually get this merged? I've read through some of the docs on contributing and I get the feeling we are just waiting on someone to review it? |
Awesome! Good to know that it'll persist configurations through syncing. I'm not quite sure, I'm definitely waiting and looking for a review from the NixOS community just to make sure things look good. Also, just so we're on the same page, being listed as a maintainer for |
Well that wasn't supposed to happen. I'll work on squashing and cleaning up this branch, and resubmitting a new PR. And because I don't 100% my git-fu, I made a backup branch just in case lol. https://github.com/V3ntus/nixpkgs/tree/wazuh-agent-pre-rebase |
New PR up at NixOS#309573 |
Lol. Yea, I'm down to be on the maintainers list. Is it safe to open up a PR or are we going to blow it up again? |
PR for adding me to the maintainers as well. |
Should be good! Looked to be a flaky workflow that caused it after a terrible go at a force push on my end. |
Didn't see this. Probably would have to look into using this process with the recent reviews on the Nixpkgs PR. |
First 4.9.0 alpha is out which includes the added journald support. Hoping I can get traction back to testing. |
Moved from: NixOS#230623
The text was updated successfully, but these errors were encountered: