Google也挺鸡贼啊

Google也挺鸡贼啊
不知道什么时候封了这个搜索方式

以前可以直接搜索IP的网站
使用 site:.88 就可以搜索出所 IP段88结尾的网站

不要问我为什么有这个需求,反正就是有用
这个方式封掉了….

我试着使用 site:*.88 加通配符 又有结果了
估计之前是拿IP结果玩的太厉害 封了这种模式

修改 nginx access.log日志的时间格式

因为要获取nginx访问信息,作为开发的数据使用,但是nginx的access.log文件中的默认的时间格式是这样的:

  [02/Nov/2017:20:48:25 +0800]

  而要求的格式类似如下:

  [2017-11-02 20:52:06]

方法都几种,但是修改源码的方法看上去麻烦,做起来也简单,我这边修改了源码(把原来的删了,复制新的),重新编译

  1.修改src/http/modules/ngx_http_log_module.c  

{ ngx_string("time_local"), sizeof("28/Sep/1970:12:00:00 +0600") - 1,
ngx_http_log_time },

修改后:
{ ngx_string("time_local"), sizeof("1970-09-28 12:00:00 +0600") - 1,
ngx_http_log_time },

return ngx_cpymem(buf, ngx_cached_http_log_time.data,
ngx_cached_http_log_time.len);

修改后:
return ngx_cpymem(buf, ngx_cached_err_log_time.data,
ngx_cached_err_log_time.len);

2、修改 src/core/ngx_times.c 140行

(void) ngx_sprintf(p1, "%4d/%02d/%02d %02d:%02d:%02d",
tm.ngx_tm_year, tm.ngx_tm_mon,
tm.ngx_tm_mday, tm.ngx_tm_hour,
tm.ngx_tm_min, tm.ngx_tm_sec);

修改后
(void) ngx_sprintf(p1, "%4d-%02d-%02d %02d:%02d:%02d",
tm.ngx_tm_year, tm.ngx_tm_mon,
tm.ngx_tm_mday, tm.ngx_tm_hour,
tm.ngx_tm_min, tm.ngx_tm_sec);

  3.备份一下配置文件(小心一些好)

  4.重新编译,参数还是用原来的吧

5. make && make install 之后重启nginx就行了

seafile专业版 破解

0001. seafile:
关于seafile的介绍请自行百度,其实官方是提供了专业版的,而且免费的专业版跟付了钱买的专业版功能上没有任何区别,主要是免费的只能注册三个用户。(百度上也貌似找不到专业版的破解版)
虽然说是可用的状态,但是我的感觉是十分蛋疼。毕竟有强迫症在作怪,正好作为小白的我可以用这个程序来练练手。

0010.破解:
详细的破解过程就不在此进行阐述,主要是对限制人数进行了破解使其突破3人的限制。(将其修改为1000人)
破解的版本为目前的最新版本 6.2.9
大致分析及破解过程如下:
该程序是由python和C编写,前台使用了python的django框架。
安装好运行之后添加4个用户,根据报错信息追踪代码调用位置。
最后发现判断人数是否超限的代码就在 seafile-pro-server-6.2.9/seahub/seahub/utils/licenseparse.py 文件中:

难道真的就么简单??,于是把3改为1000,重启服务。
继续添加用户,不过这时候错误变成了添加用户失败。果然没那么简单!
继续追踪分析python代码,最后发现基本上所有的操作(比如添加用户,更换邮箱,删除用户)都是使用rpc进行通信调用C语言程序进行的操作。
这时候突然想起启动时控制台的输出信息,于是使用IDA进行静态分析。从 seafile-pro-server-6.2.9/seafile/bin/ccnet-server 文件中发现了端倪。
进行text搜索 :license 果不其然,决定使用人数的代码就在其中。(文件删了后我也懒得下,所以就不放图了,后面的就自行分析吧)。
不过最初我是想做个注册机出来,最后发现程序使用RSA来验证授权文件,所以如果做注册机还需将程序中的公钥替换成我的,这样还不如直接修改人数限制来的简单粗暴。

0100.下载链接:
不知道为什么官网也是放出了一个Ubuntu的版本?所以顺带也破解了。

Ubuntu 版:https://pan.baidu.com/s/1w2jZcoOYKAec1eurHPJVEw 密码:xz2z

百度网盘:https://pan.baidu.com/s/1bYVO_KfWqFbX8vZQwIr7HA 密码:zayr

demo站点:https://pan.deny.cx

文件都是从官网下载的,然后进行了破解,后门病毒之类的应该不存在的吧?(大家请放心,我技术这么渣想加也加不了啊)

0101.安装教程官方的文档都有
安装方法就按照官方的说明来就是了。

0110..侵删;

最近通过搜索访问本文章的关键词:

LVM SATA SSD缓存 性能比较

给客户部署测试的

做了个性能测试比较

测试结果

提升了56M的写入速度,读取速度一般不会是不会成为瓶颈的
这个是未进行LVM差数优化的结果, 根据应用场景,应该有提升空间
例如图片存储,优化meta size的大写, 更换文件系统, 使用XFS,ZFS等等

总结
有效 提升空间不是特别大

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. 增加服务器,按目录平滑分离

Linode KVM升级以后发现些问题

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

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

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

不过还是

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

其实CPU都是一样的

Vimeo 如何赚钱? 如何活下来的?

看到有人问这个?

Vimeo这类视频网站 如何盈利?

尤其是那些比油土鳖次一级的视频网站,有一些在国内可以直接观看,有些需要 dnscrypt,最近在其中一个看旅游类的视频,我的天,那些视频的质量,简直可以跟著名纪录片《 HOME 》媲美,而片头片尾都没任何广告,就连网页两侧的广告都没有,而且只需要一个邮箱就能注册,不需要任何客户隐私信息,不注册也可以直接观看。

更惊人的是,视频基本都是 1080p 以上的质量,这么高的带宽和存贮、运营费用,这家公司是怎么活下来的,我能发现的就是上传视频存贮的话,需要购买付费计划。

对比起我们特色国的视频网站,连 CNTV 都是各种广告,侧栏、片头片尾、视频叠加,能挤广告的都挤满了,更不用说其它公司的了。而且还强制 Flash,Flash 还不够,更强推客户端。。。

然后我回答下
继续阅读Vimeo 如何赚钱? 如何活下来的?

最近通过搜索访问本文章的关键词:

【分享】一个不算成功的数据网站的开发和运营和流量数据的案例 包括原理和想法介绍

分享个不算成功的数据网站制作案例 包括原理和介绍

很早以前 打算利用信息差 尝试下数据网站的存活率
所以设计了这个网站

这个例子算比较早 好几年了 网站现在还存活着
域名使用的是 www.91r.net 很简陋 主要是编程相关的内容
这个内容是来源于 stackoverflow.com

收录可以查看 2017-07-02 更新

百度 8月3日 收录过千万了
该网站共有 10,454,575 个网页被百度收录

百度: https://www.baidu.com/s?wd=site%3A91r.net

Google: https://www.google.com/search?q=site%3A91r.net

当初最早设计的时候
姑且叫第一个版本吧 直接使用小偷程序的原理 就是抓数据 返回
后来发现英文内容 搜索对英文重复内容的判断过于强大 基本无法带来什么流量
数据在多也没用

所以换个思路 就弄了第二个版本
第二个版本的设计 小偷还是小偷 但是利用翻译 把内容翻译为中文
这里的信息差 就是内容唯一性,以及使用百度翻译结果给google抓取
结果是成功的 很短的时间 流量上升到5000IP/天

继续阅读【分享】一个不算成功的数据网站的开发和运营和流量数据的案例 包括原理和想法介绍

最近通过搜索访问本文章的关键词:

semget: No space left on device N次遇到这个问题

This relates to semaphores on your system (you’ve run out). Run the following to clear them out:
ipcs | grep apache | awk ‘{print $2}’ > sem.txt
for i in cat sem.txt; do { ipcrm -s $i; }; done;

If this becomes a common occurance, then you may need to change your ipcs semaphore limits.
Set the following in your /etc/sysctl.conf:
kernel.msgmni = 1024
kernel.sem = 250 256000 32 1024

and reboot your system to load in those values. 继续阅读semget: No space left on device N次遇到这个问题

最近通过搜索访问本文章的关键词: