Amazon Linux的aws configure設定問題

這幾天工作上碰到一些關於AWS EC2的需求，針對使用Amazon Linux的Instance，打算把資料上傳到AWS S3的Bucket，上網查了一下，可以在命令視窗使用aws指令，不過需先設定configure，指令為aws configure，之後系統會要求輸入相關參數

[ec2-user@ip-xxx-xx-xx-xxx ~]$ aws configure
AWS Access Key ID [None]: accessId
AWS Secret Access Key [None]: accessKey
Default region name [None]: us-west-2
Default output format [None]:

像上面後就可以正確執行了，之前發生問題的部份是Default region name這個項目，由於S3 Bucket的Properties中，顯示的Region為Tokyo，一開始就填成Tokyo了，結果就是怎麼嘗試上傳資料到S3都失敗。
一直出現下面顯示的錯誤
aws s3  Missing required header for this request: x-amz-content-sha256

改成 us-west-2 就沒事了....


順便記錄一下抓取S3資料得語法
aws s3 cp s3://BucketName/path/filename toFileName

留言

張貼留言

這個網誌中的熱門文章

天雨粟、鬼夜哭、思念漫太古。

天雨粟、鬼夜哭、思念漫太古。 五月天新歌，『倉頡』的最後一小段，單純的感受，覺得是很有韻味的一句歌詞， 可是這是什麼意思呢？ 網路上查找了一下， 『天雨粟、鬼夜哭』這兩句出自『淮南子』-『昔者倉頡作書而天雨粟，鬼夜哭。』這一句 然後有人這樣解釋了 漢字的產生驚天地，泣鬼神，天上下起了粟米，鬼神在黑夜里哭泣。 漢字的產生為何會使“天雨粟，鬼夜哭”？ 那是因為有了漢字之後，“造化不能藏其密，故天雨粟； 精怪不能遁其形，故鬼夜哭” （張彦遠《歷代名畫記》），簡單地說， “天雨粟”寓意中華民族因為有了文字，變得更聰明， 思想更開闊，生產能力、創造能力大大增强； “鬼夜哭”寓意漢字的產生真正揭開了天地的奥秘， 使中華民族智慧增强，鬼神從此難以主宰人類的命運了， 因此只能在黑夜里哭泣。 只是這麼一來我還真不知道跟前面的歌詞有什麼關係， 通篇是思念、想望、不捨與期待，跟這邊的天地同慶、鬼神悲歎又有什麼關係？？？ 後來發現了另一段解釋， 整段『淮南子』應該如下： 昔者倉頡作書，而天雨粟，鬼夜哭；伯益作井，而龍登玄雲，神棲昆侖。能愈多而德愈薄矣。故周鼎著倕，使銜其指，以明大巧之不可為也------ 參考此文 後面的大巧不可為才是重點，也就是淮南子認為，人類懂得文字等巧變之事，將會越來越投機，能愈多而德愈薄，上天降下粟米是悲憫人們將不務農事，鬼夜哭則是神鬼的哀鳴， 所以天雨粟、鬼夜哭其實都是警訊， 而這樣解釋的話，這最後的一段感覺就說的通了 看前面的歌詞 寫出能讓你快回來的詩篇、 創造能讓你想起我的字眼、 寫出讓宇宙能重來的詩篇、 前兩句可能還好，最後一句可就是逆天而行了， 所以應該是這樣解釋的吧 即便天雨粟、鬼夜哭，這些警訊一一浮現， 我還是期望能讓宇宙重來一遍，只因我對你的思念早已經瀰漫了整個太古。
閱讀完整內容

蘇打綠 - 御花園

蘇打綠 - 御花園 一開始聽只覺得是首節奏明快、清爽好聽的歌，歌詞還滿複雜不太好記，常常唱錯， 不過當開始去注意歌詞的意涵之後，才發現是首相當有趣的歌。 所以！來破題吧，歌名叫御花園，御花園是什麼？ 御花園是紫禁城中的一座庭院的名稱，簡單講就是皇親國戚才能使用的地方， 大概聽過的細想一下歌詞與歌名大概也就知道大意是什麼了， 這該是首對時下政客的嘲諷歌曲吧， “他把最美的花都偷走 種在他後院裡頭 我們受難時候的苦痛 來自於他的享受 就好比那凶狠的杜鵑 對撫養牠的麻雀 沒上過當的鳥不拒絕 餓林召喚的玫瑰” 這是第一段個歌詞，翻白話就是大家辛勤的工作，結果所以好康都被你拿走了， 然後他們在哪，強盜就躲在城堡， 再那邊愉快的舉杯享受收活，高興自己能夠成功，欺瞞了那些奉獻犧牲的人。 接著第二輪的歌詞，我覺得實在是相當有意思。 “窮奢極欲的內心化做 蜜糖一樣的嘴唇 玉液瓊漿的生活演成 奉獻犧牲的亢奮 公正無私的法律變身 嚇鳥用的稻草人 生靈塗炭的結局是否 是種巧合的緣份” 不就是講那些話總是說的很好聽的人嗎？把大家都迷倒似的。 然後法律只是稻草人，嚇嚇老實人用的罷了！ 最後罵都罵完了，還是留下一些希望 “夏天 養只秋老虎準備 只顧著馴獸師的威風 沒想到最後被反撲咬一口” 是呀，我們還是有那一點點反撲的本錢喔。 雖然這有點自我安慰的味道啦， 不過，民主政治就是這麼一回事吧， 在現代御花園，可不是只屬於某些人擁有罷了。 另外，說到最喜歡的一句歌詞是哪句的話，我一定選下面這句， "烏鴉 也能夠罵別人黑" 實在是罵的太恰當了，不是嗎？ 後面附上歌詞跟youtube的影片，這首歌的影片不多，不知道是不是不夠受歡迎。 蘇打綠 - 御花園 詞曲作者：詞/曲:吳青峰 他把最美的花都偷走 種在他後院裡頭 我們受難時候的苦痛 來自於他的享受 就好比那凶狠的杜鵑 對撫養牠的麻雀 沒上過當的鳥不拒絕 餓林召喚的玫瑰 強盜就躲在城堡 慶祝 他們偉大深遠的計謀 慶祝 舉杯我們身上流的血 慶祝 他們高超演技的成功 慶祝 舉杯我們汗水和眼淚 烏鴉 也能夠罵別人黑 只顧著頭上盛開的花 卻忘了腳下腐爛的無花果 窮奢極欲的內心化做 蜜糖一樣的嘴唇 玉液瓊漿的生活演成 奉獻犧牲的亢奮 公正無私的法律變身 嚇鳥用的稻草人 生靈塗炭的結局是否 是種巧合的緣份 強盜就躲在城堡 慶祝 他們偉大深遠的計謀
閱讀完整內容

Nodejs Base64 Url Safe

一、關於Base64編碼： 雖然常用卻沒注意過，一般Base64，包含英文字母A-Z、a-z、數字0-9，這樣62個字元，然後呢，這樣還少2個字元才64個，這另外兩個就是+、/兩個符號，最後呢，編碼完成依據狀況會補上=，詳細的說明可以參考wiki。 https://zh.wikipedia.org/wiki/Base64 之前使用的情境通常是在http的header中使用，比如oauth相關的應用，可是當打算於url中使用base64編碼時，就可以發生問題了，因為編碼中包含了"+"跟"/"，於QueryString使用需在編碼過，在Restful的api使用時，"/"更是會造成url路徑錯誤。 針對這個問題，Base64有一個變種，通常會說是URL and Filename Safe Alphabet，符合 RFC4648, Section 5. 規範，這個規範將"+"、"/"至換成"-"、"_"，並移除最後的"=" 二、Nodejs的Base64 encode與decode 在Nodejs常這樣用 var   code  =  new   Buffer ( "Base64是一種基於64個可列印字元來表示二進位資料的表示方法" ). toString ( 'base64' ); //code:QmFzZTY05piv5LiA56iu5Z+65pa8NjTlgIvlj6/liJfljbDlrZflhYPkvobooajnpLrkuozpgLLkvY3os4fmlpnnmoTooajnpLrmlrnms5U= console . log ( "code:" + code ); var   decode  =  new   Buffer ( code  ,  'base64' ). toString (); //decode:Base64是一種基於64個可列印字元來表示二進位資料的表示方法 console . log ( "decode:" + decode );
閱讀完整內容