2016年11月19日 星期六

偷偷拷貝夥伴的COMPOSER_HOME目錄

和夥伴在同一台主機下共同練習Laravel
每個人都自己的家目錄
而每個人也需要各在自己的家目錄下
composer global require "laravel/installer"
指令
主要目的是要把laravel的安裝程式下載回來到COMPOSER_HOME
(關於COMPSER_HOME是~/.composer還是~/.config/composer請看這一篇)

但是composer global的執行實在太慢了
偷懶一點的作法是

一、利用root的權限,把別人的COPY回來就好了
##舉例有test1與test2兩個使用者
mkdir ~/.composer
sudo cp -R /home/test1/.composer/* /home/test2/.composer/
sudo chown -R test.test /home/test2/.composer


二、設定laravel指令及XDG環境變數
sudo vi ~/.profile 或sudo vi ~/.bash_profile
在最後一行寫入
export PATH=$HOME/.config/composer/vendor/bin:$PATH
三、重新開機或直接執行source ~/.profile並執行laravel安裝
重新開機後,切換到自己的網頁目錄
輸入

laravel new blog

四、修改bootstrap/cache及storage
sudo chown -R www-data.www-data bootstrap/cache/
sudo chown -R www-data.www-data storage/


[Ubuntu16.04]安裝Laravel,COMPOSER_HOME竟多出了.config資料夾



如上圖
安裝Laravel的官方文件中提到:
執行
composer global require "laravel/installer"
安裝程式後,可以在~/.composer/vendor/bin目錄下找到laravel指令,但是今天卻發現此次設定的主機的路徑竟是~/.config/composer/vendor/bin,多出了一個.config的資料夾

仔細查閱相關資料後才發現,原來
假如電腦主機若是採用 freedesktop.org standards標準的作業系統,他會先偵測環境變數中XDG_CONFIG_HOME是否有設定,若沒有設定的話,就會自動幫你加上.config

If your system uses freedesktop.org standards, which it detects by looking for environment variables beginning with XDG_, then Composer uses $XDG_CONFIG_HOME/composer/, falling back to $HOME/.config/composer/ if that isn't set.


若要解決這個困擾(至少操作時跟路徑跟官方文件一致比較不會出錯),可從兩個方向著眼:
1.更改全域的設定,主機內全部使用者受惠
sudo vi /etc/profile

2.更改個別使用者
vi ~/.profile

同樣都是在檔案的最後一行加上
export XDG_CONFIG_HOME="$HOME"

這樣一來,當電腦重新啟動後,XDG_CONFIG_HOME環境變數就會先執行了,但假如你先前已經安裝過Composer的話,可能就需要再重新裝一次囉


註:其他XDG環境變數請參閱Environment variables
註:察看目前5.7的laravel Document官方文件,已經將安裝目錄改為~/.config/composer/vendor/bin,所以上面的XDG_CONFIG_HOME已毋需修改。
參考文件:




2016年11月8日 星期二

MySQL中的offset

offset的英文意思為抵消,當用在MySQL時的意思就好比忽略前幾筆資料,常跟limit搭配使用,使用時機通常是換頁時。

例如:select * from country limit 5 offset 5
意思就是:忽略前5比資料,列出country資料表中的第6~10筆資料。

2016年11月1日 星期二

ssh連線時,發生遠端主機認証資料已經改變的錯誤訊息

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:sTZh1ToLgA3719MjTD+Hnvbfb2HXXKtOk7uvp3Us23s.
Please contact your system administrator.
Add correct host key in /home/chunkai/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/chunkai/.ssh/known_hosts:3
  remove with:
  ssh-keygen -f "/home/chunkai/.ssh/known_hosts" -R 192.168.30.9
ECDSA host key for 192.168.30.9 has changed and you have requested strict checking.
Host key verification failed.


上面是最近常出現的訊息,這是因為進行ssh連線時,本機端會將伺服器端的金鑰與IP對應紀錄,寫入到
/home/使用者/.ssh/know_hosts

但是因為我裝了許多台虛擬主機,不同台的虛擬主機重啟後卻有可能使用同一組IP,如此一來本機端的know_hosts紀錄對應不符(另一種狀況,當然就是伺服器有重新安裝過,似服主機的金鑰碼又會不一樣囉,這樣也會產生對應不符的情形),就會出現上述的錯誤。只要照著他提示的建議:

ssh-keygen -f "/home/chunkai/.ssh/known_hosts" -R 192.168.30.9

重新建立know_hosts紀錄。