CLEMONの小栈

5G来了，千兆家宽也有了，但是6aidu网盘还是万年不变的100k/s！！这谁顶得住？其他网盘虽然速度可以，但是依旧存在种种限制，且文件不在自己手里，还得防和谐。自己的数据自己掌控，何不试试自己搭建私人网盘呢？毕竟数据是自己的，就得自己说了算，也不用去忍受小灵通下载速度。（P.S. 2023年5月似乎OneDriver也和谐了） 开源网盘有OwnCloud、青阳网络文件传输系统kiftd、Seafile、蓝眼云盘、NextCloud等选择。Seafile支持企业级协作，功能也极为丰富；Kiftd较为简洁，适合单人共享文件；而NextCloud流传较为广泛，支持插件，功能也极为丰富。我个人的网盘就选择了NextCloud，使用OnlyOffice处理文档等。 部署 Docker 直接上docker！ 由于App较多，不能一个App就起一个数据库，所以这里的数据库是位于另一台虚拟机里的，所有App统一使用，方便维护。 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647 ...

受够了爱优腾的付费？受够了费劲满世界找资源还得等下载？受够了下载的视频只能在电脑上看？那不如试试自动化追剧这一堆玩意～ 总体上说，通过这一套系统，可以通过ombi网页选择想看的电影or电视剧，后台自动下载视频文件、修改成标准命名并按需下载字幕。随后就可以在emby网页上或者客户端上观看，并且支持多用户多设备。而且顺便可以自动做种，自动刷PT。 结构 总体系统如图所示 由下到上进行说明功能： Indexer Manager(索引管理器)：Jackett、Prowlarr二选一，Prowlarr比较新，支持自动将合适的indexer推送到各个PVR。由于各个BT、PT、NZB资源站都不统一格式且不提供api，所以索引管理器就是将不同资源站点暴露为统一接口，方便其他程序调用以获取资源信息（种子、磁链等），基本就是个干些脏活累活的爬虫。当然这也是一切资源的源头，建议随时保持更新。 PVR(Personal Video Recorder): Sonarr电影集管理、Radarr剧集管理。PVR通过索引管理器提供的各个indexer搜索目标电影、剧集并获取种子，然后调用下载器下载。待下载完成 ...

之前写过使用netmaker的组网，今天就推荐类似的基于wireguard的另一个更优雅的组网工具开源版tailscale–>headscale。根据官网介绍可以支持内网打洞，经过实际使用后感觉打洞成功率还是可以的，移动、电信均成功打洞。严格来说headscale是tailscale的开源服务端（这个名字有点恶趣味2333），不过支持了绝大部分功能。 客户端连接的前几个数据包默认通过derp server进行中转，所以无论打洞成功与否都能保证网络网络联通。同时，客户端会尝试进行打洞，成功后两个客户端间即可P2P直连。 部署Headscale服务端 Tailscale的中继节点称为DERP Server，官方提供了免费节点但是都在国外。。。而Headscale内置了derp server，所以可以直接部署在同一服务器上。DERP Server需要自己来处理TLS，而如caddy、nginx等一般都只处理七层的http，对于4层的TLS(TCP)无法做到反向代理。而Let’s Encrypt自动TLS证书需要绑定443或者80端口，这就导致了如果作为DERP节点的服务器要么只能用非 ...

一直眼馋三层交换机，而且自己无论使用RouterOS还是OpenWrt配置三层路由进行跨VLAN通信都一直搞不起来，在路由内部每个VLAN都可以访问，然而外部进来的流量就不行。在搜索解决方案的时候无意间发现了OpenvSwitch这个SDN项目，该项目目前主要用在数据中心等地方，完整的方案叫OpenStack，而且囊括进三层之后还有个OpenvNetwork这个项目。经过测试后发现OpenvSwitch完全可以做到我需要的三层功能，而且还便宜不需要其他硬件支持跑在虚拟机上即可。 OpenvSwitch简称OVS，根据数据包不同的转发路径分为普通用户空间转发、内核数据路径转发（kernel datapath）、DPDK驱动转发三种，速度也是由低到高排序的。第一种数据路径的OVS安装较为简单，直接使用系统自带包管理器安装即可，具体参考官方文档。剩下两种里基本都是涉及到内核与驱动的，所以自己编译OVS在所难免。 这里记录下OVS-DPDK的编译流程。我所使用的编译环境是centos-8.5，最小化安装，因为有关内核驱动所以以后的机器也都是这么配置。宿主机是ESXI-6.7。 update@ ...

都说国家在大力推行IPv6了不是，咱们怎么也得整上一个不是。国内三大运营商应该基本都分配IPv6了，但是得把光猫设置成桥接模式才可以让内网的设备获得IP，如果运营商没给IPv6的话应该可以打电话问问。除此以外各大高校基本都是有教育网IPv6的，而且有的学校还不限流量。IPv6的存在是为了解决IPv4地址耗尽的问题，理论上IPv6地址可以给地球上每一个沙子都整一个hhh，设计的挺美好但是实际应用中感知并不那么强烈。而且鉴于以上的设计，IPv6是没有NAT的，虽然有NAT66的实现，但是一般也不推荐使用。 本人目前在宿舍可以直接DHCPv6获取到v6的IP，但是猜测学校是为了响应一人终端一号的安全要求，分配的IP竟然是/64的，这种情况也就是所谓的无PD（Prefix Delegation）。正常情况下IPv6应该给分配一个地址前缀，然后你自己的路由设备给局域网内的设备分配这个前缀下的子IP。而无PD后这个IP就算到头了，不可以再往下分配了，这就导致了只可以单个设备使用（实在不想吐槽1202年了宿舍竟然还只能一个设备上个看视频都卡的网），所以解决这个问题的方法也简单，那就是IPv6 NAT ...

虽然已经基于WireGuard将家里的本地网络同云服务器连接在了一起，但是由于内网穿透始终不是wg的强项，且一些情况下依旧需要P2P形式的内网穿透，所以目光就又回到了老朋友frp上来了，毕竟我的需求比较简单且frp用着习惯感觉也很稳定。 类似的内网穿透软件还有Ngrok、n2n等，都是大同小异的中心服务器架构，区别在支持的功能以及是否有官方节点等服务。当然非官方的服务还是有挺多的，只是简单的用一用可以考虑。 frp的server即frps，需要部署在具备公网ip的环境下。回到Homelab的结构，一个master和worker都有公网ip，所以当然就要部署在这个公网worker上。 而在怎么把frps服务暴露出去这个问题上属实折腾了很久，说到底还是对k8s的service不理解所致。frps支持几乎常用的所有协议，基本使用情境下就仅聚焦于TCP、UDP以及HTTP就行了，其中HTTP视作TCP流量即可。集群ingress使用的是ingress-nginx，文档中提及可以做L4的lb，但是不推荐，尝试后发现一个的lb类型的ingress的svc仅可以支持一种协议，即TCP和UDP不能共存 ...

无论本地储存或者把helm chart文件直接放在项目里面多少有点显得臃肿不方便，尤其对于我这种洁癖的来说就很烦。虽然有着类似helmMuseum的开源chart repo，但是搭建一个自己的还是更加舒服不是吗？而且继续薅Github的羊毛不香么？而且看官方说明也是支持薅羊毛的？？？ Helm chart repo原理很简单。首先，index.yaml文件里存储着这个helm repo里所有的chart的各版本信息以及地址，helm cli添加repo的操作就是获取这个index.yaml内信息；部署一个chart的时候就从index.yaml指示的地址获取到chart的压缩包进行部署就完成了。所以对应过来，我们需要一个网络服务器使得index.yaml可以被访问，还需要一个对象存储类似的储存各个chart的压缩包；这里白嫖方法也就是使用Github Pages来发布index.yaml，使用Github Release来发布各个压缩包，发布流程可以选择本地推送打包好的chart也可以直接使用Github Action进行打包并推送。当然我们这就选择将白嫖进行到底咯～ 建立Githu ...

刚开始时候博客部署在Github Pages上面，当时感觉用了github的托管就没啥归属感。再接着使用rsync将github action生成的public文件夹同步到国内云服务器的caddy服务器里面，使用自己的服务器域名，但是rsync这个方案不太优雅每次部署时阿里云都会有访问告警。现在自己的k3s集群起来了一切就好说了。 主要的想法是CI部分依旧白嫖github，将编译好的网站文件夹连同caddy服务器打包成docker镜像，依靠Helm3实现CD。 这里先放出完整的github ci文件 The deploy_hexo updated at: 2022.08.01 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556name: deploy_hexoon: push: branches: - hexo # default branchjobs: deploy_hexo: runs-on: ubu ...

前文安装k3s时禁用了traefik，之前在实习的时候公司自研SaaS平台就用了consul服务发现配合traefik路由的结构，整体感觉下来微服务后端的发现与治理无需太多人工干预，且这两个安装也很简单，体验确实不错。不过本系列没有那么重的需求，且ingress-nginx功能更多的说～ helm配置 helm简而言之就是k8s的模版仓库。helm v2需要在目标集群里安装Tiller，在越来越大的云环境下导致了越来越多的安全问题，所以在v3版本就没有Tiller这个东西了，配置也是简单到只需要搞定本地的kubeconfig文件再安装个helm v3命令行工具就可以了。Mac直接使用homebrew即可： 1brew install helm 提一嘴，helm指向的集群是和本机kubectl指向的是一样的～所以切换集群就是直接切换kubectl的context即可。 安装ingess-nginx helm部署很简单，按照这里的知道就行。首先添加repo并更新： 12helm repo add ingress-nginx https://kubernetes.github.io/in ...

本文章代理仅作为获取镜像使用！其他一切概不负责，不提供技术支持、镜像加速等服务！ 直接简单的方法就是搞个魔法服务器，自己部署registry，详细过程参考这位大佬的教程Docker 镜像加速教程，自己也参考了很多非常感谢🙏。然后我们来说一说穷人的解决方法！经过实际测试发现由Docker出品的registry是可以通过http_proxy和https_proxy两个环境变量进行代理的，所以方法也就不言而喻了。但是为了解决DNS污染和实现Docker部署，还需要做点小改动：简单来说就是利用容器编排工具启动两个container，一个运行register，另一个运行提供代理的软件；最后通过反向代理将服务暴露出去并提供自动https等功能。 本blog完整的代码位于github，觉得可以的话给个小星星也好～ proxy部分 clash直接提供了容器部署，并且也有网页版的dashboard容器，支持所需要的代理类型，所以直接拿来使用。刚开始测试的时候使用docker内部DNS来访问clash容器，不知道为什么及其不稳定，并且考虑到还有使用clash的dns服务器的需要，就直接为clas ...