您好,登錄后才能下訂單哦!
本篇內容介紹了“如何在tinycolinux上安裝和使用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的方式)。
其實這一切都基本都是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,好了,開始吧
由于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到目標文件夾。
把生成的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之類的開機啟動邏輯
“如何在tinycolinux上安裝和使用cloudwall”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站,小編將為大家輸出更多高質量的實用文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。