很久没写blog了。今天考虑写一篇,登陆过程中想起目前登陆还是http裸奔状态,安全性实在是差。决定加一个登陆https保护。

    之前搞过一个startssl的免费证书,一年到期了。这次不想用他家了,一副浓浓山寨风。去namecheap搞了一个,很快就签发了。

    给一个子域名部署上去,把博客登陆提交地址改成https地址。这样密码的提交操作就被https保护了。


     如果只这么做了,登陆是不会成功的。因为子域的session和主域session默认是不通的。

     在session_start前加一句:  ini_set("session.cookie_domain", '.snooda.com');


     然后重启一下浏览器(此步骤必须)


     尝试一下登陆,ok了。
Tags:
    Thinkpad刚买回来的时候散热性能是非常好的,夏天用也非常凉爽,但用上两三年后,d壳就会非常热,夏天感觉都能有五十度往上了。拆开彻底的清理过灰尘,好了一些,但远没有新机的时候好。

    看到网络上很多人提到给笔记本风扇上了油或者换了新风扇,温度下降很多。认为有可能是风扇老化了。

    查看风扇转速,发现还是3000+转啊,噪音是变大了。但转速在那里,散热器灰尘也吹干净了,风量不小。


    为啥就是那么热呢?



     今天终于找到了问题的答案。原来散热器也是会老化的。


     笔记本的散热器就是一个铜的家伙,之前一直以为是靠铜来导热,还想那么长,导热过去要多久。今天仔细一研究,发现小小的散热器也用的热管。时间长了,热管里的导热剂泄露,导致热管导热性能下降。于是就产生了这种结果:风扇狂转,风量很大,但温度就是降不下来。


      这个时候只更换风扇是不够的了。要将整个散热器更换才可以治本了。









Tags: ,
    最近发现很多同学不知道线上操作替换文件的要点。所以又整理了一下。


    线上替换一个正在运行进程的文件时(包括二进制、动态库、需要读取的资源文件等)。应避免使用cp/scp操作。而需要使用mv/rsync作为替代。

    原因:cp是将源文件截断然后写入新内容。也就是说正在打开这个文件的进程可以立刻感知到修改。修改文件内容很可能导致程序逻辑错误甚至崩溃。而mv则是标记”删除“老文件,然后放一个新的同名文件过去。也就是说老文件和新文件其实是两个不同文件(inode不同),只是名字一样而已。正在打开老文件的进程不会受到影响。如果进程使用了mmap打开某文件(比如载入so),如果目标文件被使用cp覆盖并且长度变小。那么读取差额部分的地址时(在新文件中其实已经不存在了),会导致SIGBUS信号。使进程崩溃。




    至于可执行文件本身。倒是不怕cp导致崩溃。。因为cp时会报”text file busy"。压根cp不了。这时候也应该使用mv类操作。替换完成后重启进程。执行的就是新的可执行文件了。





Tags:
    lighttpd有一个功能,就是收到SIGHUP信号时会重新打开日志文件。这样在日志切分时很有用。但最近发现了一个bug。

    就是如果有子进程挂掉。父进程新fork出的子进程accesslog会默认打日志到最最开始父进程启动时的那个文件里。


   看了下代码。原来父进程在收到SIGHUP的时候只是把errorlog重新打开了下。没有重新打开accesslog(没办法,这个句柄是mod_accesslog模块搞的)。所以父进程维护的accesslog句柄一直是最老的。它本身不打accesslog日志倒无所谓。但它fork出的子进程是打的。这样就有问题了。



    一个最简单方法。就是外部脚本判断进程有更新的时候发一个SIGHUP信号过去。

    根治方法就是父进程重新启动子进程时给其发一个SIGHUP信号。

    至于父进程自己处理SIGHUP时重新打开句柄这个我感觉不太好。毕竟那是模块内部数据。lighttpd主干不应该关心。





Tags: ,
    最近arm盒子想用下tun功能。结果发现内核编译时没开tun,所以决定编译一个。

    先去找到了当前内核的config文件。打开了tun支持。下一步就是去找内核的源码。找了半天。发现没有完全一样的。于是找了个版本相近的,编译完载入。显然加载不了。提示insmod: error inserting 'tun.ko': -1 Invalid module format。在dmesg里提示tun: no symbol version for module_layout。

    很多资料在这里提示没有Module.symvers云云。但我的编译目录是有这个文件的。所以不是这个问题。

    由于内核源码版本和当前内核版本并不完全一致。所以尝试关闭CONFIG_MODVERSIONS。编译后加载。

    insmod依旧提示invalid module format。dmesg里改为提示version magic 'xxxxxxxxxxxxxxxxxxxxxx' should be 'xxxxx'。


    modprobe是可以强制忽略version magic的。即--force-vermagic参数,使用后成功载入tun.ko。由于内核源码非常相近。故工作正常。
    查阅了一下2.4内核源码中对CONFIG_MODVERSIONS的说明,该参数有四种可能。即内核是否开启与要加载的扩展是否开启2*2。经观察发现在3时代内核上这个特性跟之前的文档不太一致。由于时间关系没有详细研究。

    modprobe还有个参数,即--force-modversion。是在编译时开启了CONFIG_MODVERSIONS的情况下忽略接口不一致的。这个参数没有实验。


    也就是说如果想给一个内核编译扩展。最好的方式当然是找到当时编译的环境。或者编译一个新内核+扩展给系统装上。但现实中往往无法这样做。这时找到相近的源码编译。最后强制载入也就行了。(生产环境不推荐)



    happy,tun可以用了。
Tags: ,

top/vmstat等cpu iowait值含义

[| 不指定 2013/06/05 23:03]
    今天发现了一个现象。有一台io压力比较大的机器,基本iowait百分之七十左右。idle接近0。按我的理解是百分之七十的cpu都在等待或处理io。没有空闲的时间片了。

    但开启了一个视频转码服务后,iowait降到很低水平,usr和sys飙高,idle还是接近0。但此时发现视频转码和原io操作的服务均正常运行,未发生性能波动。

    马上感觉到其中的矛盾。cpu不是用完了么?为啥还能承受一个视频转码这种cpu密集的服务呢?

    
    仔细查看了一下iowait的解释。原来它的真实含义是:cpu空闲并且有进程在等待io就绪的时间。

    也就是说如果iowait很高。那么磁盘压力较大。但此时cpu是较为空闲的。此时如果运行诸如视频转码这种cpu密集型操作。是可以提高cpu利用率的。这一点在服务混布提高利用率上可以做文章。




Tags: ,
    今天发现这样一种部署情况:
   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:
分页: 2/33 第一页 上页 1 2 3 4 5 6 7 8 9 10 下页 最后页 [ 显示模式: 摘要 | 列表 ]