Raid卡的自动化管理

Raid卡的自动化管理

实现自动化安装系统并不难

难在如何实现按客户选的Raid级别
去自动实现Raid的Rebuild

终于明白逻辑了 还是传参

第一步
Raid卡是不是存在 存在=允许客户选择Raid级别
第二步
客户选择Raid级别, 计算是不是满足需求,满足就放行,否则返回False
例如, 客户选Raid5, 但是设备只有2块硬盘,只能建Raid0或Raid1
第三步
客户选择了Raid
系统开机,PXE启动维护盘,下载对应的Raid规则和脚本预定义
建立物理卷和逻辑卷,分区
完成后重新启动

第四步
继续PXE启动,进行网络安装系统!

PHP 最简单的API 请求频率限制 方式

例如 限制 API 每秒仅允许请求一次

原来的API这样

加限制以后 这样

以时间作为判断依据
这个适合小应用使用 其他规模的还是使用 

真讽刺,电信运营商的互联网套餐

真讽刺,电信运营商的互联网套餐
为了抢地盘,不闻不问的推各种低价互联网套餐

以前是老用户与狗不得办理
后来用户投诉的多,工信部约谈了,不得已让老用户也能改互联网套餐

当然 不能让老用户那么容易就改了

于是乎 各种扯淡限制来了
对外宣称 营业厅/10000号可以改
实际情况 10000 只能提供咨询,
“营业厅” = 指定营业厅,偌大一个城市,只能去有限的几个偏远营业厅改
是的 大家都闲的很 从城市一头到城市另一头就为改个套餐
还要求本人带本人身份证办理

大家都知道什么套路

10000号推销各种增值服务的时候, 你这边说好,话务员那边立马就能给你搞好,很快短信就通知你钱扣好了
你要是从59换199的套餐, 话务员直接权限就能给你办好

你想改个互联网套餐,必须去营业厅,还是指定的营业厅….

讽刺吧?

nginx Cache loader process exited 问题 产生的原因和解决办法

nginx Cache loader process exited 问题 产生的原因和解决办法
nginx Cache loader process exited

这个一般出现在缓存大量碎片文件的情况下
例如 大量图片文件的缓存 大量小文件的缓存

这个错误是由于缓存配置不当引起的
主要的不当在于配置的缓存目录深度太浅
导致单一缓存目录下文件过多,导致寻道错误
或者nginx缓存控制器查询文件超时
如果在加上系统句柄数有限制 100%间歇性出现

建议解决办法
1. 使用SSD硬盘
2. 使用XFS,EXT4文件系统,建议XFS, 不要使用EXT3,单一目录有最大文件限制,超过无法写入文件
3. 优化NGINX的缓存目录深度
4. 增加服务器,按目录平滑分离

PowerShell因为在此系统中禁止执行脚本解决方法

在Powershell直接脚本时会出现:

无法加载文件 ******.ps1,因为在此系统中禁止执行脚本。有关详细信息,请参阅 “get-help about_signing”。
所在位置 行:1 字符: 17
+ E:\Test\test.ps1 < <<< + CategoryInfo : NotSpecified: (:) [], PSSecurityException + FullyQualifiedErrorId : RuntimeException 查看“get-help about_signing”: 主题 继续阅读“PowerShell因为在此系统中禁止执行脚本解决方法”

Linode KVM升级以后发现些问题

Linode KVM升级以后发现些问题
感觉分配的CPU性能 比以前要差些

主要表现在编译 GCC编译的时候
以前如丝般顺滑, 现在偶尔会在一些特殊的地方 出现卡顿

这个也可能和区域有关系
使用率低的区域 性能可能好些

不过还是

总体来说
日本区域性能最差
达拉斯性能最好

其实CPU都是一样的

一套聚合支付的安全逻辑

一套聚合支付的安全逻辑
这个是临时的一个想法 备用的

基于Redis 记录用户特征码 包括不限于IP
然后将这些信息进行加密 产生唯一特征记录
在将特征码+生成的支付链接 进行绑定存储Redis 设置有效期N分钟 + 唯一性

如果用户在N分钟内未支付 或者 打开多个支付链接
代表用户可能不是正常用户 打开第二个支付方式的时候 进行阻断
返回403 用户行为异常

拿session来说 差不多就是保证用户支付渠道的唯一性
过滤非正常的用户

谷歌浏览器 将彻底取消CA机构 沃通(WoSign)的信任

Final removal of trust in WoSign and StartCom Certificates

Hello net-dev,

As previously announced, Chrome has been in the process of removing trust from certificates issued by the CA WoSign and its subsidiary StartCom, as a result of several incidents not in keeping with the high standards expected of CAs.

 

We started the phase out in Chrome 56 by only trusting certificates issued prior to October 21st 2016, and subsequently restricted trust to a set of whitelisted hostnames based on the Alexa Top 1M. We have been reducing the size of the whitelist over the course of several Chrome releases.

 

Beginning with Chrome 61, the whitelist will be removed, resulting in full distrust of the existing WoSign and StartCom root certificates and all certificates they have issued.

 

Based on the Chromium Development Calendar, this change should be visible in the Chrome Dev channel in the coming weeks, the Chrome Beta channel around late July 2017, and will be released to Stable around mid September 2017.

 

Sites still using StartCom or WoSign-issued certificates should consider replacing these certificates as a matter of urgency to minimize disruption for Chrome users.

Cheers,
Devon O’Brien