在tinycolinux上安裝和使用cloudwall

本文關鍵字：在tinycolinux上安裝和使用cloudwall,同步器as webos，uniform native web appstack

在《cloudwall:一種統一nativeapp和webapp的appstack》中我們講到，cloudwall是一種建構在counchdb+counchdbapp之上的管理層APP可直接作為personal cloud hosting 文檔和支援cloudwall plugin開發，然而它産生的奇妙效用在于它能作為webos，提供webappstack的效用，類似我們一直追求的engitor：介乎os和app之間的層面，封裝domainapp開發棧和開發工具的層面。然而它更強大：它提供本地遠端一緻的webapp開發和釋出方式（以無差streamed to bs和anyinstance + inapp editor的方式）。

其實這一切都基本都是counchdb的效果，它內建HTTP，本身是個DB帶存儲，與浏覽器和JS結合緊密，支援hosting couchdbapp，文檔即APP，這個APP僅由HTMLCSSJS構成，這種機制為遠端web提供了至少三個棧，滿足在其中搭建APP的基本條件：1,它的http部分免去了協定開發,web頁面又是易于streamable的，2,它的DB屬性免去了存儲邏輯開發需要。 它stream到本地和每個counchdb instance（replicate）的結果是一樣的，保證了浏覽器與伺服器之間的資料可以做到本地和遠端不斷聯（in-browser os ），本地和遠端，最難跨越的就是這個無縫stream。3，它采用的counchdb使用全棧語言JS，托管在其中的每個cloudwall app本身既是服務端的程式也是用戶端程式(nobackend webapp)。然而就像tiddywiki一樣：實際上在服務端JS隻是靜态文檔stream到用戶端執行，服務端隻視一切為文檔隻是同步器。而tiddywiki這樣的東西少了資料庫托管。

可以說，正是JS和couchdb的完美結合促成了cloudwall，一個lang一個hostingtime,runtime在B端，這種意義下的“WEBAPP”不分本地還是遠端，都是通過資料庫stream的一個端，這就是文章标題說的：uniform native web appstack.

下面，我們講解在tinycolinux上搭建cloudwall，和講解在使用它的過程中，那些可以作為personalcloud使用的方方面面。

之前幾篇文章，我們提出了跨本地/遠端的DISKBIOS XAAS系統，并完善了一個/system rootfs，如前面所說，這是一個system與user libary分開的rootfs系統，/下隻有三個檔案夾/boot,/system,/usr,在/usr下有/local,/tce,/opt,/home,/vz對應于tinycolinux的那些mountable檔案夾。那麼從本篇開始，我們将管這個新的tinycolinux為dbcolinux，且以後的釋出類文章都搬到其上來實踐,如下cloudwall即是一例。

在《cloudwall:一種統一nativeapp和webapp的appstack》中我們講到，cloudwall是一種建構在counchdb+counchdbapp之上的管理層APP可直接作為personal cloud hosting 文檔和支援cloudwall plugin開發，然而它産生的奇妙效用在于它能作為webos，提供webappstack的效用，類似我們一直追求的engitor：介乎os和app之間的層面，封裝domainapp開發棧和開發工具的層面。然而它更強大：它提供本地遠端一緻的webapp開發和釋出方式（以無差streamed to bs和anyinstance + inapp editor的方式）— 這一切正是我們自bcxszy以來就追求的。

cloudwall何以如此強大？其實這一切都不難了解，因為排除cloduwall,這基本都是counchdb的效果，它明顯內建了HTTP，本身是個DB帶存儲，與浏覽器和JS結合緊密，支援hosting couchdbapp，文檔即APP，這個APP僅由HTMLCSSJS構成，這種機制為遠端web提供了至少三個棧，滿足在其中搭建APP的基本條件：1,它的http部分免去了協定開發,web頁面又是易于streamable的，2,它的DB屬性免去了存儲邏輯開發需要。 它stream到本地和每個counchdb instance（replicate）的結果是一樣的，保證了浏覽器與伺服器之間的資料可以做到本地和遠端不斷聯（in-browser os ），本地和遠端，最難跨越的就是這個無縫stream（既然WEBOS可以類比為一個雲存儲based帶nativedev likehood appstacks的東西，其必定要有DB一層，是以為何不以DB的replicate直接為網盤同步呢和app sync呢？其實當初W3C的WEB标準也準備是為WEB在BS端準備無差的web storage,web sql,webgl,etc..以提供類nativedev的appstack效果，不過好多實踐被逐漸抛棄了）。3，它采用的counchdb使用全棧語言JS，托管在其中的每個cloudwall app本身既是服務端的程式也是用戶端程式(nobackend webapp)。然而就像tiddywiki一樣：實際上在服務端JS隻是靜态文檔stream到用戶端執行，服務端隻視一切為文檔隻是同步器(伺服器不儲存程式邏輯僅資料又像極了微端。在微端眼中，與B端浏覽器搭配最好的服務端的标準設施應該就是DB了而不是logicserver。)。而tiddywiki這樣的東西少了資料庫托管。

可以說，正是JS和couchdb的完美結合促成了cloudwall，一個lang一個hostingtime,runtime在B端，這種意義下的“WEBAPP”不分本地還是遠端，都是通過資料庫stream的一個端（而其實couchdb也支援傳統的serverside applogic vs synced applogic），這就是文章标題說的：uniform native web appstack.

下面，我們講解在dbcolinux上搭建cloudwall，我使用的是gcc443 32bit，下的是otp_src_20.3.tar.gz(erlang),js185-1.0.0.tar.gz,apache-couchdb-2.1.1.tar.gz

除此之外，還需要準備3.x的zip-unzip.tcz,icu.tcz,icu-dev.tcz，好了，開始吧

編譯erlang,mozjs

由于dbcolinux的rootfs還處在初級階段，有一些程式編譯和運作還需要原來的/下的目錄布局，如make meunconfig指令時引用到的/usr/lib一定要存在否則即使安裝了ncurses.tcz和ncurses-dev.tcz,還會一直提示undefined reference，是以在這，為了順利完成以下的編譯，我們暫且恢複它，這些空目錄隻是編譯時的權宜，dbcolinux運作不需要，是以編譯完後可删除。

要恢複的目錄與檔案有：

/tmp
/bin指向到/system/bin
/lib指向到/system/lib
etc/resolver弄回來,nameserver 8.8.8.8
/usr/bin指向/system/bin
/usr/include指向/system/include
/usr/lib指向/system/lib           

解壓otp_src_20.3.tar.gz，它不支援shadowbuild和configure，直接cd src,sudo ./configure –prefix=/usr/local/cloudwall/ –with-ssl=/system,如果不加ssl，稍後會出現Uncaught error in rebar_core，然後make,make install

現在來編譯mozjs,會使用到python,python要編譯進ssl才能安裝pip，然後被用于接下來的mozjs,改下Python build目錄下的Modules/Setup中的SSL段内容為：

SSL=/system
_ssl _ssl.c \
-DUSE_SSL -I$(SSL)/include -I$(SSL)/include/openssl \
-L$(SSL)/lib -lssl -lcrypto           

再安裝pip，這裡就需要用到/etc/resolver這個原先的檔案來解析下載下傳位址。安裝zip-unzip.tcz,直接cd js-1.85/js/src,./configure –prefix=/usr/local/cloudwall,make,make install,一路成功，注：這裡千W不要下到mozjs-45.0.2.tar.bz2這樣的源碼包，couchdb2隻要求185的spidermonkey js，編譯mozjs 45要麻煩得多，它要求gcc47,glibc2.12，且接下來與couchdb連接配接不了，比如：會出現，編譯/src/couch_js/*c下檔案，c包含C++頭檔案發生error: unknown type name xxx 的情況，涉及到修改src/couch/rebar.config.script，但是最終不能成功。

接下來編譯couchdb,cd src,./configure –disable-docs,不能執行rebar,會發現它引用了/usr/bin，按開頭說的先把這目錄恢複回來，又發現解壓出來的apachecounch權限是亂的，全部弄為root,make時rebar會用到erlang,設export PATH=$PATH:/usr/local/cloudwall/bin,再make release，提示不能發現jsapi.h，修改src/couch/rebar.config.script：

{“linux”, CouchJSPath, CouchJSSrc, [{env, [{“CFLAGS”, JS_CFLAGS ++ ” -DXP_UNIX -I/usr/local/cloudwall/include/js”}, 
{“LDFLAGS”, JS_LDFLAGS ++ ” -L/usr/local/cloudwall/lib -lm”}]}]},           

成功，提示你複制生成的rel到目标檔案夾。

安裝cloudwall

把生成的rel複制到cloudwall:cp -R rel/* /usr/local/cloudwall，并安裝icu.tcz，現在，将js libs 也複制到/usr/local/lib下，然後

改下/etc/default.ini中二個127.0.0.1為0.0.0.0,

cd /usr/local/cloudwall/rel/couchdb,./bin/couchdb，成功。通路,xxx:5984/_utils/#verifyinstall，進fauxton，在左下user處增加預設的管理使用者，使用者名一定要admin，然後添加一個資料庫mineportal，然後在這個資料庫的design處建立一個文檔出現文檔編輯區，下載下傳

https://cloudwall.me/cloudwall-2.2.json

，用noteplus打開，複制，粘貼到文檔編輯區，儲存，提示成功後，通路如下頁面：

xxx:5984/mineportal/_design/cw22/index.html

進去，輸入admin和密碼，inliner是建立文章的地方，code是建立codesippter的地方，inliner file,gallery等都像是ocwp mineportal，一個網盤設施所提供的功能那樣齊全。它的強大之處就是可以inplace editor生成app.

為了友善啟動，你也可以在網上找到etc/init.d之類的開機啟動邏輯

cloudwall預定于mineporta3,cloudwall能輕易與elm-lang組合，這二者都有強烈的與JS直接綁定的特點。走的是親JS的同路子，且一個使用erlang一個使用haskell的非主流路線的風格相像。結合使用應該會有奇效。比如，打造一個能線上調試的inapp visual editor for cloudwall，下文就暫定為《另一種ipy：在dbcolinux上安裝elmlang》吧

(此處不設回複，掃碼到微信參與留言，或直接點選到原文)