@zhailw f2b 正解 此类根据某种特征识别主机并 ban 掉的操作都是 f2b 能搞定的范畴

如果你说的爬虫指的是爬 SSH 弱密码、爬 SMTP 中继的那类，规则可以设置的严格一些，我这边都是直接 ban 终身的

有的时候并不需要在源头上 ban 一个 IP 。资源够的话可以先从应用层面 ban ，然后升级至防火墙 ban 端口，最后彻底 ban ，可以有效减少误杀的可能。

18 年底收的二手 DS1812+，上的还全都是 8TB 的 SMR🤪 都是希捷的，一半是 Archive ，一半是 Barracuda ，从大概 20 年开始就 24/7 了到现在一个坏块都没有，都照样跑的杠杠的。有定期 mdadm+btrfs scrub 的习惯。

SMR 大流量下 IO 阻塞的问题确实存在，但一年到头都遇到不了几次。之前也有重建过 raid ，最久确实是需要跑两三周，挺吓人的。但真正用起来也就那个样子。

补充一点，如果使用了应用的 secret 那么这个 secret 丢失的话数据库里的数据可能就无法解密了（但可以备份这个 secret ）。这种 secret 用来加密 volatile 数据更合适（比如 session key 之类需要加密但丢了也无妨的数据）

或者你可以为对应的数据加 salt ，甚至系统中设置多个 salt ，基本上就能做到楼上上说的必须泄漏三者才会出问题：
- 主密钥（ env ）
- 应用配置 secret 或 salt （ code ）
- 主密钥、应用的 salt 和记录 /用户的 salt 参与数据库中数据加密（ db ）

对称加密可能还会用到 IV 和 nonce ，但 nonce 一般不需要记录（也不应该被复用），IV 保存在密文的开头或结尾是基本操作，在这个问题中不适用。

@julyclyde YubiOTP 不像 U2F ，是需要目录服务器支持的。如果 app 选择使用 YubiOTP ，他们就可以配置服务为仅信任 cc 开头的密钥，即便 Yubico 的服务器上 cc 和 vv 开头的密钥都有提供。

YubiOTP 生成的时候需要在服务端保存一个不公开的密钥。cc 密钥在设备生产的时候就已经生成了，可以理解为密钥没有在公网公开过，信任度更高。vv 密钥生成后需要通过网络传到 Yubico 的服务器，这个过程有可能被破解窃听，所以信任度不如 cc 密钥。

这些对 U2F 和 FIDO2 没有影响，两者是完全不同的技术

@billgong 更正：YubiOTP 原厂 key 是 cc 开头；
自己生成的 key ，需要公开注册的 key 是 vv 开头，其他前缀只能作为私有用途。

U2F 模式仅支持 MFA ，不需要用户端校验，所以每个 app 都生成新的密钥对
https://developers.yubico.com/U2F/Protocol_details/Key_generation.html
然后 yubikey 里再用设备自己的主密钥处理生成的密钥私钥，整个过程 yubikey 不存储任何新创建的信息

新的 FIDO2 支持 resident key 模式，这样就能允许设备存储某一 app 的私钥，实现（更高一级的） passwordless 。

不支持 FIDO2 的 Yubikey （四代及以前）主密钥永远不变。支持 FIDO2 的 Yubikey （五代及以后）重置 pin 会重设主密钥。

FIDO2 模式密钥你看不到的，只有 pin 可以设置（必须设置一个 pin ）抹掉 pin 的话私钥应该也就重置了吧

YubiOTP 的话出厂默认带一个 key 在 slot1 ，默认是锁定的状态，千万不要删掉（自己再生成的 cc key 有 trust 的问题）

大部分功能可以用 yubikey manager 管理，但更高阶的功能需要用 personalization tool ，只是那个工具现在已经 EOL 了

@shervy Zoom 、MSTeams 都是出了名的特别热，烂优化。后台没有了这俩哥们儿我续航能再加 3 个小时。因为 MBA 散热模组和底盖不接触，确实是凉的，但其实 SoC 真正跑起来还是会很烫

@acapla 也是 24G 的 M2MBA ，高负载过热会卡的，后来没办法还是加了散热垫，会持久很多。反正也不会放在腿上用，不怕烫。

14 寸还是太厚了，我觉得 M2MBA 是个不错的 middle point 。但别人问我我肯定无脑推 14M1 ，毕竟谁没事儿干升级到 24G 内存呢😂

小米红米有不少可以直刷 OpenWrt 的

这么想用软路由那就彻底点儿，小 x86 主机上虚拟化，无线部分最好上专门的 AP （不一定非要上 AC ）

其实感兴趣的话直接玩成套的 SDN 也挺好的

@YongXMan 可能是我这边真的没有这个需求吧，所以能接受系统盘的这种设定。DS1812+上没有开磁盘休眠，直接 24/7 转的，还带着几个 docker 容器。下载都是直接用 entware 配置的，做了 transmission 和 aria2 daemon ，除了 scrub 、torrent verify 和同时下载 50 个以上活动种以外还没有 IO 卡死的情况。那个啥……里面 8 块 8T 的 SMR🤦‍♂️ 真的没什么感知……

@YongXMan 我理解的是如果选盘位装系统的话会有一致性问题（装系统的盘空间相对少、负载更大）。系统高可用也不是说为了企业级应用，对普通消费者也是有好处的啦。现在 DSM 每个盘占用不到 5GB 作系统和 swap ，硬盘容量这么大，这点占用毛毛雨啦

Device Start End Sectors Size Type
/dev/sda1 2048 4982527 4980480 2.4G Linux RAID
/dev/sda2 4982528 9176831 4194304 2G Linux RAID
/dev/sda3 9437184 23437565951 23428128768 10.9T Linux RAID

补充一下，backup ups 后备式还是有断电的风险的，有些设备对电路切换敏感。比如多盘位的 NAS 多用内置电源，保持时间比较好。但外置电源保持时间就不好说了

但家用的话 online 在线式都太大太吵了，折中一下 line interactive 的切换时间会好一些，也相对小巧，比较安静

我之前用的 350BK 配合 DSM 没有掉线的问题，反倒是后来买的 Cyberpower 的 UPS 在 Linux 和 NUT 下 USB 端口无活动会断连，需要提高 poll rate 。不过不影响我的 NAS ，好像 DSM 有适配（成品 NAS 大多也是用的 NUT ）。

你说的这些不用说企业场景了，办公室场景都用不着。硬盘没问题的话直接 247 运行就可以了。硬盘型号也应该保持一致，SSD 也应该是要么单独卷要么缓存盘。

系统放所有盘上就是为了高可用。系统分区是 RAID1 ，即便某块盘慢也不应该对整体性能有影响。

@asilin 22.10 已经重新引入 Unity+Wayland 了，说不定下一个 LTS 就又是默认 Unity 啦

https://ubuntu.com/cpu-compatibility

我看到 16.04 可以支持到 Rome 架构的 EPYC 。对多线程性能要求高的话走 AMD 服务器平台也可以啊。Zen 2 差不多也快到捡垃圾的时候了，新的二手都可以有。

华硕那个 QoS 主要还是太吃 CPU 了。

这种情况的话也可以考虑电脑直接接到桥接的光猫上 pppoe 然后测速，缩小一下问题范围。