加入域后的Windows系统 访问外部资源会携带已登录的域用户凭证，未加入域的Samba就无法访问（Samba目前也不支持Azure AD），会提示未知错误
解决办法 打开控制面板 凭据管理器 添加Windows凭据
输入Samba文件服务器地址
用户名输入Samba的用户信息
如果是匿名访问 需要输入 计算机名\guest 密码留空
加入Azure AD域的计算机无法访问域外Samba
0
加快GitHub git clone 速度
151.101.72.249 github.global.ssl.fastly.net 140.82.112.4 github.com
Windows远程桌面连接常见问题
1. 使用已加入 Azure Active Directory 域的设备连接 Microsoft 账户登录的设备需要添加 MicrosoftAccount\ 前缀。
2. 使用未加入域的设备连接已加入 Azure Active Directory 的设备需要取消勾选【仅允许运行使用网络级别身份验证的远程桌面的计算机连接(建议)】，并编辑rdp文件添加行
。
3. 使用高分屏连接远程桌面时会因分辨率过高而变得非常卡顿，解决方案是使用第三方修改的客户端，画面会稍微模糊。
4. 国内公网环境UDP丢包厉害 可以尝试关闭 组策略 管理模板 Windows组件 远程桌面服务 主机或客户端任意一方关闭就不再使用UDP通信
获取拼多多店铺ID
获取拼多多店铺ID
使用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 Online 来了！一键搭建私有 Web 版 Visual Studio Code
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管理服务器。
Visual Studio Code SSH 连接 Google Cloud Shell
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那该多好，经过一番折腾后总算是能顺畅使用了，把结果分享在这里，也做个记录。
利用Nginx auth模块快速搭建OAuth2.0 SSO单点登录系统
假设我们起了一个服务器在 1234 端口，但是我暴露在公网上，但是又需要被授权的人方便的使用，一般情况下我们会在程序里简单加一个密码验证，或者直接使用 Auth_Basic 设置一个用户名与密码。Nginx Auth_Basic 扫描是恶意爬虫最喜欢干的事，而限制 Auth_Basic 重试次数又需要配置 Fail2ban 之类的日志监控程序，很麻烦。
在应用层设置密码对大多数开发人员来说并没有什么难点，但是有时候我们搭建的系统并不是自己开发的，甚至是已经编译好的庞然大物，就有些困难了。
这里分享一个10分钟快速搭建 OAuth2.0 授权登录系统的方法，本文使用 github 作为示例。
SSH设置socks5代理
由于各大运营商不同时间段出口带宽拥堵的问题，需要维护又连接不上服务器很恼火，整理一下通过代理访问SSH服务器的配置。
macOS / Linux 环境
~/.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" username@hostname
windows 环境
%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" username@hostname
Centos 升级 libstdc 库文件
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
查看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 配置文件历史 – fastcgi_params 与 fastcgi.conf
首先这是一个历史遗留问题，这篇文章没有什么技术点，只是对刚接触 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 来说都是一样的。