Vigilans

Using the provided schema in vscode fixes the issue: ```json "yaml.schemas": { "https://raw.githubusercontent.com/compose-spec/compose-spec/260582406ace6cf4f239ea861903549bb97c45eb/schema/compose-spec.json": "{docker-compose*.yml,compose*.yml}", } ```

# Proposal: Recommended practice for component switching This proposal proposes a better way to manage a compose project of multiple components: use `include` + `profiles` + `depends_on.profiles`. ## Environment setup...

Quoted from https://github.com/docker/compose/issues/10993#issuecomment-1771367757: > While skimming through this issue and related PR, I came up with these two questions: > > * When using `up` (without profiles), should the dependency...

Actually fixed by https://github.com/miquels/webdav-handler-rs/pull/11. However there is no review nor comment from the author for two years. If @messense would like to also maintain https://github.com/miquels/webdav-server-rs, I am happy to port...

~~经过测试，BusyBox直到v1.25.1以前，不支持`--no-check-certificate`参数。（这也意味着即使在https://github.com/rehiy/dnspod-shell/pull/111/files#diff-b9e95544319203cd4295d11dbb63f18712514497bfbfdddca4b8919e0e1399adR117 的改动之前，在v1.25.1版本以下的BusyBox执行脚本也是会失败的）~~。 检查了BusyBox源码，`--no-check-certificate`选项早在2010年就添加了，上面的测试是在alpine做的，在别的busybox镜像里，更低的版本反而也能使用--no-check-certificate。似乎是否有这个选项是由编译时的FLAG（是否支持SSL）控制的，所以还是检查一下选项是否存在比较好。 我会再细化一下BusyBox的检查逻辑发上来。

> 收到，感谢，更新后第一时间测试。另我是在Padavan路由器固件里使用的。 @withero 刚刚测试那些没有`--no-check-certificate`选项的似乎都不支持HTTPS访问，所以可以先试下`wget -O- https://baidu.com`能不能使用？ 如果上面`https://baidu.com`访问没问题的话，试下直接使用下面命令： ``` wget -q -O- --no-check-certificate -U "AnripDdns/6.2.0([email protected])" --post-data "login_token=&format=json&lang=en" https://dnsapi.cn/Info.Version ``` 看看wget会不会有报错？ 如果服务器正常返回了一个JSON（版本信息），可以再使用下面的命令： ``` wget -q -O- --no-check-certificate -U "AnripDdns/6.2.0([email protected])" --post-data "login_token=&format=json&lang=en&domain=&sub_domain=&record_type=A" https://dnsapi.cn/Record.List...

> 刚又试了下，之前子域名解释在CNAME上的，所以没成功，换到A记录就正常了。看到了Operation Successful记录 修改到A记录后，`ddnspod.sh`是否能正常使用了？ > 因为这个状况脚本里不知道能不能自动禁用CNAME换成启用或新增A记录。 @withero 这个可以参考作者在https://github.com/rehiy/dnspod-shell/issues/94 里的回复： >> Q: 现在我要解析一个新的域名，必须先去dnspod建一个才能用这个解析，能不能一步到位？ > >> A: 这样的操作有些越权 --- 不知你的CNAME使用场景如何，我个人也是在使用CNAME记录的，我的理解和设计思路是： * A/AAAA记录的域名应尽可能详细地描述这个IP的特征，并通过DDNS更新； * CNAME记录作为“引用”或“别名”，用来指向一个具体的A/AAAA记录，或是套娃另一个CNAME记录，从而简化域名/表示一个解析策略。 按照以上理解，CNAME记录应该是在dnspod里一开始就静态写好的，并且不应被用于DDNS，从而只要网络拓扑没有改变，没有更新的必要。 举例：某域名为`test.domain`，然后在上海有一个同时接入了三大运营商宽带的路由器（并在如杭州等城市也有自己管理的路由器设备），可以这样设计域名： * 上海电信路由器（A/AAAA）：`sh.telecom.router.test.domain` * 上海联通路由器（A/AAAA）：`sh.unicom.router.test.domain` * 上海移动路由器（A/AAAA）：`sh.cmcc.router.test.domain`...

@withero 试着使用一下 https://github.com/Vigilans/dnspod-shell/blob/vigilans/debug-%23113/ardnspod 里更新的脚本，把输出日志贴到issue里看看？ 我在Fetching RecordId相关的每一步添加了debug输出，这样来定位一下你那一边具体的报错_(:з」∠)_ 添加的内容见https://github.com/Vigilans/dnspod-shell/commit/14af0da65ba4a5b8454be3558d14b6079ff571a9

> arDdnsApi - calling curl > arDdnsApi - dnsapi output: 所以你的路由器有`curl`，并且v6.2脚本优先调用了`curl`，且没有任何输出。 而v6.1分支里是优先调用wget的： https://github.com/rehiy/dnspod-shell/blob/404b48f5468e0e401301f7f23667f39eff417c3e/ardnspod#L119-L123 因此对应上面我们对`wget`作的没问题的测试，能够正常使用。 所以再直接测试一下下面的命令？ ``` curl -4 -s -A "AnripDdns/6.2.0([email protected])" -d "login_token=&format=json&lang=en&domain=&sub_domain=&record_type=A" https://dnsapi.cn/Record.List ``` 如果像上面日志一样没有任何输出的话，去掉`-s`，加个`-v`试试： ``` curl -v -4...

@withero 所以应该是padavan路由器里缺少了ca-certificates导致的……`wget`里用了`--no-check-certificate`，所以不会校验证书，没有ca-certificates也没事。 试着加上`-k`（也即`--insecure`）选项？ ``` curl -v -4 -k -A "AnripDdns/6.2.0([email protected])" -d "login_token=&format=json&lang=en&domain=&sub_domain=&record_type=A" https://dnsapi.cn/Record.List ``` 以及可以试试在上面wget命令里去掉`--no-check-certificate`选项，估计会有类似的报错。 检查`ca-certificates.crt`是否存在：`cat /etc/ssl/certs/ca-certificates.crt`