挂载 NFS 或者 Samba 的时候，经常会由于网络故障导致挂载好的链接断掉。 此时如果尝试进行 ls、cd、df 等各种命令，只要与此目录沾上边，就会卡住。 如果使用了类似 oh-my-zsh 这种配置的，只要在网络目录中，弹出命令提示符前就会直接卡住。
这个时候第一反应就是 umount 掉出问题的目录，但是如果直接执行，umount 本身也会卡住。
这时我们需要加上参数 -l，进行 lazy umount，即先把网络文件系统从 file system hierarchy 上 detach 掉，至于各种 reference busy 的问题押后处理。
Laravel 是当今最流行的 PHP 框架之一，如所有 PHP 项目一样，通常情况下它都需要运行在 LAMP 或 LNMP 环境之下。如何配置 LNMP 使之为 Laravel 工作可以说是每一个 Laravist 的必修技能。
本文将就 LNMP 环境下如何为 Laravel 的配置 Nginx 进行一次比较详细的探究，通过本文你可以更清晰的认识这份你每天都在使用的配置，理解其中的原理，知晓某些配置的好与不好。在文章的后半段，还会为你推荐一种更为安全，更加适合 Laravel 的配置方案。
为了能够对一台通过 PPTP 连上了的机器做端口映射，无疑是希望 PPTP 连上来后分配的 IP 是固定的。 而在之前的配置中，我们的 client IP 配置是全局的，不论通过哪个账号连上来，都是一起分配的 IP。
于是再查了一下现在的官方文档， 可以看到 remoteip 选项是可以为每个用户名密码单独配置的。 但是配置后发现还是无效的，在仔细看文档可以发现：
1
There are bugs in BARRIER BREAKER (14.07, r42625) init script. Modify /etc/init.d/pptpd to clean up temporary pptp.conf and chap-secrets. Original init script does not enable multiple simultaneous clients with fixed remote IP's. Following script and modified configuration file enables it:
对 MySQL 死锁不是特别擅长，业务中遭遇了，就尝试分析一下了。
首先有篇不错的关于 MySQL 加锁机制的文章以及一个很有意思的 INSERT 死锁例子，Mark 一下。
业务需求，写出了类似这样的 SQL：
1
2
INSERT INTO site(third_party_id, data) VALUES(%s, %s)
ON DUPLICATE KEY UPDATE data = %s
其中 site 表主键 id 自增，唯一索引 third_party_id。
SQL 目的很简单，就是从一张三方表中导数据到自己业务的一张表中间。 就这样简单的一句 SQL，没有复杂的事务，只是会出现大量的并发。
这些日子由于实验室的原因，看了几个 apk 病毒的 native so，摸索了半天终究还算有点收获。
刚看这些 so 的时候，拖进 IDA 各种报错也就算了，readelf、010 都报错，section 信息各种不正常，根本就是连个程序入口点都找不到。程序载完 so 直接结束的也有，根本没有 dump 的机会，反调也是一应俱全，只要上调试器，肯定挂不解释。
不过想来，既然程序能正常运行，那么它破坏的一定是那些不会影响运行的字段，关键的运行相关的信息，该是怎么样，还必须得是什么样。于是在网上搜集了下资料，开着 010 对比着看了下，精炼起来大概就下面几点：
也不知道是不是天气热了，这两天异常焦躁，于是找点乐子，便跑去看了看 pwnable.kr，然后，然后就卡住了（我可怜的脑细胞……
这次卡的题是 ascii，然后发现有个简化版 ascii_easy，然后看完还是发现不会，看到提示说 ulimit，当时就懵了，这又是神马黑科技，ulimit 不是用来限制资源的么，跟这题有什么关系……
在网上查了一圈后发现，通过 ulimit -s unlimited 可以禁用 ASLR，实测一下后发现，so 地址确实固定了，不过栈地址并不固定。然后看了下原理，大概就是 ulimit -s 将栈地址设成无限制后，系统会采取一种与平常不同的方式计算库基地址，而在 32 位模式下采取此方式时没有加入随机量，于是地址便固定了。最后，竟然还发现了一个最近的 CVE 讲这个问题的，感觉也是醉了
。
so 地址固定后，ascii_easy 其实就很简单了，随便在 libc 里找找函数和字符串用一用就好，注意下 ascii 字符的要求就好。至于 ascii 的话，由于静态了，需要借助 vdso 来跳一下 shellcode 了。
前段时间，看别个写的 view 的时候，看到个二维表格的实现，感觉甚是不错，效果比我之前那个方案感觉还要好。
还是就上次的例子来说，上次本来是说『印象中SQL里似乎没有什么函数可以统计某一字段为特定值的记录数』，不过这里其实我们是有办法可以实现的。
1
2
3
4
SELECT `date`, SUM(IF(`state` = 1, 1, 0)) state1, SUM(IF(`state` = 2, 1, 0)) state2
FROM `order`
GROUP BY `date`
ORDER BY `date` DESC
为了能够从公网连接 VPN 回来，最终还是把路由移到了寝室， 外网是通了，但电信毕竟上传带宽小，效果是在惨不忍睹，于是在校内的时候还是要选择内网连接。
然而我旦信息办脑子常年有洞，大张江的寝室运气不好，惨遭毒手，于是便出现这等诡异现象： 从实验室有线能连回寝室，但是，用学校无线怎么也 ping 不通寝室。 为了能够从无线连回寝室，于是便想用实验室一台台机做转发。
OpenVPN 转发的时候，直接一行 socat 转 UDP 就轻松搞定，然而想转 PPTP 的时候却蛋疼了。
PPTP 的 1723 端口转发下 TCP 也很容易，但是 47 端口（47 是协议号，之前看错了，如有误导，非常抱歉，感谢评论指出） 还有个 GRE 协议再使用，于是也得转，
鉴于 socat 实在玩不转，也不知道能不能实现这个转发，于是最终还是回到 iptables 转发。
iptables 一直没能搞太清楚，于是趁着这次机会，又好好学习了一遍万能的 iptables， 这次在网上找到一篇觉得讲的很清楚的文章，为了防止找不到了，转载了一份。
iptables是一个Linux下优秀的nat+防火墙工具，我使用该工具以较低配置的传统pc配置了一个灵活强劲的防火墙+nat系统,小有心得，看了网上也有很多这方面的文章，但是似乎要么说的比较少，要么就是比较偏，内容不全，容易误导，我研究了一段时间的iptables同时也用了很久，有点滴经验，写来供大家参考，同时也备日后自己翻阅。
首先要说明的是，iptables操作的是2.4以上内核的netfilter。所以需要linux的内核在2.4以上。其功能与安全性远远比其前辈ipfwadm,ipchains强大，iptables大致是工作在OSI七层的二、三、四层，其前辈ipchains不能单独实现对tcp/udp port以及对mac地址的的定义与操作，所以我想ipchains应该是仅仅工作在三层上的。
我们先简单介绍一下netfilter的大致工作流程，也就是一个数据包（或者叫分组、packet,我个人习惯叫包）在到达linux的网络接口的时候 （网卡）如何处理这个包，然后再介绍一下如何用iptables改变或者说控制对这个数据包进行操作。
最近，某台服务器总是收到阿里云的提醒说磁盘空间不足， 今天，由于管理的人在外面，于是让我上去帮忙清下， 出于好奇，我决定顺便看下到底为什么磁盘成天满，结果就发现了个『奇怪』的现象……
要知道为什么，上来肯定是 du 找一下是哪个文件大咯， 结果意外的发现，根目录总共也就 6.5G，而磁盘本身有 20G， 而用 dh 一看，可以发现磁盘占用了 19G 多，两者结果差距这么大，着实是第一次见。 思前想后也没想明白是为啥，只好求助万能的 Google，结果发现原来是个很寻常的问题。
df -> disk free，是通过文件系统之间获取的空间大小信息， du -> dist usage，是通过计算所选文件夹中所有文件的大小的和得到结果的， 暂且不说 inode 信息等导致的空间占用（影响肯定不会有这次遇到的这么大），会导致两者结果出现偏差最常见的一个原因就是有些被『删除』了的幽灵文件。 当我们删除一个文件的时候，其实这个可能并不会立即被从文件系统中释放掉，因为可能会有进程还在使用这个文件的句柄， 只有当所有文件句柄都被释放了之后，相应的文件才会被真正从文件系统中释放掉。