AWS Lightsail 修改 DB 参数

AWS 推出的 Lightsail Database 是目前比较实惠的托管 DB 方案。不过相对来说,Lightsail 的控制面板功能较少,很多参数无法修改。经过搜索发现,其实我们有很多参数可以调,只是需要通过命令行的方式来调整。

准备工作

安装 aws-cli 工具

https://aws.amazon.com/cli/

https://lightsail.aws.amazon.com/ls/docs/en_us/articles/lightsail-how-to-set-up-and-configure-aws-cli

Linux:

sudo apt-get install awscli

MacOS:
brew install awscli

Python(通用):
pip install awscli

设置 Access Key

https://lightsail.aws.amazon.com/ls/docs/en_us/articles/lightsail-how-to-set-up-access-keys-to-use-sdk-api-cli

先在 (更多…)

在腾讯云 TKE 上使用 Helm 的几个小坑

首先,大家都懂,gcr.io 是连不上的,需要使用阿里云镜像或别的镜像

helm init --upgrade -i registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.13.0 --stable-repo-url https://kubernetes.oss-cn-hangzhou.aliyuncs.com/chart --service-account tiller

如果没注意已经部署了,可以先删除:
kubectl delete deployment tiller-deploy --namespace=kube-system

然后,helm install 可能会报没有权限:
Error: release xxx failed: namespaces "default" is forbidden: User <a href="https://maoxian.de/2019/03/1536.html#more-1536" class="more-link"><span aria-label="继续阅读在腾讯云 TKE 上使用 Helm 的几个小坑">(更多…)</span></a>

IPv6 地址处理时的小 Bug

众所周知,IPv6 地址中可以用 ::  来省略一连串的 0,于是,在某些情况下,如果 0 被过度合并了,就会导致地址解析的问题。

最近在 AWS 上启用 IPv6 的时候就遇到了这个情况,AWS 分配给我的地址段是:

2406:da14:5c9::/56

可以看出,AWS 实际给我分配的地址是:

2406:da14:5c9:0000::/56

但是由于连续 0 的省略策略,导致 5c9 之后的真正可以被划分的部分被省略了。于是在 AWS 的系统中,子网划分页面就显示成了这样:

2406:da14:5__::/64

按照正常逻辑应该是这样:

2406:da14:5c9:00__:/56

结果当然就悲剧了。这里我除了填 c9 之外,任何的值都会导致划分出的子网不在上面的地址段内,导致划分失败。

所幸的是 AWS 的系统可以随意的解绑地址段,然后重新分配。于是重新分配之后就好了。

不过这里也是对我们的一个提醒:由于 (更多…)

Tomcat 在处理 Cookie 的时候的几个小坑

今天在代码中调用 HttpServletRequest  对象的 getCookies()  方法时,发现实际得到的 Cookie 数量与提交的不符。实际提交了 17 个 Cookie,但是获取到的只有 14 个。

经过排查,发现如果调用 getHeaders(“Cookie”)  方法,获取原始的 Cookie 串,是可以拿到正确的 17 个 Cookie 组成的字符串的。于是确认应该是 Tomcat 在处理 Cookie 的时候进行了过滤。

经过一番搜索,发现了这个文档:

http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html

其中,跟 Cookie 相关的参数有:

org.apache.tomcat.util.http. ServerCookie.ALLOW_EQUALS_IN_VALUE If (更多…)

Nginx 诡异 SSL_PROTOCOL_ERROR 问题排查

这两天在检查一台 Nginx 配置的时候,遇到了一个极端诡异的问题。一段很通用的配置,配在这个服务器上,就会 100% 导致 Chrome 报 ERR_SSL_PROTOCOL_ERROR 。但是这段配置非常的通用,是用 Mozilla 提供的工具生成的。

而且在 iPhone 的 Safari 上访问又是完全正常的,服务器日志也看不到任何错误。看到的请求相应码也是完全正确的 200 。

先贴出配置:

# https://mozilla.github.io/server-side-tls/ssl-config-generator/
    listen 443 ssl http2;

    # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
    ssl_certificate <a href="https://maoxian.de/2017/12/1471.html#more-1471" class="more-link"><span aria-label="继续阅读Nginx 诡异 SSL_PROTOCOL_ERROR 问题排查">(更多…)</span></a>

MySQL 分区表的一些问题

最近在使用 MySQL 分区表的时候,研究了一下多列 Range 分区,也就是

PARTITION BY RANGE COLUMNS(`a`, `b`, `c`) (
    PARTITION p1 VALUES LESS THAN (0, 0, MAXVALUE),
    PARTITION p2 VALUES LESS THAN (10, 10, MAXVALUE),
    PARTITION p3 VALUES LESS THAN (20, 20, MAXVALUE)
)

在多列的情况下,MySQL 的分区策略和单列略有不同,这也是比较坑的地方,查遍所有文档都没人提到。。。

先说说单列 Range 分区。比如,如果这么写:

PARTITION BY RANGE(`a`) (
    PARTITION p1 VALUES LESS THAN (0),
  <a href="https://maoxian.de/2017/06/1458.html#more-1458" class="more-link"><span aria-label="继续阅读MySQL 分区表的一些问题">(更多…)</span></a>

nginx rewrite 的一个小坑

今天在配置 Nginx 的时候写了这么一个 location

location /a {
    rewrite /a/(.*) /$1 break;
    ...
}

然后发现当我直接访问 /a 的时候,rewrite 并没有生效,后端收到的还是 /a 而不是我想象中的 / 。想了想可能是结尾 / 的问题,于是这样改:
location /a {
    rewrite /a(.*) $1 break;
    ...
}

结果新的问题来了,由于这样匹配到的 $1 是空的,所以 Nginx 报错了,the rewritten URI has a zero length

所以这种情况下只好这么写:

location /a/ {
    rewrite /a(.*) $1 break;
    ...
}

注意第一行的末尾 / 。这种情况下,访问 /a 会被 (更多…)

Nginx 配置 ECC RSA 双证书

Config Nginx for parallel ECC and RSA Certificate

先决条件

Nginx 1.11.0 以上

OpenSSL 1.0.2 以上

申请证书

首先申请 ECC 证书,这个不多说,很多方法都可以,大部分 CA 现在也都可以签署。生成 CSR 的命令是:

openssl ecparam -out 证书名.key -name prime256v1 -genkey && openssl req -new -key 证书名.key -nodes -out 证书名.csr

拿到证书之后,还是像之前一样将中级 CA 拼接在证书后面,得到给 Nginx 使用的 domain-cert.crt

配置 Nginx

首先是将两个证书链都加入 Nginx 的配置文件:

ssl_certificate     example.com.rsa.crt;
ssl_certificate_key <a href="https://maoxian.de/2016/08/1436.html#more-1436" class="more-link"><span aria-label="继续阅读Nginx 配置 ECC RSA 双证书">(更多…)</span></a>

MySQL 隐式转化整理

前几天在微博上看到一篇文章:价值百万的 MySQL 的隐式类型转换感觉写的很不错,再加上自己之前也对MySQL的隐式转化这边并不是很清楚,所以就顺势整理了一下。希望对大家有所帮助。

当我们对不同类型的值进行比较的时候,为了使得这些数值「可比较」(也可以称为类型的兼容性),MySQL会做一些隐式转化(Implicit type conversion)。比如下面的例子:

mysql> SELECT 1+'1';
        -> 2
mysql> SELECT CONCAT(2,' test');
        -> '2 test'

很明显,上面的SQL语句的执行过程中就出现了隐式转化。并且从结果们可以判断出,第一条SQL中,将字符串的“1”转换为数字1,而在第二条的SQL中,将数字2转换为字符串“2”。

MySQL也提供了CAST()函数。我们可以使用它明确的把数值转换为字符串。当使用CONCA()函数的时候,也可能会出现隐式转化,因为它希望的参数为字符串形式,但是如果我们传递的不是字符串呢:

mysql> <a href="https://maoxian.de/2016/06/1427.html#more-1427" class="more-link"><span aria-label="继续阅读MySQL 隐式转化整理">(更多…)</span></a>

退出当前 Bash Shell 并不保存历史的 5 种方法

某些时候我们希望在退出 Bash Shell 的时候不要保存执行命令的历史记录,那么可以用以下几种方法来实现:

先说两个不影响以前的历史记录的方法:

1. 修改 HISTFILE 变量

unset HISTFILE && exit

2. 直接 Kill 当前 Shell

kill -9 $$

下面三个方法会清除所有的记录:

3. 清除历史记录并退出

history -c && exit

4. 设置历史记录保存数量为 0 条并退出

HISTSIZE=0 && exit

5. 删除历史记录文件并修改 HISTFILE 变量

rm -f $HISTFILE && unset HISTFILE && exit

如果你想每次都自动执行这些命令,可以在将对应的指令添加到 ~/.bash_logout 文件中,或者使用 alisa 功能。

译自:http://www.if-not-true-then-false.com/2010/quit-bash-shell-without-saving-bash-history/