是二级域名也要备案,还是白名单来了?

刚刚访问网站的邮件服务子域名, http://mail.ee-forum.org ,得到如下画面:

未备案的二级域名解析
未备案的二级域名解析

其它几个子域名,例如一直可以正常访问的 calendar.ee-forum.org,也得到上述结果。这些子域名和邮件服务,都是使用google的免费站点服务,邮件迄今工作是正常的,而在线文 档,则几个月前开始,进入不能用状态(偶尔能打开一下),协作站点(sites,提供类似在线协作编辑站点页面的功能),同样也不能用很久了,这些明显都是被“墙”掉的, 你访问时会得到服务器超时或无法解析的错误,和上述提示不是一回事。

而以上上述几个子域名,都是用“URL转发”的方式,指向谷歌的对应网址的,奇怪的是,在得到上述阻截的同时,一级域名,ee-forum.org 访问是正常的(这是国内已正常备案的域名),而URL转发的目标,例如 https://mail.google.com/a/ee-forum.org 也是正常可访问的,登录到我的域名解析服务商那里看,也没有异常。

这就奇怪了:要么,这是G.F-W检测域名解析服务的机制有一点偏差,把这种情况判别为需要备案;要么,就是开始要求二级域名也要备案?或者是域名指向国外链 接也要备案?如果是后者的话,那就意味着白名单

所谓白名单,就是说一切可以看见的,都是预先备案的。打个比方说,你在广场上可以随意和人交流,但你不想 和潜在的疯子对话,你很可能通过其它途径,了解疯子的特征,然后拒绝符合这种特征的人,这就是黑名单策略。然而,有人也许会要求所有说话的人先提交一个 精神正常的证明,然后你才愿意与他对话(大家是否会认为他才精神不正常呢^_^)。这两种策略,就如同其名字一样,是天地之别。也许妈妈正在高堂上说:孩子,不要和陌生人说话

顺便说一下,不知何时开始,曾经正常很久的 http://groups.google.com/group/Enterprise-Engineering 也不能访问了。到底是什么法律决定上述的非常正常、增值、优秀而且免费的服务不能用了呢?是严格贯彻党和国家的政策,还是无良商人拉大旗做虎皮,借机封杀 竞争对手呢?不得而知。不过最近的风声鹤唳,完全不像是抽风的样子。也许,党和国家似乎真的作出了重大的、历史性的决定,要对互联网实行全面封闭的政策了。

升级WordPress 2.8.6 到 2.9

网站刚建,正在配置优化,看到最新版的2.9,是一个较重要的版本升级,于是决定先升级再配置、优化。在后台自动升级,不成功,出现以下错误提示:

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 2764934 bytes) in /home5/ninoneum/public_html/ee-forum.org/wp/wp-includes/http.php on line 1331

搜索结果很多,就不引用了,得知这是php或wp设置参数问题,建议无非三条:

  1. 修改php.ini                            memory_limit = xxM
  2. 在程序里面添加                     ini_set(‘memory_limit’, ‘xxM’);
    对wp,wp-settings.php 中有设定(在某个版本开始我没求证)
  3. 在根目录.htaccess 添加     php_value memory_limit xxM

具体数值应该比现有限制加一倍,例如 32M(33554432) -> 64M

据说修改了php.ini,可能要重启服务器。后面的方法,则可能受到服务器设置的限制,不一定生效。我使用的是Bluehost服务器,但我无法修改php.ini,想着没事最好不要去找服务商,于是找到 wp-settings.php 先试试运气。一找就找到了:

if ( !defined(‘WP_MEMORY_LIMIT’) )
define(‘WP_MEMORY_LIMIT’, ’32M’);

if ( function_exists(‘memory_get_usage’) && ( (int) @ini_get(‘memory_limit’) < abs(intval(WP_MEMORY_LIMIT)) ) )
@ini_set(‘memory_limit’, WP_MEMORY_LIMIT);

将上面的数字32M改为64,再回到后台执行升级,OK

今天股票也涨了,运气不错滴说;-)

—-

顺便保留一个帖子,作为备忘。这里解释了在Bluehost上修改php.ini无需重启的特点,和一些操作的注意事项。

Bluehost Clarification

Maximus284 – December 18, 2008 – 09:17

I am one of the tech support staff for the bluehost companies and i would like to clarify a few settings on our system.

Your PHP.INI file is the file you need to modify in order to increase your memory limit.

the settings you will need to modify are these:

max_execution_time = 30 ; Maximum execution time of each script, in seconds (set this to something high like 300)

max_input_time = 60 ; Maximum amount of time each script may spend parsing request data (set this to something high like 600)

memory_limit = 10M ; Maximum amount of memory a script may consume (set this to something like 500M)

Then in the php config icon of your account, set your site to the php5 (single php.ini) settings as the Fast CGI is not compatible with some drupal installations. if you find that fast cgi works, great if not, just stay on the php 5 setting.

Also, you do Not need to , and you cannot reboot the server on bluehost. We have a special modification to our server that allows the php.ini files to be initialized on the fly and it does not need to be restarted every time a change is made. Therefore, make the changes in the php.ini and refresh your site a couple of times and the new settings will be applied.

To see if the settings you are making in your account are taking affect, put a phpinfo.php file in your account and use the <? phpinfo(); ?>

Lastly, do not use the php_flag variable in our server. The .htaccess file does not recognize that flag and it will result in your account producing a 500 error, just make your modifications to the php.ini file itself.

If the above memory fix does not solve your problem, there may be a file in the drupal that is limiting your memory usage. (as this line suggests here: “ini_set(‘memory_limit’, ’12M’); in your sites/default/settings.php file”)

If all the above doesn’t work, contact the bluehost support and drupal to see if there are any other fixes to your problem and/or any other files you may need to modify.

Thanks

—-

用户author和Permalink设置上发生的小问题

测试中创建了一个用户名为“author”,以此用户添加的文章使用固定链接permalink访问时总是404——找不到。

经过一番折腾,发现问题可能是固定链接设置里的 %author%,把这个换成别的,或吧author创建的文章作者改成别的用户,上述错误就不出现了。

这是个很小,很特别的问题。

上传文件路径移到wp安装目录之外的问题

目的

将上传路径由wp安装目录中转移到其他位置。

问题

相关设置在杂项“默认上传路径”(默认为 wp-content/uploads)和“文件的完整URL地址”(默认为空白)。前者为相对地址,相对于当前wp安装目录。改成绝对地址(形如 /pub/files),在我的虚拟服务器上,就直接定位到真正的根目录了,所以上传会报告“无法创建。。。是否有权限之类的”。网上有不少都说是要修改权限,有些人遇到的也许是权限问题,但对虚拟主机用户,可能主要是这里的“绝对路径跑出界”的问题,(为此我也折腾了一番,授所有的权都没有用,才想到这个)。

方案

将默认上传路径改为虚拟主机服务器上的绝对地址,形如:

/…/…/MyDomainName/pub/files (…/… 部分是什么,视乎你的主机)

同时,将“文件的完整URL地址”设为:

http:// MyDomainName/pub/files

* 这两者的设置必须是一致的,否则会出问题,造成404文档找不到的错误。

其它问题

  • 没有普通文件上传。全部被归为“媒体”,上传有些文件类型如xml,log,则报告不符合安全规则之类。
  • 文章中“添加媒体”默认的位置为“相册”。在控制板上叫做“媒体库”。

修改安装目录遇到的问题

目的:把WordPress安装到根目录下的子目录wp中,内容(默认在 wp的 wp-content 子目录),包括permalink或将来静态化目标、上传的文档的目录,则改在安装目录之外,在网站根目录下创建。例如:

  • 安装目录为:\wp
  • 发布目录为: \pub
  • 上传文档目录为:\pub\files

过程

按主机管理员提示,在wp下执行 install.php ,报告正常,出现 adim 登陆页面。登陆正常。然后,修改博客地址,修改前:

  • WordPress安装地址(URL):  http://<mydomain>/wp
  • 博客地址(URL):http://<mydomain>/wp

改为

有提示:“如果您想让博客地址和 WordPress 的安装地址 不相同 的话,请在这里输入您期望的地址。” 按照其中提示的步骤,复制 index.php到根目录,并修改

require(‘./wp/wp-blog-header.php’);    改为   require(‘./wp-blog-header.php’);

在此之前,设了自定义固定链接:

  • /pub/%year%/%monthnum%/p%post_id%.html

上述操作完成(根目录.htaccess 自动创建),复制修改好的index.php到根目录,操作完毕。

问题:无法从根目录 index.php 进入

执行 index.php,出错,无法进入wp。改回原来状态,恢复正常。

问题分析与解决

根目录下有一个index.html,执行index.php,总是被转向读出该文件。估计与访问根目录的默认文档设置顺序有关(未查证)。将index.html删除,就正常了。