LinuCの試験について

こんにちは。22年度入社の中島です。

この間、Linux資格のLinuCを受験しました。
今回私が受けたのは、LinuCレベル1(101試験)になります。
この試験は、101試験と102試験があり、認定されるためには2試験を(片方を合格していたら5年以内に)合格する必要があります。

今回は、LinucCレベル1 101試験を受けた感想や試験の内容を簡単に書いていこうと思います。

Linux技術者認定「LinuC(リナック)」とは
クラウドやDX時代のITエンジニアに求められるシステム構築から運用管理に必要なスキルを証明できる技術者認定です。

・受験動機
この試験を受ける理由は、仕事に対する自信につなげられるようにするためと、これからの業務の役に立つと思い受験しました。

・予約と受験方法、前日までの準備について
今回はオンラインでの受験だったので、テストセンターでいかなくてよかったのですが、
試験を受けるにあたっての、本人確認書類の用意、受験スペース準備や規則などが大変でした。

・試験対策と試験概要
対策として、テキストでの学習や過去問を解くなどをしていました。一日に学習する範囲を決めてやったり、章まとめの問題集を何回も解きなおしていました。

LinuCレベル1(101試験)は試験時間は85分で出題数は60問でした。
以下は試験囲です。

第1章: Linuxのインストールと仮想マシン・コンテナの利用
第2章: ファイル・ディレクトリの操作と管理
第3章: GNUとUnixのコマンド
第4章: リポジトリとパッケージ管理
第5章: ハードウェア、ディスク、パーティション、ファイルシステム

・勉強してみた感想
Linuxのことを何もわからない状態からのスタートだったので、なんとなく理解するのにも時間がかかりました。
特にコマンドとそのオプションを覚えきれず、とても苦労しました。

・結果と感想
結果は残念ながら不合格でした。
1~5章の全範囲まんべんなく出ていたので、全体的に復習が必要だと思いました。
受験した感想といたしましては、どのような形で問題が出されるのかわからず、緊張して問題とくペース配分がうまくいかず、時間が掛かりました。
それによって見直しを行う時間がありませんでした。
また、第3章、第4章のコマンドを忘れていたり、コマンドは合っているのにオプションを間違えてるなどのミスが目立ちました。

今回の試験で自分の努力不足をとても感じました。次回受験する際には過去問やりこみ、解くスピードを上げて見直しをする時間を作りたいと思います。模擬試験で正解8割を安定して出せるようになってから再度、受験したいと思います。

現在は、ping-tというサイトを使って過去問を解いています。
このサイトは、試験範囲・問題数・出題形式まで自由に決めることができて便利です。
間違ってもわかりやすい解説があるので、おすすめです。(アカウント登録が必要です。)

https://mondai.ping-t.com/users/sign_in

いかがでしたでしょうか。

久しぶりのブログでしたが、よいネタを見つけたら投稿していきたと思います。

最後までご覧いただきありがとうございました!

Linux学習についてのまとめ 01

こんにちは。22年度入社の中島です。

最近はLinuxの資格であるLinuCを受験するために、Linuxの学習をしています。
今回は復習も兼ねて学習したもの、実際に使ったものの一部を紹介したいと思います。

 

shutdownコマンド
私が最初に覚えたコマンドで、システムを安全に停止するコマンドです。

12:00に時間指定でシャットダウンする場合

[crayon-65d68f1f72110380798516  ]shutdown -h 12:00[/crayon]

すぐに再起動する場合

[crayon-65d68f1f7211e389782661  ]shutdown -r now[/crayon]

私がこのコマンドを使うときは、オプションの-rをよく使います。

書式 shutdown [オプション] 時間 [メッセージ]

オプション
-h  シャットダウンする
-r  シャットダウン後に再起動

 

cpコマンド
ファイルやディレクトリをコピーするコマンド。
業務では、WinSCPなどで追加したVMの共有フォルダからファイルをコピーするとき以下のようなコマンドでファイル情報を保持するオプションをつけ実施しました。

[crayon-65d68f1f72127406272254  ]cp -rp vagrant/html/* /var/www/html[/crayon]

書式 cp [オプション] コピー元ファイル名 コピー先ファイル名
   cp [オプション] コピー元ファイル名 コピー先ディレクトリ

オプション
-f  コピー先に同名のファイルがあれば上書きする
-i  コピー先に同名のファイルがあれば上書きするかどうか確認する
-p  コピー元ファイルの属性(所有者、所有グループ、アクセス権、タイムスタンプ)を
   保持したままコピーする

 

chownコマンド
ファイルに設定されている所有者を変更するコマンド。
業務ではApacheを起動する際、所有者が違ったのでオプションの-Rを使って対象ディレクトリの全ファイルの所有者を変更しました。

[crayon-65d68f1f72130783979866  ]chown -R root vagrant[/crayon]

書式 chown [オプション] ユーザー [:グループ] ファイル名やディレクトリ名

オプション
-R  指定したディレクトリとその中にある全ファイルの所有者を変更する

 

lsコマンド
ディレクトリを指定した場合は、そのディレクトリ内のファイルを表示します。ファイル名を指定した場合は、そのファイルの属性を表示します。何も指定しない場合は、カレントディレクトリ内のファイルを表示します。ドットファイルも参照したかったため、以下のようなコマンドを実行して確認しました。

[/crayon]

書式 ls [オプション] (ファイル名あるいはディレクトリ名]

オプション
-l  カレントディレクトリにあるファイルの詳細設定を表示
-A ドットファイルも含めて表示。ただし./ および ../ をのぞく
-a  ドットファイルも含めて表示。

 

grepコマンド
ファイルやテキストの中に、 正規表現によって表される検索文字列があるかどうかを調べます。引数にファイルを指定した場合、そのファイルの中で検索パターンにマッチした文字列が含まれる行をすべて表示します。


オプションの-nをつけることで、自分の探している文字が何行目にあるかを確認することができます。

書式 grep [オプション] 検索パターン [ファイル名]

オプション
-n  検索結果とあわせて、行番号も表示する

 

いかがでしたでしょうか。

LinuCは、試験レベルが3つありレベル1の試験は、「101試験」と「102試験」の2試験に合格するとレベル1合格になります。Linuxの復習しながら、ブログの続きとしてを出していけたらと思います。

今回はここまで
最後までご覧いただきありがとうございました!

 

S3+CloudFront+Route 53を使った静的コンテンツ配信 Part 2 (lambda@edge編)

福岡拠点の野田です。

前回、S3を使った静的コンテンツ配信を実現しましたが、ちょっとカッコ悪い点がありました。

ドメイン直下については、 Default Root Object 設定すると https://サイト名/でアクセスしたときindex.html を参照するようにできます。ただし、サブディレクトリ配下はDefault Root Objectの設定が効きません。サブディレクトリ配下で/news/とアクセスしたとき、/news/index.htmlを参照するためにはlambda@edgeを使う必要があります。

/で終わるuriの場合に/index.htmlを参照する設定について、今回は以下の流れで設定を行います。

  1. lambdaを追加
  2. CloudFrontで使えるようにIAMを修正
  3. lambdaにトリガーを追加し、CloudFrontと関連付け

lambdaを追加

リージョンus-east-1のlambda画面から関数を追加します。ほかのリージョンではCloudFrontへのトリガーを作成できないため、正しいリージョンが選択されているか確認してください。

https://console.aws.amazon.com/lambda/home?region=us-east-1

lambdaは1から作る形で進めます。

・関数名:subdir-redirect (適宜適当な名前を設定してください)
・ランタイム:nodejs (バージョンはデフォルトでOK)
・アクセス権限:AWSポリシーテンプレートから新しいロールを作成
・ロール名:cloudfront-lambda (適宜適当な名前を設定してください)
・ポリシーテンプレート:基本的なlambda@edgeのアクセス権限

関数詳細ページが表示されるので、関数コードに以下を追加します。

[/crayon]

画面右上の「保存」を押下してコードを保存します。

CloudFrontで使えるようにIAMを修正

そのままでは使うことができないため、関数詳細ページ「アクセス権限」のタブを選択します。実行ロール「 cloudfront-lambda 」を編集し、末尾の「 IAM コンソールで cloudfront-lambda ロールを表示します。」のリンクをクリックします。

ロールの詳細ページから「信頼関係」のタブをクリックします。「信頼関係の編集」ボタンを押下して、以下のようにedgelambdaの設定を追加します。

[/crayon]

これにより信頼されたエンティティにedgelambdaが追加されます。

信頼されたエンティティ
ID プロバイダー lambda.amazonaws.com
ID プロバイダー edgelambda.amazonaws.com

続いて「アクセス権限」のタブに再度戻ります。+インラインポリシーの追加から以下のポリシーを追加します。

  • Lambda: GetFunction, EnableReplication (対象リソースは、先ほど登録したsubdir-redirect lambda のARNを指定)
  • IAM: CreateServiceLinkedRole(対象リソースはすべて)
  • CloudFront: UpdateDistribution(対象リソースは、展開するCloudFrontのARNを指定)

ここまでやってようやくlambda@edgeが使えるようになります。

lambdaにトリガーを追加し、CloudFrontと関連付け

仕上げにlambdaの関数詳細画面に戻ります。画面上の「アクション」から新しいバージョンを発行します。コメントは必要あれば適宜入力してください。

そののちにデザイナーから「トリガー」を追加します。トリガーの種類は、CloudFrontを選択します。ここでCloudFrontが選択できない場合はlambdaのリージョンが間違っていますので、最初からやり直してください。設定はデフォルトのままで以下のチェックボックスにチェックを入れます。

[/crayon]

追加ボタンを押下するとCloudFrontへの更新が入ります。Distributionの更新が終わるまでしばし待つと、晴れてサブディレクトリのリダイレクト処理を利用することができるようになります。

まとめ

lambdaというと単機能のAPIや軽量サーバーとして使うイメージが強いですが、実はいろいろなところに組み込めます。lambda@edgeを利用することでCloudFrontに対してヘッダーのカスタマイズ、 BASIC認証など多岐にわたって処理を組み込むことができます。静的コンテンツに対してちょっとした動的処理を行いたいな、というときはlambda@edgeの出番です。是非ご活用いただければと思います。

面倒なところもありますが、ひと手間かけるといろいろなことができるのがAWSの良いところ。いろいろエンジニアとしていろいろHackしていければと思います。

S3+CloudFront+Route 53を使った静的コンテンツ配信

福岡拠点の野田です。

WordPressで運用していた個人サイトをメンテしなくなったので、S3とCloudFrontとRoute 53を使って静的コンテンツ配信方式に切り替えてみました。手順の大きな流れは以下のようになります。

  1. S3にコンテンツを配置
  2. CloudFrontを設定
  3. Route53でCloudFrontへ振り分け

S3 にコンテンツを配置

まずは、wget で既存サイトを取得します。

[/crayon]

日本向けに配信することを考え、 S3 の東京リージョンにて新規バケットを作成して、上記取得したファイルを配置します。

S3における設定ですが、アクセス権限の設定を行います。静的コンテンツとして公開するため、以下のバケットポリシーのブロックをオフにすることで外部からのアクセスを行えるようにします。

  • 新規のパブリックバケットポリシーまたはアクセスポイントポリシーを介して付与されたバケットとオブジェクトへのパブリックアクセスをブロックするオフ
  • 任意のパブリックバケットポリシーまたはアクセスポイントポリシーを介したバケットとオブジェクトへのパブリックアクセスとクロスアカウントアクセスをブロックするオフ

バケットポリシーは、以下のようなCloudFrontからの接続を許可する設定を行いますが、CloudFront側から設定ができるため、ひとまずスキップで大丈夫です。

[/crayon]

CloudFrontを設定

Create DistributionでCDNを新規作成します。

  1. Web/RTMPの選択でWebを選択
  2. Origin Domain NameにS3のバケットを選択
  3. Origin Pathは空欄でOK
  4. Origin IDは任意のIDを設定(S3-バケット名みたいな感じで設定しました)
  5. Restrict Bucket Accessは、YES
  6. Origin Access Identityは、 Create a New Identity。
  7. Grant Read Permissions on Bucketは Yes, Update Bucket Policy (これが先ほどのS3バケットポリシーに反映されますので、一応S3側でも設定されているか確認)
  8. Viewer Protocol Policyは、Redirect HTTP to HTTPS (httpからhttpsリダイレクト)
  9. Allowed HTTP Methodsは、GET/HEADのみで対応(CORSを考えるとOPTIONSまでやってもいいかもしれません)
  10. Compress Objects Automaticallyは、true(圧縮化。転送量削減)
  11. Price Classはベストパフォーマンス
  12. AWS WAF Web ACLは、None
  13. Alternate Domain Namesは割り当てるドメイン名を改行区切りで入力。
  14. 証明書については、独自ドメインで割り当てる場合、ACMに登録したものを選択。
  15. 残りはデフォルトで登録

Distribution作成後、 GeneralタブでEditボタンを押下して、以下を設定します。

  1. Default Root Objectにindex.htmlを設定

続いて Restrictionsタブを選択して、GeoRestrictionをEditします。

今回は、日本のみを対象とします。全世界を対象とするとコストと直結します。1日1000円以上かかってもいい!どんな攻撃もどんとこい!という方以外は、対象を絞ったほうが良いと思います(私もこれで当初1日放置して1000円かかってしまい冷や汗、急遽制限を追加しました)。

Route53でCloudFrontへ振り分け

仕上げにRoute53からCloudFrontへ振り分けします。A(IPv4アドレス)およびAAAA(IPv6アドレス)のエイリアス指定でCloudFrontにつなげることができます。

まとめ

Cloudは設定をミスると高額な請求が発生してしまうリスクはありますが、うまく使えば個人で使っても安く運用することができます。最近では予算設定や請求が高額になりそうなときにアラートも出せる機能もありますので、そうしたものを組み合わせて、安全に運用すると良いと思います。先月からの運用の感じだとアクセス数次第なところがありますが、100円~300円/月ぐらいで運用できそうな感じでした。

初心者にはおすすめはしませんが、興味ある方は是非チャレンジしてみてください。

AWSでインスタンスを停止し、再起動した時にパブリックIPが割り振られない場合

AWS特訓中の宮里です。

AWSでインスタンスを作成したときに、少し困った現象があったため情報共有したいと思います。

AWSで作成したインスタンスを一旦停止後、ネットワークインターフェイスを追加し、再起動した後にパブリックIPが割り振られない現象が発生しました。

?????となりながら、再起動を何度か試すもパブリックIPは復活せず。
作成したばかりのインスタンスだったので、インスタンスを一から作成し直し、特に問題は起こりませんでした。
その後、気になったので原因を調べてみると、AWS公式のドキュメントに今回の現象の解答がありました。

下記、公式のドキュメントから一部引用します。

手動でパブリック IP アドレスをインスタンスに関連付けること、また、手動でインスタンスから割り当て解除することはできません。場合によって、パブリック IP アドレスはインスタンスから解放されたり、新しいインスタンスに割り当てられたりします。
インスタンスが停止または終了されると、インスタンスのパブリック IP アドレスは解放されます。停止していたインスタンスが再起動されると、そのインスタンスには新しいパブリック IP アドレスが送信されます。
VPC 内のインスタンスのパブリック IP アドレスが既に解放されている場合には、複数のネットワークインターフェイスがインスタンスにアタッチされていると、インスタンスに新しいパブリック IP アドレスは送信されません。

出典:
AWS ドキュメント「パブリック IPv4 アドレスと外部 DNS ホスト名」

インスタンスを再起動するときは、プライマリENI以外はインスタンスにアタッチしてはいけないということでした。。。

少しづつ身につけていきたいと思います。

AWSのタイムゾーン設定でハマった件

福岡拠点の宮里です。
先日、アパッチのアクセスログをアーカイブして一定期間保存する作業を行っていたのですが、

apache-loggenでダミーアクセスログの生成

ログを確認していると、何か違和感が…

|02/May/2018:09:24:59 +0000|

私「あれ?もう出社して9時間は経ってて、もう今日も終わっちまうのかなぁって気がしていたけど」

心の中の金子賢「バカヤロー、まだ始まってもいねーよ」


サーバー時刻をUTCからJSTへ変更

あれあれあれと心を鎮めながら、サーバーに設定されているタイムゾーンを確認してみると、

このサーバーのタイムゾーンはUTC。
このままだとなにかと不都合です。
心臓にもわるいので、JST時間帯へ変更したいと思います。

sysconfigディレクトリの設定ファイル(clock)からタイムゾーンを修正します。
ひとまずバックアップ取って、

シンボリックリンクの向き先Asia/Tokyoへ変更します。

サーバーのタイムゾーンがUTCからJSTに変わりました。

これでひと安心かと思いきや、
この作業を行う前にすでに記録されているログの時刻をJSTに修正しないと何かと収まりがわるいです。
なので、USTで記録されているログをJSTへと変換するスクリプトを作りたいと思います。


既に出力されているログの時刻をJSTへ修正

スクリプトは、サーバーに標準でインストールされているpythonで作成してライブラリをひとつだけ追加します。

pytzの取得

JSTへ変換するスクリプト
changeJst.py

粗いスクリプトですが、ひとまず期待通りに動くことが確認できましたので、作業するサーバーのhttpdを停止してスクリプトを実行しました。ちなみにAWSのELBがunhealthyを認識して振り分けを開始するまで約1分~2分ほどかかるようです。認識する前にhttpdを止めると502で振り分けもされなくなるので注意が必要です。

処理するディレクトリのバックアップを取って実行。

なんとか完了です。
サーバー時刻もUTCからJSTへ変更します。
その後、httpdを再起動。
無事に現在時刻が18時に修正されました。
やっと終わっちまえます。


あれ、cronの実行がおかしい

それから様子をみること数日。
dateコマンドやログに出力される時刻はしっかりUTCからJSTに変更がされているけど、cronに設定したタスクの実行時間がおかしい!どうにも9時間遅れて実行されている!と気づきました。
調べてみるとサーバーのタイムゾーンを変更しただけではcronの実行時刻への反映がされないようです。crondを再起動してJSTタイムゾーンの反映が必要でした。。。

crontabの設定ファイルへtimezoneを記述して、crondの再起動。

これでcronの実行時間にもJSTが反映されました。

VPSサーバーのリソース不足を回避する方法

福岡拠点の野田です。もうすぐ花見の季節ですね。来週か再来週あたり、お昼休みの合間を縫って花見に行きたいと思っています。

さて、今日は、仮想サーバーのリソース状況について話をしようと思います。
皆さんは、VPS環境で以下のような画面を見たことがありますでしょうか。開発用だったり、低予算の貧弱な環境では、結構こういう場面に遭遇することもあります。

上記は、composer を実行した際に発生したエラーです。このエラーがでたあと、httpd をいったん停止してから実行すると普通に実行できたりします。これは、仮想サーバーのリソースが不足するために発生しているエラーになります。こういうときは、都度、エラーが出るたび、httpdを止めて、ということをしなければいけないのでしょうか。

仮想サーバのリソース状況をチェックするには以下のようなコマンドがあります。

この中のprivvmpagesという値に注目します。これは、プライベート仮想メモリサイズです。リソースを解放するためには、httpd など消費リソースが大きいサービスを再起動するとリソースが解放されます。

以下は、リソース情報をチェックし、閾値を越えてリソースが足りない状態になると httpd サーバーを再起動するスクリプトになります。

/root/bin/restart.sh

シェルを毎分 cron 実行したら、リソースがないときは、httpdを再起動して、適宜、リソースが解放されるという仕組みです。

ちなみに800 というのはなんとなくの感覚値です(・ω<) 。某VPSサーバーでは、httpd を再起動すると 3000 くらいまで回復します。300 とか切るとセグメンテーションエラーとかメモリ関連のエラーがよく発生します。

これでサーバーのリソース不足でエラーとなるイライラも収まるでしょう。それでは、Have a nice server life!