爱就疯狂,不爱就坚强。

用网盘做免费的附件服务器

之间在群里面有见高手做过 用rayfile做了免费的音乐服务器,貌似效果不错,免费的CDN加速,免费的存储空间,免费的带宽,当然最重要的是可以直接,没有加密,这个效果太棒 完全可以和独立服务器相媲美了。

下面仅仅讲一下思路,上传文件到网盘 然后获取下载地址 有一些网盘没有设置防盗链 比较容易处理 直接php远程获取url地址就可以了

典型的就是rayfile 可以直接拿来使用。

其次就是有加密的 可以通过代码也破解防盗链来实现 稳定的网盘 有115 dbank

当然还有微博了 sina的微博可以做图片服务器,你上传图片 免费CDN 带宽不限空间不限制。

以上仅仅是思路,当然也是只是最初级的应用 你可以用伪静态来处理 把网盘的url换成自己的url地址 规则而已很好写的。

最重要的一点是要备份好文件 一旦网盘出现问题也可以直接切换回来,当然尽量要选择大一点的网盘服务商。

nginx 拒绝指定IP访问服务器

因为测试站点老是被百度收录,所以在测试站点上做了nginx上拒绝所有外来IP的访问。
location /private{
allow 192.168.1.3;//自己公司的外网IP。
deny all;//不允许所有的外来IP访问。
}
这样设置后,目录下的php之外的文件确实只有192.168.1.3这个网的机器访问,但是php文件却依然可以访问,这是为什么哪?
因为nginx的匹配方式是正则表达式优先级比较高。因此PHP解析用的是正则表达式进行匹配,而要限制的目录如果不是用正则表达式,所以,就算是要限制的目录,因为PHP还是能被匹配到,所以,还是解析PHP了。
所以,如果想解决的话,需要把目录也写成正则匹配,而且要放在PHP的前面,否则就会先匹配PHP。
location ~ ^/ {
allow 192.168.1.3;
deny all;
}
改成这样就可以了,外网IP访问的话就会显示 403 forbidden

Linux Load average负载详细介绍

也许你在学习Linux操作系统,会遇到很多问题,这里为你讲解Linux系统Load average负载的知识,你可能对于 Linux 的负载均值(load averages)已有了充分的了解。负载均值在 uptime 或者 top 命令中可以看到,它们可能会显示成这个样子:
load average: 0.09, 0.05, 0.01
很多人会这样理解负载均值:三个数分别代表不同时间段的系统平均负载(一分钟、五 分钟、以及十五分钟),它们的数字当然是越小越好。数字越高,说明服务器的负载越 大,这也可能是服务器出现某种问题的信号。
而事实不完全如此,是什么因素构成了负载均值的大小,以及如何区分它们目前的状况是 “好”还是“糟糕”?什么时候应该注意哪些不正常的数值?
回答这些问题之前,首先需要了解下这些数值背后的些知识。我们先用最简单的例子说明, 一台只配备一块单核处理器的服务器。
行车过桥
一只单核的处理器可以形象得比喻成一条单车道。设想下,你现在需要收取这条道路的过桥 费 – 忙于处理那些将要过桥的车辆。你首先当然需要了解些信息,例如车辆的载重、以及还有多少车辆正在等待过桥。如果前面没有车辆在等待,那么你可以告诉后面的司机通过。 如果车辆众多,那么需要告知他们可能需要稍等一会。
因此,需要些特定的代号表示目前的车流情况,例如:
0.00 表示目前桥面上没有任何的车流。 实际上这种情况与 0.00 和 1.00 之间是相同的,总而言之很通畅,过往的车辆可以丝毫不用等待的通过。
1.00 表示刚好是在这座桥的承受范围内。 这种情况不算糟糕,只是车流会有些堵,不过这种情况可能会造成交通越来越慢。
超过 1.00,那么说明这座桥已经超出负荷,交通严重的拥堵。 那么情况有多糟糕? 例如 2.00 的情况说明车流已经超出了桥所能承受的一倍,那么将有多余过桥一倍的车辆正在焦急的等待。3.00 的话情况就更不妙了,说明这座桥基本上已经快承受不了,还有超出桥负载两倍多的车辆正在等待。
上面的情况和处理器的负载情况非常相似。一辆汽车的过桥时间就好比是处理器处理某线程 的实际时间。Unix 系统定义的进程运行时长为所有处理器内核的处理时间加上线程 在队列中等待的时间。
和收过桥费的管理员一样,你当然希望你的汽车(操作)不会被焦急的等待。所以,理想状态 下,都希望负载平均值小于 1.00 。当然不排除部分峰值会超过 1.00,但长此以往保持这 个状态,就说明会有问题,这时候你应该会很焦急。
“所以你说的理想负荷为 1.00 ?”
嗯,这种情况其实并不完全正确。负荷 1.00 说明系统已经没有剩余的资源了。在实际情况中 ,有经验的系统管理员都会将这条线划在 0.70:
“需要进行调查法则”: 如果长期你的系统负载在 0.70 上下,那么你需要在事情变得更糟糕之前,花些时间了解其原因。
“现在就要修复法则”:1.00 。 如果你的服务器系统负载长期徘徊于 1.00,那么就应该马上解决这个问题。否则,你将半夜接到你上司的电话,这可不是件令人愉快的事情。
“凌晨三点半锻炼身体法则”:5.00。 如果你的服务器负载超过了 5.00 这个数字,那么你将失去你的睡眠,还得在会议中说明这情况发生的原因,总之千万不要让它发生。
那么多个处理器呢?我的均值是 3.00,但是系统运行正常!
哇喔,你有四个处理器的主机?那么它的负载均值在 3.00 是很正常的。
在多处理器系统中,负载均值是基于内核的数量决定的。以 100% 负载计算,1.00 表示单个处理器,而 2.00 则说明有两个双处理器,那么 4.00 就说明主机具有四个处理器。
回到我们上面有关车辆过桥的比喻。1.00 我说过是“一条单车道的道路”。那么在单车道 1.00 情况中,说明这桥梁已经被车塞满了。而在双处理器系统中,这意味着多出了一倍的 负载,也就是说还有 50% 的剩余系统资源 – 因为还有另外条车道可以通行。
所以,单处理器已经在负载的情况下,双处理器的负载满额的情况是 2.00,它还有一倍的资源可以利用。
多核与多处理器
先脱离下主题,我们来讨论下多核心处理器与多处理器的区别。从性能的角度上理解,一台主 机拥有多核心的处理器与另台拥有同样数目的处理性能基本上可以认为是相差无几。当然实际 情况会复杂得多,不同数量的缓存、处理器的频率等因素都可能造成性能的差异。
但即便这些因素造成的实际性能稍有不同,其实系统还是以处理器的核心数量计算负载均值 。这使我们有了两个新的法则:
“有多少核心即为有多少负荷”法则: 在多核处理中,你的系统均值不应该高于处理器核心的总数量。
“核心的核心”法则: 核心分布在分别几个单个物理处理中并不重要,其实两颗四核的处理器 等于 四个双核处理器 等于 八个单处理器。所以,它应该有八个处理器内核。
审视我们自己
让我们再来看看 uptime 的输出
~ $ uptime
23:05 up 14 days, 6:08, 7 users, load averages: 0.65 0.42 0.36
这是个双核处理器,从结果也说明有很多的空闲资源。实际情况是即便它的峰值会到 1.7,我也从来没有考虑过它的负载问题。
那么,怎么会有三个数字的确让人困扰。我们知道,0.65、0.42、0.36 分别说明上一分钟、最后五分钟以及最后十五分钟的系统负载均值。那么这又带来了一个问题:
我们以哪个数字为准?一分钟?五分钟?还是十五分钟?
其实对于这些数字我们已经谈论了很多,我认为你应该着眼于五分钟或者十五分钟的平均数 值。坦白讲,如果前一分钟的负载情况是 1.00,那么仍可以说明认定服务器情况还是正常的。 但是如果十五分钟的数值仍然保持在 1.00,那么就值得注意了(根据我的经验,这时候你应该增加的处理器数量了)。
那么我如何得知我的系统装备了多少核心的处理器?
在Linux 下,可以使用
cat /proc/cpuinfo
获取你系统上的每个处理器的信息。如果你只想得到数字,那么就使用下面的命令:
grep ‘model name’ /proc/cpuinfo | wc -l
Popularity: 11% [?]
以上就是Linux系统Load average负载的内容。

使用scp命令在两台linux上对拷文件或者文件夹

以前一直是在服务器上tar打包压缩,下载到本地电脑上,再上传到另外一台服务器上,再解压。
其实使用scp就可以直接对拷文件或者文件夹了。
scp就是secure copy,是用来进行远程文件拷贝的.数据传输使用ssh1,并且和ssh1使用相同的认证方式,提供相同的安全保证.与rcp不同的是,scp会要求你输入密码如果需要的话.
最简单的应用如下:
scp 本地用户名@IP地址:文件名1 远程用户名@IP地址:文件名2
[本地用户名@IP地址:]可以不输入,可能需要输入远程用户名所对应的密码.
可能有用的几个参数:
-v 和大多数linux命令中的-v意思一样,用来显示进度.可以用来查看连接,认证,或是配置错误.
-C 使能压缩选项.
-P 选择端口.注意-p已经被rcp使用.
-4 强行使用IPV4地址.
-6 强行使用IPV6地址.
scp中很多参数都和ssh1有关,需要的话在看.
例如拷贝单个文件命令:
scp file username@ip:filepath
说明:file是要拷贝的文件名
username:远程登录的用户名,
ip:远程服务器ip
filepath:远程文件路径
拷贝文件夹命令如下:scp -r file username@ip:filepath
多加上一个-r参数即可。
==================================================
不同的Linux之间copy文件常用有3种方法,第一种就是ftp,也就是其中一台Linux安装ftp Server,这样可以另外一台使用ftp的client程序来进行文件的copy。第二种方法就是采用samba服务,类似Windows文件copy的方式来操作,比较简洁方便,第三种就是利用scp命令来进行文件复制。
scp是有Security的文件copy,基于ssh登录。操作起来比较方便,比如要把当前一个文件copy到远程另外一台主机上,可以如下命令。
scp /home/1.gif root@172.19.2.75:/home/root
然后会提示你输入另外那台172.19.2.75主机的root用户的登录密码,接着就开始cp和ungzip了
如果想反过来操作,把文件从远程主机copy到当前系统,也很简单。
scp root@172.19.2.75:/home/abc.gif
复制文件夹的格式是scp -r root@192.168.1.1:/home/ /本地目录

解决Nginx文件类型错误解析漏洞的方法

昨日,80Sec 爆出Nginx具有严重的0day漏洞,详见《Nginx文件类型错误解析漏洞》。只要用户拥有上传图片权限的Nginx+PHP服务器,就有被入侵的可能。

其实此漏洞并不是Nginx的漏洞,而是PHP PATH_INFO的漏洞,详见:http://bugs.php.net/bug.php?id=50852&edit=1

例如用户上传了一张照片,访问地址为http://www.domain.com/images/test.jpg,而test.jpg文件内的内容实际上是PHP代码时,通过http://www.domain.com/images/test.jpg/abc.php就能够执行该文件内的PHP代码。

网上提供的临时解决方法有:

方法①、修改php.ini,设置cgi.fix_pathinfo = 0;然后重启php-cgi。此修改会影响到使用PATH_INFO伪静态的应用,例如我以前博文的URL:http://blog.s135.com/read.php/348.htm 就不能访问了。

方法②、在nginx的配置文件添加如下内容后重启:if ( $fastcgi_script_name ~ \..*\/.*php ) {return 403;}。该匹配同样会一并干掉类似“/read.php/348.htm”的URI。

方法③、对于存储图片的location{…},或虚拟主机server{…},只允许纯静态访问,不配置PHP访问。例如在金山逍遥网论坛、SNS上传的图片、附件,会传送到专门的图片、附件存储服务器集群上(pic.xoyo.com),这组服务器提供纯静态服务,无任何动态PHP配置。各大网站几乎全部进行了图片服务器分离,因此Nginx的此次漏洞对大型网站影响不大。
本人再提供一种修改nginx.conf配置文件的临时解决方法,兼容“http://blog.s135.com/demo/0day/phpinfo.php/test”的PATH_INFO伪静态,拒绝“http://blog.s135.com/demo/0day/phpinfo.jpg/test.php”的漏洞攻击:

location ~* .*\.php($|/)
{
if ($request_filename ~* .*\.php$) {
set $is_path_info ’0′;
}
if (-e $request_filename) {
set $is_path_info ’1′;
}
if ($is_path_info ~ ’0′) {
return 403;
}

fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fcgi.conf;
}

也可将以下内容写在fcgi.conf文件中,便于多个虚拟主机引用:

if ($request_filename ~* .*\.(php|php5)$) {
set $is_path_info ’0′;
}
if (-e $request_filename) {
set $is_path_info ’1′;
}
if ($is_path_info ~ ’0′) {
return 403;
}

fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param SERVER_SOFTWARE nginx;

fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $uri;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param DOCUMENT_URI $document_uri;
fastcgi_param DOCUMENT_ROOT $document_root;
fastcgi_param SERVER_PROTOCOL $server_protocol;

fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $server_name;

# PHP only, required if PHP was built with –enable-force-cgi-redirect
fastcgi_param REDIRECT_STATUS 200;

转载自 http://blog.s135.com/nginx_0day/ 本人测试正常


返回顶部