寒晨 发布的文章

准备`复活`本博客

整理心情,整理博客,为博客加入 HTTPS 支持。好久没折腾了,一大波安全更新进行中。

关于更新 HTTPS

对 letsencrypt 不感冒,装 X 买了一个廉价的 Comodo SSL 买了两年总计 14$, 部署也比较顺利。

关于安全更新

涉及的列表

  • typeecho
  • nginx
  • php (php-fpm)
  • openssl / openssh
  • freebsd

遇到的问题

  • 需要在博客程序中配置一下博客地址成 https
  • 已前写的文章直接引用了 http 的图片,已经修正成无协议的。
  • 静态资源 CDN https 不可用(老问题,无解)

Python内置子模块之site.py

为什么要做

这里主要以python2.7版本代码为例,用来进行自动的预配置第三方模块目录。 如果你在系统中安装了Django,python需要知道如何才能找到Django模块,这个时候site.py就起预配置的作用。

官方文档
源代码

做了什么

python本身导入模块是以sys.path为依据的,调用imp模块来进行导入。

sys.path初始化分两步:

  • 第一步,python进程本身,是由getpathp.c实现的,加入python本身导入路径。
  • 第二步,调用site.py附加一些第三方部模块导入路径。

所以site.py的本质就是补充sys.path路径,协助python预配置第三方模块目录。

什么特点

  • 补充sys.path路径,协助python预加载第三方模块

允许通过-S/-s 参数和 _PYTHONNOSITEPACKAGES等环境变量进行开关

  • 允许通过调用addsitedir,进行程序级别扩充sys.path 。

不推荐直接修改sys.path,会丢失一部分特性。

  • 支持.pth扩展文件(只对sys.path目录起效),允许继续追加sys.path。

同时python进行.pth解析中,允许直接进行代码执行 (后门有木有,python进程插入)

  • 支持用户自定义第三方模块,权限细化隔离。

应用场景

  • import 的时候得到包含第三方模块路径的sys.path
  • 协助确认系统是否已经安装指定包,比如setuptools,pip等 (其实只是给出目录)。
  • virtualenv patch 这个模块实现目录级别的包管理。
  • 需要扩充sys.path时,更推荐调用 site.addsitedir方法。
  • 利用.pth文件的支持,代替PYTHONPATH,实现系统和程序的隔离。

踩过的坑

  • 导入顺序和系统模块覆盖问题。

在项目根目录自己写了一个site.py 然后从这里启动django。 结果一直提示找不到django,各种重装,各种版本尝试,始终找不到django。 删掉新写的site.py 就好了why?, 因为sys.path第一个变量一般是本地执行目录,所以优先导入本地的site.py代替系统的site导入第三方模块功能就没了。 (同样该问题使用在其他内置模块,比如命名一个re.py,原始的re就功能丢失了)

解决方法 1.不与系统原有模块名称冲突,2.采用绝对导入PEP328

  • 不同版本同名模块,版本判断问题。

系统里同时存在两个版本django (别管怎么装,都是泪啊) 比如一个1.3 一个1.6 当安装系统库依赖 django >=1.5版本时,问题就出来了,到底需不需要更新? site.py提供功能太原始了。给个目录其他直接想办法,遇到用os.listdir的还要看人品。

解决方法 1.统一安装途径。 这样入口可以管控起来。(推荐都用pip) 2.权限隔离,少数人有root权限,平时降权操作。

向大家推荐BSD

和大多数人一样操作系统方面学习曲线是这样的。 Windows -> Linux -> BSD

在接触BSD前已经有还过得去的Linux基础,抱着尝尝鲜的角度试了BSD,虽然初期被没找到bash,找不到free命令,UTF-8等问题困扰,但是在慢慢熟悉过程。发现渐渐开始对BSD有一些好感,这里着重推荐FreeBSD

FreeBSD

简单列出一些个人觉得比较的地方:

  • 整个系统使用完整一致的版本控制。
  • 大多数配置被分类存储在几个相对统一配置文件中。
  • 强大稳定高性能的网络支持。
  • 集中一致的学习手册
  • 官方man在线手册
  • 更加开放的BSD License(可商业)。
  • 大多配置被简化,比如编译内核配置。
  • ports包管理基于Makefile简单实用。
  • 升级方便freebsd-update。
  • 稳定不折腾。

当然有长必有:

  • 许多云服务提供商并不支持BSD
  • 部分比较新的硬件兼容比较差。
  • 定制性略有不足。
  • 没有GNU/Linux那样有一堆发行版本,但是仍然有部分选择NetBSD,OpenBSD等。
  • 一些开发者,开发软件并没有考虑BSD兼容(优秀开发者,一般会考虑这个问题)。
  • 桌面方面用户基础比较差。

个人在开发环境选择上优先选择Gentoo定制性强,稳定的在线环境FreeBSD。比如你看到这个博客

NETGEAR WNDR3700 v4 OpenWRT USB性能。

由于家里小路由网口太少不满足日益增多的网络设备,故一直眼馋网件系列可以刷OpenWRT的路由器。刚好某东在做网络产品做活动,马上剁手。到手后一查。

晕。原来4300和3700v4都是处于支持工作进行中的状态。早知道这样直接入4300了也差不了几十块钱。还好支持已经做的不错了。已经基本可以正常使用了。各种编译各种折腾后,效果相当不错。可惜偶手机并不支持5G无线 MOTO G -_- 。

来张大图

想着这路由器只当路由器就太浪费了。就弄一个简单smb当文件服务器吧。之前小路由703n搭建smb协议后,不知道是不是供电问题。频繁读写就挂了。正好试试这货的USB口的性能。找来一个速度不错的U盘大名鼎鼎CZ80 32G,格式化vfat。本地dd先是试试IO速度如图

本地dd速度

尝试通过U盘读写200M文件,换算后读大约28M/s,写大概22M/s,比树莓派好上一点。有点失望。(dd结果由于cache会略高!)

通过千兆有线+smb速度就更悲催了。 写大约11M,读只有9M(不理解),再看看vmstat 发现瓶颈在CPU,关掉大多数程序,重新试了一下,提升10%。就这样吧。偶尔跨机器传输一个小文件玩玩。弃疗。。。

二进制文件如何进行版本控制

难以避免的烦扰

通常在项目开发过程大多数代码是以文本形式存在在版本管理系统中。但是难免有一些二进制数据需要进行版本管理,比如 图片、数据库文件、其他二进制可执行程序等。

存在的问题

  • 二进制文件通常无法进行直接diff,导致版本控制功能弱化。
  • 二进制文件通常比较大,特别是git存储方式(镜像存储)占用大量磁盘空间。
  • 二进制文件通常是有特定的需求比如patch过后编译出来的。后期无法跟踪。
  • 二进制可执行程序,无法做到跨平台运行,可能依赖特定环境。
  • 二进制文件,无法直接进行代码审计。无法做到行级别跟踪。

某场景

我们项目中有一个sqlite3的数据库文件用来存放规则信息。在维护过程这个数据库文件每次都被整体更新。进行主干稳定代码库发现紧急一个问题,需要临时修复并立马二次发布。但是这个sqlite3数据文件在开发分支。已经被完整更新过许多次了。但是我只需要其中某一次提交。这时候不淡定了。魂淡,为什么不存储xml格式?啊啊啊啊。实在没办法,把sqlite3数据文件手动转换成sql文件,人肉小心翼翼的进行sql文件 diff & merge。最后终于发布紧急版本。

BOSS问:为什么紧急版本发布比平时版本还慢,客户意见很大。 偶:我容易吗。。

合理存储二进制

有很多场景确实让人无奈,比如老项目维护,必须把二进制存放版本库。给大家一些建议降低维护成本。

  • Web前端图片

    • 尽量合并多张图片到单个图片文件,避免图片文件碎片化。参考CSS Image Sprites
    • 推荐对不同模块静态资源进行区分目录存储。参考 Django managing static files
    • 进行图片文件commit的时候写上清晰明确messags,后期维护的主要依据 (适用于任何场景)。
    • 定期确认和清理已经不在使用的图片。
  • 数据库文件

    • 善用git提供的gitattributes主要用到filter和diff两种方式,

      • filter可以做到开发模式和存储模式过滤转化。实现开发看到的是文本,存储的是二进制。
      • diff 可以对二进制文件进行差异比较,比如sqlite数据文件,在diff情况下看到就是sql文本文件差异。
  • 二进制程序或其他进制程序。

    • 再次确认,不推荐二进制可执行程序直接行版本库。
    • 进行文件commit的时候写上清晰明确messags,后期维护的主要依据 (适用于任何场景)。
    • 善用Linux提供的strings程序。必要的时候调用strings 把二进制转换成文本。

使用文本替代二进制存储

大多数场景下除了图片资源外,不建议在版本库中存放其他二进制文件。但是这些程序又必须被管理起来。如何才能解决呢?

  • 数据库文件

    • 数据量不是非常大的情况,能否用xml或其他文本文件代替。
    • 能否转换成原生的sql文件再存储。
    • 善用git提供的 gitattributes filter功能,在提交到暂存区时自动把它转化成sql文本文件。
  • Word和文档类型文件

    • 推荐用 Sphinxmarkdown方式进行文档编写与存储,必要时生成PDF。
    • 使用 DocBook进行文档编写与存储支持生成Word.
  • 二进制程序

    • 采用git提供submodule功能,直接进行跨项目依赖。
    • 采用svn提供svn:externals property进行跨项目依赖。
    • 提供工程化程度足够的安装脚本主动进行依赖处理。
    • 如果有进行patch操作,必须在版本库中保留patch文件,patch文件名需要足够清晰,并且用Quilt管理起来。
  • 压缩包

    • 根据实际压缩内容,再针对性处理。

总结

要做一个有洁癖的开发者,善用手上的工具。你遇到的哪怕是一点点困难,也已经无数前人踩过坑。