1、升级linux的python为最新版本
ln -s /usr/bin/python /opt/python**{your install path}**/bin/python
2、设置django-admin.py至系统命令
ln -s /opt/python**{your install path}**/lib/python2.5/site-packages/django/bin/django-admin.py /usr/bin/django-admin.py
然后查看 django-admin.py –version
回显版本正确，则证明系统配置成功。
1、安装django，当然要安装python，我安装的python2.5
./configure –prefix=你的路径
2、安装mysqldb
这个可以看这篇文章 http://www.sunboyu.cn/2009/04/22/python25mysqldb122%E5%AE%89%E8%A3%85.shtml
3、安装easl_install
http://pypi.python.org/pypi/setuptools 我下的源码，按照提示安装就行
4、使用easl_install安装flup
地址 http://www.saddi.com/software/flup/dist/flup-1.0.2-py2.5.egg
5、安装django1.1
python setup install
到这里大体就算安装完了，底下配置。
使用开源产品，的确能加快我们的产品实现进度，我们也感谢那些提供免费开源产品的人。当然，我个人也喜欢开源技术。
但如果开源的产品中给你下个后门，抓取你的数据，你还能高兴么？
现在分析 discuz 7.0 的几段代码：
恩，看见了没，我告诉大家一个写木马常用的方式 eval ,比如asp中查找木马，通常查找fso等关键字，木马一般都给他写成 eval(’f'+’s’,'o’)，写php的应该很熟悉这个函数了。这段代码当然不是木马，咱看看他具体做了什么：
看见了吧，看他提交的几个关键字段：$update['members'],$update['threads'],$update['posts'],$thread['special'],$update['spt_'.$thread['special']],$update['msn_domain'],这些字段提交过去，也许对我们系统安全并无影响，可看看6.0版本的论坛还提交了什么：
uniqueid=**&version=6.0.0&release=20081117&php=5.2.6&mysql=5.0.22&charset=utf-8&bbname=**&mastermobile=****&members=4965&threads=883&posts=25921&spt_0=879&spt_1=4&
mastermobile 看见这个字段你会汗不？
康盛应该为此行为买单不？不会 。
看下边：
III 有限担保和免责声明
1. 本软件及所附带的文件是作为不提供任何明确的或隐含的赔偿或担保的形式提供的。
2. 用户出于自愿而使用本软件，您必须了解使用本软件的风险，在尚未购买产品技术服务之前，我们不承诺提供任何形式的技术支持、使用担保，也不承担任何因使用本软件而产生问题的相关责任。
3. 康盛创想(北京)科技有限公司不对使用本软件构建的论坛中的文章或信息承担责任。
您必须了解使用本软件的风险–用户了解信息泄露的风险么？
康盛创想(北京)科技有限公司不对使用本软件构建的论坛中的文章或信息承担责任。其实，我也不愿意承担。
本文纯属月经文，如有难受，过几天自然恢复。
最近一直在琢磨discuz的优化，想出一些数据缓存的策略：
index.php 部分数据已经进行了缓存，但需要全部缓存，只有当 页面刷新数/更新时间 >>>> 发帖数/更新时间 ，则有必要做此缓存，此处缓存更新最为频繁，适合做内存缓存，但 更新时间不宜太久，此时间根据首页更新频度确定。
forumdisplay.php 更新频繁，优化策略同上，只是更新频度略低于首页。
viewthread.php 回复更新频繁，内容更新频度低，适合做硬盘缓存。但分页部分不可做缓存，否则……
space.php 更新不频繁，适合做硬盘缓存。
faq.php 做个静态即可。
以上分析只是根据平时维护总结，临时脑子一蹦，未作具体分析，欢迎广大站长讨论试用。版权所有，欢迎盗版。
接此篇 http://www.sunboyu.cn/2009/11/05/discuz%E8%AE%BA%E5%9D%9B%E4%BC%98%E5%8C%96.shtml
最近一直在修改discuz，看到了很多问题，在跟系统工程部门合作的时候，也看到了很多比较优秀的解决方案，可以引入到系统中。
底下粗略讲述下已经做过的优化和可以着手进行的优化。
对于一个数据量比较大的论坛，首先是分表。posts表，threads表是必须要分的。可以按照forum表的fid进行分，也可以使用tid进行hash散列分布。分表带来的问题，显然是分页。我们进行排序的时候不可能去进行union查询，否则就失去了分表的意义。在这里，我们使用了一个支持排序的key-value型存储的小型数据库-Tokyo Tyrant（http://1978th.net/tokyotyrant/），用此数据库去同步threads表和posts表的数据，达到高速分页。（附：典型应用可以参见此文章 http://blog.s135.com/tcsql/ ）
随着数据表的膨胀，很多join联查必须进行拆分。分表可能强制我们去拆分联查，另外一些很变动不大的表，比如用户信息表的数据，使用率明显很高，变动不会太大，而使用key-value存储再合适不过。这时候，bdb和memcached是首选，我推荐使用bdb，可以持久存储于硬盘上，由用户更新资料触发更新，不必考虑过期和服务器重启的问题。这样可以减少太多的join联查，而节约数据库服务器的缓存。
随着静态文件的增长和访问量的增长，带宽浪费是一个值得考虑的问题。我们打开discuz的首页，静态文件要比php文件多好几倍，而每个文件都夹带了长长的cookie信息，因此，把这些cookie去掉显然会节约大量的带宽。discuz的文件结构还是很不错的，通常通过一个参数的配置或者全文替换就能完成这项工作。此应用，可以在新浪所有的图片上有所体现。
全文检索是mysql所不擅长的，因此附加一个好的全文检索方案很必须，我熟悉的方案：Lucene，sphinx，whoosh是我喜欢的几个全文检索的工具，对于discuz的负载，我感觉任何一个都能满足应用。在此方案上，设计一个完美的同步触发机制很重要。
还有很多问题，都在待发现中，部分问题已经解决，部分问题可以优化。discuz优化好，其实是个不错的产品。
最近一直在修改系统，并无太多原创的代码。其中修改了ucenterhome和discuz两套代码。
ucenterhome原来的队伍进行优化后，我又改进了分享功能。此功能虽然上线，功能也无大碍，但UE方面差强人意，主要是因为年前项目紧张，此项目投入人力并不多的原因。此功能修改，无详细的需求文档，也未进行详细的需求分析和业务逻辑设计，就匆匆开始了编码过程，结果就是：代码比较混乱，结构性比较差，升级和改进的潜力小。如果要改进，面临的结果就是重写。又因为uchome本身的设计结构，无论改写和重写成本都比较高。
因此，前期的规划是比较重要的，前期多想一点，后期就能节约更多的时间和精力。
这种做法马上应用到下一个项目中：discuz论坛的优化和功能改造。
前期对需求做了详细的分析，在中间不断的需求细化和明确，因此，功能和业务逻辑清晰，代码在修改的时候，保留了原来功能，只做了功能的分支。虽然前期的需求交流花费了较多的时间，但编码过程所花费的时间就很小了。
后者的流程才是以后要继续发扬的流程。
