OpenWrt中通过自定义脚本为Cloudflare域名更新DDNS

　　在上一篇文章中，威联通NAS上myQNAPcloud DDNS获取外网地址不准确的问题，提到使用myQNAPcloud服务来设置DDNS。这次尝试不依赖QNAP的服务，在OpenWrt里定时运行自定义脚本来直接更新域名的DNS地址。

　　我的域名托管在Cloudflare上，所以主要思路是定时在OpenWrt里运行脚本检测公网IP地址是否有变化，如果有就用Cloudflare的token和API来更新相关DNS设置。

　　记录具体步骤如下：

1. 获取Cloudflare的API token，稍后脚本中会用到。进入 https://dash.cloudflare.com/profile/api-tokens 页面，Create Token，为了使token权限最小化选择Create Custom Token，设置如下图。Specific zone选项可限制token权限为仅允许更新某一个域名。

    - 

2. 在上面所选域名的DNS设置中，添加一条A记录，设置成DDNS想要绑定的域名。IP地址随意设置比如8.8.8.8（之后脚本会付覆盖），Proxy status设置为DNS only。

3. OpenWrt运行的脚本。参考了一些网上的脚本，发现 https://raw.githubusercontent.com/K0p1-Git/cloudflare-ddns-updater/main/cloudflare-template.sh 这个脚本比较全面，注释也清楚。几点注意事项：

    - 第一行的`#!/bin/bash`需要修改成`#!/bin/sh`，否则OpenWrt中没有bash环境无法运行。

    - 要填写的项目有auth_email，auth_key，zone_identifier，record_name，其余可留空。

    - auth_method="token" 注意保持token方式，对应步骤1中创建的API token。同一页面还可看到Cloudflare的Global API Key，因为它可以操作账户里的所有设置，不建议使用。

    - 如果OpenWrt设置了科学上网/透明代理，`curl -s -4 https://cloudflare.com/cdn-cgi/trace`运行时可能获取到代理服务器的ipv4地址。可以注释掉相关if判断部分，改为用其它API直接获取，即`ip=$(curl -s https://api.ipify.org || curl -s https://ipv4.icanhazip.com)` 。

4. 用scp命令将修改好的脚本上传到/root目录，`chmod +x updateDDNS_cloudflare.sh`赋予执行权限。先手动运行一次观察输出是否正常`/bin/sh -x updateDDNS_cloudflare.sh`。如果脚本运行无误的话，可以在Cloudflare中观察到对应A记录的DNS更新成功。

5. `crontab -e`编辑计划任务，添加一行内容`*/10  *  *  *  *  /root/updateDDNS_cloudflare.sh`，这样此脚本会每10分钟运行一次以按需更新DDNS。此步骤也可在OpenWrt网页端的“系统->计划任务”里完成。

　　其实同样的工作也可以在OpenWrt的web管理页面上完成，如果你可以在“服务->动态DNS->DDNS 服务提供商 [IPv4]”的设置中找到Cloudflare选项的话。我用的OpenWrt编译了动态DNS的应用（luci-app-ddns， ddns-scripts），但没有Cloudflare的入口点。尝试安装ddns-scripts-cloudflare或更早的ddns-scripts_cloudflare.com-v4_2.7.8-3_all.zip，不仅依然找不到Cloudflare入口点，还有可能破坏掉OpenWrt：实际后台依然运行，可以上网，但web页面（LuCI web interface）报错`Bad Gateway The process did not produce any response.`，只能借助ESXI里的快照恢复或重新安装OpenWrt。所以才有了这篇博客。 

北京联通烽火HG220G-U光猫升级+路由改桥接

　　去年家里宽带升到200M之后，因为原先的光猫是百兆LAN口，网速受限，所以打联通客服要求换一个千兆LAN口的光猫。当时说我们这片只有烽火HG220G-U个型号的二手光猫支持千兆了，于是就先用着，还算稳定，但发现光猫的工作模式被锁死在路由模式下，不像原来的百兆光猫是桥接模式，这样光猫后面的路由器就没法拨号，导致路由后的NAS没法从外网直接访问，又用回了之前的SSH反向端口转发的办法。
 　　后来又联系过两次联通客服，总说新猫没有到货，于是想看看有没有什么办法自己解决。找到了老周部落贴吧里的《烽火HG220G-U E00L2.03M2000光猫改桥接教程》，修改完成后发现光猫确实按桥接模式工作了，路由器也能正常拨号上网，但网速从200M降到了不到100M，发现是因为光猫的固件版本掉坑里了，2.02版本的光猫确实会出现改桥接后掉速的问题。当时也没找到升级光猫固件的办法，无奈又改回了路由模式。
 　　昨天恰好看到老周部落贴吧里的又出了新文章《北京联通烽火HG220G-U/HG221G/HG260G-U/HG261G互通型HGU升级指导》，先看了下跟贴，发现有一人情况和我一样，原来是2.02版本，想通过升级再改桥接。但他升级到最新2.04版本后，改完桥接依然掉速。

本想希望不大，抱着试试看的心态也升级了家里的光猫固件版本，但没有直接升到最新的2.04，而是到之前教程里改桥接肯定没问题2.03版本，然后改桥接，路由拨号，测试，200M->200M。又可以从外网愉快的访问NAS啦～

家用（影像）存储及备份方案选择

　　随着家庭成员和移动设备的增多，我们日常生活中越来越频繁地产生着各种照片和视频文件，日积月累，这些数字资料的保存，读取，备份或早或迟都会成为困扰你的一个问题。

　　先来说说存储。我们移动设备存储空间满额的时候，最先想到的是把照片和视频导出保存到电脑硬盘上；而你肯定经历或者听说过硬盘坏掉这件事情，所以你可能觉得电脑硬盘靠不住了，买个移动硬盘来寸照片和其他重要资料吧，一来不用天天通电读取，看起来寿命似乎要更长，二来可以当作备份使用。但仔细想想，移动硬盘只不过是一个体积更大，容量更大的u盘（而且抗震性能还不如u盘），把你认为重要的资料存在u盘里可靠吗？你听说周围朋友移动硬盘坏了，丢了的情况多还是他说我家里台式机硬盘坏了的情况多？既然台式机硬盘无法保障我的照片和视频，更好的方案是什么呢？答案就是NAS。关于NAS的介绍大家可以自己google一下，品牌一般就是Synology（群晖）和QNAP（威联通）二选一。而当你使用NAS超过一段时间后，会发现对NAS硬盘里的资料进行备份又变成一个不可避免的话题。虽然比台式机硬盘坏掉概率要小很多，但只要发生，对于你的资料就是100%的丢失。

　　再来说说备份。如何对NAS上的资料进行备份呢？通常NAS里不仅有比较珍贵的照片和视频，可能还有不太重要的一堆高清电影。最先想到的办法是多块硬盘做RAID1或者RAID5。前者硬盘空间浪费多，后者对NAS硬件级别又有要求（最少3块硬盘）。自己手上的QNAP 212P是比较低端的NAS，虽然有两个盘位，但发现做RAID1的话需要自己把现有资料备份，然后塞两块硬盘进行重新格式化，之后再把备份的数据倒回去；想做热备份的话就得换更好的NAS。前者需要多加一块硬盘，外加数据导入导出，成本1000元左右；后者换NAS，加硬盘，成本更高。

　　最后目光又落回了云存储上面。之前也看到NAS里有应用可以备份本地数据到云存储上面，一般都支持增量备份及本地/云端双向同步备份，足够满足需求了。但感觉有额外的费用，没有细想。这回重新计算一下成本发现，云存储的备份办法确实比较划得来。目前需要备份的照片和视频差不多有100G，按照AWS S3最贵的Standard存储级别0.03美元/GB/月来算，就算200G数据，每月成本6美元，2年的成本大约1000人民币，相比加硬盘，换NAS来说更有优势。因为目前家用NAS正在快速普及，两年后NAS功能，硬盘容量，成本几何都是未知数。

　　　下来就比较一下可选的云存储方案。能考虑的也就是三家，亚马逊的AWS S3，谷歌的Google Cloud Storage和微软的Azure Storage。从信誉度来说国内的各种所谓云计算直接pass，从持久性来说微软的Azure也pass，不是说Azure的durability不行，而是怕微软的Azure哪天就不行了。。。S3中的Glacier响应速度4小时，就不用考虑了；S3还有一个Reduced Redundancy Storage（RRS）的durability是99.99%，相比其他剩余选项的99.999999999%来说，在成本差别不大的情况下也可以淘汰掉。剩余的选项对比如下：

	AWS S3 Standard	AWS S3 Standard – Infrequent Access	GCD Standard	GCD Durable Reduced Availability	GCD Nearline Storage
Durability	99.999999999%	99.999999999%	>= 99.9%	>= 99.0%	>= 99.0%
Availability	99.99%	99.99%	“High availability”	“Lower availability than Standard”	“Lower availability than Standard”
Storage Pricing (per Month)	$0.03 per GB	$0.0125 per GB	$0.026 per GB	$0.02 per GB	$0.01 per GB
Data Transfer Pricing	$0.09 per GB	$0.09 per GB	$0.012 per GB	$0.012 per GB	$0.012 per GB
Retrieval Fee	-	$0.01 per GB	-	-	$0.01 per GB

　　其中，S3的价格以us-east为准；Data Transfer即是数据下载到本地的价格（存储收费，下载消耗网络带宽也要收费），而Google Cloud Storage还要区分下载到哪，大部分地区是$0.012/GB，而下载到中国（可能吗？）和澳大利亚地区费用更高；Retrieval Fee是价格保护策略的收费，对于价格更低的AWS S3 - IA和Google的Nearline Storage来说，本身存储成本低，划算，所以设置了额外的费用增加使用成本，也就下载是除了Data Transfer的费用外还要额外收取$0.01 per GB的费用；此外的Request Pricing（请求次数的费用）很低，可以忽略不计。

　　Google Cloud Storage和S3的设计理念完全一致，IAM管理，bucket，object，storage class等，但控制台界面的友好性，即使用策略的灵活性来说（S3允许单向切换Storage Class，Google不行；S3的Life Cycle策略的应用粒度可以到bucket内的某个/某些文件夹，google不行），AWS完胜Google。另外，虽然家里已经有能翻墙的路由器，但在其他网络上访问Google的数据的不便利性，也是需要考虑的一个因素。

　基于上面的数据，和大约200GB左右的数据量，几乎完全是单向备份，极少机会会下载到本地（除非NAS硬盘坏掉）的使用场景来看，AWS S3 Standard – Infrequent Access是最好的选择。最后从安全性上来说即使RAID1，硬盘加再多也有可能出事故，比如搬家时摔坏了，丢掉了；云存储可以防止此类隐患，理论上来说即使地震也不怕了。。。当然地震后你本人仍要有能够访问云端数据的机会：）

参考：
1. Amazon S3 Storage Classes
2. Amazon S3 Pricing
3. Google Cloud Storage Storage Class
4. Google Cloud Storage Pricing
5. Google Cloud Storage SLA

Windows下删除过长路径下文件(夹)的办法

有时候在Windows下删除文件或文件夹会碰到如下错误：

The source file name(s) are larger than is supported by the file system. Try moving to a location which has a shorter path name, or try renaming to shorter name(s) before attempting this operation.

或

文件名对目标文件夹可能过长。您可以缩短文件名并重试，或者尝试路径较短的位置。

解决的办法是在命令行输入：

robocopy /MIR c:\a d:\xxx

其中c:\a是c盘新建的一个空目录，d:\xxx是路径过长的文件(夹)的根目录。执行后，你会发现d:\xxx目录已经被清空了。

使用AWS CodeDeploy的几点注意事项

AWS CodeDeploy是亚马逊云计算提供的服务之一，用来将代码更容易地部署到EC2实例或私有云实例中。

它能够根据用户配置，从S3或Github上获取最新代码，并按照用户提供的appspec.yml配置文件，在不同的hook事件阶段执行不同的脚本文件，从而使代码部署过程自动化。

比如你可将多个EC2实例分为Dev，QA，PRD三组，通过结合CodeDeploy和其他CI工具(如Jenkins），自动化完成持续交付（部署到Dev/QA实例上），持续部署（部署到PRD实例上）的任务。

在使用CodeDeploy的过程中，有以下几点事项需要注意：

• 所有EC2实例上必须安装CodeDeploy Agent服务，EC2实例之所以会响应CodeDeploy服务，都是由CodeDeploy Agent来完成工作的。
• 默认CodeDeploy Agent是通过root用户安装的，所以appspec.yml中执行脚本时，默认是以root用户身份执行。而我们的代码中用到了PM2，执行PM2命令（如pm2 start）时，需要在appspec.yml中指定以ec2-user用户执行脚本，否则相关命令执行时，会导致EC2实例cpu持续占用100%，最终导致超时而部署失败。
• sudo: sorry, you must have a tty to run sudo问题。在sh脚本中，如有需要sudo执行的命令，则需在所有EC2实例的/etc/sudoers文件中，注释掉“Default requiretty”一行。
• /bin/bash^M: bad interpreter: No such file or directory问题。这是因为在windows操作系统上修改了.sh文件，导致文件末行编码不同，而在linux机器上无法执行。解决办法是在linux机器上重新保存该文件，或在windows上用sublime打开该文件，View->Line Endings->选择Unix，保存即可。