MacOS homebrew 更改为阿里源

简介

Homebrew 是一个软件包管理系统,用以简化 macOS 和 linux 系统上的软件安装过程。它拥有安装、卸载、更新、查看、搜索等很多实用的功能,通过简单的一条指令,就可以实现包管理,十分方便快捷。

Homebrew 主要有四个部分组成: brewhomebrew-corehomebrew-bottleshomebrew-cask

名称 说明
brew Homebrew 源代码仓库
homebrew-core Homebrew 核心软件仓库
homebrew-bottles Homebrew 预编译二进制软件包
homebrew-cask 提供 macOS 应用和大型二进制文件

替换为阿里源

# 查看 brew.git 当前源
$ cd "$(brew --repo)" && git remote -v
origin    https://github.com/Homebrew/brew.git (fetch)
origin    https://github.com/Homebrew/brew.git (push)

# 查看 homebrew-core.git 当前源
$ cd "$(brew --repo homebrew/core)" && git remote -v
origin    https://github.com/Homebrew/homebrew-core.git (fetch)
origin    https://github.com/Homebrew/homebrew-core.git (push)

# 修改 brew.git 为阿里源
$ git -C "$(brew --repo)" remote set-url origin https://mirrors.aliyun.com/homebrew/brew.git

# 修改 homebrew-core.git 为阿里源
$ git -C "$(brew --repo homebrew/core)" remote set-url origin https://mirrors.aliyun.com/homebrew/homebrew-core.git

# zsh 替换 brew bintray 镜像
$ echo 'export HOMEBREW_BOTTLE_DOMAIN=https://mirrors.aliyun.com/homebrew/homebrew-bottles' >> ~/.zshrc
$ source ~/.zshrc

# bash 替换 brew bintray 镜像
$ echo 'export HOMEBREW_BOTTLE_DOMAIN=https://mirrors.aliyun.com/homebrew/homebrew-bottles' >> ~/.bash_profile
$ source ~/.bash_profile

# 刷新源
$ brew update

重置为官方源

# 重置 brew.git 为官方源
$ git -C "$(brew --repo)" remote set-url origin https://github.com/Homebrew/brew.git

# 重置 homebrew-core.git 为官方源
$ git -C "$(brew --repo homebrew/core)" remote set-url origin https://github.com/Homebrew/homebrew-core.git

# 重置 homebrew-cask.git 为官方源
$ git -C "$(brew --repo homebrew/cask)" remote set-url origin https://github.com/Homebrew/homebrew-cask

# zsh 注释掉 HOMEBREW_BOTTLE_DOMAIN 配置
$ vi ~/.zshrc
# export HOMEBREW_BOTTLE_DOMAIN=xxxxxxxxx

# bash 注释掉 HOMEBREW_BOTTLE_DOMAIN 配置
$ vi ~/.bash_profile
# export HOMEBREW_BOTTLE_DOMAIN=xxxxxxxxx

# 刷新源
$ brew update

Kubernetes的Kata Containers 与 gVisor - ghostwritten

原文:https://blog.csdn.net/xixihahalelehehe/article/details/119942945

1. 容器发展

使用虚拟化技术来做一个像 Docker 一样的容器项目,并不是一个新鲜的主意。早在 Docker 项目发布之后,Google 公司就开源了一个实验性的项目,叫作 novm。这,可以算是试图使用常规的虚拟化技术来运行 Docker 镜像的第一次尝试。不过,novm 在开源后不久,就被放弃了,这对于 Google 公司来说或许不算是什么新鲜事,但是 novm 的昙花一现,还是激发出了很多内核开发者的灵感。

所以在 2015 年,几乎在同一个星期,Intel OTC (Open Source Technology Center) 和国内的 HyperHQ 团队同时开源了两个基于虚拟化技术的容器实现,分别叫做 Intel Clear ContainerrunV 项目。

而在 2017 年,借着 Kubernetes的东风,这两个相似的容器运行时项目在中立基金会的撮合下最终合并,就成了现在大家耳熟能详的 Kata Containers 项目。 由于 Kata Containers 的本质就是一个精简后的轻量级虚拟机,所以它的特点,就是“像虚拟机一样安全,像容器一样敏捷”。

而在 2018 年,Google 公司则发布了一个名叫 gVisor 的项目。gVisor 项目给容器进程配置一个用 Go 语言实现的、运行在用户态的、极小的“独立内核”。这个内核对容器进程暴露 Linux 内核 ABI,扮演着“Guest Kernel”的角色,从而达到了将容器和宿主机隔离开的目的。

难看到,无论是 Kata Containers,还是 gVisor,它们实现安全容器的方法其实是殊途同归的。这两种容器实现的本质,都是给进程分配了一个独立的操作系统内核,从而避免了让容器共享宿主机的内核。这样,容器进程能够看到的攻击面,就从整个宿主机内核变成了一个极小的、独立的、以容器为单位的内核,从而有效解决了容器进程发生“逃逸”或者夺取整个宿主机的控制权的问题。这个原理,可以用如下所示的示意图来表示清楚。

在这里插入图片描述 而它们的区别在于,Kata Containers 使用的是传统的虚拟化技术,通过虚拟硬件模拟出了一台“小虚拟机”,然后在这个小虚拟机里安装了一个裁剪后的 Linux 内核来实现强隔离。

而 gVisor 的做法则更加激进,Google 的工程师直接用 Go 语言“模拟”出了一个运行在用户态的操作系统内核,然后通过这个模拟的内核来代替容器进程向宿主机发起有限的、可控的系统调用。接下来,我就来为你详细解读一下 KataContainersgVisor 具体的设计原理。

2. KataContainers原理

在这里插入图片描述

我们前面说过,Kata Containers 的本质,就是一个轻量化虚拟机。所以当你启动一个 Kata Containers 之后,你其实就会看到一个正常的虚拟机在运行。这也就意味着,一个标准的虚拟机管理程序(Virtual Machine Manager, VMM)是运行 Kata Containers 必备的一个组件。在我们上面图中,使用的 VMM 就是 Qemu

而使用了虚拟机作为进程的隔离环境之后,Kata Containers 原生就带有了 Pod 的概念。即:这个 Kata Containers 启动的虚拟机,就是一个 Pod;而用户定义的容器,就是运行在这个轻量级虚拟机里的进程。在具体实现上,Kata Containers 的虚拟机里会有一个特殊的 Init 进程负责管理虚拟机里面的用户容器,并且只为这些容器开启 Mount Namespace。所以,这些用户容器之间,原生就是共享 Network 以及其他 Namespace 的。

此外,为了跟上层编排框架比如 Kubernetes 进行对接,Kata Containers 项目会启动一系列跟用户容器对应的 shim 进程,来负责操作这些用户容器的生命周期。当然,这些操作,实际上还是要靠虚拟机里的 Init 进程来帮你做到。而在具体的架构上,Kata Containers 的实现方式同一个正常的虚拟机其实也非常类似。这里的原理,可以用如下所示的一幅示意图来表示。

在这里插入图片描述 可以看到,当 Kata Containers 运行起来之后,虚拟机里的用户进程(容器),实际上只能看到虚拟机里的、被裁减过的 Guest Kernel,以及通过 Hypervisor 虚拟出来的硬件设备。

而为了能够对这个虚拟机的 I/O 性能进行优化,Kata Containers 也会通过 vhost 技术(比如:vhost-user)来实现 GuestHost 之间的高效的网络通信,并且使用 PCI Passthrough (PCI 穿透)技术来让 Guest 里的进程直接访问到宿主机上的物理设备。这些架构设计与实现,其实跟常规虚拟机的优化手段是基本一致的。

3. gVisor原理

相比之下,gVisor 的设计其实要更加“激进”一些。它的原理,可以用如下所示的示意图来表示清楚。

在这里插入图片描述 gVisor 工作的核心,在于它为应用进程、也就是用户容器,启动了一个名叫 Sentry 的进程。 而 Sentry 进程的主要职责,就是提供一个传统的操作系统内核的能力,即:运行用户程序,执行系统调用。所以说,Sentry 并不是使用 Go 语言重新实现了一个完整的 Linux 内核,而只是一个对应用进程“冒充”内核的系统组件。

在这种设计思想下,我们就不难理解,Sentry 其实需要自己实现一个完整的 Linux 内核网络栈,以便处理应用进程的通信请求。然后,把封装好的二层帧直接发送给 Kubernetes 设置的 Pod 的 Network Namespace 即可。

此外,Sentry 对于 Volume 的操作,则需要通过 9p 协议交给一个叫做 Gofer 的代理进程来完成。Gofer 会代替应用进程直接操作宿主机上的文件,并依靠 seccomp 机制将自己的能力限制在最小集,从而防止恶意应用进程通过 Gofer 来从容器中“逃逸”出去。

而在具体的实现上,gVisorSentry 进程,其实还分为两种不同的实现方式。这里的工作原理,可以用下面的示意图来描述清楚。 在这里插入图片描述 第一种实现方式,是使用 Ptrace 机制来拦截用户应用的系统调用(System Call),然后把这些系统调用交给 Sentry 来进行处理。这个过程,对于应用进程来说,是完全透明的。而 Sentry 接下来,则会扮演操作系统的角色,在用户态执行用户程序,然后仅在需要的时候,才向宿主机发起 Sentry 自己所需要执行的系统调用。这,就是 gVisor 对用户应用进程进行强隔离的主要手段。不过, Ptrace 进行系统调用拦截的性能实在是太差,仅能供 Demo 时使用。

而第二种实现方式,则更加具有普适性。它的工作原理如下图所示。

在这里插入图片描述

在这种实现里,Sentry 会使用 KVM 来进行系统调用的拦截,这个性能比 Ptrace 就要好很多了。当然,为了能够做到这一点,Sentry 进程就必须扮演一个 Guest Kernel 的角色,负责执行用户程序,发起系统调用。而这些系统调用被 KVM 拦截下来,还是继续交给 Sentry 进行处理。只不过在这时候,Sentry 就切换成了一个普通的宿主机进程的角色,来向宿主机发起它所需要的系统调用。

可以看到,在这种实现里,Sentry 并不会真的像虚拟机那样去虚拟出硬件设备、安装 Guest 操作系统。它只是借助 KVM 进行系统调用的拦截,以及处理地址空间切换等细节。值得一提的是,在 Google 内部,他们也是使用的第二种基于 HypervisorgVisor 实现。只不过 Google 内部有自己研发的 Hypervisor,所以要比 KVM 实现的性能还要好。

4. 对比

通过以上的讲述,相信你对 Kata Containers 和 gVisor 的实现原理,已经有一个感性的认识了。需要指出的是,到目前为止,gVisor 的实现依然不是非常完善,有很多 Linux 系统调用它还不支持;有很多应用,在 gVisor 里还没办法运行起来。 此外,gVisor 也暂时没有实现一个 Pod 多个容器的支持。当然,在后面的发展中,这些工程问题一定会逐渐解决掉的。

另外,你可能还听说过 AWS 在 2018 年末发布的一个叫做 Firecracker 的安全容器项目。这个项目的核心,其实是一个用 Rust 语言重新编写的 VMM(即:虚拟机管理器)。这就意味着, FirecrackerKata Containers 的本质原理,其实是一样的。只不过, Kata Containers 默认使用的 VMM 是 Qemu,而 Firecracker,则使用自己编写的 VMM。所以,理论上,Kata Containers 也可以使用 Firecracker 运行起来。

在性能上,KataContainers 和 KVM 实现的 gVisor 基本不分伯仲,在启动速度和占用资源上,基于用户态内核的 gVisor 还略胜一筹。但是,对于系统调用密集的应用,比如重 I/O 或者重网络的应用,gVisor 就会因为需要频繁拦截系统调用而出现性能急剧下降的情况。此外,gVisor 由于要自己使用 Sentry 去模拟一个 Linux 内核,所以它能支持的系统调用是有限的,只是 Linux 系统调用的一个子集。

不过,gVisor 虽然现在没有任何优势,但是这种通过在用户态运行一个操作系统内核,来为应用进程提供强隔离的思路,的确是未来安全容器进一步演化的一个非常有前途的方向。值得一提的是,Kata Containers 团队在 gVisor 之前,就已经 Demo 了一个名叫 Linuxd 的项目。这个项目,使用了 User Mode Linux (UML) 技术,在用户态运行起了一个真正的 Linux Kernel 来为应用进程提供强隔离,从而避免了重新实现 Linux Kernel 带来的各种麻烦。


MacOS 更改默认截图文件名

Mac中默认的中文截图名太难看/难以快速理解/自动化软件复用了。

截屏2022-02-12 上午10.15.29.png

这里记录下几个配置,多数为在终端中输入命令,可以按需更改。

一、更换前缀

defaults write com.apple.screencapture name "TheNameDesired"

重启服务

killall SystemUIServer

二、更换“下午”为英文名称

系统偏好设置->语言与地区->高级:

image-20220219104722333

把上午下午改为am/pm即可。

image-20220219104827899

三、更换默认截图的图片格式

OS X 默认识别以下图片格式:「.jpg」「.gif」「.pdf」「.png」和「.tiff」,所以你可以设置截图文件格式为上述 5 种。

defaults write com.apple.screencapture type jpg;killall SystemUIServer
defaults write com.apple.screencapture type gif;killall SystemUIServer
defaults write com.apple.screencapture type PDF;killall SystemUIServer
defaults write com.apple.screencapture type png;killall SystemUIServer
defaults write com.apple.screencapture type tiff;killall SystemUIServer

四、移除时间戳

如果不需要时间,也可以直接移除:

defaults write com.apple.screencapture "include-date" 0
killall SystemUIServer

参考资料


MacOS 文件默认列表展示

这不算个重要的东西,但是还是记录一下,太久不用Mac已经忘记如何设置了。

标题栏->显示->查看显示选项

image-20220219105944564

勾选始终以列表视图打开,然后点击用于默认

image-20220219110038527


Hidden Bar:一键折叠,给 macOS 菜单栏解压 - 少数派

原文:https://sspai.com/post/58194

一直觉得 Windows 托盘区可收纳的功能非常人性化,不像 macOS 的菜单栏势要把顶部的长条填满。

weixin

冬天看着菜单栏这些图标抱团取暖,没准还能让你感觉一丝暖意。但大部分时候都是有些碍眼,甚至在与某些软件菜单栏重合会直接隐藏。

部分软件运行在后台完全可以通过快捷键操作,例如 Magnet,这样看来不是很必要在菜单栏占坑,然而真正支持隐藏菜单栏图标的软件并不多。 Apple 官方也迟迟没有加入菜单栏收纳的功能,只能依赖第三方工具了。

Xnip2019-12-30_22-38-12

此前,大家推荐最多的这类工具是 Bartender 3,售价 15 美元。而在 macOS 10.15 上,有用户反馈会索取「全屏录制」权限(官方回应并不会记录用户隐私信息),出于隐私考虑他换用了 Hidden Bar

Xnip2019-12-30_22-43-11

Hidden Bar 是一款免费开源的工具,已经上架 Mac App Store,并且在最新的版本中加入了中文的支持。

Mockup

直接看效果,Hidden Bar 在展开的状态下还是会占用菜单栏空间,打开后菜单栏会出现「|」以及「>」或者「<」(分别代表展开和折叠两种状态)。

Mockup2

使用起来也比较简单,按住 Command 键,拖动想要折叠的图标移到「|」符号左侧就可以了,点击「>」就可以直接折叠,菜单栏也瞬间清爽了。

截屏2019-12-30下午11.15.37

「|」和「>」是可以分开的,你可以自由放置,比如,把「>」拖到最右侧,点击之后折叠的还是「|」左侧的所有图标。

不过要注意一个逻辑问题,「>」不能放置在「|」左侧,毕竟它不能把自己也折叠进去。

Xnip2019-12-30_23-22-10

Hidden Bar 可以设置用全局快捷键实现折叠/展开,使用更便捷;同时支持延时折叠菜单栏图标。

Xnip2019-12-30_23-26-13

略有一丢丢不完美的是,Hiden Bar 中文支持并不完整,不过也基本不影响使用,估计很快会完善了。

如果你也在为 macOS 菜单栏位置紧张烦恼,这款小工具或许可以给你解压,而且还是免费的,甚至会吸引一部分Bartender 3 付费用户。我也发现 GitHub 上还有一款 Dozer 的应用,在功能上与 Hidden Bar 几乎一致,只是显示图标上略有不同,暂且不知道两者是否有关联,大家有兴趣的也可以尝试。


MacOS 无共享密钥使用 L2tp

先前有过两篇 L2tp相关的配置,分别是 WinLinux 的。这篇讲一下 Mac 下的。不知道为什么,我配置的总是需要手动添加路由。有可能是哪一部分工作漏掉了,不过只要它能跑起来就行。It just works。

一、配置 L2tp

左下角新增网络连接,选择L2tp

image-20220211110945026

填写账户信息。

屏幕快照 2022-02-11 上午11.16.18

鉴定设置:

屏幕快照 2022-02-11 上午11.24.17

公司给的VPN没有共享密钥,如果你也没有,要在 /etc/ppp/ 下创建 options 文件:

sudo vim /etc/ppp/options

文件内容如下:

plugin L2TP.ppp
l2tpnoipsec

image-20220211112958756

然后开始连接。

二、添加路由

当前路由表内容如下:

netstat -rn

image-20220211094208106

无效内容太多了,只看ppp0的。

image-20220211094611522

看得出来网关地址应该是 192.168.100.254

将要访问的ip声明为走 ppp0 网卡,使用下面的命令添加路由,我假定我们要代理的ip为 10.187.0.0/24

# 添加路由
sudo route -n add -net 10.187.0.0 -netmask 255.255.255.0 192.168.100.254

# 备忘,删除路由命令
sudo route -v delete -net 10.187.0.0/24 -gateway 192.168.100.254

添加好路由,就可以访问我们想访问的资源了。完成。

参考资料