这里以 debian 为例子, 一般能够看到为了国内源从而配置修改相关的 sources.list 等文件, 目前有以下集中源配置:
sources.list: 直接源配置
DEB822: 新的安全配置源
比如下面的的源格式:
123456789# sources.list 经典的远程源配置deb http://mirrors.ustc.edu.cn/debian trixie main contrib non-free non-free-firmware# DEB822 格式远程源配置, 追加 gpg 签名做安全验证, 'SignWith: no' 代表不启用签名验证 Types: debURIs: http://mirrors.ustc.edu.cn/debianSuites: trixie trixie-updatesComponents: main contrib non-free non-free-firmwareSigned-By: /usr/share/keyrings/debian-archive-keyring.gpg
如果要自己做内网二进制打 ...
之前公司内部都是采用 Gitea 做自己平台的内网脱管, 但是自从 Gitea 被其他公司收购后为了避免后续的商业纷争,
原版本 Gitea 额外分出 Forgejo 这个开源分支.
官方网站: forgejo
这里还是需要说明下个人的 Git 自托管服务系统配置:
系统: 主流 Linux 发行版(Ubuntu 22.04/Debian 12/CentOS Stream 9 以上版本等)
硬件: 最低 1GB 内存, 1 CPU 核心, 10GB 磁盘(生产环境建议 2GB+ 内存,当然内存越大越好)
网络: 服务器需开放 22(SSH, 可以自定义端口设定), 80(HTTP)|443(HTTPS),3000(Forgejo 默认端口)端口
依赖: Git(必须), 数据库(可选,SQLite/MySQL/MariaDB/PostgreSQL), Docker(采用容器部署才需要)
这里采用 debian/ubuntu 系统搭建, redhat 系的搭建方式可能有所不同
首先是必须要的组件, 我这里采用的 MariaDB 数据库配置:
123456789 ...
这里主要讲解的是 WebDAV 服务, 主要核心作用是让客户端(电脑|手机|服务器)
通过网络远程访问/编辑/管理服务器上的文件,和传统的传输功能相比较如下:
协议类型
全称
核心用途
适用场景
特点(优势/劣势)
与 AI 部署的适配性
WebDAV
Web-based Distributed Authoring and Versioning
基于 HTTP/HTTPS 的通用文件访问
跨平台(Windows/Mac/Linux/手机)、公网访问、目录挂载、实时协作
优势:无客户端依赖、支持 HTTPS 加密、穿透防火墙、可挂载为本地目录;劣势:传输速度中等、大文件断点续传支持一般
✅ 高(跨设备共享模型/知识库、无需重复存储、安全公网访问)
SMB
Server Message Block
局域网文件共享(Windows 默认)
家庭/办公局域网、Windows 为主的环境、高速文件传输
优势:速度快、支持文件锁/权限控制、大文件传输稳定;劣势:公网访问不安全(需额外加密)、Linux 兼容性一般
✅ 中高(局域网内 Windows/Mac 访问服务器模型/数据集 ...
一般来说个人部署 AI 服务是及其耗费时间和精力(还有可怕的满载电量和噪音), 但对于小规模的个人来说,
利用闲置的服务器设备部署个小型 AI 服务作为个人资料库其实也可以稍微玩玩.
而个人部署就推荐采用 ollama 来搭建, 按照官方文档来说其实最简单是采用 docker,
不过我这边本身就是闲置硬件也就是总结采用二进制安装部署就行, 不需要在套一层 docker 镜像.
注意: 本文涉及的很多网络相关可能需要 ‘工具’ 来处理, 否则网速基本上很慢没办法快捷部署
这里采用 ollama-linux 安装方式处理:
12345678910111213141516171819202122232425262728293031323334# 如果之前安装过, 需要手动先卸载清空, 执行以下命令cd /tmp # 现在临时目录, 二进制差不多2G左右sudo rm -rf /usr/lib/ollama# 下载安装 ollama 应用# 需要注意这里安装的是 amd64 的架构, 如果你是 arm64 架构需要换成 ollama-linux-arm64.tgz# 这里的安装包差不多 ...
Nginx 的 fancyindex 是一个第三方模块, 用于美化 Nginx 默认的目录索引页面;
默认的 Nginx 目录索引页面样式简陋, 而 fancyindex 模块提供了更美观的布局/文件图标/排序功能/面包屑导航等特性.
nginx-rtmp-module 这个模块目前各大发行版都放置在 nginx-extras 包之中, 这里以 debian 服务器为主:
123456789# 安装 Nginx 及其第三方扩展sudo apt install nginx nginx-extras# 具体确定是否存在 nginx-rtmp-module 模块可以输入以下指令确实是否有输出ls -l /usr/share/nginx/modules/ | grep ngx_http_fancyindex_module# 这里最好删除掉默认 nginx 的 80 监听, 不知道为什么配置好 fancyindex 会出现报错sudo rm /etc/nginx/sites-enabled/default sudo rm /etc/nginx/sites-available/default
如果 ...
自 php7 之后的 php 服务是我见过最便捷的部署方式, 基本上用自带的源安装就能处理完所有步骤:
1234567891011121314151617# 直接首先安装应用和 fpm 解析程序, 同时建议安装的组件sudo apt install php php-fpmsudo apt install php-intl php-mysql php-redis php-curl php-mbstring php-dom php-gd php-zip# 现在很多发行版默认安装 php 会自动帮你安装 apache2 这个 Web 服务# 这个服务会和 Nginx 之类产生占用冲突, 所以建议关闭掉# 如果没有这些服务单元就不用管sudo systemctl stop apache2.service # 关闭服务sudo systemctl diable apache2.service # 禁止开机自启动# 启动解析服务, 这里后续发行版都带 php{版本号}-fpm.service 启动# 具体需要看默认源安装的版本号, 我这边默认安装的 php8.2 版本sudo ...
借助其赛博菩萨 Cloudflare 的 Workers 实现动态 IP 与域名的自动绑定, 简单来说就是只需要域名就能将本地宽带内部服务暴露到公网,
并且还同时享受到 Cloudflare 的CDN|DDoS防护|IP代理隐藏等额外优势, 仅仅只需要把域名移交给 cloudflare 管理.
这里首先就是需要以下条件:
cloudflare 账号: 官网地址
cloudflare 托管的域名: 不要用国内的任何域名, 因为国内可能需要做网证等验证
一台能够持续运行的 linux 服务器
这里依赖 Cloudflare Zero Trust, 其实就是要求本地局域网运行的 Cloudflare 守护程序,
与 Cloudflare 云端通信, 从而将云端请求数据转发到本地网络的 IP + 端口.
通过依赖 Cloudflare Tunnel 业务实现内网穿透, 但是国内特殊国情, 可能在国内访问速度不快并有断流的情况发生
上面提到的国情问题导致实际上体验方面可能很不好, 所以如果想长期稳定使用还是要购买公网IP服务.
另外需要说明下的是启用 Cloudflare ...
目前 Linux 发行版都集成 SystemCtl 做系统管理, 现在如果要把二进制应用写入成系统应用基本上绕不开.
Systemctl 的服务基本可以分为以下类别:
service: 常规服务
timer: 定时器
mount: 挂载点
device: 设备
socket: 套接字
这里先从基础的自定义 service 编写服务开始:
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142 ...
日常使用自动化脚本的时候常常会出现这种问题: 如果创建专用系统账户如果执行系统服务命令要么需要 sudo 输入密码, 要么就是无法使用命令
像是这种情况在日常当中也是十分常见, 好处也是很明显直接低配权限防止被入侵的时候完全掌控服务器:
123456# 如果想以非 root 用户重启 nginx, 以下命令是无法生效# 如果你的用户组正好是 sudo 组, 则会提示你必须手动输入用户密码确认启动systemctl restart nginx# sudo 组则是需要通过以下方式sudo systemctl restart nginx
但是在自动化运维的时候就很麻烦了, 引入不可能调用这些命令还要让你手动输入密码, 毕竟都自动化了肯定不能这样操作
所以这里就衍生出 visudo 和 NOPASSWD 概念, 通过配置可以让指定用户或用户组执行 sudo 命令时无需输入密码:
12# 进入 sudo 配置菜单, 注意调用的默认编辑其是 nano 而非 vi/vimsudo visudo
这里内部每一行就是定义权限:
12345678910username ALL=(ALL) NOPASSW ...
Cockpit 是开源的 Linux 服务器图形化管理工具, 专为简化服务器运维工作设计, 适合中小规模环境搭建使用.
一般用于常规 nas 或者 10 台服务器管理规模这类日常服务器运维
基本上主流的 Linux 都集成在包管理之中, 直接运行以下命令就可以安装:
12345# debian 系sudo apt install cockpit# redhat 系sudo yum install cockpit
默认启动的服务端口为 9090
cockpit 并不是 EXSI 和 PVE 这种专门虚拟化管理那种专业化的虚拟化平台, 仅仅是作为界面化运维管理;
同时也不具有底层系统级别的管理能力, 且不具有大规模服务集群的能力.
不过如果只是想单独简单管理几台容器化服务, 利用 cockpit 反而更加轻量而无须对系统整个重新构建.
cockpit-machines 只能间接管理 KVM 虚拟机, 仅支持基本的启停|创建, 没有快照|克隆|高可用方案
如果是小规模(5台)服务器范围且不需要快照备份功能, 只需要对应 cockpit 就足以满足.
系统级别虚拟化带来的问题就是 ...








