Step-by-step 輕鬆架設部落格

edited 十月 2013 in 個人資訊管理
LifeType 是國內目前最熱門的部落格架站程式之一,
以前稱為 pLog , 根據國內著名的 OSS 開發者也是 LifeType 團隊成員一的
Mark 報導,許多大站提供的 blog 服務都選擇 LifeType !!
你也可以參考先前 Mark 為晟鑫科技撰寫的 " 網誌Blog的企業應用 "
http://www.ossii.com.tw/modules/sections/index.php?op=viewarticle&artid=22

在晟鑫科技推出的 MagicOSS 平台架設 LifeType 就跟玩"樂高積木"一樣,
是一件輕鬆又有趣的事,以下就讓我們一起 Step-by-step 來架設 LifeType 1.0.6 。
(截至 2006/08/25 LifeType 最新的穩定版本是 1.0.6 )

全文請參考以下的連結:
" Step-by-step 輕鬆架設部落格 --- 在 MagicOSS 上安裝 LifeType !!。"
http://www.bizforge.com.tw/modules/news/article.php?storyid=9

原始討論: http://twpug.net/x/modules/newbb/viewtopic.php?topic_id=2023

評論

  • edited 八月 2006
    說實話,我對 LifeType 很感冒。
    如果你們有時間去堆那個東西的話,我到希望你們去堆底下這個:
    ISPConfig http://www.ispconfig.org/

    我個人目前有個小計畫要作類似這個東西,也是作整合...
    今年的目標是把一些Serevr軟體玩過一遍,明年開始寫程式。
  • edited 八月 2006
    oh .... 有多感冒?可以說說看嗎?

    Mark
  • edited 八月 2006
    我們打算把本站首頁下的那些 e-MAP 軟體都做成 Step-by-step 的 rpm 。
    如果你覺得不適用,不用就是了 ...
    我只知道 99 % 的人可能需要一個 Blog ...
    而不到 1% 的人可能需要你要做的那個 ISPconfg ...

    沒有所謂對錯,確信自己無悔就好 !!

    P.S. TWPUG 的部落格也是用 Lifetype , 不是嗎 ?
  • edited 八月 2006
    對 LifeType 感冒的也不指我一個,我只是覺得,在 Blog 上有其他的選擇就是了,為什麼要選這個被許多主機商「指名」不許用戶使用的東西呢?

    至於這邊的 Blog 也是用 LifeType 我沒立場講 Kiang ,但是你們的產品可是要給各大企業用的,我只是給個建議而已,沒有惡意...

    說實話,有時候我真的很怕這種意見之爭,至於我提的那個 ISPConfig ,則是我從另外一個角度、看法提出的東西,或許跟威豆你們本身的「基礎」有相當的替換性(個人看法)。

    只是覺得每過一段時間再回去看你們做的事情,就像大樹一樣越長越大,可是根扎的不夠深,你所謂的平台會逐漸被其他的東西漸漸侵蝕掉。

    我不記得上次有沒有跟你提過B2D這個東西?這東西比起你們做的,已經在「表面」上看起來差異不大了。

    我知道經營很辛苦、困難,也希望你們能長得很好,不過別忘了這些潛在的競爭者唷!
  • edited 八月 2006
    我想部份主機商會禁止使用 LifeType 的原因也許是它屬於"多用戶程式",會跟主機商的利益產生衝突吧? :)
  • edited 八月 2006
    我瞭解的是因為 LifeType 本身程式的關係,只要用戶一多,會消耗掉許多系統資源,影響同一台主機上其他的站台。

    跟他本身多用戶其實無關。有許多主機商是用流量算錢的,流量越多他越高興,所以這件事情基本上是有其他原因。

    我之前回應時本來想轉一篇我在其他地方看到的文章來佐證,不過一直找不到那篇文章,只好算了!
  • edited 八月 2006
    呵呵!我來幫你找吧!

    http://blog.gslin.org/archives/2006/05/20/601/

    很多事情是要自己用過,然後去驗證的,這是工程師的精神。

    請參考看看了!

    Mark
  • edited 八月 2006
    不是這一篇...
    這篇我也看過,不過我最近看到的是另外一篇,文章發表日期是最近的兩個禮拜內。
    文章的用的是 1.1 beta 來測試,以及跟其他的 Blog 系統來作比較。

    我無意說 LifeType 如何如何,反正就像威豆說的有人需要 Blog 系統,所以他們就弄了一個上去,我對許多主機商至今仍對 LifeType 下禁用令這點有意見而已,並非針對 LifeType。

    至於是誰的問題,是主機商有問題還是 LifeType 有問題,我不與置評。
    我只說:兩年多前,我在國內找不到 PHP5 的主機商,現在仍然屈指可數,這件事到底是誰有問題呢?這跟 LifeType 的事件可以等量齊觀嗎?

    由廣大的群眾去決定吧,由掌握國內網路的偉大主機商們去決定吧。
    P.S.
    Mark,有時候要常常回過頭看看環境,程式寫的好有時並不代表什麼,大環境不允許你的東西這樣搞,要懂得找其他得出口。

    我承認在中小企業內這麼搞是條出口,這個策略也會奏效,但是下個版本當你們再增添新的功能時,會不會又再度發生類似的事情呢?

    我不是純粹的工程師,我有時也會偷懶、也會犯錯,但是我想如果這件事情對 LifeType 的發展有傷害,你應該從比較正式的管道,來一次公平的測試,洗清這個疑慮,讓主機商們把禁用令撤掉。

    個人認為在 Blog 、 論壇上打筆戰不是辦法,正面回應才是正道。

    另外一提,我跟 kiang 最近都在玩 Drupal 這套 CMS,老實說,個人感覺這套的 Loading 還比 LifeType 重一些,不過這套主機商們卻沒下禁用令。
  • edited 八月 2006
    我沒在打筆戰吧?我到現在才寫了幾句話,連反對或贊成的話都還沒說呢?

    我只是想瞭解你對 LifeType 感冒在哪裡啊?如果你作了測試,我很樂意聆聽,如果你是從別的地方看來,我很樂意去看。

    可是你似乎就是先預設我是要來打筆戰的。呵呵!

    如果找到那篇文章,記得貼給我!在還沒看到你說的文章之前,我實在無法修正。

    Mark
  • edited 八月 2006
    如果我有誤會你的說法我道歉!

    我會等 1.1 正式 Release 弄出來,放到我這邊的 lighttpd 上測看看。

    我最近在測 ldap 的整合應用,我最後發現,這個方式是在各種組合以及效能、易用性配置取捨間,瓶頸最少的一個。

    測試的時間大概是在九月中旬或下旬會進行,希望到時候 1.1 會Release,如果來不及,我會裝當時已發表 1.1 beta 來測看看...

    不過呢,我其實真的想講的是那個 P.S. 那一段。
    我不否認 LifeType 很好用,我也很喜歡,只是這件事情一直在我心中有疑慮,我要證明個是非黑白。

    另外一提,我個人根本不理 CPU Usage 這項指標,電腦買來就是要操的!我在乎的是瀏覽器前面的等待時間。
  • edited 八月 2006
    我作了很多測試:

    Lighttpd + fastcgi + php
    apache + mod_php5 mpm=prefork
    apache + mod_php5 mpm=woker
    apache + fcgid +php

    lighttpd 真的最快, apache 必需要調教,以穩定度而言 mod_php mpm=prefork 與 fcgid 比較好。worker 雖然快,但是很不穩,常常 lost connection。

    LifeType 現在慢在幾個地方

    1. scripts loading。這部份因為 MVC 的架構,所以能作的就是要把 include_once 改成 require。根據實驗 require 比 include_once 聰明,雖然我不知道為什麼會這樣。但是改成這樣後,至少可以減少 script 的 reload。

    2. resserver.php。目前檔案的輸出,不是用 directly link,而是透過 print 把圖片 output 到 webborwser,這是最大的敗筆。這個部分不僅佔用很高的 resource loading,速度上更是慢。

    3. Page 與 Object Cache。這部份除了 cache lite, 連 memcached 我們也都做好了。只是目前在實驗的 branch 中,我們尚未公佈。

    1, 3 好解決,也已經在 1.1 解決了。而 2 就很難解決,因為要改寫的還不少。改成 directly link 也可以,但是就沒有 httpcache 的 control。還沒想到好方法 ....

    我在 dreamhost 上,自己 complie php5 + eaccelerater + fastcgi,他的速度上,比 dreamhost 本身提供的還快很多,應該說非常多。已經跟我裝在 local 一樣快,而 cpu usage 卻沒有提高。

    所以這是目前的狀況。也是現實的狀況。

    另外,如果你只是單人在用,那麼 memory_limit = 8M 在 1.1 版中已經綽綽有餘。而多人在用,因為你必須計算你的彙整網頁,哪些人氣最高,哪些最多人迴響。 Memory_limit 會比 8M 還高些,目前需要到 12M。

    所以你說有虛擬主機禁用 LifeType,這個我到還沒看到。他們禁止的是不想讓你用 mod_rewrite, 不想讓你用 allowoverride, 不想讓你增加每一個 request 的 memory_limit。所以誰的錯?

    很難說 .... 因為我只付了每個月 US$ 7 元,他每一台機器的 turn rate per month,可能要到 US$ 3000元,所以他當然不希望我用高一些的 cpu, 也不希望我用高一些的 ram,這樣才能多賺一些錢 .... 這我可以理解啊。

    而多用戶的程式,LifeType 與 Xoops, Joomla 或是 Drupal 是很不一樣的。一個是 multi-site, 一個是 single site。很難這樣看。

    sigh,你很容易就看到一堆人在罵東罵西。但是你卻很難看到大家把這些經驗分享出來。

    其實 Server 調教與程式的寫作本來就是兩門『藝術』,很難同樣的設定,能夠用在所有的地方。

    你可以去比對一下 mysinablog 與 hercafe blog ,你可以看看速度上有沒有差異。

    mysinablog 與 hercafe 都是我看著他們長大的,也都參與某些的設計與建置上的討論。由你自己去判斷他們的差別吧!這樣再來討論,免得你被我誤導。

    至於你如果找到那篇文章,我很希望你能貼上來。我也很好奇啊!目前可以找的到的PHP based 大概就是 lyceum, wordpress mu 與 lifetype。所以如果有人作了比較,我高興還來不及呢!

    而『路』,走不走得出來。呵呵!誰知道。對我而言,這是興趣,也是我跟外國朋友接軌的方式,很好玩!如果那一天不好玩我就會退出了!這是 Open Source 不是嗎? :)

    Mark
  • edited 八月 2006
    我大膽的猜一猜,2 的部份你不採用 directly link 的原因還有一個應該是跟檔案操作有關。

    最近我在 Apache 上不跑 mod_php 而改用 suphp 來跑,也是這個因素。如果情況是跟我所想的一致,這部份說實在話:無解!

    因為主機商的網管比我們「號稱」是程式設計師的這群人都懶,我知道我說這句話會得罪人,但我還是要說。

    至於成本問題,我之前跟這裡的G4們研究過,即便我住新店,有億聯光纖可以請,但是不含管銷費用,每個單位每月都要NT$600才能損益平衡,這個計算是在從0開始經營,一個一個客戶慢慢累積的前提下計算的。當然如果有一群客戶的基礎上,單位成本是會下降的。

    禁用令的部份我是前兩個月在調查目前的主機商支援 PHP5 的程度時發現的,這個月是否有撤銷我還沒作追蹤調查,晚一點我會做一下,再回報給你。

    multi-site 已經是現在的趨勢了,我不認為你的設計策略有任何問題。
    我個人的看法是,假設我是主機商,我就將流量作為一個收費的基數,即便他是線性增加的也好。因為這樣我可以減少許多機會成本,本來一台機器上要給50個單位的,因為你的流量大、CPU Usage高,所以只能放5個這樣的站。
    因此我要跟承租空間的人多收錢,這很合理,使用者付費嘛!

    從另一個角度看,我的管理成本下降了(對50人的客服與技術支援變成5個),機會成本也下降了(不用再到處招商湊滿50個單位)。

    所以我想,可能只有靠低價競爭的主機商會不滿吧,因為入門級的條件並沒有作這樣的設定。

    我這兩個月一直在搞 Server 的系統管理,就是因為我之前對主機商的不滿引起的,就像之前威豆說的要拼地圖。系統管理這塊目前還沒有人很完整的拼出來比較簡單的整合方式,我想這是我可以切入的。
  • edited 八月 2006
    Mark, 在此必須向你道歉。

    我剛剛去繞了一圈,我發現之前有限制裝 LifeType 的主機商都已經不再限制了。所以你是對的!
  • edited 八月 2006
    我這兩個月一直在搞 Server 的系統管理,就是因為我之前對主機商的不滿引起的,就像之前威豆說的要拼地圖。系統管理這塊目前還沒有人很完整的拼出來比較簡單的整合方式,我想這是我可以切入的。

    哈哈哈,威豆的功德無量喔,一篇短短的文章引出兩位大師精彩的對話,真是值得 !!
    顯然 tokimeki 兄雖然聽過幾次威豆的簡報,並不是很清楚威豆的團隊要幹啥,你目前在做的這些事情,在我來看都不是你的核心專長,更不幸地,核心競爭力也不是操之在你,以目光如豆的我而言實在看不到前景 !!

    威豆在玩樂高,不玩拼圖 ... Mark 應該很清楚各位現在評比,介入的主機代管與網站場域是威豆團隊目前不會也不敢去碰的 ...

    威豆提出的 MagicOSS 平台本來就不是專屬的,我們做的就是"整合" !!
    B2D 早已如雷灌耳,但兩者氣質完全不同, MagicOSS 是有"銅臭味"的 ...
    我們做的 rpms 與 Step-by-step Guide 只適用在 MagicOSS 平台,因為威豆在實驗一個概念 --- OSS 缺乏一個 Common Configuration Layer ---
    MagicOSS 就是來提供這樣一個 Layer , 如此而已 !! ( Opendesktop 計畫的 Pupa 提供另外一個 CCL 給 Desktop 的使用者)

    本來下週要報導 Step-by-step 架設 mediawiki ,看到兩位的討論,害我不知道如何是好 ... 或許先報 Step-by-step 架設 Durpal 如何 ?
  • edited 八月 2006
    可能是我把 Web Application 跟 Desktop Application 分的太清楚了。
    感覺上威豆你們在整合的是 Web Application ,而非 Desktop Application ,而我有興趣的是 Server 整合這塊。
    不過剛剛我去看了一下pupa,發現你們也有作 Desktop Application 這塊的整合。

    的確在系統管理非我專長,不過我認為在Web Application 這個範疇底下,程設、系統管理是很難分開來的。
    原因就是我假設大多數會「使用」我的程式的人,都在虛擬主機的環境下跑。

    這個假設是不實際的嗎?不,這個假設只是不夠精確,我要知道的是,虛擬主機的環境與我們自己自行架設的環境,到底有何差異。

    威豆你們可以跳過這一塊是因為你們自己有 Magic OSS 這個 Common Configuration Layer ,要調整環境很簡單,用升級手段就行了。
    其他非 Magic OSS 硬要跑你們放出來的 rpm 也可以,不過或許要稍微調整一下(純猜測)。

    我承認 Common Configuration Layer 的概念很好,可是問題是,這不是大多數 Web Application 開發者的平台!
    以我來說,在 Serevr 端我會故意選擇 Win32 / FreeBSD 以及 Apache / Lighttpd 來作交叉測試,在 Client 則是會用 FF / IE 。

    在推廣上,你們必須說服開發者們使用你們的 Common Configuration Layer ,這點相當重要,不然每次軟體有重大的改版,你們就要花人力去再包一次,這是相當辛苦的事情!
    幾點評論,給你參考看看。
  • edited 八月 2006
    tokimeki:

    這,這 .... 不用道歉,沒那麼嚴肅啦!本來就是在討論問題。何況我也想知道不同的看法。

    謝謝。也請記得找到連結後 post 上來。

    Mark
  • edited 八月 2006
    我覺得做錯事情道歉是最好的處理態度!
    死不認錯只會讓人的觀感不好。

    這幾天也是很努力去找,可是還是找不到那個連結,好死不死我又習慣結束瀏覽器的時候把 History 清掉,造成死無對證...

    個人還是覺得要建議你們,在 1.1 Release 發表時可以辦個測試。

    為了這個爭議,我今天去找了幾個號稱能夠量測 CPU Usage 的軟體,結果幾乎都是作總量統計,最細的也頂多做到某個程式(指定pid)作統計。

    而這些資料很難將每個使用者區分出來,尤其是在以 mod_php 方式執行程式的時候。
    我不太確定 dreamhost 是怎麼抓的,但我跟 kiang 討論的結果是,主機商都很懶,不會自己去研究程式,應該是靠一些設備量測的。
    所以如果 SNMP 無法取得這些 CPU Usage 資料,又或者根本無法區別是哪個使用者在執行程式的話,我覺得這整件事情根本就是 dreamhost 在扯謊。

    對了,我想問一下你的 Blog 為什麼我只能看到首頁,按閱讀全文跑出來的是一片空白 (而且會跑很久)
Sign In or Register to comment.