apporc

apporc

24 posts
Twitter Facebook

Pixel 3 完美支持中国电信

其实很多帖子都在说“完美”支持中国电信,然而什么是真正的“完美”呢,只要不是将电信卡插上就用,我想都不算是“完美”吧。本篇方法所说的“完美”主要是指,在支持了电信的情况下,仍然能够无痛或者微痛的进行 OTA 升级。 本方法有两个步骤,首先安装 Magisk,然后使用一个叫作 chinese_sim_supporter 的 Magisk 模块来开启中国电信支持。 注意:本方法只在 Pixel 3 的 Android 10 版本上进行过测试,其它机型或者版本,理论上虽也可行,但具体操作方法会有出入,不要一味套用。 Magisk 前文 之中我记录过一种 Magisk 的安装方式,

  • apporc
    apporc

Pixel 3 中国电信折腾记

2014 年入坑 Nexus 5 的时候,美版在网上看到通过破解是可以支持中国电信 3G 的。然而谁知一入此坑深似海。网上的破解教程,通常是机锋网上的一个个帖子,往往语焉不详,最奇怪的是我记得有一个用来写入 SIM 卡数据的软件,好像叫作 DFS,在同样的条件下做同一个操作,居然会出现随机的结果,需要反反复复尝试,经常彻夜不成。后来有了锤子,果断不折腾了几年,然而风云难测,锤子让老罗自己玩死了,此处略去十万句。只好又回来参考 Google 的手机,这次就是换了汤的 Pixel 系列了。经过基本的调查之后,确认现在对中国运营商的支持好多了,于是再度入坑,这次我选择的是 Pixel 3。至于为什么只在 Google 与锤子之间抉择,这里就不扯了,我想如果你已经搜到了这篇的话,你已经有了自己的选择。

  • apporc
    apporc

python 配置管理:oslo.config

概览 oslo.config 是用于从命令行或配置文件解析配置参数的框架,来自于万能的 OpenStack 社区。作为 oslo 项目的子项目,可以通用在任何 python 程序中。 oslo.config 的主要特性包括: 参数的类型限定 同时管理命令行与配置文件(ini) 自动生成示例配置文件 支持参数分组 运行时重新载入配置 快速开始 安装 oslo.config pip install oslo.config 定义参数 #!/usr/bin/python # test_oslo_config.py from oslo_config import cfg from

  • apporc
    apporc

python 单元测试框架: testtools,fixture,mock,mox

概述 python 有大量的单元测试框架,本文尝试对下列模块进行梳理: testtools,fixture,mox,mock 本文仅从整体的角度对各模块的使用方式进行把握,更详细的信息请随时查阅文中的参考 链接。 模块列表 testtools unittest 是 python 标准库中自带的单元测试框架,python 2.7 及以后版本中为它加入一 些新特性,将这些新特性整理形成了在 python 2.6-3.4 都能工作的 unittest2 模块。 而 testtools 即是对 unittest2 的扩展。 在安装有 testtools 的 python 环境中找到文件 lib/python2.7/site-packages/

  • apporc
    apporc

python 持续集成: setuptools & pbr

概览 setuptools 是针对 python 项目的一个打包工具,使用它可以方便地对 python 项目进行 打包安装。要使用 setuptools 只需要在安装脚本中调用其提供的 setup 方法,项目的信 息都通过高度可定制的参数传递给该方法。当调用安装脚本的时候,可以通过传递诸如 build, install 等参数直接进行构建与安装的操作。setuptools 是对 python 标准库中的 distutils 的加强。 pbr 是一个对 setuptools 加强的插件,通过它可以将 setup 函数所需的参数放在一个统 一的配置文件中集中管理,此外它也带有自动化管理项目版本的功能。pbr 来自于 openstack 社区。 快速开始 安装 setuptools 和

  • apporc
    apporc

python 持续集成: tox 单元测试

概览 tox 是 python 单元测试方面的工具,使用它可以方便地设定一个预期的 virtualenv 列表,并自动在每个 virtualenv 下进行指定的安装与测试工作。 tox 的使用步骤概括一下就是: 安装 tox 生成 tox 配置文件,在其中指定 virtualenv 列表以及每个 virtualenv 环境 下要运行的测试命令 由 tox 命令自动创建准备 virtualenv,并在其中运行指定的测试命令 快速开始 下面来一起试用一下 tox。 安装 tox 可以使用 pip/easy_install 来安装 tox,或者使用各 Linux 发行版的包管理器: pip

  • apporc
    apporc

python 字符编码那些事

本文旨在整理字符编码的信息以及 python 对字符编码的支持情况。 what is ASCII ? 回顾一下 ASCII 码是怎么一回事。 1968 年, American Standard Code for Information Interchange 制定了一个常用字符与数字的转换关系,这个关系就以机构名称的首字母命名, 即 ASCII,ASCII 码中使用了 1-127 的数字。 ASCII 码的问题是: 127 个的数字所能代表的字符数极为有限,存在大量显示不了的字符, 例如西欧的重音符,中国汉字字符等。 1980 年的时候,大部分电脑是 8 位的,也就是能使用的数字范围为 0-255,ASCII 码使 用了其中的一半。很多不同厂商的电脑于是把 128-255定义为其它的重音符号,

  • apporc
    apporc

requests-mock 模块

背景 微服务盛行的当下,服务之间的交互变得极为频繁,这带来了更好的服务模块化, 但也为开发和调试带来了一个问题,即当你正专注于解决服务 A 的问题的时候, 却常常被它的依赖服务 B 的问题搞得焦头烂额。 requests-mock 这个模块就是解决此类问题的,它通过在服务 A 中模拟所依赖的 服务 B 的 api 接口,而为服务 A 提供一致稳定的响应,从而隔离掉服务 B 所可能带来的问题。 模块地址:https://pypi.python.org/pypi/requests-mock 使用 Mocker 下面来实作一下,看几个官方的例子 以 context manager 的形式使用 Mocker >

  • apporc
    apporc

nova: 远程对象模型

概述 本文说一下 nova 数据库对象的远程使用。这是 nova 里很精彩的一个地方。 远程对象所实现的效果是,一个 A 服务中的远程对象实例,可以由消息队列传送到 B 服务,B 服务能够使用这个实例,当调用实例的方法时,实际执行这个方法却是在 A 服务中。 以 Instance 类的实例为例,该类是代表虚拟机数据库抽象的类,通常我们通过更改实例 的属性,并调用 Instance.save() 方法更改数据库。该类的定义在 nova/objects/instance.py 中。 nova-conductor 在收到创建虚拟机请求时生成了实例 instance = Instance(),之后将 instance 通过消息队列发送到了 nova-compute,

  • apporc
    apporc

nova: 创建虚拟机流程

nova 各服务角色 先说一下 nova 各服务所担当的角色 nova-api nova-api 代表 nova 对外提供服务接口,接受虚拟机的操作指令。无论是从 openstack 的命令行还是 dashboard 界面,只要是虚拟机的 操作请求最终都会发给 nova-api 服务。这个服务通过 HTTP 协议对外提供 REST API。 nova-conductor nova-conductor 是 nova-compute 之上的一个新服务层。一者它为 nova-compute 代理数据库的操作,即 nova-compute 不直接操作数据库 而是通过 nova-conductor 的 rpc 方法来读写;二者相对于一些启动、关闭、暂停、

  • apporc
    apporc

oslo.messaging 0x03: rpc 客户端

oslo.messaging 0x03: rpc 客户端 在前一篇 中已经提到,oslo.messaging 中的客户端实例 RPCClient 有两个方法 来完成消息的发送,它们分别是 call 和 cast。且这两个方法最终都是调用的 Transport 的 _send 方法。这一篇梳理一下这两个方法的内部实现细节。 RPCClient 回到 RPCClient 的实现。RPCClient 与 transport 之间其实还隔着一个 _CallContext 实例,但这里我们略过这一层。直接看 call 与 cast 方法的实现。 首先看一下 oslo.messaging 开发者文档所说: A

  • apporc
    apporc

oslo.messaging 0x02: rpc 服务端

接上篇的 MessageHandlingServer 继续, 这一篇专注于梳理 oslo.messaging 中一个 rpc server 对消息的处理流程。 openstack 各服务 nova-compute, neutron-server, cinder-volume 等等每一个都对外提供了 rpc 服务,接受其它组件的 rpc 调用。例如,nova-api 接到一个创建虚拟机的请求,就是通过调用 nova-compute 的一个创建虚拟机的 rpc 接口来进行虚拟机创建的。 +------------------------+----------------+ | messaging.server.MessageHandlingServer | +------------------------------------------------+ | | +--------------------------------------------------------+ | messaging/_drivers/amqpdriver.AMQPListener | | self._executor -----------+-----&

  • apporc
    apporc

oslo.messaging 0x01: kombu

oslo.messaging 中的 kombu 代码结构图如下: +----------------------------------------+ | | nova.rpc.get_server --> messaging.server.get_rpc_server --> | messaging.server.MessageHandlingServer | | | | self.transport | | | | +---------+------------------------------+ | v +----------------------------------------------+ +----------------------------------------+ +--------------------------+ | | | | | | | messaging._drivers.impl_rabbit.RabbitDriver | | messaging.transport.Transport | | messaging.rpc.RPCClient | <---- nova.

  • apporc
    apporc

AMQP 协议消息库 kombu

背景 kombu 是一个 python 消息库,提供 AMQP 协议的高级封装。 题外话:目前 kombu 也支持对非 AMQP 协议的封装,支持 Redis,MongoDB,ZeroMQ 等。 概念 参见 AMQP 协议,协议中的几个关键元素在 kombu 中都有对应的封装,下面把关系 先列出来: publisher: kombu.Producer() exchange: kombu.Exchange() queue: kombu.Queue() consumer: kombu.Consumer() 使用 建立连接 kombu 的封装抽象中建立一个连接即是建立一个

  • apporc
    apporc

RabbitMQ 配置初步

Table of Contents 安装 配置简介 配置文件 用户管理 防火墙 system limits RabbitMQ 集群 手动创建集群 重启集群 破坏集群 自动创建集群 fuel 中的 RabbitMQ 安装 rabbitmq 的安装分两部分,rabbitmq-server 自身的安装以及其依赖 erlang 的安装。 rabbitmq-server: rabbitmq-server 的安装包 fedora 系统安装源有提供,epel 也有提供。 fedora 系统源: 提供的包版本往往比较老旧,比如现在 fedora20 的源提供的版本为 3.1.5。 EPEL: 提供的版本要新得多,

  • apporc
    apporc

RabbitMQ: 开启消息历史记录

简介 本文记录如果为 RabbitMQ 开启消息历史记录。基于 RabbitMQ 消息队列作应用开发的时候,难免会需要追查 RabbitMQ 服务中发送的消息详细信息。通过开启消息记录,将会为开发带来很大的便利。 打开 RabbitMQ 消息历史记录 RabbitMQ 服务自带有一个管理界面,我们只需要开启它。 打开管理插件 在安装有 RabbitMQ 服务的节点上,执行命令 rabbitmq-plugins enable rabbitmq_management。 然后重启 RabbitMQ 服务使更改生效。 这时访问本机的 15672 端口,即可看到 RabbitMQ 的管理界面: 登录管理界面,需要帐户有特殊权限,通常使用 rabbitmqctl set_user_tags administrator

  • apporc
    apporc

nova: 基于 windows iso 镜像创建虚拟机

问题 制作虚拟机镜像是在 openstack 外,通常都是使用镜像制作工具 image tools,或者自已动手 create image manually。然后将制作的镜像,上传至 glance 服务之中使用。 不过,在一些极为特殊的情况下,有些客户可能有特殊的需求,例如,客户想要从 windows 或者 linux iso 启动一个 openstack 虚拟机,并利用这个虚拟机制作一个镜像。这里不就需求的合理性作讨论,只说一下如何在 openstack 中达成这个需求。 面对的问题主要是两个: 如何在 openstack 中,创建包含多个磁盘的虚拟机? 因为我们基于 iso 安装虚拟机,所以除了 iso 之外,我们还需要额外传递至少一个空的磁盘给虚拟

  • apporc
    apporc

AMQP 协议简介

Table of Contents 概述 模型简介 交换机 队列 绑定 消费者 消息 连接与通道 虚拟主机 协议实现 参考链接 概述 AMQP(Advanced Message Queuing Protocol),即高级消息队列协议,是一种应用层网络协 议,它为特定客户端应用(application)与消息中间件代理(messaging middleware broker) 之间的通信提供支持。AMQP 协议有过多个版本,本文所说的是 0-9-1,针对AMQP 0-9-1 协 议模型作一个简单的介绍,该模型即 rabbitmq 所使用的模型。 模型简介 消息代理(message

  • apporc
    apporc

nova : shelve/unshelve/shelve-offload

问题 openstack 中 nova 对于虚拟机的操作,有非常多种,在此不一一列举。普通的操作如 start,stop,suspend,resume 是很好理解的。然而像 shelve,unshelve 就比较新颖了。 而且从官方文档中也看不出来是干嘛的,官方文档是这样说的: Shelving is useful if you have an instance that you are not using, but would like retain in your list of servers. For example, you

  • apporc
    apporc
openstack

Openvswitch with libvirt

问题 linux bridge不支持vlan, openvswitch支持. 在虚拟机环境中测试neutron的vlan功能时需要宿主机的虚拟网支持vlan. 安装openvswitch 启用rdo源 安装openvswitch yum install -y openvswitch 开启openvswitch服务 systemctl enable openvswitch systemctl start openvswitch 配置openvswitch和libvirt 建立openvswitch桥 ovs-vsctl add-br testbr0 更改libvirt配置 这里演示了一个虚拟网络允许通过vlan 47, 将vlan 42的摘掉vlan tag. network部分: $ virsh net-edit test_net <network> <name>test_net<

  • apporc
    apporc

setuptools: 制作deb包

检查python setup.py –help-commands的命令列表, 会发现setuptools提供的打包命令如下: bdist create a built (binary) distribution bdist_dumb create a "dumb" built distribution bdist_rpm create an RPM distribution bdist_wininst create an executable installer for MS Windows bdist_egg create an "egg" distribution 有bdist_rpm, 可以将软件打包成rpm包, 就可以拿来方便地安装到那些使用rpm包管理机制的linux操作系

  • apporc
    apporc