本文为实战操作过程的全程记录,采用一台新创建的linode vps(512M内存)环境,操作系统采用centos 6.2,以从源码编译的方式安装配置nginx, php(fast-cgi模式)web环境。
我们的目标:配置一台高性能、安全的web服务器。
本文为实战操作过程的全程记录,采用一台新创建的linode vps(512M内存)环境,操作系统采用centos 6.2,以从源码编译的方式安装配置nginx, php(fast-cgi模式)web环境。
我们的目标:配置一台高性能、安全的web服务器。
vps最好的主机商有哪些?
vps最好的操作系统是什么?
vps最好的web服务是什么?
vps上运行最好的虚假化技术是什么?
vps最好用的web环境配置是什么?
vps最好的版本是什么?
vps最好的数据中心(机房)选址地点是哪里?
vps上怎样配置参数MySQL最好?
vps上最好的备份方案是什么?
本文是一篇很久以前只写了个提纲的文章。在草稿箱里放了4年多,最近整理博客看其更新时间为 2012年6月30日 @ 10:40,这么久都没有继续写,大概以后也不会续写了,直接发出来算了(2016-10-10 18:48)
vps对于有兴趣建网站的朋友可谓是再好不过的东西,它有着传统虚拟主机所不具备的优点,得到越来越多站长有青睐,现在有越来越多的站长选择了它。然而随着vps主场的火爆,有些不厚道的商家伤害了站点的心。所以站长朋友们要多了解一些vps相关的知识,选择一款适合自己的vps,安心使用、安全管理,enjoying you vps!
VPS是Virtual Private Server的缩写,直译为虚拟专用服务器。顾名思义,它不是一台真实的物理服务器, 但它又不是Shared Hosting(共享虚拟主机),因为使用者对VPS拥有完全的控制权。也就是说,单纯就使用而言,vps就是一台服务器,可以随意的安装卸载软件,可以添加用户,可以开关机,跟使用实体服务器一样。但是,你到机房里,却看不到它,因为它是“虚拟”出来的。
使用过vmware, virtualbox,virtualPC等虚拟机软件的朋友,应该对“虚拟机”并不陌生,其实vps就是虚拟机(客户机),在实体服务器(宿主机)上通过软件虚拟出来的多台虚拟机(客户机)。不过对于建站而用的虚拟机,习惯上称为vps,而不叫虚拟机。(注意不是“虚拟主机”与“虚拟机”不是一个东西)。
这一节着重介绍传统虚拟主机及其缺点。
共享虚拟主机(Shared Hosting)通常简称虚拟主机,是传统上的建站设施,它是在一台服务器主机上安装支持多用户的web服务器软件(现代web服务器软件基本上都支持多用户的),从而可以让多个用户建各自的web站点。它有以下显著特点:
上面提到的虚拟主机的几个劣势,在vps上都是天生不存在的;它主要有以下几个优点,了解虚拟机(vmware或virtualbox等)的朋友很容易理解:
vps的使用,最主要的障碍是技术门槛。
因为vps的管理跟对实体服务器的管理几乎完全一样,除了对硬件的管理之外;所以,vps的使用者要有一定的技术水平,至少要懂得点系统环境配置方面知识。好在有不少vps管理面板软件可供我们使用,如果不是特殊的配置,完全可以满足日常的管理需要。
安全方面的管理,因为vps是互联网上的一台独立服务器,你要保证你的服务器的安全!对于虚拟主机而言,这点主机商会帮我们做好的,所以不用我们多操心。
vps价格通常比虚拟主机高,预算有限的朋友,要多考虑一下了:是使用虚拟主机,还是多花点钱用vps,或者是跟信得过的朋友合租vps? vps也有不同档次,有些入门级的vps也很便宜,尤其美国的。
虚拟主机 | vps | 实体服务器 | |
性能 | 通常较差 | 通常较好,可升级扩充 | 好, |
技术门槛 | 低 | 较高 | 更高,包括硬件维护 |
内存 | 完全共享 | 独立,数百M到数G都有 | 完全独立,由服务器硬件决定,可添加 |
硬盘空间 | 共享,容量通常较小 | 独立,较大 | 完全独立,可添加 |
cpu | 通常限制较多,不能运行耗费资源大的程序 | 有一定限制 | 由服务器硬件决定,完全独占 |
带宽 | 共享带宽,容易受其它站点影响 | 相对独立,一般有保障带宽 | 大,由接入网络决定 |
流量 | 一般较少 | 较大 | 大,由接入网络决定 |
运行速度 | 通常慢 | 较快 | 快 |
站点隔离性 | 很差 | 好 | 完全隔离 |
稳定性 | 通常较差 | 一般较好,前提是系统要正确配置 | 完全依赖配置,包括硬件软件配置 |
功能限制 | 非常多 | 很少 | 几乎没有 |
灵活性 | 几乎根本没有 | 灵活 | 灵活 |
可控性 | 较少 | 很大 | 完全可控 |
安全性 | 较差,主要由主机商负责 | 高,主要靠自行管理 | 高,完全自行管理 |
操作简便性 | 简单 | 较复杂 | 较复杂 |
功能丰富程度 | 十分单一 | 丰富,自由定制 | 丰富,完全自由定制 |
IP地址 | 通常共享,部分主机商提供独立IP | 独立IP,可增加IP | 独立IP,可增加IP |
可扩充性 | 差,通常只能扩充硬盘空间、流量 | 较好,非常方便,可以随时升级内存、硬盘、cpu、带宽等,联系客服或自助操作 | 好,但不方便,要通过更换或添加硬件来实现,麻烦,还有虑硬件兼容性风险 |
迁移便捷性 | 较麻烦,要手工逐个备份站点文件及数据库等,恢复亦然 | 方便,所有文件都可打包压缩,包括配置文件,传到新环境下稍做修改甚至不用修改就可用;有些主机商甚至可以对整个系统直接搬迁 | 靠搬迁机器硬件设备实现 |
适用范围 | 入门级站长、小型个人网站、小型公司网站 | 有一定经验的站长,爱折腾的玩家,有特殊网络服务要求者,模拟实践实体服务器管理者,访问量较大的中小公司网站 | 大中型网站,有特殊网络服务要求者 |
vps并不适合所有人使用,
谁
持续更新中。。。。。。。
前言:今日忽然良心发现,从此告别伸手党。前两天考试结束,就开始闲的蛋疼,索性开始看各种教程,本人N小时之前也是小小白,现在已经跻身小白之列。由于几乎一点计算机技术都不会,教程也是看的晕晕乎乎,头昏脑胀。不过还是搞成功了一些东西,特来分享一些经验。由于没什么实力,也只能各方借鉴来完成一下教程。在此说明,之前看各前辈教程的时候,有用的自己就复制下来到自己电脑,现在写教程,好多就不知道谁是原作者,所以恳请大家见谅。下面肯定有不足之处,甚至错误,欢迎指正,不胜感激。
好了,废话少说,直接开始教程了。。。。。。。近来主要看了反编译之类的教程,先分享这方面知识
Java环境配置
————————————————————————————————————
要想使用apktool等工具,首先必须搭建java环境
请自己下载JDK(到处可以找到,看好自己是32-bit还是64-bit,对应下载。我就不上传了),安装,我是安装在 C:\Program Files\Java\jdk1.7.0 要记住安装位置,待会儿用的着。
接着(以win7示例,xp也差不多)以此打开 计算机-属性-高级系统设置-高级-环境变量,
如下图
点击系统变量(s)下的新建按钮
新建 变量名 JAVA_HOME
变量值为 C:\Program Files\Java\jdk1.7.0(即刚才的安装路径,视自己情况而定)
同理
新建 变量名 PATH
变量值 %JAVA_HOME%\bin;%JAVA_HOME%\jre\bin
新建 变量名 CLASSPATH
变量值 .;%JAVA_HOME%\lib\tools.jar;%JAVA_HOME%\lib\dt.jar
最后保存下配置。。。。。
至此,java环境已经配置成功。为了保险起见,我们来验证一下
打开CMD(开始-附件-命令提示符 或者 win+R)
输入javac或者java,回车如果出现以下类似帮助,哈哈,恭喜你
——————————————————————————————
Apktool工具的使用
接下来主角出场啦,就是apktool,虽说这个工具网上到处都是,但好多不能编译4.0的apk。所以但我极力推荐下面这个(虽说比起其他的麻烦一些,但成功率是我见过最高的,为某些懒惰的机友着想,我也做了些傻瓜处理),这个工具我找的好辛苦的啊。
下载下来之后,解压到任意路径。(建议是某个盘的根目录,好找,哈哈)
我的是这样的
这个工具基本只有以下两个命令:
一、apktool d XX.apk YY
apktool d为反编译命令,其中d代表decode
XX.apk为需要反编译的apk的文件名(XX最好不要带汉字)
YY为存放反编译后的文件的文件夹(随你便,也不要为汉字。。。。YY也可以省略,默认放在XX文件夹内,建议直接省略)
二、命令说明:apktool b YY(上面省略的话就是XX,哈哈)
apktool b为重新编译命令
YY为需要编译的目录(就是存放刚刚你定义的文件夹,上面省略的话就是XX)
实战
下面我以RE管理器(非系统文件)为例(刚好桌面上有一个,哈哈,直接拿来用)
1傻瓜方式
1、 将“re管理器.apk”拉进apktool文件夹内,如下:
2、 将“re管理器.apk”改名为“0.apk”(是零,不是O)
3、 双击“点我反编译.bat”,然后等。。。。等。。。。等。。。。。。。。。。。。然后就发现多了一个文件名为0文件夹。
4、 由于是学习阶段,暂时不做修改,直接双击“点我回编译.bat”回编译感受下成功的喜悦。看着窗口,你就知道生成的apk在哪里了。(吊吊胃口,谁用谁知道)
5、 当然,你以后做到这一步,还需要签名才能安装。签名工具最后又下载,下了你就会用。
2手动方式(以4.04系统文件systemui.apk修改1%电量为例)
1、 将systemui.apk还有framework-res.apk(很重要)放入apktool文件夹下
2、 接着打开CMD窗口,输入e: (回车)
3、 再输入cd apktool(回车) 结果如下:
4、 接着输入:apktool if framework-res.apk(回车),这一步是加载框架,反编译系统程序时很必要。但是我这个版本可以省略这一步的,为安全起见,我顺便也做了这步
5、 输入apktool d systemui.apk(回车),看到下面就成功一半了
6、
然后你就可以修改新生成的systemui文件夹里边的文件了(可没让你乱改,哈哈)现在就可以将1%电池脚本替换到apktool\systemui\res\drawable里边了。如下
7、 然后将你需要的电量图标复制到apktool\systemui\re s\drawable-hdpi里边。
8、 回编译,CMD窗口输入apktool b systemui(回车)出现下面画面,你就有希望成功了。
9、 最后,很重要的一步,你看不到自己卡M了不要怪我哈。这里将原始apk称为A,新生成的apk称为B。以方便下面叙述。将A,B均用winrar打开,不要解压。
第一,(还有第二哦)将B中的resources.arsc文件拉到A中替换,压缩方式改为存储。切记
第二步:将B中的电量脚本拉到A中进行替换,方法参考上面。B中的drawable-hdpi文件夹也拉进A中替换。大功告成,佩服你自己吧。
最后,修改好的A就可以替换到你的手机啦,不过切记要先改权限,相信大家都懂的。
总结:系统apk的反编译是不需要签名的,但最后要进行替换。如上。
一共要替换两类:
1resources.arsc文件
2回编译之前修改过的文件。如例子中的电量脚本与电量图标所在的drawable-hdpi文件夹。
工具包下载 apktool及签名
整整编了一个下午。饭都没吃有木有。既然看到这里了,不介意给我点鼓励吧,哈哈
centos6本身不带mcrypt库的支持,手工编译php时,还需要先安装该库,这里有两个途径
1. 使用第三方源实现yum安装,推荐使用RPMforge,在centos下配置该yum源,配置后即可尝试yum install libmcrypt, yum install libmcrypt-devel, yum install mcrypt-devel 安装该库。本人没有实际操作,不确定具体该包的包名。因为如果使用该库,就没必要手工编译php了,直接yum安装好了。配置RPMforge如下
rpm -ivh http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.i686.rpm yum clean all yum makecache
请参看RPMforge, 很不错的centos RPM/yum源
2. 手工编译安装mcrypt库的支持。
这才是本文主要针对的,手工编译。按php官方的说明 http://www.php.net/manual/en/mcrypt.requirements.php
These functions work using » mcrypt. To use it, download libmcrypt-x.x.tar.gz from» http://mcrypt.sourceforge.net/ and follow the included installation instructions
但是http://mcrypt.sourceforge.net/并没有libmcrypt,而是应该到sourceforge上下载,http://sourceforge.net/projects/mcrypt/files/Libmcrypt/2.5.8/
下载,解压,./configure, make,make install, 很常规的步骤。注意libmcrypt需要c++编译器,请保证安装过gcc-c++, 否则请yum install gcc-c++装之
本地生成的的RSA密钥传需要传到远程主机相应用户家目录下的.ssh子目录下,注意该子目录的权限设置是有严格要求的:其所属用户当然是该用户,其权限应该是700, 即不允许其它用户进入并访问该目录;否则,无法自动登录的。
这种情况下,使用ssh 的-v参数显示详细消息大致如下:
$ ssh -v feng@myremote.host.net OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to myremote.host.net [50.116.14.251] port 22. debug1: Connection established. debug1: identity file /home/feng/.ssh/identity type -1 debug1: identity file /home/feng/.ssh/id_rsa type 1 debug1: identity file /home/feng/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3 debug1: match: OpenSSH_5.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.3 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'myremote.host.net' is known and matches the RSA host key. debug1: Found key in /home/feng/.ssh/known_hosts:8 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information Credentials cache file '/tmp/krb5cc_501' not found debug1: Unspecified GSS failure. Minor code may provide more information Credentials cache file '/tmp/krb5cc_501' not found debug1: Unspecified GSS failure. Minor code may provide more information debug1: Unspecified GSS failure. Minor code may provide more information debug1: Next authentication method: publickey debug1: Offering public key: /home/feng/.ssh/id_rsa debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Offering public key: .ssh/id_rsa debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Trying private key: /home/feng/.ssh/identity debug1: Trying private key: /home/feng/.ssh/id_dsa debug1: Next authentication method: password feng@myremote.host.net's password:
了解关于ssh免密码登录,强烈推荐这篇文章,基于ssh密钥对的自动登录原理及实际操作
注意:本文内容仅供参考,测得数据并没有广泛的代表性。测试结论参看文后总结。
今天凌晨0点买了个linode的 512vps,久闻其最近日本机房质量严重下降——我指的是在本朝大局域网内访问的速度——有点不是太相信,想亲自测试一下;以后把站点迁移上去之后就不方便这么折腾了。
于是点选了Tokyo JP,ssh连接上去看了看,一个很空的系统,大概是最小化安装的,还是这种环境好,没有乱七八糟的东西,想装什么装什么,省心。太困了,于是睡觉。
起床后开始折腾:
时间:2012-06-09 10:00
安装apache ,在web目录里 wget -r http://blog.path8.net ,搞一点文件,用来测试一下页面打开速度。wget太慢,运行了一两分钟,Ctrl+C中止掉;浏览器打开测试页面,通过firebug的网络检测功能查看,速度跟burstNet vps差不多,甚至更慢。
vps上 wget上去一个linux kernel的bz2包,这可是真正的高压缩文件,测试网速时最喜欢用它了! 在vps上wget,速度基本上在300-500K左右,最高也没超过700K。
这么来看,linode 日本东京机房的网络速度果然不很快。
网上找比较linode几个数据中心的速度方面的文章,都比较老,通过搜索得知linode library中(http://library.linode.com/getting-started#sph_selecting-a-data-center)提供的有测速的链接 http://www.linode.com/speedtest/
============= 这几个测速链接如下: ===================
Use this information to determine the best location for your Linode.
Facility | Hostname | Test Download |
Tokyo, JP | speedtest.tokyo.linode.com | 100MB-tokyo.bin |
London, UK | speedtest.london.linode.com | 100MB-london.bin |
Newark, NJ | speedtest.newark.linode.com | 100MB-newark.bin |
Atlanta, GA | speedtest.atlanta.linode.com | 100MB-atlanta.bin |
Dallas, TX | speedtest.dallas.linode.com | 100MB-dallas.bin |
Fremont, CA | speedtest.fremont.linode.com | 100MB-fremont.bin |
========================================================
上网环境为 中国电信光纤宽带,使用firefox下载一个测试文件1分钟左右,然后断开,再下载下一个。
测速结果大致如下:
数据中心 粗测速度(KB/s)
Tokyo, JP 150~210
London, UK 400~700
Newark, NJ 200~220
Atlanta, GA 400~500
Dallas, TX 400~800
Fremont, CA 100~120
因为正好是美国的夜间,而是日本的白天,这点也会影响实际结果。
换个时间再测一下速度,以使结果更具代表性
12:30再次测试,使用wget 命令,仍下载一部分,加上两个参数:wget第一次显示的速度值,wget第一条日志记录中显示值
数据中心 前10秒平均速度 第一次显示速度 第一条记录中速度
Tokyo, JP 35 (35~26) 33 35
London, UK 400 (220~600) 33 193
Newark, NJ 120 (156~80) 30 156
Atlanta, GA 400 (260~560) 42 289
Dallas, TX 600 (480~900) 49 389
Fremont, CA 140 (120~260) 61 138
总结:
Atlanta, GA 与 Dallas, TX 表现最佳,另外 London, UK 也不错,这点之前是没有想到。
----------------------------------
不过就实际有使用情况来看,在国内访问Dallas, TX机房的网络速度很慢,ping值在几个机房中是最高的,web访问起来,跟burst速度差不多,根本没有体现出linode的形象来。经过一天的使用,请求客服换到Fremont, CA ,使用这个据说有些悲摧的机房,一段时间看看情况再说,看是是真的有带宽拥挤而抽风等情况。据说Atlanta, GA 机房在国内访问也是不错的,不过没有试用。
目前本站vps就是在Fremont, CA机房,速度尚可。
----------------------------------
另外,顺便扯一点:
有不少主机商提供的测速都是做过手脚的:他们提供的文件其实是内容高度重复的文件,甚至是整个文件里都是同一个字符,这样的文件,通过http协议下载时,会自动压缩传递的。所以他们的主机:测速链接的文件下载速度超级的快,但用时时候慢得要死。
而linode的测速文件下载下来后,使用zip、bz2压缩,文件大小都没有减小,也就是说他们提供的测速文件还是很专业的,至少在测速方面,他们根本没有想骗用户。
----------------------------
后记:本文是很早写的。2014年的某天本站已迁移到linode日本,当时网络质量还是不错的,丢包率通常在2%以内。然而在2015年,上海电信连接海外网络质量严重bug,丢包暴增,linode日本平均丢包20-30%;cnn, apple, ms等网站在上海电信丢包率也好不了哪里。所以,网络质量这东西,是动态的,老文章的数据,参考意义不大。
很多很多年前的草稿,只有一个标题的草稿,直接发掉算了,不太可能继续写了。2024/3/11