git challenge #8 2018.02.03 に参加しました
株式会社mixiさんが開催している技術イベント "git challenge"に参加させて頂きました.
「ブログに書くまでがgit challenge」(mixiのエンジニアさん談)との事だったので,参加した感想とか書いていきたいと思います.
git challengeとは
git challengeは、git/GitHubを使う上で起こり得るトラブルに関する問題群を2人1組で制限時間に解き,獲得ポイントを競う形式のイベントです. CTFや競技プログラミングのような競技形式をイメージして頂ければと思います.*1
2015年11月に第1回,それから年2回のペースで開催され,今回が第6回となります.
参加に至るまで
2016年の夏にmixiさんのインターンに応募(落ちたけど)して以来,gitchallengeの案内のメールが届くようになって,興味があったのでgit多少使えるようになったら応募してみてもいいかなーって思ってたので挑戦したって感じです.
レベル高いイベントだったら怖いなーって尻込みしてたんですけど、多分エントリーした時はお酒入って判断力鈍ってたのでお酒は偉大
あと大きな理由の1つは交通費がある程度支給されるって事でしょうか,つくばと渋谷の往復は地味に交通費かかるので助かりました.TX高いですね
前日
前日に過去問*2をちょっと確認しました.これを見たから当日の問題を解くのが楽になった訳ではありませんが,問題の雰囲気はだいぶ掴めるのでこれから参加する方は見ておくと良いと思います.
ちなみに前日の行動に関する一番の後悔は「夜に脂っこいもの食べた上に卒論関係のレポートに追われて睡眠時間を削った事」です,おかげで当日の体調が結構厳しかった記憶があります
当日
むっちゃ腹痛い (@ ベルサール渋谷ファースト in 渋谷区, 東京都) https://t.co/oCIrLkDmCi
— はくまい (@inside_hakumai) 2018年2月3日
いた #mixi_git pic.twitter.com/sAmZ72Wf4E
— はくまい (@inside_hakumai) 2018年2月3日
当日会場で受付を済ませたのち指定された座席に移動し,そこでチームの相方と対面しました.この手の競技イベントは初めてだった上に結構なコミュ障なのでマトモにコミュニケーション取れるか心配でしたが,相方が穏やかな大変話しやすい方だったので感謝です.
その後,チュートリアルと昼食の後,競技開始となりました.
git challengeの第8回大会が開始となりました。毎回天気に恵まれて嬉しい限りです。各サービスのgit事例を共有したのちに、只今チュートリアル中です。 #mixi_git pic.twitter.com/7mofbc1S4D
— ミクシィグループ 新卒採用公式アカウント (@HR_mixi) 2018年2月3日
節分の日だったので昼食では恵方巻きを頂きました.美味しかったです.
肝心の競技ですが,問題の内容については口外を控えるように,との事だったので詳しいことは述べられませんが,問題の難易度が複数設定されておりgitの初歩的な操作に関する問題からgitの構造に関する深い理解を求められるものまで非常に多様でした. 自分のチームは相方が簡単な難易度の問題から,自分がちょっと難しい難易度の問題を並列で消化していく方針で取り組みました.問題数が存外に多かったので,問題の割り振りの方法はともかく多分どのチームも並列で消化していたのではないかなと思います.
問題への解答はremoteのリポジトリに解答となるブランチをpushすることで行いますが,pushするとremote側で即時採点が行われ,結果が会場正面のスコアボードに反映されるのが面白いというか楽しかったです.競技プログラミング系統のイベントってどれもこんな感じで進行するんでしょうか.
競技開始から約1時間が経過しました。解答内容をリセットする「リセットセンター」には随時お越しになっています。そして、まもなくおやつの時間です。 #mixi_git pic.twitter.com/a2KSxnnlq6
— ミクシィグループ 新卒採用公式アカウント (@HR_mixi) 2018年2月3日
3時間半の競技の後,問題の解説と順位発表が行われました.
1位が同率で3チームという異例の事態でしたが,ありがたいことにその3チーム中のひとつが自分のチームでした. 相方が分からなかった問題を自分が解いたり,逆に自分が分からず後回しにしてた問題を相方が解いてくれたり,うまく連携できたのが良かったのかなって思います.今回は本当に相方に恵まれたと思いました.ありがとう.
4位以下も1,2問差で複数のチームが続くなど,だいぶ接戦だったという印象です. 競技中Webで調べる等の行為は認められていたので,一定の難易度まではなんだかんだ解ける,というのが接戦になった要因だったのではないでしょうか,逆にそれ以上の難易度は調べる云々の前にどうやって調べれば良いのか分からないようなgitへの理解を求められるものだったので,それで上位も一歩先に出るようなチームがなかなか出てこなったんじゃないかなって思います.
mixiの方も3チーム同率1位は想定していなかったようで,1位の副賞が2人分しか用意されておらずその場でじゃんけんによる争奪戦に.この日は相当ツキが回ってきていたのか,こちらも勝ててしまったのでありがたく副賞を頂戴しました. オクトキャットのフィギュアです.名前始めて知った.
ところでこれひげの部分どうやって取り付けるんでしょうか,それっぽい穴はあるんですがどうにも小さい.接着剤とかで無理矢理固定するのかな. ご存知の方いましたら教えて頂けると幸いです.
競技終了後
競技終了後はmixiの方々との懇親会がありました. 本場のエンジニアさんの開発に関する話を聞けたりしてとても楽しかったです.ただやっぱり当日の体調がお察しだったので,ほろよい1缶で嫌な酔い方してあんまり料理を戴けなかったのが後悔ですね.体調管理気をつけましょう.
所感
GUIクライアントによる可視化が便利
やっぱりgitのGUIクライアントが使えると便利ですね,コミット間の依存関係やブランチが切られた位置などが見やすく可視化されるのでそれぞれの関係を把握する上でだいぶ助かりましたし,競技中の時間の削減になりました.
と言ってもCUIを全く使ってないかと言われるとそうではなくgit remote add
やgit push
、git clone
などはコマンド叩いた方が早かったのでCUIを使用していましたし,問題の一部はCUIのコマンドに関する知見を前提とするようなものでした.
因みに競技中のルール上GUIクライアント使って良いかという話ですが,そこは特に制限されていないようです(競技開始前の説明の中でちょっとだけGUIの使用に言及されてましたし,過去の記事*3では過去の優勝者がSourceTreeを使っていた旨の記述があります)し,この競技の趣旨はgitを扱う上での問題解決に関する知見を得ることだと認識しているので,GUIクライアントを使ってもその趣旨から逸脱することにはならないでしょう,多分
ちなみに自分が使ってるgitクライアントはGitKraken*4です.
gitに関わる様々なケースの問題を体験できた
単純なpush時のrejectやコンフリクト解決の場面から,もっと複雑なケースまで様々な問題を体験できました.
gitの内部構造に関する知見を得られた
gitを普通に使っているだけでは触れる機会の少ないgit内部の構造の話に触れることができました.と言ってもちょっと話を聞けただけで体系的に理解できた訳ではありませんが.
ちなみにmixiのエンジニアさんが紹介していたgitの内部構造に関する解説のページはこちら*5です.
参加の敷居が高くない
出題された問題は,一番難しいものではそれこそgitの内部構造に関する理解を求められるものでしたが,簡単なものではgitの初歩的な使い方に関するものもあり,問題の難易度が非常に幅広いという印象を受けました.さらに競技中は資料の参照なりGoogle先生に頼るなりも認められていたので,競技の敷居がある程度低く設定されていて参加しやすいと思いました.
と言っても競技中に調べるにしても「躓いた問題に対して,どういう検索ワードで調べれば解決に繋がる情報が出てきそうか」が分からないとどうにもならないので,その程度の理解は求められると思いますが.
おわりに
そもそも技術系のイベントに参加するの自体始めてだったので一時はどうなることかと思いましたが,参加してみると得るものの大きいイベントだったと感じています.
mixiの方々には当日大変お世話になりました.大変有意義なイベントでした.ありがとうございました.
ちなみに競技中一番「知っててよかった」って思ったコマンドはgit cherry-pick
でした.ありがとうcherry-pick.
参考文献(2018.02.08 閲覧)
http://alpha.mixi.co.jp/entry/2015/11/24/083300 https://matome.naver.jp/odai/2145498307629534701 https://mixi-recruit.snar.jp/jobboard/detail.aspx?id=QSmdeVlbclE http://alpha.mixi.co.jp/entry/2017/08/03/113000 http://alpha.mixi.co.jp/entry/2017/07/27/113000
はてなIDは後から変更できないという話と、記事の移行の話
はてなブログを普段から使っている人には公然の事実なのかもしれないけど。
はてなIDは変更できない
はてなIDは新規登録時に一度決めると登録後は変更できない。
以下はてなブログのヘルプ引用。
http://www.hatena.ne.jp/faq/qa/login#190190366963115843
Q . はてなIDの変更はできますか?
A . いったん登録されたはてなIDは変更することはできません。退会してから再登録をお願いします。なお退会されますと二度と同じはてなIDはご利用いただけませんので、十分お気をつけください。ご不明な点がございます場合には、退会をされる前にはてなまでお問い合わせください。
ということで、はてなIDを作り直してはてなブログも作り直した。
そもそも、何故はてなIDを作り直したくなったかというと、
という理由があり。 twitterのscreen_nameは容易に変更できるのでこっちを変更してはてなIDに合わせても良かったのだが、2、3番目の理由の通り、とにかくはてなIDを変更したかったので却下。 3番目の理由に関してはだからなんだっていう話でもあるのだが、まあちょっと気持ち悪いので。
ブログの記事の移行
ここで、はてなIDを変更するにあたって気になるのが「以前のはてなブログどうにか移行できないか?」っていう話。
はてなブログには記事データをエクスポートする機能が存在する。
ブログの設定画面の左のツールバーから「設定」の内部から「詳細設定」タブを選択、その下部に「エクスポート」という項目がある。
ここからブログの記事のデータをMovableType形式のテキストファイルで取得できるので、これを利用して以前のはてなIDのブログのデータを取得する。
その後、新しく取得したはてなIDからブログの設定画面にアクセスし、左のツールバーから「インポート」を選択。
表示されるフォームから先程エクスポートしたファイルを選択。
これで記事のインポートができる。
ただし、元の記事で押されたスターなどの一部の情報は引き継がれない模様。
また、インポートした記事を確認すると画像は問題なく表示されているが、URLを確認すると以前のはてなIDでアップロードしたファイルを参照しているだけのようなので、以前のはてなIDの退会等を行った後に画像のリンクが切れるかどうかなどは不明。
もしかしたら退会前にアップロードした画像を一通りローカルに保存して、新しいはてなIDで再度アップロードする、といった作業が必要になるかもしれない。
おわり
そもそもそこまでちゃんとした記事を書いていた訳でも相応の量を書いていた訳でもないので、わざわざ移行する必要無かったかなって思うけど、まあせっかく書いたので、ということで
MacでEmacsにパッケージを導入するまで
VSCodeやらAtomやらばかり使っていて久しくEmacsに触れていなかった間にパッケージの導入方法を完全に忘却していたので備忘録として。
環境
今回の作業環境は以下の通りです。
最新版のEmacsのインストール
Macにデフォルトでインストールされているバージョン22のEmacsはパッケージの管理に関する機能が搭載されていないなど、色々と不都合があります。(現時点での最新版は25.2)
Homebrew-Caskを使用して最新版のEmacsをインストールします。
“Homebrew"はmacOS用のパッケージマネージャー、"Homebrew-Cask"はHomebrewで扱うパッケージの範囲をGUIアプリケーション等まで拡大したものですが、ここでは詳しい説明は省略します。
$ brew cask install emacs ==> Downloading https://emacsformacosx.com/emacs-builds/Emacs-25.2-universal.dmg ######################################################################## 100.0% ==> Verifying checksum for Cask emacs ==> Installing Cask emacs ==> Moving App 'Emacs.app' to '/Applications/Emacs.app'. ==> Linking Binary 'Emacs' to '/usr/local/bin/emacs'. ==> Linking Binary 'ctags' to '/usr/local/bin/ctags'. ==> Linking Binary 'ebrowse' to '/usr/local/bin/ebrowse'. ==> Linking Binary 'emacsclient' to '/usr/local/bin/emacsclient'. ==> Linking Binary 'etags' to '/usr/local/bin/etags'. 🍺 emacs was successfully installed!
ここで取得したEmacsはそのまま実行するとGUIのEmacsが起動してしまうので、CUI版を実行するためには-nw
オプションを使用します。
$ emacs -nw
バージョン25のEmacsが導入できました。
パッケージのインストール
Emacsを起動し、M-x
list-packages
を入力し実行します。
利用可能なパッケージの一覧が表示されます。
インストールしたいパッケージの行にカーソルを移動し、i
キーでマークが付きます。
選択後、x
キーでインストールを実行します。
パッケージリポジトリの追加
list-packages
で表示されるパッケージは、デフォルトではEmacsの公式リポジトリに含まれているもののみが表示されますが、それとは別に参照する外部のリポジトリを追加することも可能です。
今回は有名なパッケージが多数含まれている"MELPA"というリポジトリを追加します。
設定ファイル~/.emacs
を開き、(package-initialize)
という記述がある行の直後に以下を追記し、リポジトリを追加します。
;; MELPA-stable (add-to-list 'package-archives '("melpa-stable" . "https://stable.melpa.org/packages/") t)
その後、再度Emacsを起動、list-packages
を実行しパッケージ一覧を表示させた後、M-x
package-refresh-contents
を実行しパッケージリストを更新します。
MELPAに含まれるパッケージをインストールすることが可能になりました。
おわり
3年前に似たような事書いた時*1はなんか2,3日かかった気がするんですが、今見たらEmacs22と24の両立とかいうこれ意味あるのかなあ、と感じるような事を書いていたので大人しく最新版を使うのが良いと思います
はじめてのReact.jsで詰まった
クッソ久々の更新
この記事は"coins Advent Calendar 2016" 20日目の記事です。
www.adventar.org
ひょんなことからReactを触ってみたのでその時困ったことなどを書きたいと思います。
Reactってなに
Reactは、Facebookが開発したJavaScriptライブラリです。
主にWebページ上のUI部品の構築・描画に関する機能を提供します。
細かい機能や扱い方などは、公式チュートリアルなりWeb上の記述なりを探していただければと思いますが、ざっくりと特徴を挙げると以下のようになります。
- 画面上の各パーツをコンポーネントと呼ばれるカプセル化された構造で管理
- コンポーネントは状態(state)を持ち、状態の変化に応じて自動で画面を描画
- MVCで言う所のViewの部分のみを管理する、各種フレームワークと共存化
こんな感じでしょうか。
一応コードの例を挙げてみたいと思います。
コンポーネントの作成例です。ボタンを表示し、押すとその数だけ下に「ほげ」が表示されます。
class ClickButton extends React.Component { constructor(props) { super(props); this.state = { text: "" }; this.addHoge = this.addHoge.bind(this); } // "hoge"を追加する関数 addHoge() { this.setState({ text: this.state.text + "hoge" }); } // 実際にDOMに追加されるHTMLを記述 render() { return ( <div className="clickButton" > <button onClick={this.addHoge}>{this.props.name}</button> <div> {this.state.text} </div> </div> ); } }
上記のコードで作成したコンポーネントは、以下のような記述で呼び出し、idが"wrapper"のdiv要素の中に追加することができます。
ReactDOM.render( <ClickButton name="おしてね" />, // name属性の値はコンポーネント内でthis.prop.nameで参照できます document.getElementById("wrapper") );
こちらで実行結果を確認できます。
ボタンを押すと、onClickに指定されているaddHoge関数が呼び出され、this.state.textの値が変更されます。この時、コンポーネントは、stateの変更を自動でキャッチし、render関数が再度実行され再描画されます。
このように、Reactは画面のパーツをコンポーネントとして管理し、ユーザーの入力に応じた変化への対応に長けたライブラリと言えます。
Reactをいきなり使おうとして困ったこと
そんなReactですが、初めて触ってみるにあたって、ブラウザ上で動かせる状況になるまでに詰まった点がいくつかあったので挙げてみたいと思います。
「なんかJSの中にHTMLが混じってるんだけど」
先述のコードのように、Reactに関連するコードにはJavaScriptの内部にHTMLのような記述が混じる構文が頻繁に出てきます。これは"JSX"と呼ばれるJavaScriptの独自拡張構文です。厳密にはHTMLのタグがそのまま使える訳ではありませんが、ほぼ似たような形で書くことができます。
最終的には普通のJavaScriptに変換して実行するため、厳密には必ずJSX構文で書く必要はありませんが、使ったほうが分かりやすく書けると思います。
「どうやって読み込むの」
npmのようなパッケージマネージャーを使えばよいと思いますが、単純に使うだけなら以下の記述でソースコードを読み込めば十分です。
<script src="https://unpkg.com/react@15/dist/react.min.js"></script> <script src="https://unpkg.com/react-dom@15/dist/react-dom.min.js"></script>
「これどうやって実行するの」
JSX構文のJavaScriptはそのままではブラウザ上で実行できないため、JSX構文でない通常のJavaScriptに変換する必要があります。
変換する方法はいくつかありますが、一番簡単なのは"JSXTransformer"を使用することです。
<script src="http://fb.me/JSXTransformer-0.12.1.js"></script> <script src="path/to/jsxfile.jsx" type="text/jsx"></script>
これでページをロードする際にJSXファイルをその場で変換し、JavaScriptとして実行することができます。しかし、本番環境でこの方法を使用することは推奨されていません。(読み込みが明らかに遅くなります)
他の手段として、Babelというコンパイラを使用し、あらかじめJavaScriptに変換しておく方法があります。
$ npm install -g babel-cli babel-preset-react
上記のようにBabel本体とJSX用のプラグインをインストールすると、以下のコマンドで変換することができます。
$ babel input_jsx_file.jsx > output_js_file.js
他にもwebpackやbrowserifyを使用する等の方法があるようですがこの辺りは使った事が無いので省略します。
「JavaScriptにclass構文ってあったっけ」
これは厳密にはReactとは関係無いですが、Reactに関して調べる際に公式チュートリアルや他サイトのサンプルコード等で頻繁に見かけたので一応。
2015年5月に公開されたECMAScript2015*1(ES6)より、JavaScriptにclass構文が追加されました。
以下はclass構文を使用しない例です。
var Hello = React.createClass({ render: function() { return ( <div>Hello {this.props.name}</div> ); } })
これをclass構文を使用すると以下のように記述することができます。
class Hello extends React.Component { render(){ return ( <div>Hello {this.props.name}</div> ); } }
他にもアロー関数やlet, constを使った変数宣言の機能などが追加されていますがそれは省略します。
このES6の構文は、記事を書いている現在ではIE11等のブラウザがまだ未対応*2なので、それ以前の構文に変換する必要があります。
先述したJSXTransformerでは、JSXファイルを読み込む際に以下のように"harmony=true"を追加することで、class構文やアロー関数など、ES6の構文の一部が使用できます。
<script src="path/to/jsxfile.jsx" type="text/jsx;harmony=true"></script>
Babelの場合は、ES6用のプラグインを追加で導入することで変換の際にES6の構文に対応できます。
$ npm install -g babel-preset-es2015
おわりに
ここで挙げた点はReactの公式Docsやチュートリアルをちゃんと読めば分かる事かもしれませんが、私のような英語流し読みマンはもしかしたら同じような所で詰まるかもしれませんので、参考になれば幸いです。
Reactはライブラリという位置づけからも言えますが、JavaScriptは各種フレームワークと比べて、学習コストが低く手が出しやすい割に慣れればかなり便利に扱えると思います。触った事が無い人も、もし興味が湧いたらとりあえずチュートリアルを読んで雰囲気だけでも掴んでみると良いのではないでしょうか。
おわり。
マサカリはお手柔らかにお願いします。
*1:ECMAScript : Ecma Internationalによって策定されている、JavaScriptの標準仕様
WordPress導入時にディレクトリの位置で混乱した話
VPS、いろいろあるけど自分は↓のサービスを使ってます。
http://dream.jp/vps/
選んだ理由はなんだったか、ぱっと見安かったから?色々考えてた訳ではないです。
ドメイン取得して自分のWebページ運用するのが契約した主目的だったので本当にそれだけでしか使ってなかったんですが、このVPS、契約時に「ブログセット」なるものを選択すると初期の状態からWordPressがインストールされているんですね。んで折角なので初期設定してみました。
http://dream.jp/vps/service.html より。真ん中のやつ
と言っても実際の初期設定の手順に関しては省略。特に何もなかった。公式のチュートリアルによると「http://<ドメイン名>/blog」がWordPressのアドレスらしい。
んで設定終わったあと、もう1回アクセスしてみると、
それっぽい画面とサンプル投稿らしきものが。確かに設定できたらしい。
じゃあ実際のところ<ドキュメントルート>/blog下にはどんなファイルが入っているだろうか。設定時間かかったしさぞかしごちゃごちゃした構成なんだろうなあ。
何もありませんでした。残念。
というわけでWordPressの関連ファイルを探してみた。
ドキュメントルート(htmlディレクトリ)のひとつ上に置いてありました。
じゃあWordPressの設定でここを参照してるようにしてるのかなあ、と見てみたら、
blogディレクトリ指定してました。どういうこったい。
そもそもURLで指定するからドキュメントルートより親の階層は覗けないし、ここじゃ対処できない。WordPressのデータベース内の記述もちょっと見てみたけど正直良く分かりませんでした。
んで結局
http.confでインクルードされてたwordpress.confでエイリアス設定されてただけでした。
これでhttp://<ドメイン名>/blogに対するアクセスで/var/www/wordpressを参照するようにしていたようです。多分これだけ。
これって
ドキュメントルート下に置いてないファイルもWebから参照できますし結構便利なんじゃないですかね。パーミッション周り気をつけないと大変なことになりそうですけど。
サーバー移転作業
ServersMan@VPSを借りておきながら自前のページは未だにさくらのレンタルサーバーで運用していたので移転作業した話。
Apache導入
移転先のサーバーにWebサーバーソフトウェアApacheをインストール。
インストールしたhttpdを再起動等の時に自動起動するようにする。
/etc/httpd/conf/httpd.confを編集して設定の変更。
記述の最後に以下を追記。
ServerTokens ProductOnly
# サーバー署名の非表示
ServerSignature off
以下の記述を探す。
・
・
・
Options Indexes FollowSymLinks ←これ
これを以下のように変更。
Options -Indexes
ファイルの移行
元のサーバーに置いてあったWeb用のデータを丸ごとVPSの/var/www/html/下にコピーする。
さくら側のドメイン設定削除
さくらのレンタルサーバーのコントロールパネルでドメインの設定を削除する。
ネームサーバーの設定を変更
独自ドメインのネームサーバーを変更する。
今まではさくらのネームサーバーを使用していた(らしい。さくらサーバーの初期設定の時に何も考えずに設定していたが、ドメインの登録時にネームサーバーの登録も行われていたのか)が、お名前.comのネームサーバーに変更する。
お名前.comの設定ページから「DNSレコード設定を利用する」を選択
独自ドメインとVPSのIPアドレスを関連付けさせるようにDNSレコードを追加。
"TYPE"の項目は"A"("Adress"?)、"TTL"の項目は"3600"(キャッシュ生存時間)、"VALUE"の項目はサーバーのIPアドレスを入力する。
一番下のネームサーバー変更確認のチェックボックスにチェックを入れる。
ここまでやったら入力した情報を確認して設定を保存。
おわり
DNSの変更が浸透するまでしばらく時間がかかるものの、これで最低限の設定は終わったかと。
完全に手探りで作業したのでどこかでやらかしてそうなのが怖いところ
これで現状、さくらのレンタルサーバーが完全に使われなくなってしまったので何か使用用途を考えたいところ。確か1年契約だったはず
VPSを借りたので初期設定
「botつくりてえ」
↓
「プログラム動かすサーバーが必要」
↓
「ならVPSを借りればいいじゃない!(・∀・)」
というわけでVPSを契約したので初期設定。
ドットインストールのVPS関連のページ参考。
http://dotinstall.com/lessons/basic_sakura_vps
契約した
今回使うのはServersMan@VPSのEntryプラン。安かった。
http://dream.jp/vps/
契約の流れは省略。
データセンターの場所は東京、初期OSはCentOS7 64bit、テンプレートはブログパックを選択した。
初期設定
接続
sshコマンドを使ってrootユーザーで接続。初期設定ではssh用のポート番号は3843。
パッケージ更新とか
パッケージの管理にはyumコマンドを使う。最初はyum updateで入っているパッケージの更新。
テキスト編集にはEmacsを使いたい人間なのでインストール。viは初期から使える。
ユーザー作成
作業用にユーザーを作成、パスワード設定
# passwd username password
所属グループをwheelグループとする
wheelグループでsudoコマンドが使えるようにする。
visudoコマンドでsudoコマンド用の設定ファイル(/etc/sudoers)を編集する。
起動するエディタがviであることに注意
下のような記述を探す
# %wheel ALL=(ALL) ALL
2行目の行頭がコメントアウトされている場合は # を消去して解除
最初から無かった場合はそのままで良い
%wheel ALL=(ALL) ALL
作成したユーザーでログイン
rootユーザーをログアウトして作成したユーザーで再ログイン。
鍵認証の設定
鍵保存用のディレクトリを作成し、パーミッションを所有者のみに変更
ssh接続元の端末で公開鍵と秘密鍵のペアを作成する。(Macでの作成方法)
ssh-keygenコマンドを使用し、RSA形式の鍵を作成。保存先やパスフレーズはデフォルトで良いので何も入力しない。
Enter file in which to save the key (/***/***/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
「id_rsa」と「id_rsa.pub」の2つのファイルが~/.ssh下に作成される。
id_rsa.pubのパーミッションを所有者のみに変更
公開鍵をVPSに転送する。転送先は先程作成した~/.sshとし、ファイル名を「authorized_keys」とする。
scpコマンドでのポート番号の指定は「-P port」とすることに注意。(sshコマンドでは「-p port」)
以後、パスワード無しでssh接続が可能になる。(rootユーザーでの接続にはパスワードが必要)
なお、秘密鍵はデフォルトで~/.ssh/id_rsaを参照するようになっているが、それ以外の場所に秘密鍵を作成した場合はsshコマンドを使用する際に手動で秘密鍵の場所を指定する必要がある。
ssh用ポート番号の変更
sshコマンドで作成した作業用ユーザーでログインした後、root権限での作業を行うのでsudoコマンドを「-s」オプションを付けて実行する。
$ sudo -s
sshに関する設定は/etc/ssh/sshd_configに記述されている。編集前にバックアップをとっておく。
バックアップを取ったら編集。「Port 3843」と書いてある部分を変更する。17行目あたり。
パスワードログインの禁止
同ファイルの「PasswordAuthentication yes」と書いてある部分を変更する。78行目あたり。
Rootユーザーでのログイン禁止
同ファイルの「PermitRootLogin yes」と書いてある部分を変更する。48行目あたり。
コメントアウトされている場合は解除。
編集終了後、設定の変更を反映させるためsshサーバーの再起動を行う。
ファイアーウォールの設定
サーバーに対する通信のルールを設定する。
設定は /etc/sysconfig/iptables を編集して変更する。ここでは省略
編集終了後、設定を保存し、変更を有効にするためにサービスを再起動する、
おわり
VPS契約直後にやったこととしてはここまで
あとは使用用途に合わせて色々と