经常出现ssh连接由于网络问题，“卡住”了。不能进行任何操作，也不能退出。 ssh文档里面也有写通过~.来断开ssh连接：

$ man ssh
…
ESCAPE CHARACTERS
…

 The supported escapes (assuming the default \`~') are:

 ~.      Disconnect.

 ~?      Display a list of escape characters.

但是，实际使用过程中发现，按了没有反应。 后来看了其他人的做法，发现两个技巧：

1. ssh转义字符，只有在新行生效。所以最保险的按键方式是：回车 -> Shift+` -> .。
2. 由于输入两个~会导致ssh直接发送~。比如我们按~``~``~``. 会关闭第二层ssh，而不是当前失去响应的ssh会话。

所以为了保险起见，我的操作是这样子的： 按 回车``~``?，直到出现ssh的转义字符帮助（没有出现就继续按回车``~``?） 然后按 ~``.。 退出ssh

按~``~``~``. 会关闭第二层ssh，对吗？

1. ~``~是给第一层ssh会话发送~字符
2. ~``~``~是给第二层ssh会话发送~字符
3. ~``~``~``.是给第二层ssh会话发送~``.字符，即关闭第二层ssh会话

首先，来一张非常有用的图：

基础知识

iptables可以jump到TRACE目标，开启_包追踪_（packet tracing）选项。 iptables有一个raw表，基本上是iptables最先处理包的地方。

开始调试

在最入口的位置给符合条件的包开启包追踪，比如对所有进入的icmp包：

1

iptables -t raw -I PREROUTING -p icmp -j TRACE

有的时候，还需要加载需要的模块（CentOS 7下）：

1

modprobe nf_log_ipv4

然后你就可以在/var/log/messages日志中看到包追踪信息了。

翻译自https://hdante.wordpress.com/2014/07/08/the-hello-wayland-tutorial/

TLDR

我写了一个wayland下的hello world，源码在 https://github.com/hdante/hello_wayland。

介绍

从最终用户的角度，很容易理解wayland是什么：它是一个新的窗口系统，它将显示服务器和窗口管理器合并了[1]。从技术角度来看，wayland是为了摆脱传统，使用现代设计来实现一个高效的窗口系统，解决X窗口系统中长期存在的效率问题和一些极端情况[2]。这个教程展示如何实现一个作为wayland客户端的hello world程序、解释基础的wayland概念、创建一个GUI程序的必要流程。hello world程序不需要任何GUI工具包，它直接使用底层的wayland协议，以便解释wayland的基础概念。本教程是我自己研究wayland协议的结果。教程分为两部分。这是第一篇教程，解释所有的概念和程序的高级部分。

再问一次，什么是wayland？

wayland窗口系统的的完整设计分为好几层。如果你下载了wayland library的代码[3]，或者你看了下wayland的API[4]，你会注意到两层：

1. 最基础的一层是进程间通讯功能的实现，以及一些实用工具。比如主循环调度器和一些数据类型。大部分这些代码都出现在wayland library中（所有在src文件夹[5]中的内容），并且和窗口系统无关。
2. 第二层是窗口系统协议。它的描述在protocol/wayland.xml[6]文件中，这个文件应该算是一种接口定义语言。IDL文件可以用wayland-scanner 工具处理，并在 wayland-client-protocol.h 和 wayland-server-protocol.h中生成代理方法。协议定义了客户端程序和显示服务器的基础功能。比如访问输入设备、注册共享缓存以便显示在屏幕上。wayland library并不实现这些协议。这些协议的实现被分割到一个第三方层。服务端的参考实现是weston的一部分[7]，它在客户端和服务端都定义了一些附加层。以实现wayland协议。在hello world程序中，我们并不需要了解任何关于weston的东西。我们仅仅需要IDL文件。

从上面关于wayland library的描述中，我们发现wayland的三个定义。它是一个（额听用途的）IPC库，不像D-Bus库，它仅仅用于显示服务器，并且它没有定义wayland到底是什么、wayland协议的定义以及如何找到协议定义。我相信即使人们在阅读官方文档后，大部分人也不明白wayland到底是什么。我想，这三个定义澄清了“什么是wayland”这个问题，每一个定义都能够用在不同的上下文中。

Hello, World!

最近在做一个 https://packagist.org 的镜像，所以需要一个CDN来做国内加速。国内比较适合的也就七牛和又拍云了。

作为CDN

后来比较了下，发现七牛仅仅是做存储，它会忽略用户设置的超时时间（Cache-Control 字段）。而又拍云则会遵守源站的缓存设置。 比如我如果设置我的url缓存为5min，那又拍云就只会保留缓存5min。 在这一点上，又拍云就做的非常好，可以选择存储模式，也可以选择CDN模式。当然，更重要的一点是有免费额度。相比七牛的免费额度来讲，确实比较宽裕。 比如，我的这个项目，源站是在我的vps上，接受http访问。那我只需要将空间的回源设置如图即可：

支持SSL/TLS

为了让我的域名支持SSL/TLS，我只需在云拍云上花费0元购买Let’s Encrypt的SSL证书，然后补全信息即可。 如图： 我绑定了又拍云，然后又拍云直接向Let’s Encrypt申请DV证书，绑定到域名就行。 相比其他服务商，需要手动上传服务器证书，确实方便了很多。而且自己手动申请的Let’s Encrypt证书，需要每90天更新一次，所以还是直接交给又拍云比较方便。

云存储

和云存储厂商一样，又拍云也提供了对象存储服务。 基本的文件操作都是支持的。当然，也必须支持断点续传，对于上传大文件来说，这个尤其方便。 还可以给文件添加各种自定义的元数据，比如我可以给文件设置x-upyun-meta-sha512: 123456，可以参考https://docs.upyun.com/api/rest_api/#metadata。 但是这儿也有一些坑： 比如，获取文件信息： MD5算法确实有很严重的漏洞，容易产生重复的哈希值。建议又拍云下一版换成sha512算法。 还有，如果我设置了自定义元数据，比如x-upyun-meta-sha512: 123456，那我只能通过下载文件接口来获取这个元数据，通过获取文件信息接口反而没有自定义的元数据，这一点很不方便。

文件拉取

做镜像的过程中，很重要的一个点就是文件拉取。 比如，我要代理laravel的下载地址：https://github.com/laravel/framework/archive/v5.5.13.zip，我只需要将url拉取到又拍云上对应的地址就好。 但是，由于要使用回调，在调试的时候很不方便，所以目前我用的比较少。 建议又拍云在拉取文件的时候，给拉取任务一个id，然后客户端根据这个id查询拉取状态，会方便开发。

又拍云重度用户

Round #1

Complete output from command python setup.py egg_info:
sh: mysql_config: command not found

Solution

brew install mysql

or

brew reinstall mysql

Round #2

clang -bundle -undefined dynamic_lookup ****/_mysql.o -L/usr/local/Cellar/mysql/5.7.18_1/lib -lmysqlclient -lssl -lcrypto -o build/lib.macosx-10.12-x86_64-2.7/_mysql.so
ld: library not found for -lssl

Solution

brew install openssl
export LDFLAGS=”-I/usr/local/opt/openssl/include -L/usr/local/opt/openssl/lib”
pip install mysql-python

翻译自 How input works – pointer input。 在上一篇博文中，我讨论了键盘输入。这篇博文将会讨论指针设备——多被称为鼠标。就像本系列文章一样，本文仅仅讨论了KWin／Wayland上面的情形。

不同的硬件类型

有好几种不同的设备被识别为指针设备。有轨迹球这样的传统鼠标，也有在笔记本上的触摸板。此外，还有可绝对定位的设备，比如触摸屏。 在libinput中，对于不同的设备，有很多不同的选项可供配置。比如指针加速等其他选项。我们正在开发Wayland的触摸板配置模块，看起来会合并到Plasma 5.9中。像第一篇博文描述的，一旦设备创建，一系列配置选项会被立马设置。

指针运动

指针设备生成不同种类的事件，其中一种就是指针运动事件。通常来说，有两种指针运动事件：绝对运动和相对运动。大多数设备，比如鼠标，产生相对运动事件，所以我们在本文中只关注相对运动事件。

确定新的位置

相对运动是一组带x和y坐标的距离向量，它描述了指针位置该如何移动。 所以，一旦事件从KWin队列中读取出来，需要确定新的指针位置。这并不单单是最后的指针位置再加上一个运动向量。这会导致指针离开可视区域。 相反，指针运动得验证和约束。我们确保光标不会离开可视区域，并且还要遵守应用程序窗口对指针的约束。 这是KWin在Plasma 5.9中支持的新协议。它允许Wayland窗口将指针锁定到某个位置或将指针限制在某个区域。在第一种情况下，指针根本不移动，在第二种情况下，只允许指针在窗口的特定区域移动。

处理新的位置

即使在光标被限定的情况下，不需要移动鼠标指针，事件也会得到进一步处理。即使光标不移动，应用程序也可能对相对运动感兴趣，并对其做出反应。 像键盘的情况一样，为了进一步处理，会生成QMouseEvent并发送到KWin的输入过滤器。指针运动可能在KWin内部处理，例如：指针位置超出了当前的屏幕边缘。或者通过KWayland将指针运动转发到窗口。

更新获取焦点的窗口

虽然为知收费了，但是目前只有为知笔记的Linux客户端做的不错，也只能用它了。 首先，安装编译期间的依赖：

# git拉代码，cmake编译
sudo dnf install -y git cmake

编译器

sudo dnf install -y gcc gcc-c++

qt5相关的包

sudo dnf install -y qt5-qtbase-devel qt5-linguist qt5-qtwebengine-devel qt5-qtwebsockets-devel

sudo dnf install -y zlib-devel

拉代码（此处以v2.5.0分支为例）：

git clone https://github.com/WizTeam/WizQTClient.git
cd /path/to/WizQTClient
git checkout v2.5.0

编译：

本文是 How input works – Keyboard input 的翻译。

在上一篇博客中，原作者解释了KWin中，输入设备是如何打开和处理的。在这篇博文中，我们将仔细关注下键盘设备和键盘事件。

键盘并不总是键盘

在Linux中，键盘是一个非常奇特的设备。你不会只有一个键盘，你肯定会有很多个。很多设备宣称自己是键盘，但是只支持一个键。比如，电源按钮或者带静音按钮、音量加减按钮的外置耳机。从输入系统的角度来看，这些设备也是键盘。

对于KWin，发现真正支持的键盘是很重要的。如果没有一个“真的”键盘连接（或者说开启），我们的虚拟键盘应该自动激活。比如，如果你从平板PC二合一设备上拔了键盘，它应该转换为平板模式，即有虚拟键盘的模式。如果连接上了键盘，虚拟键盘就不是主要的输入设备了。libinput提供了函数来检测键盘支持哪些键。我们使用这个功能来区分不同的键盘类型。

键盘事件

在这里，键盘是最简单的输入设备。libinput仅仅触发一个LIBINPUT_EVENT_KEYBOARD_KEY事件，并包含了被按下或者释放的键。KWin有一个专用线程，用来从libinput读取事件。所以这些事件现在仅仅是放在处理队列中，主线程同时也得到新事件通知。一旦主线程处理事件，事件就被转换成我们的输入重定向类。不管事件是通过哪种源头抵达，所有输入事件都会通过输入重定向。KWin不仅仅支持来自libinput的事件，并且支持嵌套会话(即KWin运行在X11之上，或者在另一个Wayland服务器之上)，还有在集成测试中使用的模拟事件。这意味着一旦事件到达输入重定向，我们基本上就丢失了事件来自哪个设备这些信息。最近，我们扩展了内部API，可以在事件处理函数中包含设备源，这是可选的。可以在调试终端中使用，来显示哪些设备产生了哪些事件。

xkbcommon

现在，一个键的按下、释放事件到达了中心分发方法KeyboardInputRedirection::processKey。第一件也是重要的一件事就是在xbkcommon中更新键盘状态。xkbcommon被用将物理键为事件，转换过程根据键盘布局、键盘状态（比如激活的修饰符）来进行。比如：如果我按下了“y”键（键码是21）并且“Shift”键是按下的状态，在德语键盘布局下，就会创建“Z”按下的事件；但是在英语键盘布局下，它会是“Y”。

在KWin中，我们将所有需要的xkbcommon功能都封装到Xkb类中。这个类追踪活跃的键盘布局、执行键盘布局切换（当布局变换的时候展示OSD）。它知道上一次按键的符号，当前活跃的修饰符和快捷键相关的修饰符。

在公司通过kerberos登录ssh，完全没有问题。但是在家里通过l2tp连接vpn后，就无法登录了。

通过ssh -v查看日志，发现卡在debug1: SSH2_MSG_KEXINIT sent这一步。

查了下，发现是因为mtu设置太大。

但是由于系统的网络是NetworkManager管理的，如果需要自动设置mtu，connection的配置中并没有vpn对应的mtu设置。

后来，看了有人使用dispatcher脚本来设置：

创建/etc/NetworkManager/dispatcher.d/vpn-up文件，内容如下

1
2
3
4
5

#!/bin/sh

if [ "$2" = "vpn-up" ]; then
  ip link set "$1" mtu 1350
fi

然后vpn连接的时候，就会自动设置mtu了。

本文是How input works – creating a Device的翻译。

最近，我(原作者，下同）在KWin/Wayland输入栈上做了一些工作，比如实现了鼠标手势和鼠标限制协议（pointer constraints protocol），并且想写一些系列博客来描述输入事件是如何从设备传递到应用的。在第一篇博文中，我将关注于创建和配置输入设备，以及与此相关的其他事情。

evdev

Linux内核通过evdev API来产生输入事件。如果你对evdev如何工作感兴趣，我推荐你读一读Peter Hutterer写的优秀的博文。对于我们关注的层面来说，输入事件API太底层了，我们仅仅想用对它的一个抽象。

libinput 和设备文件

对输入事件API的抽象叫做libinput。它允许我们得到通知，不论何时添加、删除输入设备、不论何时产生输入事件。但是别急，我们首先需要打开输入设备，这是我们的第一个挑战。

正常情况下，设备文件不能被用户读取。这有好的一面，否则每个程序都能够读取所有的键盘事件。这种情况下，键盘记录器太容易实现了。

但是如果KWin以普通用户的方式运行，普通用户又无法读取设备文件，那KWin如何获取输入？为了让KWin获取输入，我们需要特殊的支持。libinput就是为这种情况准备的，它自己不会尝试打开文件，它会使用用户提供的open_restricted函数。KWin就是这么干的，并将打开文件的任务交给了logind。logind允许一个进程控制当前登录会话。并且这个登录会话的控制进程可以打开一些设备文件。所以KWin和logind的dbus API交互，成为登录会话的控制进程，通过logind的API打开设备文件，并将其传递回libinput。

这也是为什么对于整个Wayland会话，KWin在运行时依赖logind的DBus接口。请注意，这并不意味着你需要使用logind或者sysemd。这仅仅意味着需要一个进程来同logind的DBus接口通讯。

KWin中的设备