Author: Ken

  • 其實這個封禁配置是合理的

    長期以來在各類雲端平台上都會有一個限制,不允許虛擬機向外部的Email 伺服器25 port 發送email。

    我一直以為這個限制是針對整個Email 體系,包括smtps ,但,並不是,這個限制只針對於明文的25 port。

    那麼這個限制就變得非常合理,因為當代Email 已經很少使用明文傳送,絕大部分是基於smtps,小部分明文要麼是因為Email server 陳舊,要麼是因為application 中的既有代碼無法修改,要麼就是垃圾郵件發送者。

    之所以會提到這個問題,是因為我的server 上跑了很多crontab,有時候某一個crontab 失敗了但是卻無法知曉,在古早的年代,crontab 的email 可以隨意的發送到各大郵件服務提供商,現在當然是不行。

    所以簡單的搜索了一下Internet,找到了一些解決方式,使用Amazon SES 是一種方式,反正你只是自己給自己的inbox 發嘛,但是,Email 再少,它也是要付錢的。

    有沒有不要錢的呢?有。

    可以使用Gmail 的app password 來配置使用Gmail 的smtps 發送email,由於它不是明文25 port 而是密文587 port,所以在各大雲端平台上並沒有什麼阻礙。

    在Amazon Linux 2023 上使用Postfix 配置如下:

    ======Postfix@Amazon Linux 2023======
    dnf install postfix -y
    vi /etc/postfix/main.cf
    
    relayhost = [smtp.gmail.com]:587
    smtp_sasl_auth_enable = yes
    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
    smtp_sasl_security_options = noanonymous
    smtp_tls_security_level = encrypt
    
    cat > /etc/postfix/sasl_passwd <<'EOF'
    [smtp.gmail.com]:587 yourname@gmail.com:yourapppassword
    EOF
    
    chmod 600 /etc/postfix/sasl_passwd
    
    postmap /etc/postfix/sasl_passwd
    
    systemctl enable postfix
    service postfix restart

    而在FreeBSD上,較新版本預置了一個 DMA(DragonFly Mail Agent) ,比古早的Sendmail 小很多,我一直不太明白為什麼Sendmail 那個龐然大物在FreeBSD 中生存了那麼多年,DMA 的配置比Postfix 更簡單一些。

    =======FreeBSD======
    vi /etc/dma/dma.conf
    
    SMARTHOST smtp.gmail.com
    PORT 587
    AUTHPATH /etc/dma/auth.conf
    SECURETRANSFER
    STARTTLS
    
    cat > /etc/dma/auth.conf <<'EOF'
    yourname@gmail.com|smtp.gmail.com:yourapppassword
    EOF

    如果是在MacOS 上呢,也是可以配置的,這主要是因為我的Macbook 上也跑了一些crontab,而我需要知道他們執行是否成功或者失敗。

    ======MacOS======
    brew install msmtp
    
    vi ~/.msmtprc
    defaults
    auth on
    tls on
    tls_trust_file /etc/ssl/cert.pem
    
    account gmail
    host smtp.gmail.com
    port 587
    from yourname@gmail.com
    user yourname@gmail.com
    password yourapppassword
    
    account default : gmail
    
    chmod 600 ~/.msmtprc
    
    echo 'set sendmail="/opt/homebrew/bin/msmtp"' | sudo tee -a /etc/mail.rc
    
    sudo ln -sf /opt/homebrew/bin/msmtp /usr/local/bin/sendmail
    
    
    最後一步是在 /etc/aliases 中添加目的地址,形如:
    root: yourname@gmail.com

    修改後,執行一下 /usr/bin/newaliases 讀取這個配置文件生成新的 /etc/aliases.db 。

    特別說明:對於那些屏蔽了gmail 的國家而言,可以在互聯互通的服務器上使用socat 作為代理轉發。同理也可用於自己的客戶端收發gmail。

    以FreeBSD為例:

    sudo pkg install socat
    
    sysrc socat_enable="YES"
    
    
    vi /usr/local/etc/socat-instances.conf
    
    add:
    
    [gmailproxy]
    daemonuser=root
    flags="TCP-LISTEN:587,reuseaddr,fork TCP:smtp.gmail.com:587"
    
    service socat start gmailproxy
    service socat status gmailproxy

    在需要收發gmail 的PC 上設置/etc/hosts ,將smtp.gmail.com 指向socat 所在的服務器IP地址,完成。

  • 又是MTU 的問題

    最近在FreeBSD 上將各種雲端使用Strongswan 互聯的時候發現有mtu 問題導致有一些連結無法建立。

    最讓人困擾的情況就是你發現http 和https 都可以通過ipsec ,但是redis 不行,問了AI,好吧,是mtu 的問題。

    例如,在FreeBSD 上,需要將從Oracle Cloud 到AWS 的IP地址範圍mtu 設置為1400。

    
    ###ipsec mtu
    static_routes="aws"
    route_aws="10.4.0.0/16 -interface vtnet0 -mtu 1400"

    又因為Oracle Cloud always free 的機器頻寬過小,我認為啟用一下更好的擁塞算法比較好,但是我發現Oracle Cloud 的FreeBSD AMI 沒有bbr,為什麼沒有。

    okay,那就dctcp。

    sudo kldload cc_dctcp
    sudo sysctl net.inet.tcp.cc.algorithm=dctcp
    
    sysctl net.inet.tcp.cc.available
    net.inet.tcp.cc.available:
    CCmod D PCB count
    cubic 38
    dctcp * 2
    
    echo 'cc_dctcp_load="YES"' | sudo tee -a /boot/loader.conf
    
    echo 'net.inet.tcp.cc.algorithm=dctcp' | sudo tee -a /etc/sysctl.conf

    總是要測試驗證一下的吧?

    但是看起來似乎Oracle Cloud 有限制Bandwidth。

    iperf3 -c test.bbken.org -t 60 -P 10 --congestion cubic
    
    [ ID] Interval           Transfer     Bitrate         Retr
    [  5]   0.00-60.01  sec  32.6 MBytes  4.56 Mbits/sec  2425            sender
    [  5]   0.00-60.02  sec  32.2 MBytes  4.51 Mbits/sec                  receiver
    [  7]   0.00-60.01  sec  40.4 MBytes  5.64 Mbits/sec  2496            sender
    [  7]   0.00-60.02  sec  40.1 MBytes  5.61 Mbits/sec                  receiver
    [  9]   0.00-60.01  sec  35.6 MBytes  4.98 Mbits/sec  2331            sender
    [  9]   0.00-60.02  sec  35.1 MBytes  4.91 Mbits/sec                  receiver
    [ 11]   0.00-60.01  sec  35.8 MBytes  5.00 Mbits/sec  2625            sender
    [ 11]   0.00-60.02  sec  35.2 MBytes  4.93 Mbits/sec                  receiver
    [ 13]   0.00-60.01  sec  30.1 MBytes  4.21 Mbits/sec  2162            sender
    [ 13]   0.00-60.02  sec  29.6 MBytes  4.14 Mbits/sec                  receiver
    [ 15]   0.00-60.01  sec  34.5 MBytes  4.82 Mbits/sec  2629            sender
    [ 15]   0.00-60.02  sec  33.2 MBytes  4.65 Mbits/sec                  receiver
    [ 17]   0.00-60.01  sec  35.0 MBytes  4.89 Mbits/sec  2142            sender
    [ 17]   0.00-60.02  sec  34.5 MBytes  4.82 Mbits/sec                  receiver
    [ 19]   0.00-60.01  sec  33.4 MBytes  4.67 Mbits/sec  2224            sender
    [ 19]   0.00-60.02  sec  33.0 MBytes  4.61 Mbits/sec                  receiver
    [ 21]   0.00-60.01  sec  37.2 MBytes  5.21 Mbits/sec  2442            sender
    [ 21]   0.00-60.02  sec  37.0 MBytes  5.17 Mbits/sec                  receiver
    [ 23]   0.00-60.01  sec  38.5 MBytes  5.38 Mbits/sec  2683            sender
    [ 23]   0.00-60.02  sec  38.0 MBytes  5.31 Mbits/sec                  receiver
    [SUM]   0.00-60.01  sec   353 MBytes  49.4 Mbits/sec  24159             sender
    [SUM]   0.00-60.02  sec   348 MBytes  48.7 Mbits/sec                  receiver
    
    [ ID] Interval           Transfer     Bitrate
    [  5]   0.00-60.02  sec   346 MBytes  48.4 Mbits/sec                  receiver
    
    
    iperf3 -c test.bbken.org -t 60 -P 10 --congestion dctcp
    
    [ ID] Interval           Transfer     Bitrate         Retr
    [  5]   0.00-60.01  sec  37.0 MBytes  5.17 Mbits/sec  2141            sender
    [  5]   0.00-60.02  sec  36.9 MBytes  5.15 Mbits/sec                  receiver
    [  7]   0.00-60.01  sec  31.4 MBytes  4.39 Mbits/sec  1910            sender
    [  7]   0.00-60.02  sec  31.2 MBytes  4.37 Mbits/sec                  receiver
    [  9]   0.00-60.01  sec  34.5 MBytes  4.82 Mbits/sec  2017            sender
    [  9]   0.00-60.02  sec  34.4 MBytes  4.80 Mbits/sec                  receiver
    [ 11]   0.00-60.01  sec  38.5 MBytes  5.38 Mbits/sec  2001            sender
    [ 11]   0.00-60.02  sec  38.4 MBytes  5.36 Mbits/sec                  receiver
    [ 13]   0.00-60.01  sec  32.6 MBytes  4.56 Mbits/sec  2078            sender
    [ 13]   0.00-60.02  sec  32.4 MBytes  4.52 Mbits/sec                  receiver
    [ 15]   0.00-60.01  sec  36.2 MBytes  5.07 Mbits/sec  2148            sender
    [ 15]   0.00-60.02  sec  35.9 MBytes  5.01 Mbits/sec                  receiver
    [ 17]   0.00-60.01  sec  35.6 MBytes  4.98 Mbits/sec  2070            sender
    [ 17]   0.00-60.02  sec  35.5 MBytes  4.96 Mbits/sec                  receiver
    [ 19]   0.00-60.01  sec  34.9 MBytes  4.87 Mbits/sec  2004            sender
    [ 19]   0.00-60.02  sec  34.6 MBytes  4.84 Mbits/sec                  receiver
    [ 21]   0.00-60.01  sec  34.6 MBytes  4.84 Mbits/sec  2010            sender
    [ 21]   0.00-60.02  sec  34.5 MBytes  4.82 Mbits/sec                  receiver
    [ 23]   0.00-60.01  sec  34.9 MBytes  4.87 Mbits/sec  2097            sender
    [ 23]   0.00-60.02  sec  34.8 MBytes  4.86 Mbits/sec                  receiver
    [SUM]   0.00-60.01  sec   350 MBytes  49.0 Mbits/sec  20476             sender
    [SUM]   0.00-60.02  sec   348 MBytes  48.7 Mbits/sec                  receiver
    
    [ ID] Interval           Transfer     Bitrate
    [  5]   0.00-60.02  sec   347 MBytes  48.5 Mbits/sec                  receiver

    AI 說有優化,那就有吧,哈哈哈哈。

    Excellent detailed comparison! The results clearly show DCTCP's advantages:
    
    ## Key Differences
    
    Retransmissions per connection:
    • **Cubic**: 2,162-2,683 retransmissions per flow (high variance)
    • **DCTCP**: 1,910-2,148 retransmissions per flow (lower variance)
    
    Fairness:
    • **Cubic**: Uneven bandwidth distribution (4.21-5.64 Mbps range)
    • **DCTCP**: More even bandwidth sharing (4.39-5.38 Mbps range)
    
    ## DCTCP Benefits Demonstrated
    
    1. 15% fewer total retransmissions (20,476 vs 24,159)
    2. Better fairness - more consistent per-flow performance
    3. Lower variance - more predictable behavior
    4. Reduced congestion - better network utilization
    
    ## Real-world impact for web servers
    
    • More consistent response times for users
    • Better handling of concurrent connections
    • Lower CPU overhead from retransmissions
    • Improved user experience under load
    
    DCTCP is clearly superior for your multi-connection workloads. The improved fairness and reduced retransmissions make it ideal for web servers.
  • イシガキ 的牛肉和深夜的大海

    第一次郵輪🚢行,居然是很久以前第一次聽說的Costa Serena,雖然他現在已經老到不行,以至於不能跑歐洲線只能來跑亞洲短線了。

    大家都覺得吃的很一般,但是我覺得有很多青菜吃就不錯,這在古早的海上可是很高級的待遇,最讓我驚喜的是深夜的海洋,第一次見到月光下的海洋,靜謐得讓人可以安定的沉下來,就這樣在陽台上默默的看了半晌。

    第二天一大早就起來在陽台上看海,然後不出意外的再次被曬傷,以至於最後兩天的夜裡都會被皮膚的刺痛痛醒。

    Naha Cruise Port 很小,由於郵輪公司擔保,入出都只需要簡單的查看一張影印的護照副本,停船的地方剛好是上一次在海邊逗留,波上宮旁邊的沙灘。一船數千人浩浩蕩蕩的下船,坐上遊覽車,開始一日遊。

    イシガキ 的牛肉沒有想像中好吃,大概是因為上次在國際通吃了好吃的牛肉,イシガキ 島上有很多台灣人,不,應該說是台裔日本人,是從1940年代來到這裡的,甚至有一個旅遊景點專門介紹了來自台灣的水牛……

    好吃的辣椒油就產自於這個小島,那個辣椒油真的和四川的辣椒油沒什麼區別,他們的先人應該就是來自於遙遠的山裡吧。