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

最近新建了一个 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 了。


将本地Git仓库与远程仓库进行关联

平时有在本地随手建立代码库当 hello world,开发到一半发现好像还不错,就想直接 push 到远端进行关联。

这一篇介绍如何进行这样的操作。

本地初始化仓库

git init

然后就正常对仓库进行编辑提交。

远端新建项目

这个就各显神通了,可以用 github oschina 或者 gitlab 之类的。然后拿到 git 的 ssh 地址,类似这种:

git@github.com:kelvinblood/KeluLinuxKit.git

关联

将本地的仓库和远程的仓库进行关联,例如

git remote add origin git@github.com:kelvinblood/KeluLinuxKit.git

至此,就将本地与远端的代码仓库关联了起来。


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

今天用 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服务器

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

  • 知乎: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 。

参考资料


Shadowsocks 代理修改 PAC 与 user-rule 文件

什么是PAC

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

PAC的好处

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

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

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

windows

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


1 2 43 44 45 46 47 89 90