さくらVPSの初期設定手順
はじめに
先日、さくらのVPSを触る機会がありました。
今後も機会がありそうので、初期設定の手順を残しておこうと思います。
ちなみに、ここでいう初期設定とは、
- ユーザーの作成と鍵認証
- SSHの接続設定
- sudo の設定
くらいです。
環境
さくらVPS(CentOS 6.8)
作業用PC(Mac OS X)
サーバの起動
上記の手順でサーバーを起動します。
初回の起動は、かなり時間がかかります。
コンソールを確認すると、
Updating RPMS on system
でフリーズしているかのように見えます。
時間がかかる理由は、古いRPMのパッケージが一気に更新されるためですが、フリーズしているわけではありませんので、待っていればそのうち終わります。
待つしかありませんので、本でも読みながら気長に待ちましょう。
サーバーが起動したら、さくらから送られてきている(はずの)アカウント情報でサーバーに root で接続します。
ログインできたら、パスワードは
# passwd
で変更しておきます。
ユーザー作成
作業用のユーザー(arfyasu)を作成します。
# useradd arfyasu # passwd arfyasu
続いて、鍵認証にしてパスワードを入力せずに接続出来るようにします。
鍵の生成と接続設定
作業用PCで秘密鍵と公開鍵を生成します。
$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/Users/user/.ssh/id_rsa): /Users/user/.ssh/sakura Created directory '/Users/user/.ssh'. ← ~/.ssh がない場合、ディレクトリを作成します Enter passphrase (empty for no passphrase): ← パスフレーズを入力します Enter same passphrase again: ← もう一度パスフレーズを入力します
.ssh ディレクトリに sakura と sakura.pub が作成されます。
ssh で接続する際、上記で作成したキーを使用するために、.ssh/config に下記の設定を追加します。
$ vi .ssh/config Host sakura HostName xxx.xxx.xxx.xxx ←サーバーのIPを指定します User arfyasu IdentityFile ~/.ssh/sakura
公開鍵の設置
作成した公開鍵(sakura.pub)をサーバーに転送します。
$ scp .ssh/sakura.pub arfyasu@サーバーのIP:
転送した公開鍵を設置し、鍵認証でssh 接続出来るようにします。
# mkdir .ssh # chmod 700 .ssh # mv sakura.pub .ssh/authorized_keys # chmod 600 .ssh/authorized_keys
公開鍵が設置出来たら、作業用PCのターミナルでサーバーに接続できるか確認します。
$ ssh sakura
接続できればOKです。
SSH接続設定
root 及びパスワード認証による接続ができないよう、SSHの設定ファイルを変更します。
# vi /etc/ssh/sshd_config -- #PermitRootLogin yes => PermitRootLogin no ← ルートユーザでのログインを無効にする PasswordAuthentication yes => PasswordAuthentication no ← パスワード認証を無効にする
設定ファイルをが変更できたら、サービスをリロードします。
# /etc/init.d/sshd reload Reloading sshd: [ OK ]
sudo 設定
作業用ユーザに sudo コマンドが実行できるよう権限を与えます。 root のパスワードを共有することなくルート権限を使うことができるので便利です。
作業用ユーザーを wheel グループに追加し、wheel グループに所属するユーザーが sudo コマンドを実行できるよう設定を変更します。
# usermod -G wheel arfyasu # visudo -- ## Allows people in group wheel to run all commands # %wheel ALL=(ALL) ALL => %wheel ALL=(ALL) ALL
確認してみましょう。
# pwd /home/arfyasu # touch ../test touch: cannot touch `../test': 許可がありません # sudo touch ../test [sudo] password for arfyasu: arfyasu のパスワードを入力
sudo が使用できることが確認出来ました。
まとめ
ミドルウェアを入れる前までの基本的な設定をまとめてみました。
ファイアウォール(iptables)の設定はまだ良くわかっていないので載せていません。
また、勉強して別エントリーでまとめられたらと思います。
- 作者: 福田和宏
- 出版社/メーカー: ソーテック社
- 発売日: 2016/03/31
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
Ruby のプロジェクトで RSpec のテストがパスするまで
はじめに
仕事で Rails を使わないピュアな Ruby のプロジェクトで開発をすることになり、RSpec のテストがパスするまでに少々はまったので、恥を忍んでまとめておきます。
RSpec を動かすまでの手順については、こちらのサイトの手順を参考にさせて頂きました。 qiita.com
環境
rbenv 1.0.0
ruby 2.3.0
事前準備
rbenv で ruby をインストールしておいて下さい。
ディレクトリ構成
今回作成するプロジェクトのディレクトリ構成です。
ソースコードは src 以下に、テストコードは sprc 以下に作成します。
rspec_sample ├── Gemfile ├── Gemfile.lock ├── src └── spec
初期設定
プロジェクトのディレクトリを作成し移動します。
ついでに、ソースを作成する src フォルダも作成しておきます。
$ mkdir rspec_sample $ cd rspec_sample/ $ mkdir src
rbenv で使用する ruby のバージョンを指定します。
bunlder をインストールしていない場合、インストールします。
$ rbenv local 2.3.0 $ gem install bundler
bundler にて rspec をインストール
bundler を初期化しGemfile を生成します。
$ bundle init
Gemfileを以下のように修正します。
source "https://rubygems.org" gem "rspec"
rspec をインストールします。
$ bundle install --path vendor/bundle
rspec の初期設定
.rspec, spec/spec_helper.rb を生成します。
$ bundle exec rspec --init create .rspec create spec/spec_helper.rb
src 以下のファイルを読み込むよう、spec_helper の最後に以下を追記します。
Dir.glob(File.join(File.dirname(__FILE__), "../src/**/*.rb")).each { |f| require f }
上記を追加することで、各 spec ファイルの先頭で必要なファイルを読込まなくても
require 'spec_helper'
をしてあげれば事足りてしまいます。
Rails ぽくて良い感じです。
コードの作成
以下のような構成になるようファイルを生成します。
rspec_sample ├── Gemfile ├── Gemfile.lock ├── src │ ├── libs │ │ └── message.rb │ └── person.rb └── spec ├── libs │ └── message_spec.rb ├── person_spec.rb └── spec_helper.rb
libs/message.rb の作成
src/libs/mesage_spec.rb
spec/libs/mesage_spec.rb
上記を作成して、rspec を実行します。
$ bundle exec rspec
結果がグリーンになってますね。なっているはずです!
person.rb の作成
src/person.rb
message.rb をロードする際、require_relative を使って、相対パスでファイルをロードします。
require 'libs/message'
のように指定して rspec を実行すると、下記のようなエラーが表示されます。
LoadError: cannot load such file -- libs/message
Rails を使用するとファイルの読込はフレームワーク側でやってくれるので意識する必要はありませんが、今回ここではまりました(^^;
sprc/person_spec.rb
message_spec と同様に、先頭に require 'spec_helper'
すればいいのでスマートですね!
上記を作成して、rspec を実行します。
$ bundle exec rspec
結果がグリーンになっていればOKです。
最後に
Rails を使っているときには気づきませんでしたが、Rails の便利さに如何に頼っているかを思い知らされますね。
逆に、Rails を使わないと出来ないことが多いのは、それだけ Rails が優秀だということにもなりますが、、、
RSpec を動かすのに、require_relative ではまるとは...
自分のあまりの無知っぷりに恥ずかしくなりました。
それでも、Ruby という言語を理解できていないからこそ、問題に直面したときに自力で解決できないと思うので、Rails のことを学ぶことも大事ですが、その言語自体をきちんと理解することが大事だと改めて思いました。
今回のサンプルコードと Ruby のプロジェクトのテンプレートをgithub にpushしたので、こちらもよければお使いください。
- 作者: Peter J.Jones
- 出版社/メーカー: 翔泳社
- 発売日: 2015/01/19
- メディア: Kindle版
- この商品を含むブログ (3件) を見る
新入社員研修のサブ講師をして学んだ事
はじめに
4月の末から20日間(プログラミングとインフラの研修を10日間づつ)に渡り、 とある企業の新入社員研修のサブ講師をしてきました。 本当に大変だったけど、学んだ事がたくさんあったので、忘れないために、ブログにまとめておこうと思います。
従来の講義形式では身につかない
メインの講師が前で講義を行い、サブ講師が受講生の質問に答えるというスタイルの講義形式を想定していました。
座学の形式ですね。
これでは、受講生は眠くなってしまうし、自ら学ぼうとする意識が芽生えずモチベーションも上りません。
なので、座学形式での研修はすでに成り立たなくなってきているとのことでした。
受講生が講義を通して何を学ぶのか。
興味や目的意識、競争環境を作り、受講生が自ら積極的に学ぼうとする意識づけをすること(ARCSモデル)が大切だと、先輩講師から教えてもらいました。
でも、これめちゃくちゃ難しい!
メイン講師と毎日PDCAを回して、より良い講義形式にしようと協議しました。
これは良い取り組みだったと思います。
例えば、
- 講師が課題を与え、それに対して何人かでディスカッションをし発表しあう
- 受講生が講師の立場となって教える
- 実習の成果をプレゼンし、どこが良かったか受講生と講師で評価する
などを行いましたが、受講生のやる気スイッチを入れるにとても効果的でした。
自分で解決できる力を育てる
「魚を与えるのではなく、魚の釣り方を教えよ」というのは、有名な言葉です。
人に魚を与えてもその時は良いが、翌日また同じことで悩んでしまいます。
魚の釣り方が分かれば、一生食べていけることから、その人のためを思うならば、魚の釣り方を教えるべきと言われています。
これを講師の立場で心がけましたが、実践するのは中々難しかったです。
理由は、答えを教えてしまう方が簡単だから。
そこをぐっとこらえ、グーグル先生との上手なつきあい方、リファレンスの使い方などを伝えて自分で解決する方法(というより、解決する情報を入手する方法)を伝え、それでも分からないことは教えるようにしました。
ただ、プログラムで全く何を書いて良いのか分からない人には、横について一緒に作業をして(ペアプロで)、コーディングの流れを理解してもらうことも大事だったり。
結局は、人によって教え方を柔軟に変えないと行けないのかなとは思います。
抽象化能力は必須
何かを教える時、ありのまま伝えても理解することはなかなかできません。。
例えば、Webサーバーとアプリケーション・サーバーのそれぞれの役割を説明する場合、
Webサーバーは、ユーザのリクエストを受付け、アプリケーション・サーバーに渡し、結果を返す。
アプリケーション・サーバーはリクエストに合わせた処理を行い、処理結果をWebサーバーに返す。
などと説明しても絶対に理解してもらえなません。
(上の説明も言葉が足りなくて分かりにくいというのもありますが、、、)
そうではなく、身近なものに例えて伝えて伝えることが大切で、
例えば、お客さんの電話対応を例に取って説明すると理解しやすいです。
- まず、お客さんからの問合せ受付をオペレータが行います。
- オペレータが処理できるものは自分で処理しますが、調査が必要なものは専門部署に問合せを行います。 (その間、お客さんにはお待ちいただきます。)
- 専門部署は、オペレータからの問合せを受け、調査した結果をオペレータに伝えます。
- オペレータは調査結果をお客さんに伝え対応を終了します。
この場合のオペレータが Web サーバー、専門部署がアプリケーション・サーバーです。
と、専門的な説明を行う前に身近な例を出すことでイメージしてもらうことが大事です。
この身近なものに例えて伝える能力で絶対に欠かせないのが抽象化能力。
この能力が乏しいと身近な例との関連付けができません。
物事を抽象化して捉える、身近なものと関連付けることができれば、こうした説明をすることが可能です。
この能力を磨くことができれば、伝える能力が向上するはずだと気づきました。
ベクトルは自分ではなく受講生に向ける
受講生には講師から積極的にコミュニケーションをとらないと駄目です。
分かってはいたことだけど、最初はどう声がけしていいのか分からずにかなり悩みました。
これは心構えですが、いかに自分にベクトルを向けて生活していたかに気付かされました。
最初、受講生の質問に答えられなかったり、間違ったことを答えて馬鹿にされるのは嫌だなと考えていました。
これは、自分がどう思われるかばかりを気にかけ、受講生を全く見ていません。
自分にベクトルが向いている状態。
これが受講生に積極的に声がけできない原因だったのは言うまでもありません。
こんな気持ちで講師をしていた自分をめちゃくちゃ恥じました。
これでは駄目だと早い段階で気づき、
- 受講生に何を伝えられるか
- どうしたら受講生に違った視点を与えられるか
など、受講生に意識を向けることで、受講生とスムーズに話すことが出来るようになりました。
正直、間違ってしまったことを伝えてしまってもゴメンと謝れば問題ありませんでしたし、それによって受講生との信頼関係が壊れることはありませんでした。
杞憂でしたw
相手の言っていることを正確に理解する
受講生から質問された内容を間違って把握することが良くありました。
受講生の質問を2人の講師で聞いた時、講師間で答える内容が異なるという。
そして、たいてい私が受講生の質問の意図を正しく把握できていません。
他人の言っていることを、正確に理解することは本当に難しいと感じました。
理由を考えてみると、相手の言った曖昧な部分を無意識のうちに自ら補完し、その部分の認識が違っているため話が噛み合わないことが多かった気がします。
これもコミュニケーションの課題の1つだと思うけど、コミュニケーションについては課題が山盛りなので、もっと勉強したいなと改めて思いました。
最後に
これまで、社内の新入社員研修を少しやった程度の経験しかなく、サブ講師とは言え50名を超える人数の研修を担当したことはありませんでした。
最初は不安で仕方がなく、研修が始まった時は、正直20日間もたないと思った。
自分の力不足に悩み、何度も心が折れそうになった。
最初の10日のみにしておけば良かったと何度も後悔したw
でも、終わってみれば多くの学びが得られ、とても貴重な経験をすることができました。
挑戦して本当に良かったと心から思っています。
今後、機会があれば今回の失敗を改善してまた挑戦したい。
でも、開発している方が自分の性分には合っているとは思っています。
講師をする前に読んだ本の感想
arfyasu.hatenablog.com