タグ

ブックマーク / blog.father.gedow.net (6)

  • インプットのすゝめ | 外道父の匠

    絶賛成長期にあるだろう若手エンジニアは、どういう流れで自身の成長を促したら良いのだろうか、とふと思いつつ口頭で説明してみたけどよくわからんくなったので整理してみたいお気持ちです。 当ブログではアウトプットの効用みたいなものは書いてきましたが、インプットそのものについてはお初なので、自身を振り返る良い機会にもなりそうです。 はじめに これは私が二十数年間、プログラマー・インフラ・SRE といったエンジニアとして通ってきた中で、どのようにインプットをしてきたかを整理してみるチラ裏です。 自分は一般(?)と比べれば少々特殊な経歴で、情報学を学んだことも、新卒研修を受けたことも、IT系資格も、転職したこともない…… ほぼ独学による野良エンジニアとして生息してきましたので、あまり参考にはならないかもしれません。 それでも一応長く生き抜いてきたエンジニアの経験として、インターネットに数多くある参考例の

    インプットのすゝめ | 外道父の匠
  • SSSDとnslcd+nscdの比較 | 外道父の匠

    SSSDを触り始めた理由である、nslcd+nscd と結局どっちがエェねんという疑問をまとめていきます。 SSSD といっぱいタイピングしていると ssh が sssh になってしまう病気にかかるので要注意です。 関連記事 認証システムSSSD+LDAP+SUDOの構築手順 SSSD+LDAP+SSH連携の設定 システムの用途 nslcd(Name Service LDAP Connection Daemon) はその名の通りLDAPとの接続を担うだけなので、キャッシュ担当の nscd (Name Service Cache Daemon) がいないと毎回LDAPに接続することになり、不健康となるためセットで使うのが基です。 SSSDは認証管理+キャッシュの役割を併せ持つので、デーモンとしては1つになります。LDAP以外の様々な認証機能を使えるのも強みですね。 LDAP周りだけでいえば

    SSSDとnslcd+nscdの比較 | 外道父の匠
  • ドリコムを退職しました……弟子が | 外道父の匠

    世間の流れに沿って、一度、退職エントリを書いてみたかったんですけど、まだちょっと退職しそうにないんで、倒置法で我慢してみました。 人には「退職エントリ書くね!」と去り際に伝えてありますが、センシティブなカテゴリですから、企業・個人事情に基づくものというよりは、身近な人間が退職したという出来事に対する感想的なものとなります。 ザッと振り返って 前に書いた、「新卒インフラエンジニアを育成した話」で地獄を見せようと試みて、いまいち業火で焼き尽くせず耐え切ったアノ弟子です。二年が経過し、中小規模のサービスを専任で4~5個担当するまで至っていたので、当人の努力と成果は十分であったのかと思います。 他にも、AWS関連や、インフラのアーキテクチャなどは、私と共に進めたり、時には率先して案を出したりもしてくれていたので、中盤からは弟子というよりは普通に共同作業者という立ち位置でした。例えば「現代ITイン

    ドリコムを退職しました……弟子が | 外道父の匠
  • systemd時代に困らないためのlimits設定 | 外道父の匠

    数年前に、こういう記事「ulimitが効かない不安を無くす設定」を書きました。しかし、ディストリビューションのバージョンが上がり、デーモン管理が systemd に変わったことで、インターネットのゴミとなりつつあります。 そのため今回は、その次世代バージョン的な内容ということで、systemd の場合はこうしておけば見えない敵と闘うこともなくなるはずです、というものになります。例によって、抑えきれていないパターンがあったら御免なさいです、押忍。 limits設定で目指す所 復習になりますが、limits の設定で困るのはだいたいこういうパターンでしょう。 作業中ユーザーのシェルのlimits設定が思い通りにならない コンソール/SSHログインしてデーモンを再起動したら、limits設定が戻っていた su/sudoを使ってデーモンを再起動したら同上 デーモンをシステムに自動再起動させたら同上

    systemd時代に困らないためのlimits設定 | 外道父の匠
  • エンジニアが初めて書籍を執筆するにあたって | 外道父の匠

    新年一発目のブログは腰が重いがゆえに、いざ書き出すと長くなる悪い癖──ですが、今年も継続アウトプット頑張っていきます。よろしくお願いします! ──昨年9月に、書籍『たのしいインフラの歩き方』を発売させていただきましたが、数ヶ月が経って年も変わったので、執筆話の発生からどのような経緯があったのかなどについて、まとめてみます。一冊しか書いていないのでアレかもですが、私のように職業ライターではない、職がエンジニアの方の初執筆や、会社内における調整などの参考にしていただければと思います。 目次 執筆話の発生 会社との調整 執筆契約と〆切 著作権 印税 執筆作業 編集 告知 発売後 執筆について 執筆話の発生 初動 ブログに設置してある、問い合わせフォームからメールがきました。技術評論社の編集者と名乗る方から、ITインフラについての書籍を執筆してみませんか、という内容です。 メールの『執筆』という

    エンジニアが初めて書籍を執筆するにあたって | 外道父の匠
  • 新卒インフラエンジニアを育成した話 | 外道父の匠

    お久しぶりでございます。諸事情によって半年近くも息を潜めていましたが、また継続的なアウトプットをしていきたいと思います。あうとぷっとあうとぷっと。 昨年からAWSに触り始めて、少しずつ研究して、今年から番運用を開始できています。なので、そっち方面が多くなりそうなのですが、その一発目として昨年にAWSを軸に新卒インフラエンジニアを育成してみた話を書いてみます。 経緯 ウチでは一般的な新卒採用を行っています。内定が出て、入社後はエンジニアも一定期間の研修を受けて、そして配属されることになっています。 私は稀に、キャリアプランによっては内定した段階の子との面談を組まされるのですが、その時点でインフラエンジニアになるという断固たる決意を持っていて、研修の段階に入っても意志は変わらなかった野郎がいたのでインフラ部隊に入れることにしました。しましたといっても普通は、配属は人の希望以外に人事部判断や

    新卒インフラエンジニアを育成した話 | 外道父の匠
    yasuharu519
    yasuharu519 2015/05/12
    参考になる
  • 1