初心易得,始終難守
C'est la vie.© 2002 - 2025
  • 我是誰-Who Am I
  • 我在哪-Where Am I
  • 我是什麼-What Am I
  • 年鑑-YearBook
    • 二零零六年终总结
    • 一吻定情—二零零八年年终总结
    • 突如其来的明天—二零零九年年终总结
    • 人生大起大落得太快——二零一零年年终总结
    • 贰零①①年年终总结-女朋友已经成家了
    • 贰零壹贰年年终总结-奔波的肿瘤
    • 贰零壹叁年年终总结
    • 雪字怎么写-贰零壹肆年年终总结
    • 每个不曾表白的今天,都是对青春的亏欠-贰零壹伍年年终总结
    • 按部就班的IT 人生-貳零貳肆年年終總結
  • 連結
RSS
9 月 9 日, 2025 年

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

Ken Tech 0 Comments

長期以來在各類雲端平台上都會有一個限制,不允許虛擬機向外部的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地址,完成。

8 月 22 日, 2025 年

又是MTU 的問題

Ken Tech 0 Comments

最近在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.
8 月 15 日, 2025 年

イシガキ 的牛肉和深夜的大海

Ken 随笔 0 Comments

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

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

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

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

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

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

7 月 18 日, 2025 年

第二次漢光演習

Ken 随笔 0 Comments

這是我經歷的第二次漢光演習,金融區的街道上能變得空無一人,當然天氣太熱也是原因之一。

我覺得演習的力度還是不夠,沒有太大的主動參與感,被動的參與感那當然是有的。

巧芯我是喜歡的,因為他長得很可愛,罷免團體給的罷免理由很模糊,我至今沒有認識到為什麼要罷免他,不能讓人感受到有充分的理由要來罷免巧芯,相對來說葉元之的罷免理由就很充分。

光電是綠能,這不錯,我很支持光電和風電,但是經濟部一波波的為颱風後海上光電板的廠商洗地,甚至刺裸裸的親自下場發新聞稿,這就有點此地無銀三百兩的意思了,究竟是利益所在,還是面子掛不下去,捅出好幾億台幣的簍子,就這樣不了了之。經濟部這樣撒謊,損害的是政府的誠信,如果不是關係人的背景,應該不會不要臉到這個程度。

這KMT 不去追著打,實在是令人匪夷所思,除非KMT 在其中也有利益,或是KMT 已經接受了廠商的政治獻金。

6 月 30 日, 2025 年

歐羅巴的風吹痛了我的頭

Ken 随笔 0 Comments

上個月去了歐洲,也去了年輕的時候應該去的巴黎。

Emirates 居然有免費機上Wi-Fi,土豪國家的航班確實不一樣,餐點也是一大盤,各種小零食,感覺以前坐的飛機都是假的,這才是真正的飛機。

巴黎人真的很需要香水,因為以前可能真的很臭,在從義大利到法國的這段旅程中,我發現歷史的長度其實是不一樣的,同樣的五百年,歐洲大陸上的每個國家,不,應該說每一片土地上的人,前進的速度是不一樣的,就像華夏文明的那片土地,所謂的五千年歷史,可考的只有兩千年,而這兩千年裡面,倒行逆施的還不知道有多少年 ,歷史的長度並沒有任何值得驕傲的地方,因為他可能是源遠流長,也可能是又臭又長。

義大利人大概是從羅馬帝國終結就厭倦了戰爭而變得慵懶,畢竟哪個國家要論戰爭的藝術,恐怕都是不及羅馬帝國的,鬥獸場就是如何花式殺人的藝術表演場所。

在墨索里尼時代則完整的表達了打一炮就跑去喝咖啡的精神,現在也是,關鍵地點的持槍警衛,幾乎都會端著一小杯義式濃縮,怪不得動不動就🤌🏿,咖啡喝多了可能就會這樣,Si?

羅馬的行程大概是在不同的天主教墓穴中穿梭,還可以直接看到某一任教皇的乾屍,這樣那個教皇會開心嗎?感覺他應該不會開心吧,還是他有遺囑說可以給大家看?

我最大的發現,是在梵蒂岡博物館裡面四處的大理石牆面上都有塗鴉和刻字,我原本以為是最近的這些人幹的,但是我從落款的日期中發現,我靠,好幾百年前,原來古人的手也是這麼賤,相比之下凡爾賽宮的牆面上就沒有刻字。

空中之城是個獨特的地方,這裡的居民應該都搬走了,剩下的只有商家和以前殘留的洞穴,那些洞穴看起來就是修道士們苦修的地方,依山挖個洞,雖然他的位置看起來很高,但是風並沒有很大,因為進入空中之城的路非常陡峭,即使已經改為了現代化的水泥路面,但仍時不時的有專門爬山像小山貓一樣的救護車開上來,托著走不動路的歐洲老人家下山去。

威尼斯看起來更多的是陳舊,似乎停留在了歷史的某一個時間點,原來的居民已經搬走很多,賭場也沒有開,最熱鬧的地方就是廣場和超市,也許有扒手。威尼斯或許是很獨特,但是他的獨特並沒有讓人覺得驚奇之處,純粹算是見證了商會的興盛與消亡,大概就如同大航海時代世界各地的那些曾經興盛的港口吧。

比薩斜塔位於一個比較鄉下的地方,也許是以前的水運比較發達。人出奇的比其他地方多,可能是因為比較有名,也可能是因為Viking 的郵輪剛好停在旁邊下來了一大群人。但是和斜塔比起來我覺得旁邊的教堂更有意思,所有的窗戶都沒對齊,當年修房子的人一邊修一邊想要怎麼調整,真是一個動態大工程,比現在修房子難度高很多喔。

但從羅馬看到巴黎,便會覺得巴黎的建築並沒有多了不起,鐵塔,聖母院,凡爾賽宮,還是要賣得出贖罪券的團隊最有錢,修得最華麗。

Monaco 的海洋博物館沒有時間去,下次應該要去看一看。

凡爾賽宮只能看到他的軀殼,看起來凡爾賽宮沒有被翻修過,畢竟從歷史書中看來,大革命時期的革命家們雖然愛好殺人,但似乎並沒有見到他們毀壞文物,但凡爾賽宮裡面擺放的東西看起來並不在他們原來的位置,似乎是從其他地方搜羅來然後再擺上去的,沒有辦法想像他原來的樣子,只能確定他原來不是現在這個樣子剩下的似乎是從其他地方找來東拼西湊的,因為很多雕塑的顏色,位置與原本宮殿的顏色和搭配格格不入,沒想到法國人為了賺遊客的錢,也這麼厚顏無恥。

羅浮宮還算是不錯,很多看不懂的畫作,和遠遠看不清楚的蒙娜麗莎,但是我依然錯過了行前準備好要去的埃及館,只能下次再去。

紅磨坊沒有想象中的好看,但仍然是場場爆滿,女演員的奶都比較小,大腿都比較壯,也許是為了方便表演,畢竟康康舞是招牌,太大的奶抖動可能會因為晃動過於劇烈而無法穩定姿態,當然美觀和藝術性是有的,力與美的結合,但不知道是不是招募不到新人,重複的面孔很多,也沒有我喜歡的類型。

很不幸的在巴黎被風吹到著涼,可能是因為褲子穿太薄,巴黎市區的溫度只有十幾度,在酒店的床上攤了半天,吃了普拿疼繼續遊玩。

«‹ 2 3 4 5›»

過 客

  1. R2 on 卷進了美商5 月 15 日, 2024 年

    终于回来了,好。

  2. Ken on Mommy最後的樣子11 月 6 日, 2023 年

    也沒有很久吧,最近終於閒下來

  3. R2 on Mommy最後的樣子10 月 26 日, 2023 年

    好久不见

  4. Ken on 天朝Loli控组曲(带歌词,修正版)10 月 12 日, 2023 年

    哈哈哈,祝福你,好人一生平安

  5. liu on 天朝Loli控组曲(带歌词,修正版)10 月 12 日, 2023 年

    hello,我在找天朝lolicon组曲时发现了你的博客,感谢你十四年前做出的贡献,祝一切安好

December 2025
S M T W T F S
 123456
78910111213
14151617181920
21222324252627
28293031  
« Nov    

Spam Blocked

101,924 spam blocked by Akismet

↑

© 初心易得,始終難守 2025
Powered by WordPress • Themify WordPress Themes