JerryYuan 最近的时间轴更新 JerryYuan 最近的时间轴更新 |
JerryYuanV2EX 第 657743 号会员，加入于 2023-11-01 17:08:44 +08:00 |
www.jerryzone.cn
| 含锂离子电池报废设备应该怎么妥善处理？ 生活 • JerryYuan • 115 天前 • 最后回复来自 dejavuwind | 11 |
| Clash For Windows 可以通过 mixin 追加节点吗？ 程序员 • JerryYuan • 199 天前 • 最后回复来自 JerryYuan | 2 |
| 如何在 Node 中实现类似于 docker-cli 的效果 程序员 • JerryYuan • 2024-01-01 20:06:56 PM • 最后回复来自 JerryYuan | 1 |
| 求一枚开源，轻量级的分布式任务调度系统 程序员 • JerryYuan • 2023-11-11 23:20:34 PM • 最后回复来自 morebuff | 10 |
JerryYuan 最近回复了
1 天前 回复了 wjx0912 创建的主题 › 程序员 › postman 有咩有这个功能 |
environment 或者 variable?
配置一个环境变量(不是 os 的那个，是 postman 自己的概念)，然后拿着变量去构造 url 。需要替换的时候就改环境变量就行了。
配置一个环境变量(不是 os 的那个，是 postman 自己的概念)，然后拿着变量去构造 url 。需要替换的时候就改环境变量就行了。
2 天前 回复了 hikarumx 创建的主题 › 程序员 › apifox 挂了，没有离线版就是不方便。 |
VSCode + thunder client
后者 js 写的插件，需要花些时间破解掉 50 个请求的限制和不升级不让用，基本可以实现纯离线的 API 调试工具，支持 curl 导入、pre-scripts 、env 、code-gen 这些 postman 基础功能，也支持导入 postman 的导出文件。
后者 js 写的插件，需要花些时间破解掉 50 个请求的限制和不升级不让用，基本可以实现纯离线的 API 调试工具，支持 curl 导入、pre-scripts 、env 、code-gen 这些 postman 基础功能，也支持导入 postman 的导出文件。
5 天前 回复了 kyonn 创建的主题 › 程序员 › 有没有开源靠谱的青龙平替选择? |
@kyonn nodered 其实算是那种低代码平台，拖拉拽实现一个流程。只是玩智能家居的有不少没能力写代码的，促成了 nodered 在这个圈子的繁荣。
5 天前 回复了 kyonn 创建的主题 › 程序员 › 有没有开源靠谱的青龙平替选择? |
之前用 cronicle ，优点是可以通过插件扩展出很多种执行器，缺点是连 docker 官方都没支持，得自己写插件实现 nodejs 调用 docker ，之前也自己搓出来了这个插件。
直到某天误操作 rm -rf 了(操作效果类似，但不是 rm -rf)，懒得重新研究文档写插件了，发现了一个新的异步任务调度工具 Dagu
Dagu 本质上是一个 DAG 工具，即有向无环图调度工具，因为是 golang 搓的，它原生支持 docker 所有参数，用 yaml 定义 DAG ，然后逐个节点执行。缺点嘛，就是这东西轻量到可以称之为简陋，没有汉化，甚至没有一个 icon ，执行器方面你得把代码打包成服务(走 HTTP 触发器)或者 docker 镜像它才能调用(或者在 yaml 里搓 shell 脚本)，前者内存常驻和 cronicle 其实无差了，后者还得自建 docker registry ，当然我的话是有搭建 gitea ，它本身带一个简化的软件包管理，支持 docker 镜像托管，搭配上 gitea action 自动构建镜像，用 dagu 去自动拉镜像执行还是挺舒适的。
Dagu 项目地址:https://github.com/dagu-org/dagu
PS:打到这，其实如果有 gitea 了，搭一个 gitea action 让它定时执行也不是不行哈。
直到某天误操作 rm -rf 了(操作效果类似，但不是 rm -rf)，懒得重新研究文档写插件了，发现了一个新的异步任务调度工具 Dagu
Dagu 本质上是一个 DAG 工具，即有向无环图调度工具，因为是 golang 搓的，它原生支持 docker 所有参数，用 yaml 定义 DAG ，然后逐个节点执行。缺点嘛，就是这东西轻量到可以称之为简陋，没有汉化，甚至没有一个 icon ，执行器方面你得把代码打包成服务(走 HTTP 触发器)或者 docker 镜像它才能调用(或者在 yaml 里搓 shell 脚本)，前者内存常驻和 cronicle 其实无差了，后者还得自建 docker registry ，当然我的话是有搭建 gitea ，它本身带一个简化的软件包管理，支持 docker 镜像托管，搭配上 gitea action 自动构建镜像，用 dagu 去自动拉镜像执行还是挺舒适的。
Dagu 项目地址:https://github.com/dagu-org/dagu
PS:打到这，其实如果有 gitea 了，搭一个 gitea action 让它定时执行也不是不行哈。
@Puteulanus 卧槽亮瞎我狗眼
层主可能需要的是一个 pastebin 。纯静态站点想不太出来输入的数据怎么留到下一次访问，既然客户端重启就重置，那么 localstorage 这种浏览器内的本地存储大概也会被重置，想留下数据就只能靠后端，但是这又是个静态页面，没有后端。还是说层主只需要一个页面，在单次开机周期内能留下数据就行。
pastebin 的话就是专门给你个地方去保存剪贴板里无处安放的数据，因为功能很简单，就算有后端也很轻量，可以考虑在路由器上部署。
另外还有个骚路数，就是让 ai 给你写个 luci 插件，实现一个文本框，里边能保存一些数据，然后数据直接用 openwrt 那个配置管理 uci 存或者/tmp 下或者哪的开个文件存。认证就靠 op 的登录，配一个强密码，主打一个数据和路由器配置共存亡。
pastebin 的话就是专门给你个地方去保存剪贴板里无处安放的数据，因为功能很简单，就算有后端也很轻量，可以考虑在路由器上部署。
另外还有个骚路数，就是让 ai 给你写个 luci 插件，实现一个文本框，里边能保存一些数据，然后数据直接用 openwrt 那个配置管理 uci 存或者/tmp 下或者哪的开个文件存。认证就靠 op 的登录，配一个强密码，主打一个数据和路由器配置共存亡。
53 天前 回复了 chunqicoder 创建的主题 › 程序员 › 求推荐家庭服务器(nas)配置方式，有外网 ip |
@JerryYuan 用这点性能损耗换快照这些功能还是很值的。
53 天前 回复了 chunqicoder 创建的主题 › 程序员 › 求推荐家庭服务器(nas)配置方式，有外网 ip |
@YsHaNg 现在的虚拟机都是靠专门的虚拟化指令集实现的了，效率已经接近 99%了，损耗几乎可以忽略不计了。现在云厂商，再加个最基础的芯片去做虚拟化控制器，甚至都能做出 100%效率的虚拟机了。
56 天前 回复了 chunqicoder 创建的主题 › 程序员 › 求推荐家庭服务器(nas)配置方式，有外网 ip |
建议选一个 pve 或者 esxi 这种，没啥可折腾的虚拟化系统做整个家庭私有云服务的底座，折腾的越少越稳定。同时虚拟化平台还可以提供快照这一粒重要的后悔药。
然后包括 NAS ，还有计算节点都在其上另开虚拟机。磁盘啥的可以直通进虚拟机，部署 NAS 系统可以和物理机一样的。
目前我就是 PVE 做底座，其上部署黑群(存储)+OpenWRT(网络)+Ubuntu(计算)，完全按括号里的拆分，群晖负责一切和存储/备份有关的操作，Ubuntu 负责一切数据处理工作，OpenWRT 负责一切和网络相关的工作。Ubuntu 挂载群晖的 NFS 卷作为 Docker 的持久化卷(Volume)，Openwrt 完成异地组网，VPN 一键回城。
然后包括 NAS ，还有计算节点都在其上另开虚拟机。磁盘啥的可以直通进虚拟机，部署 NAS 系统可以和物理机一样的。
目前我就是 PVE 做底座，其上部署黑群(存储)+OpenWRT(网络)+Ubuntu(计算)，完全按括号里的拆分，群晖负责一切和存储/备份有关的操作，Ubuntu 负责一切数据处理工作，OpenWRT 负责一切和网络相关的工作。Ubuntu 挂载群晖的 NFS 卷作为 Docker 的持久化卷(Volume)，Openwrt 完成异地组网，VPN 一键回城。
63 天前 回复了 yellowstrong 创建的主题 › OpenWrt › 求助万能的 V 友关于两台 OpenWRT 异地组网的问题 |
建议还是研究下 IPv6 公网地址，直连的带宽和延迟不是转发能比拟的(可以多配置一条转发的路由备用)
回到题主的问题，所谓的 A 网络主机访问 B 网络主机实际包含两步，A 网络主机请求 B 网络主机，B 网络主机处理请求响应 A 网络主机(这一层很容易被忽视)
所以按题主配置，ping 包传输的整个链路应该是:
去程:
* A 网络主机→A 路由器 LAN(ICMP Request)
* A 路由器 LAN→A 路由器 WG0(ICMP Request)
* A 路由器 WAN→中转节点 WAN(wg 协议)
* 中转节点 WG0→中转节点 WG0(ICMP Request ，中转节点 wg0 也许能抓到，抓不到跳过也行)
* 中转节点 WAN→B 路由器 WAN(wg 协议)
* B 路由器 WG0→B 路由器 br-lan(ICMP Request)
* B 路由器 br-lan→B 网络主机(ICMP Request)
回程:
* B 网络主机→B 路由器 br-lan(ICMP Echo)
* B 路由器 br-lan→B 路由器 wg0(ICMP Echo)
* B 路由器 WAN→中转节点 WAN(WG 协议)
* 中转节点 wg0→中转节点 wg0(ICMP Echo)
* 中转节点 WAN→A 路由器 WAN(wg 协议)
* A 路由器 WG0→A 路由器 br-lan(ICMP Echo)
* A 路由器 br-lan→A 主机(ICMP Echo)
捋清楚完整的预期数据通路以后，就可以分段配置每一台设备，让数据包按预期流转。
这里引入一个调试技巧，即在整体不通时，在每一段两端的网络适配器抓包看看数据包走到哪一步就迷路了，找到迷路的那一步，对照发送的一侧适配器所在主机的路由表看看实际走到哪条路由上去了，一般修正这个路由表配置，数据包就能继续往前走了。所有链路都抓包确认成功以后，网络应该也就通了。
回到题主的问题，所谓的 A 网络主机访问 B 网络主机实际包含两步，A 网络主机请求 B 网络主机，B 网络主机处理请求响应 A 网络主机(这一层很容易被忽视)
所以按题主配置，ping 包传输的整个链路应该是:
去程:
* A 网络主机→A 路由器 LAN(ICMP Request)
* A 路由器 LAN→A 路由器 WG0(ICMP Request)
* A 路由器 WAN→中转节点 WAN(wg 协议)
* 中转节点 WG0→中转节点 WG0(ICMP Request ，中转节点 wg0 也许能抓到，抓不到跳过也行)
* 中转节点 WAN→B 路由器 WAN(wg 协议)
* B 路由器 WG0→B 路由器 br-lan(ICMP Request)
* B 路由器 br-lan→B 网络主机(ICMP Request)
回程:
* B 网络主机→B 路由器 br-lan(ICMP Echo)
* B 路由器 br-lan→B 路由器 wg0(ICMP Echo)
* B 路由器 WAN→中转节点 WAN(WG 协议)
* 中转节点 wg0→中转节点 wg0(ICMP Echo)
* 中转节点 WAN→A 路由器 WAN(wg 协议)
* A 路由器 WG0→A 路由器 br-lan(ICMP Echo)
* A 路由器 br-lan→A 主机(ICMP Echo)
捋清楚完整的预期数据通路以后，就可以分段配置每一台设备，让数据包按预期流转。
这里引入一个调试技巧，即在整体不通时，在每一段两端的网络适配器抓包看看数据包走到哪一步就迷路了，找到迷路的那一步，对照发送的一侧适配器所在主机的路由表看看实际走到哪条路由上去了，一般修正这个路由表配置，数据包就能继续往前走了。所有链路都抓包确认成功以后，网络应该也就通了。
Select Language