2009.8.12 八八水災

8/7是莫拉克颱風關係,放假一天
8/8傳出南部水災.
雨量太大,南部多處地方相繼發生水災及土石流等.

非常非常慘.
我看到新聞畫面時,都掉眼淚了!
許許多多的家庭已無家可歸, 或妻離子散, 太可憐了!

這幾天我們家有收到退稅的款項, 我今日拿2000元出來捐給慈濟, 請慈濟繼續follow!

2009.8.10 尚恩的第三節游泳課

尚恩在培恩的第二個禮拜開始, 而今天是第三節的游泳課.
晚上碰面時,趕緊問尚恩今天游泳課教了什麼內容. 我以前沒上過游泳課, 另要讓尚恩回憶, 所以問了許多事.
尚恩這次肯回答了, 說學了水上漂, 肚子上放浮板, 抱住浮板, 眼睛看上面, 這樣就可以浮起來了.
還有學殭屍跳, 學憋氣等....

2009.8.10 Passive FTP and Active FTP

Passive FTP與Active FTP模式有何不同?
參考來源Active FTP vs. Passive FTP, a Definitive Explanation

簡明扼要的解釋是:
Active FTP: Ftp server會主動用自己的port 20去連線到Ftp client的port N+1
Passive FTP: Ftp server是被動的讓ftp client來連線到data port(非port 20)

2009.8.10 不同OS的Traceroute動作是不同的!

Cisco IOS/Linux 與 Microsoft Windows traceroute的動作是不同的.

簡單是這樣分:
windows -> tracert -> icmp
linux -> traceroute -> udp

仔細分是這樣:
共同的部分是一樣都是讓TTL隨著hop count的增加而遞增, 中間的點(TTL等於0的那一點)都會送icmp time exceeded(type=11 code=0)的 error message 回給送端.
但在實做時:
Cisco IOS and Linux
使用UDP封包. 目的地的udp port一開始是33434(但每多送一次,會遞增), 而source udp是亂數(不過是與0x8000做過OR後的亂數).
在中間的hop(還未到目的地的點),每當TTL到zero時, probe會送icmp time exceeded(type=11 code=0)的 error message 回給送端
一直到目的端時, 目的地端會回送icmp Port Unreachable(icmp type=3 code=3)error message給送端.
Microsoft Windows
此種OS就不是使用UDP封包, 而是用ICMP echo request與TTL. 而目的地端就不是用ICMP unreachable類型的封包回, 而是用ICMP echo reply回.

請參考Cisco Using the traceroute Command on Operating Systems

2009.8.10 家裡的電話及ADSL故障

家裡電話及ADSL從上禮拜四就故障, 也報修了, 而剛好又遇到莫拉克颱風, 所以還沒修好,可以體諒!
於是這次休三天在家, 都無法上網, 幸好也沒有公事是需要上網處理!
希望今天下班後, 已修理完畢!

2009.8.10 老爸問4次,兒子問21次的What is that?

我看影片後, 掉了眼淚..., 因為太感動了!
我的小孩一個七歲(暑假中,正要升小一), 另一個五歲,正在念中班.
大的正是迷惑之年, 常常在問我那是甚麼, 或是甚麼是甚麼.
而我總是非常有耐心,非常和藹可親的解釋
但如果是媽媽問我, 有時連一次的回答都不想回答........

值得深思--有一天我們也會老

影片內容概要：

一個老父親問兒子4次"那是甚麼?"，兒子回答4次"麻雀"後大發雷霆。

父親進家裡拿出自己的日記叫兒子念一段：

「...幾天前小兒子跟我在公園，

他問了我21次"那是甚麼?"，我回答了21次"麻雀"，

每一次都是緊抱著他，慈愛的回答我那純真的小孩...」

2009.8.6 SOL10328: Forcing a file system check on the next system reboot

SOL10328: Forcing a file system check on the next system reboot

---

Updated: 7/23/09 7:43 AM

The fsck utility is used to scan the file system for errors, and to correct those errors if possible. In order to correct errors, the file systems must be unmounted. Performing a file system check using the fsck utility can be a tedious manual process requiring the user to reboot the system to a minimal run level and then issue an fsck on each file system listed in the /etc/mtab file. This method requires direct access to the system in order to access and run the fsck utility.

A more convenient method is to force a file system check on the next system reboot. This method removes the tedious manual process, and allows the system to check all of the available file systems.

Important: F5 Networks recommends that you have direct access to the system during a forcefsck so that you are able to observe any errors or information that may be reported during the fsck process. While this method removes the manual process of specifying the various file systems, the system reboots into a minimal run level to perform the necessary tasks.

The following two methods can be used to force a file system check on the next reboot:

• Creating a forcefsck file in the root directory

  This method allows you to schedule a file system check at the next reboot by creating a blank file called forcefsck that resides in the / directory. When the system is rebooted, it will read this file and begin checking the file systems.

• Forcing a file system check using the shutdown command

  This method allows you to reboot the system immediately and perform a forced file system check using the shutdown command. When the command is issued, the system reboots and begins checking the file systems.

Creating a forcefsck file in the root directory

To create a forcefsck file in the root directory, perform the following procedure:

1. Log in to the command line.
2. To create the forcefsck file, type the following command:
   

   touch /forcefsck

3. Leave the file in place. A file system check is automatically run the next time the system reboots.

Forcing a file system check using the shutdown command

1. Log in to the command line.
2. To restart the BIG-IP and force a file system check, type the following command:
   shutdown -rF now

Once the fsck has finished checking the file systems, the system will continue to boot normally into the proper run levels.

2009.8.6 SOL7036: The Linux uptime counter wraps after 497 days

SOL7036: The Linux uptime counter wraps after 497 days

---

Known Issue
Updated: 7/21/09 11:05 AM

This is the result of a known issue, which was discovered in 1998 and still exists in the Linux 2.4 kernel. The kernel computes the system uptime based on the internal jiffies counter, which counts the time since boot in units of 10 milliseconds, or jiffies. The counter is a 32-bit counter, which has a maximum value of 2^32, or 4,294,967,296. When the counter reaches this value (after 497 days, 2 hours, 27 minutes, and 53 seconds, or approximately 16 months), it wraps back around to zero and continues to increment.

F5 Networks Product Development is tracking this Linux issue as CR74550. Currently, no Linux kernel patch is available to resolve this issue.

When the counter wraps, the following side effects may be observed:

• The ps (Process Status) command may report incorrect TIME values for daemons that were running at the time of the counter wrap
• Some processes that depend on accurate elapsed time calculations may be adversely affected, as detailed in the following Solutions:

SOL7071: SCCP kernel driver i2c read failure

SOL8087: SCCP kernel driver timer wrap may cause system component health misreadings (FirePass only)

SOL9679: The lacpd daemon stops sending LACP messages after 497 day linux uptime wraparound

SOL9683: The gtmd, tmm, or bcm56xxd daemons may crash after 497 day linux uptime wraparound

SOL10311: The performance graphs no longer display data after 497 day linux uptime wraparound

Note: These are the only known side effects of the uptime counter wrapping. The issues documented in these Solutions have been patched as noted therein. If you encounter issues that seem related but are not documented here, contact F5 Networks Technical Support.

Workaround

You can work around most issues created by the wrapping of the uptime counter by rebooting the system. In some cases, further remedial steps may be necessary. Refer to the solutions above for specifics.

You can avoid this issue by rebooting the system prior to the 497 day counter wrap. To determine how long the system has been up, use the Linux uptime command. The uptime command produces output that appears similar to the following example:

19:52:48 up 20 days, 9:24, 1 user, load average: 0.09, 0.05, 0.11

2009.8.6 Cat 3750 Stack function

2009.8.6 Cat 3750 Stack function
Cat 3750在有Stack功能之下的升級方式,請參閱Catalyst 3750 Software Upgrade in a Stack Configuration with Use of the Command-Line Interface
Cat3750設定Stack功能方式:Managing Switch Stacks or Creation and Management of Catalyst 3750 Switch Stacks
Cat3750當有cross-stack功能在時,要如何設定EtherChannel,請看Cross-Stack EtherChannel on a Catalyst 3750 Switch Configuration Example

喔, 要這樣收集相關文件,資訊等,蠻累的耶!

2009.8.5 台語俗語[阿婆踉港]意思與典故

阿婆踉港這俗語不陌生, 但由來一直不曉得. 一直到昨晚看一台節目, 主持人就解釋了阿婆踉港的由來. 今早起床後,忘記了由來的前半段,只記得後半段, 於是Google又發揮了價值, 把來由找出來了.
以下文來自於儒林戲語部落格

『阿婆踉港』這句俗語，為什麼說是最[正港]的台灣話呢？這是有歷史典故的。中日甲午戰爭滿清戰敗，1895年簽訂[馬關條約]將台灣割讓給日本，日軍由台北澳底登陸，由前清官出任的「台灣民主國」總統唐景松卻不戰而逃，以喬裝老太婆從滬尾港[今淡水港]，潛逃回大陸。留下台灣義勇軍與日軍做殊死激戰，戰死的台灣義勇軍，估計達一萬四千人以上。因此才有這句『阿婆踉港』俗語產生。形容見情勢不對有狀況時，自己先開溜，趕快逃跑的意思。因此，[跤踏台灣地，頭戴台灣天]的台灣人，要知道這段悲慘的台灣史。