之前經常拿來備份數據的企業郵箱滿了,而qq為了賺錢不讓企業郵箱擴容了,所以沒辦法,準備換成可自動擴容的qq郵箱。但發現一些大郵件無法收到,查看mail.log后發現發送超時。錯誤信息:
dsn=4.4.2, status=deferred (lost connection with mx3.qq.com[119.147.6.81] while sending message body

而用企業郵箱的時候從來沒有這個問題,排查了下,把postfix發送超時設長,無效,還是發送一分鐘后就超時,看來是qq的mail服務器設置了1分鐘超時,如果1分鐘內郵件發送不完就斷開連接。

    tracert了一下到兩個郵件服務器的路由,前若干跳都是一樣的,但后續設置了禁ping,無法得知具體路徑。

    看來我的機器到qq郵箱mail服務器速度比較慢,而到企業郵箱速度快,有可能是qq郵箱設置了速度限制之類的東東,只能給企業郵箱開自動轉發,把郵件中轉一下了。



Tags:

博客vps故障及恢復處理

[| 不指定 2012/07/22 23:06]
    周四上午查看博客統計的時候發現居然一個訪問量都沒有。由于監控沒有報警,所以心想統計壞了。

    中午的時候準備看看日志確認下,結果發現真的一個訪問都沒有。。蛋疼了,發現凌晨5點后一點日志都沒了,奇怪,心想網絡沒有斷,為啥呢,訪問了下頁面,發現數據庫掛掉了,無法更新。一查文件系統,原來只讀了。發ticket說磁盤壞了,正在更換。等了一個多小時沒好,等不及了,開始切換。

    剛準備好切換,機器down掉了,還好博客數據和程序都有備份,從代碼倉庫里check出來代碼。備份里恢復出來數據庫,恢復數據庫的時候有個插曲,由于是全量備份,所以導入的時候會把目標庫里的mysql庫等信息都覆蓋,會使目標數據庫錯亂,所幸沒有flush,于是把目標庫的備份重新覆蓋了下。

    然后dns切換,由于主dns掛掉,只有從dns服務器還能工作,手動修改了數據文件指向新機器。修改ttl為300s,以便切回的時候能快速切回。

    周五機器更換磁盤起來了,但是沒數據,客服說等磁盤寄回來后才知道數據能不能恢復。雖然自己有備份,但很多軟件配置沒備份,自己重新配比較麻煩。還是等數據。
   今天告訴我數據取出來了,給了個ftp取數據,搞到數據后恢復了一下環境,dns切換回來了。


    看來冷門數據也要做長周期備份了。
Tags:
    今天需要臨時展示一個樣例站點,上傳程序太麻煩,修改起來也不方便,而電信寬帶沒有公網ip,只能先在電腦上用ssh連接到服務器,在服務器開個端口映射到電腦上。

    運行了ssh -Ng -R "*:2222:*:3333" server

    發現在服務器端映射端口是成功了,但只是監聽在本地。改了半天也不行,百思不得其解。因為之前用過都是成功的。


    后來發現某些版本的sshd因為安全性考慮,默認只允許監聽在本地。

    需要在/etc/ssh/sshd_config里面加一句:
    GatewayPorts clientspecified


    即可
Tags: ,

lighttpd中CONST_STR_LEN的用法

[| 不指定 2012/07/05 19:49]
    今天遇到一個問題,在獲取http頭的時候怎么也獲取不到,手動core出來和gdb上去調試發現都是空的,應該是開了O2優化的緣故,于是在程序中打印http頭,正常。

    不得已,單步gdb進匹配函數里,發現一個四字符的key值長度被判定為8,很奇怪,查代碼原來是用了個CONST_STR_LEN來代替了本來應該填ptr, strlen(ptr)的位置。而CONST_STR_LEN是一個宏,內容為:x, x ? sizeof(x) - 1 : 0。顯然,如果傳一個指針進去的話,sizeof指針的結果是8(字節,x64),這個宏只能在內容是字符串常量的時候用,不可以用在指針上。當時用的時候看lighttpd代碼中一些地方用了這個宏,于是想當然認為到處都可用。。看來還是要注意一些。









Tags:
   最近研究了一下pptp vpn的插件編寫。剛開始的時候以為身份認證等信息是pptpd服務進程做的,后來看了代碼后發現并非如此,是在pppd那里做的,也就是ppp軟件包。

    下載了ppp源碼看了下,當前版本是2.4.5,項目居然在samba域名下,不知道這個跟samba有啥聯系。

    在代碼的pppd/plugins里面有一些插件,比如radius的,看了下源碼。大致了解了下思路:

    一個插件即是一個標準的動態鏈接庫。pppd使用dlopen()庫調用來加載。pppd使用plugin選項來加載插件,只有一個參數:插件文件名。如果指定的文件名沒有斜線,pppd會到/usr/lib/pppd/目前下面查找該文件,這里面version是pppd的版本,比如2.4.5。也可以設置全路徑,在使用自己編寫的插件時比較方便。

    插件可以做的事:
    使用add_options(),傳入option_t 。最后一項是NULL,跟lighttpd配置是一樣的。這個作用應該是時ppp支持相應配置。

    指定hook。pppd會在處理過程中調用各個鉤子。插件可以任意設置自己的過程到這些hook。
    
    插件可以用add_notifier消息回調。

引用

#include "pppd.h"
#include "chap-new.h"

char pppd_version[] = VERSION;


static int pppd_chap_check(void) {
        return 1;
}
static int pppd_chap_verify(char *user, char *ourname, int id, struct chap_digest_type *digest, unsigned char *challenge, unsigned char *response, char *message, int message_space) {
        if(digest->verify_response(id, user, "a", strlen("a"), challenge, response, message, message_space)) {
                return 1;
        } else {
                return 0;
        }
}

static int check_address_allowed(int addr) {
        return 1;
}
void plugin_init(void) {
        chap_check_hook = pppd_chap_check;
        chap_verify_hook = pppd_chap_verify;
        allowed_address_hook = check_address_allowed;
}


這是一個簡單的插件源碼,如果用戶密碼是a就通過。可以進行擴充就可以讓pppd支持多種不同的權限認證,并且可以支持各種計數操作。該插件支持chap認證,包括mschap,mschap-v2,chap方式,至于pap,由于安全性不行,不支持也無所謂。

    這里需要注意allowed_address_hook 需要實現,表示同意使用分配的該ip,沒有實現時會在注冊網絡時失敗。

    char pppd_version[]                  = VERSION;
    表示支持的ppp版本。

    plugin_init,就是插件被載入時執行的操作,執行hook注冊等等操作。

    chap_check_hook 表示該插件是否可以進行chap認證。
    chap_verify_hook 是身份認證的過程,一般使用digest->verify_response來進行校驗。

以下是一篇資料里貼出的函數及消息列表:
  
插件鉤子函數列表

int (*idle_time_hook)(struct ppp_idle *idlep);

idle_time_hook在這個連接第一次開始的時候被調用(比如,第一個網絡協議開始的時候),那之后被定時調用。在第一次調用的時候,idlep參數是NULL,返回值則是pppd檢查連接活躍前的秒數,或者0表示沒有超時。

在后來的調用中,idlep指令一個指向最包被發送、接收秒數的結構體。如果返回的值大于0,pppd會在再次檢查之前等一些的秒數。如果小于等于0,就是說該連接在不活躍的情況下應該被終結。



int (*holdoff_hook)(void);

當嘗試拌連接失敗或是連接被終結的時候,holdoff_hook被調用,persist或是demand選項被使用。它返回PPTP重新建立連接應該等待的秒數(0表示立即)。



int (*chap_check_hook)(void);

int (*chap_passwd_hook)(char *user, char *passwd);

int (*chap_auth_hook)(char *user, u_char *remmd, int remmd_len, chap_state *cstate);

這些hook被設計用來在插件里面替換常規的CHAP密碼處理過程(比如外部服務器的認證)。

chap_check_hook被調用來檢查對端是否有必要向我們認證其自身。如果返回1,pppd將詢問詢問其自身,否則返回0(如果該認證被要求了,在網絡協議協商之前pppd會退出或是終結當前連接)。如果返回-1,pppd將查找chap-secrets文件使用常規方式處理。



chap_passwd_hook決定pppd應該使用什么密碼來使用CHAP來向對端認證自身。user字符串使用’user’選項或者’name’選項、主機名進行初始化,有必須可以進行修改。這個鉤子只有當ppdp是客戶客戶端而非服務的時候被調用。passwd可以容納最多MAXSECRETLEN 字節。如果鉤子返回0,PPPD使用 *passwd,如果返回 -1,pppd認證失敗。



chap_auth_hook 鉤子確定由對應提供的CHAP挑戰響應是否有效。user指向一個包含對端提供用戶名的非NULL結束的字符串。remmd向向對端提供的響應,由remmd_len表示其長度 。cstate是PPTP維護的內部CHAP狀態結構體。chap_auth_hook應該返回CHAP_SUCCESS 或者CHAP_FAILURE。



int (*null_auth_hook)(struct wordlist **paddrs, struct wordlist **popts);

這個鉤子允許插件確定當請求的認證被對端拒絕的時候應該采取的策略。 如果返回0,連接被終結;1,連接被允許處理,這種情況下 *paddrs和*popts可像pap_auth_hook一樣被設置,以指定被允許的IP地址列表和任意擴展屬性。如果返回-1,pppd查找pap-secret文件按常規處理。

void (*ip_choose_hook)(u_int32_t *addrp);

該鉤子在IPCP協商開始的時候調用。它使得插件有機會設置對端的IP地址。地方應該保存在*addrp。如果*addrp里什么也沒有存儲的慶,pppd使用常規方式決定對端的地址。

int (*allowed_address_hook)(u_int32_t addr)

這個鉤子確認對端是否可以使用指定的IP地址。如果鉤子返回1,地址可以接受,返回0為拒絕。如果返回-1,將使用常規方式查找適當的選項和secrets文件來決定。

void (*snoop_recv_hook)(unsigned char *p, int len)

void (*snoop_send_hook)(unsigned char *p, int len)

這些鉤子在接受或是發送數據包的時候被調用。數據包在p里同,長度由 len表式。使得插件可以檢查pppd的會話。這些鉤子在實現L2TP的時候將會起到很大的作用。

可注冊的消息列表

插件可以使用notifier注冊自身,通過申明一個下面形式的過程:

void my_notify_proc(void *opaque, int arg);

然后使用適當的notifier,以下面形式調用來注冊這個過程。

add_notifier(&interesting_notifier, my_notify_proc, opaque);

add_notifier 中的’opaque’參數每次調用notifier的時候傳遞給my_notify_proc 。傳遞的’arg’參數決定于notifier一個nofify過程可以使用下面的方式從當前的notifier列表中被移除。

remove_notifier(&interesting_notifier, my_notify_proc, opaque);



下面是目前pppd實現的notifier列表。

pidchange 由其父進程在pppd已經forked并且子進程在繼續pppd’s處理時調用,比如pppd從其控制終端中分離出來的時候。參數就是這個子進程的pid。

phasechange 當pppd從一個階段操作轉移到另一個的時候調用。參數是新階段的編號。

exitnotify 在pppd退出前調用。參數是pppd退出的狀態。(比如exit()的參數)。

sigreceived 在收到信號的時候調用,存在于signal handle里面。參數是signal的編號。

ip_up_notifier 在IPCP發生的時候調用。

ip_down_notifier 在IPCP關閉的時候調用。

auth_up_notifier 在對端認證自身成功的時候調用。

link_down_notifier 在連接關閉的時候調用。




參考資料:http://liaoweiqiang.info/?p=411
Tags: ,
    前幾天百度開放云支持綁定自有域名了,在應用列表里有很明顯的綁定域名鏈接,點擊后會提示將要綁定的域名cname到應用主域名上,一般是*.duapp.com,然后點擊確定即可綁定成功。

    需要注意的一點是,一定要在域名設置生效后再點擊綁定按鈕,否則由于dns緩存問題,可能需要等待最長24小時才能成功。

    修改域名指向的過程也比較簡單,進入dns管理頁面(一般域名注冊商提供),添加cname記錄(如該條記錄已存在且不是cname記錄,則修改為cname記錄),目標設為應用主域名,點確認即可。盡量不要在設置成功前訪問或nslookup該域名,這樣會使域名生效時間延后,無法綁定后立即體驗效果。





Tags: ,
    買過一些空間,有時候有的朋友要放個小博客,于是就手動開通一些賬號和綁定域名給他們,但總是不太方便,很麻煩,于是就有搞一個面板來實現這個功能。
    現在使用最多的主機面板就是cpanel,而cpanel恰好有很多api。
    于是搞了一個面板,可以將一個普通的cpanel用戶賬號多人共享,互不干擾。這樣方便了主機合租和賬號分享。朋友們共享主機時不再需要購買多個主機或reseller賬號了。
    不過面板的賬戶間共享資源,所以隔離性上還是不如reseller賬號的。所以建議還是朋友或熟悉的人之間使用。

    項目地址:http://code.google.com/p/cp-share/
    本文地址:http://www.trreps.com/read/307
    第一版實現了域名,數據庫,ftp賬號的管理,功能和界面都比較簡陋。不過已經可以滿足基本的需求了。后續慢慢完善。

    附截圖一張:
點擊在新窗口中瀏覽此圖片


Tags:
    有一個問題,是在一個環境上的lighttpd一打日志就出core,很奇怪,看堆棧信息是出在mod_accesslog里,今天看了下,發現原來是試圖打印%i導致的。
    lighttpd支持在日志中打印請求頭中的字段,方法是%{key}i,這樣就能在請求頭中的key字段打印到日志里,打印referer等東西的時候比較方便。

    但如果直接寫%i的話,由于沒有指定key,導致NULL指針,lighttpd沒有校驗導致出core。

    恰好%I是打印請求長度,大寫I還是比較容易誤按成小寫的。所以有了這個問題



Tags: ,

redis的性能初測

[| 不指定 2012/06/12 12:13]
    最近準備用用redis,于是做了下性能測試,在一臺虛擬機上跑了下,發現add命令大概1s可以執行3-5w條,使用redis官方推薦的php客戶端:Predis ,使用pipe功能批量插入1w條數據的話大概要0.3-0.5s,感覺速度有些慢,仔細研究了下,發現時php庫在生成那個1w條的redis命令是非常慢,一個請求要耗費掉1s的cpu時間,實在是性能殺手,考慮后續使用c實現。







Tags:
    今天有同學希望將webserver與后端fcgi換成長連接以提高性能,于是在lighttpd里直接配置proxy-core.max-keep-alive-requests即可,為了做測試,后端只啟動了一個fcgi進程。然后發現了奇怪的問題,每隔幾個請求就會有一個非常非常慢的連接,需要等待10s左右。

    后來決定開strace看看,由于lighttpd配了多進程,不好搞,于是改成單worker,結果問題解決了。


    這樣問題就豁然開朗了,原來多個請求落到了不同的lighttpd工作進程上,而唯一的一個fcgi進程被處理第一個請求的worker起長連接占用了,結果導致其他lighttpd無法連接到后端。


    這是一個啟用長連接后比較隱蔽的坑,可能會導致各個webserver的worker進程間負載不一致。需要小心了。




Tags:
分頁: 4/33 第一頁 上頁 1 2 3 4 5 6 7 8 9 10 下頁 最后頁 [ 顯示模式: 摘要 | 列表 ]
一级a做爰片_免费一级特黄大片_日本一级特黄大片 <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>