作成者別アーカイブ: 工藤

工藤 について

インフラエンジニア 主にサーバ・ネットワークを担当

Freenasで簡単samba ホント詳しくない人向け

タグ: | 投稿日: 投稿者:

こんばんは。工藤です。

親不知が今さらヤル気を出してきて、とても迷惑です。アゴが痛い…

で、本日はfreenasで、PCとかあんま詳しくない人向けの共有サーバーを作成したいと思います。

目標
・極力GUIで実施する。
・ACLを実現する。
・JJ(注1)でも分かりやすい手段を取る。

考え方
・ユーザー権限の与え方はグループを使用する。
→freenasでは１ユーザーは複数のグループに所属できる。
これを踏まえ、ディレクトリのグループ権限でACLを実現する。

作成方法
まず、ディレクトリは「CIFSの追加」では作られない。そのため、必要となるディレクトリはユーザーを作成し、そのホームディレクトリの作成を実施する。ついでに、当ユーザーを作る際に、あらかじめACLをかけておきたいグループに所属させる。そうする事で後々グループの変更等を実施しなくてもよくなる。
「Windows share」から新規で共有ディレクトリを作成する。共有名などは日本語でもOKなので、適当に名前をつける。「パス」の指定の際、上記で作成したユーザーホームディレクトリを指定する。その後、「Inherit Owner」「パーミッションの継承」「ゴミ箱の有効化」にチェックを入れ「OK」を押下。

管理方法
共有ディレクトリを作成した際、指定したパスのディレクトリの所有者を確認し、制御したいユーザーの「補助グループ」に上記ユーザーが所属するグループを追加する。

で、面倒くさいけど、これらの作業を実施した最期は必ずサービスの再起動が必要。
「サービスの制御」→「CIFS」のoff/on実施。

上記で適用完了。
うわっめんどくさっ！が出来た！

注1：情弱（この場合の情弱は情報弱者というよりも、ITリテラシーの低い人を指します）

このエントリーをはてなブックマークに追加
Share on GREE

【備忘録】lsyncdの使い方 ssh編

タグ: | 投稿日: 投稿者:

ご無沙汰しております。工藤です。

しさしぶりなのでライトな内容にしようと思います。

インフラエンジニアではお馴染みのリアルタイム同期ツール「lsyncd」の使い方について。
lsyncd自体についての説明は割愛します。

相変わらずのCentOSでのやり方。

yumります。 

# yum install lsyncd

レポジトリは任せます。(epelとかだと2.1.4とかなんで便利です)

sshで同期を実施するため、同期元→同期先といった感じでpushによる同期となります。sshの鍵を作成します。

(同期元) 

# ssh-keygen -t rsa

出来上がったファイルを同期先のauthorized_keysにコピーします。

(同期元) 

#scp .ssh/id_rsa.pub (同期先アドレス):/root/.ssh/authorized_keys

sshでログインしてみましょう

(同期元) 

# ssh root@(同期先)

ログインできたらOKです。これでNGなら何かがおかしいので、/ssh/sshd_configなどをよく見ましょう。

lsyncdを設定します。yumると/etcにlsyncd.confが作成されています。
簡単に動かすだけならこんな感じです。

例：同期したい元ディレクトリ /home
同期したい先ディレクトリ /home
同期したいくないディレクトリ /home/exclude 

settings{
    logfile = "/var/log/lsyncd/lsyncd.log",
    statusFile = "/var/log/lsyncd/lsyncd.status",
    nodaemon = false,
}
sync{
    default.rsync,
    source = "/home/",
    target = "root@(同期先):/home/",
    rsync = {
      _extra = { "-av" },
    },
    exclude = "/home/exclude",
}

こんな感じです。

で、lsyncdを起動します。 

# /etc/init.d/lsyncd start

自動起動に登録します。 

# chkconfig lsyncd --on

後はちゃんと同期されているか確認してみましょう。

 

このエントリーをはてなブックマークに追加
Share on GREE

Gratuitous ARP

タグ: | 投稿日: 投稿者:

こんにちは。工藤です。
もうすぐ春ですね。春が過ぎると夏ですね。夏の後には秋がきて、やがて冬ですね。

「Gratuitous ARP」ってカタカナだと「グラチュータスアープ」と読むみたいです。
勝手に「グラシャスアープ」とかって覚えてました。スペイン語でありがとう「Gracias(グラシャス)」って全然違うじゃん。ありがたいarpってなんだって話です。

このGratuitous ARPは同じネットワーク内にIPアドレスの重複が発生しないかを確認するために使われます。この辺りは通常あまり意識しなくてもいいかもしれません。
もう一つ、IPの重複確認とは別にarpキャッシュなどを使用する機器「ホスト」「ルータ」「L3スイッチ」のarpテーブルを強制的に更新させる事もできます。
これらの機能を良く使用するのがVRRPなどですね。

ルータやL3スイッチの交換を実施する際に、このGratuitous ARPが威力を発揮します。例えばarpテーブルのキャッシュを300秒保持するスイッチなどがあった場合、ケーブルの差し替えだけではarpテーブルが更新されないため、通常は300秒待たないといけません。しかしこのGratuitous ARPを意図的に発行できれば、300秒待たずとも疎通を行う事ができます。

しかし使用法を誤った場合、同ネットワークのarpテーブルが狂い、正常な通信を阻害してしまう事にもつながります。そのため、通常は人為的な発行はせずに、機器が起動するタイミングやネットワークの再起動などを実施した際に自動的に発行されます。

具体的な方法についても書こうと思いましたが、面倒なのでまた別の機会にします。
機器の交換を実施する時は、時間はかかるが機器の再起動によるarpテーブル更新が一番確実ですね。

このエントリーをはてなブックマークに追加
Share on GREE

LVMでVGを変更したら再起動後にKernel panicになった

タグ: | 投稿日: 投稿者:

こんにちは。工藤です。

Linuxのバックアップやリストアに便利ツール「Mondorescue」を使用する事が良くあり、P2Vなどに重宝したりする事もあるのですが、バックアップは簡単だけど、リストアってホント面倒だよね。
「リストアなんて事が発生しませんように！」
って毎回祈ってバックアップ取ってますから。

で、今回もハマったポイントについて。(CentOS版)

バックアップしたマシンとリストアするマシンが異なる場合などに起こり得やすい。
HDDのサイズなんかが異なっていて、手動でLVMを作成し、そこへバックアップデータをリストアした時なんかに特に注意。
grubのdevice.map、grub.confとかfstabとかmtabとかは比較的ちゃんと書き直すのですが、いざ起動しようと思うと

Volume Group not found

Kernel Panic

ってなってヤな感じです。ホント、起動中にコケるのが一番嫌いです。やる気が削がれ「あーーーーー」ってなるから。

で、気を取り直して問題解決へ。
Linuxの起動プロセスを考えるに、どうやらinitrdというヤツがキモらしい。
ここを変更したLVMの内容に書き換えなくてはならない。

Rescue CDなんかで起動させて、いつもの

# chroot /mnt/sysimage

やって

# cd /boot
# mkinitrd initrd-2.6.18-308.13.1.el5.img 2.6.18-308.13.1.el5
など実施し、initrdを再作成する。(もしアレならgrub-installしなおしても可)
そして再起動！

NGポイントがここだったらこれで回復。ここ以外だったらそれはまた別のお話。

このエントリーをはてなブックマークに追加
Share on GREE

OOM killerを消極的方法で回避

タグ: , | 投稿日: 投稿者:

こんにちは工藤です。

Linuxの運用をしているとたまにやってくるoom-killer。
詳しい説明は割愛しますが、簡単に言うとメモリ不足が発生しシステムダウンを防ぐため、無差別にプロセスを殺してゆく機能です。不要なプロセスなら問題ないのですが（そもそも不要なら立ち上げないけど）重要なプロセスの場合は殺されてはたまったものではありません。いくらシステムダウンを防ぐためとはいえ、サービスの提供できないサーバなんか死んだも同然。本末転倒ですわ。

っつう事でoom-killerが発動する場合はそれはすでにシステムとして正常に稼働していない。という事にして、とっととシステムを再起動させます。その方がきっと傷口は小さくて済むはず。原因調査より復旧が優先だから！原因調査なんて賢い人がやってくれるハズです。

oomの発生時に直接再起動というプロセスは踏めないため、oom時にkernel panicになるように設定します。

/etc/sysctl.confに下記を追記しましょう。

vm.panic_on_oom=1

さらにいつも通りkernel panicになったら再起動するアレを入れておきます。

kernel.panic=60　(秒数はお好みで)

上記2行を追記したら

# sysctl -p

で適用します。

こうする事で、oom発動→kernel panic→再起動となります。

もう一度念のために

oomの原因調査は賢い人がやってくれるハズ！

このエントリーをはてなブックマークに追加
Share on GREE

サーバの運用管理

タグ: | 投稿日: 投稿者:

こんにちは。工藤です。

インフラ屋さんとして業務を行っていますが、サーバの管理、運用なども行っています。この管理、運用業務が意外と頭を悩ませる内容で、どうやって管理をしたら良いか試行錯誤の日々です。

いったいヨソの会社ではどうやってサーバの管理を行っているのだろうか？エクセル？自作ツール？

サーバと一口に言っても関わる人間が多く、また用途も様々。誰かが専任で管理をするなどほぼ不可能。当たり前かもしれないが、内容がニッチなんでそんな便利ツールを作って公開する人なんていないだろ…

 

いたーーーーーーーーー!!

 

ライブドアさんが数千台規模のサーバを管理するために作成したツール「yabitz」

https://github.com/livedoor/yabitz

完全にサーバ管理に特化しているため、その他の用途としてほぼ使用できないくらいにカスタマイズ不能。サーバ管理業務を行った事がある者にしか分からないある種の怨念すら感じる。弊社サーバ台数はせいぜい数百といったところなので、まだまだヒヨッコではありますが、このツールの作成者の方にはシンパシーを感じざるを得ません。

サーバ管理業務を行う上で必要な項目を過不足なく設定でき、かつ操作感もダイレクト！エレガント！これでもう営業から「この顧客で使用しているサーバって何台？」とか、開発から「このIPのサーバってどこにあるの？」とか、経理から「課金、非課金のサーバは？」といった問い合わせ(※あくまで弊社の場合)に対してggrksスピーディに対応する事ができます。非常に重宝しており、作者の方には何かの折にごあいさつに伺いたいと思うほどです。

世のサーバ管理業務担当者にGOD BLESS YOUだ。

このエントリーをはてなブックマークに追加
Share on GREE

【復習】ルーティングの優先順位

タグ: | 投稿日: 投稿者:

あけましておめでとうございます。工藤です。

昨年からスッキリのど越しのスーパードライから、やや苦味のあるラガーへビールの好みが変わりました。

さて、ルーティングについてのお話です。

ルーティングの優先順位の決め方は「メトリック値の小さい方から」というのは誰しもが知るところかと思いますが、メトリック値が同じだった場合はどうなるの？

CIDRによるとプレフィックスの大きい順。つまりネットワークの小さい方が優先されます。

例)192.168.0.0/16のゲートウェイが192.168.100.1,192.168.1.0/24のゲートウェイが192.168.1.1だとすると、メトリック値が同じであれば192.168.1.0/24のルーティングが優先される。

サブネットの考え方を辿れば「そりゃそうだ」という事ですが、そんなネットワークの歴史に興味ねーし。

これらより、「デフォルトルートを変更したいけど、すでに設定されているデフォルトルートは書き換えたくない」といった要望を叶える事ができます。

0.0.0.0/1と128.0.0.0/1のルートを追加し、そのゲートウェイを変更したいIPに設定します。

具体的には下記のようになります。

0.0.0.0/0(default)     GW     1.1.1.1
0.0.0.0/1                   GW     2.2.2.2
128.0.0.0/1               GW     2.2.2.2

このようにすると実質的にデフォルトゲートウェイは「2.2.2.2」になります。

※規定されているルールですが、お使いのハードウェアが対応しているかはご自身でお確かめください。ちなみにwindowsやLinux、BSDは準拠しています。

今年もよろしくお願いします。

このエントリーをはてなブックマークに追加
Share on GREE

heartbeatで若干ハマる

タグ: | 投稿日: 投稿者:

こんにちは。工藤です。浅草界隈に生息しておりますが、仲見世はすっかり新年です。

CentOS 6でheartbeat3.0.5を使い、仮想IPとお決まりのDRBD、httpd、postgresql9.2をフェールオーバーさせようと試みた。

普通にharesourcesに

server01 \
IPaddr2::10.8.0.1/24/em1/10.8.0.255 \
MailTo::root::server01 \
drbddisk::r0 \
Filesystem::/dev/drbd0::/home \
postgresql-9.2 \
httpd

としてharesources2cib.pyを実行して、オラッと

# /etc/init.d/heartbeat start

したら、postgresqlまでは正常に動き出したが、httpdが上がったり落ちたりを繰り返している様子。

ググるとhttpd.confに”ExtendedStatus On”が無いなどの情報があり、一通りやってみたがどれも上手くいかない。

意を決してログを読むと

WARN: For LSB init script, no additional parameters are needed.

とあり、LSBでは余計なパラメータは不要との事。ocfでもない限りは<operation>はいらないっぽいので、cib.xmlから消して再読み込みさせてから再度オラッと

# /etc/init.d/heartbeat restart

したらhttpdも落ち着きました。プロセス監視が入っていませんが、取り急ぎ「動かす」事ができました。

最初からログを見れば良かったって話ですが、heartbeatのログはちょっと肌に合わないので…

このエントリーをはてなブックマークに追加
Share on GREE