在tinycolinux上安裝sandstorm davros

本文關鍵字：git更新失敗tlsv1，源碼編譯nodejs，提取sandstorm中的davros為免sandstorm版本

在《釋出mineportalv1:ocwp》，《釋出mineportalv2:odoo,seafile》中，我們不斷提到“以中心存儲為後端的webapp設計”，因為以存儲為中心符合個人操作PC的習慣。對于伺服器和運維人員也是一樣，網站體APP也可以産生海量資料，對于遷移和備份是十分重要的，這種存儲後端支援要麼被內建在appstack中（像seafile使用專門的repo server,odoo使用postresgl），要麼被app級自身提供如owncloud的圖床(其實我更傾向于不使用專門的appstack元件的方式比如seafile的檔案伺服器，它破壞了logic server就是langserver的事實，複雜化了不應常變動的appstack單元，odoo用專門的文檔資料庫來做這個檔案伺服器倒是更順眼一些)，也有程式從api互動級維護，我不知道buzz是不是這樣的設計-忘了名了，一個社交聚合管理系統(維護一套應用協作)，更有一些程式從paas級促成這樣的結果如sandstorm：

sandstorm就是一種以維護中心資料為一體的app管理程式設計，為了達到這個目的，它先提出一個paas，這就是sandstorm，它用類似docker的方式為每個應用準備一個沙盒環境，但在管理架構級---也就是sandstorm自身---它本身就是一個js應用，維護所有app産生的執行個體（grains）資料備份，打包，它的grains就是用來做集中化存儲的，且各個grains可以共用使用者驗證機制這樣可以進行API級的互動，還有它下面的一個app-davros:一個類oc personal cloud storage的東西，如果做起plugin來完成可以達到像oc一樣的規模。

該如何看待sandstorm呢？它其實還是一種web os的東西。

繼我們的《在tinycolinux安裝chrome》，群晖就是這樣的web os的典型 as nas os，而OC,sandstorm，也其實是類似群晖桌面的東西，它們都是用web ui做appstore和webapp管理的本質作用-類似native desktop shell，隻是工作在不同的層次---而其實也差不多：oc純php實作管理php apps,sandstorm純js實作，但管理混合語言stack apps，群晖synology都是混合。如果說考慮與langsys綁定的關系，sandstorm和群晖一樣可以管理應用混合語言架構的東西,可以裝各種appstack和各種appstack下的apps，但它與oc一樣也可以全是one lang webstack的:oc是php,sandstorm是js。

為了讓它成為一個純粹的類oc的隻管理js web apps的項目，其實可以把sandstorm關于paas的部分截取去掉，（比如将其放在xaas層次的VM管理中做一個管理入口到sandstorm，這樣sandstorm不光有apps,grains且有vms管理跨langsys,xaas,appstack,etc..），保證它的生态下全是類davros之類的js應用，共用一個類似mean的單appstack，且純粹面向webapps

《elmlang》後，我們關注了大web的js語言，而且還将基于一體化存儲後端的webapp系統的關注點從php,py移到js，那麼這個davros，它就是我們的mineportal3。我們要做的，就是先提取sandstorm中的davros為免sandstorm版本先用起來因為它本身也是一個獨立的單js app。分離掉與sandstorm的xaas管理層薄薄的聯系就可以了。

在tinycolinux上編譯安裝nodejs和npm

tinycolinux上gcc481最高最能編譯7.10.1 ,8.0.0和8.0.0以上會提示ArrayVector(v8::internal::StringStream::FmtElm [])相關的錯誤, 最新的894要求gcc494，

sandstorm自身用的是nodejs8.9.3,官方使用的davros 0.21.7 spk中使用的nodejs6.4.0，是以在這裡我們使用6.4.0版本,首先裝好git，然後裝好py，下載下傳nodejs640其源碼,cd到其中，執行：

./configure --preifx=/usr/local/nodejs && sudo make install

cd到/usr/local/nodejs,export PATH=$PATH:/usr/local/nodejs/bin，執行nodejs發現需要libstdc++高版本，把libstdc++.so.6.0.18(這個是編譯cmake時也需要的庫，參見以前文章)換到/usr/lib下，接着執行npm install -g git://xxx，發現調用git時不能下載下傳https裡的git repos内容，提示SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version Completed with errors

這是由于最近2018.2.1github不采用低級的加密方法了，git依賴cur,curl 指令行依賴 openssl 庫才能使用 ssl 和 TLS。目前一般認為 TLSv1.1 及 TLSv1.2 才是安全的，很多 https 伺服器僅支援這2個協定，不再支援 TLSv1.0 及 ssl。但是 openssl 是從 1.0.1 才支援 TLSv1.1 及 TLSv1.2。系統目前安裝的openssl-1.00.tcz+curl不支援。檢視已安裝的ssl和curl，執行：curl -V(大寫）發現openssl是1.0.0k,curl是7.30.0

我也不想去其它的5.x的tinycolinux中去找了，自己編譯吧。好像5.x的是1.0.2的去掉了sslv2v3的？是以還是自己編譯安裝吧。

我下載下傳的是openssl 1.0.1src和curl-7.15.0.tar.gz,首先安裝perl5,openssl編譯需要perl5,cd srcroot,./config --prefix=/usr/local shared && sudo make install就可以（注意不是./configure）一定要加/usr/local，否則安裝到/usr/local/ssl中去了，加shared可免去下列錯誤:x86cpuid.s:(.text+0x2d0): multiple definition of `OPENSSL_cleanse' ../libcrypto.a(mem_clr.o):mem_clr.c:(.text+0x0): first defined here

接下來編譯新的curl7.30.0，./configure --enable-shared --with-ssl=/usr/local

檢視新的openssl版本

/sbin/ldconfig -v

openssl version -a

檢視curl是否引用了剛編譯安裝的1.0.1版本

curl -V(大寫的），發現使用的是openssl1.0.1

現在git會自動使用ssl3,npm install -g git://xxx或

https://

可以用了。

準備davros代碼并編譯運作,失敗

現在準備davros,我下載下傳的是

https://github.com/mnutt/davros

中的davros-ca480aea708d0e9ae4b63342a4583660609f331f的0.21.7 release,将davros的根中的所有内容全選，上傳到/usr/local/nodejs根目錄，cd到此

我們看到js npm的包管理還是蠻好的，每一個包都維護一個package.json，申明它向前依賴的項。應用即包本身，各個包組成一個樹形關聯關系組成一個大應用，davros作為大應用，可以看到其根下有npm用的根package.json,bower用的根bower.json,etc..

根據

的說明，先sudo npm install，但是發現奇慢，加tb的mirror吧npm install -g cnpm --registry=

https://registry.npm.taobao.org,

再sudo cnpm install發現快多了（這是在安裝src root下那個package.json的依賴關系包括bower）。它可以代替預設的npm，比對不到的它會從預設從github下載下傳。如果有紫紅色的就是出錯的

接下來，sudo bower install後會提示找不到bower,把生成的node_modules/bower/.bin中的那個連結檔案移到/usr/local/nodejs/bin中，并修改指向對應位置

然後sudo npm install 和 sudo bower install --allow-root，發現git出錯：error: SSL certificate problem: unable to get local issuer certificate while accessing

git config --global http.sslVerify false一下會在home/tc/下産生.gitconfig檔案，再sudo bower install --allow-root這下能繼續了。

我們也無法去追蹤到底安裝了多少東西了。

然後按照

的說明，sudo PORT=3009 ember serve，發現ember也沒連結進/usr/local/nodejs/bin中（在src root package.json中它跟bower一樣是要被安裝的也一路并沒有出錯），直接執行吧，不做了：sudo PORT=3009 node_modules/.bin/ember server，發現ember的确在背景打開了守護，根據github的readme.md說明，這時本地桌面用戶端可以連接配接了。

但其實我們根本不用這樣做，因為這個背景守護會耗盡記憶體， top中會看到記憶體占用一直漲，最終指令行也顯示heap out of memeory，嘗試失敗！！

按理說，這裡要ember build一次，之後會将ember一系列東西，包括davros src root的app檔案夾下面的東西全打包在生成的srcroot/dist下一個davros打頭的随機檔案名中。是不是這樣呢，我們也沒時間追究了，隻能換個死方法了，我們直接從spk中取來所有ember build好的東西：

直接提取spk的已編譯好的davros運作,成功

在另外一台機器上安裝一個sandstorm，然後連上進入winscp,進那個spk的目錄，我的是/opt/sandstorm/var/sandstorm/apps/e813a833d983fbc38d87da62ea461fa7/opt/app，全部打包下載下傳，清空原來nodejs的根目錄，重新/tce/nodejs460下make install一次，然後把新的spk中的包的内容全部上傳到這裡，./sandstorm中的launcher.sh弄出來到根，稍微修改下其中的路徑，建立data,data-temp,samplefiles等目錄，執行sudo ./launcher.sh(它其實就是nodejs執行根下的app.js)，注意8000端口不要被占據，成功！！不光oc的桌面用戶端通路。網頁端免sandstorm也可以進入。 可見它與sandstorm管理架構和ember build過程是沒有太多導緻運作失敗上的關系的。

當然，這個免sandstorm是沒有認證機制的，如果是自用的話，随便寫個認證邏輯就可以，這個服務端比oc的服務端快多了。

----------

下文《mineportal demobase總成：一個類sandstorm +sandstorm appsystem的東西》，這應該是在《tinycolinux上裝chrome as 用戶端》之大webstack對應于伺服器的東西。服務于bcxszy教學和實用。

關注我。

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