今天发现这样一种部署情况:
   a的文件放在b的目录下,a不想让b看到,所以设置了700权限。

   其实这样也是不安全的。b虽然看不到a的文件,但可以把a的文件删掉。

   因为linux里,目录也是一个“文件”,里面记录了它里面有哪些文件,这些文件的inode。b的目录里可以放啥,b说了算,也就是说,只要将那个目录“文件”里不顺眼的文件项删掉,就能删掉文件,而不管对那个文件本身有没有权限。

   至于文件是不是真的被删掉了。取决于文件的引用数,如果没有其他硬链存在。文件就真的被删了。

  
   这里有一个特殊的目录:tmp。大家都可以往里面写,但只有属主可以删掉自己的。
   可以看下tmp目录的权限,它是root所有,所以对于普通用户来说,生效的是最后三位:rwt。其实应该是rwxt。t是特殊权限,是建立在x权限上的,如果删掉x权限,可以看到t变成了T。即失效了。

   t:SBIT(Sticky Bit)目前只针对目录有效,对于目录的作用是:当用户在该目录下建立文件或目录时,仅有自己与 root才有权力删除。
最具有代表的就是/tmp目录,任何人都可以在/tmp内增加、修改文件(因为权限全是rwx),但仅有该文件/目录建立者与 root能够删除自己的目录或文件。




  
Tags:
新增的HTTP返回码:
650:应用已删除或域名未绑定
651-654: 其他内部错误,请联系管理员


680:被应用防火墙ip黑名单封禁
681:超过应用防火墙设置的限额


配置功能(rewrite)新增点:

1,新增regex_url。该规则与url规则用法相同,区别是规则为标准正则。
例子:
         - regex_url: ^/[a-z0-9]\.html$
                   script: /index.php
                  
注意:regex_url和url规则在同一个app.conf不推荐混合使用。会有匹配顺序问题。

2,新增check_exist。检查文件和目录是否存在。支持的匹配规则:file_exist/dir_exist/not_exist
例子:
    - check_exist: not_exist
                   script: /index.php
                  
3,新增规则:status_code和location。
status_code指定返回的状态码。允许的值:301,302,403,404
location指定跳转地址(在status_code为301,302时使用)
例子:
         - regex_url: ^/secure_page$
                   status_code: 403

         - check_exist: not_exist
                   status_code: 302
                   location: http://example.com/error.html




url规则使用的lua正则由于使用比较晦涩,以后不推荐使用。本次新增的status_code和location也不再支持url规则。
原有url规则功能不受影响。



Tags: ,

dns glue record的查看与校验

[| 不指定 2013/03/31 21:23]
    在使用自有dns服务器时,一般会使用glue record。即使用ns01.snooda.com作为snooda.com的dns服务器,这样就会遇到一个先有鸡还是先有蛋的问题。为了解决此问题,会使用glue record,即由com域dns服务器提供ns01.snooda.com的ip地址。一般这个记录在域名注册商那里修改。但怎么查看是否修改成功了呢?这里dig就派上了用场。


    使用dig +trace +nosearch +all +norecurse snooda.com

    在返回的结果里,我们会在com域dns返回的结果中,看到一个”ADDITIONAL SECTION“,里面提供了两个a记录。这就是glue record。由于我们试图解析snooda.com,所以先从com域dns服务器获取snooda.com的dns服务器地址,com域dns判断结果是一个snooda.com的子域,所以是glue record。所以不但返回了dns地址,还返回了对应的a记录。

    用这个方式就可以检验设置的glue record是否生效。





Tags:
    当使用国外服务器时,经常会发现,下载速度只有十几k。平时可能不太注意,认为服务器带宽不足,或者自己使用的宽带不给力,其实很有可能原因并不在此。

    由于光速的局限性,延迟会比较高(即使光沿直线传播,太平洋一个往返也要一百多毫秒)。并且由于距离较远,途径路由跳数较多,并且网络拥堵的原因。经常会发生丢包的情况。

    对于平时使用最广泛的TCP协议来讲,发送端发出包后,接收端会回复ACK,表示自己收到了。用这种机制来保证可靠性。但对于高延迟链路来讲,如果每发送一个包都等待应答,那么大部分时间都在等待数据包到达,而链路则空置了。为此一般会采用滑动窗口技术。即在窗口满之前,发送端一直发送包,然后收到应答后将确认收到的包从窗口中移除。这样可以提高链路利用率。

    TCP还有一个特性则是拥塞控制。当发送端检测到链路发生丢包时,则会主动缩小窗口大小以减慢发送速度,避免拥塞。不过对于跳数较多的链路来讲,只要有一个路由不够稳定丢包,就会被发送端判断为拥塞,从而影响网络速度。

    为了解决丢包问题,最简单粗暴的方法就是双倍发送,即同一份数据包发送两份。这样的话在服务器带宽充足情况下,丢包率会平方级降低。

    这种方式下,直接优点是降低丢包率,直接缺点是耗费双倍流量。一些延伸影响是更容易触发快速恢复逻辑,避免了丢包时窗口缩减过快。一定程度也能提高网络速度。


    最近比较忙,空闲时间做了一个最简单的程序,试用效果很好,在一台VPS上测试后发现,未开启时单线程下载、ssh管道速度在十几K级别。开启后可以达到平均300KB+的速度。效果非常明显。但对于不加速就可以跑满带宽的类型来讲(多线程下载),开启后反而由于多出来的无效流量,导致速度减半。所以对于多线程/高速链路,这个方案是不适合的。

     目前版本是最简单的逻辑,未来会进行细化(主动触发快速恢复、快速重传等),降低流量浪费,提升加速效果。

     目前程序起名net-speeder,相对于修改协议栈来讲,由于后者需要重新升级编译内核,使用用户态程序部署更方便,稳定性更高,兼容性更好。缺点则是性能开销稍大和自由度有损失。总体比较起来,个人使用还是使用用户态程序更合适一些,特别是在虚拟机中使用(OpenVZ,LXC等虚拟机无法自己定制内核)。




      项目托管地址:http://code.google.com/p/net-speeder/
                           https://github.com/snooda/net-speeder


      

关注微信公众号随时接收最新开发进度。近期将会推出加速效果体验ssh/pptp账号
点击在新窗口中浏览此图片


Tags:

Linux服务器安全操作技巧

[| 不指定 2013/03/13 11:52]
      在服务器操作系统市场上,Linux因其开源、自由的特性赢得了很多人的亲睐。但相比于Windows系统简单直观的GUI界面,Linux的操作很大一部分是使用命令行方式来进行,这对于一部分初学者来讲是一个不小的挑战。操作失误轻则影响服务,重则丢失数据。那么,究竟怎样才能降低风险,更安全的使用Linux呢?

1,  vi的使用
vi是使用很广泛的文本编辑器,可以让双手在基本不离开字母区的情况下完成各种操作。应注意在查看超大文件时,不能使用vi。因为vi会将文件整体载入内存,打开大文件很容易造成服务器内存耗尽、IO占用率飙升。在这种场景下,推荐使用less命令。
2,  慎用rm
在日常操作用,应谨慎使用rm,尤其是-rf参数。对于不需要的文件应先mv到其他位置保留一段时间,待磁盘空间占用率较高需要清理文件时再进行清理。
3,  替换文件使用mv而不是cp
在替换文件时,应先备份原有文件,再使用mv操作将文件覆盖。对于正在使用该文件的进程来讲,mv操作不会在本次使用周期内被感知到,只有重新打开文件时才会生效。而cp则不然。使用cp覆盖文件,特别是覆盖动态链接库,很容易导致一些进程coredump。
4,  编写重要命令时前面加符号#
在编写重要/批量命令时,应在命令开头处先输入符号#(#在shell中为注释符)。确认无误后再去掉#,避免误按回车键导致不完整命令执行造成破坏。
5,  确保操作所依赖条件成立
对于依赖前面执行结果的操作来讲,可以使用&&来连接各条命令,确保前面执行都成功后才进行后面操作,避免前一步执行失败仍继续下一步造成破坏。
6,  使用rsync而不是scp
在拷贝大量文件时,scp无法查看具体进度,并且一但中断就要从头再来。相比之下rsync功能更为强大一些,支持增量传输,并且还可以随时查看进度。
7,  网络操作注意限速
对于rsync或wget等网络操作,应注意限速,避免耗尽带宽影响正常服务的通信。
8,  操作前设计好回滚方案
操作结果不符合预期时,需要将之前的操作回滚。应提前设计好回滚方案,避免到时候手忙脚乱导致操作失误,或操作时未注意备份文件和数据导致回滚失败。








    最近发现有个问题,一个自制的webserver在应答前端请求时,总是要处理1s以上,似乎是由于哪里等待了1秒。研究了下发现:Expect: 100-continue这个东东。

    100-continue这个状态码之前是很少遇到的。这个是http1.1协议为了提高效率设置的。当客户端要POST较大数据给webserver时,可以在发送http头时带上Expect: 100-continue,服务器如果接受这个请求,应答一个HTTP/1.1 100 Continue,那么客户端就继续传输正文,否则应答417,客户端就放弃传送剩余的数据了。这样就避免客户端吭哧吭哧传了一大堆数据上去,结果服务端发现不需要的情况。

    libcurl在不同版本里逻辑不同,有的版本libcurl会在POST数据大于1024字节的时候发送100-continue请求,有的版本则不会。我们用到的libcurl版本会发送,而自制webserver不会应答这个请求,客户端等待1s钟没有收到肯定或否定的应答,还是继续传输了正文,虽然逻辑上并没有问题,但速度上就慢了下来。

    加了下逻辑,对100-continue进行应答,速度马上提高很多。



Tags: ,
    很久之前就有一个问题在困扰,就是明显感觉svn操作完后要顿一顿才结束。一直以为是svn机器性能问题,后来上了ssd也没效果。

   最近抽时间看了下。

   先strace一下看看时间,发现在操作末尾两个gettimeofday之间夹了个select操作。会阻塞几百ms到1s不等,然后超时。

   第一感觉是最后处理完了可能给服务器发回个什么数据之类的,服务器那里哪个规则配的不对,客户端连不上然后超时了。

   看svn源码,看不出来末尾做了啥网络操作,封装了好多层,不确定是不是哪一层注册了什么奇奇怪怪的回调函数,在最后析构时搞一把。

   用gdb单步跑了一下。

   发现svn_io_sleep_for_timestamps函数很可疑。

   查看代码,发现这是个延时函数。svn通过mtime获取文件修改信息,所以每次svn co操作末尾,svn会等待一小段时间再返回,svn客户端判断apr_stat返回的文件mtime是不是1000000整倍数(stat看到的mtime小数点后面是否全是0),如果是0,那么svn认为该文件系统不支持毫秒级粒度的mtime记录,就会等待系统时间秒的跳变,即等待平均0.5s,最长1s。如果不是0,那么只等待1ms。
  
   由于svn使用的apr_sleep为了实现较高精度的sleep延时,使用了select来做延时。这就是strace中select系统调用的由来。


   这里还有一个问题,就是如果文件mtime恰好是整数,那么svn就会判断失误,进而等待较长的时间。作者认为总比每次都等较长的时间好。

   之前用的文件系统是ext2,它只支持秒级精度的mtime,而ext4支持更高精度。

   找了一台机器,划了两个同样大小的分区,一个格式化为ext2,一个格式化为ext4,使用svn co向两个分区中checkout代码,前者耗时0.3到1s不等,后者稳定在100ms。性能提升非常明显。





Tags:
    想上无风扇电源,所以调研下电源去掉噪声后其他地方如何降噪。开始拿cpu风扇入手。cpu散热器用的最便宜的超频三青鸟3。cpu是32nm Sandy Bridge 赛扬G550,比较节能。看网络上有些人在尝试G530无风扇工作,不过都比较简单,决定自己试一下。


    有很多人是在bios中对cpu进行降频以实现降温的,想了下,感觉这种方法灵活性不足,另外太过高端。决定不采用。还是用软件的cpufreq比较简单灵活。使用sensors工具查看cpu温度。


    首先拔掉cpu风扇电源,开机滴滴报警,忽略之,进入系统。看到温度在50度左右。cpu默认工作在1.6G频率下。


    写了个死循环程序,先单核跑满,单核心运行在2.6G频率下,温度缓慢上升。慢慢上升到83度左右稳定下来。

    然后尝试双核跑满,结果温度迅速冲上90+,我看sensors里提示的温度最高值为102度。急忙停了压力,温度1s内就降到了60+。还是挺快的。

     看来默认情况下双核满载单靠散热器是不行的了。下面尝试限制最高频率后的满载测试。

     首先限制双核1.6G,满载,温度没什么变化,很正常,cpu本来就在1.6G下跑着,满不满载没啥区别。
     2G+1.6G,温度上升至70+
     2G+2G,温度缓慢上涨2-3度,看来较低频率情况下,总温度和温度较高那个核的温度相关性大,与发热总核数关系不怎么大。
     2.1G+2.1G,温度上升至80+
     由于80度就已经算是较高的温度了,所以没有继续往上测试。


     当前室温在20度左右。

     也就是说2.1G是可以无风扇长时间稳定运行的一个频率。再高就不好说了。以后有需求就搞个自动限频脚本,温度升到指定值就降低频率防止过热。


     然后看看频率对性能的影响。在网上随便扒拉了一个算某某值的命令,大致跑了下,1.6G频率下跑完需要40多秒,而2G频率下跑完只要33s,再高频率的就没有试了。看来性能还是有一些影响的。





    

  
Tags:
    很久没有写博了,最近一段时间比较忙,不过怕太长时间不更新被抛弃,还是写一些水文章吧。

    前两天入了块硬盘,之前装的台式机一直拿老笔记本硬盘跑着,容量不够了,最近感觉硬盘价格自洪水后又回归到比较合理位置了,于是准备出手。

    最开始看上的是希捷2T,用的人很多,不过网上一看评价,比较惨,说噪音大的,故障率高的等等。另外我的笔记本原装的就是希捷硬盘,用了两年就挂了。于是不敢买了,看看别的,看到了西数的1T蓝盘。


    说实话这一款也不怎么被看好,刚出来时评测说寻道时间高达20ms以上。性能比希捷的稍微差些。不过我比较在意的是噪音和稳定性,由于有计划上无风扇电源,所以对于其他部件的噪音很在意,性能倒是其次了。于是就选定了西数单碟1T。


     下单的时候看有人说新出的已经有寻道时间比较正常的批次了,心里又多了些期望。


     历经几天,终于到手了,刚拿到时感觉比想象的轻很多,看批次是9月30日出厂,产地马来西亚。回家装上,通电,听到一个嗖的加速声音,然后是磁头吱吱的来回运动,持续了1s,没有了。仔细听了下噪音,震动和声音比笔记本的大多了,带动机箱隔板有些颤动。不过相比于电源风扇的声音稍微好一点点。

     先装个windows跑跑hdtune,跟网上的数据对比了下。读取速度还是比较稳定的,基本上一个较为平滑的曲线,最高180MB左右,最低到了100MB以下。所幸寻道时间还可以,16ms,看来寻道时间长的问题修正了。

    由于用了比较老的hdtune,缓存大小测试不出。不过蛋疼的是,居然不支持噪音管理。设置了下aam,果然不行。囧,这也太弱了。另外转速也测不出。


    总体还凑合,反正比老笔记本硬盘快多了
Tags: , ,
    最近一直苦于没有什么话题来写博,今天终于找到一个。    有人疑惑为什么使用fq代理后访问某些网站反而快了,疑问是不是某防火墙在捣鬼。    世界上一共40亿个ipv4地址,ipv6就更多了,为啥访问任意一个地址就能访问的到?是谁维护了这40亿个地址的分布?从这个ip到那个ip途径的路由是谁来指定的?

    从我们电脑的上网来讲,接入网络就能上网,这个是很稀松平常的事,但如果同时接入两个网络呢?比如一根有线一根无线,那么流量是怎么走的呢?这个时候电脑里的路由表就发挥了作用,运行route print命令,可以看到一行行的规则,每个网络包都会从上到下匹配这些规则,如果匹配上,就按规则指定的端口转发出去。一般同一时间段内流量只从一个网卡流出。


    进一步讲,家里多人上网的话会有路由器,对于家里电脑间传送文件和访问公网网站,流量是分发到不同端口的,路由器的路由表规则就不再是简单的向某一个端口分发,而是针对不同的ip段走不同的分发规则,一般内网ip流量分发至对应内网端口,公网流量统一从公网端口发送。

    对于公网上的流量,一样是按照路由表指示的路径行进,路由表是如何生成的呢?

    首先不会是每个ip一条记录,因为数据量太大,这里就用到了ip的分块,最早是用a,b,c三类来划分,后来由于粒度太粗,后来改用子网掩码的形式,子网掩码规定的范围是ip段的网络名,其余部分是可用地址范围(不全是,本文内容不做涉及),这样,路由表的尺寸就能缩减不少。

    互联网是网状的,每个路由都会于1个或多个其他路由进行连接,连接可能断开,可能阻塞,可能新建,所以路由表也会不断更新,一个路由器如何得知互联网上其他路由间的连接状态从而更新自己的路由表,就需要用到路由交换协议,比如RIP,路由器将自己所知道的路由信息广播给周边路由,这样网络连通信息就能不断扩散至全网。


    不过网络上的路由器成千上万,如果所有路由都按照这种方式,效率非常低下。

    现实中,网络划分为了不同的自治系统:AS,AS的编号由ICANN管理,成为一个AS需要有多线路的连通能力,像电信、联通都是AS,一些较大的网络服务商也可以申请AS号和自己的地址空间。每个AS系统内部维护自己地址空间的路由信息,AS系统间的边界路由器使用BGP协议交换各自地址空间,这样,发往一个AS的网络流量只需要发给对应AS的边界路由即可。不过如果AS间网络带宽较小或者不稳定,就会有“跨网络互通问题”,就像国内电信和联通间访问效果不佳。

    早期国内主机解决网络互通问题会使用双ip的方案,同时接入一个电信ip和一个联通ip,再搭配智能dns,可以较好的解决了互通问题。但还是有浪费ip地址、智能dns解析不够准确的问题。

    后来就有了多线主机有的也叫bgp主机,只有一个ip,但同时接入多个线路,有双线、三线、甚至五线。对于接入的线路,均可以实现较好的访问效果。原理就是机房同时实现和多条线路的互通,将ip广播至每条线路。

    对于服务器可以通过接入多线的方式提高接入性能,对于上网者来说也一样。但同时开通两条甚至多条宽带的成本是比较高的,这样我们就可以借助多线服务器来提高网络访问速度。比如辽宁教育网用户访问辽宁联通,需要绕行至东北教育网节点甚至中国教育科研网节点,但如果借助一台部署在辽宁、同时接入教育网线路和联通线路的服务器中转。网络速度就能大大提高。对于访问国外站点也是一样。
    

    资料:
    查看全球bgp路由表:http://www.ris.ripe.net/bgpviz/
    telnet:route-views3.routeviews.org




    
Tags: , ,
分页: 3/31 第一页 上页 1 2 3 4 5 6 7 8 9 10 下页 最后页 [ 显示模式: 摘要 | 列表 ]