九月
11
2014

請不要再使用isleaked.com檢查自己的Gmail了

今天看到一則不負責任的文章: 全球 493 萬 Gmail 賬密遭洩,輸入你的 Email 就知道是不是「受駭者」! 做為一個這麼多人閱讀的資訊網站,沒有做到資訊檢查的前置作業,就將這樣的文章發表出來,不知道會造成多少人受害?

為什麼這樣說呢? Gmail爆發帳戶的密碼外洩事件,是在台灣的2014年9月11日凌晨,而isleaked.com這個網域的註冊時間是在2014年9月8日網站的SSL申請日期是在2014年的9月10日。有沒有這麼剛好? 這個網站難道未卜先知,知道Gmail即將爆發帳戶密碼外洩的資安事件,所以在資安事件爆發前就架設好提供給大家查詢 (迷之音:順便蒐集大家的email)

不是杞人憂天,而是真的對於一個資訊網站對於資訊內容沒有做好檢查,就這樣散播出來,對於一般使用者來說,可以說是一項很不負責任的行為

  • isleaked.com 網域註冊資料:http://www.whois.com/whois/isleaked.com
  • isleaked.com 的SSL資訊:
  • isleaked.com SSL

九月
10
2014

iPhone 6 和 iPhone 6 Plus該選那支?

先來看看從iPhone 4 到 iPhone 6 Plus的手機重量
iPhone 4: 137公克
iPhone 5: 112公克
iPhone 5S: 112公克
iPhone 6: 129公克
iPhone 6 Plus: 172公克

拿過iPhone 4和iPhone 5會覺得iPhone 4好重,同理如果換成iPhone 6 Plus那應該會感覺到手機又大又笨重

接下來我們來比對各手機和 iPhone 5的重量比
iPhone 4 和 iPhone 5的重量差: 25公克
iPhone 6 和 iPhone 5的重量差: 17公克
iPhone 6 Plus 和 iPhone 5的重量差: 60公克

對比 iPhone 4 和 iPhone 5的重量差是2.4倍,如果真的要我選,我會選擇 iPhone 6,不會選擇 iPhone 6 Plus,真的是重死了!

七月
28
2014

使用Shell Script自動建立AWS AMI Image備份

我已經將這個shell script放上github,方便維護與更新 https://github.com/henrychen95/AWS-AMI-Auto-Backup

使用AWS的時候,建立AMI Image算是一個不錯的備份方式,下面我分享使用AWS內建的指令來進行備份

必備條件

  • 必須安裝AWS tools,可以使用 yum install aws* 來進行安裝所有需要的套件。
  • 請確認你的AWS tools路徑,預設會是在/opt/aws/bin,如果你的路徑不相同,請修改Shell Script的第二行。
  • 請確認你的EC2_HOME路徑,可以使用 env | grep EC2_HOME 來確認。
  • 請確認你的JAVA_HOME路徑,可以使用 env | grep JAVA_HOME 來確認。
  • 請建立適當權限的IAM Role,並且在啟動instance的時候加入IAM Role。如果你對於IAM Role不熟悉,可以建立admin IAM Role來快速使用。

這個Shell Script可以設定以下變數

  • region: 填入要備份的region
  • instanceID: 填入要備份的instance
  • amiNamePrefix: 填入你希望使用的AMI名稱
  • amiDescription: 填入你希望使用的AMI描述
  • routine: 如果設定為true,那麼會在amiNamePrefix後面加上Mon, Tue…這樣的文字來當作AMI名稱,並且會保留7天的備份

這個shell script會刪除舊的AMI和snapshot來節省空間
#!/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/opt/aws/bin

# Please use env | grep EC2_HOME to find out your system's setting
EC2_HOME=/opt/aws/apitools/ec2

# Please use env | grep JAVA_HOME to find out your system's setting
JAVA_HOME=/usr/lib/jvm/jre

export EC2_HOME JAVA_HOME

# Regions reference: http://docs.aws.amazon.com/general/latest/gr/rande.html
region="ap-northeast-1"

# You can find your instance ID at AWS Manage Console
instanceID="YOUR-INSTANCE-ID"

# Your prefer AMI Name prefix
amiNamePrefix="AMI_"

# Your prefer AMI Description
amiDescription="Daily AMI backup"

# If you want to keep 7 days AMI backups, please set routine true otherwise set it false
routine=true

# Variable for routine is true
weekday=$(date +%a)

if [ $routine = true ]; then
    # Setup AMI Name
    amiName=$amiNamePrefix$weekday

    # Get AMI ID
    amiIDs=$(ec2-describe-images --region $region | grep 'ami-[a-z0-9]' | grep "$amiName" |cut -f 2)

    # Get Snapshot ID
    if [[ ! -z $amiIDs ]]; then
        snapshotIDs=$(ec2-describe-snapshots --region $region | grep $amiIDs | cut -f 2)
    fi
else
    # Setup AMI Name
    amiName=$amiNamePrefix

    # Get AMI ID
    amiIDs=$(ec2-describe-images --region $region | grep 'ami-[a-z0-9]' | cut -f 2)

    # Get Snapshot ID
    if [[ ! -z $amiIDs ]]; then
        snapshotIDs=$(ec2-describe-snapshots --region $region | cut -f 2)
    fi
fi

if [[ ! -z $amiIDs ]]; then
    # Deregister AMI
    for amiID in $amiIDs
    do
        ec2-deregister --region $region $amiID
    done

    # Delete snapshot
    for snapshotID in $snapshotIDs
    do
        ec2-delete-snapshot --region $region $snapshotID
    done
fi

# Create AMI
ec2-create-image $instanceID --region $region --name "$amiName" -d "$amiDescription" --no-reboot
  • 我們可以把這個shell script存成/root/createAMI.sh
  • 然後執行 chmod 755 /root/createAMI.sh
  • 接著新增一筆排程,就可以自動進行AMI的備份

四月
23
2014

MySQL使用AWS SSD效能測試

AWS某些instance有提供SSD,下面是使用m3.medium,並且將MySQL安裝在SSD上面的測試數據

[root@ip-172-31-17-67 ssd]# time sysbench --test=oltp --mysql-table-engine=innodb --mysql-user=$dbUser --mysql-password=$dbPassword --db-driver=mysql --mysql-db=test --oltp-table-size=1000000 --oltp-table-name=t1 --oltp-nontrx-mode=insert --mysql-socket=/mnt/ssd/mysql/mysql.sock run
sysbench 0.4.12: multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing OLTP test.
Running mixed OLTP test
Using Special distribution (12 iterations, 1 pct of values are returned in 75 pct cases)
Using "BEGIN" for starting transactions
Using auto_inc on the id column
Maximum number of requests for OLTP test is limited to 10000
Threads started!
Done.

OLTP test statistics:
queries performed:
read: 140000
write: 50000
other: 20000
total: 210000
transactions: 10000 (169.49 per sec.)
deadlocks: 0 (0.00 per sec.)
read/write requests: 190000 (3220.29 per sec.)
other operations: 20000 (338.98 per sec.)

Test execution summary:
total time: 59.0009s
total number of events: 10000
total time taken by event execution: 58.8980
per-request statistics:
min: 2.65ms
avg: 5.89ms
max: 111.90ms
approx. 95 percentile: 15.02ms

Threads fairness:
events (avg/stddev): 10000.0000/0.00
execution time (avg/stddev): 58.8980/0.00

real 0m59.107s
user 0m4.027s
sys 0m9.246s
頁次:1234567...278»