Oh please I want some day to see Turris support plugging a USB drive and configuring the OS to put /var and not on the ramdisk, for persistent logrotate managed logging!
Out of topic but it is considered for a long time: https://gitlab.labs.nic.cz/turris/foris/foris-storage-plugin/issues/1
1 Like
It is not that simple, at least not with magnetic drives. You don’t want them to be spun up every minute by logging that cron has run the rainbow script or whatever. Here’s my config for Turris OS 3, which writes to disk more or less once an hour, or (obviously) whenever someone connects to WiFi/VPN and so on. https://gist.github.com/peci1/979fd510d82a99a784d5996d6d93c93a
2 Likes
Nice gist! Thanks. I’m not sure why it’s not that simple mind you, how is it different to all systems that have mag disks and /var on them? I mean I have a number of 24/7 servers with mag disks and Ubuntu running be it a web server a NAS (with an embedded Linux variant) or a Nextcloud server. All of them running 24/7 with mag disks logging to /var.
Is it the latency of spin up that is the concern? A router does have one criterion above all others which in fact leaves me still surprised that they use a non-real time OS (unless I’ve misunderstood the kernel OpenWRT and Turris use) which is real time packet processing. Latency is not a good thing there. But I suspect (not being too well versed in router design) that they way they get away with a non real time OS like the Linux kernel) is that routing happens underneath the kernel in firmware or hardware that’s configured by the overlying OS but upon which it does not rely and can run real time. Alternately perhaps OpenWRT and Turris use the RT-Linux microkernel?
But as an aside, what I’d really like is not to have to study the internals so much at all and for Foris or Luci to have a simple sys config options like “Persist logs” that implements say your gist or something like it, to put persist relevant logs on a USB drive.
This arose for me some while back when trying to diagnose issues that were causing resets. Imagine my joy to disvover all the logs were ephemeral. Not. What I did learn to love is the superb Turris feature to roll back to earlier filesystem snapshots using the reset button! Absolute stroke of stabilising genius and one reason I suspect many of us love the Omnia. A router you can destroy by accident (by implementing a broken firewall or routing rule) and recover from ;-).
2 Likes
Hmm, my concern comes probably more from my view of Turris devices as routers, which I expect to keep power consumption as low as possible. Nothing more. If you’re not concerned about power consumption, then there’s probably no reason to not log everything.
I can imagine adding a “Persist logs” option, which could at least be part of the diagnostics performed by Foris. That could help with some issues.
AFAIK, the Turris devices do switching in the dedicated hardware chips, but routing is done in the Linux kernel.
Interesting. While low power consumption sure is a boon, I’m not sure given the server farm behind the router that’s running 24/7 that the routers’s power consumption makes any grave difference. One more little hard disk running on top the the dozen or so drives running on serves behind that router ;-).
That said, I do like the idea of optimising power consumption and your gist looks like an awesome way to separate important logs onto the mag drive. The only concern I have is that it requires a certan savvy to install and to understand it and to delve to that level of system details, and a lot of folk might really love to see a simple Foris option to persist logs, so that any issues that span reboots can be examine sin the system logs.
Or, you can simply forward all syslog to another log_server and store it there