配置vsftpd服務

配置vsftpd服務:Linux是壹種開源的而且安全的操作系統,已經深入人心。作為Linux的壹種流行發行版本,Ubuntu的使用更為普及。vsftpd作為Linux下壹種最為方便的FTP程序,也為人們所推崇。本文講述的是如何配置vsftpd服務
    服務的啟動與停止
    啟動服務之前,我們先編輯配置文件/etc/vsftpd.conf. 打開配置文件後可以看到許多以“#”開始的行,這些行都是註釋行,大多是幫助信息,可以仔細閱讀。vsftpd.conf文件的所有項目都是以“參數=值 ”來設置的,對格式要求比較嚴格,必須嚴格區分大小寫,等號兩邊不能有空格,每行的最後也不能有空格。每個參數都有壹個默認值,沒有在配置文件中明確指定的參數就會使用默認值。我們這裏不理會配置文件本來的信息,把所有內容都刪掉或註釋掉,最後加上下面四行,每行右邊的//及後的文字是含義說明,不要輸入到文件中:
    1.listen=yes //vsftpd工作在standalone 模式下  2. 3.anonymous_enable=yes //允許匿名用戶登陸服務器  4. 5.local_enable=yes //允許本地用戶登錄到服務器  6. 7.pam_service_name=vsftpd //使用PAM認證  8. vsftpd有兩種工作模式,standalone模式和xinetd守護進程模式,第1行就是讓其工作在standalone模式下。此種模式中,每次修改配置文件必須重新啟動vsftpd服務才能生效,關於兩種模式在後面有詳細介紹。我們安裝時還把 Redhat 目錄下的 vsftpd.pam 文件復制成了/etc/pam.d/vsftpd 文件。這個文件就是本地用戶登陸的 pam 驗證配置文件。關於這個文件我們會在後面具體介紹。這裏我們要知道,必須得有這個配置文件,而且主配置文件裏要加上 pam_service_name=vsftpd語句,我們才能讓本地用戶登陸。用以下命令啟動服務:
    1.[root@redhat vsftpd-2.3.2]# /usr/local/sbin/vsftpd & //後臺啟動vsftp  2. 我們可以通過pgrep vsftpd 來查看vsftpd服務器是否運行起來;
    1.[root@redhat vsftpd-2.3.2]# pgrep vsftpd  2. 3.4248  4. 上面顯示vsFTPd服務器運行起來了,您可以通過ftp命令、lftp工具或gftp或其它的FTP客戶端來測試連接;
    為保證服務確實啟動,我們用如下命令檢測:
    1.[root@redhat vsftpd-2.3.2]# netstat -an |grep 21  2. 3.tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN  4. 我們看到服務器已經打開了tcp21端口,表明ftp確實已經啟動。再登錄服務器:
    1.[root@redhat vsftpd-2.3.2]# ftp 127.0.0.1  2. 3.Connected to 127.0.0.1.  4. 5.220 (vsFTPd 2.0.5)  6. 7.530 Please login with USER and PASS.  8. 9.530 Please login with USER and PASS.  10. 11.KERBEROS_V4 rejected as an authentication type  12. 13.Name (127.0.0.1:root): ftp  14. 15.331 Please specify the password.  16. 17.Password:  18. 19.230 Login successful.  20. 這時我們已經用匿名用戶(用戶名ftp或anonymous,密碼任意)登錄到服務器了,還可以用本地用戶登錄。我們做測試時建議使用如上所示的ftp命令(windows、Linux及Unix都帶這個命令,用法都是壹樣的)來登錄服務器,這樣可以看到更詳細的信息,對於我們調試服務器是非常有幫助的。最簡單的ftp服務器就已經達建起來了。
    使用如下命令關閉ftp服務:
    1.[root@redhat vsftpd-2.3.2]# killall vsftpd //或是 pkill vsftpd  2. 3.[root@redhat vsftpd-2.3.2]# pgrep vsftpd //查看vsftpd服務器是否已經關閉  4. 開機自啟動
    用vi打開etc/rc.local在裏面加入/usr/local/bin/vsftpd & 即可。

物理standby failover

操作系統:red hat enterprise 5
    ORACLE:  11.2.0.1.0
    ORACLE-DataGuard系列文檔初始測試環境(單實例物理standby):
    http://xin23.blog.51cto.com/1827266/504066
    每次實驗環境均基於上次實驗改變之後。如有需要。可按時間先後順序查看。
    1.檢查歸檔文件是否連續
    SQL> select * from v$archive_gap;
    no rows selected
    如果有返回記錄。復制相應歸檔文件到待轉換的standby服務器。
    並通過alter database register physical logfile ‘arcfile’ 命令將其加入數據字典
    2.檢查歸檔文件是否完整
    primary> select distinct thread#,max(sequence#) over(partition by thread#) max from v$archived_log;
    THREAD#        MAX
    ———- ———-
    1         78
    standby> select distinct thread#,max(sequence#) over(partition by thread#) max from v$archived_log;
    THREAD#        MAX
    ———- ———-
    1         77
    如果最大序號不同。則需要將對應歸檔文件復制到待轉換的standby服務器。
    由於是測試。我直接通過primary發送歸檔文件後重新檢查
    standby> select distinct thread#,max(sequence#) over(partition by thread#) max from v$archived_log;
    THREAD#        MAX
    ———- ———-
    1         78
    這就OK了。
    3.啟動failover
    standby> alter database recover managed standby database finish force;
    Database altered.
    4.切換物理standby角色為primary
    standby> alter database commit to switchover to primary;
    Database altered.
    5.啟動新的primary數據庫
    standby> alter database open;
    Database altered.

YUV格式詳細解釋與FFMPEG的關系

YUV主要的采樣格式
    主要的采樣格式有YCbCr 4:2:0、YCbCr 4:2:2、YCbCr 4:1:1和 YCbCr 4:4:4。其中YCbCr 4:1:1 比較常用,其含義為:每個點保存壹個 8bit 的亮度值(也就是Y值), 每 2×2 個點保存壹個 Cr 和Cb 值, 圖像在肉眼中的感覺不會起太大的變化。所以, 原來用 RGB(R,G,B 都是 8bit unsigned) 模型, 4 個點需要 8×3=24 bites(如下圖第壹個圖)。 而現在僅需要 8+(8/4)+(8/4)=12bites, 平均每個點占12bites(如下圖第二個圖)。這樣就把圖像的數據壓縮了壹半。
    上邊僅給出了理論上的示例,在實際數據存儲中是有可能是不同的,下面給出幾種具體的存儲形式:
    (1)    YUV 4:4:4
    YUV三個信道的抽樣率相同,因此在生成的圖像裏,每個象素的三個分量信息完整(每個分量通常8比特),經過8比特量化之後,未經壓縮的每個像素占用3個字節。
    下面的四個像素為: [Y0 U0 V0] [Y1 U1 V1] [Y2 U2 V2] [Y3 U3 V3]
    存放的碼流為: Y0 U0 V0 Y1 U1 V1 Y2 U2 V2 Y3 U3 V3
    (2)   YUV 4:2:2
    每個色差信道的抽樣率是亮度信道的壹半,所以水平方向的色度抽樣率只是4:4:4的壹半。對非壓縮的8比特量化的圖像來說,每個由兩個水平方向相鄰的像素組成的宏像素需要占用4字節內存。
    下面的四個像素為: [Y0 U0 V0] [Y1 U1 V1] [Y2 U2 V2] [Y3 U3 V3]
    存放的碼流為: Y0 U0 Y1 V1 Y2 U2 Y3 V3
    映射出像素點為:[Y0 U0 V1] [Y1 U0 V1] [Y2 U2 V3] [Y3 U2 V3]
    (3)   YUV 4:1:1
    4:1:1的色度抽樣,是在水平方向上對色度進行4:1抽樣。對於低端用戶和消費類產品這仍然是可以接受的。對非壓縮的8比特量化的視頻來說,每個由4個水平方向相鄰的像素組成的宏像素需要占用6字節內存
    下面的四個像素為: [Y0 U0 V0] [Y1 U1 V1] [Y2 U2 V2] [Y3 U3 V3]
    存放的碼流為: Y0 U0 Y1 Y2 V2 Y3
    映射出像素點為:[Y0 U0 V2] [Y1 U0 V2] [Y2 U0 V2] [Y3 U0 V2]
    (4)YUV4:2:0
    4:2:0並不意味著只有Y,Cb而沒有Cr分量。它指得是對每行掃描線來說,只有壹種色度分量以2:1的抽樣率存儲。進行隔行掃描,相鄰的掃描行存儲不同的色度分量,也就是說,如果壹行是4:2:0的話,下壹行就是4:0:2,再下壹行是4:2:0…以此類推。對每個色度分量來說,水平方向和豎直方向的抽樣率都是2:1,所以可以說色度的抽樣率是4:1。對非壓縮的8比特量化的視頻來說,每個由2×2個2行2列相鄰的像素組成的宏像素需要占用6字節內存。
    下面八個像素為:[Y0 U0 V0] [Y1 U1 V1] [Y2 U2 V2] [Y3 U3 V3]
    [Y5 U5 V5] [Y6 U6 V6] [Y7U7 V7] [Y8 U8 V8]
    存放的碼流為:Y0 U0 Y1 Y2 U2 Y3
    Y5 V5 Y6 Y7 V7 Y8
    映射出的像素點為:[Y0 U0 V5] [Y1 U0 V5] [Y2 U2 V7] [Y3 U2 V7]
    [Y5 U0 V5] [Y6 U0 V5] [Y7U2 V7] [Y8 U2 V7]
    對應AVPicture裏面有data[4]和linesize[4]其中data是壹個指向指針的指針(二級、二維指針),也就是指向視頻數據緩沖區的首地址,而data[0]~data[3]是壹級指針,可以用如下的圖來表示:
    data –>xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    ^                ^              ^
    |                |              |
    data[0]      data[1]         data[2]
    比如說,當pix_fmt=PIX_FMT_YUV420P時,data中的數據是按照YUV的格式存儲的,也就是:
    data –>YYYYYYYYYYYYYYUUUUUUUUUUUUUVVVVVVVVVVVV
    ^             ^            ^
    |             |            |
    data[0]    data[1]      data[2]
    linesize是指對應於每壹行的大小,為什麽需要這個變量,是因為在YUV格式和RGB格式時,每行的大小不壹定等於圖像的寬度,對於RGB格式輸出時,只有壹個通道(bgrbgrbgr……)可用,即linesize[0],和data[0],so RGB24 : data[0] = packet rgb//bgrbgrbgr……
    linesize[0] = width*3
    其他的如data[1][2][3]與linesize[1][2][3]無任何意義。
    而對於YUV格式輸出時,有三個通道可用,即data[0][1][2],與linesize[0][1][2],而yuv格式對於運動估計時,需要填充padding(right, bottom),故:
    linesize=width+padding size(16+16)。
    ///////////////////////////////////////////////////////////////////////////////////////
    case PIX_FMT_YUV420P:   case PIX_FMT_YUVJ420P:   case PIX_FMT_RGB555:    if (PIC_DIRECTION_0 == m_dwFilpPicDirection)    {     m_pYuvFrame->data [0] += m_pYuvFrame->linesize[0] *  m_pVCodecContext->height;     //因為是隔行掃描U與V只有高度的壹半     m_pYuvFrame->data [1] += m_pYuvFrame->linesize[1] *  m_pVCodecContext->height/2;     m_pYuvFrame->data [2] += m_pYuvFrame->linesize[2] *  m_pVCodecContext->height/2;     m_pYuvFrame->linesize[0] = -m_pYuvFrame->linesize[0];     m_pYuvFrame->linesize[1] = -m_pYuvFrame->linesize[1];     m_pYuvFrame->linesize[2] = -m_pYuvFrame->linesize[2];    }        break;   case PIX_FMT_YUVJ422P:   case PIX_FMT_YUV422P:   case PIX_FMT_YUYVJ422:   case PIX_FMT_YUV411P:   case PIX_FMT_YUYV422:      if (PIC_DIRECTION_0 == m_dwFilpPicDirection)    {     m_pYuvFrame->data [0] += m_pYuvFrame->linesize[0] *  m_pVCodecContext->height;     m_pYuvFrame->data [1] += m_pYuvFrame->linesize[1] *  m_pVCodecContext->height;     m_pYuvFrame->data [2] += m_pYuvFrame->linesize[2] *  m_pVCodecContext->height;     m_pYuvFrame->linesize[0] = -m_pYuvFrame->linesize[0];     m_pYuvFrame->linesize[1] = -m_pYuvFrame->linesize[1];     m_pYuvFrame->linesize[2] = -m_pYuvFrame->linesize[2];    }    break;   }在FFMPEG中轉換RGB時順便顛倒圖像的方向算法