抛开场景谈需求都是耍流氓

1. 大部分时候，我们只能从客户那边拿到一个端口号
2. 一个端口便于管理
3. 私有桶，公开桶不需要做这样的设置
4. 下载上传不受影响，因为是后台对后台，通过 docker 的 servername:端口直接访问的
5. 前端直接调用 minio 的服务预览会有问题

环境

使用 docker-compose 编排的 ruoyi-vue-plus 环境，并且使用 minio，假定客户访问的地址或者域名是 example.com，想要实现的效果是

1. example.com/web 访问 web 前端
2. example.com/ 下的其他请求请求转发到后台
3. example.com/minio-ui 转发到 minio 的web 控制台
4. example.com/minii-* 其他请求转发到 minio 的 api

做法

这里docker-compose 具体写法就不贴了，假定 minio 在 docker-compose 中的名称就叫 minio

1. 配置 /minio-ui/ 的请求，到 minio 的控制台，这一步比较简单
2. 配置 ^~ /minio- 的请求，转发到 api 端口

[……]

继续阅读

场景

项目发布中，不同客户很多时候是由分支来管理的，但同时也存在很多用标准产品的客户，就会出现同一个分支不同时间的代码出现在不同的客户那边。

但是在发布很久之后可能需要修复某个 bug，这时候是不需要部署最新代码的（避免出现新问题），所以要找到当时发布时那个节点的代码，对应修复部署即可。

之前的做法是在发布的时候，打个 tag，但有时候容易忘记，并且也会导致 tag 太多混乱

解决办法

git-commit-id-maven-plugin 插件

找到一款叫做 git-commit-id-maven-plugin 的插件，可以很方便的将当前编译的时间、分支信息加入到文件中，使用方法也很简单。

github 主页：https://github.com/git-commit-id/git-commit-id-maven-plugin

pom.xml 集成插件

注意，这里的 groupId 和 artifactId 会根据 jdk 版本不同而有不同的写法，下面这种写法是 jdk8 的写法，具体请参考 github 中的使用方法

<plugin>
    <groupId&gt[......]
继续阅读

总所周知，Chrome 的地址栏搜索框的历史记录是臭名昭著的存在，但是一直没找到办法去删除或者屏蔽，只要在地址栏搜索过任何信息，打开新标签页，都会自动弹出，让人十分反感。

之前用过一个扩展，叫做 HCOS – Hide Chrome Omnibox Suggestions，但是最近在升级 Chrome 之后，以“此扩展程序未遵循 Chrome 扩展程序的最佳实践，因此已无法再使用。”为理由提示不能再使用，不小心删除了。

找了好久，终于找到一个离线版本的，通过 Chrome 开发者模式加载进来，那清爽的地址栏又回来了。

原扩展地址：
https://chromewebstore.google.com/detail/hcos-hide-chrome-omnibox/aldijnffnfojelcpcfoekkeifffkhldo

HCOS扩展离线下载地址 （需要右键另存为下载）

[……]

继续阅读

场景

项目中需要有 Excel 或者 Word 文档导出功能，但是很多用户希望能在导出前做个预览，想着导出功能本身就做好了，就不想再做个前端预览功能了，而且也不通用，所以就想着直接预览将要导出的文件即可

kkFileView

这个软件本身就是开源的，符合要求，也支持本地文件、远程文件、文件输出流

部署过程

这里只讲写怎么用 docker 进行部署

1. 我这边用的是 4.3.0的镜像文件，使用 docker load < 镜像文件命令，把镜像导入到系统中

2. 准备字体文件
   大部分的情况都会出现预览中文乱码的情况，基本都是字体问题，一下是官方解决方案

   大部分Linux系统上并没有预装中文字体或字体不全，需要把常用字体拷贝到Linux服务器上，具体操作如下： 下载如下字体包 https://kkview.cn/resource/fonts.zip 文件解压完整拷贝到Linux下的 /usr/share/fonts目录。然后依次执行mkfontscale 、mkfontdir 、fc-cache使字体生效

   2. 启动容器
      2.1

      docker run -it --name kkfilev[......]
      继续阅读

docker镜像极致压缩（二）

之前在一篇文章中提到 如何在编译镜像的时候尽量缩小镜像的体积 以用于网络传输，这次在构建另一个镜像的时候，采用了更为激进的办法，直接将原来4G的镜像，缩小到了1G左右，压缩更明显，图片见对比。

抛开场景谈需求都是耍流氓

1. 原来的镜像用了很多年了，且是基于 CentOS 7 为基础的，早就不维护了，现在各甲方对这方面越来越注重
2. 各种库的版本很低，同1
3. 原来的镜像各种乱七八糟的软件安装了一大堆，导致体积很大，docker images 有4个多G，压缩后还有2G多，传输难

为什么不使用 docker-compose ，为什么要把这些软件全部安装到镜像内，这里就不作过多讨论了

直接开整

总的来说，就是2点，分别是：

• “阅后即焚”
• “一次操作”

这两点都很好理解，阅后即焚，是在之前聊过的减少层数这个基础上，把每一层创建好之后，不需要的东西删掉，因为一层的内容创建好之后，体积就相对固定了，下面一层再去删除，是无法改变原有镜像大小的，例如，通过FROM ubuntu:22.04来使用ubuntu的镜像，然后在接下来编译的过程中，删除镜像的文件，并不会对最[……]

继续阅读

抛开场景谈方案都是耍流氓

项目中使用了emqx来对硬件进行管理和状态数据的更新，但由于错误的使用姿势，导致在某个项目中，硬件设备超过了500个后，后台服务器接收处理mqtt的消息达到了惊人的2分钟延迟。

而项目甲方的服务器问题，导致无法修改emqx的配置来进行调优，流程特别繁琐，而且在调整过程中需要不断尝试。

所以就尝试在后台服务代码层面解决问题。

分析

当前场景为：
有A、B、C、D 等n个设备，后台服务器订阅了所有设备的所有topic，每台设备在数秒内会上报一条状态消息，由后台服务器处理、存档，并且将设备最新的信息，再发回设备端，另外需要在 A 设备上展示 B、C、D等设备的状态，同时A设备操作B设备的开、关门的业务。

有一天发现，当B设备开关门后，或者A指令B开门后，需要长达2分钟才能响应，在跟踪代码之后，发现了项目中错误的使用姿势，例如mqtt服务不止用来做状态更新上报等，还在请求中加入了大量的数据，又或者过分依赖mqtt的消息来做业务处理。

改进

在查阅文档，以及做了很多测试后，发现一开始对emqx的订阅有一些误解，原以为它的客户端（org.eclipse.paho.clie[……]

继续阅读

抛开场景聊需求都是耍流氓

在很多企业和高校内做私有化部署的服务的时候，信息中心都会给一台服务器，不管是虚拟机或者是实体机，都会定期做漏洞扫描，每次一扫出来，都是很多漏洞，要求中高风险的漏洞必须修复，否则谁没事去搞这玩意呢。

比较麻烦的是，这些服务器大多都是纯离线，利用VPN、跳板机、远程桌面进行访问的，这无疑给软件升级带来了很多麻烦。

这次需要升级的内容是OpenSSH，为什么有这篇文章，因为我参考了很多文章，内容很多都不一样，有点连版本号也没有，都是拼拼凑凑来实现的，所以在这里做个记录

步骤

安装Telnet

为了确保在升级过程顺利，最好安装一个Telnet服务，来确保后续可以继续操作，否则一旦服务器失联，一定是一件头皮发麻的事情。

1. 下载以下文件上传到服务器：
   参考了文章: https://lblog.net/?p=282 但是此站点现在已经无法访问

   telnet-0.17-65.el7_8.x86_64.rpm
   telnet-server-0.17-65.el7_8.x86_64.rpm
   xinetd-2.3.15-14.el7.x86_64.rpm

2. 安装以上文件

   rp[......]
   继续阅读

抛开场景聊需求都是耍流氓

在目前网络环境这么好的情况下，大文件传输似乎已经没有什么问题了，动辄上G的文件传起来也不在话下，在这个场景下，再大的镜像体积，看起来也没什么问题。我这个镜像体积也不算过分，但是需要通过微信传输 – SVN推送 – SVN下载 – 镜像推送 – K8S 部署这几个步骤，一整套下来也确实挺浪费时间的，而且都是通过公网传输，在没有办法改变流程的情况下（客户要求，无解），尽量缩小镜像体积，会提高很大的效率。

早期的镜像

最早的镜像和最新的镜像体积差别,<none>是不断更新过程中被覆盖的

可以先用 docker history 命令看下镜像的构建步骤，可以简单理解成构建了多少层，这是原来刚开始构建镜像的时候写的Dockerfile，在构建过程中，步骤达到了30+，很多RUN操作虽然不会增加体积，但是无形中增加了很多镜像的 layer ，积少成多，会影响构建的效率。

另外还有几十甚至是几百兆的体积增加，最好都尽量避免掉

早期镜像的history

现在的镜像

优化之后的镜像history

优化方法

由于 Docker 镜像构建，就像它的名字[……]

继续阅读

不要折腾

最为一个新手，最近搞了一台J4125的机器，装了一个iStoreOS，来体验了一下所谓的轻NAS，里面放一些个人网站、Jellyfin、备份和私人ChatGPT服务，感觉还是非常不错，机器性能也还过得去，但是外网访问是个问题，还没有公网IP，所以有诸多不便，单纯Web服务的话，可以考虑FRP内网穿透，但是对于文件和媒体服务，对FRP的带宽要求就显得高了，所以就另寻蹊径了，看看能不能用IPv6。

抛开环境谈配置都是耍流氓

电信 F450G ZTE的光猫
TP-LINK XDR5430 路由器，升级官方系统到最新版，含防火墙开关
J4125 小主机

一开始比较当心会搞坏网络影响家人上网，所有没有将小主机作为软路由或者旁路由，仅仅作为一个普通的小主机，iStoreOS称为轻NAS

搞定光猫

很久之前通过网上的一些方法，搞到了超管密码，但是后来好像被远程关闭了（光猫是可以被远程控制的，尴尬不尴尬），找密码的办法是（仅在网上的那些192.168.1.1后面加各种后缀无效可尝试，谁不想简单点呢）：

0. 准备好你的网络宽带账号、密码、宽带识别码（LOID ）等信息

1. 拔掉光信号线，捅 R[……]

   继续阅读

为什么有这个标题

在规划客户需求的时候，看到了一个叫 AIChatWeb 的 开源 软件，为什么有删除线呢，因为我也不知道它到底是不是开源的。我习惯性的看了仓库中的README，这个软件是根据 https://github.com/Yidadaa/ChatGPT-Next-Web 这个项目延伸的，开发出了一个SpringBoot的后台，和一个Vue的前端，来管理页面title、api key以及销售套餐之类的项目。

我大概看了下之后，下意识的认为这个项目前后台都开源，并且在README中也找到了后台地址，但是是一个空仓库，在部署完demo后，发现这个项目功能上还是基本吻合的，准备做二次开发，所以我就加群准备问下如何获得源码以及费用问题（实际上我这是个赚钱的项目，是做好了付费的准备，无非多赚少赚的问题）：“你好，想请问这个项目的后端模块是否开源或者是付费获得”，没想到却得到一些“没有开源计划”、“编外人员开源有什么好处”、“白嫖用户洗洗睡吧”、“先买pro版再提问”之类的傲慢回复，所以然后就没有然后了，我就离开了。

然后一直到现在，在GITHUB仓库中，仍然没有明确表示后台不开源，也仍[……]

继续阅读