anakinsean

Just a test from XML/RPC client

And this is second paragraph

Just a test from XML/RPC client

在麻蛙星球上看到這篇文章, 連過去又連過去, 總算看到原文. 我想這應該是很多人想要的解法, 我簡單翻譯如下. 首先你要有一片 Ubuntu 的 Live CD, 如果沒有就去 Download 吧. 用 Ubuntu Live CD 開機, 請進入試用模式. 等到看到 Ubuntu 的畫面之後, 請開啟一個 Terminal. 執行 "sudo apt-get install chntpw",  安裝 chntpw 這支程式. 然後把原本的 Windows 的分割區 mount 進來,  請參考這裡. 接下來, 切換目錄到  WINDOWS/systerm32/config. 執行 "sudo chntpw SAM" 經過一連串的畫面與說明之後, 你會被要求重新設定密碼, 建議用空白, 然後重新開機. Bingo! 這篇原文裡面還有張圖我很喜歡... 哈哈~~ 企鵝破視窗...

花了三天的時間才搞定 Adaptec 2100s 這塊 I2O RAID CARD, 一定要紀錄一下. 根據 Samson 的傳授, 一定要用 Fedora Core 4 安裝, 然後再升級到 Fedora Core 5 才可以.  我呢?  愛搞怪的個性, 燒了 Fedora 9, 安裝過程完全沒問題, 但是重新開機就出現找不到 Partition, 根據我在網路上搜尋的結果, 應該是 i2o_block 這個 driver 沒載入, 或是 Partition name (/dev/i2o/hda or /dev/sda ) 不 match. 試了以下幾種組合: 啟動 Adaptec RAID 的功能, F9 看到一顆硬碟, 安裝沒問題, 重新開機就掛點. 關掉 Adaptec RAID 的功能, F9 看到兩顆硬碟, 使用 Soft-RAID 安裝沒問題, 重新開機, 掛點. 關掉 Adaptec RAID 的功能, F9 看到兩顆硬碟, 安裝在一顆硬碟上, 另一顆不用, 重新開機, 掛點. 於是, 我終於放棄 Fedora, 拿了 Ubuntu Server 7.04 裝, 蛙勒, 安裝成功, 重新開機也沒問題, 帥呆了~~ 但是用同樣的方法在另外一台硬體設備相同的機器上試, 安裝成功, 重新開機卻發生 IO Buffer Error, 我猜測是不是 HD 有問題, 所以拆開機器, 把兩顆硬碟的 SCSI ID 對調, 再試一次, 不行~~~ 我沮喪地放棄, 心想這台機器應該快要宣告罷工. 接下來, 在那台可以執行 Ubuntu 7.04 的機器上執行線上版本 Upgrade 到 8.02, 重新開機之後, 掛點... (人生可以再悲慘一點)   最後,  拿了 Ubuntu 8.02 Server 版, 重新安裝這兩台機器, 蛙勒~~~ 順順順, 順到不行. 安裝完, 重新開機, update 最新更新套件, 重新開機, 還活得好好的.  接下來, 我就要測試一下穩定度, 希望不會有之前使用 Fedora SMP Kernel 會不穩的問題.   Fedora~~~ 看樣子我要離開你投到 Ubuntu 的陣營去了!!

話說, 老王今天一早想到有些機器很久沒做更新, 認真地做了一下 yum update. 看到有新的 kernel 安裝完畢, 想說也該重新開機, 沒想到開完機之後, 有個東西就一直跑不起來, 看到的現象是 httpd 一直 segmentation fault. 我心想, 哪有這種事, 當然還是上 Google 大神查了一下, 發現有些網頁有提到 php 5.2.6 有類似的問題. 好吧! 死工程師就把更新過的 php 5.2.6 降回 php 5.2.2, 蛙勒, 還是不行. 那看一下 yum.log 到底更新了什麼?  哈哈~~ Apache 也更新到 2.2.8,  那就再 downgrade 到 2.2.4,  蛙勒, 還是不行. 死工程師氣到了, 沒關係, 我把 kernel 再換回舊版本總該可以了吧... 重新開機之後,  不行!! 這下子傻眼了... 到底是怎樣!!! 再換版本, php -> 5.2.6  不行!!  httpd -> 2.2.4 不行!! ." ..."" ......""""" .....................................................................""""""""""""""   最後發現,  ㄎㄠ四聲!! (看官, 我不是在罵你, 我只是再唸自己)   那台機器的 mysql 沒跑起來.....!!! 該死的!!!   讓我不僅想到 KISS 法則  (Keep It Simple Stupid).  最簡單的事情要先檢查, 不要自己把問題搞複雜!!

最近在注意這個東西  OpenID :)

這是什麼鬼?  簡單來說,

網路上有很多網站, 每個網站如果要加入會員, 我們就得註冊, 選個帳號, 選個密碼... 等等等, 因此, 加入多少網站, 就有多少帳號, 通常這些帳號可能每個都長得不太一樣, 久了, 可能就忘記了.

OpenID 就是為了解決這個問題,

OpenID 是一個 URL 型態的帳號, 有點像是 email 長長一串.

運作的方式是這樣的, 好比你在一個 mail provider (公司啦, 免費的郵件提供者, 譬如 Yahoo, Hotmail 等等) 申請一個帳號, 你就會擁有一個 email 一樣.  如果你在 OpenID Provider 有帳號, 那麼你就擁有一個 OpenID 的帳號. 目前有提供 OpenID 帳號的有 Yahoo!, Blogger, Flickr, LiveJournal.. 等等, 有個列表在這裡, 可以去看看.

假使您現在有 Yahoo 的帳號, 可以連到 http://openid.yahoo.com/,  登入之後, 就會看到畫面上顯示您的 Yahoo OpenID, 應該是長這個樣子: https://me.yahoo.com/XXXXX .

有了 OpenID 之後呢, 您就可以到有支援 OpenID 的網站上, 用您的 OpenID 登入. 假設您是用 Yahoo 給你的 OpenID, 那個網站就會將你導到 Yahoo 去認證, 然後再回到那個網站去.  ( 目前有支援 OpenID 的網站大多在國外, 這裡有個目錄列表 )

哇~~~ 從此以後, 您只要記得一個帳號密碼就可以在網路上通行無阻了.  這樣不是很棒嗎?

為了找出 MySQL 緩慢的原因, 跟如何 Tuning, 用了好幾個工具, 不小心找到神秘好心人寫的

tuning-primer.sh

基本上, 它是利用 MySQL 本身提供的訊息, 做點判斷, 同時提供一些建議.

以下是它執行產出的結果. 它建議 mysql 至少跑超過 48 小時之後, 收集的資訊跟建議會比較準確.

-- MYSQL PERFORMANCE TUNING PRIMER --
- By: Matthew Montgomery -

MySQL Version 5.0.27-log x86_64

Uptime = 0 days 1 hrs 10 min 21 sec
Avg. qps = 73
Total Questions = 311395
Threads Connected = 83

Warning: Server has not been running for at least 48hrs.
It may not be safe to use these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html
Visit http://www.mysql.com/products/enterprise/advisors.html
for info about MySQL's Enterprise Monitoring and Advisory Service

SLOW QUERIES
Current long_query_time = 5 sec.
You have 2613 out of 311407 that take longer than 5 sec. to complete
The slow query log is enabled.
Your long_query_time seems to be fine

WORKER THREADS
Current thread_cache_size = 16
Current threads_cached = 14
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 512
Current threads_connected = 83
Historic max_used_connections = 130
The number of used connections is 25% of the configured maximum.
Your max_connections variable seems to be fine.

MEMORY USAGE
Max Memory Ever Allocated : 4 G
Configured Max Per-thread Buffers : 14 G
Configured Max Global Buffers : 1 G
Configured Max Memory Limit : 15 G
Physical Memory : 1.96 G

Max memory limit exceeds 90% of physical memory

KEY BUFFER
Current MyISAM index space = 440 M
Current key_buffer_size = 768 M
Key cache miss rate is 1 : 507
Key buffer fill ratio = 5.00 %
Your key_buffer_size seems to be too high.
Perhaps you can use these resources elsewhere

QUERY CACHE
Query cache is enabled
Current query_cache_size = 256 M
Current query_cache_used = 10 M
Current query_cache_limit = 4 M
Current Query cache Memory fill ratio = 4.17 %
Current query_cache_min_res_unit = 2 K
Query Cache is 14 % fragmented
Run "FLUSH QUERY CACHE" periodically to defragment the query cache memory
If you have many small queries lower 'query_cache_min_res_unit' to reduce fragmentation.
Your query_cache_size seems to be too high.
Perhaps you can use these resources elsewhere
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 16 M
Current record/read_rnd_buffer_size = 3 M
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 256.00 K
You have had 2 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.

Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.

OPEN FILES LIMIT
Current open_files_limit = 2570 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_cache value = 1024 tables
You have a total of 224 tables
You have 284 open tables.
The table_cache value seems to be fine

TEMP TABLES
Current max_heap_table_size = 63 M
Current tmp_table_size = 64 M
Of 24475 temp tables, 60% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.
Perhaps you should increase your tmp_table_size and/or max_heap_table_size
to reduce the number of disk-based temporary tables
Note! BLOB and TEXT columns are not allow in memory tables.
If you are using these columns raising these values might not impact your
ratio of on disk temp tables.

TABLE SCANS
Current read_buffer_size = 7 M
Current table scan ratio = 37 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 2015
You may benefit from selective use of InnoDB.

因為某位神秘同事發現, 我們目前使用的網頁認證 (apache mod_auth_ldap + openldap) 有奇怪的狀況, 研究之後發現, 因為我們在 openldap 裡面用的 userPassword 是 Crypt 編碼, 而 Crypt 編碼只處理前八個字元, 也就是說如果密碼長度超過八碼, 也只有前八碼有效. 為了解決這個問題, 我們改用 md5 編碼, 但是利用 perl 的 Digest::MD5 裡的 md5_base64 發現會有問題, 研究了一下前人的腳步發現, 要用以下的方法:

use Digest::MD5 qw(md5);

use MIME::Base64;

my $encrypted_password = mime_encode(md5($clear_password));

產生出來的編碼才是對的, 直接使用 Digest::MD5 的 md5_base64 產生出來的會有問題.  (當然要餵入 openldap 之前, 前面要加上 {MD5} )

但是改成 md5 之後, 原本有台機器透過 pam_ldap/nss_ldap 做認證的卻失敗, 我猜測是需要更改原本的 crypt, 但是改了 /etc/ldap.conf 裡的 pam_password 卻還是不行, 研究了半天, 發現其實 Fedora 本來就有一個 authconfig 的程式可以用, 所以執行 authconfig 設定一下就可以了.

稍微研究一下, 我想應該是 authconfig 更改了 /etc/pam.d/system-auth.

附記, 雖然 openldap 支援 crypt, md5, ssha 等等編碼方式, 但是如果要跟 pam_ldap/nss_ldap 整合, 就只有 crypt/md5 兩種選擇.

因為隔壁認真的琳達小姐通知我, 我的瀏覽器對網站有些怪怪的 access, 因此認真研究一下到底我的 Firefox 做了什麼怪事情. 因此發現了, 我裝的 Fasterfox 擴充套件會對網站要求 robots.txt.

順便介紹一下這個好用的擴充套件好了!!

Fasterfox 這個 Firefox 的擴充套件, 如同它的名字所表示的, 是用來加快 Firefox 瀏覽網站的速度.

它有以下幾個重要的功能:

• Prefetch Links: 利用閒置的頻寬, 事先載入瀏覽頁面裡的其他連結, 以加快接下來的瀏覽速度, 尤其是圖檔之類的 static page.


• Tweak Network: 調整電腦對網路的相關設定以加快瀏覽速度, 譬如說, 同時連結數, 快取, DNS 快取...等等.


• Page Load TImer: Fasterfox 可以在瀏覽器的下方狀態列顯示頁面載入的時間.


• Block Popups: 阻擋跳出廣告視窗.

Firefox 真的是個很好的瀏覽器, 建議所有的蛙友都裝起來, 你會發現看麻蛙會有不一樣的感覺喔!!

如果你還沒開使用 Firefox, 請到這裡下載安裝.

如果你已經裝了 Firefox, 想裝 Fasterfox, 請到這裡下載安裝.

這是不小心在 Linux Journal 上看到介紹的.

甚麼是 Spread Toolkit? 懶得打字介紹, 基本上就是個 high performance messaging service, 欲知詳情請點這裡.

我只是要紀錄一下, 在 FC5 64 bits 上面, 安裝這個東西, 要注意的事情.

Spread Toolkit 就按照 INSTALL 上面安裝, 但是請指定把 library 裝到 /usr/lib64 去, 否則在裝 PERL Spread Module 的時候會一直出現問題, 甚麼找不到 symbal 之類的.

我想, 在 64bits 的環境裡可能都得注意這樣的事情, 因為 FC5 x86_64 上的 PERL 應該 default 會到 /usr/lib64 去找 share library, 如果不安裝在那裡, 會找不到.

當使用 MSN 這類的工具在網路上跟朋友聊天時, 其實這些聊天內容是未經處理地在網路上傳遞, 也就是說, 有心人士, 譬如說公司的 MIS, 或是無聊的同事, 可能可以透過某種工具, 就能看到這些內容, 想想, 是不是挺恐怖的?!!

尤其是常在外面公共場合使用無線網路, 還用 MSN 跟朋友聊天的, 只要某個跟你使用同個無線網路的人, 裝了某種工具, 就可以偷窺您的交談內容, 恐怖吧!! (無聊的老王就曾經嘗試過, 我自首)

那怎麼辦呢? 建議大家去下載 Simp Lite for MSN, 並且請您的朋友也裝上去, 如此一來, 您跟朋友之間的對談就會加上加密功能, 即使被半路攔截, 也不容易被解讀. 不過, 一定要兩邊都有安裝才有用喔!!

Simp Lite for MSN 原創公司: Secway

除了 MSN, Simp Lite 同時也支援 Y!M, ICQ/AIM, Jabber/Google, 請直接到該公司網站下載.

怎麼解決?

把 library/select_lang.lib.php 裡面的

'big5' => 'big5'  改成  'big5' => 'utf8'

'utf-8' => 'utf-8' 改成 'utf-8' => 'utf8'

如果還是有問題, 把 browser 的 cookie 清掉, 因為 phpmyadmin 會把 charset 紀錄在 cookie 裡.

myadminp.ttn.net 已經修正完畢.

前些日子因為我的舊 Server 停擺, 急忙地把相關的東西搬到新機器上, 所有的東西都沒什麼大問題, 唯獨 mail server...

舊機器上因為多年來的努力, 防堵 SPAM 的機制已經相當完整, 但是新機器只有個簡單的 MailScanner, 因此, 我目前每天大概都會收到 500 封以上的 SPAMMail, 我真是砍信砍到一肚子火...

讓我想起曾經想做的 RBL (Realtime Black List)... 時間真是不夠用... 殘念!!

稍微看了一下 MySQL 的 Document 發現, MySQL 從 4.1.x 的版本開始支援 Cluster 的功能.以基本四台機器的構成來說, 前端一台是 SQL Node, 中間兩台是 DATA Node, 後面一台 Management Node.原先的 MySQL Client 還是對 SQL Node 做 Query, SQL Node 跟 DATA Node 之間使用 NDB 的 Data Engine 來處理. Management Node 就是用來管理 Cluster 的.(上圖來自 MySQL 網站)原則上, SQL Node 跟 Data Node 可以一直擴充.這個東西感覺比原先的 Duplication 來得進步許多, 限制也比較少, 但是相對的, 需要的設備機器至少就需要四台, 否則就沒太大意義.不知道效能是否會比較好, 值得試試看!

同事轉來一篇文章, 提到目前討論很熱烈的民國轉西元的事情.文章作者應該是資訊從業人員, 他談到的是當民國 100 年時, 有些電腦系統應該當會碰到當初 Y2K 同樣的問題.讓我想起當年 Y2K 的時候, 那個跨年待在機房嚴陣以待的情形.那時候手上的機器清一色都是 Unix/Linux 的機器, 說真的, 根本就不會有 Y2K 的問題, 因為計算儲存的方式不同.  但是, 沒辦法, 母公司有一套完整的機制, 非得跟著走不可.其實比較值得擔心的, 反倒是 Unix 系統是用 Epoch Time 來紀錄時間, 也就是紀錄從 1970/1/1 到目前的秒數, 這個秒數即將在 2038 年會溢位, 也就是說, 在 2038 年所有的 Unix 機器將面臨類似 Y2K 的問題, 不過我相信到那個時候, 這問題應該早就解決了...2038 年.... 嗯... 我應該已經不在管機器了吧...

WTN 上面部份通知的 email 原本會 BCC 給我 (chinian@noc.ttn.net).

為了讓事情正常處理, 我將程式修改為 registrar@noc.ttn.net, 然後在 noc.ttn.net 設定 alias 給 samson.

Samson, 交給你了!!

 

我其實蠻喜歡東看西看的...

總花很多時間在網路上, 看看有甚麼新的東西, 譬如說, 看看 CPAN 上面有甚麼新的 Perl Module, 常常因為有些新的 Module, 讓我接觸到新的概念, 新的協定...雖然大部分時間, 這些新的東西在當下, 都沒甚麼用, 或說, 都用不到.  但是往往在以後的日子, 就會突然發現, 原來碰到的問題早在之前就有看過解法.

看雜誌也是, 以前有訂閱 Linux Journal, 每個月收到, 就會從第一篇看到最後一篇, 只不過有些會比較認真看, 有些則是帶過. 現在偶而還會把很久以前的 Linux Journal 當廁所文學, 坐在馬桶上翻翻. 有時, 也會有意外的驚喜.

其實網路的資訊真是太豐富了, 看看別人的想法, 常就會發現自己很貧乏, 所以平時一定要多練功

現在一堆 www.mawa.net.tw, mawa.net.tw (?), mawa.tw, www.mawa.tw 全都指到同一台機器, 之前沒問題, 但是因為把圖片顯示的切到 img.mw.net.tw, 所以改了 cookie 的 domain 是 .mw.net.tw, 反而造成如果用上面的 URL 連進麻蛙, 登入會失效.

因此重新設了 VirtualHost, 將以上所有的 URL 全部 External Redirect 到 www.mw.net.tw, 順便實驗, 以後要全部轉為 mawa.tw 時, 可不可以避免掉那些原先已經使用的 URL .

 

當初做貼紙的時候, 為了跟老闆殺價錢, 做了一百張, 心想, 會不會太多了...沒想到這幾天下來, 紅色的車貼只剩下沒幾張, 大概只有五張左右吧. 黑色的反而比較多, 二十張左右. 感謝大家的熱情, 麻蛙車貼居然有那麼多人要...今天早上還收到兩個蛙友寄來回郵信封, 真是讓麻蛙小工雀躍得大叫... 哈哈!!請拿到車貼的蛙友們, 不管貼在哪裡, 都照張像回來給大家看看吧.

剛開始弄網站, 應該是十年前幫莉翔做 Musical 的專輯開始吧. 那時候還是用 NCSA 的  Web Server, 所謂的 CGI 才剛定義出來 (?). 也是因為這樣我開始學 Perl.後來做了 Hello, Netvigator, 不過也比較著重在網站架構跟效能上, 從來沒去思考所謂的 UI, 畢竟這樣的東西都是給美工做的, 工程師哪需要管這個啊.不過, 因著 Julia 的介紹, 我借了她的書來看, 書名是 Don't Make Me Think, 副標是 A Common Sense Approach to Web Usability. 我開始恍然大悟, 原來麻蛙很難用的原因.其實剛開始看, 就很想把一些想法寫下來, 不過這陣子在忙著做新的控制台, 也正好印證一些書上的說法, 所以遲遲都沒動手.前天看到 Chapter 8: The farmer and the cowman, 突然感覺很強烈, 還是寫下來好. 至於前七章, 找時間再分享好了.所謂的 The farmer and the cowman 其實在對比於程式設計, 網頁設計, 行銷...等等不同的腳色. 通常在網站設計時, 這些人的很多想法都是衝突的, 而大家都會以 "我也是個使用者" 的角色來說 "大部分的人會喜歡 xxx" 或是 "大部分人不會喜歡 xxx". 實際上呢? 事情沒有那麼簡單, 沒有甚麼東西是大部分人都喜歡或是大部分人都不喜歡這回事. 所以這樣的爭論其實沒有答案, 因此也就沒甚麼意義.反而需要考慮的是, 這樣的東西在這個頁面, 對於這個人有沒有用, 如果沒有用, 有沒有其他的選擇...工程師喜歡簡單明瞭, 新奇功能的東西, 設計師則喜歡視覺絢爛的東西, 本來就不一樣, 老闆跟行銷的要求也各不相同. 因此網站設計必須要回到使用者本身去思考. 問題是, 使用者有那麼多, 千百種, 每個人的想法又不相同, 那怎麼辦?Chapter 8 還沒看完, 所以我也沒答案 :)