Laravel 部署问题 —— "Please provide a valid cache path"

2017-09-11     tech php laravel 1 mins 376 字

最近新建了一个 laravel 5.5项目，发现本地运行好好的，部署到服务器就发现出问题了。

在访问后台 admin 页面时提醒出错：

Please provide a valid cache path

经过一番排查，这个可以算作是 gitignore 的问额，也可以不算233333

之前在本地创建项目时，使用的是 github 默认的 laravel 的 gitignore。所以很多文件没有创建，系统缓存没办法创建，于是就出现了这样的问题。

最后的解决办法是手动创建了下面这些目录：

  • storage/framework
  • storage/logs
  • storage/framework/cache
  • storage/framework/sessions
  • storage/framework/views
  • bootstrap/cache

最后就 ok 了。

postgresql 使用不同账号新建数据库

2017-09-09     tech postgresql 1 mins 2 图 353 字

今天用 postgresql 的默认账号 postgres，想新建一个角色然后新建数据库，竟然报错：

ERROR:  must be member of role "ttfix"

好奇以前为什么没有发现这个问题——《# PostgreSQL入门》

比较简单的解决办法是在新建用户后，将新用户的权限赋予当前用户，再进行其他操作。具体如下：

GRANT "ttfix" to postgres;
CREATE DATABASE "ttfix" owner "ttfix";
GRANT ALL PRIVILEGES ON DATABASE ttfix to ttfix;
REVOKE ttfix from postgres;

参考资料

自建DNS服务器

2017-09-07     tech dns proxy 9 mins 1 图 3244 字

查阅了相关的讯息，转载其中的两篇，剩下更多的资料在文末参考资料中

  • 知乎：10万域名求自建DNS解决方案？
  • 国内开源DNS－－dnspod-sr

10万域名求自建DNS解决方案？

题主应该是在域名注册商所在的公司上班吧。

很有幸我主导过超大型第三方dns开发（CloudXNS - 免费智能DNS解析服务）, 支持海量域名，100多条解析线路，还有很多私有记录，整体系统工作得很好。

我介绍下cloudxns其中系统架构的衍化过程，应该能减少题主的弯路。

2009-2011年，我所处在的CDN公司有不少CDN客户将DNS解析直接托管给我们，和CDN的权威DNS混在一块管理（此时CDN的权威DNS也是用BIND），这样的托管数量少没有问题，数量多了 1) 影响CDN调度解析数据的下发速度，2) 也容易产生管理混乱, 3) 由于没有用户界面，客户用邮件形式通知修改，实际修改由运维同事处理，增加运维工作量。

2011-2012年，域名托管数量一直在增加，我们团队就开始着手对这类业务拆分到一个新项目cloudxns。起初，我们用BIND+DLZ+NOTIFY+AXFR来做底层支撑，DLZ是让BIND从数据库动态读取解析配置的一个模块。

BIND+DLZ会让DNS解析查询性能下降到不用DLZ的1/10甚至更多（4-5K QPS），但为了给用户提供一个WEB界面，有个数据库的底层支撑会节省很多工作量，因此我们只用BIND+DLZ做master, 仅提供SLAVE的AXFR复制查询，不对外提供实际DNS解析查询； DLZ的mysql数据和WEB系统打通，WEB系统将用户填写的数据实时写到mysql, 然后出发notify通知SLAVE自动化过来AXFR拉取新版本的DNS配置文件。

这个第一个版本的CloudXNS系统做到了： 1）客户自助解析 2）“实时生效”（域名线路少时候1分钟之内，域名线路多就不确定了） 3）SLAVE的性能没有打任何折扣（10万-20万QPS）

本来以后可以就此打住了，但是这样架构仅仅支撑了半年，我们又开始进行了新的征程。 原因： 1）既然已经有成型的产品，而且原有域名托管用户转到自助的CloudXNS上还总体比较满意。 2）恰恰中国云计算市场在此时开始高歌猛进布道之时，做为网络入口的域名解析，开始成为各大巨头要争的战略要地。 那么CloudXNS也就被顺利成章包装出去运营，接来下用户数量进一步增加，域名解析行业无法绕过的劫数，黑客军团的时不时利用DDOS攻击也开始向我们“宣战”了。BIND+DLZ+NOTIFY+AXFR方案什么时候会停摆挂掉，一直是像高悬在我们头顶一把利剑。

2012-2013年， 我经过一段时间的痛苦挣扎和不断反思，终于决定要放弃BIND, 重新实现一个海量第三方域名解析服务器。

BIND VIEWZONE模型，也就是线路域名的意思，线路多了，数据冗余很大，如何降低冗余，提高zone_transfer效率，比如很多用户整个东北地 区都是一个解析，但有少部分用户东北每个省有各自的解析，那么多大部分用户按VIEW*ZONE进行zone_transfer将有大量的重复冗余数据。

要解决的问题（这些问题限于篇幅我就不讲了解决的细节了，大家有兴趣可以登录CloudXNS - 免费智能DNS解析服务）： 1） 如何组织用于解析配置传输的数据结构模型最有效 2）如何实现界面配置后秒级生效，更重要的是如何做到和托管的数量级没有关系 3）如何实现一个兼容超精细解析（省*运营商）和普通精细解析（到运营商级别）用户需求的系统。 4）如何将DNS性能大幅提高，尽量逼近网卡限速。

技术选型： 1）内核模块,（当初的想法是：路由器那么高的性能，为什么不能把dns服务器当路由器来做？） 2）dpdk（intel刚刚推出的新技术，不是第一个吃螃蟹，也是第一批没有先后的吃螃蟹人） 综合各因素和团队成员，我们最终选型是用内核模块来实现下一版本的CloudXNS服务器。

经过整个团队（加我自己，3个C工程师+1.5PHP工程师）3个月的连续奋战，我们顺利攻克了各个 问题并成功上线，做到了当时国内的各项指标的极致。 1）生效速度（解析填写到权威解析生效），0.5秒 2）解析配置线路可伸可缩，兼容精超细解析需求和普通精细解析用户（支持线路130多个） 3）单机性能到达350万QPS（实际业务环境由于加了其他一些功能，有所下降）

2014-2015 软件上没有进行大架构调整，仅进行产品功能迭代，界面改版。开始安排专业运营人员进行运营，知名度也慢慢起来了，有大量知名互联网企业大量使用CloudXNS。

此时由于用户量增加（50亿次解析量每天），攻击的规模和频次大幅攀升， 这时DPDK技术也开始成熟起来了，CloudXNS也开始着手DPDK版本的研发，毕竟内核模块的性能还没有到达网卡限速，而DPDK更容易达到这个目标，这也是抗攻击的最大手段了（除了增加服务器之外）。

2015-2016 再后来我离开了这家公司，我原来的团队在继续努力，做的还不错（快100亿每天的解析量了）。

国内开源DNS－－dnspod-sr

早之前在DNSPOD的官方博客里就看其开源了一款号称秒杀BIND的DNS软件－－－dnspod-sr 。做为国内最大的DNS解析商，自然其在DNS块有一定的造诣，不过这么久时间过去了，关于dnspod-sr 也只是零零散散的在一些网站上看到过互相转载抄袭的文章。也去过DNSPOD-sr在git 上的项目页，里需的wiki 并不太多内容，而目前由于在了解rhel7下的unbound，所以这里顺便在测试机上玩下dnspod-sr，做一下对比。

以下先引用下其在github上介绍，dnspod-sr 是一个运行在 Linux 平台上的高性能的递归 DNS 服务器软件，具备高性能、高负载、易扩展的优势，非 BIND 等软件可以比拟。其具有以下特性：

  • 高性能，比所有流行的开源 DNS 软件性能高出2倍以上
  • 安全，能抵御一般攻击 稳定，有效降低解析失败率
  • 主动刷新缓存，响应速度更快
  • 易于扩展，非常容易部署
  • 防污染，能够正确解析被污染域名

先不看这个，我们先看下如何使用起来。 （安装配置省略了）

三、其他

其解析一个域名的原理思维图如下：

dnspod-sr

从DNSPOD官方博客来看其引入本地内存hash表缓存，可以加快本地解析速度 。其中几个支撑模块的做用分别如下：

  • net：网络的各种操作接口，完成socket的相关操作和数据收发。
  • storage：内存存储模块，为解析记录缓存和quizzer列表提供增、删、改、查功能支持。
  • memory：内存池的相关操作接口，用于内存池的创建、分配和释放。
  • io：物理读写模块，包括加载配置文件和记录日志等功能。
  • datas：红黑树的相关实现接口，用于自动刷新即将过期的记录。
  • utils：一些杂项操作接口都丢在这里了，如获取随机数据、大小写转换等操作

由于官方和wiki里找到的文档相当少，而本身对于C语言不是很了解。建议懂C语言的人可以看下源代码，代码并不多。但对于官方所宣称的性能较BIND、unbound牛X多少倍云云 。这个我们没必要去深究。从github上源代码更新的速度来看，将近一年左右没有什么代码更迭，感觉上应该又是一个阳痿的产品。

相较之前网上看到吹嘘多少还是有些失望，至少在生产环境上我不会选择dnspod-sr，考虑到官方文档的完备度、项目的发展持续性，个人的选择会是unbound — bind —- powerdns/mydns —- 最后才会考虑选择dnspod-sr 。

参考资料

代理修改 PAC 与 user-rule 文件

2017-09-06     tech proxy 1 mins 6 图 433 字

什么是PAC

代理自动配置（英语：Proxy auto-config，简称PAC）是一种网页浏览器技术，用于定义浏览器该如何自动选择适当的代理服务器来访问一个网址。

PAC的好处

PAC自动代理属于智能判断模式，它的优点有：

  1. 不影响国内网站的访问速度
  2. 节省Shadowsocks服务的流量，节省服务器资源

这里不讲太深入的，直接讲如何配置。

windows

软件所在的同级目录下有 pac.txt 和 user-rule.txt 的文件。

依葫芦画瓢，把你想要自定义的网址填进去，可以在 pac.txt 上改，也可以在 user-rule.txt上改：

1 2 117 118 119 120 121 162 163