- new: Implement Harvest-MCP
- new: API tokens are no longer stored in cleartext on disk
- new: Automatic version check and upgrade for Harvest and NAbox
- new: Add configuration for http proxy
- new: Moved alerts configuration to /etc/vmalert for easier customization
- Harvest 25.08.1 (new deployments only)
- Grafana 12.2.1
- Base OS upgrade (Flatcar Container Linux 4230.2.4)
#NAbox 4.1.0b2 available
dawn salmon
dense iron
pushed the update (running on azure via hyperv image)
It's been on this screen for about 15min or so and hasn't moved, console shows nothing going on.
dense iron
and the system is in a boot loop again, just like when trying to update from the last time.
I did make a snapshot of the disk beforehand this time
dawn salmon
Still using nfs on /data ?
dawn salmon
If you try it again, run and record sudo journalctl -fu naboxd in terminal
dense iron
yea, i am.
ok, run that command and then try to do the upgrade I'm guessing
I will as soon as i get back
dawn salmon
I'm trying something, see if it breaks anything, so far it's ok :
admin@nabox4 ~ $ cat /etc/systemd/system/nabox.service
[Unit]
Description=NAbox Containers
After=docker.service remote-fs.target
[Service]
Type=simple
WorkingDirectory=/etc/nabox
ExecStartPre=touch .env.custom
ExecStartPre=rsync -avh --update /usr/share/nabox/alertmanager/ /etc/nabox/alertmanager/
ExecStartPre=rsync -avh --update /usr/share/nabox/vmalert/ /etc/nabox/vmalert/
ExecStart=dc up --remove-orphans
ExecStop=dc down --remove-orphans
EnvironmentFile=/etc/nabox/.env.custom
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
Change is :
After=docker.service remote-fs.target
in theory, it'll make sure containers are started after remote fs are up, and stopped before they are taken down
which I suspect is the problem
dense iron
for somr reason azure is not letting me switch the OS disk back to the snapshot. Guessing it's because the system never reports it's up and running with the agent, and it thinks it is not allocated properly.
Is there a way to edit grub, or boot from the command line, with a very minimal set of options and bypass the attempt to access that disk, or the mount or anything?
I know you can normally do systemd.mask=#service.name but that doesn't seem to do anything.
Also tried just using single and /bin/bash
i'll try to edit the files from the grub menu, if it will let me and see if that does anything
dawn salmon
Ah not cool… you tried USR-A and USR-B I guess ?
dense iron
hrm.
Attached the disk to another system, edited the nabox.service file and added the remote-fs.target
booted, still sticks at the exact same spot
dawn salmon
What’s that spot exactly ? I mean is that somewhere during booting and do you have a screenshot ? Or is that the web ui stuck in upgrade ?
hushed mesa
Hi @dawn salmon very cool thanks 😊 short question about the mcp integration. This means that with that release every NAbox has the mcp server integrated and can be used from a mcp client?
dawn salmon
Indeed, still needs documentation but basically mcp is listening on /mcp port 80 (must be enabled in preferences)
dense iron
it's during boot, it's the exact same spot it was stopping/sticking the last upgrade
dawn salmon
Dang it. Can’t remember.
Ok its on the 4.0.11 thread. So you were never able to figure out exactly the failure.
Since it seems to fail even before upgrading the system, I’m hoping watching journalctl -fu naboxd can be useful
dense iron
that needs to be ran on the system during the upgrade right?
dawn salmon
yes that's correct
pearl summit
Deployed this with the nightly harvest build to get the ASA r2 dashboard. Zero problems. Great job on this project!!!