1. 使用已加入 Azure Active Directory 域的设备连接 Microsoft 账户登录的设备需要添加 MicrosoftAccount\ 前缀。
2. 使用未加入域的设备连接已加入 Azure Active Directory 的设备需要取消勾选【仅允许运行使用网络级别身份验证的远程桌面的计算机连接(建议)】，并编辑rdp文件添加行
。
3. 使用高分屏连接远程桌面时会因分辨率过高而变得非常卡顿，解决方案是使用第三方修改的客户端，画面会稍微模糊。
使用app或者web端找到目标店铺，分享给微信好友或文件传输助手
使用PC登录微信，点击打开店铺链接
点击复制链接按钮，复制店铺链接到剪切板
粘贴店铺链接会得到
https://mobile.yangkeduo.com/mall_page.html?refer_share_id=kBwDgBBtmx6d6i1FOOipaJ7IRBTjTbDZ&refer_share_uid=3645162710&_wv=41729&refer_share_channel=message&share_uid=3645162710&mall_id=9870859&_wvx=10
找到其中的mall_id=9870859字段, 9870859 就是店铺ID了。
Visual Studio Code是现今最流行的编辑器，我也是从Sublime转过来的，一见面就爱不释手，尤其是它强大的生态系统，丰富的插件。
众所周知VS Code是基于Electron开发，打开VS Code的开发工具，你会发现它就是一个在Chrome上渲染的WEB应用，加上远程开发的需求所以VS Code Online的到来是迟早的事情，微软在5月份宣布了Web版的VS Code，但是迟迟不见上线，手痒的话可以先尝尝同人。
code-server是一个在服务器上搭建VS Code Online项目，基于官方的源码打了一些patch来完全剥离前后端。最新发布的是code-server v2预览版，很多功能已经比较稳定，支持了直接从官方源安装插件和语言包，但是最新的releases有较多Bug，我重新从源码编译了程序，并打包了中文语言，可以做到开箱即用。
默认简体中文，可以搭配利用Nginx快速搭建OAuth2.0 SSO单点登录系统，既可以作为远程开发的辅助，也可以当作WebShell管理服务器。
Google Cloud Shell是Google Cloud的一个Shell环境，默认集成了很多开发环境和Google Cloud SDK可以方便的管理云资源，它本身是一台 Docker 虚拟机，$HOME有5G永久磁盘，但是要求必须在120天内访问过，否则就会清空。其他目录的修改断开连接一小时后就会重置，空间不足的问题可以通过 gcsfuse my-bucket ~/my-bucket 映射Cloud Storage到本地。
支持网页预览，网页登录后访问 https://ssh.cloud.google.com/devshell/proxy?port=8080会指向Cloud Shell的8080端口，端口切换需要在网页端设置。
启用增强模式后在24小时内会提高主机性能，但每周有60小时使用时限，Cloud Shell的定位就是一台远程开发机，不能24小时运行，如果需要更强的性能可以尝试自定义环境。
说Cloud Shell是Google为开发人员发放的福利也不为过。
_,met$$$$$gg.
,g$$$$$$$$$$$$$$$P. OS: Debian 9.9 stretch
,g$$P"" """Y$$.". Kernel: x86_64 Linux 4.19.44+
,$$P' `$$$. Uptime: 8h 49m
',$$P ,ggs. `$$b: Packages: 590
`d$$' ,$P"' . $$$ Shell: bash 4.4.12
$$P d$' , $$P Disk: 31G / 45G (68%)
$$: $$. - ,d$$' CPU: Intel Xeon @ 2.2GHz
$$\; Y$b._ _,d$P' RAM: 856MiB / 3697MiB
Y$$. `.`"Y$$$$P"'
`$$b "-.__
`Y$$
`Y$$.
`$$b.
`Y$$b.
`"Y$b._
`""""
但是目前使用Cloud Shell只能在网页端，ALPHA SDK中提供的SSH访问方式，我本地测试没有成功唤起PuTTy，这样以来就感觉Cloud Shell离我们的距离有些远，要是能集成到Visual Studio Code那该多好，经过一番折腾后总算是能顺畅使用了，把结果分享在这里，也做个记录。
假设我们起了一个服务器在 1234 端口，但是我暴露在公网上，但是又需要被授权的人方便的使用，一般情况下我们会在程序里简单加一个密码验证，或者直接使用 Auth_Basic 设置一个用户名与密码。Nginx Auth_Basic 扫描是恶意爬虫最喜欢干的事，而限制 Auth_Basic 重试次数又需要配置 Fail2ban 之类的日志监控程序，很麻烦。
在应用层设置密码对大多数开发人员来说并没有什么难点，但是有时候我们搭建的系统并不是自己开发的，甚至是已经编译好的庞然大物，就有些困难了。
这里分享一个10分钟快速搭建 OAuth2.0 授权登录系统的方法，本文使用 github 作为示例。
由于各大运营商不同时间段出口带宽拥堵的问题，需要维护又连接不上服务器很恼火，整理一下通过代理访问SSH服务器的配置。
~/.ssh/config
Host hostname
ProxyCommand nc -x 127.0.0.1:1080 %h %p
命令行使用方法 ssh -o "ProxyCommand=nc -x 127.0.0.1:1080 %h %p" [email protected]
%UserProfile%\.ssh\config
Host hostname
ProxyCommand C:\Program Files\Git\mingw64\bin\connect.exe -S 127.0.0.1:1080 %h %p
批处理中要这样使用 ssh -o "ProxyCommand=C:\Program Files\Git\mingw64\bin\connect.exe -S 127.0.0.1:1080 %%h %%p" [email protected]
libstdc++.so.6: version `GLIBCXX_3.4.20' not found
错误信息是由于gcc版本低导致的，Centos通过yum无法升级，标准方案是手动编译安装，但是gcc编译少要半个小时，腾讯云的云盘可能要编译几个小时，不过有个取巧的办法，可以手动下载debian的二进制文件，下载地址 http://ftp.de.debian.org/debian/pool/main/g/gcc-*/ 根据需要选择 i386.deb 与 amd64.deb ，lib目录下放的是32位，lib64目录下是64位，如果是在其他奇怪的目录可以通过 file 命令查看原文件是32还是64位。
高能预警！！！
glibc是linux系统的核心部分，系统的很多文件就是基于这个程序编译，以下操作可能会导致未知的后果，仅限开发阶段，生产环境万万不可以。
然后在debian下解压出需要的文件
cd /usr/lib[ro lib64] chmod +x libstdc++.so.6.0.20 rm -f libstdc++.so.6 ln -s libstdc++.so.6.0.20 libstdc++.so.6
再检查一次看看
$ strings /usr/lib/libstdc++.so.6 | grep GLIBCXX GLIBCXX_3.4 GLIBCXX_3.4.1 GLIBCXX_3.4.2 GLIBCXX_3.4.3 GLIBCXX_3.4.4 GLIBCXX_3.4.5 GLIBCXX_3.4.6 GLIBCXX_3.4.7 GLIBCXX_3.4.8 GLIBCXX_3.4.9 GLIBCXX_3.4.10 GLIBCXX_3.4.11 GLIBCXX_3.4.12 GLIBCXX_3.4.13 GLIBCXX_3.4.14 GLIBCXX_3.4.15 GLIBCXX_3.4.16 GLIBCXX_3.4.17 GLIBCXX_3.4.18 GLIBCXX_3.4.19 GLIBCXX_3.4.20 GLIBCXX_DEBUG_MESSAGE_LENGTH
查看glibc版本
# 查看链接 ls -l /lib/libc.so.* # ldd 返回glibc版本 ldd --version
编译 glibc
curl -O http://ftp.gnu.org/gnu/glibc/glibc-2.18.tar.gz tar zxf glibc-2.18.tar.gz cd glibc-2.18/ mkdir build cd build/ ../configure --prefix=/usr make -j2 make install
首先这是一个历史遗留问题，这篇文章没有什么技术点，只是对刚接触 nginx 的同学解开一点可能遇到的困惑。
在诸多发行版中默认 nginx 安装后你会发现在 /etc/nginx 目录下有两个fastcgi配置文件，fastcgi_params 与 fastcgi.conf，运行diff后你会发现他们的区别只有一行，既fastcgi.conf多了一个fastcgi_params配置
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
SCRIPT_FILENAME 参数对PHP的运行是必不可少的，它的作用是告诉后端 PHP 应该执行哪个文件，但是由于历史原因他并没有被添加到 fastcgi_params 中。
在 nginx 0.6.x 时代，nginx 提供的默认配置中使用的是硬编码的方式
location ~ \.php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME /var/www/foo$fastcgi_script_name;
fastcgi_pass backend;
}
这对迁移造成了不必要的麻烦，后来 nginx 建议大家使用 $document_root 来替代真实路径，大家慢慢开始使用它来替换之前的硬编码方式，但是很多年以后很多人依然在使用绝对路径，于是 nginx 在 0.8.30 中开始提供一个新的配置文件 fastcgi.conf来保持向后兼容，这样以来社区就可以推荐大家使用 fastcgi.conf 不需要在 location 中手动添加 SCRIPT_FILENAME。
现在我们引入这个文件可以使用下面的方式
location ~ \.php$ {
include fastcgi.conf;
fastcgi_pass backend;
}
如果你发现你的配置文件是
location ~ \.php$ {
include fastcgi_params;
SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass backend;
}
那也不用着急去修改自己的配置文件，无论使用这两种的哪一种，对 nginx 来说都是一样的。
Forsaken Mail 没有域名限制，只需要将自己的域名解析到已经部署的任意服务器。
1、服务器需要开启25端口
2、域名解析
# MX记录 xx.com MX 10 mx.xx.com # A记录 mx.xx.com A 服务器IP # A记录 mail.xx.com A 服务器IP
随着TLS 1.3问世，网络流量迈入了新时代，DoH和DoT都是将不同形式的数据包通过TLS 1.3加密，网络中可嗅探的数据变得越来越少，我前面发过一篇透过公共Wi-Fi 热点上网究竟安不安全，DNS加密后并且全程使用HTTPS协议，网关中依然会泄露访问的域名。
这里就需要普及一个名词叫做SNI，简单说因为服务器和客户端建立加密连接之前，客户端需要请求证书并明文发送主机名给服务器，服务器发送证书后，本地客户端再加以校验，这是因为通常同一个服务器端会部署多个域名服务，TLS握手发生在建立加密连接之前，如果直接扔过来一个加密包服务器端无法知道包的内容，也无法决定返回哪一个证书，所以网关仍然可以获取客户端访问的域名列表。
题外话：由于SNI的特性，通常NGINX服务器直接通过域名访问会泄露配置文件中的第一个证书，而有心者这可以通过证书内容获取很多信息，这个“漏洞”暂时还无法解决。
IETF在最新的草案中设计了一种新的加密SNI机制 Encrypted Server Name Indication（ESNI），ESNI要求DNS服务器负责随解析记录分发一个公钥，这样在TLS握手时，客户端就可以将通过加密DNS获取的公钥一并发送给服务器来直接建立加密连接，从而堵上了信息泄露的最后一个口子。
ESNI目前还在草案中，甚至还有很多可用性修复工作正在进行中，不过各大浏览器上已经在积极适配，Cloudflare在ESNI上特别积极，他们已经在1.1.1.1和所有Cloudflare节点部署ESNI完成。
目前浏览器支持方面比较悲观，仅Firefox 62+可以开启，Chrome开发组表示ESNI需要基于安全稳定的DNS服务，将会放在DoH适配之后，Cloudflare还煞有介事的制作了一个ESNI支持检测。
Firefox 开启 ESNI 方法
在地址栏输入about:config进入设置页面，修改network.trr.mode选项，设置为2优先使用DoH，设置为3则仅使用DoH。
修改network.trr.uri选项可以指定DoH服务器，默认是https://mozilla.cloudflare-dns.com/dns-query，我们也可以手动修改为https://dns.google.com/experimental或者https://1.0.0.1/dns-query。
也可以修改network.trr.resolvers值后，在选项 网络设置中配置服务器。
[{ "name": "Cloudflare", "url": "https://mozilla.cloudflare-dns.com/dns-query" },{ "name": "1.0.0.1", "url": "https://1.0.0.1/dns-query" },{ "name": "Google", "url": "https://dns.google/dns-query" },{ "name": "朽木", "url": "https://dns.xiumu.org/dns-query" }]
接下来点击修改network.security.esni.enabled即可开启ESNI。