saru.moe搬遷 -- MAIL!

這裡真的該改名回蚊子館了XDDD (?
難得想到來隨興塞一篇wwww
有時間&心情再來看要不要修好點wwwwww

saru.moe搬遷的事情整理?
這次主要大概就這個DNS放在cloudflare上吧
說真的cloudflare的DNS管理介面還蠻不錯的
而且DNS更新速度也很快www

不過這不太算重點(?
這次不同的就是自己搞了個比較完整的SMTP了
有兩個MX分別是
MX 10 mail.saru.moe
MX 20 mailbak.saru.moe

而mailbak.saru.moe本身不收信件
只做對mail.saru.moe的relay而已

而設定上的重點的話(這邊是postfix)
Primary(mail.saru.moe)本身沒太多重點
反正照常設定就行了

而Backup(mailbak.saru.moe)則有幾點要注意
relay_domains要加上(廢話
然後mydestination不能有要relay的domain
(不然會把信搶收去啦XD)
大概就這幾點吧OwO

被NTP Flooding啦OAO

又是久違了一篇了XDD
平常沒太多想打的就噗浪解決了wwww

3/3 - 增加正確設定
學校內也有幾台機器有同樣問題wwww
順便加上設定了www

純粹昨天在更新MariaDB
所以在跑Ports的更新時閒閒來看個使用量
(雖然也沒啥好看 就100%滿載的CPU啊wwww)

結果看到網路部分的用量就發現...
等下!!!!!!!!!!!!
誰來解釋一下這用量是哪招啊!!!!!!!!!!!!!!!!!!!
這持續的流量怎看都不對勁啊!!!!!!!!!
不過因為有點懶+看來用量也不是很可怕(5M算還好?)
所以就先丟著了wwww

今天看了看還是這流量......
絕對有問題!
所以就稍微看了下....
嗯.... 對某個IP有很可怕的流量
不重要... 再看看... 是udp... port... 123...
嗯.... 啊!
XXXX的 NTP忘了設定 啥都沒擋啊
趕快調了下設定重開NTPD
流量馬上掉了下來...

這比之前DNS被放大攻擊還嚇人
這是不間斷的狂耗流量啊......

真的是任何服務都要小心設定啊...



補上NTPD的正確設定~~~~~~
就NTPD方面而言是透過restrict來限制ntp的使用者
而針對純client來說不外乎就是localhost以外一律拒絕
而這方面又分兩種設定法
1.(目前各大Linux distro的預設設定)
Ref.ntpd access restrictions - Allow Queries?

# 下方這行是預設禁止一切對此NTP Server查詢(不擋對外之對時查詢)
# 各選項意義可參考下方網址
# http://support.ntp.org/bin/view/Support/AccessRestrictions#Section_6.5.2.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
# 允許localhost一切查詢
restrict 127.0.0.1
restrict ::1

2.(麻煩點的方法? - 不過是FreeBSD樣板給的方法)
Ref.ntpd access restrictions - If you used 'restrict default ignore'

# 下方這行是預設禁止一切查詢(包含一切對外的對時查詢 << 麻煩的地方XD)
restrict default ignore
# 這行是開放對clock.stdtime.org.tw的對時查詢(但禁止對方查這個NTP Server)
restrict clock.stdtime.org.tw nomodify nopeer noquery notrap
# 這行是開放tick.stdtime.org.tw的一切查詢
# 上方那邊的官方文件是說讓對方能查比較"禮貌"啦，不過其實應該沒啥差XD
restrict tick.stdtime.org.tw
# 允許localhost一切查詢
restrict 127.0.0.1
restrict -6 ::1

如果使用第二種設定要特別注意幾點

• 每個"server"都需要設好對應的restrict放行，不然會被擋掉，跟沒設一樣www
• 如果使用domain name的話，只對對應單一A Record的DNS有效，像pool.ntp.org對多個A Record的請使用IP

個人是比較喜歡第一種設定啦
相對設定簡單
再說很少會需要擋對外的對時查詢吧XDD

然後除了NTPD方面的設定外
如果防火牆本身也擋好就更好了wwww

Project Marai 2 開箱!

先上OP~~~~  跟後面的學習帳也有關www

【初音ミク Project mirai 2 テーマ曲】アゲアゲアゲイン By Mitchie M

水管~~~

NicoNico
http://www.nicovideo.jp/watch/sm21965634


說起來...
我差點就沒買到特典版了XDD
好在剛好有瞄到巴哈&PTT有人說Marai 2的消息
才想到好像快發售了XDD

匆匆問某店還有沒有拿得到的特典版
結果剛好還有www

原本是說訂完當天馬上就能寄 (星期三)
結果也確實隔天就送到了 (宅配員call咱起床了XDD)
結果學校整理信件名字給我打錯...
所以沒收到領信通知
就想說可能還沒整理完等明天再看看...

結果竟然是Key錯名字! ┴┴︵╰（‵□′）╯︵┴┴
不過至少是順利拿到了 030


拿到時~~~
~~~易碎品+籠車~~~
(雖然好像沒那麼容易碎 別壓到就好XDD)

就這樣抱著這個箱子從文書組走回到宿舍
反正也看不到裡面是啥XD

打開外箱理所當然是塞一堆東西

不過這填充物...

這是雜誌啊!
不要可以送我啊 不用拆也無所謂

把這些垃圾雜誌屍體排除後

包著氣泡袋的本體啊!!!!!!!!!!
不過膠帶黏得有點多 不是太好拆www

東西出來啦!
初回特典+限定版maria 2  +  店家另外送的小黏土人

對了 還夾了張傳單XDD
還好咱對PVC基本上免疫...
(其實是跳不下去...)

總之先來拆送的小黏土人
外盒上的封口貼紙有撕過的痕跡
很不易外的這種隨機的東西幾乎都會被拆過XD

是大姊~~~~
不過看了下就收回去了
宿舍沒地方擺www

再來是特典
說真得這有點奇妙XDD
學習帳
會買的基本上用不到吧www
這是要留給孩子用的嗎XD

來幫ミク上色～～

這是ミク呦 是你的媽媽 要記好喔

附了mirai 2的OP歌詞

拖了一堆 現在進入本體啦!

可以看到限定版小黏土人+遊戲盒(&貼紙 大概還看得到吧?)

先拿出小黏土人啦~~~
這盒確定沒開過痕跡(廢話

開盒!!!!....

等...
這啥?
有必要包成這樣嗎XDDD


拆開氣泡袋

不過最後還是收回去了XD

貼紙其一&被推倒的遊戲盒

貼紙其二

遊戲盒正面~~~

 背面(順便拆了塑膠套~~~)

 盒背

開盒啦!!!!!
(好多盒XD)

內容物:
說明卡書
AR卡組*2
SEGA問卷
SEGA SONIC廣告
mirai 2宣傳單?
任社CLUB點數

(別忘了還有卡帶 和... 盒子?

這次的盒子在盒子挖洞處塞了人物圖www
圖案數和盒子的洞數一樣
想到任天狗要拆下來才能全看到 030

說明書兩面
任社說明書電子化
盒子裡大部分不會有整本的說明書了OwO

然後是AR卡~~~

這次的AR卡還是雙面的呢www

不過...
想到舊版&PDf的AR都被我那鬧水災的背包殘害過...
還好看起來沒啥痕跡就是

最後的最後~~~
這才真正重點啊!!!!
(咦? 重點不是前面那些特典?
卡帶本體!!!

卡帶上還是滿滿的商標啊...

插上3DS啦~~~

可以開始玩遊戲啦~~~

接下來遊戲的部分就跟咱無關啦XD
逃~~~~~~~~~~~~~~




不過雖然敗了
但依照最近卯起來當提督瘋狂摧殘鑑娘們的這狀況
不知道有多少時間能玩就是www

SSD終於回家啦~~~~~~ (雖然好像不是同一顆XD

上個月底終於把出毛病的ADATA S511拿去送修~~~
(應該拖了3~4個月有了XD 反正確定保固內沒差www)

然後就過了漫長的等待...
還真的是兩個星期多才回來 OTZ
(禮拜五收到通知 過了18天...)
很不意外的回來的不是S511 XDD
畢竟SSD沒在修都直接換
而S511又早就停產www

回來的是SP900 同樣還是SF 2281主控
顆粒從Intel變Micron 不過都非同步顆粒XDD
但共通特色都是有超過500MB/s的可壓縮資料跑分
多媒體檔案的讀寫有200 / 100 MB/s就不錯了www
不過當初是拿來組RAID0當系統碟 便宜而且有基本速度就夠了~~~
要說的話還是現在的M5S比較爽快XDDD

對SSD本身倒是沒啥太大抱怨啦
不過為了省成本所以把原本送的鋁合金3.5"轉接架
換成塑膠製的整個質感暴跌 這怨念超大...
(尤其外觀設計感覺很強調這就是塑膠製品...)

順便偷偷期望一下另外一顆S511在保固期內出毛病
這樣可以再換一顆新的XDDD

學校停電之鬼混計 (!?

當現代人的依靠被切斷之時
中央校園被黑暗襲擊了
同時陷入了無人的寂靜

理應如此
但巨大的聲響也同時入侵了校園
破壞了這片安寧
(此人因停電發瘋了請無視



說真的...
之前停電咱都睡死(雖然好像都是上午?)
所以也沒注意過學校到底有那些發電機
但這次發現校內幾乎遍佈著極大量啊OAO!


話說因為忙完回宿舍(真的不該順路逛中壢夜市-3-)
剛好是12點所以停電了...
一片漆黑的浴室實在不適合洗澡
沒冷氣又全身不大舒服根本睡不著
所以就難得大半夜跑到校外鬼混去了XDD

一開始衝到了麥噹噹去
吹到冷氣瞬間復活XDD
還很爽快的灌了整杯可樂
(東西還是一樣不是給人吃就是)

吃完後立馬衝新都市
第一次大半夜到新都市
當然自然是走到幾乎被K社佔據的音樂機台區XD
雖然18禁那區的機台也算熟悉...
算家庭背景因素?

而且這還是第一次打到K社的E-PASS伺服器關機呢www
(北部貌似沒啥開24HR的點啊OWO?)
雖然說關機後貌似有會爆能力的八卦
不過沒存檔開過的歌就沒試了
關機後開始瘋狂還能連的MaiMai

~~~題外話~~~
發現這一代的MaiMai Green跟咱同步率有點可怕的高啊
那歌曲打完後的貓叫聲...
害咱每次都自主性的跟著叫一次了XD
咱就常在亂喵叫了 這根本開了總開關啊XDD

Long Polling 之 隨興實作

上次終於得知Long Polling之後
原本只覺得應該只是知道 短時間內沒機會用到...

結果今天點歌系統做個小改版發現其實頗適合用的XDD

原本點歌系統點播清單那塊是隨著換曲時重載
(因為每次換曲點歌數一定會減少啊XD)

不過這樣要是別人點了歌並不會馬上更新
除非自己手動更新或換了歌才會知道
這樣不就不符合即時系統了嗎!!!!!! (請無視此人的發瘋

所以就開始準備動手修改一下
但... 很明顯的用polling絕對不是好方法(理想大概要1s的間隔吧...)
所以就來弄弄Long Polling啦

因為Long Polling會有相當數量的持續連線
當然不能用PHP寫啦~~~ (其實用PHP寫daemon應該可行?)

這回用的是node.js 順便來玩玩這用JS來寫Server XDD
(題外話... 原本想要裝forever來跑這server 不過好像npm registry被衝爆了...)

因為需求上是點歌系統點的一首歌後送出訊息要求客戶端更新
設計上只要一個簡單的訊息交換就夠了
所以這js還頗小的www

server.js

// http
var http = require("http"),
    url   = require("url");

http.globalAgent.maxSockets = 200;

var pendingRequests = [];

// 客戶端連線時讓連線進入等待狀態
function processPendingRequest(request, response) {
    // 連線被強制關閉時移除
    response.on('close', function() {
        clearTimeout(this.timeout);
        var id = pendingRequests.indexOf(this);
        if (id != -1) pendingRequests.splice(id, 1);
    });
    
    // force reconnect
    response.timeout = setTimeout(function (){
        response.writeHead(200, { 'Content-Type': 'application/json', 'Access-Control-Allow-Origin': '*' });
        response.write(JSON.stringify({ "message": "" }));
        response.end();
        var id = pendingRequests.indexOf(response);
        if (id != -1) pendingRequests.splice(id, 1);
    }, 30000);
    
    pendingRequests.push(response);
}

// 送出訊息時針對所有等待中連線送出訊息
function processSendingRequest(request, response) {
    var u = url.parse(request.url, true);
    var msg = u.query.msg, dat = u.query.dat;
    while (pendingRequests.length > 0) {
        var element = pendingRequests.shift();
        clearTimeout(element.timeout);
        element.writeHead(200, { 'Content-Type': 'application/json', 'Access-Control-Allow-Origin': '*' });
        element.write(JSON.stringify({ "message": msg, "data": dat }));
        element.end();
    }
    response.writeHead(200, { 'Content-Type': 'application/json' });
    response.write("{\"result\":\"complete\"}");
    response.end();
}

// 建立HTTP伺服器
http.createServer(function(request, response) {
    var u = url.parse(request.url, true);
    if (/* 此處為訊息傳送端驗證 */) processSendingRequest(request, response);
    else processPendingRequest(request, response);
}).listen(13453);

沒有寫的很複雜
整體就很簡單的訊息交換而已

而點歌頁面也做了對應的調整

function polling_call() {
    $.ajax({
        cache: false,
        dataType: 'json',
        type: "GET",
        crossDomain: true,
        url: "http://live.sbsstudio.twbbs.org:13453/",
        error: function () {
            setTimeout(polling_call, 15000);
        },
        success: function (p) {
            switch (p.message) {
            case "NeedUpdateRequireList":
                requestlist_call();
                break;
            }
            polling_call();
        }
    });
}

Long Polling的客戶端總是很簡單XD
只需要反覆的ajax請求就好
要是伺服器端沒有支援的話，這可是比Polling還糟糕啊XDD

最後後台點歌的PHP檔只需要在點歌成功後外加一個CURL請求就好
就沒多放程式碼啦~~~

這永遠BETA的點歌系統又往正式版前進一步了~~~
(這句話矛盾的很嚴重啊XDD

Long Polling 之 很殘念的到了最近才知道啊...

是說這是第一篇文耶!!! (還不是某人真的讓這成了蚊子館XD

雖然標題是Long Polling來著
不過其實不全然是呢XDD (遭毆

以下正文(?


雖然這技術有段時間了
不過說真的不久前才剛知道啊XDD

得知起因莫名簡單的(?
主要是因為tlk.io這服務而起的XD
是個簡單的聊天室服務
雖然功能簡單樸素 不過技術倒不怎簡單啊www

存粹某天閒閒沒事對著他開了GC的開發者工具
(用了GC得到了這工具之後的習慣XD)
然後發現...
等... 竟然有個始終pending的連線? 而且status code還是101 !?
好奇的看了下URL... ws:// 這啥? 見都沒見過
所以就順手Google了一下...

恩... HTML5的新協議之一 WebSocket
原來這一直希望能有的東西被加進來啦OWO
恩... GC從6開始就有在實作了 (正確來說是4開始 不過貌似6才稍微比較完整?)
等... 咱看到啥了
咱可是只差最初的1沒用的GC死忠用戶啊(正式版前的版本無視XD)
老早就支援了咱竟然都沒注意到!!!!!!!!?
不過各瀏覽器支援仍然不大相同
看來還不適合實際使用
不過就像剛才說到的
tlk.io倒是用上啦XDD
(自然有其他fallback啦 不支援的狀況應該還是long polling)

然後這是新技術
自然會有對應的舊技術啦~~~
總不可能在哪邊每秒reload或者AJAX request的啊XD
(這就是polling 雖然之前確實這樣想的... OTZ
找資料的同時也發現了
除了polling這種爛到爆的方法外
還有comet&long polling
comet雖然可行 但終究不理想
所以就出現了long polling

這方法倒是意外的簡單說www
主要在伺服器端
收到客戶端的連線後就先丟著 讓他進入pending狀態
等到有資料要送的時候在送出去
而瀏覽器收到後就結束連線處理資料
然後又一個新的request送出繼續等待

不過這會有霸著連線的問題
自然得要靠event driven的後端
不然用apache連線直接被吃滿滿還要服務嗎XDD

照慣例的簡單試了下~~~
longpolling.php

<?php
$time = rand(2, 5);
sleep($time);
echo json_encode($time);
?>

longpolling.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<head>
    <script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
    <script>
    function pull() {
        $.getJSON("longpolling.php", function(result) {
            $("#pullresult").append("<p>waiting time : "+result + "</p>");
            setTimeout(pull, 100);
        });
    }
    $(document).ready(function() {
         pull();
    });
    </script>
</head>
<body>
<div id="pullresult">
</div>
</body>
</html>

結果~~~

(上面只是示範 如果真的拿來用的話Web Server會炸掉的XDD)


說實話
還真是沒想到現在使用的技術是如此的簡單啊XDD
果然好方法真的不一定是複雜的方法呢www
不過還是期望WebSocket能盡速普及啦
畢竟相較之下仍然是個比較好的方法XD

不過實際上也有SPDY這個方案呢www
總之看狀況啦~~~
反正寫網頁還是要看使用者啦
(望向那令種網頁設計師反感的IE 不過最近也好很多啦XD