加入Azure AD域的计算机无法访问域外Samba

0

加入域后的Windows系统 访问外部资源会携带已登录的域用户凭证,未加入域的Samba就无法访问(Samba目前也不支持Azure AD),会提示未知错误

解决办法 打开控制面板 凭据管理器 添加Windows凭据

输入Samba文件服务器地址
用户名输入Samba的用户信息
如果是匿名访问 需要输入 计算机名\guest 密码留空

Windows远程桌面连接常见问题

0

1. 使用已加入 Azure Active Directory 域的设备连接 Microsoft 账户登录的设备需要添加 MicrosoftAccount\ 前缀。
2. 使用未加入域的设备连接已加入 Azure Active Directory 的设备需要取消勾选【仅允许运行使用网络级别身份验证的远程桌面的计算机连接(建议)】,并编辑rdp文件添加行



3. 使用高分屏连接远程桌面时会因分辨率过高而变得非常卡顿,解决方案是使用第三方修改的客户端,画面会稍微模糊。

获取拼多多店铺ID

1

获取拼多多店铺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

1

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

0

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单点登录系统

0

假设我们起了一个服务器在 1234 端口,但是我暴露在公网上,但是又需要被授权的人方便的使用,一般情况下我们会在程序里简单加一个密码验证,或者直接使用 Auth_Basic 设置一个用户名与密码。Nginx Auth_Basic 扫描是恶意爬虫最喜欢干的事,而限制 Auth_Basic 重试次数又需要配置 Fail2ban 之类的日志监控程序,很麻烦。

在应用层设置密码对大多数开发人员来说并没有什么难点,但是有时候我们搭建的系统并不是自己开发的,甚至是已经编译好的庞然大物,就有些困难了。

这里分享一个10分钟快速搭建 OAuth2.0 授权登录系统的方法,本文使用 github 作为示例。

SSH设置socks5代理

0

由于各大运营商不同时间段出口带宽拥堵的问题,需要维护又连接不上服务器很恼火,整理一下通过代理访问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" [email protected]

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" [email protected]

Centos 升级 libstdc 库文件

0
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

0

首先这是一个历史遗留问题,这篇文章没有什么技术点,只是对刚接触 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 来说都是一样的。