皮フ炎
かぶれ
じんましん
虫さされ
しっしん
ただれ
あせも
しもやけ
痒み
皮フ炎
被れ
蕁麻疹
虫さされ
湿疹
爛れ
汗疹
霜焼
發癢
皮膚炎
皮膚中毒
蕁麻疹
蟲刺傷
濕疹
爛瘡
痱子
凍傷
2009年8月17日 星期一
2009.8.17 商業周刊／政府救災的5大荒謬
商業周刊／政府救災的5大荒謬
「天災總是在人們遺忘時降臨。」這是日本天災防治專家寺田寅彥的名言。誰也沒料到，一個原被認為平平無奇的中度颱風莫拉克，竟會釀成台灣五十年來最慘重的水災。颱風既是台灣不可避免的天災，如何才能避免悲劇重演？
荒謬一：以為告知就盡到責任 事前測到降雨量，卻未強制撤離
這次從馬英九總統到地方縣市首長，都指責中央氣象局雨量預測有誤，彷彿只要預測準了就不會釀成災害。真的如此嗎？事實上，在颱風來臨前的八月六日，氣象局就已預估中南部山區會有八百毫米的降雨量。在颱風來臨當天的八月八日上午，氣象局更把屏東等地的降雨量上修到兩千毫米。
然而，除了事前農委會發布的土石流警戒、以及在七日下午「建議」包括高雄縣甲仙鄉小林等五個村「提早疏散」外，幾乎沒看到中央或地方政府事先撤離 可能受災居民。彷彿只要政府有「告知」民眾要注意，責任就完了。殊不知在重大災害發生前，必要時「強迫」民眾事先撤離，也是政府的責任。何況政府花更大資 源事後救災，將間接排擠日後的施政資源。
荒謬二：全靠媒體發現災情 一一九打不通，打電視台才得救
救災資源有限，「取捨」救災的優先順序是關鍵，政府應優先掌握並分析災情資訊，進而研判資源如何配置，但這非地方縣市能力所及，只有中央才能掌握 整個災情的「面」。但這次水災，幾乎看不到中央災害應變中心有此優先順序概念，而是一股腦的跟著媒體的SNG現場報導打轉，這種對全面災情資訊掌握的不 足，充分反映在行政院長在災害應變中心時，對各救災單位所說：「所有中央與地方的溝通，一律透過媒體。」
媒體的報導有其選擇性，掌握的是片面的資訊「點」，甚少從「面」的角度即時報導最需要救援的災區，如果只靠媒體來溝通，再據此資訊分配資源，豈不 容易誤事？再退一步說，就算氣象局事前預報不準，在實際降雨一至兩個小時後，也應該知道真正的大雨落在哪裡，這時中央就應發布警戒、撤離居民，或調派機具 去搶救。
但實際的情況卻是，水開始淹了，民眾打電話求救，地方政府得知後再通報中央，中央才開始派人搶救，而有的民眾一一九、一一○都打不進去，媒體曝光後才有官員注意去搶救。這種救災指揮模式，毫無章法，極可能耽誤最需要救援民眾的可能。
荒謬三：救災中心沒人在管 大官只顧勘災，卻忘了指揮救災
此外，這次救災行動不盡人意，關鍵在於最高主事者未能全盤掌握災情資訊，沒有負起協調各部會、調集資源救災的重責大任，反而是四處奔波去勘災。那 麼地方縣市政府何用？調派資源的決策又該誰來做？總統與其花時間去第一線災區聽取民意，還不如從長遠思考究竟如何讓救災體系更完善，對民眾的幫助更大。
荒謬四：救災行動邊做邊學 人員年年換，靠電視台call in溝通
再者，每次天災發生，中央成立的災害應變中心都是各部會臨時組成，天災過後「各自解散」，明年天災再來，各部會再「集合一次」，但參與人員早因人 事異動而換人。如此組合，能夠記取前車之鑑嗎？高度如馬總統，是否更應花時間去思考一個更有效的災害應變流程，讓經驗可傳承，而不是每次救災都像「邊做邊 學」？
荒謬五：救援人力始終有限 科技進步，還是得付出巨大代價
每次碰到天災，民眾大多苦等政府救援，但當救援姍姍來遲，就痛批政府救災不力，殊不知政府的能力本來有限，如果我們有此意識，事前多點防災準備，或許能為自己多爭取一段存活生機。
同樣每年面臨颱風侵襲的日本，其商店就有專賣「防災用品專用包」，裡面有十八種至二十種一般人可用的救災用品，包括簡易燈、急救護理包、食用水 等，廠商宣稱有此救助包可讓一般人在孤立無援下多活一到兩天。即便台灣還無此產品，但我們似乎可自力救濟，颱風來襲前，事先準備飲食、飲水，這樣即使斷水 斷電，還可應急，等到救援到來。
二○○九年八月八日，莫拉克颱風重創台灣，距離一九五九年的八七水災正好五十年。五十年後的今天，台灣人均所得已比過去成長了數十倍，科技也進步到能預測到颱風的路徑。面對同樣的天災，我們還是付出了和以往一樣巨大代價。那麼，下次呢？
「天災總是在人們遺忘時降臨。」這是日本天災防治專家寺田寅彥的名言。誰也沒料到，一個原被認為平平無奇的中度颱風莫拉克，竟會釀成台灣五十年來最慘重的水災。颱風既是台灣不可避免的天災，如何才能避免悲劇重演？
荒謬一：以為告知就盡到責任 事前測到降雨量，卻未強制撤離
這次從馬英九總統到地方縣市首長，都指責中央氣象局雨量預測有誤，彷彿只要預測準了就不會釀成災害。真的如此嗎？事實上，在颱風來臨前的八月六日，氣象局就已預估中南部山區會有八百毫米的降雨量。在颱風來臨當天的八月八日上午，氣象局更把屏東等地的降雨量上修到兩千毫米。
然而，除了事前農委會發布的土石流警戒、以及在七日下午「建議」包括高雄縣甲仙鄉小林等五個村「提早疏散」外，幾乎沒看到中央或地方政府事先撤離 可能受災居民。彷彿只要政府有「告知」民眾要注意，責任就完了。殊不知在重大災害發生前，必要時「強迫」民眾事先撤離，也是政府的責任。何況政府花更大資 源事後救災，將間接排擠日後的施政資源。
荒謬二：全靠媒體發現災情 一一九打不通，打電視台才得救
救災資源有限，「取捨」救災的優先順序是關鍵，政府應優先掌握並分析災情資訊，進而研判資源如何配置，但這非地方縣市能力所及，只有中央才能掌握 整個災情的「面」。但這次水災，幾乎看不到中央災害應變中心有此優先順序概念，而是一股腦的跟著媒體的SNG現場報導打轉，這種對全面災情資訊掌握的不 足，充分反映在行政院長在災害應變中心時，對各救災單位所說：「所有中央與地方的溝通，一律透過媒體。」
媒體的報導有其選擇性，掌握的是片面的資訊「點」，甚少從「面」的角度即時報導最需要救援的災區，如果只靠媒體來溝通，再據此資訊分配資源，豈不 容易誤事？再退一步說，就算氣象局事前預報不準，在實際降雨一至兩個小時後，也應該知道真正的大雨落在哪裡，這時中央就應發布警戒、撤離居民，或調派機具 去搶救。
但實際的情況卻是，水開始淹了，民眾打電話求救，地方政府得知後再通報中央，中央才開始派人搶救，而有的民眾一一九、一一○都打不進去，媒體曝光後才有官員注意去搶救。這種救災指揮模式，毫無章法，極可能耽誤最需要救援民眾的可能。
荒謬三：救災中心沒人在管 大官只顧勘災，卻忘了指揮救災
此外，這次救災行動不盡人意，關鍵在於最高主事者未能全盤掌握災情資訊，沒有負起協調各部會、調集資源救災的重責大任，反而是四處奔波去勘災。那 麼地方縣市政府何用？調派資源的決策又該誰來做？總統與其花時間去第一線災區聽取民意，還不如從長遠思考究竟如何讓救災體系更完善，對民眾的幫助更大。
荒謬四：救災行動邊做邊學 人員年年換，靠電視台call in溝通
再者，每次天災發生，中央成立的災害應變中心都是各部會臨時組成，天災過後「各自解散」，明年天災再來，各部會再「集合一次」，但參與人員早因人 事異動而換人。如此組合，能夠記取前車之鑑嗎？高度如馬總統，是否更應花時間去思考一個更有效的災害應變流程，讓經驗可傳承，而不是每次救災都像「邊做邊 學」？
荒謬五：救援人力始終有限 科技進步，還是得付出巨大代價
每次碰到天災，民眾大多苦等政府救援，但當救援姍姍來遲，就痛批政府救災不力，殊不知政府的能力本來有限，如果我們有此意識，事前多點防災準備，或許能為自己多爭取一段存活生機。
同樣每年面臨颱風侵襲的日本，其商店就有專賣「防災用品專用包」，裡面有十八種至二十種一般人可用的救災用品，包括簡易燈、急救護理包、食用水 等，廠商宣稱有此救助包可讓一般人在孤立無援下多活一到兩天。即便台灣還無此產品，但我們似乎可自力救濟，颱風來襲前，事先準備飲食、飲水，這樣即使斷水 斷電，還可應急，等到救援到來。
二○○九年八月八日，莫拉克颱風重創台灣，距離一九五九年的八七水災正好五十年。五十年後的今天，台灣人均所得已比過去成長了數十倍，科技也進步到能預測到颱風的路徑。面對同樣的天災，我們還是付出了和以往一樣巨大代價。那麼，下次呢？
2009.8.17 PIX/ASA flags
轉載自Cisco's PIX/ASA TCP flags syntax
Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,
B - initial SYN from outside, C - CTIQBE media, D - DNS, d - dump,
E - outside back connection, F - outside FIN, f - inside FIN,
G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,
i - incomplete, J - GTP, j - GTP data, K - GTP t3-response
k - Skinny media, M - SMTP data, m - SIP media, O - outbound data,
P - inside back connection, q - SQL*Net data, R - outside acknowledged FIN,
R - UDP SUNRPC, r - inside acknowledged FIN, S - awaiting inside SYN,
s - awaiting outside SYN, T - SIP, t - SIP transient, U - up
inside Client to Outside Server: UIO
Outside Client to Inside Server: UIOB
UFRIO
Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,B - initial SYN from outside, C - CTIQBE media, D - DNS, d - dump,
E - outside back connection, F - outside FIN, f - inside FIN,
G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,
i - incomplete, J - GTP, j - GTP data, K - GTP t3-response
k - Skinny media, M - SMTP data, m - SIP media, O - outbound data,
P - inside back connection, q - SQL*Net data, R - outside acknowledged FIN,
R - UDP SUNRPC, r - inside acknowledged FIN, S - awaiting inside SYN,
s - awaiting outside SYN, T - SIP, t - SIP transient, U - up
inside Client to Outside Server: UIO
Outside Client to Inside Server: UIOB
UFRIO
2009.8.17 PIX/ASA 開traceroute
In the outside-in access-list (acl_out), make sure that the following
entries are present:
access-list acl_out permit icmp any any time-exceeded
access-list acl_out permit icmp any any unreachable
access-list acl_out permit icmp any any echo
access-list acl_out permit icmp any any echo-reply
I've seen the question asked hundreds of times, and since I finally
found how to do it without allowing ALL icmp, I thought I'd share.
Hope it helps!
-J Keegan
j keegan at ctny dot net
entries are present:
access-list acl_out permit icmp any any time-exceeded
access-list acl_out permit icmp any any unreachable
access-list acl_out permit icmp any any echo
access-list acl_out permit icmp any any echo-reply
I've seen the question asked hundreds of times, and since I finally
found how to do it without allowing ALL icmp, I thought I'd share.
Hope it helps!
-J Keegan
j keegan at ctny dot net
2009.8.17 Host flapping 02:01:00:00:00:00 & Microsoft NLB service
參考自 supportwiki.cisco.com
- The host is connected to ports x/y, and x/y runs a type of clustering or redundancy and has an issue with this mechanism.
If the MAC address specified in the error message can be traced, this is likely the issue. For an example, refer to this error message:
%C4K_EBM-4-HOSTFLAPPING: Host 02:01:00:00:00:00 in vlan x is flapping between port Gi x/y and port Gi x/y
The MAC address 02:01:00:00:00:00 appears to be associated to Microsoft's Network Load Balancing (NLB) Service Heartbeat. It is suggested that the connected device (Microsoft host) be checked for causing these messages.
訂閱：
文章 (Atom)