从神州租车更改手机号，看数据库关系设计

Posted on 2019年 05月29日 by admin

我搬来深圳之后，就换了手机号。为了应对一些出行需求，我就打算从神州租车租辆车来用。用新手机号注册之后提交身份证，结果提示该身份证已经被占用。联系客服，说是一个135的北京手机号占住了，还提示我以前在嘉峪关租过车，客服可以帮忙把这个135的登录手机号改成我的新手机号。我检查了一下通讯录，认识，跟他打了招呼之后就同意了客服的做法。

但其实，这个事情暴露了神州租车方面的数据库强关系设计，与实际业务冲突的问题。我和这位朋友之前两次一起租车，因为他当时还不会开车，所以登记了我的证件，但后续他仍有使用此注册名租车的业务需求啊。身份信息应该关联在“一次租车行为”而不是关联在“一个注册用户”身上，也就是每次发生租车行为的时候，把身份信息从注册信息复制过来，或者由门店人工录入身份信息到“一次租车行为”的数据库记录里。

这不是关系范式之间来回迁移，而是正确与错误的区别。

联想到以前在美团我们自制的一个用作软件版本发布的小系统，旧的设计并没有把“发布功能相关设置”关联到“一次发布行为”，而是关联到“要发布的应用”，以至于检查每一次发布行为到底为啥不正确的时候，根本不敢确定设置页面里看到的设置就是当时生效的设置。

这个错误在后面重构中被推翻了。

Posted in 默认分类 | 1 Comment

配置管理 vs provisioning 及配置管理工具的几点随想

Posted on 2018年 11月7日 by JulyClyde

关于“怎么构建一个确定的运行环境”这件事，有多个流派，其中一个是配置管理，另一个是provision流。

配置管理流派，适合于物理服务器、虚拟机等等，有机会长期存活的环境。因为它们有机会长期存活，在其生命周期里需要使用技术手段去维持一个有序可控的状态，排除软件运行时累计的旧日志和临时数据、手工操作带来的计划外变更等等影响。

而provision流派，直接从模版构建一个（容器或虚拟机）实例起来运行，用完就扔，基本上没有重新调整的价值。这种东西往往依赖于服务注册与发现机制，因为在它真正起来运行之前，网络通信方面的参数无法被外界预知，外界不知道如何跟它通信；对于日志和数据，也提倡使用显式远程的方式去访问。

 

再说说配置管理工具的几点随想：

我最近一年在给下属的一个公司做一些产品运维工作，其中遇到把设备投放到客户的网络环境去运行这种情况。考虑到网络通信的问题，我只好选择了“反向连接”的saltstack软件。在通信的角度来考虑，配置管理工具可以分为：master主动连接minion（ansible等）、minion主动连接master（puppet、saltstack等）

今天听师兄说他的一个同事因为认知问题，把一批机器glibc给删掉了。尝试恢复的时候，他发现ansible无法正常运行（我猜想sshd启动python的时候因为缺glibc而失败了），只好改用saltstack。因为saltstack的salt-minion是长期运行的，一旦启动之后，外部依赖较少，才能在glibc被删除这么极端的条件下苟活。在“有没有agent”的角度考虑，配置管理工具可以分为：有agent（saltstack、puppet、cfengine等）和无agent（ansible等）

另外，其实还有一个分类角度，就是主动和被动。saltstack和ansible是主动式的，运维工程师可有更多的主动权，可以用手工指定minion，或者指定批次规模分批执行等手段，控制变更的节奏；cfengine、puppet等是agent定时刷新式的（虽然听说也可以主动？不过我经验较少还没用过），得按定时器来，这种情况下就得运维工程师多看监控了，一不小心，死都不知道怎么死的。

Posted in 默认分类 | Tagged | Leave a comment

在嵌入式开发板上使用蓝牙耳机

Posted on 2018年 01月23日 by admin

简单记录一下：

  • 安装 bluez pulseaudio-module-bluetooth 软件包
  • pulseaudio是用户级后台服务，视情况可能需要手工-D启动之
  • bluetoothctl命令进入交互式界面，先scan on 等看到蓝牙耳机之后，pair和connect到蓝牙耳机的MAC地址，看到连接成功之后scan off并退出bluetoothctl
  • pactl list sinks查看设备，看看它支持哪些profile，有可能需要通过pactl set-card-profile将其切换到a2dp
  • aplay -Dpulse 指定pulse虚拟设备播放文件

还没搞定录音。看起来话务耳机在handfree等模式似乎需要特殊步骤激活录音模式？

Posted in 默认分类 | Tagged , | Comments Off on 在嵌入式开发板上使用蓝牙耳机

hostname和dnsdomainname命令

Posted on 2017年 12月14日 by JulyClyde

先讲结论：

忽略已经过时的NIS/YP相关内容（/sbin/sysctl kernel.domainname、/bin/domainname、/bin/nisdomainname、/bin/ypdomainname等）

/bin/hostname、/sbin/sysctl kernel.hostname 和 /bin/uname -n 是一码事，都是本机的主机名

/bin/dnsdomainname 命令会把上述主机名按“第一个点”分成两端，输出后一段。这是简单的字符串处理的结果，在内核和DNS层面均无正式意义。

/etc/resolv.conf文件里的search或domain指令，用于从本机访问外部短主机名时，补充域名的后缀部分。

 

hostname命令：

通过gethostname(2)函数读到本机的主机名。在glibc的情况下，gethostname(2)不是syscall而是标准库函数，转而调用uname(2) （我不太确认调用的是glibc uname还是syscall uname）。根据 https://github.com/torvalds/linux/blob/master/Documentation/sysctl/kernel.txt#L285 的说法，/proc/sys/kernel/hostname、sysctl hostname 和hostname命令应该是功能相同的。

hostname -d 或者 dnsdomainname 命令：

根据/etc/host.conf指定的顺序，先尝试/etc/hosts然后尝试DNS，查找自己的主机名。如果能找到，把第一段去掉之后，输出剩下的部分。这个输出不具备内核意义，只是主机名经过字符串处理之后的派生结果

hostname –fqdn命令：

getaddrinfo()函数查询到的ai_canonname

strace观察到的行为是去DNS查一下主机名（如果主机名是短形式，按需补充/etc/resolv.conf里声明的search/domain后缀）对应的A记录，只要能查到，即使返回的IP地址不是本机的也不管，就以这个主机名作为结果。

hostname –all-fqdn命令：

拿自己的IP地址们循环调用getnameinfo()函数（strace/tcpdump观察到的具体行为是去DNS查PTR记录），并全部输出

Posted in 默认分类 | Tagged , | Leave a comment

为什么有些系统是动作式的而非描述式的？

Posted on 2017年 07月1日 by JulyClyde

接手一个旧系统，上线发布是“拷贝文件过去，替换掉，重启服务”这样的，而不是“把编译好的东西打包，发上去安装，包的scripts部分带有重启动作”。

是否打包、包里包含什么，很有讲究：

  • 查询当前版本号：XXX -v vs rpm -qi XXX
  • 重启服务：killall XXX && sleep 30 && XXX vs /sbin/service XXX restart
  • 删除软件：rm -fr XXX vs rpm -e XXX
  • 安装依赖： ldd XXX |xargs -n1 yum provides |xargs yum -y install vs rpm -i XXX

……不胜枚举

描述式的好处是可以由机器自动评估效果，而动作式的效果需要人工评估。

描述式的好处的携带的信息（比如依赖关系）更丰富，而动作式的有可能在一开始就没收集齐足够的信息。

Posted in 默认分类 | Tagged | Leave a comment

placeholder 2016年10月欧洲之行

Posted on 2017年 02月28日 by admin

6月办签证，因为英国当时在闹脱欧，签证审批速度大大降低，耽误了办理申根，连瑞航机票都耽误了。所以决定10月辞职后再去。

临辞职，拿了在职证明去办法国申根，但忘记提前买好英法之间欧洲之星国际列车的票，后来多花了好多钱

走之前没查时区，10天行程调了5次时区，痛不欲生

不喜欢法国的繁复建筑物，但很爱她的博物馆们；塞纳河左岸下午照不到太阳，是酸臭文人吹捧起来的地方。

英国很有沉淀感

国际标准时间曾经是巴黎天文台，但英国人解决精度问题之后，标准时间变成了“比我巴黎时间晚9分9秒的‘那个时间’”

Posted in 默认分类 | Tagged , , | Leave a comment

django database router是个好东西

Posted on 2016年 09月28日 by admin

今天给sentry加了MySQL读写分离机制，记录一下：

DATABASES里，（sentry的脾气比较怪）保留名为default的配置，写master数据库的参数；新增一个名为slave的配置，使用只读用户名密码，或开启服务器端read only
然后增加一个类，带四个函数：

class DatabaseRWSplitRouter(object):
    def db_for_read(self, model, **hints):
        return 'slave'

    def db_for_write(self, model, **hints):
        return 'default'

    def allow_relation(self, model1, model2, **hints):
        return True

    def allow_migrate(self, db, app_label, model_name=None, **hints):
        if db == 'slave':
            return None
        else:
            return True

再把这个注册进去

DATABASE_ROUTERS = (DatabaseRWSplitRouter(), )

注意这个注册，可以写字符串形式的dotted_path也可以是一个对象，我偷懒就直接写了一个对象。

Posted in 默认分类 | Tagged , , | Leave a comment

内训教程释出：from CGI to WSGI

Posted on 2016年 09月2日 by admin

古代时，读过MSDN里的《from C++ to COM》受益匪浅。后来学习Python，自己也写了一篇 from CGI to WSGI 的教程，用于内部培训。

https://julyclyde.org/pyCGIWSGI.pdf

Posted in 默认分类 | Tagged | Leave a comment

给rq添加了RedisCluster支持

Posted on 2016年 08月23日 by admin

最近一直在和前同事Puff潘、RainSun吕合作，做一些给使用redis的软件增加redis cluster或者redis sentinel支持功能的工作。

传统上，做sharding工作有三种做法：

  1. 客户端支持，比如redis cluster客户端需要支持KeySlot计算（我报告的bug: https://github.com/Grokzen/redis-py-cluster/issues/153）
  2. 代理层支持：twemproxy、codis等
  3. 服务器端支持：比如MySQL partition table之类

我比较推崇的是第二种，但redis的cluster和sentinel都属于第一种，客户端需要有明确的能力和知识去处理连接多个服务器的问题，而这方面，各常见客户端库做的并不好。另外还有个问题是用Python语言写的各应用软件，往往直接写死了用redis库，而不是用rediscluster库或者运行期动态决定，导致根本不具备使用cluster的能力。

近期在看rq的时候，发现rq支持custom worker class，于是我就改了改，让它也支持custom connection class，并说服了作者merge进来。

https://github.com/nvie/rq/pull/741

不过其实我觉得还是略别扭。主要是因为生成connection对象的时候套了两层函数，为了补全function signature，并尽量减少其它代码的修改，不得不在两层都使用参数默认值，显得多余。尽管如此，还是很为自己能为基础软件做出贡献而感到高兴的。

Posted in 默认分类 | Leave a comment

kube-proxy –proxy-mode=iptables 与 rp_filter 冲突

Posted on 2016年 08月11日 by admin

2015年12月16日，朱鹏安装了新版kubernetes master版本（比1.1新，为1.2alpha**），然后发现，访问 clusterIP:clusterPort 会发生无法连接的故障。

从集群内Node上访问

分别在Node rz-ep19和container里执行curl访问，发现container里curl可以成功访问，但Node上一般不行（偶尔成功，几率很低）。查看iptables规则，发现新版kube-proxy已经不再将请求REDIRECT到本机kube-proxy端口，而是：

  1. 先把PREROUTING、OUTPUT无条件指向KUBE-SERVICES链；如匹配不上KUBE-SERVICES链，则再尝试匹配发给docker0
  2. 在KUBE-SERVICES链里匹配clusterIP:clusterPort条件，然后发到KUBE-SVC-***链
  3. 在KUBE-SVC-***链中，用-m statistic –mode random –probability这样的条件将流量按等比例分给多个KUBE-SEP-***链
  4. 然后再在KUBE-SEP-***链中，将数据包DNAT给endpoint

为了减少干扰，我们缩减了kube-system/elasticsearch-logging 10.16.59.73:9200服务的规模，到只有一个endpoint 172.16.86.48:9200运行在rz-ep10上；rz-ep19 10.16.49.16作为运行curl的客户端

  • 在rz-ep19的flannel接口上抓包，抓到了 10.16.49.16->172.17.86.48的TCP SYN，但没有收到回应。
  • 在rz-ep10（endpoint Pod所在的Node）的flannel接口上抓包，抓到了和上述相同的包，也没有收到回应。
  • 在rz-ep10的docker0接口上抓包，没有抓到

由此判断，rz-ep10的内核在转发时主动丢弃掉了 10.16.49.16->172.17.86.48的SYN，以至于无法建立TCP连接。查看/proc/sys/net/ipv4/conf/{all,flannel.7890}/rp_filter，发现flannel.7890/rp_filter内容为1，即在此网卡上执行“根据回溯路由检查数据包是否为伪造”的检查。因为源IP 10.16.49.16在rz-ep10看来理应出现自eth0而非flannel.7890接口，所以被判定为假造包，丢弃。

将此参数改为0，再去docker0上抓包，可以收到172.17.86.48发回10.16.49.16 SYNACK包；但rz-ep19上curl仍显示无法建立连接。

在rz-ep10的角度考虑，这个172.17.86.48->10.16.49.16的包应该从eth0发出，也就是在rz-ep19的eth0上收到。而在rz-ep19的角度考虑，源IP 172.16.86.48不应来自eth0，也会被rp_filter参数影响，丢弃掉，所以无法建立连接。把rz-ep19的eth0/rp_filter参数改为0，终于可以正常访问了。

 

plantuml9098040596798137974

 

从集群外访问

从办公区我的笔记本电脑 172.30.26.169 访问 10.16.59.67:80 服务，该虚IP被手工绑在rz-ep01上，ping可以通，但访问不通。

在笔记本电脑上抓包，发现只有从本机发往clusterIP的SYN包，没有返回，所以无法建立TCP连接。

改以Pod IP为过滤条件，发现Pod IP直接发回 SYN_ACK给我的笔记本电脑，但因为笔记本电脑这边没有发起对Pod的SYN，所以直接回复RST给Pod了。

改用iptables模式之后，由于不对称路径的问题，这种访问基本上无法以以前“把clusterIP绑在Node上”的做法实现

Posted in 默认分类 | Tagged | Leave a comment