https://blog.margrop.net/en/tag/cron/ Recent content in Cron on Margrop Blog Hugo -- gohugo.io en-US Thu, 09 Jul 2026 10:00:00 +0800 https://blog.margrop.net/en/post/qinglong-baihu-panel-security/ Thu, 09 Jul 2026 10:00:00 +0800 https://blog.margrop.net/en/post/qinglong-baihu-panel-security/ <blockquote> <p><strong>Bottom line first</strong></p> <p>QingLong Panel used to be the default answer for many self-hosted scheduled-script setups. It can run scripts, manage environment variables, show logs, synchronize repositories, and wrap crontab-like workflows in a friendly web UI. But the critical QingLong issues publicly discussed in early 2026 changed the risk calculation: <strong>a task scheduler panel is not just another web admin page. It often holds scripts, secrets, notification tokens, and execution privileges. If authentication can be bypassed, the attacker is not merely viewing a dashboard; they may be standing in front of a machine that can run jobs.</strong></p> <p>For new lightweight deployments, I would now evaluate BaiHu Panel first. BaiHu is a Go + Vue3 automation task scheduling platform focused on low overhead and high performance. Its public README describes Docker / Docker Compose deployment, Mise-based runtime management, repository task synchronization, logs, notifications, and secret handling. It is not a perfect one-to-one replacement for every QingLong workflow, but it is a better starting point for many personal script-hosting cases.</p> <p>If you must keep using QingLong temporarily because of old jobs, migration cost, or compatibility constraints, do not expose it directly to the public Internet. Put a protection layer in front of it: VPN, zero-trust access, reverse-proxy Basic Auth, an allowlist, WAF rules, or equivalent access control. This article includes one-click scripts for Windows 11, Ubuntu 26.04, and macOS 26. They deploy BaiHu by default, require an explicit switch to deploy QingLong, and put either panel behind Caddy Basic Auth.</p> </blockquote> https://blog.margrop.net/en/post/openclaw-backup-failure-investigation-and-fix/ Mon, 13 Apr 2026 09:30:00 +0800 https://blog.margrop.net/en/post/openclaw-backup-failure-investigation-and-fix/ <p>This post is a full incident review, not because the failure was dramatic, but because it was a very typical automation problem.</p> <p>Two machines lost their automatic OpenClaw backups at the same time: a local macOS machine and a remote VPS. Manual runs worked on both sides, and the archives could still be synchronized to the NAS, but the scheduled jobs were unreliable. At first glance it looked like &ldquo;the scheduler did not fire.&rdquo; In reality, the root cause was spread across scheduling, permissions, locking, logging, and even the way I validated the schedule.</p> <p>That combination is what makes these incidents annoying: every individual piece looks almost fine, yet the full pipeline still fails.</p>