Nginx Proxy Manager修复笔记

更新于 分类于 阅读次数： 阅读时长 ≈ 47 分钟
排查Nginx Proxy Manager，反向代理，让网站变成HTTPS

有什么用

排查Nginx Proxy Manager，反向代理，让网站变成HTTPS

实现方法

Nginx Proxy Manager 登录异常
http://192.168.6.116:881/login

11am NPM, 登录失败错误：Bad Gateway
    template-db-1	已停止	jc21/mariadb-aria:latest	
发现是附属的docker的"/template-db-1" 启动失败
- 修复？

2023-11-03  3:13:28 0 [Note] /usr/bin/mysqld (mysqld 10.4.15-MariaDB) starting as process 1 ...
2023-11-03  3:13:28 0 [ERROR] mysqld: Can't create/write to file '/var/lib/mysql/aria_log_control' (Errcode: 13 "Permission denied")
2023-11-03  3:13:28 0 [ERROR] mysqld: Got error 'Can't create file' when trying to use aria control file '/var/lib/mysql/aria_log_control'
2023-11-03  3:13:28 0 [ERROR] Plugin 'Aria' init function returned error.
2023-11-03  3:13:28 0 [ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed.
2023-11-03  3:13:28 0 [Note] Plugin 'InnoDB' is disabled.
2023-11-03  3:13:28 0 [Note] Plugin 'FEEDBACK' is disabled.
2023-11-03  3:13:28 0 [ERROR] Could not open mysql.plugin table. Some plugins may be not loaded
2023-11-03  3:13:28 0 [ERROR] Failed to initialize plugins.
2023-11-03  3:13:28 0 [ERROR] Aborting

可能是从因为Nginx Proxy Manager是通过docker-compose来运行的，断电重启以后，docker无法自动正确地按docker-compose来启动了。
解决办法是
1. 关闭这个两个docker容器（jc21/nginx-proxy-manager:latest	和 jc21/mariadb-aria:latest）
2. SSH去执行
    # cd /www/server/panel/data/compose/NginxPorxyManager/template
    # docker-compose up -d
这就意味着以后，以后机器重启，都要去手动去执行这docker-compose，有没有更好的解决办法？
解决了docker启动，登录NPM还是提示：Bad Gateway错误
检查了docker ps，依旧Restarting (1) 28 seconds ago  template-db-1

2:20pm
Docker 具体错误

1
2
3
4
5
6
7
template-db-1   | 2023-11-03  6:20:19 0 [ERROR] Plugin 'Aria' init function returned error.
template-db-1   | 2023-11-03  6:20:19 0 [ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed.
template-db-1   | 2023-11-03  6:20:19 0 [Note] Plugin 'InnoDB' is disabled.
template-db-1   | 2023-11-03  6:20:19 0 [Note] Plugin 'FEEDBACK' is disabled.
template-db-1   | 2023-11-03  6:20:19 0 [ERROR] Could not open mysql.plugin table. Some plugins may be not loaded
template-db-1   | 2023-11-03  6:20:19 0 [ERROR] Failed to initialize plugins.
template-db-1   | 2023-11-03  6:20:19 0 [ERROR] Aborting

最后方案：放弃视频‘推荐’的方案，改用默认的sqlite.

4:46pm NPM
改了配置以后，服务都正常了；可是新的配置在UI上没有加载之前的的配置内容。
不配置maradb db section, NPM会自己在保存在./data目录下面一个database.sqlite文件数据库。
5:10pm Cloudflare API token 重新配置
dns_cloudflare_api_token e385e19ce47c207b15bf@@@@@
重新申请证书，用DNS challenge的方式。 

接下来，新的反代的就直接去新建就好了（待验证）
》5:17pm

安装目录：/www/server/panel/data/compose/NginxPorxyManager/template

如何编辑artalk的robots.txt

收到Google的邮件（New reason preventing your pages from being indexed）
第二天根据链接里面的indexing report，转到问题的问题；之前还去主站点位置添加的www.carlzeng.top/robots.txt.
原来是报告https://artalk.carlzeng.top:4443/robots.txt 这个页面下的。

在artalk容器以及映射出来的目录找了半天也找不到这个文件，莫非是程序动态生成的（无解了？）
也可能是NPM的反代有这样的设置?
https://www.iots.vip/post/hexo-artalk-comment.html

在BT中，/www/server/phpmyadmin/phpmyadmin_c123@@/目录下，搜索到了robots.txt, 修改内容为：
User-agent: *
Allow: /
继续访问https://artalk.carlzeng.top:4443/robots.txt；仍然无效
尝试修改NPM中关于artalk反代的nginx配置文件，参考博客样式
location =/robots.txt {
default_type text/html;
add_header Content-Type “text/plain; charset=UTF-8”;
return 200 “User-Agent: \nAllow: /“;
}

12:56pm NPM配置好的一个个host，被保存在了debian映射出来的那个目录？
原来都保存在了 docker-compose.yml 的目录下，
/www/server/panel/data/compose/NginxPorxyManager/template/data/nginx/proxy_host#

  1. 修改配置nginx问题 root@Debian11:/www/server/panel/data/compose/NginxPorxyManager/template/data/nginx/proxy_host# vi 1.conf

  2. 重启NPM docker-compose
    root@Debian11:/www/server/panel/data/compose/NginxPorxyManager/template# docker-compose restart

  3. 验证 https://artalk.carlzeng.top:4443/robots.txt
    User-agent: *
    Allow:/
    Works perfect

灵感来源：
如果需要 Nginx 反向代理， 这里提供一份 Nginx 配置参考
https://zh.wikipedia.org/zh-tw/Robots.txt

Debian 11的一些基础

Debian 11默认是关闭ssh的，如何开启？设置了自动开启，断电重启就无忧
    旧方案是：在BT面板中开启SSH开关，然后用carl用户登录进ssh，在su，就可以到root用户下
    新的：
        算了，为了debian11安全，就不开放ssh了；走面板，或者pve终端的ssh


artalk docker 没有自动重启，如何设置特定的docker自动重启？假设机器死机需要断电重启
    手动重启成功

缩短URL之简化4443端口成3端口

尝试在NPM的docker把443映射成4443，同时增加了映射到3（后来发现这个步骤是可选的）

原来仅需要在OP上，把3端口映射给重复的内部端口4443即可。
https://c.carlzeng.top:4443/tv
https://c.carlzeng.top:3/tv

Docker端口映射之一对多的几种情况

  1. 端口多对一，可行：访问宿主的多个端口可以映射到容器中的同一个端口。
    1
    # docker run -d -p 9000-9001:9000 tomcat:8.5-jre8
  2. 多对多的几种情况 9000-9001:9000-9001 可行
    1
    # docker run -d -p 9000-9001:9000-9001 tomcat:8.5-jre8

NPM弊端？

不知为何本地局域网可访问的http://192.168.6.116:881/ 无法映射代理到外网，来实现npm自己代理自己的目标。

真是奇怪，https://npm.carlzeng.top:4443/ 更可能是NPM自己做了什么设置？无法自己代理自己的web管理服务？

2023年12月初：解决办法：用在线云浏览器Firefox，远程过去访问本地局域网的NPM面板即可

Mamoto面板反代以后无法正常登录，也请使用在线云浏览器Firefox

J4125 pve半死状态

这种状态大约半个月左右出现一次；难受；这次是（已启动13天1小时20分57秒）

现象：

  1. 各个设备终端上网正常

  2. 画面卡死，无法登录 http://192.168.6.116:881/nginx/proxy

  3. SSH可以到达192.168.6.1

    1. web到OP也正常

  4. 无法连接pve https://192.168.6.2:8006

    1. This site can’t be reached192.168.6.2 took too long to respond.

  5. SSH无法到达bebian .116的

    1. kex_exchange_identification: read: Operation timed out
      banner exchange: Connection to 192.168.6.116 port 22: Operation timed out

  6. metaUI无法正常打开，http://192.168.6.116:9090/#/overview

    1. This site can’t be reached192.168.6.116 took too long to respond.

  7. StatCount 无法正常打开，http://192.168.6.116:8597/index.php?module=CoreHome&action=index&idSite=1&period=day&date=yesterday#?period=day&date=2023-12-01&idSite=1&category=Dashboard_Dashboard&subcategory=1

    1. This site can’t be reached192.168.6.116 took too long to respond.

  8. IPNAS 无法打开http://192.168.6.203:5000/

    1. 奇怪的是：用手机可以正常打开；反复测试中

  9. NAS中的docker Aria2 可以正常使用 https://aria2.carlzeng.top:4443/#!/downloading

  10. Debian clash 的 7890无法正常使用

  11. Debian

    1. artalk 正常
    2. bt 无法连接web
    3. dujiaoka正常https://buy.carlzeng.top:4443/
    4. Yourls正常https://c.carlzeng.top:3/admin/index.php
      1. Yourls后台可以正常登录查看https://c.carlzeng.top:3/admin/index.php
    5. metaUI又能正常打开了，http://192.168.6.116:9090/#/overview
      1. 可是，仍然无法连接到http://192.168.6.116:9091
    6. NPM无法正常打开http://192.168.6.116:881/nginx/proxy
    7. Hnet Web首页正常了https://proxy.carlzeng.top:4443/
    8. 电脑端的statcounter无法打开，可是手机端（在系统中）可以正常查看各种信息
      1. 奇怪

  12. 20231204昨天没有重启，后来自动就恢复了；今天又假死了

    1
    2
    nc -vz 192.168.6.116 881                                                                              
    nc: connectx to 192.168.6.116 port 881 (tcp) failed: No route to host

PVE, 以及PVE中的docker debian，NAS都下线了

可是OP还活着，一直充当主路由的工作

稀奇的是手机确可以ping通192.168.6.116；这简直无法理解

手机端也是无法打开NPM的881端口，可是matomo可以正常使用

重启一下MAC电脑，重新测试

重启MAC，链接NPM又正常了！pve又可以链接了; 原来问题的根源不是在J4125；汗，而是在用来发现问题的MAC上，引以为戒。下次核查的时候要多设备核实（才能去硬重启J4125）

跳闸后J4125通电未正常启动

J4125断电后无法启动，
导致K2P无法正常获取192.168.6网段的IP地址；（获取的169.254.12.86不正常IP）
整个本地局域网瘫痪。

理清楚，如果J4125小主机无法启动，要怎么调试？
有没有画面输出？如何输出画面；
答：通过连接HDMI的液晶显示器，在连接USB键盘操作

目前J4125 和 K2P是怎么连接工作的？

目前J4125的网口分配情况？

如何调试？调整K2P的设置？连接端口？
答：通过连接HDMI的液晶显示器，在连接USB键盘操作

J4125进入命令行模式（由于WEB控制没有启动，无法远程。需要借助显示器和键盘）

一种pve的命令行模式，好像输出startup.sh的倒计时（由于无显示器，进入命令行模式后，通过WEB只能判定其属于无法启动或死机状态）

无意间通过输入help（很多命令，但大部分一闪而过，无法使用 ｜more来暂停；不知道怎么慢慢输出所有的help内容）和 exit命令，退出了这个命令行模式；系统正常启动成功，所有虚拟机和docker，启动成功。

目前启动状态（这也是最干净的状态）：

image-20240325091403026

解决Debian异常

Yourls、Matomo没有正常启动

pve中debian状态也正常，ping debian的IP是正常的。最终进入SSH，通过bt命令14，查看了面板地址。进入bt面板后，发现是mariadb没有正常启动，造成了特定的三个容器（Yourls、Matomo 和surveyking）因缺少数据库而无法正常运行。

解决办法：

ssh下进入目录进行docker-compose down 和 docker-compose up

查看日志发现Permission denied错误

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
yourls_mysql    | 2024-03-25 01:34:54+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'          
yourls_mysql    | 2024-03-25 01:34:54+00:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:11.2.2
+maria~ubu2204 started.                                                                                       
yourls_mysql    | 2024-03-25 01:34:55+00:00 [Note] [Entrypoint]: Initializing database files                  
yourls_mysql    | 2024-03-25  1:34:55 0 [Warning] Can't create test file '/var/lib/mysql/d6741f2674af.lower-te
st' (Errcode: 13 "Permission denied")                                                                         
yourls_mysql    | /usr/sbin/mariadbd: Can't change dir to '/var/lib/mysql/' (Errcode: 13 "Permission denied") 
yourls_mysql    | 2024-03-25  1:34:55 0 [ERROR] Aborting                                                      
yourls_mysql    |                                                                                             
yourls_mysql    | Installation of system tables failed!  Examine the logs in                                  
yourls_mysql    | /var/lib/mysql/ for more information.                                                       
yourls_mysql    |                                                                                             
yourls_mysql    | The problem could be conflicting information in an external                                 
yourls_mysql    | my.cnf files. You can ignore these by doing:                                                
yourls_mysql    |                                                                                             
yourls_mysql    |     shell> /usr/bin/mariadb-install-db --defaults-file=~/.my.cnf                            
yourls_mysql    |                                                                                             
yourls_mysql    | You can also try to start the mariadbd daemon with:                                         
yourls_mysql    |                                                                                             
yourls_mysql    |     shell> /usr/sbin/mariadbd --skip-grant-tables --general-log &                           
yourls_mysql    |                                                                                             
yourls_mysql    | and use the command line tool /usr/bin/mariadb                                              
yourls_mysql    | to connect to the mysql database and look at the grant tables:                              
yourls_mysql    |                                                                                             
yourls_mysql    |     shell> /usr/bin/mariadb -u root mysql                                                   
yourls_mysql    |     MariaDB> show tables;                                                                   
yourls_mysql    |                                                                                             
yourls_mysql    | Try '/usr/sbin/mariadbd --help' if you have problems with paths.  Using                     
yourls_mysql    | --general-log gives you a log in /var/lib/mysql/ that may be helpful.                       
yourls_mysql    |                                                                                             
yourls_mysql    | The latest information about mariadb-install-db is available at                             
yourls_mysql    | https://mariadb.com/kb/en/installing-system-tables-mysql_install_db                         
yourls_mysql    | You can find the latest source at https://downloads.mariadb.org and                         
yourls_mysql    | the maria-discuss email list at https://launchpad.net/~maria-discuss                        
yourls_mysql    |                                                                                             
yourls_mysql    | Please check all of the above before submitting a bug report                                
yourls_mysql    | at https://mariadb.org/jira                                                                 
yourls_mysql    |                                                                                             
yourls_mysql exited with code 1

解决办法：授予mysql用户在目录下的执行权限/www/server/panel/data/compose/yourls_service/template/yMariaDb

解决mariadb启动正常后，访问yourls网页仍然错误

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
yourls_service  | 172.18.0.1 - - [25/Mar/2024:01:38:29 +0000] "GET /admin/index.php HTTP/1.1" 403 521 "-" "Moz
illa/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/53
7.36"                                                                                                         
yourls_service  | [Mon Mar 25 01:38:29.171055 2024] [core:crit] [pid 23] (13)Permission denied: [client 172.18
.0.1:18438] AH00529: /var/www/html/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readab
le and that '/var/www/html/' is executable                                                                    
yourls_service  | [Mon Mar 25 01:38:29.208916 2024] [core:crit] [pid 24] (13)Permission denied: [client 172.18
.0.1:18450] AH00529: /var/www/html/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readab
le and that '/var/www/html/' is executable, referer: https://c.carlzeng.top:4443/admin/index.php              
yourls_service  | 172.18.0.1 - - [25/Mar/2024:01:38:29 +0000] "GET /favicon.ico HTTP/1.1" 403 521 "https://c.c
arlzeng.top:4443/admin/index.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, 
like Gecko) Chrome/122.0.0.0 Safari/537.36"                                                                   
yourls_service  | [Mon Mar 25 01:38:29.737844 2024] [core:crit] [pid 25] (13)Permission denied: [client 172.18
.0.1:18464] AH00529: /var/www/html/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readab
le and that '/var/www/html/' is executable

解决办法：授予所有用户在目录下的执行权限777

/www/server/panel/data/compose/yourls_service/template/yourlsData20231229

yourls Docker启动修复

chown mysql /www/server/panel/data/compose/yourls_service/template/yMariaDb -R
chown mysql /www/server/panel/data/compose/yourls_service/template/yourlsData20231229 -R

chmod +777 /www/server/panel/data/compose/yourls_service/template/yMariaDb -R
chmod +777 /www/server/panel/data/compose/yourls_service/template/yourlsData20231229/ -R
cd /www/server/panel/data/compose/yourls_service/template
docker-compose down
docker-compose up -d

解决mariadb 和 应用程序的 Permission denied 错误

同上原理:

  • 将mariadb的目录授予mysql用户执行权限
  • 将应用程序的主目录授予所有用户执行权限777
1
2
3
#应用程序目录如果没有777权限，错误信息如下：
Matomo     | [Mon Mar 25 09:52:04.935003 2024] [core:crit] [pid 51] (13)Permission denied: [client 192.168.6.2。21:65111] AH00529: /var/www/html/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable
 and that '/var/www/html/' is executable, referer: http://192.168.6.116:8597/index.php

Matomo Docker启动修复

1
2
3
4
5
6
7
8
9
10
chmod +777 /www/server/panel/data/compose/matomo/matomo -R
chmod +777 /www/server/panel/data/compose/matomo/matomodb -R
	
chown mysql /www/server/panel/data/compose/matomo/matomo -R
chown mysql /www/server/panel/data/compose/matomo/matomodb -R

cd /www/server/panel/data/compose/matomo
docker-compose down

docker-compose up -d

chmod +777 /www/server/panel/data/compose/surveyking/mysql_data -R

cd /www/server/panel/data/compose/searx
chmod +777 searx/ -R
解决了docker启动错误

MAC清除+刷新DNS缓存

Mac OSX本机的DNS缓存误导了一些自定义域名的IP指向。

ping frp.carlzeng.top -c 3
PING frp.carlzeng.top (123.112.254.91): 56 data bytes
64 bytes from 123.112.254.91: icmp_seq=0 ttl=62 time=7.484 ms

发现是Mac OSX本机的DNS缓存误导了一些自定义域名的IP指向。

image-20240325105222077

ping frp.carlzeng.top -c 3
PING frp.carlzeng.top (123.112.254.91): 56 data bytes
64 bytes from 123.112.254.91: icmp_seq=0 ttl=62 time=7.484 ms

发现是Mac OSX本机的DNS缓存误导了一些自定义域名的IP指向。
10:51am dns问题依旧，


11:54am 突然frp的域名恢复了：
ping -c 3 frp.carlzeng.top
PING frp.carlzeng.top (221.218.236.157): 56 data bytes
64 bytes from 221.218.236.157: icmp_seq=0 ttl=64 time=2.954 ms

​

how to fix non-authoritative answer
似乎只有等待！（大约等了2小时）

优化：删除掉mail.carlzeng.top的A记录，因为*的A记录，会自动涵盖这一条A记录

修复DNS A记录

7:30pm 发现img.carlzeng.top仍然对应了错误的IP，导致上传图片出错

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
策略：
1. 反复的dig查询dig img.carlzeng.top
2. 更换本机DNS IP服务器地址
8:17pm dns的A记录依旧是错误的；即便更换了本机的DNS服务器到本地192.168.6.1 TTL越查询，数值越小；目前到了341; 猜测这个值越来越小的时候（到0），会主动向CF的根域名服务器查询；到那时，就会返回正确的IP。
8:19pm 
;; ANSWER SECTION:
img.carlzeng.top.       246     IN      A       123.112.254.91
8:21pm
img.carlzeng.top.       109     IN      A       123.112.254.91
8:22pm 自动变为41
8:22pm 自动变为19，然后9
8:23pm #重新返回到3600秒=1小时
;; ANSWER SECTION:
img.carlzeng.top.       3600    IN      A       221.218.236.157

# 也就是说DNS记录在自动循环着向主/根服务器查询A记录或更新，每个小时，不停递减后查询一次。

策略：

  1. 反复的dig查询dig img.carlzeng.top（检查ANSWER SECTION 中的TTL）

  2. 更换本机DNS IP服务器地址（切换以后，dig查询发现 TTL值，一直加快速度地变小，相对于不切换DNS服务器的情况下）

    Note： DNS记录详解 中详细讲解了TTL的含义及设计原理

DNS相关命令

dig命令：

  • dig img.carlzeng.top 查询DNS寻址过程
  • dig +short math.stackexchange.com 直接显示DNS寻址结果
  • dig @8.8.8.8 math.stackexchange.com 向特定DNS服务器寻址
  • dig ns com 查询com顶级域名的ns记录
  • dig a com 查询com顶级域名的a记录
  • dig -x 192.30.252.153 用于查询PTR记录（用IP查域名）

host命令：

  • host github.com 返回域名的各种记录
  • host 192.30.252.153 逆向查询IP地址对应的域名

nslookup命令：

  • nslookup github.com 查询域名记录

whois命令：

  • whois abc.com 查询域名的注册情况

K2P udpxy异常

ps 发现系统有：
441 admin 776 S /usr/sbin/udpxy -m br0 -p 8012 -B 65536 -c 10 -M 120

kill -9 441 后，运行
udpxy -p 8012

udpxy一切正常了；可以正常使用VLC播放：http://192.168.6.243:8012/rtp/239.3.1.158:8000

测试：

UI上看太玄学了，kill掉‘udpxy -p 8012’，重新检查ps中udpxy都消失后，重新提交IPTV页面一切正常了。

这导致每次重启K2P都需要运行 /usr/sbin/udpxy -p 8012

即便在自定义脚本》路由器启动后执行定义了 /usr/sbin/udpxy -p 8012 也不知道是否管用？

期待下一次的断电重启测试

无意间点进PVE，不看不知道，一看吓一跳：

原来很可能是pve的磁盘占用 96.69% (104.62 GiB的108.20 GiB）

我不知道/dev/sdb3(在SSD128上面, Reeinno CY128GB S1S3上面)为何就满了？里面放了什么了？
pve存储空间扩容 磁盘大小调整 proxmox6

采取措施（对debian和NAS）

​ docker volume prune
​ docker image prune

没招，找了一圈又一圈：没有找到解决办法。

尝试着把Win2008的备份10G的文件删除，PVE的使用率从96.69%降到87.55%。先用吧，观察着debian中docker的安装有没有占用这块128G的SSD盘？

答案是：有的，目前debian的数据还是没有被放到另外一块512的SSD上。2023.12.29

Linux 查看当前开放端口

在K2P的padavan或者openwrt里面都是适用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
netstat -nl

#tcpdump 不会用啊

#想要查看那些客户端连接了？
#通过padavan的UI查询：网络信息 > 流量监控https://k2pzl.carlzeng.top:4443/Main_BWMon.asp

找到了服务器上frps的192.168.6.116:6006, frpc映射至192.168.123.189:5555
这样scrcpy -e
就会显示两个客户端了！
scrcpy -e
scrcpy 2.1.1 <https://github.com/Genymobile/scrcpy>
ERROR: Multiple (2) ADB devices over TCP/IP:
ERROR:     --> (tcpip)  192.168.6.116:6006              device  p230
ERROR:     --> (tcpip)  192.168.6.216:5555              device  p230
ERROR: Select a device via -s (--serial), -d (--select-usb) or -e (--select-tcpip)
ERROR: Server connection failed

#手动指定连接到那一个adb 5555 客户端（即便是被frp映射过的也一样）
scrcpy --tcpip=192.168.6.116:6006

重启docker服务

这是一个类似于把整台软路由重启一样的指令

磁盘占用率97%导致数据库无法写入，应用开始出错。 为什么重启？据说能减轻磁盘占用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
root@Debian11:/www/server/panel/data/compose/matomo# du -hs /var/lib/docker/                               
11G     /var/lib/docker/ 


> docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          17        14        5.674GB   624.4MB (11%)
Containers      14        14        224.4MB   0B (0%)
Local Volumes   0         0         0B        0B
Build Cache     0         0         0B        0B

> docker system prune -a
y

> docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          14        14        5.057GB   7.335MB (0%)
Containers      14        14        224.4MB   0B (0%)
Local Volumes   0         0         0B        0B
Build Cache     0         0         0B        0B
1
sudo systemctl restart  docker

重启 以后 引导磁盘大小92.47% (45.23 GiB的48.91 GiB)

重启以后，其他的服务都正常重启了，除了：Matomo，ChatgptNextWeb，和Firefox。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
1. docker start chatgpt-next-web

2. 添加
restart: always
到firefox的docker-compose.yml文件中
启动巨慢，表面上docker已经启动完成的状态，可实际中，观察日志
[cont-init   ] 15-cjk-font.sh: installing CJK font...
[cont-init   ] 15-cjk-font.sh: fetch https://dl-cdn.alpinelinux.org/alpine/edge/community/x86_64/APKINDEX.tar.gz
[cont-init   ] 15-cjk-font.sh: fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/main/x86_64/APKINDEX.tar.gz
[cont-init   ] 15-cjk-font.sh: fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/community/x86_64/APKINDEX.tar.gz
[cont-init   ] 15-cjk-font.sh: (1/1) Installing font-wqy-zenhei (0.9.45-r3)
要耗时4-5分钟左右

3. Matomo已经有restart: on-failure:3比较尴尬。

PVE 如何给docker debian虚拟机分配更多的磁盘空间？

目前是50G 92%的占用率。

防止 Docker 日志塞满硬盘（泪的教训）

/etc/docker/daemon.json

1
2
3
4
5
6
7
# 增加：
{
"log-driver": "json-file",
"log-opts": {
"max-size": "20m",
"max-file": "3"
}
1
systemctl restart docker

无法解决问题，反而让docker无法启动数据库了（因为磁盘已满）

rm -rf /var/log/*

终于找到原因了BT 默认备份功能（默认每天备份panel文件夹下的所有内容）害死我了

采取行动：关闭宝塔面板自动备份功能

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
> cd /
> du -sh *
。。。
12G     var
35G     www
root@Debian11:/www# du -s /www/* | sort -nr                                                        
31497608        /www/backup                                                                        
4538716 /www/server                                                                                
652     /www/dk_project                                                                            
36      /www/wwwlogs                                                                               
8       /www/wwwroot                                                                               
4       /www/disk.pl                                                                               
root@Debian11:/www# bt                                                                             
===============宝塔面板命令行==================                                                    
(1) 重启面板服务           (8) 改面板端口                                                          
(2) 停止面板服务           (9) 清除面板缓存                                                        
(3) 启动面板服务           (10) 清除登录限制                                                       
(4) 重载面板服务           (11) 设置是否开启IP + User-Agent验证                                    
(5) 修改面板密码           (12) 取消域名绑定限制                                                   
(6) 修改面板用户名         (13) 取消IP访问限制                                                     
(7) 强制修改MySQL密码      (14) 查看面板默认信息                                                   
(22) 显示面板错误日志      (15) 清理系统垃圾                                                       
(23) 关闭BasicAuth认证     (16) 修复面板(检查错误并更新面板文件到最新版)                           
(24) 关闭动态口令认证          (17) 设置日志切割是否压缩                                           
(25) 设置是否保存文件历史副本  (18) 设置是否自动备份面板                                           
(26) 关闭面板ssl           (28) 修改面板安全入口                                                   
(0) 取消                   (29) 取消访问设备验证                                                   
===============================================                                                    
请输入命令编号：18                                                                                 
===============================================                                                    
正在执行(18)...                                                                                    
===============================================                                                    
|-检测到已开启面板自动备份功能,正在关闭...                                                         
|-已关闭面板自动备份功能                                                                           
root@Debian11:/www#

排查过程

  1. cd /. 然后 du -sh *
    1. 这样查找出来www目录占用了35G（不知情）
  2. du -s /www/* | sort -nr
    1. 按文件占用大小排序，找出最大的占用空间文件夹： /www/backup
  3. 清除所有的文件：/www/backup
  4. 运行bt 选18 关闭面板自动备份功能

这个BT还是更适合方便+初级用户+快速上线，很高心释放出了30G空间。下一步：找BT替换方案。

感谢列表：

一个反向代理神器——Nginx Proxy Manager>修改Docker配置

一种给PVE虚拟机磁盘扩容的方法

如何迁移/导入/导出 NPM 数据库

  1. Copy the /data and /etc/letsencrypt volumes to your new instance and mount them into your new instance. If you use the default config

  2. Export the database if you are using the MariaDB / MySQL database. If you are using the SQLite database it is likely included in your data folder, otherwise just copy the file over. Also possible using DBeaver.

    1. docker exec -it [db-container-name] mysqldump --user=[mysql-user] --password=[mysql-password] [mysql-db-name] -h 127.0.0.1 > npm-export.sql

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14

      我的实例是

      ```shell
      docker exec -i template-app-1 apt-get update
      docker exec -i template-app-1 apt-get install -y default-mysql-client
      docker exec -it template-app-1 mysqldump --user=npm --password=npm npm -h 127.0.0.1 > my-export2024010501.sql

      mysqldump: Got error: 2002: "Can't connect to MySQL server on '127.0.0.1' (115)" when trying to connect

      docker exec -it template-app-1 mysqldump --user=npm --password=npm npm -h 127.0.0.1 > my-export2024010501.sql

      #我就卡在这步，也不用往前了，因为我用的是sqlite文件型数据库，直接复制就可以备份了
      docker cp 2c88aa4ba4d5:/data/database.sqlite /home/pi/database.sqlite

  3. Import the database to your new database container (if you are using the MariaDB / MySQL database). Also possible using DBeaver.

    1. docker exec -i [db-container-name] mysql --user=[mysql-user] --password=[mysql-password] [mysql-db-name] -h 127.0.0.1 < npm-export.sql

      1
      2
      3
      4
      5
      6
      7

            



      假如mysqldump没有在容器里面

抱错误：
OCI runtime exec failed: exec failed: unable to start container process: exec: “mysqldump”: executable file not found in $PATH: unknown 

1
2
3
4
5
6

```shell
docker exec -i [container_name] apt-get update
docker exec -i [container_name] apt-get install -y default-mysql-client

docker exec -i [conatiner_name] mysqldump --column-statistics=0 --user=[user_id] --password=[user_password] --databases npm > npm-backup.sql

网上的文档有滞后现象，mysql-client 已改名：default-mysql-client

docker exec -i template-app-1 apt-get install -y default-mysql-client