読者です 読者をやめる 読者になる 読者になる

RFC1034読書会に行ってきたよ

2017/03/01 追記 近日中にセルフ赤ペンが入ります。
2017/03/04 追記 ただいま、セルフ赤ペン中です。
2017/03/08 追記 セルフ赤ペンしました。

おはこんばんにちは。なつよです。

プライベートやお仕事が立て込む日々です。
インフラガール活動の時間、もうちょっと増やしたい・・・(ノД`)

今回は、先日行ってきたRFC1034読書会について書こうと思います。

RFC1034とは?

とってもざっくり言うと、DNSに関するRFCです。
私は、TwitterでDNSDNS言ってたら、「まずRFC1034を読むことだ、話はそれからだ」と言われて知りました。

RFC1034読書会とは?

浸透言うな先生こと鈴木先生(@tss_ontap_o)主催の会です。
atnd.org

なんで参加しようと思ったの?

RFC1034,日本語訳を読んでみたのですがまったくわからんかったのです。
私が読んでみた過去についてはこちらの記事をごらんください。

infragirl.hatenablog.jp

infragirl.hatenablog.jp

そんな中、鈴木先生から声をかけていただき、参加することとなりました。

出発から到着まで

開催地は中京大学八事キャンパスでした。
私は富山から高速バスに乗って行きました。

suica使えるじゃんやったぜ~と思っていたら、「名古屋で地下鉄乗るならドニチエコ切符のほうがお得だよ」と
教えていただきました。ありがたや。

13時半スタートだったのですが、早く着きすぎたので
大学内をぶらぶらしていたら(迷子とも言う)運よく鈴木先生エンカウントしました。(∩´∀`)∩ヤッター

開催されるお部屋は眺めのいいゼミ室?でした。

参加者の方がぞくぞく到着される中、皆さん電源タップを自主的に持参されたり、
お菓子を持参される方がいて、何も持ってこなかった自分がちょっと恥ずかしかったのでした。(;´Д`)

読書会開始!

読書会は、鈴木先生が解説され、参加者がそのつど質問をする、というスタイルで行われました。
初めて参加だったので、「ついていけなかったらどうしよ」と思っていたのですが、
わからないところを丁寧に解説してくださったので、なんとか着いていけたと思います。

あとから知ったのですがかなりゆっくり解説してくださっていたようです。
ありがたや(´Д`)

読書会で学んだこと


今回の読書会に参加してみて、自分の中のモヤモヤが晴れたというか・・・アハ( ゚д゚ )体験が沢山ありました。
以下、自分のメモをもとに書き起こしてみました。

DNSは考古学
 RFC1034が書かれたのは1987年でした。鈴木先生いわく、当時のとりまく環境を知らないと理解できないよ~、とのことでした。
 私は1991年生まれなので、生まれる前の話なんですよね。
 telnetとmailが主体で、webが出るのはこれより20年ほどあとなんだとか。

これは誤りで、1989年~1991年がwwwの始まりだそうです。

ティム・バーナーズ=リーさんが提案したのが1989年「Information Management: A Proposal」、
これをさらに具体的にしたのが1990年「WorldWideWeb: Proposal for a HyperText Project」、
CERN(ティム・バーナーズ=リーさんが所属する組織)外の人もコミュニティに参加できるようになった(開かれた)のが1991年のようです。

webfoundation.org


・RFC1034はけっこうざっくりとしたRFC
 DNSソフトウェアNO.1と名高い(?)BINDの開発元であるISCのサイトに、DNSに関するRFCの一覧が掲載されているとのことです。
DNS RFC | Internet Systems Consortium

 その中でRFC1034のタイトルは「Domain names - concepts and facilities」、DNSの概念についてざっくり述べているものだそうです。
 これを知って、私は「最近ホスト増えてきたじゃん?管理めんどいよね、こんな感じのもん考えてみたわ、どう?」ぐらいの気持ちで書いたんじゃないかなぁ?と思いました。

 RFC1034もがあまりにもざっくり?すぎるので、「っときちんと使おうよ~」ということで書かれたRFC(RFC1912)もあるそうです。
 
RFC1912 -> 「 Common DNS Operational and Configuration Errors」、
RFC2181 ->「Clarifications to the DNS Specification」

これまだ読んでないんですよね・・・いつ読めるかしら(´Д`;)

RFCは1周読んだだけでは分からない。2~3周すべき
 最後のほうになって、「最初のほうで言っていたのはそういう意味だったのか!」と分かることもあるとか。

・RFC1034は浸透(percolate)という表現が出てくるが、実装では「浸透」しない
  RFCでの表現と、実装は異なるとか。DNSややこしすぎか。

DNSは「一貫性」よりも「可用性」を取った仕組みである

RFC1034の中に以下のような文があります。
 When updates are unavailable due to network or host failure, the usual course is to believe old information while continuing efforts to update it.
 
 これはネットワークが分断されたとき、動作としては「古い情報を信じる」という記述で、
CAP定理を知った上でこのことを知っておくとよいとの話でした。
 CAP定理・・・恥ずかしながら知らんかった・・・APとか取るときに出たかもしれないけど・・・

・recursive(再帰問い合わせ)はオプション。iterative(反復問い合わせ)できないサーバがrecursiveする
 
 これは、私の中で一番のアハ体験だった話です。
 DNSには「再帰問い合わせ」と「反復問い合わせ」があることは知っていたのですが、何のために2種類存在するのかよく分かっていませんでした。
 「DNSの基本はiterativeなんだ、それができないサーバがrecursiveするんだ!」と聞いて「あ!なるほど!」と思いました。
 
 RFC1034が書かれた頃のインターネットの設備は今では考えられないこと貧弱で、iterativeという動作は「とてもリソースを使う動作」だったとか。
 それで、iterativeするほどリソースに余裕がないサーバが、iterativeできるサーバにrecursiveしたとのことです。

f:id:okisan2:20170308230752j:plain

今の時代ならば、ゾルバをクライアントが直接iterativeできるそうですが
 現在の端末ならば、リゾルバを介さずに、クライアントから直接iterativeできるぐらいの性能が出るそうですがNAT環境でそれをやると、NATテーブルがいっぱいになるから注意とのことです。(;´∀`)

鈴木先生(@tss_ontap_o)より「クライアントのリゾルバに直接 iterative を追わせられるリソースは確保できる」と教えていただきました・・・こっちのほうがしっくりくる・・・。
私の言い方だとリゾルバ不要、と受け取れますね・・・日本語ムツカシイ


 まだまだあるんですが、それは私の復習&予習が終わってからまた書くかもしれません。

読書会に参加して思ったこと

 ひとことでいうと・・・とても有意義でした!
 富山から片道3時間半かけていきましたが、行った価値があったと思いました。

 自分のモヤモヤが晴れたこともよかったんですが、技術的な話する場に行くと、刺激を受けていいなぁ、と思いました。

読書会の後は

 読書会の後、近所の居酒屋さん「串太郎」で懇親会がありました。
 何気に人生初ガード下居酒屋(^ω^)
 
 バスの時間があり1時間ほどでさよならしましたが、とてもとてもおいしかったです。
 昼抜いてたせいか、ムシャムシャ食べ過ぎたわ。。。
 
 今度行くときは富山の地酒持参で行きたいなぁと。

今後

 第2回が3/24開催とのことです。
 それまでに復習と予習をしておかなきゃ( ゚д゚ )

他の参加者の方の声など

 Togatterにまとめを作成されたそうです!ありがたや~
 
RFC 読書会 - RFC 1034 第1回 - #1034reading - Togetterまとめ

2016年をふりかえって

こんばんは。 なつよです。

@infragirl755 のTwitterを2015年9月1日に開始して、約1年3ヶ月経過しました。 特に今年1年でいろいろな動きがありましたので、2016年の振り返り記事を書こうと思います。

では、1月から順番に振り返っていきます。

今年を振り返って

1月は、BINDの脆弱性対応の記事を書きました。 infragirl.hatenablog.jp

BINDについてぐぐってみると、「BINDは脆弱性が多い!」とか「BINDによるDNSサーバの構築手順」といった記事はよく見ます。 しかし、「BINDの脆弱性対応をするために人間はどう動くべきか?」という、運用にかかわる人間の心構えや行動指針に関する記事は見つけられません。それなら自分で書いてみるか、と思い投稿しました。

結果、Twitterはてなブックマークで沢山のリアクションをいただきました。

特にTwitterでは「ここの文章はこう治したほうがいいよ」「こういう手順を書いてみたよ」という具体的な指摘をいただきました。

投稿してしばらくはボコボコに叩かれるかと思ってどきどきしていたので、 SNSでのリアクションやわかりやすい指摘をいただけたことは本当にうれしかったです。

2月は、はじめてインフラガールの漫画を投稿しました。

漫画なんて描いた事なかったから、何時間もかかりました。 漫画家さんってすげぇと何回思ったことか・・・

結果、Twitterで100を超えるRTをしていただき、リプライでも「私もこうなったことあります」とか「おもしろい」というコメントを もらえてめちゃくちゃうれしかったです。

3月から4月は、セキュリティスペシャリストを受験が迫っていたので、 勉強漬けだった気がします。

infragirl.hatenablog.jp

「どうせ受けるなら1発で受かってやる!」と気合を入れて勉強していましたが、まさか本当に受かると思っていなかったので・・・会社で机の周りの人にかたっぱしから自慢しました。なんてウザイやつなんだ・・・。

5月はRTX1100買ったりいろいろ妄想したり・・・・

6月はDNS Summer Day 2016に行きました。 infragirl.hatenablog.jp

技術書典にも行きました。 infragirl.hatenablog.jp

思えばこの2つのイベントが、今年の転換期でした。

DNS Summer Day 2016に行って、沢山の方と話しました。 知り合った方もTwitterでフォローさせていただきました。 タイムラインがすごく充実しています。ありがたいです!

7月~10月は、ブログではたいした更新をしていないですね・・・。 二輪免許を取りに自動車学校に行って、引越しもしてたんだっけ。( ゚д゚)ウム

11月は、Redmineの月でした。 会社でも使い始め、プライベートでもVPSかけて構築してみました。 infragirl.hatenablog.jp

この記事のあと、オレオレ証明書https化しようとして いろいろおかしくなり復旧できなくなりました。ちーん。 現在はBacklogというサービスを利用しています。快適です。

・・・そこはエンジニアとしてなおさんかい!( ‘д‘⊂彡☆))Д´) パーン

12月はシス管系女子のアドベントカレンダーの記事をかきました。 infragirl.hatenablog.jp

みんとちゃん書くのすっごい楽しかった!!!

こうしてみると、今年はけっこういろんなことしてるんですね。

来年は・・・

2016年は、たくさんの方と知り合うことができました。

普段のツイートから興味を持ってくださった方、へたくそまんがから興味を持ってくださった方、 ブログ記事から興味を持ってくださった方DNS Summer Day 2016で知り合った方、技術書典で知り合った方・・・

いろんな方たちと相互フォローになって、タイムラインが充実しました。 そして、沢山の情報が流れてくるようになりました。

「あっ!これ気になる!」「これこないだ仕事で悩んだやつだ!」と何回思ったかわかりません。 「あれもやりたい!」「これも勉強したい!」とやりたいことがあふれ、何から手をつけていいかわからない状態に・・・。

2016年はDNSの勉強がぜんぜんできなかったので RFC1034の読破を目指したいです。

こないだもちょっとやったけど、絵に描きながら読むのが 一番頭に入る気がします。

そして、インフラ女子あるある漫画をもっと描きたいです。

f:id:okisan2:20161230230552j:plain

皆さん、よいお年を!

シス管系女子を読むべきなのは誰か?

書庫

おはこんばんにちは。
シス管系女子のアドベントカレンダー、12月9日分として投稿させていただくことになりました。
www.adventar.org

今回は、ファンアートともに、
「シス管系女子を読むべきなのは誰か?」をテーマに
書いていこうと思います。

まず最初に、わたしとシス管系女子との出会いから説明させてください。

わたしとシス管系女子との出会い

私とみんとちゃんとの出会いは、確か2~3年前ぐらいだったか・・・。
確か、「もっと複雑な条件でファイルを探したい」(単行本2巻第11話)
の回だったかと思います。findコマンドを使えば、複雑な条件を組み合わせてファイルを検索できる、というあらすじです。

当時の私はLinuxサーバの管理者として配属されたものの、
Linuxサーバなんて学生時代触ったことがなかったし、本番環境を触るのに楽しむ余裕などなく、黒い画面におびえる日々でした。

そんな自分を打破したく手に取ったのが「日経Linux」でした。
みんとちゃんみたいなかわいい女の子がfindコマンドを使いこなす姿に驚きました。
当時、私の部署には同年代の女性インフラエンジニアがいなかったため、みんとちゃんに親近感を感じました。

大野さんからレクチャーされ、コマンドの便利さに驚く姿、「もうだめだーーー!」と頭を抱える姿、
結局二度手間でがっくりする姿を見て、「CLIに戸惑っていいんだ、悩んでいいんだ」といわれた気がして、気が楽になったのを覚えています。

今年の6月に技術書典でPiro先生にサインをもらえたのはうれしかった(・∀・)
infragirl.hatenablog.jp

シス管系女子を読むべきなのは誰か?

さて本題に入ります。
結論を言うと、Linuxサーバを管理する立場になったものの、どんなコマンドを使っていいかわからずググっちゃう人」だと思います。

・・・・え?そりゃそうだろって?( ゚д゚)

なぜそう思ったか書いていきますね。

Twitterではたまに書いてるんですが、つい最近後輩インフラボーイが配属されまして、私がOJTをしています。
Linuxの経験は1年ほどで、「やりたいことがあっても、どんなコマンドが適切かわからない」状態なんですね。

そういうときに彼はとりあえずぐぐっちゃうんです。
そんで、ぐぐったのと実際のサーバでの結果が違っちゃったりして「????」ってなっちゃうんですよね・・・。

わかる、わかるよ。
私もね、そんな時期、とりあえずぐぐってたよ( ;∀;)
そんで、思い通りの結果が得られなくて、先輩に泣きついてたよ。
「man見てやらないとだめだよ」って良く言われたっけ・・・。

ぐぐること自体はだめじゃないんですよ。
でも、かならず自分が思う結果が得られるかどうかはわからないし、それが正しいかもわからないんですよね。
そういう判断ができないうちは、やっぱりお金を払ってでも本で勉強するべきだと思います。

※その後、彼にはポケットリファレンスを渡しました。
 それでもだめならmanを読んで、もうお手上げなら声かけてって言っておきました。

そういう中で、シス管系女子って「どんな問題を解決したいときにこのコマンドが役に立つか」っていうことを「漫画形式で気張らずに読める」とても良い教科書だと思うんです。

普段から読んでおいて、いざそういう場面にでくわしたら
「あれ・・・こういう場面見たことある・・・そうか、みんとちゃんがやってた気がするわ」って思い出して対処の道筋を立てられます。

実際、わたしも「これシス管系女子で見たやつだ・・・!」って場面が何回かありましたw

「最初の1歩を踏み出すための本」ではないけど、「システム管理者として歩き出した人の手を引いてあげる」という意味では
最適な本ではないかと思います。

さいごに

ファンアートです!
Piro先生、3巻楽しみにしてます。これからもがんばってください~!

f:id:okisan2:20161207222048p:plain

RFC1034を読むよ(2.1.The history of domain namesから)

DNS RFC1034読破計画

おはこんばんにちは。
前回の続きです。

infragirl.hatenablog.jp

RFC952が「各自FTPで取りにきてね」という内容に対して、RFC953は「プログラム作って各自取りにきてね」という内容なのでしょうか。

2つとも1985年の10月みたいだし、なんでわざわざ2つに分けたんだろう・・・(;´Д`)
2つとも読み進めたらわかるんですかね。

でも、1034のほうが気になるからそっち先に読み進めてます。
ただ訳文を見るだけじゃなくて、英語もみたほうがいいといわれたので、
最初に英文を訳してから、答えあわせとして日本語訳を見ていくことにしました。


1. STATUS OF THIS MEMO
このメモの状態

This RFC is an introduction to the Domain Name System (DNS), and omits
many details which can be found in a companion RFC, "Domain Names -
Implementation and Specification" [RFC-1035]. That RFC assumes that the
reader is familiar with the concepts discussed in this memo.

知ることができるRFCの仲間の沢山の詳細については省略します。
ドメインネームの実行と仕様について(RFC1035)」。
このRFCは当然、読み手に親しみやすく、このメモのコンセプトについて討議されていることがよく知られている。

omits:省略
details:詳細
companion:仲間
Implementation:実行、履行
Specification:仕様
assumes:当然だと思う
familiar:よく知られている、親しみやすい
discussed:討議されている

The impetus for the development of the domain system was growth in the
Internet:

impetus :刺激、推進力
インターネットの成長がドメインシステムの発達の推進力であった。

Host name to address mappings were maintained by the Network
Information Center (NIC) in a single file (HOSTS.TXT) which
was FTPed by all hosts [RFC-952, RFC-953].The total network

訳: すべてのネットワークにおいて、ホストネームのアドレス変換はマッピングされていました、それはすべてのホストがネットワークインフォメーションセンターの中にあるHOSTS.TXTをFTPで維持されていました。

maintain:維持される、保全する

ぬ~ん
寝ます。

RFC1034を読みはじめた(数ヶ月ぶり2回目)

DNS RFC1034読破計画

おはこんばんにちは。
好きな本を好きなだけ買ってほくほくのなつよさんです。
カフェちゃんとブレークタイムを読んで、今日もコーヒーがうまい( ^ω^ )


Twitterで「DNSわからん」ってつぶやきまくっていたら、「RFC読まないと理解できないよ」と聞きまして
前野さん(@beyondDNS)訳のRFC1034を読んでみることにしました。

DNS/RFC/1034 - moin.qmail.jp


そして・・・

読んでもちっともわからなかったです。
これは日本語???日本語なんだけど何が書いてあるのかわからないんです。
何がわからないかもわからなかったです。

なるほど絵に描けばいいのか。


描いた。


そして悟った。


このへんを眺めながらARPANETの成り立ちを調べました。

インターネット歴史年表 - JPNIC


ARPANETが始まったのが1969年らしい。
RFC1034が公開されるよりも18年も前だった。

18年間もなにしとったん・・?


RFC1034よりも前のRFCがあるらしい。
そういえば、DNSができる前はHOSTS.TXTを各自FTPで取りにいっていたって、
どこかで聞いた事がある。

そういえば、どこかでRFCの系統図を公開されていたのを見た気がする・・・。

※滝澤さん(@ttkzw)のサイトから引用させていただきました。ありがとうございます。
Diagram of the descent of DNS RFCs – ttkzw's site

むちゃくちゃデカイ(゚д゚)!

どうやら、DNSのベースになった一番ねっこのRFCは226のようなので、
ぐぐってみました。


最初のHOSTS.TXT(アドレスと名前の変換テーブル)はたったの20行だったんですね・・・。


ここまで調べてやっとRFC1034に戻ります。
※下の文は、前野さん訳より引用させていただきました。ありがとうございます。
DNS/RFC/1034/2 - moin.qmail.jp

「かつてはホスト名をアドレスに変換するのには、
ネットワーク情報センター(NIC)で管理されるひとつのファイル(HOSTS.TXT) を各ホストがFTPで取り出して使うという方法で行なわれていた [RFC-952,RFC-953]。 この方法だと新版を配るのに必要な全ネットワークバンド幅資源は ネットワーク上のホスト数の 2 乗に比例するので、 多段の FTP を使ってさえ、NIC ホストの FTP 負荷はかなり のものであった。 ホスト数の爆発的増加は悪い状況を示していた。 」

文中に出てきた、RFC-952を読んでみました。
最初は、FTPでこのホストで、IDとパスワードはこれで・・・って言う話で、
その後はHOSTS.TXTの体裁の話かな?


あとでRFC-953も読んでみようと思います。
とりあえず今日はここまで。

OpenSSL脆弱性対応手順まとめ

おはこんばんにちは。

OpenSSLさんがまた脆弱性ですって(´・ε・`)?

JVNVU#92930223: OpenSSL に複数の脆弱性

私の中ではBINDさんの次に多い印象があります。

BINDの脆弱性対応手順をまとめたのにならって、今回はOpenSSLバージョンをまとめてみますね。

infragirl.hatenablog.jp

 1.OpenSSLの脆弱性の発表をキャッチする

本家が情報をわかりやすく出してくれてるようです。

脆弱性がアナウンスされた時https://twitter.com/ha4gu/status/750102197174607872の一次ソース「Security Advisory」はここですね。

ここのRSSが見つけられない…。

https://www.openssl.org/news/newslog.html

過去の脆弱性情報がまとまってるページもあるんですね。

/news/vulnerabilities.html

 

OpenSSLに限ったことではないですが、CVE,JPCERT/CC,JVNも要チェックですね!

私はNVDとかもたまに見るんですけど、JVNと微妙にCVSSスコアが違ってたりするので基本はJVNを信用してます( ´ω`)

 

あと、OpenSSLのBlogにけっこう書いてたりすることがあるようで・・・

www.openssl.org

脆弱性情報出た後にOpenSSL本家からアップデートが出なくて、

「これいつでるのかなぁ・・・」ってウジウジしてたら

「ブログに書いてあるよ」と教えていただいたことがあり、その時からBlogも見るようにしてます。

 一次ソースのチェックは大事ですね( +・`ω・)b

 

  2.自分の管轄内のOpenSSLのバージョンを調べる

バージョンを出すだけなら・・・

$ dpkg -l | grep openssl

yum list installed | grep openssl

最近知ったんですがCent OSだとアップデート可能なら黄色くなってくれるそうですね。便利(゚д゚)!

 

パッケージを使っていなくてもopensslコマンドで

バージョンを確認することができます。

$openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013

 

でも・・・

それ本当に今使っているOpenSSLのバージョンなんでしょうか?

もしかしたら後からソースインストールしてるのかも!!!

ギャアァァァァ━━━━━━(|||゚Д゚)━━━━━━!!!!!!

 

lsofコマンド(どのプロセスがどのファイルを開いているのか

わかるコマンド)でopensslのライブラリを開いているプロセスを見つけましょう。

# lsof | grep ssl

・・・

fail2ban-  2565                root  mem       REG              253,4    449880    4680996/usr/lib64/libssl.so.1.0.1e

 

これで新しいほうを参照してたらOKです。

古いほうを参照してたらアップデートしてあげましょう。4へ続く。

 

ちなみに現在のstableバージョンは1.0.2系で、1.0.1系はセキュリティ上のバグ修正しかしていないんですって。

そんで、1.0.1系のサポートは2016/12/31までですって。

( ゚д゚)ナンデスト!

ソース:https://www.openssl.org/source/

   3.アップデートするかどうかを決める

BINDのときとほとんど同じことを言いますが・・・

これは、環境によって異なるのでなんとも言えない(´・ω・`)ショボーン

あとは以下の観点から判断しています。

・対象のサーバが外に出ているかどうか

→FWで守られているかどうか。外に出ているものであれば、一刻も早く対処しないといけないです。リモートで攻撃可能な脆弱性だといつ攻撃を受けるかわかりませんし。

脆弱性によって受ける影響が大きいかどうか

→これも環境によりけりですね。でも、SSLって大事な情報を守るために使われているものですし、本来守られているべきのものが情報漏えいの脆弱性あり!といわれたら

私なら最優先でアップデートかけちゃうと思います。サービス停止の脆弱性とかだとどうかな。でも、SSL使うようなサービスって大事なやり取りばかりですよね・・・。

 基本的には脆弱性にはすべて対応すべきだと思っています。ただし、実際に対応するかどうかは実際の環境や、対応にかかる工数とリスクを天秤にかけて、上司や客先と相談して判断しています。

  4 .OpenSSLをアップデートする

パッケージならアップデートしてあげればOKですね。

アップデート後は、OpenSSLのライブラリを参照しているプロセスが

本当に新しいライブラリを参照しているかlsofコマンドで確認してあげてください。

必要に応じてプロセスのサービスも再起動しましょう。

 

Σ(゚д゚) エッ!? OSがサポート切れ?パッケージが提供されない?

<丶´Д`>ゲッソリ しますね。

 

OpenSSLのサイトからソースをインストールしましょう。

そんで、opensslのライブラリを参照しているプロセスが、新しいバージョンのライブラリを参照するようにがんばりましょう。

(サービス再起動でそううまいこといってくれなくて、筆者はソースapacheのconfigureからやり直したことがあります。超めんどくさかった)

ソースからアップデートの方法については、参照するプロセスによって

大きく違いそうですし、筆者はapacheしかやったことないので割愛します。

 

ながくなりましたが私はこんな感じでOpenSSL脆弱性対応をしています。

間違いやこうしたらいいよ!という意見などありましたら@infragirl755までリプライいただけると幸いです。

 

2016/11/29 追記

このエントリを見た方が、この件についてより掘り下げたブログ記事を書いてくださいました。

 

OpenSSLに限らず、パッケージ管理についてどう付き合って行くべきかという視点で書かれており、とてもためになる記事でした( •̀ᄇ• ́)ﻭ✧

 

お兄様さん‪(@phase_d ‬)ありがとうございました!

 

さくらのVPSでRedmineを構築してみました

自宅redmine

おはこんばんにちは。

突然ですがさくらのVPSRedmineを構築しました。

 

理由は以下のとおりです。

 お金関係のタスクって自分ではしっかり管理してたつもりだったんです。

それを忘れたのがショックで・・・。

会社でRedmine使い始めたので、家でも使いたいなぁと思って・・・。

https://twitter.com/infragirl755/status/799864684727783425

 

さくらのVPSの一番安いプラン契約しました。月額685円なんて安いですねぇ(´∀`*)

 最初からrootログインできるようになっててびびった。

あとループバックオンリーでpostfix動いてたのはCentOS7の親切なのかしら・・・?

systemd?会社でdebian8触ってるしいけるやろ、と何も考えずにCentOS7にしました。

あとからFirewalldで苦しむとも知らずに・・・ふっε- (´ー`*)

 

とりあえずやったこと

iptablesコマンドで必要なポートだけ空ける

(これ意味あったのかな・・?後からFirewalldだと気づいた)

・rootユーザと一般ユーザの作成

sshでrootログインできなくする

sshの鍵認証を設定し、鍵認証を強制する設定を入れる

・fail2banでsshポートの設定する

・logrotateの設定を見る(とりあえず一通り設定されているようだからこのまま)

・bitnamiインストーラを使ってredmineのインストール

→めちゃくちゃ簡単でびびった。

iptablesではなくfirewalldだと気づく

 

redmineでユーザ作成

redmineのサーバ用のAレコードを登録

・redminePMのインストールと動作確認

・backlogsプラグインを入れようとして挫折中

rubyのgemとかnokogiriとかわけわかめで(´・ω・`)ショボーン

 

とりあえずredmineが動くようにはなりました。

会社でbacklogsプラグインで慣れちゃったからこれ使いたいん

だけどな・・・。

家使いでredmineつかってて、こういう運用してるよ!って方が

いたら教えていただきたいです。

(チケットの種類とかサブプロジェクトの粒度とか・・・)

さくらのVPSの最小スペックですが、今のところ問題なさそうです。今後使い込んだらしんどくなってくるのかな。

 

これからどんどん使い込むぞ~。