Category Archives: 默认分类

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

简单记录一下: 安装 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命令

先讲结论: 忽略已经过时的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

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

接手一个旧系统,上线发布是“拷贝文件过去,替换掉,重启服务”这样的,而不是“把编译好的东西打包,发上去安装,包的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 … Continue reading

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

placeholder 2016年10月欧洲之行

6月办签证,因为英国当时在闹脱欧,签证审批速度大大降低,耽误了办理申根,连瑞航机票都耽误了。所以决定10月辞职后再去。 临辞职,拿了在职证明去办法国申根,但忘记提前买好英法之间欧洲之星国际列车的票,后来多花了好多钱 走之前没查时区,10天行程调了5次时区,痛不欲生 不喜欢法国的繁复建筑物,但很爱她的博物馆们;塞纳河左岸下午照不到太阳,是酸臭文人吹捧起来的地方。 英国很有沉淀感 国际标准时间曾经是巴黎天文台,但英国人解决精度问题之后,标准时间变成了“比我巴黎时间晚9分9秒的‘那个时间’”

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

django database router是个好东西

今天给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 … Continue reading

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

内训教程释出:from CGI to WSGI

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

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

给rq添加了RedisCluster支持

最近一直在和前同事Puff潘、RainSun吕合作,做一些给使用redis的软件增加redis cluster或者redis sentinel支持功能的工作。 传统上,做sharding工作有三种做法: 客户端支持,比如redis cluster客户端需要支持KeySlot计算(我报告的bug: https://github.com/Grokzen/redis-py-cluster/issues/153) 代理层支持:twemproxy、codis等 服务器端支持:比如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 冲突

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端口,而是: 先把PREROUTING、OUTPUT无条件指向KUBE-SERVICES链;如匹配不上KUBE-SERVICES链,则再尝试匹配发给docker0 在KUBE-SERVICES链里匹配clusterIP:clusterPort条件,然后发到KUBE-SVC-***链 在KUBE-SVC-***链中,用-m statistic –mode random –probability这样的条件将流量按等比例分给多个KUBE-SEP-***链 然后再在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,终于可以正常访问了。     从集群外访问 从办公区我的笔记本电脑 172.30.26.169 访问 10.16.59.67:80 服务,该虚IP被手工绑在rz-ep01上,ping可以通,但访问不通。 … Continue reading

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

Kubernetes内的网络通信问题

首先复习一下Kubernetes内的对象类型 Node:运行kubelet(古代叫minion)的计算机 Pod:最小调度单位,包含一个pause容器、至少一个运行应用的容器 RC:复本控制器,用于保持同类Pod的并行运行的数量 Svc:暴露服务的可访问通信接口   对象之间的通信关系 客户端 服务器 访问方式 master kubelet Node的10250/TCP端口。Node报到后,Master得知Node的IP地址 kubelet & kube_proxy apiserver master:8080/TCP HTTP 配置文件写明master地址 kubectl命令行 apiserver localhost:8080/TCP或命令行参数指定 other ALL apiserver ClusterIP_of_kubernetes:443/TCP HTTPS 上述IP和端口号通过环境变量通知到容器 需要出示身份信息 kubernetes是一个ClusterIP模式的Service。参见下面详述 pod pod 跨Node的多个pod相互通信,需要通过overlay network,下面详述 ALL service 三种模式,下面详述   overlay … Continue reading

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

Docker in docker的一些故障检查过程

术语约定: Host:外层运行操作系统的机器 外层daemon:Host上的docker daemon 外层容器:外层daemon下辖的container,镜像启动时加–privileged参数。这个镜像的准备步骤是从docker下载当前1.9.1版安装(并固化到镜像里)CMD是一个脚本,先启动带debug选项的docker daemon 并放后台运行,然后pull并运行centos:7 一次,最后开启一个不停ping的命令,保持容器持续运行。通过docker exec 进入另行执行docker run命令测试内层是否可以正常启动 内层daemon:外层容器里的docker daemon 内层容器:内层daemon下辖的container   宋传义最近几周在尝试docker in docker,报告过几个问题,我在这里简要记录一下。因为在此docker in docker研究过程中我只是顾问的身份,并非主研人员,所以记述内容难免有缺乏背景介绍、阶段靠后等问题。宋传义报告的大量现象都是“最后一句错误信息”,但我的工作方式是从“第一条错误信息开始看”。 启动内层docker daemon时报告缺cgroup mount 宋传义报告在1.9上可以成功的在外层容器里运行内层的docker daemon,但1.7的报告缺cgroup mount。检查发现,Docker 1.7 并不会给内层容器 mount /sys/fs/cgroup/* 目录。只需要手工补mount即可混过去,满足启动docker daemon的需求。 在Docker 1.8.0的changelog里 Runtime 小节记述了这个变动: Add cgroup bind mount … Continue reading

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