Docker设置自动重启
刚发现甜糖的新业务镜像自己停止运行了,无语,这玩意参数都没自动重启。
只能手动添加了:docker update --restart=always tiptime_wsv
no - 容器退出时,不重启容器;
on-failure - 只有在非0状态退出时才从新启动容器;
always - 无论退出状态是如何,都重启容器;
刚发现甜糖的新业务镜像自己停止运行了,无语,这玩意参数都没自动重启。
只能手动添加了:docker update --restart=always tiptime_wsv
no - 容器退出时,不重启容器;
on-failure - 只有在非0状态退出时才从新启动容器;
always - 无论退出状态是如何,都重启容器;
最近突然发现个很恼人的事情,我的笔记本双系统为了便于交换数据有一个命名为DATA的NTFS分区,但是现在它不能正常写入了,和其他NTFS分区一样变成了只读状态。
刚好看到更新Linux内核的提示,现在使用的正是5.15.0-47-generic,我寻思ntfs3在5.15已经并入主线了,我干嘛还用ntfs-3g这不靠谱的玩意。索性一顿搜索,找到文档和一篇实践文章。(如果你看过二者的性能和功能完善度测试就别在这篇文章下跟我抬杠扯ntfs3没人维护。)
打开Disks,看了看分区表,确定DATA分区UUID。卸载当前挂载的分区,编辑/etc/fstab
加入如下内容
# /dev/nvme1n1p3 Double Systeam Data Exchange, mount at /media/xfox/DATA
UUID=064CD8C0634B2442 /media/xfox/DATA ntfs3 iocharset=utf8,umask=0,prealloc 0 0
RIME(中州韵输入法引擎)是由佛振开发的自由软件,以 BSD-3-Clause license开源。RIME存在多个平台分支,包括Windows、darwin和Linux,以及Android四个主要平台分支。
作为一款自由软件,RIME的主要分支大都支持导出词库配置快照,因此有机会实现备份。
预定方案:使用Python编写,对需要同步的文件使用Webdav协议连接自建或坚果云Webdav等服务商进行同步,UI方案使用Python自带的Tkinter。(暂时对安卓开发无能为力)
上次遇到这个问题还是在我刚买回ThinkPad用着Windows10的时候。但是没想到这次居然在NAS的Debian下出现了,就很无语。
解决方案如下,查找policies文件里是何方妖魔鬼怪,结果发现是DuckDuckGo?WTF....吃相真难看啊。
xfox@J3160:~$ whereis chromium
chromium: /usr/bin/chromium /usr/lib/chromium /etc/chromium /etc/chromium.d /usr/share/chromium /usr/share/man/man1/chromium.1.gz
xfox@J3160:~$ cd /etc/chromium
xfox@J3160:/etc/chromium$ ls
master_preferences policies
xfox@J3160:/etc/chromium$ cd policies/
xfox@J3160:/etc/chromium/policies$ ls
recommended
xfox@J3160:/etc/chromium/policies$ cd recommended/
xfox@J3160:/etc/chromium/policies/recommended$ ls
duckduckgo.json
xfox@J3160:/etc/chromium/policies/recommended$ sudo rm duckduckgo.json
学长推荐了Docker可视化工具Portainer,我没多想就去查了查,发现知乎有文章,日期是2021年上半年的,倒也不算很旧。就进去看了看,按上面的说明配置了,但是进去发现版本是1.X并且提示更新,于是有查询如何更新,随手找到一堆2022年发的互相抄袭的烂文章写:直接“docker pull portainer/portainer
”
What FUCK???
结果当然就是报错:Error response from daemon: pull access denied for portainer, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
于是我就各种尝试各种找解决方案,甚至一路怀疑到了我的阿里docker镜像加速服务上,终于发现有人提了一嘴:从 2022 年 1 月开始,此存储库的最新标记将指向 Portainer CE 2.X
所以,麻烦各位营销号抄袭的时候看看日期和文章质量吗?一篇2021年一月份的文章到2022年7月份仍然有一个标点符号不差的新拷贝🙃
为了避免被垃圾信息干扰,我就直接用duckduckgo搜索得到www.portainer.io,从里面找到了官方文档对社区版安装的指引接下来皆大欢喜。
我不明白CSDN和B呼的过时信息是怎么在Bing国内版上面位居前列的,可能野生培训班出来的那群普遍就这么low?
也是我的问题了,这次查资料不先用DuckDuckGo和Bing国际版找官网文档却跑去用Bing国内特供版,还先去看的逼呼和CSDN的烂文章😓
就在刚刚,NAS崩溃了,重启后ping不通。且路由器内无法看到J3160的连接。
回溯一下我都做了什么。
宝塔使用PM2管理器插件-->卸载PM2管理器插件-->使用APT安装npm和nodejs,试图npm install -g a
-->执行apt autoremove
紧接着Windows 10 RDP远程崩溃提示发生错误,接着就连不上ping不通。
接通HDMI,HDMI无信号,机箱电源灯正常,板载千兆网口指示灯不亮,可闻机械硬盘运作噪音。
按下电源键,设备输出HDMI信号,屏幕快速刷新内核界面后无信号输出。-->判断内核可能已启动,系统所在杂牌SSD硬盘数据暂无异常。
再次按下电源键。正常引导至Grub启动界面,主板暂无无异常。内核启动时可见多个Failed报错,但系统正常加载到Debian登录窗口,可正常使用帐号密码登入。
查看发现NAS无网络连接,且原先自动配置的有线连接消失。-->可能由于执行apt autoremove删除了原先的网络连接管理工具并删除了其配置项目导致连接丢失。但重新配置后发现无法正常连接。
重启NAS,有线网络依旧未能连接,遂手动配置使用主板上M.2 PCIE接口的24Ghz无线网卡完成WIFI连接。
未避免出现更多问题,决定先行备份数据再进一步研究。
我选择了直接重装系统,因为第一次装机时缺乏经验对很多东西进行了尝试,让系统软件包较为混乱,重新安装系统可以彻底解决一些遗留问题。吸收上次的经验,使用apt代理充分利用手头的代理资源让这次重装速度快了很多。
我仔细想了想可能和第一次安装时没有手动安装网卡的非自由固件有关系,后续多次更换桌面环境又使用apt autoremove彻底删除了初次安装时留下的设备配置文件,所以这次我在安装系统后查询了Debian 官方Wiki找到了相关内容6.4. 加载缺失的固件。以下内容摘自Debian Wiki:
一旦登录进了已安装的系统,遵循以下步骤可能可以自动检测缺失的固件,并启用它们:
以“root”用户运行 isenkram-autoinstall-firmware
命令。
通常,重启是保证各个内核模块已经正确初始化的最简单的方法;这在使用 nomodeset 参数作为临时措施以启动系统的情况下尤为重要。
[注意] 注意 安装固件软件包很可能需要启用软件仓库的 non-free 区。截至 Debian GNU/Linux 11.0,运行
isenkram-autoinstall-firmware
命令会自动完成该工作,这是通过创建一个指向通用镜像的专门文件(/etc/apt/sources.list.d/isenkram-autoinstall-firmware.list)实现的。
至此,固件问题完美解决。
参见第一次装机写的文章简单装好了J3160小主机
1.挂载硬盘
2.配置DDNS
3.安装docker
1.安装 Portainer 可视化管理Docker 参见portainer.io
2.安装 Nginx Proxy Manager (docker)
根据需要自行查阅官方文档,需要注意的是,似乎使用Host网络模式才能使用内网IP访问本机上没有绑定外部端口的docker,至少在本人使用Nginx docker镜像时存在此问题。(最开始我只按照官方安装示例给NPM绑定了80,81,443三个端口,但进行下列步骤时反代出现504错误),使用host网络模式可解决。
当前我的home.xfox.fun亦通过内部运行的一个nginx docker和Nginx Proxy 实现访问。
docker run --name home.xfox.fun -v /home/xfox/www/home.xfox.fun:/usr/share/nginx/html:ro -d nginx
此时,通过NPM面板或docker ps命令可得到此nginx容器被自动分配的内网IP:172.17.0.3,使用NPM新增反代站点并将源站IP设置为172.17.0.3,不必映射到公网端口。(你先别急,不把下面的内容看完有你急的时候)
考虑到docker自动分配的内网IP可能会在重启后改变(docker容器获取ip的原则:最先启动的容器获取ip段中最小的ip,之后启动的容器按照顺序获取ip),可采取两种方式解决。
1.为容器绑定一个网络别名
别名类似一个互联网域名,同一个网络中的其他容器可以通过这个别名来访问该容器
使用--network-alias指定容器网络别名
--network-alias home
2.运行容器时就绑定指定内网IP
使用--net指定容器使用的网络 --ip指定容器使用此网络的一个ip
--net somenetwork --ip 172.18.0.2
注意,未指定内网IP时,docker默认分配“bridge”网络的内网IP。如果希望避免容器被入侵后通过默认的bridge内网感染其他容器,你可以新建一个网络并指定新建网络的网段使用与其它容器不同的网段。
我自己有备份Cloureve的程序和数据,官方安装教程够细了
本来想用docker,想了想涉及很多文件读写和端口还是算了吧。
以前也是多次配置aria2apt install aria2
即可,配置文件参考https://github.com/P3TERX/aria2.conf 写的很详细
值得注意的是,Debian11默认关闭了rc-local服务,需要手动开启该服务,可参考Enable rc.local in Debian Bullseye
nano /etc/rc.local
写入如下内容
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
exit 0
设置可执行权限
chmod +x /etc/rc.local
重载systemd配置
systemctl daemon-reload
启动rc-local进程
systemctl start rc-local
检查rc-local状态
systemctl status rc-local
考虑到需要让aria2开机自启动,得向rc.local写一句:aria2c --conf-path=/home/xfox/.aria2/aria2.conf -D
由于NAS上SATA口只有两个,暂时没把16MB Cache的古董机械装上去,装上去的是64G固态(M4-CT064M4SSD2),这个固态当作甜糖缓存盘跑回本电费和硬件,Cloudreve暂时也拿此盘凑合,后期再换大容量固态或者插PCIE转接卡接机械盘。(露出了贫穷的目光 >-> )
此前安装了Linux Mint20.2Uma,后续升级到了20.3Una,现在基于Ubuntu 22.04 LTS的Mint21 Vanessa已经可用了!(关于vanessa还有另一个词条:https://zh.moegirl.org.cn/Vanessa(Cytus_II)#)
我没有看到官方对于“Vanessa”的解释,但是可以参见ThinkBabbyNames的解读:
as a girls' name is pronounced va-NESS-ah. It is of Greek origin, and the meaning of Vanessa is "butterfly". The name of a genus of butterflies that includes the Red Admiral and the Painted Lady. Also possibly an early-18th-century literary name of English origin created by Jonathan Swift for "Gulliver's Travels" as a pseudonym for Esther Vanhomrigh, based on the first syllable of her surname, and possibly the Latin verb "esse", meaning "to be"
这是我写的DS18B20用户态驱动
Goodspeed最近好像比较清闲,所以这位有点闲的同学跑来远程我的OrangePi Zero2 完成了一份正经的单总线驱动。实现后效果如下:
root@orangepizero2:~# cd /sys/bus/w1/devices/28-0721c061a6ac/
root@orangepizero2:/sys/bus/w1/devices/28-0721c061a6ac# ls
alarms eeprom_cmd hwmon power temperature
conv_time ext_power id resolution uevent
driver features name subsystem w1_slave
root@orangepizero2:/sys/bus/w1/devices/28-0721c061a6ac# cat w1_slave
bb 01 4b 46 7f ff 0c 10 74 : crc=74 YES
bb 01 4b 46 7f ff 0c 10 74 t=27687
显而易见大约27摄氏度,详细过程会在他的博客写好后在下方公开。(人比人气死人:)
给香橙派 Zero 2 适配 1-wire 总线————William Goodspeed
在向Goodspeed抱怨此事之前,香橙派官方4群里邹明燊先生也曾经写过一个dts文件,也是根据其他已经支持1-wire的设备简单改写的(如下),但是我通过orangepi-add-overlay xxx.dts 添加后会在日志中看到错误信息,即我上一篇文章里写被占用的哪些错误信息,并且经过测试dts生成的dtb文件没有正常工作。而Goodspeed提供的截图中可以看到,这个dts文件并没有写错,只是设置的GPIO不同。
/dts-v1/;
/plugin/;
/ {
compatible = "allwinner,sun50i-h616";
fragment@0 {
target = <&pio>;
__overlay__ {
w1_pins: w1_pins {
pins = "PC9";
function = "gpio_in";
};
};
};
fragment@1 {
target-path = "/";
__overlay__ {
onewire@0 {
compatible = "w1-gpio";
pinctrl-names = "default";
pinctrl-0 = <&w1_pins>;
gpios = <&pio 2 9 0>; /* PC9 */
status = "okay";
};
};
};
};
二者的主要不同在于Goodspeed是在 arch/arm64/boot/dts/allwinner/overlay/Makefile 中加入一行 sun50i-h616-w1-gpio.dtbo,make dtbs
让构建系统编译新的 overlay,而邹明燊先生试图让我直接通过orangepi-add-overlay将改写好的单总线支持dts文件编译并自动添加到overlay路径。
这两者方法不太一样,Goodspeed的方法是从orange-pi-5.16-sunxi64 linux分支源码中自动编译生成dtbo文件,而邹明燊先生是自己写dts从写好的dts去编译得到dtbo文件。但是不知道为什么后者无法生效,从内核日志里的报错看是和pinctl冲突了,也就是说比pinctl抢先占用了pin,但是理论上应该先由pinctl统一管理,驱动应该基于pinctl运行。从这点看,由linux分支源码去自动编译可能会得以避开这一问题,但是具体避开抢占问题的原理就不得而知了,我也不打算深究。
关于linux设备树,请参考如下内容深入浅出理解Linux设备树(DTS)
Dts:DTS即Device Tree Source,是一个文本形式的文件,用于描述硬件信息。一般都是固定信息,无法变更,无法overlay。
Dtsi:可以理解为dts的公共部分,添加、变更非常灵活。Dtsi包含在dts中。
Dtb:Dtb编译出来的二进制
Dtbo:Overlay编译出来的二进制
dtbo-base:指定overlay是以哪个dtb为base来覆盖的。
Node:树的节点
Property:属性