看來以前沒有人用 phpmsnclass 這東西在 big-endian 的機器上頭.... 直到昨天有人問我他在登入時一直出現 911 的錯誤, 加了一些除錯訊息之後, 終於發現 pack() 的結果與在 x86/x64 上的結果不一樣. 造成 login 所需要的 BLOB 資料運算錯誤.
因為我只有 x86 的機器, 所以... 自然都用 little-endian 的方式來處理, 所以 pack() 傳入的參數是 'L' (依據 machine 來決定 unsigned long 的儲存方式)... 不過, 在 big-endian 結果就不同了.
所以我們應該在這地方使用 'V' (用 little-endian 的方式處理 unsigned long) 才處理, 這樣不管在 little-endian 或 big-endian 的機器都可以正常使用.
有需要的, 請自行到 Google code 去抓 r61 或之後的版本.
由於 Debian Stable 版本除非非換新的版本才能修正安全性的問題, 否則, 是不會把所使用到的軟體的版本升級的. 這時... 就只能選擇使用 backports, 但是如果要用的東西沒在 backports 裡頭時, 就只能自己抓 Debian pool 裡頭的 source 回來自己重編. (閱讀全文)
這問題自從很久之前 (都忘了是多久之前了) 升級到 Debian Squeeze 之後就碰到, 一直沒有處理, 當時只是直接把原本用到的東西轉成 OID 來查, 讓它可以正常使用後就一直沒去管它了. (閱讀全文)
systemrescuecd 實在是一個好東西, 對於出問題的 Linux 來說, 有了這東西, 要修起來就變的方便許多. 一般的使用, 除了燒成光碟來使用外, 也可以放到 usb 隨身碟上頭使用.... 當然, 對於已經存在的系統來說, 更可以直接把 .iso 檔案丟到 /boot 或 / 下頭 (看你的 grub 能找到那一個), 讓 grub 直接載入該光碟來開機. (閱讀全文)
上個月中就發現家裡的一台主機上的 RAID 0 不見了, 試著重開機幾次, 發現某一個硬碟有時會抓不到, 如果有抓到時, 當真的要寫資料進去時, 就會發生問題, 然後整個 RAID 的 filesystem 就看不到了.
這個月回家, 想說最近硬碟價位仍然過高, 打算只把那個有問題的硬碟 (WD 750GB) 移出來, 剩下的三個 750GB 的硬碟再撐一下... 結果, 拿出來後, RAID 重建後開始複製資料 (原本就是拿來備份主要的那台主機的資料), 結果.... 跑了幾個小時, 又出現相同的問題, 一看.... 又一個硬碟 (Hitachi 750GB) 一樣在寫入時發生錯誤.... 看來只好買個新的硬碟來換到這原本的 1.5TB 的空間 (還好最近 Seagate 出了一個感覺比較便宜的 3TB 硬碟, 跟我半年前買的 Hitachi 3TB 似乎差不多價格, 不知是規格那兒有差別... 因為以前同等級的價格還在近 9000 上下, 相差兩千左右).
換上後.... 新的硬碟用起來似乎也比較快, 做 rsync 時感覺比之前快多了.... 不過.... 突然發現在處理到某個路徑的時候, 整個系統突然變的很慢.... 找了半天, 發現主機上頭一個 Hitachi IDE 400GB 怪怪的, 可以讀, 也可以寫, 但.... 讀取速度居然只有 1MB/s.... 比我用的網路還慢.....
因為覺得買小硬碟不划算, 所以就只好再買一個 3TB 的回來, 把原本用來備份的 750GB 換來用, 拿 3TB 的來備份資料. 不過.... 那 400GB 的硬碟裡頭的資料還是得慢慢的 copy 出來 (還好花了兩天慢慢 copy, 都沒出問題, 還是把資料給弄出來了).
最後... 發現新買的 3TB 硬碟 (ST3000DM001), 裝在 ICY DOCK MB454SPF-B 會有時抓的到, 有時抓不到, 試了十幾次, 最後決定直接接到主機板上頭, 似乎就正常了. 我後來有發 email 詢問 ICY DOCK, 他們認為應該可以正確使用才對, 說也許是 SATA III 的硬碟對排線的要求比較高一些, 換個排線也許就可以用. (這我要以後有機會才能試了.... 不過.... 什麼叫做比較好的 SATA III 排線呢? 這東西好像也不是賣的比較貴就比較好吧.... 到時還真不知道要去那兒找排線來用呢....)
之前說過, 可以把 Gallery 2.x 與 3 看成是不同的軟體. G3 可以使用 g2_import 模組把原本 G2 的資料匯入到 G3 裡頭 (所有的檔案都會複製一份, 所以做好後在 G3 的任何動作都不會影響原本在 G2 裡的東西. (閱讀全文)
這是早上那個 Gallery 3 與 ZendGuardLoader 一起使用時的問題, 寫了一個小的 test case, 可以重製這個錯誤. (閱讀全文)
如果你在有使用 Zend Guard Loader 的網站中架設 Gallery 3 的話, 在跑完 install 的畫面之後, 你就會發現你的 Gallery 3 永遠都出現一個空白畫面. 這問題... 有人在 Gallery 那邊問, 想當然的.... 得到一個不是我們的問題的答案 (如果我是作者, 我也會這樣回答的), 也有人在 Zend 那邊問, 結果與我以前問 Zend 問題的經驗一樣.... 完全沒有任何作用. (閱讀全文)
在一般靜態網頁的處理上頭, nginx 可以正常的顯示一些錯誤的訊息 (如 404 File not found 之類的訊息). 不過對於 PHP (其他用 fastcgi 方式跑的程式也一樣), 預設來說, 如果有什麼錯誤, 往往就看到空白的一個網頁. 而一般的 nginx 教學上頭, 對於這個問題的處理建議就是 fastcgi_intercept_errors on 的設定. 但... 這個方式並不是完美的. (閱讀全文)
在 Gallery 3 的 Search 模組中, 是透過 MySQL 的 full-text search 方式來處理, 不過... 這個方式對於 CJK 之類的文字, 由於無法分辨詞的斷點, 是無法正常運作的. 這個修改, 是把有非英文的 search, 改成 like 來處理 (東西一多, 也許效能會很差, 所以... 如果你的系統這樣子改之後, 找東西變很慢的話, 就不要用了). (閱讀全文)
這個是以前寫給 LifeType 使用的 gallery 模組的修改版本, 與之前版本的差異就是可以選擇不使用 Gallery 的 embed 方式來存取. (這時相簿的連結會直接轉到 Gallery 的網頁)
檔案放這兒: http://www.teatime.com.tw/~tommy/files/lifetype/lifetype_gallery.tgz
需要的就自己抓回去用吧.
這是給 LifeType 用的 minislideshow plugin, 可以加上一個區塊顯示 minislideshow 的內容. (閱讀全文)
由於 Gallery 3 使用 flowplayer 這一個 flash player 的原因, 所以只接受 flv 與 mp4 (只能播 h.264, 不過有時會有影無聲) 這兩種檔案. 而在 Gallery 2 的時候, 是透過 QuickTime 的 plugin 來播放, 所以支援的格式似乎多了一些. (閱讀全文)
之前提過 Gallery 3 內部是使用 utf-8 在處理 (實際上, 討論區與官網的文章似乎也多次提到要傳入參數時要用 utf-8 編碼的字串才可以), 不過... 另人不解的是, 為什麼一個說是用 utf-8 字串來處理資料的程式, 反而不能處理 utf-8 的中文路徑與檔名呢? (閱讀全文)
這問題應該很久之前就有了 (七個多月了), 修正的方法很簡單也很直覺, 不過, 不清楚為什麼一直沒被接受.
如果你想刪除這個資料, 可以選擇的進階的設定去直接修改 server_add 的那一個變數 (那是 php serialize 之後的變數值), 或者用這個 patch:
diff -Nur gallery3.orig/modules/server_add//views/admin_server_add.html.php gallery3/modules/server_add//views/admin_server_add.html.php
--- gallery3.orig/modules/server_add//views/admin_server_add.html.php 2011-05-25 12:04:04.000000000 +0800
+++ gallery3/modules/server_add//views/admin_server_add.html.php 2011-12-12 13:48:12.465883402 +0800
@@ -26,7 +26,7 @@
<? foreach ($paths as $id => $path): ?>
<li>
<?= html::clean($path) ?>
- <a href="<?= url::site("admin/server_add/remove_path?path=" . urlencode($path) . "&csrf=<?= access::csrf_token() ?>") ?>"
+ <a href="<?= url::site("admin/server_add/remove_path?path=" . urlencode($path) . "&csrf=".access::csrf_token()) ?>"
id="icon_<?= $id ?>"
class="g-remove-dir g-button">
<span class="ui-icon ui-icon-trash">
修正後就可以正常的刪除不要的路徑了.
當我們利用 minislideshow 之類的小東西在顯示某個相簿的照片時, 是直接利用 RSS 的方式來取得要顯示的照片. 不過, 在 Gallery 3 裡頭, 對於 RSS 中指定要某個相簿的時候, 是使用相簿的 ID 來選取, 利如, 我有個相簿放在 /var/albums/tommy/tommy_photo 這個目錄下, 我必需要知道這個相簿在 Gallery 資料庫中的 ID (例如是 6), 才能用 /rss/feed/gallery/album/6 的方式來取得資料. 這個對於一般的使用者來說, 要知道那個 ID 是多少, 是比較有難度的, 並不如 tommy/tommy_photo 來的直覺. 所以... 改一下程式允許用路徑來選擇, 會比較方便些. (閱讀全文)
Gallery 3 與 Gallery 2 一樣, 也提供了一個 serveradd 模組, 讓我們直接由 server 上頭某個目錄來新增項目, 不過.... 在使用上感覺有點怪怪的. (閱讀全文)
在 Gallery 3 中, 有提供一個 hide 模組, 用來隱藏某些相片, 在一般相簿的瀏覽時可以正常運作, 不讓被隱藏的項目被沒有足夠權限的人看到, 不過... 如果直接給該照片所在的 URL (不管是 Gallery 裡頭的網頁, 或是全圖與縮圖之類的連結), 就可以直接看到該相片, 完全失去隱藏的功用. (閱讀全文)
由於 Gallery 3 大幅的簡化, 所以在安裝使用上, 並不像 Gallery 2 一樣有那麼多的 rewrite 要處理, 相對來說是簡單許多. 原則上只要 nginix 底下的 php 設定是正確的, 而且可以正確使用 PATH_INFO 就可以運作了. (閱讀全文)
Gallery 這軟體很奇怪, 每次改版就是一個全新的程式, 基本上與上一個版本可以當做是完全不同的程式來看待. 據作者的說法, 當初 Galley 2 的出現, 是為了解決在 Gallery 1 上頭的問題.... 而 Gallery 2 看起來是一個很成功的軟體.... 除了整個系統過於肥大之外, 應該也沒什麼缺點. 不過.... 作者還是開發了 Gallery 3, 而且這次的開發應該不太順利吧, 因為由一開始的 beta 到最後正式版的發行, 經過了好幾年. 而且.... 雖然正式版推出了不算短的時間, 整個 Gallery 3 用起來, 我覺得應該還算在 beta 階段吧.... 與 Gallery 2 比起來, 除了用了一些 AJAX 的技巧外, 在功能面上完全比不上舊的 Gallery 2.
如果 Gallery 2 用的還滿意的人, 建議先不要考慮 Gallery 3 吧, 等 3.1 (或 3.2 再來看看). 如果你決定使用 Gallery 3, 那, 這篇與後續的幾篇有關 Gallery 的文章, 應該會對你有些用處. (閱讀全文)
在 Gallery 2 裡頭, 原本播放影片的方式是使用 QuickTime plugin 來處理. 不過... 這個 plugin 並非所有的使用者都有裝, 所以... 我們可以改用 JW Player 來處理. (閱讀全文)
這幾天在測試 Gallery3, 測試 Gallery Remote 時, 發現原本裝的 Gallery2 在使用 Gallery Remote 時也無法正常登入. 登入時會出現這個錯誤訊息:
這錯誤在 Gallery Remote 的 FAQ 裡頭就有, 應該是一開始執行是會去使用 gallery_remote2.php, 如果不存在, 才會轉用別的 URL, 而在 Gallery2 的時候, 是沒有 gallery_remote2.php 的, 正常來說, 這個存取會回傳 404 not found 的錯誤, 不過... 由於我的 nginx 有對 404 做轉向的處理, 結果... 會造成實際收到的是 302 的轉向回應, 所以... 接下去就動作就不正常了.
原本希望保留我在 nginx 下的轉向設定, 只針對 gallery_remote2.php 回應 404 就可以. 不過... 試了一下, 發現似乎不能這樣子處理, 因為只要有轉向的設定, 不過是透過 php 去回應 404, 或在 nginx 對該 URL 回應 404, 都還是會去做轉向的動作.
最後... 只好在使用 Gallery2 的這個 virtual host 中不去對 404 做轉向處理, 改成回應 404 的錯誤. 如:
error_page 404 /internal_error_404_page.html;
location /internal_error_404_page.html {
internal;
}
這樣子改之後, 就可以正常登入了.