vCSA 7.0 更改root密码以及SSO 密码

vCSA 7.0 默认会要求每隔90天更改root密码以及SSO密码.

很不幸的是我忘记修改了,于是乎今天我就被锁在外面了.

我们需要先更改root的密码,然后在用root去修改SSO的密码. SSO账户我们这里默认为是: [email protected]

  1. 更改root密码

这个还算比较简单的,首先先去你安装vCSA 的ESXi 的后台,一般是某个IP地址,https://xx.xx.xx.xx

然后找到vCSA所在的虚拟机,双击图像打开web console,按F2选择customize system,在debug mode 里面选择打开SSH,这样就你就可以用root以及旧密码登录SSH. 

因为你的root密码已经过期了,所以在登录完以后会强制你修改root密码,按照提示修改root密码就可以了.  然后你就会发现你现在已经可以登录vCSA VAMI界面了.

这个界面通常在 https://vcsa_ip:5480

2) 更改SSO密码

紧接着上面的SSH Console 使用,首先我们需要输入”shell”给root账户授权bash权限,然后我们使用的其实是一个bash 工具/usr/lib/vmware-vmdir/bin/vdcadmintool,

直接在console中输入上面的路径以后回车,就会看到一个命令列表,我们选择3 “Reset account password”,然后输入你想要重置密码的SSO 用户名,按照上面所说

我们输入[email protected] 后回车,就会看到系统自动生成了一个新的十分复杂的密码. 复制下来,我们就可以登录vCSA管理界面了.

最后别忘了关闭SSH权限.

写的比较简单,图文参考可以参见下面的文章:

重置root密码

http://vcloud-lab.com/entries/vcenter-server/vmware-vcenter-server-management-exception-in-invoking-authentication-handler-user-password-expired

重置SSO账户密码

http://vcloud-lab.com/entries/vcenter-server/how-to-reset-vcenter-server-sso-administrator-vsphere-local-password
https://vtraintech.com/reset-vcenter-sso-password/

Cloudflare 是如何处理HTTP Request Headers的(How Does Cloudflare handle HTTP Request headers)?

我们都知道,cloudflare其实本质上就是一个反向代理(reverse proxy), 因此cloudflare 会把收到的所有的HTTP headers request原原本本的转发给你的源服务器,在此基础上还会添加一些CF自己的header.

这些header 都有一个共同的特性,就是以CF开头

CF-Connecting-IP: 

Provides the client (visitor) IP address (connecting to Cloudflare) to the origin web server. 
This header will only be sent on the traffic from Cloudflare's edge to your origin webserver.

True-Client-IP (Enterprise plan only):

企业用户专享

X-Forwarded-For:

Maintains proxy server and original visitor IP addresses. If there was no existing X-Forwarded-For header in the request sent to Cloudflare, 
X-Forwarded-For has an identical value to the CF-Connecting-IP header

CF-RAY:

The cf-ray header is a hashed value encoding information about the data center and the visitor’s request

CF-IPCountry:

Contains a two character country code of the originating visitor’s country. XX is used for unknown country information

CF-Vistor:

Currently, this header is a JSON object, containing only one key called “scheme”. The meaning is identical to that of X-Forwarded-Proto above - e.g. it will be either HTTP or HTTPS, 
and it is only really relevant if you need to enable Flexible SSL in your Cloudflare settings.

CDN-Loop:

Allows Cloudflare to specify how many times a request can enter Cloudflare's network before it is blocked as a looping request.

CF-Worker:

The CF-Worker request header is added to an edge Worker subrequest that identifies the host that spawned the subrequest. 
This is useful when you want to protect against cross-zone worker subrequests.
You can add CF-Worker header on server logs similar to the way you add the CF-RAY header. Just add "$http_cf_worker" in the log format file: log_format cf_custom "CF-Worker:$http_cf_worker"'

用phpinfo()函数测试了一下,发现多了以下几个fields:

$_SERVER['HTTP_CDN_LOOP']: cloudflare
$_SERVER['HTTP_CF_CONNECTING_IP']: 99.99.99.99
$_SERVER['HTTP_CF_VISITOR']: {"scheme":"https"}
$_SERVER['HTTP_CF_RAY']: 6a4247906e83762b-EWR
$_SERVER['HTTP_X_FORWARDED_FOR']: 99.99.99.99
$_SERVER['HTTP_CF_IPCOUNTRY']: US

同时,REMOTE_ADDR这个ip是CF的节点IP

$_SERVER['REMOTE_ADDR']: 174.245.52.215 (CF新泽西IP)

 

Nginx 使用多个map条件语句(conditionally block)

在Nginx 的location中,if is evil.

因此多个if条件语句可以转化为多个map条件语句.

一般有两种方式,一个是map中直接map 两个变量,变量之间用:间隔;另外一个就是使用多个map,后一个map里面直接使用前面一个map里的变量,形成map chain. 下面详细说明:

第一种方式:

map "$http_x_target:$arg_target" $destination {
default upstream0;
~something upstream1;
~something2 upstream1;
~something3 upstream2;
}
...
server {
location / {
proxy_pass https://$destination;
}
}

第二种方式:

map $arg_target $arg_destination {
default upstream0;
something upstream1;
something2 upstream1;
something3 upstream2;
}
map $http_x_target $destination {
default $arg_destination;
something upstream1;
something2 upstream1;
something3 upstream2;
}
...
server {
location / {
proxy_pass https://$destination;
}
}

参考文档:

https://stackoverflow.com/questions/59671623/conditionally-map-values-in-nginx-config
https://gock.net/blog/2020/nginx-conditional-logging-responses/

Nginx 禁止某些UA(User Agent)访问

一般来说,我们直接用nginx 的if 语句配合正则表达式就可以了,比如说

# case sensitive matching
if ($http_user_agent ~ (Antivirx|Arian)) {
return 403;
}

# case insensitive matching
if ($http_user_agent ~* (netcrawl|npbot|malicious)) {
return 403;
}

但是当我们需要禁止的user agent lists过长时,用if语句配合正则表达式就不是那么方便,而且性能上也会有影响,因此Nginx官方

多推荐使用map 来代替 if 语句

map $http_user_agent $badagent {
default 0;
~*malicious 1;
~*backdoor 1;
~*netcrawler 1;
~Antivirx 1;
~Arian 1;
~webbandit 1;
}

 if ($badagent) {
return 403;
}

Curl 常用commands

经常利用curl 来测试网站的一些301/302转向,检查代码什么的.

下面是常用的命令, 这里保存一下,经常用的上. 

curl -o vue-v2.6.10.js https://cdn.jsdelivr.net/npm/vue/dist/vue.js 
#vue.js 保存为vue-v2.6.10.js
curl -O https://cdn.jsdelivr.net/npm/vue/dist/vue.js  
# -O 直接保存为原文件名
curl -I  https://www.ubuntu.com/  
# 获得HTTP HEADER
curl -I --http2 https://www.ubuntu.com 
# --https2 检查是否支持http2协议
curl -L google 
# -L 命令curl 跟随跳转到final destination
curl -A "googlebot" https://www.ubuntu.com 
# -A 自定义UA
curl -x 192.168.66.1:8888 http://linux 
# -x 或者 --proxy 设定proxy
curl -H "X-Header: value" https://www.keycdn.com 
# -H 自定义header
curl -H "X-Header: value" https://www.keycdn.com -v 
# -v 表示 verbose
curl -h # -h 表示manual
curl --request GET/POST https://www.keycdn.com  
# curl 默认是GET, --request 可以自定为GET或者POST

Nginx 关闭Google weblight 访问

Google weblight 说的很好听,可以让较慢网速的人访问你的网站,但是也有他自身的不足: 严重影响你的广告收入.

因此很多人都会想法去关闭Google weblight的访问.

Google weblight的网站给出方案,就是在header里面添加Cache-Control: no-transform. Google 看到这个header,就会展示原网页.

一个小知识, 按照RFC 7230, 3.2.2. Field Order里面所说,你可以在header里面添加多个Cache-Control,只要他们的field-value pair是不一样的,多个Cache-Control就是有效的.

比如说:

Cache-Control: no-cache, no-store, private
Cache-Control: no-cache

这是有效的,会被浏览器认为是:

Cache-Control: no-cache, no-store, private, no-cache

这个明白了以后, 在nginx中关闭Google Weblight 访问就很简单了. Google weblight使用的UA为

Mozilla/5.0 (Linux; Android 4.2.1; en-us; Nexus 5 Build/JOP40D) AppleWebKit/535.19 (KHTML, like Gecko; googleweblight) Chrome/38.0.1025.166 Mobile Safari/535.19

关键字符”googleweblight”, 因此我们只需要对含有googleweblight字符的UA的访问,添加header “Cache-Control: no-transform”就好了

下面上配置代码:

在Nginx http block 里面添加map 命令:

map $http_user_agent $cache_no_transform { 
"~*googleweblight" "no-transform"; 
}

然后在server block 或者 location block 里面添加:

add_header Cache-Control $cache_no_transform;

就可以了. 

一个小知识, Nginx 的add_header命令,如果value为空的话,默认是会忽略的. 因此

add_header Cache-Control '';

其实是会被nginx忽略的.

 

ESXi 6.7升级到7.0

这个属于ESXi的大版本升级,所以一般用两种方式: Cli 直接升级或者用vCSA Life Cycle Manager 用创建baseline 的方式升级

用cli的方式升级前面的文章已经写过了,因此这篇文章主要用来说以下用vCSA 的Life Cycle Manager 的方式升级

大概步骤也很简单,主要就是import ISO创建baseline, 然后相应的ESXi Host 选择baseline进行升级.

可以借鉴下面的两篇文章:

https://virtualg.uk/upgrade-esxi-6-7-to-7-0-lifecycle-manager-vlm/ 
https://www.nakivo.com/blog/how-to-upgrade-from-vmware-vsphere-esxi-6-7-to-7-0/

 

三星S20+ 安装Play Store

今天下午手贱,点了手机系统更新,结果更新完以后Play Store没有了,国区的固件确实有这个毛病.

三星的手机框架齐全,只需要自己去apkpure 或者apkmirror上下载一个最新的play store apk 就可以了. 

但是版本问题又让我迷糊了半天.

我下载的是这个版本:

Google Play Store 26.9.22-21 [0] [PR] 394273994 (82692210)
Update on: 2021-09-03

App uploaded by: Google LLC

Requires Android: Android 5.0+ (Lollipop, API 21)

Signature: 38918a453d07199354f8b19af05ec6562ced5788 Google Play Store 26.9.22-21 [0] [PR] 394273994(82692210) safe verified

Screen DPI: nodpi

Architecture: arm64-v8a, armeabi-v7a, x86, x86_64

File SHA1: f78f5d812a9ed0aa68fcb869020c930f79d9247b

File Size: 44.8 MB

[0] 表示对所有的硬件(相对应的, [5]表示可穿戴andorid设备, [8]代表andorid TV)

26.9.22 代表play store 的版本, 没什么好说的,22这一列迭代的很快

[21]  表示的是只支持API21以上(相对应的,还有[19], 表示API19),现在的机器直接选择[21]就可以了

Nginx 中获取cloudflare保护的网站的访问者的真正IP

一般来说,有三个参数可以使用:

  1. CF-Connecting-IP, 在nginx log中为 cf-connecting-ip.
  2. True-Client-IP, 仅给Cloudflare 企业用户使用,在nginx log中为true-client-ip
  3. X-Forwarded-For, 在nginx log 中比较常见,为x-forwarded-for. X-Forwarded-For 其实是一个数组,按顺序记录了用户的真正的IP和用户使用的Proxy.

举例说明:

X-Forwarded-For: 203.0.113.1 

这个表示用户的真实IP是203.0.113.1

X-Forwarded-For: 198.51.100.101,198.51.100.102,203.0.113.1

这个表示用户的真实IP是203.0.113.1,然后依次经过了198.51.100.102和198.51.100.101代理,然后才访问到了CF的edge 节点

综上所述, CF 推荐使用CF-COnnecting-IP 和 True-Client-IP 两种header,因为他们能够保证他们的value只有一个IP