服务器+网站
35服务器:目前是日新的主服务器,日新的绝大部分应用在35服务器上:
- Filesystem Used Mounted on
- /dev/da0s1a 3.0G /
- devfs 1.0K /dev
- /dev/da0s1d 81M /var
- /dev/da1s1g 21G /data
- /dev/da1s1d 19G /usr/home
- /dev/da1s1e 6.3G /var/log
- /dev/da1s1f 28G /www
- /dev/da2s1d 53G /backup
网站程序建议放在/www或者相应帐号的home目录;mysql数据都在/data中;备份文件在/backup中,数据库是每天会自动备份一次的;日志文件在/var/log中,已经给每个网站设置好了日志定时切割。
Web服务方面35服务器很畸形地用了Nginx+FastCGI+Apache共存的方式,Nginx占80端口,php-cgi占139端口,Apache占888端口,相对稳定和不常修改的程序在Nginx+FastCGI下跑着,一些老成员的站点在Apache下跑着并由Nginx反向代理。由于在PHP 5.2以上启用safe_mode or an open_basedir会导致CURLOPT_FOLLOWLOCATION失败,所以在Apache下的php是没有打开open_basedir的,需要使用相应功能的站点可以放在Apache下跑,而FastCGI下相应的限制更严格。
35服务器使用ipf防火墙,对公网仅开放80端口,对办公室所处的网段全端口开放,另外对部分IP段开放22、8081端口。SSH占用22端口,Webmin占用8081端口。外网登录服务器需要使用90服务器的代理服务。
登录服务器后提示如下:
- You can edit your website configure in following files:
- /usr/local/etc/apache22/extra/httpd-vhosts.conf (apache)
- /usr/local/etc/nginx/vhost.conf (nginx)
- Then you can use this to apply your settings:
- "nginx -s reload"
- "apchectl restart"
- And you can modify the website files in /www all!
- BUT YOU MUST BACKUP IT BEFORE YOU DO ANYTHING!
- PS:The old data is still in the /usr/home/oldhome/.
- Now the Nginx+FastCGI is working on ecjtu.net,try it in the files:
- /usr/local/etc/nginx/ecjtu.conf.
35服务器一般只给成员开放www组和ftp组权限,如何添加自己的网站以及相应的权限如上,已经解释得很清楚,需要注意的是如果使用日新的域名务必以{yourname}.u.ecjtu.net格式,如果是使用自己的域名必须先备案才可以绑定到日新服务器,严禁绑定未备案的域名到日新的服务器上!
90服务器:日新唯一一台Windows服务器,主要运行着一些ASP站点和日新投稿系统。
未完待续……
马上要准备彻底闭关备战考研,可能就目前的情况有必要对目前日新技术部的整体工作进行一下总结并交付给接下来的TX们了。
日新的基础是整个好几代前辈一起不断努力的结晶,这其中包括新闻部、技术部、互动社区的诸多前辈之心血。首先技术部的TX们需要明确:技术一种工具——或是达到目标的工具,或是展示你能力的工具等,技术的存在终究是为了能够更好地工作,如果以纯技术为全部的话结果可能会是自己最终沦为“工具”。在技术部的TX可能更多的是以磨练技术的想法为主,以学习和研究技术为主固然是好事,在此之外建议大家适当地去关注一下非技术的因子,比如找到自己真正合适的爱好、关注关注互联网大事记、在日新多交一些合适的朋友、多了解非技术人士的想法等。此外大家应该明白日新是一个整体,技术部是日新的一部分,与其他非技术部门的TX更多地交流可以让你的视野和思维更加的广阔:不同圈子的人有不同的大学经历,不同圈子的人交流往往更能碰撞出火花。
好梦网的创始人ZhangWei前辈一直是技术部里的神话,我们一直在期待技术部可以出更多的zhangwei,更多的“好梦网”,但说实话就目前技术部的整体实力还是有些令人无奈的。虽然说除了努力之外学技术多少还是要讲究一些天份,但是绝大部分你需要掌握的技术内容都是更需要你付出努力和时间的,走过之前给TX们各式各样填鸭式培训的探索之路后我最终还是觉得应该:“师傅领进门,修行在个人”。加油吧! TX们!
在Ngnix中如果用变量作为反向代理的地址时,容易出现“no resolver defined to resolve xxx.xxx”的问题,例如:
- server
- {
- listen 80;
- server_name ~^(.*).lib.ecjtu.net$;
- access_log /var/log/nginx/access-lib_ecjtu.log;
- set $key $1;
- location /{
- auth_basic "What's your password?";
- auth_basic_user_file /www/lib_ecjtu_net/htpasswd;
- proxy_pass http://$key;
- }
- }
首先是关于PHP在PHP 5.2以上启用safe_mode or an open_basedir会导致CURLOPT_FOLLOWLOCATION失败,再导致curl_setopt/curl_setopt_array失败。
官方对此有声明如下:
Starting in PHP 5.2.0, CURLOPT_FOLLOWLOCATION can't be set via curl_setopt_array() (or curl_setopt()) when either safe_mode is enabled or open_basedir is set. In these cases, the order of CURLOPT_* settings in the array can be important.
1.CURLOPT_FOLLOWLOCATION
Warning: curl_setopt() [function.curl-setopt]: CURLOPT_FOLLOWLOCATION cannot be activated when in safe_mode or an open_basedir is set
2.curl_setopt_array()
如果curl_setopt_array中包含CURLOPT_FOLLOWLOCATION键值,会导致所有options设置失败,让你感觉curl_setopt_array有问题,其实这个函数本身是没问题的。
昨天晚上涛哥发短信过来说服务器reboot一下就起不来了,刚才看到机柜前看了一下原来是服务器重启的时候卡在了POST之后一个“strike the f1 to continue f2 to run the setup utility”错误提示的地方。
初步判断是BIOS设置的问题,遂按f2进BIOS检查……发现无一异常。
最终通过下面的方法解决这个问题:
按f2进bios按numlock scrolllock capslock三个键点亮键盘灯,然后按alt+e,alt+f,alt+b然后保存退出。
PS:其实就是恢复BIOS默认设置……
我始终觉得这“strike the f1 to continue f2 to run the setup utility”的错误提示跟启动设备有关,不知道为啥
不少网站页面习惯于在URL中的目录名后不加斜杠“/”,这在在apache下会自动添加一个斜杠从而不会造成什么问题,但是如果URL中的二级目录名后不加斜杠的话在Nginx下就会出现403 Forbidden的问题。在网上找到的比较可靠的原因供以想深究的TX进行参考:
在某些情况下(具体可参考 wiki.nginx.org),Nginx 内部重定向规则会被启动,例如,当 URL 指向一个目录并且在最后没有包含“/”时,Nginx 内部会自动的做一个 301 重定向,这时会有两种情况:
1、 server_name_in_redirect on(默认),URL 重定向为: server_name 中的第一个域名 + 目录名 + /;
2、 server_name_in_redirect off,URL 重定向为: 原 URL 中的域名 + 目录名 + /。
当你有多个 域名要指向同一个虚拟主机,并且你自己写 301 重定向规则把它们合并到某一个域名时,情况就更复杂了:
首先,nginx 检查 URL,如果符合条件,就用该规则(你写的)做第一遍重定向,接着,检查新生成的 URL,如果符合内部自动重定向之条件,就用前面提到的规则再做一次重定向。
至于 PHP 的 $_SERVER["SERVER_NAME"],在 nginx 中默认是由 nginx 的变量 $server_name 提供,这时它和重定向没有关系,始终是 server_name 设置中的第一个域名,但这是可以被改变的,在你的 nginx 配置中找到 fastcgi_param 部分,修改
fastcgi_param SERVER_NAME $server_name;
为
fastcgi_param SERVER_NAME $host;
但 现在就要注意了,此时的 $_SERVER["SERVER_NAME"] 会受你写的和 nginx 自己的重定向规则所影响而变化。
现 在就清楚了,如果 MediaWiki 是通过 $_SERVER["SERVER_NAME"] 来自己处理 URL 的话,那么在 nginx + php 的默认环境下,它获得的将始终是 server_name 设置中的第一个域名,所以造成了“不管通过什么域名访问 MediaWiki 首页,都会被跳转到其中的一个域名上。”,这不是 nginx 的重定向造成的,虽然默认 server_name_in_redirect 是 on,但这个指令的影响范围仅仅只是 nginx 自己内部的重定向规则。
有不少TX可能因为一些原因(比如说天朝的cn域名不停政策变化等)从cn域名转换到了其他域名,但是原来使用的cn域名可能已经积攒了大量的搜索引擎亲和因子,在各大搜索引擎被收录了上万的页面,冒然的直接启用新域名会显得得不偿失。所以这个时候通过一些方法最大可能地保存原来已经有的一些网页资源是势在必行的事情。
对于Google来说可以通过Google提供的网站管理员工具来加快域名转移的速度和效果,关于Google网站管理员工具的操作这里就不赘述了,相关的介绍非常详细。
在执行完前期的网站程序和数据转移之后就需要对原网站进行301的永久重定向,在Apache 下可以通过.htaccess配置RewriteRule,Nginx则在配置文件中加上跟下面类似的一段配置就行:
- server {
- listen 80;
- server_name holmesian.cn www.holmesian.cn;
- if ($http_host !~ ~S^holmesian\.org$~T) {
- rewrite ^(.*) http://holmesian.org$1 permanent;
- }
- }
这里值得一提的是Nginx的 Rewrite Flags:
redirect – 返回临时重定向的HTTP状态302
permanent – 返回永久重定向的HTTP状态301
测试一下,现在从搜索引擎来的holmesian.cn和www.holmesian.cn都被直接转成holmesian.org,用户几乎没有任何察觉。接下来等待搜索引擎响应了……估计这个会有一个周期。
DeDe CMS是一个由PHP编写功能强大的开源CMS系统,经过了长时间不断磨合,现在已经是一款比较完善开源CMS系统。
最新版的DeDeCMS提供对每篇文章的关键字自动提取功能,但是经过实际使用之后发现UFT-8版的关键字自动提取功能实在是不敢恭维,所以想到用tag替换关键的办法。
具体操作方法:修改相应文章模板文件,找到
- <meta name="keywords" content="{dede:field.keywords/}" />
改成
- <meta name="keywords" content="{dede:tag row='6'}[field:tag /],{/dede:tag}">
上传修改的文件后重新生成页面即可




