Monday, November 15, 2010

poppassd + roundcube on FreeBSD

最近因為被roundcube的美貌所吸引,所以正在考慮是否拿它來當webmail。roundcube最大的特點就是: 相當美+相當陽春。

紀錄一下poppassd跟roundcube怎麼搭配,讓使用者可以在web介面上直接改密碼,而不需要登入freebsd系統.. roundcube的安裝部分就不介紹了,直接來poppassd的部分。

Environment:
OS: FreeBSD 8.1-RELEASE-p1
roundcube: 0.4.2
poppassd: 4.0_3

STEP1: Install poppassd

# cd /usr/ports/mail/poppassd/
# make install clean

By default, you can find the binary in /usr/local/libexec

STEP2: Startup setting

# man poppassd

Modify /etc/inetd.conf AND /etc/services AND /etc/syslog.conf as describe in the man page.

STEP3: Auto-start inetd when reboot
Modify /etc/rc.conf AND add:

# inetd

inetd_enable="YES"

STEP4: restart inetd

# /etc/rc.d/inetd restart

 

STEP5: Config roundcube plugin
Modify /usr/local/www/roundcube/plugins/password/config.inc.php

// Select a driver to use, see README for more driver name

$rcmail_config['password_driver'] = 'poppassd';

STEP6: Add roundcube plugin
Modify /usr/local/www/roundcube/config/main.inc.php

// List of active plugins (in plugins/ directory)
$rcmail_config['plugins'] = array('password');

STEP FINAL: Restart roundcube and apache

 

Ref:

  1. [FRESH ports] poppassd
  2. Poppassd – Installation and Management Guide
  3. roundcube wiki – plugins/password
Thursday, October 21, 2010

iSCSI target crash when selecting ‘Device’ node

OS: Windows Storage Server 2003 R2
iSCSI target version: 3.1.3412

如題,一個很久以前就注意到的問題,不過因為沒有急迫性,就一直不理他XD。這兩天因為要整理一些空間出來用,只好處理一下。

於是找到一篇HP論壇裡的討論串,裡面有人提到是微軟的一個更新造成的...

請找KB973507

這個更新是2009/8/11出來的,如果有人遇到同樣的問題,大概也是這個時點之後,把這個更新移除後重開機,iSCSI target就可以正常使用了~

另外也有一份文件提到:

Issue: Installing Microsoft security update KB973507 results in the Microsoft iSCSI Software Target not displaying
iSCSI target devices when the Devices node is selected in the iSCSI Target management console.

Ref:

  1. [HP IT Resource Center Forums] AiO 600 - problem with Microsoft iSCSI target snapin
  2. [pdf] HP StorageWorks P4000 Unified NAS Gateway Release Notes
Thursday, September 30, 2010

Oracle shutdown hangs: forgot the ‘immediate’ option

一個簡單的小問題,不過還滿常發生的=   =||

一般需要關閉資料庫時,都會下'shutdown immediate’指令,有了immediate選項,Oracle不需等待所有連線關閉。反之,若只有下'shutdown'指令,也就是'shutdown normal',Oracle就會等到所有連線都結束後才關閉,通常都關不下來... 這時候就算又開了新的連線想重下指令,都會收到類似"Not connected to Oracle"這類的訊息.. 這時候!!

可以另外開一個新連線這麼做:

SQL> conn sys as sysdba
輸入密碼:
連線至閒置的執行處理.
SQL> startup force
已啟動 ORACLE 執行處理.
……(資料庫已掛載./資料庫已開啟.)
SQL> shutdown immediate

這樣就可以成功的把資料庫關下來囉~

另一邊原本正在shutdown的視窗可能會看見如下過程:

SQL> shutdown
ORA-03113: 通訊通道上出現 EOF

SQL> ^F^D
SP2-0042: 未知的命令 "" - 此行的剩餘部份被略過不予處理

完工!

Thursday, September 16, 2010

office: 使用萬用字元進行尋找/取代作業

今天發現office的尋找功能還滿強大的,介紹一些使用萬用字元搜尋/取代的方法:首先最基本的就是要會打開「尋找及取代」的視窗XD,在「更多(M)>>」選項裡把「使用萬用字元(U)」選項給勾起來。

  • 尋找符合「HH:MM:SS」的時間格式: 最簡易且不嚴謹的寫法可以用「??:??:??」。「?」表示任何單一字元,所以如果你的文件裡有「AA:BB:CC」這樣的字串,它也會符合尋找目標,但卻不符合我們只想尋找時間格式的目的。所以可以改寫成「[0-9]{2}:[0-9]{2}:[0-9]{2}」,就是三組「[0-9]{2}」被兩個冒號隔開來,其中「[0-9]」表示0到9之間的其中一個數字,「{2}」表示前一個字元或運算式必須出現2次。所以利用三組「[0-9]{2}」與冒號就可以找出符合的格式。
  • 在找到的「HH:MM:SS」時間格式前後加上「*」: 這時候就要需要取代功能的搭配了。在取代的頁籤裡,「取代為」的表示式該怎麼寫呢? 我希望找到所有的符合的時間格式並在他前後加上星號,卻不希望更改了時間的值。一開始嘗試用「*[0-9]{2}:[0-9]{2}:[0-9]{2}*」,結果他就把所有時間格式整個直接取代成「*[0-9]{2}:[0-9]{2}:[0-9]{2}*」的字樣OTZ。正確做法應該是把尋找目標寫成「([0-9]{2}):([0-9]{2}):([0-9]{2})」, 取代寫成「*\1:\2:\3*」。「\1」, 「\2」, 「\3」依序代表尋找目標的三組括號裡的值! 這個技巧主要用在你真正的目的不是「取代」,而是利用尋找到的目標再做一些位置上的變化或像此處加上其他字元符號的應用。

以上兩個就是今天有用到的精隨啦~ 當然還有很多種變化,像是{2,}則表示前面的字元或運算式至少要出現2次,若是{2,4}就表示前面的字元或運算式須出現2-4次。另外在不使用萬用字元的情況下也可用「代碼」來尋找特殊的格式或字元:

  • 將空白行去除: 搜尋目標以「^p^p」表示(記得不必勾「使用萬用字元(U)」)。一個「^p」表示一個換行符號,兩個「^p^p」就會空一行,所以將「^p^p」取代為「^p」,就可以將空白行去掉了。

其他還有許多用法請參閱reference。

 

Ref:

  1. Office產品支援中心: 尋找及取代文字或其他項目
Wednesday, September 01, 2010

(ORA-01031) Cannot create/edit view with the owner of the schema

environment: enterprise linux + oracle11gr2

前情提要:
userA先生在9i的時代運作得相當正常,當然包含本篇所要探討的小小新建一個view的動作。升級到11g之後某天,卻發現userA再也無法在自己的schema下create view... 這麼小小一件事情都辦不到!!! 檢查了權限也跟9i時代完全相同(就是CONNECT, RESOURCE, UNLIMITED TABLESPACE這麼簡單,所以也沒把腦筋動到權限上),なんで??? 當時為了應急直接用dba帳號幫他處理掉了,今天又遇到一次,該是要面對的時候了..

一開始看到的都是在說"物件的權限需要直接grant給指定的人,不要透過角色(ROLE)來做"這件事情,因為在所有stroe procedures或PL/SQL block裡,角色權限是不會起作用的(All roles are disabled inside stored procedures.)等,不過這並不是我的情況..

無意間看到這篇文章在探討Oracle的Role包含了那些權限,才恍然大悟...

9ir2的CONNECT角色裡包含了"CREATE VIEW"的權限,但在11g裡,CONNECT的角色卻只剩下"CREATE SESSION"的權限... 就這麼簡單... 所以在11g要另外把CREATE VIEW的權限grant給userA先生,這樣就可以正常新建/修改view了... 就這樣orz

若要詳細列出角色所包含的權限,可使用以下查詢:

SQL> select * from ROLE_SYS_PRIVS where role='CONNECT';
(ROLE_SYS_PRIVS: 列出登入帳號所有擁的角色,及角色所包含的系統權限)

或者也可以這樣查:

SQL> select * from DBA_SYS_PRIVS where grantee='CONNECT';
(DBA_SYS_PRIVS: 列出所有user/role所擁有的系統權限)

Wednesday, August 25, 2010

Error: 5243: An inconsistency was detected during an internal operation.

Environment: WinServer2008 SP2+SQL Server 2008

昨天檢查SQL Server的時候在記錄檔裡看見一整串長相不凡的訊息... 大概長這樣:

ex_raise2: Exception raised, major=52, minor=43, state=8, severity=22, attempting to create symptom dump
Using 'dbghelp.dll' version '4.0.5'
***Stack Dump being sent to D:\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\LOG\SQLDump0001.txt
... (略)
錯誤: 5243,嚴重性: 22,狀態: 8。
An inconsistency was detected during an internal operation. Please contact technical support.

最明顯的訊息大概就最後兩行了吧... 另外一個dump file內容更是人類無法閱讀=   =,明顯是要給機器讀的。

先是找到這篇: M$技術支援, Article ID:828337: An assertion or Msg 7987 may occur when an operation is performed on an instance of SQL Server.
標題看起來不怎麼有關係,不過內容確實有一些蛛絲馬跡。最早在SQL Server2000執行SELECT或UPDATE之類的transact-SQL時,就可能會有3624的錯誤訊息,而同樣的錯誤在SQL Server2005, 2008則是錯誤5242或5243。

造成5242/5243錯誤的原因只有簡單一小行: The problem may occur if inconsistencies exist in the databases on the instance of SQL Server....
還好相當有良心的還有solution..

  1. On the instance of SQL Server where the failure occurred, run the DBCC CHECKDB Transact-SQL command on all the databases.
  2. If the DBCC CHECKDB Transact-SQL command reports errors that indicate database inconsistencies, resolve the errors.

哈哈哈(乾笑三聲)... 一點都沒有好人做到底,送佛送到西的精神XD,連CHECKDB都不認識請參閱這兒(2000)或這兒(2008)。

所以就找了時間針對SQL Server裡的每個資料庫跑了下面這串指令。

DBCC CHECKDB(‘DB_NAME’) WITH ALL_ERRORMSGS;

(如果資料庫真的相當龐大,建議加個PHYSICAL_ONLY選項..)
結果每個資料庫的檢查結果都正常@_@a.. 雖然是個好消息,不過還是滿令人錯愕的阿XD 資料庫不會平白無故地耍人吧OTZ,所以不死心又多看了幾篇文章,終於,Paul S. Randal先生(SQL Server MVP, 撰寫2005 DBCC CHECKDB的人,這篇文章最後有簡介)給了個比較讓人釋懷的說明。

基本上5242跟5243是一樣的錯誤,不過5242會明確指出資料庫的哪個地方出了問題,5243卻是不明原因,資料庫無法指出的錯誤所丟出來的。雖然記錄檔紀錄了相關的訊息,這中間有可能其他的維護作業重建了索引,currupt pages被釋放,所以事後跑checkdb就看不出有任何錯誤。

大致上就這樣囉~

Ref:

  1. Microsoft Support KB828337
  2. MSDN: DBCC CHECKDB (SQL Server2008)
  3. Corruption errors: Msg 5242, Level 22

Tags