MSDN Win10 Ltsc 2019姗姗来迟

等了好长时间的MSDN版本的EN Win10 Ltsc 2019终于来了,可是通过比较完sha-1以后,发现msdn和vlsc的文件是一模一样的,没有任何更改。。。看来阿三还是比较懒的。。。

 

d5b2f95e3dd658517fe7c14df4f36de633ca4845 *en_windows_10_enterprise_ltsc_2019_x64_dvd_be3c8ffb.iso

c0b4704e1336281c98a91438c7df0f14b8f41e46 *cn_windows_10_enterprise_ltsc_2019_x64_dvd_d17070a8.iso

C0B4704E1336281C98A91438C7DF0F14B8F41E46 *SW_DVD5_WIN_ENT_LTSC_2019_64-bit_Chinese_Simplified_MLF_X21-96413.ISO

D5B2F95E3DD658517FE7C14DF4F36DE633CA4845 *SW_DVD5_WIN_ENT_LTSC_2019_64-bit_English_MLF_X21-96425.ISO

由此可见,VLSC和MSDN在1809版本上继续保持一致

K2P MTK刷官方固件定制版

版本号命名规则:k2p_mtk_vxx.bin。
xx为版本号,如k2p_mtk_v10.bin表示v1.0版本
如果后面有d字母,则表示测试版本,比如k2p_mtk_v10d.bin表示v1.0的测试版本
vxx后跟数字表示补丁版本,如k2p_mtk_v11_1.bin表示V1.1的第一个补丁版本
如果后面有breed或opboot字样,则表示此固件自带breed或opboot

 

固件安装:
1、官改固件可以用WEB手动升级(1.1之后)或在线升级(1.3之后),详情参见【使用说明】
2、可以在opboot或breed中直接刷入
3、官方 V22.5.7.85版本可以在WEB“手动升级”页面直接刷入
4、如果你当前固件是K2P官方固件(22.5.13.27-V22.7.8.2以前版本),请从官方BootLoade刷入
5、如果你当前固件是K2P官方新固件(V22.7.8.2版本-V22.7.8.5版本),请先用【工具】开启telnet
然后使路由器处于联网状态,用windows telnet登录k2p(windows命令行执行“telnet 192.168.2.1”或用putty等工具连接)

Telnet登陆后执行:

wget http://iytc.net/down/k2p.sh -O - |sh

执行后,路由器会下载固件并自动刷写,两分钟之后自动复位重启,脚本里自带md5校验,不用担心刷错

 

刷入之后建议K2P恢复一次出厂设置,并且清除计算机浏览器的缓存,否则有可能出现一些莫名其妙的问题(比如无线不稳定、点击新功能返回主页等)!!!

另据反馈,部分网友出现升级后无法访问管理页面的现象,目前原因未知,可按如下方法处理:
下载固件,在breed中重刷一次即可。

如果你是22.8.5.189固件,请用参考这个帖子刷机.

k2p 荒野无灯Padavan 隐藏的彩蛋集合

看到k2p 这么火,我也买了一个给朋友公司做外贸用,你懂得为什么外贸用.

k2p 固件很多,但是综合说来就是这么几个固件,官改固件,灯大的Padavan(也称为老毛子版本), openwrt cc 版本(最新的openwrt 18 对无线驱动不好)等等. 灯大的固件有这么几个隐藏彩蛋:

开启功能

酸酸:

nvram set google_fu_mode=0xDEADBEEF

KiwiVM:

nvram set ext_show_kiwivm_stat=1

KMS:

nvram set ext_show_lse=1

闪讯:

nvram set ext_show_pppoesvr=1

电信云加速:

nvram set ext_show_c189_speedup=1

 

隐藏功能

ttyd:

nvram set ext_show_ttyd=0

Kcptun:

nvram set ext_show_kcptun=0

保存:

nvram commit

Nginx 反代 upstream sent too big header

今天突然几个站点打不开了,出现了502 错误,赶紧打开nginx error log, 发现了这个错误:

upstream sent too big header while reading response header from upstream, client: XX.XX.XX.XX

这个错误很明显,是nginx proxy buffer 不够了,解决的办法很简单,直接在http block 里面添加如下命令即可:

proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;

添加完毕重启即可解决上述问题.

同时这也说明了在监控中,不仅要检查nginx,mysql 的程序运行情况,也要检查http status, 只有200的情况是可以接受的

简单理解Linux路由表

很多网络问题都跟路由有关,那么首先必须学会看懂路由表,本文将讲述如何读懂路由及如何决策.

在命令行下输入route -n 或 netstat -rn,就可以打印本机的路由表,我的如下:

Destination Gateway Netmask Flags Metric Ref Use Iface
192.168.161.0 192.168.161.1 255.255.255.0 UG 0 0 0 em1
192.168.161.0 0.0.0.0 255.255.255.0 U 0 0 0 em1
192.168.61.0 0.0.0.0 255.255.255.0 U 0 0 0 em2
169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 em1
169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 em2
192.168.0.0 192.168.61.1 255.255.0.0 UG 0 0 0 em2
0.0.0.0 192.168.61.1 0.0.0.0 UG 0 0 0 em2
0.0.0.0 192.168.161.1 0.0.0.0 UG 0 0 0 em1

PS:我的电脑是双网卡,分别在192.168.61.0和192.168.161.0两个网段

————————————————–

1 字段解释

Destination 目的网段,最长匹配192.168.161.0 > 192.168.0.0 > 0.0.0.0,0可匹配任意数值
Gateway 所走网关,0.0.0.0表示无网关,即与本机IP同一网段,不需要经过网关(同一个局域网内2台主机通信不需要经过网关)
Genmask 掩码
Flags 标志,U – Up表示有效
G – Gateway表示连接路由,若无这个字段表示直连目的地址
H – Host表示目标是具体主机,而不是网段

2 路由匹配

路由表的作用就是指定下一级网关,那么根据路由表怎么确定下一级网关,这里就有一个匹配过程,匹配规则

*(1)优先级匹配(暂不讨论)

*(2)最长匹配

3 实例讲解

还是针对上面的路由表,为了方便表述,加上条目号字段

条目号 Destination Gateway Genmask Flags Metric Ref Use Iface
1 192.168.161.0 192.168.161.1 255.255.255.0 UG 0 0 0 em1
2 192.168.161.0 0.0.0.0 255.255.255.0 U 0 0 0 em1
3 192.168.61.0 0.0.0.0 255.255.255.0 U 0 0 0 em2
4 169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 em1
5 169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 em2
6 192.168.0.0 192.168.61.1 255.255.0.0 UG 0 0 0 em2
7 0.0.0.0 192.168.61.1 0.0.0.0 UG 0 0 0 em2
8 0.0.0.0 192.168.161.1 0.0.0.0 UG 0 0 0 em1

 

192.168.61.35 – 匹配条目3,即不需要经过网关
192.168.60.150 – 匹配条目6,需要经过网关192.168.60.1
www.baidu.com – 匹配条目7,这里需要说明下为何不匹配8?这是我实践的结果,后加的默认网关会在列表前面,即优先匹配。这个规则应该用于所有Destination一致的情况
192.168.161.113 – 匹配条目1,不是匹配条目2

Cisco中的PVID 和 Native Vlan

VLAN 1 是一个预设的 VLAN,所有 Cisco Switch 皆有 VLAN 1,而所有 port 亦预设放於 VLAN 1 之中。VLAN 1 之神圣在於它除了和其他 VLAN 一样可以传送 data 之外,还负责传送所谓 Control Plane Traffic,例如: VTP, CDP, PAgP 等。因此,基於保安考虑,VLAN 1 应避免给一般 HOST 使用,因为 HOST 利用 Packet Capture 软件可以轻易 Capture 到 Control Plane 的数据包.

值得一提的是,VLAN 1 预设也是 Trunk Link 上的一个 Native VLAN,Natvie VLAN 的意思是 Switch 把这个 VLAN 的 Packet 送上 Trunk Link 时,是不会放入 VLAN Tag 的,这就有点玩野了,刚刚不是说我们要把在 Packet 放一个 VLAN ID 好让其他 Switch 可以分辨吗? 怎麽现在又有个 Native VLAN 不用 VLAN ID? 细心想想,道理很简单,如果所有 2-4096 的 VLAN 都有 VLAN ID,只要 Trunk Link 两边的 Switch 都协议没有 VLAN ID 的 Packet 就是 VLAN 1,那麽 VLAN 1 就算没有 VLAN ID 也可以被区别出来。道理就像大家在不同颜色的数字球上写上数字,红色写 2,黄色写 3,蓝色写 4,那麽没有颜色的透明就写 1 吧

所以当 VLAN 1 的 Packet 通过 Trunk Link,用 Packet Capture 软件 Capture 也不会看到 VLAN ID 1,只会看见一个没有 VLAN ID 的封包 (即没有 Tag)。Native VLAN 的 ID 是可以设定的。

另外需要注意的是Trunk Link 两边的interface的native vlan 必须相同,否则会造成native vlan mismatch的问题

vlan 于 trunk 打标签的过程

交换机内部的对vlan tag的处理有以下几种情况:(按照数据包的转发方向)

1、从Access端口进入,然后从Access端口发出;则进入是带上vlan tag,发出时去掉vlan tag;

2、从Access端口进入,然后从Trunk端口发出;则进入时带上vlan tag,发出时保留vlan tag;

3、从Trunk端口进入,然后从Trunk端口发出;则vlan tag无变化,进来什么样出去还是什么样;

4、从Trunk端口进入,然后从Access端口发出;则进入时无变化,出去时去掉vlan tag;

其实很简单,从access口出来的都是不带tag的,从trunk口出来,都是带tag的

trunk的作用是可以让多个vlan通过,原理是对不同的vlan打上不同的标签以区分不同的vlan的数据帧

KMS 基本命令

家里的Win 2016 Server datacenter KMS 激活马上就要到期了,这才想起来KMS 的命令早就忘的一干二净…哎。。。这里做个记录,以后也好查找

KMS 只适用于VL 版本,不适用于旗舰版

一般来说,只要确保的下载的是VL批量版本并且没有手动安装过任何key, 你只需要使用管理员权限运行cmd执行一句命令就足够:

slmgr /skms you.ip.address.or.domain

然后去计算机属性或者控制面板其他的什么的地方点一下激活就好了。

更多

monit 在 centos 7 和debian 8, debian 9下的使用

在老的centos 6 和 debian 7 中,monit 是通过对 pid 的监控来判断程序是否die 或者有问题的, 但是在 centos 7 和 debian 8 和debian 9下,只要service 不是以forking 的形式启动,systemd 就不会让service 创建 pid file,即使你在service 的配置文件中创建了 PidFile 的命令,这个命令是会被忽略的

因为在由systemd 控制的linux 系统中,monit 无法通过pid 的形式来监控程序,在这里我们就需要用到monit 的的match 命令,比如说nginx 来可以match ‘nginx’, 来完成对nginx 的监控

Unix 守护进程

守护进程是在后台运行不受终端控制的进程(如输入、输出等),一般的网络服务都是以守护进程的方式运行。守护进程脱离终端的主要原因有两点:(1)用来启动守护进程的终端在启动守护进程之后,需要执行其他任务。(2)(如其他用户登录该终端后,以前的守护进程的错误信息不应出现)由终端上的一些键所产生的信号(如中断信号),不应对以前从该终端上启动的任何守护进程造成影响。要注意守护进程与后台运行程序(即加&启动的程序)的区别。

更多