Pensieve: 1846
2018-11-18 22:44
所观所读
手机上继续读全职高手, 目前进度60%. 某个人实在是太bug了, 吐槽无能.
所玩
继续Diablo 3, 野蛮人玩疲劳了想换DH, 结果发现赛季奖励的套装每个账号只能领一次, 而不是每个账号的每个角色可以领一次, 遂放弃. 不急, 下个赛季再玩吧.
顺便烧香求太古套装, 目前都是垃圾武器算什么事情嘛.
个人云方案
这个算是继续折腾, 这周主要在折腾tensorflow在树莓派上的编译. 直到最后, tensorflow终于还是没能编译成功. 网上能找到各个稍旧版本编译成功的案例, 但是最新的1.12就是卡在一个AWS相关包的编译错误过不去. 错误原因是bazel在编译时因为平台检测的原因没正确地包括这个包里的cpp源码. 尝试了各种的配置选项, 编译参数和编译器版本的组合, 都没有成功, 于是就放弃了安装photoprism的主意. 毕竟:
- tensorflow只是第一步, 后面和photoprism整合的时候还不知道会有多少坑.
- photoprism这个upstream现在仍不算成熟, 后面维护这个东西时还要追着它的更新, 工作量不一定小.
- photoprism只是一个相册管理工具, 而不是一个存储方案. 对于手机里图片如何上传, 目前并不一定有好的方案.
接下来又折腾了resilio-sync和Nextcloud. 前者相对比较稳定, 不过缺点是iOS上的客户端文件管理功能比较弱, 不能本地删除单个文件, 对浏览图片情形也没有优化. 另外, 在导入图片/视频时为了节省空间, 做了一个技术上还算合理的决策, 即图片会复制到app自己管理的目录, 但是视频文件只是保留了一个到系统图片目录的引用. 但是对于长辈们而言, 这还是复杂了些. NextCloud在调研时我就不是特别想用, 因为它是用php写的. 不过因为resilio-sync实在不太靠谱, 所以尝试了一遍安装. 安装完成后没过多久就在试用时遇到了问题: 我在iOS端上传多个文件时树莓派由于资源问题卡死了(默默吐槽了下, 加一个队列很难吗?). 我在手机上取消了上传, 但是nextcloud没处理好这种异常, 导致系统里存在了若个删不掉的不存在的文件. 查了下, 貌似要进数据库手工清理这些脏数据. 于是我就放弃这货了.
还剩一个选项是seafile, 还没来得及尝试, 希望这个能靠谱些.
Cloudformation的漂移检测
上周, AWS发布了Cloudformation的这个新功能, 漂移检测(Drift Detection). 目前网上还没有文章介绍这个功能. 我工作时间玩了一下这个新特性, 给供职的公司写了一篇英文Blog文章介绍这个功能. 这儿用中文简单说几句.
漂移检测的应用场景是, Cloudformation定义的架构(Stack)和真正线上运行的架构在配置上不一定会完全一致. 有权限的用户都能在AWS的管理界面里修改某些配置以应对运维需求, 而这些在Cloudformation外进行的改动是很难追踪的. 这些配置指不定哪次Cloudformation的架构更新时就会被覆盖掉, 造成事故. 现在Cloudformation的这个特性能够找到定义的架构和真正运行的架构的配置差异, 这样能够给运维工作带来方便.
理想是美好的, 现实是骨感的, 这个特性并没有宣传得那么好. 在于:
- 这个特性需要各个资源具备漂移检测的支持, 目前列表已经比较长, 但仍然不够全面.
- 从实现上看, 有些资源是至少在目前是很难实现漂移检测的. 例如官方文档中提到的lambda. 在Cloudformation中仅仅记录了在S3中代码包的路径, 没有直接对应到lambda中的代码和依赖.
上面这两个缺点还仅仅是官方文档中已经指出的. 在试用中, 我发现还要这些坑:
- 对于
DescribeStackDriftDetectionStatus
这个API, 当一个架构包含了若个个资源, 而某个资源的漂移检测失败时, 合理的做法是在DetectionStatus
中标记检测失败, 并在StackDriftStatus
中标记状态为UNKNOWN
, 由用户决定是否要进一步查看检测失败的原因. 但现在AWS的做法是直接返回IN_SYNC
(在其他资源没有异常的前提下), 而在AWS的管理界面上看到的漂移检测结果也是直接看StackDriftStatus
, 没有去看是否有检测失败. 理论上讲, 这个叫瞒报. - 随着这个新功能的引入,
ListStackResources
和DescribeStackResources
的返回值中也包括了漂移信息. 但是可惜的是, 这两个API的返回值中的Timestamp
字段仍然标记的是架构在Cloudformation中更新的时间, 而不是资源上次被修改的时间. StackResourceDrift
这个API的返回值不算特别靠谱, 我见过ExpectedProperties
和ActualProperties
完全一致,PropertyDifferences
为空, 而StackResourceDriftStatus
为MODIFIED
的案例. 也见过由于种种小格式改变而被Cloudformation认为是改变, 但实际上两者语义完全一致的情形. 个人觉得, 这种小漂移, AWS内部处理一下为好, 不应该直接暴露给用户.
链接
- https://hackernoon.com/why-not-make-db142ccb2081和https://apenwarr.ca/log/20181113. 吐槽Make的我都喜欢. 好吧不开玩笑, 我的确不喜欢Make, 没到那么决绝的程度不过也差不多了. 第一篇是说用Make来做cpp的编译如何不靠谱, 第二篇是说用mtime来做编译时更新的依据是如何不靠谱. 重点推荐后一篇, 讲得很细很清楚, 很多corner case都考虑到了.
- https://drewdevault.com/2018/11/15/sr.ht-general-availability.html.不知道性能和特性对比gogs和Gitea如何. 现在有了树莓派而且挂载了两个硬盘, 做一个本地git服务并做好自动备份应该是不算太难都事情.
- https://www.unix-ninja.com/p/attacking_google_authenticator. 读过后了解了这一点: 对于不可靠的信道, 传递2FA的数据次数到一定限额后, 2FA可以被破解.
- https://words.steveklabnik.com/how-to-be-an-open-source-gardener. 要维护一个较大的开源项目真是累.
- https://threadreaderapp.com/thread/1058676834940776450.html. 很久以前好像踩过这个坑.