研究 – 第 10 页

docker安装dolphinscheduler添加数据源连接失败

2024-09-27 11:14:16 [ERROR] 2024-09-27 11:14:16.055 +0800 o.a.d.p.d.a.d.AbstractDataSourceProcessor:[130] - Check datasource connectivity for: MYSQL error
2024-09-27 11:14:16 java.lang.ClassNotFoundException: com.mysql.cj.jdbc.Driver

看下docker-dolphinscheduler-api-1容器的日志中发现以上失败，通过检索发现，可以把驱动包放在lib/plugin/task/sql目录下，但是，这个目录在哪里却是个问题，后来查看源代码（https://github.com/apache/dolphinscheduler/blob/3.1.0/dolphinscheduler-api/src/main/docker/Dockerfile），确定ENV DOLPHINSCHEDULER_HOME /opt/dolphinscheduler，那么进入容器的/opt/dolphinscheduler这个目录确实能看到libs子目录，其中已经有一些连接器了，只不过那些就是官方所说的符合开源协议的已经内置的，像mysql的就不符合apache的开源协议，所以只能自己往里放，可是为什么官方文档里没有提到呢？

我是搜到了https://www.bookstack.cn/read/dolphinscheduler-3.1.0-zh/7667e5f48166e75f.md，这个来自官方的早期镜像版：

我们以 MySQL 为例，如果你想要使用 MySQL 数据源，你需要先在 mysql maven 仓库中下载对应版本的 JDBC 驱动，将其移入 api-server/libs 以及 worker-server/libs 文件夹中，最后重启 api-server 和 worker-server 服务，即可使用 MySQL 数据源。如果你使用容器启动 DolphinScheduler，同样也是将 JDBC 驱动挂载放到以上两个服务的对应路径下后，重启驱动即可。

查看对应版本的官方文档却找不到对应的章节。

目前，以3.2.2版本来说，需要放连接器的容器包括：

docker-dolphinscheduler-api-1

docker-dolphinscheduler-worker-1

docker-dolphinscheduler-alert-1

以docker desktop操作说明，找到这两个容器，点击容器名进入容器，切换到Files，/opt/dolphinscheduler/libs，右键import，选择mysql-connector-j-8.2.0.jar，然后重启以上三个容器就可以了。

开放式小区计划

这个计划失败了，也成功了。

推墙没有成功，但至少门开放了。如果小区没有了院墙，世界会更美一些吧，至于大家担心的小区内道路有车通行影响安全，实际上不会比现在更差，本来也没有实现人车分流，反而，如果小区没有了围墙，车可以很快并入公共路网，小区内的汽车转圈更少。当然，这个愿景恐怕在十年内实现不了。

小区有三个门，一个东北门，是大门，进出机动车和行人，一个是东南门，是消防通道，里面和外面长期被堵，恐怕消防车很难通行，另一个是西门，长期锁闭，以前还可以通行非机动车，疫情三年之后，加焊了栏杆，只能过人了。

三个门的行人通道都是常锁的，据说是为了防止附近其他小区的人穿行，尽管我也觉得我们小区在附近算环境稍微好一点的，但也不至于自以为是高端社区，搞成封闭的。

在一段时间的努力之后，人们已经习惯于不再刷卡开门，门变成了可以直接推开的，三个都是。具体什么方式暂且保密，有一个有趣的可以提一下，消防门那里经过了长期的反复较量，有人在门磁上贴胶带缠绳子，有人就弄下来，最终，那里就不用刷卡了。规矩是人定的，事在人为。

另外一个是我们的单元门，为了防止流窜人员的理由一样站不住脚，能挡风就行了，完全没有锁上，快递上不去。最终，那个门也锁不住了。

6月，我错过的日子又找回来了

这个暑假很热，孩子们放假了，但没法出去晃，整日在家里，除了看孩子，最主要的工作是研究AI，最大的投资是买了一台二十多万的存储。

等过完了暑假，来到了9月，开始给客户做服务器迁移，却又把日子退回到了6月，因为习惯了本地的有代理环境，突然远程到客户的服务器上去部署环境，发现连最基本的docker装起来都费劲了。

查了一下才知道，是因为6月和AI，造成整个docker源挂了，甚至连国内的镜像站也都关闭了。服务器上用代理终究不是个很好的办法，于是找了半天，终于找到一个可用的镜像地址。

如此下去，国内的IT还真是要回到手推车的年代吧。

坚果R2连接三星watch5手表方法（2024）

之前费了很大劲绑定的，看了很多教程，以至于最后怎么连接的都搞不清楚了。因为手机摔坏了，换了一个手机，当然，还是坚果R2。

习惯性的先装上谷歌框架，按照原来收藏的信息，怎么都连不上。看到了https://help.wearosbox.com/faq/device/samsung.html收到启发，删掉谷歌框架，只安装了：

（1）wear os中国版（在中国的应用市场上安装就是中国版）

（2）三星智能穿戴

（3）三星健康

接下来是连接步骤：

（1）装好了之后，直接打开“三星智能穿戴”连接手表，如果提示手表需要重置，则在手表的设置中选择重置，手表重启（这个时间可能要几分钟）后，手机上的“正在扫描要添加的设备”就能看到手表型号，点击以后开始蓝牙配对，手机和手表都点击确认即可。

（2）接下来一系列确认。

（3）有一个自动备份手表的步骤，看似不能跳过，先点下一步，然后拒绝就行了，当然，如果用三星的换机助手备份一下也没有问题。

（4）然后接下来又是一系列确认，然后开始配置，估计有几分钟的时间。

（5）这样就好了。

估计是三星的app升级了，重新对接了wear os中国版，消除了bug，以至于以前的折腾终于可以免去，但如果按照了谷歌框架反而会造成上面链接提到的判断“该手机无法支持”等。

（6）最后，不要删除wear os，删除了三星智能穿戴的连接也就断了。如果你以为它已经没用，把它删掉了，那就去三星智能穿戴解绑，重新连接。

另外提一句，如果直接打开wear os，不点击三星的连接，而选择第二个wear os连接手表，虽然手表设置环节不能完成，但是这时候三星健康是可以连接上手表的，手表因为停在设置状态不可用，则可以通过重启后长按logo进入“独立使用模式”，但这个时候三星健康依然能同步，相当于跳过了三星智能穿戴，只是这个链接不稳定，而且不能通过手机app设置手表，所以还是按标准三步流程连接吧。

最后的最后，解决一下将手表步数同步到微信运动。

（1）安装谷歌框架，以在google play中去安装“健康平台”这个app，或者直接找到app安装包。参考https://www.bilibili.com/read/cv25382423/?jump_opus=1，这个app是装在手表上的，手机上看不到。

（2）然后打开这个链接https://ecommerce.samsungassistant.cn/index.html#/jd/activity/748/0

（3）“点击开启插件”，只有这样能找到这个插件，接下来是授权。这个虽然叫插件，但在手机的应用程序权限管理中可以看到，可以把自启动和第三方启动打开。

（4）授权时有可能失败，可以重新打开“三星健康”的设置“三星健康设置”中的应用程序，这时应该可以看到这个插件了，点击能确认权限。

需要说明的是，以上方法并没有让我能够确认微信运动能够获得同步的步数，用最新版的三星健康app的时候甚至有报错通知，我把版本降到了Samsung Health_6.23.0.047_APKPure.apk，不报错了，但依然无法同步，我问过三星客服，想给她要最新的插件，她说不能提供。最终在手机重启也或者是等待了一段时间之后，微信可以同步步数了。

另外一个就是三星健康监测功能，这个最主要的是提供心电图，心率在三星健康中就有，不需要单独装这个，心电图在中国版默认是用不了的。简单来说，就是先在手机上安装某个伴侣软件，具体操作可以看https://www.lxtend.com/miscs/SHM_MOD_Installation_and_Setup_Guide，也可以参考https://help.wearosbox.com/faq/device/samsung.html#%E4%B8%89%E6%98%9F%E5%81%A5%E5%BA%B7%E7%9B%91%E6%B5%8B 来操作，不过按照app中的说明一步一步走问题也不大，只是大部分人第一次搞不一定熟悉它的逻辑。

如何在nginx中将laravel配置到二级目录

    # 此处配置二级目录站点
    location /sso {
        rewrite /sso/(.*)$ /sso/index.php?=$1 last; break;
        location ~ \.php$ {   
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
            fastcgi_pass php80:9000;
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME /www/one/one-api-sso-ywcbs/public/index.php; 
        }
    }

参考：如何使用一个域名配置多个Laravel项目？

以前一直没有找到一个可用的配置，导致laravel一直挂在根目录，其他前端项目反而都要用二级目录，终于找到一个配置可用了。可怜我对nginx的了解还是不够多。

以上配置中，php80:9000是来自docker的php80，如果用的其他的php部署方式，请按指定方式配置该项即可。

面向未来的开发

上周执行了计划了很久的暑假自驾行，可惜因为四个人中的两个感染莫名其妙的病毒中途就回京了。同时，在出发的第二天就遇上滑坡阻路，划破了车胎侧壁，在太原等轮胎等了三天，深度体验了一把太原。

这个城市核心区其实还不错，老东西不少，旧街市虽已显颓势，但总比北京还是要好很多，路规划的还不错，只是路面起伏不平，不知道是地质原因，还是铺装标准不够高，或者施工队偷工减料了，估计撑不了几年。

于今来看，似乎几十年的发展并不能支撑一个十年的折旧，顶多五年就没了。那现在要做的事当然不是继续这种只管两三年的事儿，既然前景不好，那就好好做一点能有益于未来二三十年甚至更久的事儿，跟现实保持一定的距离，不被裹挟。

去了赵州桥，发现赵州桥是把老桥拆了在原址造的假的。路过三苏故里，虽然也是假的，但做的还算认真，因为确实没啥直接关联了，只是人家三苏感情上认可这个旧地方而已。既然只是基于这一点点认同，那就把这一点点认同做好一点。三个展馆看下来，也花了一两个小时，这对于一个栾城来说，算是不错的成绩了。

在太原，晋祠算是让今人玩废了，建筑尚存，文化不再。很多空间竟然用来做封闭的办公区，其他空间则以布展为名关闭，里面则透出劣质油漆的味道。值得称道的是被山西省政法霸占了几十年的都督府。一进大门便是一个小楼做的抗战博物馆，虽然也像其他地方一样的叙事逻辑，但总归有一些意想不到的细节，让人觉得希望尚在。

看下来，我们忘记的或者毁掉的，本来就是最有价值的东西，也是最值钱的东西，我们造物的能力在实际上首屈一指，我们造文化的能力却损失殆尽。那就做一做面向造文化的开发。

qbittorrent使用小结

本来用qbittorrent下载东西已经是二十年前的记忆了，这么多年也不刷美剧，基本上就告别了bt，最近因为某项目需要采集数据，重新接触qbittorrent，但是真拿它来干活的时候，发现伺候起来并不简单。

这一个任务一共一万多个种子，尽管家里已经升级了2000M光纤宽带，但无论是网速还是连接数恐怕也远远达不到肆意下载的程度，于是确认了一下光猫里的默认连接数为4000，调整成了20000，不知道真的上到这个数字会不会崩，后来又改回了4000。

qbittorrent里面的每个种子的连接数设置成了50，似乎太大了也没用，因为实际上没有那么多源，平均每个任务也就是四五个连接。全局最大连接数曾一度设置为1000或者2000，但通过网络监测结果来看，这么多任务同时下载很多资源花在了任务调度上，带宽利用并不好，于是将总连接数限制到了500或者200，。

后来，系统崩了，不知道为什么崩的，但任务恢复之后就发现很多下载任务变成了检查恢复，这个特别消耗资源，一则要从存储上把资源都读出来，我用的千兆网连接，速度本身就受限，再加上可能是多个任务同时检查，内存就废了。后来我启用qb以后，把绝大部分任务都暂停，然后逐个继续，才慢慢解决崩溃的问题。

总结下来有几个原则可以遵循：

（1）批量添加种子之前，打开设置，在“下载”中修改“默认保存路径”，否则默认到C盘就惨了，我第一晚下载就把C盘搞爆了，批量添加种子时选择的保存位置只对第一个有效，后面的不行。

（2）继续设置“连接”，每torrent最大连接数可以设置为50，实际上有5到10个就够用了，按平均每个5个计算，同时下载10个torrent，全局最大连接数设置成50也行，可以稍微放大一点到100或者200，再大了意义不大。

（3）如果涉及到大量任务恢复的情况，可以在重载界面后，首先把全局最大连接数设置成20，同时把所有任务暂停，然后手动分批恢复继续。

锤子科技绝代产品坚果R2手机电源键失灵解救办法

中午微信语音的时候，手机突然黑屏，然后就没法点亮了，后来尝试：

（1）办法一：音量加+电源键强制重启，重启之后可以点亮屏幕，再划动屏幕进入。

然后上网搜了办法，比如清理垃圾文件以及清理内存，我没有找到清理内存在哪里搞，因为是微信语音的时候出的问题，我尝试了删除微信，但并不解决问题。总是强制重启进入系统也不是办法（似乎单独按音量加十几秒也能强制重启，所以貌似就只是电源键坏了），于是想到第二个办法。

（2）插上充电线，给手机充电的时候，屏幕也会亮，这个时候划屏幕也能进入。

但这依然也不是个好办法，总不能随时握着充电宝啊。继续尝试，终于找到第三个办法。

（3）左侧的快捷键设置了双击打开卡包，这个时候也能点亮屏幕。

但是，这个也不能解决问题，于是想到第四个办法。

（4）淘宝上找了下维修店，报价说如果主板不坏，修一下180，如果主板坏了，修好300封顶，我没舍得，再者也还需要备份数据以及找备用机。

那么还有没有别的办法呢？如果微信删掉还不行，那就有一个办法就是重置系统，如果是微信或者别的app造成键位定义冲突，那么这个冲突除了重置还有什么办法清除呢？于是，找到第五个办法。

（5）在设置中的“任意开关和快捷键”这里，把各个快件键的设置来回改了几下，估计是改到双击电源键打开相机的时候，问题解决了。电源键不再失灵，恢复正常了。

希望你很快就看到了最后一条并解决了问题。

阿里云不再提供一年期限的免费域名SSL证书的应对策略

毫无疑问，当然是用Let’s Encrypt

那么就开始搞吧，事实上真的很简单。只是首先要搞清楚自己的部署环境，我用的是基于yeszao/dnmp改写的一个环境，大体上一样，可以直接看yeszao/dnmp。

首先我把域名解析到我的服务器，如果是一个新的域名，则在得到ssl证书之前，给该域名的站点conf中只配置80端口，443端口等后续得到了数字证书以后再添加或解除注释，免得没有ssl的文件nginx无法启动。

然后在该域名的站点的conf中添加

location ^~ /.well-known/acme-challenge/ {
      default_type "text/plain";
      root /www/acme-challenge/;
    }

注意，上面root后面对应的地址是基于dnmp的env配置的映射地址，也就是dnmp目录下的www中再新建一个acme-challenge，如果dnmp在/，则实际目录地址是/dnmp/www/acme-challenge，这个地址在下一步用的到。

添加以上规则后，重启nginx。

然后就可以使用命令创建证书了：

sudo certbot certonly --webroot -w /dnmp/www/acme-challenge/ -d "*.isbn.ink" -d isbn.ink

命令也可以明确–server参数

sudo certbot certonly --webroot -w /dnmp/www/acme-challenge/ -d "*.isbn.ink" -d isbn.ink --server https://acme-v02.api.letsencrypt.org/directory

certbot如何安装请看https://certbot.eff.org/instructions?ws=nginx&os=ubuntufocal&tab=standard

按提示执行完就行了，甚至都自动创建好了更新任务，任务查看命令：systemctl list-timers

NEXT                        LEFT               LAST                        PASSED       UNIT                           ACTIVATES                       
Fri 2024-01-26 14:11:00 CST 19min left         n/a                         n/a          snap.certbot.renew.timer       snap.certbot.renew.service

ssl证书文件默认会放在/etc/letsencrypt下面，那么结合dnmp的env配置项：

NGINX_SSL_CERTIFICATE_DIR=/etc/letsencrypt

如果有其他站点需要用到NGINX_SSL_CERTIFICATE_DIR的默认配置./services/nginx/ssl，那么还有个办法，即使用ln到/etc/letsencrypt/live：

ln -s /etc/letsencrypt/live /dnmp/services/nginx/ssl

那么，在站点的conf文件中，对443部分的设置如下：

server {
    listen 443 ssl;
    server_name isbn.ink;
    charset utf8;
    #ssl on;
    ssl_certificate   /ssl/live/isbn.ink/fullchain.pem;
    ssl_certificate_key  /ssl/live/isbn.ink/privkey.pem;
    ssl_session_timeout 5m;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;

    root   /www/localhost;
    index  index.php index.html index.htm;

    location / {
        if (!-e $request_filename) {
            rewrite (.*) /index.php;
        }
    }

    location ~ [^/]\.php(/|$) {
        fastcgi_pass   php80:9000;
        include        fastcgi-php.conf;
        include        fastcgi_params;
    }

}

可以看到我把live放到了conf中，而没有放在NGINX_SSL_CERTIFICATE_DIR设置中，因为live/isbn.ink/fullchain.pem是个软地址，实际文件是指向../../archive/isbn.ink/fullchain1.pem的，这里用了两层父目录，站点域名一层，live占了一层，所以ssl的映射目录只能设置为/etc/letsencrypt。