今天接到朋友的求助，php curl 貌似有問題，朋友自己也不確定問題在哪裡，只知道 API 放在遠振一切正常，但是移到 vultr 就有問題，大約幾十個 request 會遇到一個等待到 timeout 的情況，當時小蛙人在外面，大概聽了問題，還不清楚確切的原因，因為 php curl 的對象是自己 … 是自己還會等到 timeout？

一開始看 code，釐清所有的功能之後，感覺上沒有什麼問題，於是想說在 command line 直接下 curl 看看狀況，雖然不一定會跟 php 下 curl 完全一樣的情況，但至少試試看不吃虧 ~ 下了 curl -v https://xxxxxxxxx 後，詭異的事情來了，竟然等了很久都沒反應，甚至有時候還會出現 timeout 或是名稱無法解析的問題，連 ping 自己的 hostname 都 ping 不到，這是什麼好笑的狀況 …

後來小蛙在 /etc/hosts 上加入了 domain 對應之後，curl 自己的 API 至少沒問題了，看起來可以大聲說打完收工了。不久之後，小蛙又接到朋友電話，說有某個 domain curl 等到 timeout，該 domain 是外部的，有了上面的經驗後，小蛙第一次時間就 ping 該 domain，喔買尬 … 名稱無法解析，那試試看 ping noter.tw，ㄜ ~ 名稱無法解析，看來是 DNS 的問題了！

設定 Nameserver

上網查了一下 ubuntu 的 DNS 設定編輯 ，使用 Google 的 8.8.8.8 跟 8.8.4.4 就好了，換上之後一切正常。

小蛙在查資料的過程中看到有些人問，每次重開機之後這個設定檔都會恢復預設值該怎麼辦，其他人提出的解法感覺很複雜，小蛙也懶得測試，於是跟朋友要了 vultr 的帳密，也許可以直接透過網站直接設定就好，切換到 Network 設定部份，果然找到設定的方法：

開機後額外調整 resolv.conf 內容

小蛙設定上去後 reboot，花惹發 … 又跑回原本的設定 108.61.10.10，嗯 ~ 只好使出比較下三濫的手法了，修改 .bashrc，可能有更正統或正規的作法，但 … 趕時間，又剛好想到這個方法，就 ~ 先這樣子吧！常常聽到 sed 跟 awk 是神兵級的，但小蛙一直不知道怎麼用，通常都是想到什麼功能好像有，去查一下正確用法來套，於是找到 sed 搜尋並刪除整行資料 這篇，設定完重開機，就可以看到效果了！

vim .bashrc 
sed -i '/108.61.10.10/d' /etc/resolv.conf 

這篇文章 curl 的詭異問題 – Vultr DNS 設定 最早出現於 記下來。

一開始以為是之前搬伺服器的時候，Cloudflare 設定的問題，查了一段時間後發現連搜尋股票代號的功能都失效了，進資料庫看一下股票代號表，發現空白一片，此時大概知道問題出在哪裡。

把 crontab 裡更新股票代碼跟指數的 API 叫出來看一下發現「curl: server certificate verification failed.」這個錯誤，仔細看一下錯誤訊息裡面其實就有解決方法了，不過小蛙還是記錄一下備查。

curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.

有看到亮點了嗎？原本是 curl https://wxxxxxxx 改成 curl -k https://wxxxxxx 就可以忽略掉這個問題，但是同時也要注意存取目的的安全性喔！

這篇文章 Ubuntu 16.04 curl: Server Certificate Verification Failed. 最早出現於 記下來。

*/5  *  *  *    1-6     /usr/lib/cgi-bin/php5 -q /xxx/ooo/111.php >> /root/php 2>&2

第一個「*/5」指的是每5分鐘執行一次(詳細設定請參考第十六章、例行性工作排程 (crontab) @ 鳥哥的Linux私房菜)，「1-6」指的是星期一到星期六都要。「/usr/lib/cgi-bin/php5 -q」小蛙不曉得為什麼PHP路徑在那麼奇怪的地方，後面的-q也懶得去查所代表的意義，總之可以跑就對了(太懶><)，「/xxx/ooo/111.php」是要執行的PHP路徑。
設定好之後確實是可以正常運作了，但是後來發現如果別人也知道這個網址，只要在瀏覽器打上一樣的網址，程式就會運行一次 … 聽起來是多麼可怕的一件事，所以小蛙加上了現在大家最常用的API KEY的方式判斷是否為「有權限執行」。但是上面的方法似乎就不能夠帶參數了，Cron定时执行带参数的PHP代码 @ 飘易博客中提到了三種可以帶參數定期執行PHP的方法，恰巧小蛙前陣子在試node.js的時候已經安裝了curl(不知道什麼是curl以及如何安裝，請到curl @ DebianWiki)，就決定用第三種(看起來也比較簡單)。

*/5 * * * 1-6 curl 'http://xxx/ooo/111.php?APIKEY=123456&s=hi' >> /root/php 2>&2

上面那行就是最後的結果囉！希望這篇文章能對像小蛙一樣跟Linux不熟的網友有幫助！
2012-02-18
之前寫的定期備份wordpress的shell script手動可以正常執行，但只要放進crontab就完全不會動 … 後來在鳥哥的 Linux 私房菜中發現shell script第一行要宣告使用的shell名稱。

第一行 #!/bin/bash 在宣告這個 script 使用的 shell 名稱：
因為我們使用的是 bash ，所以，必須要以『 #!/bin/bash 』來宣告這個檔案內的語法使用 bash 的語法！那麼當這個程式被執行時，他就能夠載入 bash 的相關環境設定檔 (一般來說就是 non-login shell 的 ~/.bashrc)， 並且執行 bash 來使我們底下的指令能夠執行！這很重要的！(在很多狀況中，如果沒有設定好這一行， 那麼該程式很可能會無法執行，因為系統可能無法判斷該程式需要使用什麼 shell 來執行啊！)

這篇文章 crontab -e相關使用及問題 最早出現於 記下來。