Well, here is my setup of Ubuntu 18.04 + NGINX + PHP7-FPM, most part of the following content I referred comes from https://www.howtoforge.com/tutorial/how-to-build-nginx-from-source-on-ubuntu-1804-lts/. And I've just made some substantial changes. Massive thanks to the original author.
Continue reading Compile Nginx on ubuntu 18.04 LTS with PHP 7Category Archives: Linux
多用户 Docker 环境下 PyPi 源按需加速
这一篇算是接在上一篇Build a super fast on demand local PyPi mirror的后面吧～
这里会以 docker-compose 的方式为例子，详细写一下～不使用docker-compose的话，则也仅仅需要手动指定 pypicache 与需要这个服务的 container 到同一个 docker 网络中，这样就可以不用去找 pypicache 的 IP 地址，对最终用户透明化，不用增加额外的 pip 安装参数，即可轻松享受本地高速缓存，特别是对于大一点的文件效果更明显～
Build a super fast on demand local PyPi mirror
- 当公司/局域网里有多人都使用 Python 开发，并且几乎都会用到 pip 来部署环境时，虽然已经有各种镜像源了，但是下载仍受限于与外网的宽带速度，并且同样的包可能被多人下载了多次，在包较大时，重复花的时间并不值
- 当你使用 Docker 来构建不同的 Python 应用/环境时，在测试 Dockerfile 时可能需要不断的删掉之前 build 的版本，从头开始 build 时，pip 下载与上面面临同样的问题——重复消耗不必要的时间
其一解决方案是公司/局域网内部搞一个 PyPi 的镜像源，实际上维护一个完整的镜像源相当麻烦，占用的储存空间太大，在公司/局域网的情况下，大家开发的东西、使用的技术栈相对比较固定，这就导致完整的镜像源里会有很多包其实几乎没人用。
其二的解决方案可以是预先构建好一个或多个 Docker 镜像，其中包含大家都会用到的包，剩余的一些包则在使用时才被少数需要的人安装。这种方案的缺点则是目前 Docker 服务 + 多用户方案在重启之后会丢掉已经配置过的环境，重启之后依旧需要从镜像源下载包。
那么这里相对一劳永逸的方案则是搭建一个本地的按需下载的 PyPi 镜像源，其原理则是在镜像源与公司/局域网内增加了一个高速缓存，并且由于 PyPi 已经提交分发的whl或者tar.gz是不会变的，因此不用顾虑缓存时间的设置。
最后就像这样～ 182KB/s VS. 36.4MB/s
(cache server为千兆有线链接，MacBook为802.11 AC，测试时链接速度585Mbps)
Continue reading Build a super fast on demand local PyPi mirror
SSH Tunnel的systemd service生成脚本
完全是为了方便自己折腾各种跳板写的，比如把家里的aria2、Jupyter Lab等等的映射到公网服务器，用systemd的话，可以实现自启动和出错自动重启，用autossh来替换生成脚本模版里的ssh也行，这个就看个人了。
实际就是这样的感觉～
A brief tutorial on setup an AI lab server for a small team
这个是在之前导师的实验室积累的一些东西，使用场景的话，是适用于2-8人左右的小团队吧，当时有两台机器，一台是放在学校机房的服务器，CPU没注意是什么，印象中是64G内存，4块P20，貌似24G显存？；另一台机器则放在办公室，主要配置的话，一颗AMD Ryzen 2700X，64G内存，再附加两块1080ti 11G，经费肯定是还做不到一人分一块GPU，部分模型的大小也不需要完全独占一块GPU。但是构建一个小型团队使用的AI Lab服务器是没问题了。
当时搭建的AI Lab服务器的主要架构如下
系统方面选择了Ubuntu 18.04 LTS，简单方便，毕竟是做AI不是做OS，没有任何必要引入其他方面复杂的操作。然后在这之上则是系统层面的GPU驱动，当时对应的版本为396.26，目前已经有400版本号的驱动了。接下来就是与docker对接的nvidia的runc，由这个runc去给docker内的GPU提供支持。随后当时则是使用了支持多用户的JupyterHub，当然也可以通过分配多个账号解决，这一部分和之后的部分解决方案就很多了。
Continue reading A brief tutorial on setup an AI lab server for a small team
2 Days at LinuxCon 2017
有幸获得了 HACKx 赠送的 LinuxCon 2017 门票，于是便动身参加了 LinuxCon 2017，这也是 LinuxCon 首次在国内举行，顺便也在大会上见到了 Linus Torvalds。
这次的 LinuxCon 实际上是三个会议，其一不用说，就是 LinuxCon 了，然后是 ContainerCon 和 CloudOpen，官方合称为 LC3。此次 LC3 的 Keynote 和各展商的 Presentation 覆盖了以下 10 个方面
- Programming Frameworks 编程框架
- Application Platforms 应用平台
- VM / VIM Managers 虚机管理
- Containers 容器
- Operating System 操作系统
- Virtual Machines 虚拟机
- Network Management & Orchestration
- Carrier Networking 运营商网络
- Network Controller 网络控制
- Data Plane Services 数据平面服务
在这 10 个方面上，作为支撑的则是
- Security 安全性
- Governance, Operations & Ecosystem 运维
- Licensing & IPR 许可和知识产权
- Training & Certification 培训和认证
除了 Keynote Session 之外，各展商的 Presentation 都是同时在不同会议室展开的，我只去听了其中几场
- Much Ado About Blocking: Wait/Wake in the Linux Kernel - Davidlohr Bueso, SUSE Labs
- Rethinking the OS: A Travel Journal - Simora Arsene, SUSE
- MD RAID1 and NVMe: High Performance Data Duplication - Coly (Yong) Li, SUSE Linux
- Kubernetes Bootcamp 101 - Caicloud
- LinuxCon K8S + TensorFlow Bootcamp 101 - Caicloud
要说什么的话，这次的 LC3 给我的感觉是（大部分）围绕 Container 来进行的，包括但不限于 SUSE、Intel、VMWare、Caicloud 在内的公司都在致力于为 Containter 提供更好、更易用、更安全的体验。
这里我挑选几个印象最深的来说说吧。
首先是 SUSE 正式发布了 SUSE MicroOS（Micro stands for Microservice），官方是这样描述的，
A purpose built Operating System designed for microservice & containers and optimized for large deployments.
一个专为微服务与容器打造的，且为大规模部署优化过的操作系统。
主要特点则是
- An always up-to-date Operating System
- An easy to manage/upgrade OS
- Easily setup/manage a cluster of nodes
- scalable - up to 1000s of nodes
An always up-to-date Operating System（一个总是最新的操作系统）。关于更新这一点，可能有人遇到过更新之后出现问题的情况，SUSE 在这边使用了 Atomic Upgrade（原子更新），保证了在更新期间，即使出现了问题，也能回滚到更新前的状态。接下来，SUSE 做到 always up-to-date 的方案则是，一直在后台拉取更新，然后在系统负载低时进行更新。
SUSE MicroOS 则是作为 SUSE CaaS Platform 的组成之一，剩下则是 Kubernetes 和 Container Engines。
Source: https://www.suse.com/communities/blog/suse-caas-platform-whats-buzz/
关于 SUSE CaaS Platform 的更多信息，可以参考 SUSE 官方的博客
- Introducing SUSE Containers as a Service Platform
- What is SUSE CaaS Platform? What’s all the buzz about?
接下来则是 Intel 的 Clear Linux 和 Clear Container 技术。需要注意的是，虽然这两个项目命名方式类似，但是实际上是两个不相干的项目。
Clear Container 技术是为了给现有的 Container 提供一个虚拟机级别（例如 VMWare）的隔离。在现有的 Container Engine 技术中，由于不同的 Container 共享的是一个 Linux Kernel，如果其中一个感染了可以取得 Kernel 代码执行权限的病毒，那么这个病毒就可以绕过 Container Engine 的隔离，感染所有正在运行的 Container。
在 Clear Container 中，Intel 目前实现了与 Docker 无缝对接，利用 Intel VT-x 实现了 Kernel 级别的隔离，因此不同的 Container 也可以运行在不同版本的 Kernel 之上。当然，虽说是无缝对接，但是实际上还是多了一层，即 Intel VT-x 那层，据 Intel 的说明，目前在内部测试出来的开销并不大，启动一个 Container 只多 20ms 的样子，但是对文件读取的开销还没有非常明确，目前是将文件映射到内存以尽可能降低这方面的开销。
Clear Linux 则是另一个项目，这个项目的目标是构造一个尽可能小的 Linux 用于 Container，并且内核模块全部使用静态链接的方式换取速度与安全，如果你有特别的需求的话，可以自己在 Clear Linux 的基础上编译内核（当然也都是静态方式）。目前 Clear Linux 的 Container 镜像仅仅 5 MB。
Jetson TX1入手(/ω＼)
其实在去年12月10来号的时候，就已经决定要入手一个Jetson TX1做开发了，一方面是因为现在使用的MacBook自带的Intel(R) HD Graphics 515性能比较低，当时用waifu2x把一个720P的视频拉到了2560x1440，跑了两周多吧……另一方面是想学习一些并行计算和机器学习的技术。于是就让梅子帮我拿到了一个教育版的Jetson TX1～（我们学校那时还没有教育邮箱，不过现在可以申请啦）
实际拿到Jetson TX1是在12月30号，不过当时刷完系统，装了torch 7之后发现居然就没剩多少了
于是剁了一块SSD（下个月吃土吧_(:_」∠)_）
iOSOpenDev的补丁~
之前写过为iOSOpenDev增加指定设备端口功能 (English ver. is here)，今天在看LPI的时候，书中提到了Linux的内核升级，其中就用了patch来给内核文件打补丁。
这样的方式比起我当时给出的“自己对应目录层级”覆盖文件好多了，于是就当是学习diff和patch的使用方法，做了一个iOSOpenDev的补丁，不过我是按照1.6-2版本的iOSOpenDev做的，其他版本的没有测试。
Usage: sudo gzip -cd iOSOpenDev.patch.gz | patch -p0
Ubuntu中为何没有/etc/inittab文件
最近在看LPI的书，里面经常提到/etc/inittab，正当我想在Ubuntu里看一看这个inittab一般“长”什么样子的时候，系统却告诉我No such file or directory.
这不是很重要的一个文件吗！怎么就不存在呢！
防止SSH暴力破解
首先来看看服务器有没有被别人暴力破解的迹象~
grep "Failed password for root" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -nr | more
这里的/var/log/auth.log (也就是SSH的日志)根据你的系统不同，文件也不同：
Continue reading 防止SSH暴力破解