Split every checks in their own files #68
Labels
No Label
bug
bullseye
discussion
duplicate
enhancement
help wanted
invalid
question
suggestion
wontfix
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Blocks
#4 Basic OpenBSD checks and first OpenBSD release
evolix/evocheck
Reference: evolix/evocheck#68
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
And like munin plugins, use symbolic links to enable checks.
This does introduce the potential of someone editing the symbolic link with
sed -i
and overwriting it, but I think that can be fixed by making it read only?Yeah and /usr is already RO most of the time.
Also, nobody should
sed -i
a check 😧.Give a man a shovel and he'll dig himself into a hole.
IMO evocheck.sh must stay a single readeable shellscript file
Would logrotate be one big file?
Would vhosts be one big file?
Would crons be one big file?
Would ansible-roles be one big file?
Would
…
be one big file?I don't agree and I think we should vote/debate it!
I dont feel like evocheck.sh is particularly readable in the first place..
Modularization is a relatively well proven method of reducing complexity of stuff like development, testing, and deployment.
If this is to be a proper open source project and not just an internal tool, we have to make it simple and secure to add and remove checks. The filesystem has well understood semantics about adding, removing and reading information and we should use that.
After looking at the code again, I really think this would be a good idea.