月度归档： 2017 年 2 月

.user.ini无法编辑的可能原因

今天给我的WP安装了Wordfence插件（人气安全插件），因为读书笔记用的Ngnix，所以并没有php.ini，只有.user.ini。好死不死插件要求更改此文件。

然后因为连我都无法编辑此文件，导致插件死活都开启不了防火墙。

然后我尝试了后台／在线编辑IDE／SSH，均无法更改权限到可编辑。

然后去了宝塔的后台安全管理溜达一圈，也没看到有关于这个文件的设定。

最后灵机一动，莫非。。。chattr。

果然，执行chattr -i .user.ini之后，权限就可以编辑了。插件功能顺利开启。

之后将权限重新设定成644，chattr +i .user.ini，打完收工。

那么chattr命令与.user.ini都是做什么的呢？之后补充。

Salesforce中避免重复执行Trigger的思路

题外话，换了效力的公司之后，对自己的冲击还是挺大的。所以一直没有精力继续写。不过，还是一鼓作气吧。

第一种思路：在trigger中声明一个Static变量，默认为false，如果执行了业务代码，在最后将此变量值执为True，然后在一个事务中，下次再进来的时候，由于此变量为true，跳过。

但是由于static的机制并不是很稳定，有可能造成意想不到的问题。而且，在早些年版本的时候，一个批次200条数据，salesforce会分两次执行。这样后100条就会被无情的跳过。

第二种思路：在目标object上新建一个隐藏的布尔字段，默认为false，第一次执行的时候将此字段的值更新成true，然后在事务结束的时候使用future方法重新更新为false。

超大量导入数据的时候应该会死。。。

第三种思路：新建一个static class，class里面包含一个set，然后每次事务开始时将自己放入此set，事务结束时remove掉。

仍然有static诡异行为或者直接失效的风险。

所以，在表设计和业务结构设计的时候还是要尽量发生重复触发的情景。让Trigger只关注与自己要做的事情就好。

之后会给出每种思路的验证结果。

// Update 1 by 2017/03/04

应群众要求，解释一下思路一。
思路一的核心就在于static修饰符。官方文档。
熟悉高级编程语言的同学一定对static不陌生，比如在java中static经常与public final static连用。
Salesforce同样提供了static概念，不过于java中的static有些不同。
1. static的生存范围仅限一个transaction。所以幻想着初始化一次到处使用的，洗洗睡吧。
2. 虽然不能做到亘古不变，但是在一个transaction内穿梭于多个instance之间还是可以的。
同样，可以在class中的static代码块中进行复杂的初始化，也是能避免重复执行。

所以作为思路一的解决方案。就如同官方文档提供的例子一样。
首先找一个class声明一个flag。

public class P { 
   public static boolean firstRun = true; 
}

然后在业务代码里使用它。

trigger T1 on Account (before delete, after delete, after undelete) { 
       if(Trigger.isBefore){
          if(Trigger.isDelete){
             if(p.firstRun){
                 Trigger.old[0].addError('Before Account Delete Error');
                  p.firstRun=false;
              } 
           }
        }
}

搬瓦工启用chacha20加密算法的方法

搬瓦工的一键SS默认的加密算法是AES-256，这个算法在当时算是兼具了安全和性能的不二选择。

可是随着时代的发展，AES-256的性能已经不能满足广大人民群众的需求。所以新一代的算法冉冉升起————–chacha20

chacha20虽然名字很奇怪，但确是Google出品。来自RFC与Wikipedia的介绍。

ChaCha20

Google选择了带有Bernstein的Poly1305消息认证码的ChaCha20作为一个OpenSSL中RC4的替代品，用以完成互联网的安全通信。[17]Google最初实现了https (TLS/SSL)流量在Chrome浏览器（Android手机版）与Google网站之间的通信。[18]
不久之后，Google在TLS中采用它，ChaCha20和Poly1305算法也以 [email protected] 成为OpenSSH中的一个新密码包。[19][20]后来，通过编译时选项避免它依赖于OpenSSL也成为可能。[21]
ChaCha20也被用在OpenBSD[22]和NetBSD[23]操作系统中的arc4random随机数生成器，替换已经脆弱的RC4，在DragonFly BSD[24]中内核的CSPRNG子程序中也是如此。[25][26]
ChaCha20已经在RFC 7539中标准化。它在IKE和IPsec中的使用已在RFC 7634中标准化。在 RFC7905中，Chacha20-Poly1305 已经被加入 TLS 扩展标准（[1]）。

chacha20的优势在于移动设备的性能。所以我们开始动手改造吧。

按照以下步骤：

首先SSH连接自己的搬瓦工服务器。
标准起手动作，yum update。
然后执行下面命令。

yum install m2crypto gcc -y
wget https://github.com/jedisct1/libsodium/releases/download/1.0.8/libsodium-1.0.8.tar.gz 
tar zfvx libsodium-1.0.8.tar.gz
cd libsodium-1.0.8
./configure
make && make install
echo "include ld.so.conf.d/*.conf" > /etc/ld.so.conf
echo "/lib" >> /etc/ld.so.conf
echo "/usr/lib64" >> /etc/ld.so.conf
echo "/usr/local/lib" >> /etc/ld.so.conf
ldconfig

因为我还没找到搬瓦工自带SS的配置文件位置。所以只能用临时的办法。

ps -ef | grep ssserver
// 获得 sssever PID
kill [PID]
/usr/bin/ssserver -p [your port] -k [your password] -m chacha20 --user nobody

之后在客户端也选择chacha20就OK了。

操作完之后，虽然搬瓦工自带的SS管理页面看起来是STOP状态，但实际上服务器已经重新启动了。
等找到配置文件的位置之后，再更新比较完善的方法。

// Update 1 2017-02-08

关于如何做到开机自动启动与自定义参数的问题，已经找到了方案。
首先，在/etc目录下创建配置文件shadowsocks.json(vi /etc/shadowsocks.json或者ftp等你喜爱的方式)
然后输入下列内容

{
"server":"[Server IP]",
"local_address":"127.0.0.1",
"local_port":1080,
"port_password":{
"[Port]":"[Password]"
},
"timeout":300,
"method":"chacha20",
"fast_open":false
}

然后，打开/etc/rc.local，将原来的ssserver启动命令删掉，然后写入

ssserver-c /etc/shadowsocks.json -d start

之后重启，连接成功就OK了。
以后想改密码或者端口的话，直接改/etc/shadowsocks.json中的设置，重启就好。

// Update 2 2017-06-18
今天发现所有使用chacha20加密的流量被服务器疯狂的拒绝。然后监视服务器侧并没有收到任何请求，推测已被拦截。
为了追求速度快就会留下马脚。所以请暂且使用AES-256吧

// Update 2 2017-09-08
更新了tar包的url地址