qbittorrent

qBittorrent

qBittorrent，老牌的开源下载工具，部署到docker上，实现离线下载，

docker qbittorrent

docker hub: https://hub.docker.com/r/linuxserver/qbittorrent

docker run -d \
  --name=qbittorrent \
  -e WEBUI_PORT=8080 \
  -p 8080:8080 \
  -v /root/qbittorrent/config:/config \
  -v /root/download:/downloads \
  --restart always \
  linuxserver/qbittorrent

默认用户名密码是：admin adminadmin
正常情况下如果主机是非localhost的话，就应该报错: Invalid Username or Password.

原因: https://github.com/qbittorrent/qBittorrent/issues/11680
大概意思是升级4.2之后，除了本机，默认密码都不能登陆。

解决方法：

修改文件 qbittorrent/config/qBittorrent/qBittorrent.conf 加一行

WebUI\Password_PBKDF2="@ByteArray(ARQ77eY1NUZaQsuDHbIMCA==:0WMRkYTUWVT9wVvdDtHAjU9b3b7uB8NR1Gur2hmQCvCDpm39Q+PsJRJPaCU51dEiz+dTzh8qbPsL8WkFljQYFQ==)"

这样就可以用admin:adminadmin登陆了，注意需要先停止容器再修改文件，否则无效。

取消掉WEB UI登陆密码

如果有映射外网出口的就不能这样了
1.png

速度一般般，离线下载无所谓了。
2.png

NAS

我的DOCKER宿主机和NAS不是一个机器，两个分别是ALL IN NOE下的一台虚拟机。
所以我需要把下载目录挂载到NAS下。

编辑文件
nano /etc/fstab

//192.168.1.12/MOVIE    /root/download    cifs    username=guest,password=guest    0    0

解决权限问题 **
//192.168.1.12/MOVIE    /root/download    cifs    username=guest,password=guest,uid=911,gid=911    0    0

//192.168.1.12/MOVIE    /root/download    cifs    username=guest,password=guest,dir_mode=0777,file_mode=0777    0    0

执行挂载
mount -a

小坑

挂载NAS后，发现不能下载了，目测这基本就是权限问题了，

drwxr-xr-x 4  911  911 4096 Jan  4 21:40 config

drwxr-xr-x 2 root root    0 Jan  5 10:27 downloads

不能直接 chmod 777 重启之后重新挂载，权限就又变回去了。
第一个简单粗暴，好用不安全；第二个更好一些。两个方法，都可以，问题不大。

1.
dir_mode=0777,file_mode=0777
2.
uid=911,gid=911

Aria2

另外我还试了Aria2，不太好用。

简单备忘一下，完。

WeChatFerry

WeChatFerry 是一款 Hook PC WeChat 构建的微信机器人项目。

项目地址：
github: https://github.com/lich0821/WeChatFerry

wcfhttp

wcfhttp 是 WeChatFerry 的客户端，通过 http api 方式通讯。方便任何语言，任何形式与 WeChatFerry 通讯。

# 安装
pip install --upgrade wcferry

# 启动
wcfhttp --cb http://your_host:your_port/callback

callback

callback 可以是本机也可以远端。
doc 中描述机器人通过 PSOT 回调 callback 地址。
用 PHP 接收 callback post 数据有一点要注意。数据并不在 $_POST 数组中，而是在 php://input 中，用 file_get_contents('php://input') 来接收数据。

doc

wcfhttp 运行成功后，控制台打印 doc 地址：http://0.0.0.0:9999/docs。
所有的API DOCS里都有，页面上还可以做简单的Execute，十分方便。

msg-types 接口 返回数据 demo
{
  "status": 0,
  "message": "成功",
  "data": {
    "types": {
      "0": "朋友圈消息",
      "1": "文字",
      "3": "图片",
      "34": "语音",
      "37": "好友确认",
      "40": "POSSIBLEFRIEND_MSG",
      "42": "名片",
      "43": "视频",
      "47": "石头剪刀布 | 表情图片",
      "48": "位置",
      "49": "共享实时位置、文件、转账、链接",
      "50": "VOIPMSG",
      "51": "微信初始化",
      "52": "VOIPNOTIFY",
      "53": "VOIPINVITE",
      "62": "小视频",
      "66": "微信红包",
      "9999": "SYSNOTICE",
      "10000": "红包、系统消息",
      "10002": "撤回消息",
      "1048625": "搜狗表情",
      "16777265": "链接",
      "436207665": "微信红包",
      "536936497": "红包封面",
      "754974769": "视频号视频",
      "771751985": "视频号名片",
      "822083633": "引用消息",
      "922746929": "拍一拍",
      "973078577": "视频号直播",
      "974127153": "商品链接",
      "975175729": "视频号直播",
      "1040187441": "音乐链接",
      "1090519089": "文件"
    }
  }
}

chatgpt

对接chatgpt api。我的信用卡无法绑定chatgpt。所以使用 Free ChatGPT API Key 提供的免费 API KEY 使用 gpt-3.5-turbo 模型。

github: https://github.com/chatanywhere/GPT_API_free

应用

这次主要是对接 chatgpt 做一个聊天机器人。
用作消息推送，监控报警，定时消息都是OK的。

注意

任何 hook 都有风险，使用 WeChatFerry 应该会有微信号被ban的风险。最好用小号，且和大号不是同一个实名(不实名也可以)。因为腾讯实行的是连坐制。同一个实名下的所有号一起封。

不要发送大量信息，敏感信息，容易触发微信风控机制。另外据说发送GPT消息的尤其容易被封。

大量重复内容会被封号？！

我给bot开启了一个debug，忘记关了，两个同样弱智的机器人不停地互怼，跑了1天多的时间，发了可能有几万条消息？（计数器只看到99+）。
1.jpg
难道说大量重复内容不会封号？还是说风控逻辑是对单个微信发很多消息不受限？

由此能简单推测，风控的不是消息的数量，而是消息的范围？

发送人数每人发送数量影响范围影响烈度
1人10条110
10人1条101
10人群1条10-1-

如果这样假设成立，那么在很多群里，发送很多信息就是最危险的，再@的话，会更加危险。

什么时候会封号？

@lich0821 建议不封号的办法是不用微信，看来不封号只是过程，封号才是归宿。
持续观察。

更新
D3
大概挂机2.5天后，发现掉线了，上服务器看了一下，这样了：
2.png

重新登录，还能登录，没有封号，算是一次警告？【这是新环境登录的正常掉线】
持续观察。

D5
又过了两天，目前正常，只推送了少量消息，发送了一些CRON测试。
3.jpg

持续观察。

D7
又过了两天，推送消息都正常，机器人没有掉线。
难道第一次掉线是因为互怼了大量消息导致的？
持续观察。

D9
中间服务器重启，微信忘记开，停了半天，其他时间都正常在线，推送消息数量少。
也就差不多这样了。

D30~40
? 不记得多少天了，目前正常。

1.png
微2.png

旧的台锯延长板介绍

  • 优点介绍

    • 我现在使用的台锯延长系统是我之前制作的一块延长板，延长板的末端和台锯连接固定，下面用一根腿支撑，腿可以方便的放下来把延长板折叠起来。
    • 这个延长板使用起来很不错，有效的拓展了台锯的台面，极大的提高了操作时的安全性。
    • 有时候我也在这个延长台面上做一些简单的操作，他还起到了一个简单工作台面的作用。

  • 缺点介绍

    • 支撑腿没有固定，操作的时候坍塌过一次
    • 延长板采用的是一张20mm后的多层板，整体刚性不足，不够稳健
    • 延长板下方空间比较凌乱
    • 延长板下方的空间无法被有效利用，这是我决定重新做一个延长柜的最主要原因

3.png

新的延长柜介绍

  • 优点介绍

    • 柜体更加稳定
    • 索大的收纳柜体
    • 炫酷的LED灯
    • 方便的电源接口
    • 采用福马轮，移动和固定互相平衡的最优解决

  • 对比缺点

    • 空间回收没有折叠延长板方便，然后这点并不重要，因为在我半年的使用过程中发现，我一次都没有去折叠延长板。

SketchUp文件分享

实物图片

4.jpg
5.jpg
6.jpg
7.jpg
8.jpg
9.jpg
10.jpg

木材收纳车

每个木工房都有大量的零碎木料，随着制作越来越多，这些零碎木料也会越来越多，慢慢的零碎木料就会成为一个非常头疼的问题，特别是那些小面积的workshop。

所以木材收纳几乎是所有木工房都要面临的问题。

传统的木材收纳车

大概都是这样的：
woodstoragecart.jpg

我也做过一个类似这样的收纳车，没使用多长时间就被我废弃了。
微信图片_20231216124227.jpg
微信图片_20231217115000.jpg

在使用这种收纳车的过程中，我发现他有很多缺点，

  • 体积太大，太占地方，移动不方便，
  • 存储能力差，空间利用率低，
  • 分类能力差，找木料麻烦，等等。

特别是在小面积workshop，缺点尤为明显。当然他也不是完全没有优点，后面再说。

由竖向存储转变为横向存储

传统的存储逻辑是竖向存储，附带一些横向存储，有的索性就不带横向存储，比如这样的：
微信图片_20231214124017.png

竖向存储无法堆叠，垂直空间利用率很低，所以我决定重新设计制作一款木材收纳车。

我对现有的零碎木料做了一个简单的统计，有大概70-80%是30cm~80cm的短木料，我决定把木料横过来堆叠起来放。

重新设计木材收纳车

先看一下设计草图：
木材收纳车1.png
木材收纳车2.png

看起来以横向存储为主，竖向存储为辅的思路应该可行。

再看一下实物图：
微信图片_20231214202720.jpg
微信图片_20231214202746.jpg

这个木材收纳车我已经使用了快1年，大概已经用掉了它60%的存储空间。

尺寸数据：

  • height: 1794mm(不含轮子高度)
  • width:650mm
  • depth: 570mm

微信图片_20231214135836.png
微信图片_20231215102758.png

材料：

  • 18mm胶合板1.5块
  • 长木条x3（草图红色）
  • 短木条x3（草图粉色）

当时我手头仅这有1.5块多层板，宽度650深度570，所以这个尺寸基本也是材料的极限大小。

存储空间：

  • 650mm 存储空间位5个（横向）
  • 530mm 存储空间位2个（横向）
  • 330mm 存储空间为2个（横向）
  • 1500mm 存储空间位2个（竖向）
  • 650mm 顶部放置位1个（横向）

制作

这个制作很简单，几乎全部都是螺丝的T型结构，坚固程度是没有问题的。

缺点

  • 下层的木料拿放需要弯腰
  • 我的workshop比较矮，只有2.4米，太长的木料无法插入竖向存储空间，如果房子足够高就不存在这个问题了
  • 无法存储成品木板，只能存储木料，对规格1.22x2.44的成品木板就无能为力了，这个刚好是传统收纳车的优势，
    如果存储胶合板是主要需求，那传统存储车应该是不个不错的选择，

思考&改进

  • 整体尺寸略小了，受制于当时我只有1.5块胶合板，宽度被做到了650，如果宽度可以做到800就好了
  • 300~400的存储区域不够用，我的零碎木料比较多，短存储区域很快用万完，如果有4个短存储区域应该会更加好用，当然我也可以把短木料放在长存储区域，这不是大问题

其他照片

微信图片_20231214202942.jpg
微信图片_20231214202946.jpg
微信图片_20231214203003.jpg

sketchup 草图文件分享

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6