NFSクライアントサービスとしては、apt installできるnfs-commonなどが一般的？であるらしい。そのようなパッケージを用いる場合、/etc/fstab というファイルにNFSサーバやマウント先のパスの設定などを書き、ディレクトリの共有を行う。しかし、/etc/fstab を使用した場合だと、ユーザーが NFS でマウントしたファイルシステムにそれほど頻繁にはアクセスしなくても、システムにはその使用頻度に関係なくマウントしているファイルシステム専用のリソースを維持しなければならないという弱点がある。

これに対し、automountシステムは自動的にマウント・アンマウントを行うので、システムのリソースを節約することができるという利点がある。

autofs は、デフォルトの主要設定ファイルとして /etc/auto.master (マスターマップ) を使用し、マウント設定は/etc/auto.hogeに書く。

NFSクライアント側の設定

/etc/auto.hogeファイルを編集。管理者権限が必要。
$ sudo /etc/init.d/autofs restart にてautofsを再起動。

/etc/auto.hogeの書式はmount-point [options] locationで、例えば以下のようになる。

/nas_home    -fstype=nfs,rw,noacl,rsize=32768,wsize=32768    192.168.0.2:/homes # nas

ここで、オプションの意味は

rw:読み込み書き込み可、
noacl:ACP の処理をすべてオフにする、
rsize及びwsize:NFS 通信の読み込み (rsize) と書き込み (wsize) のときに一度に転送するデータブロックサイズ (バイト単位) 。NFSv3 のデフォルト値はいずれも 8192、NFSv4 のデフォルト値は 32768 。

参考

2019-07-17

サーバ管理未経験者がアカウント管理のために勉強したことをまとめる

UNIX インフラメモ

Linuxユーザ

Linuxを使用するときにログインするユーザアカウント。ユーザ独自のパスワードを持つ。

ユーザアカウントの作成にはroot権限が必要になる。

$ cat /etc/passwd

全ユーザの情報を確認する。NISでアカウント情報を共有している場合、その内容はこのファイルには反映されていないので注意。

書式は、ユーザ名：x（古い環境では暗号化されたパスワード）：uid：gid：（ユーザ作成時にのみ設定できる編集不可のコメント）：ユーザのホームディレクトリ：ユーザが使用するシェル

$ who

今現在ログインしているユーザを確認する。

# useradd --gid xxxx --uid xxxx ユーザ名

gidとuidを予め設定しつつユーザの新規追加。

 # passwd　ユーザ名

ユーザのパスワードを設定する

 # userdel -r ユーザ名

ユーザを削除する。-rオプションで、ホームディレクトリも自動削除。

Linuxグループ

例えば、特定のファイルの編集権限を特定のグループだけに与えたい、といったときに便利な概念。ユーザは必ず一つ、メイングループに所属する。その他に所属するグループをサブグループという。

 $ cat /etc/group

全グループの情報を確認する。NISでアカウント情報を共有している場合、その内容はこのファイルには反映されていないので注意。

書式は、グループ名：x（古い環境では暗号化されたパスワード）：gid：所属ユーザ（カンマ区切り）

 # groupadd グループ名

グループの新規作成。

 # groupdel グループ名

グループの削除。存在するユーザのメイングループを削除することは出来ない。

指定したグループのIDを持つファイルが残っている場合、グループを削除すると、そのファイルのパーミッションが不明（501）になる。

rootユーザ

Unix Like System上の唯一神

/etcなどのシステム全体の設定を変更することができたり、消してはいけないすべてのファイルも消すことができる。

 # id
 uid=0(root) gid=0(root)

rootかどうか確認する

 $ su

exitするまでの期間、root権限を使えるようになる。

rootパスワードを用いて実行するので、セキュリティを考えるとsudoの使用が推奨されている。

 $ sudo

コマンド単位で一時的にroot権限を使えるようになる。

ホームディレクトリ

ユーザがログインした直後に配置される場所。

一般ユーザが自由にファイルやディレクトリを作成しても良い空間は、基本的にこのホームディレクトリのみ。ユーザ個別の設定ファイルなどもこのディレクトリ内に置かれる。

基本的に他ユーザのホームディレクトリに変更を加えることはできない。

 $ cd ~     # 方法１
 $ cd        # 方法２

ホームディレクトリに戻る

プロセス

実行中のプログラムみたいなもの。タスクとも言う。

プロセスに適切なメモリやCPU時間などをOSが自動で割り振り、プロセスが終了したときに自動でそれらは開放される。

 $ ps aux

Linux上で現在動作しているプロセスを確認する。

a；端末操作のプロセスを表示、u；CPUやメモリの使用率なども表示、x；現在実行しているプロセスを表示

 $ pstree

プロセスの親子関係を確認する。

 $ top

Linux上で現在動作しているプロセスを確認する。

 $ kill プロセスID

指定したIDのプロセスを殺す。

ゾンビプロセスや暴走したプロセスをkillするときに使われる。基本的に自分の権限で実行しているプロセスしかkillできない。

他者のプロセスをkillする場合にはroot権限を必要とする。

2019-06-27

SSH接続時のWARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

メモインフラ RaspberryPi ネットワーク

ラズパイのOSをSDカードにクリーンインストールして再立ち上げし、同じIPアドレスで再接続しようとすると、このようなwarningが表れた。

$ ssh pi@192.168.xx.xx
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
xxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Please contact your system administrator.
Add correct host key in /Users/username/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /Users/username/.ssh/known_hosts:x
ECDSA host key for 192.168.xx.xx has changed and you have requested strict checking.
Host key verification failed.

このIPアドレスへ接続する際のECDSA host keyが違っているよ！という警告である。

身に覚えがないのに警告された場合は警戒しなければならないが、今回は心当たりがあるので以下の対処を行った。

$ ssh-keygen -R 192.168.xx.xx

こうすると、「このIPアドレスへ接続する際のECDSA host key」の履歴が消えるので、初めて接続するのと同じ状態になり、警告が出なくなる。

2019-06-21

サーバ管理未経験者がNFSサーバの保守のために勉強したことをまとめる

UNIX インフラメモネットワーク

ファイルパス等は私の保守対象に依存する

OS: Linux(CentOS 6.6)
CPU: Dual-Core AMD Opteron Processor 8218 2.6GHz*8

NFS

NFS（Network File System）とは、ネットワーク上のコンピュータが持つストレージを共有するためのシステムのこと。
NFSサーバは、NFSクライアントに対してストレージ領域をエクスポートする。
NFSクライアントは、ネットワークを介してNFSサーバ上のストレージ領域をクライアントのローカルストレージと同様にマウントすることで、NFSのファイルであることを意識せずに読み書きを行うことができる。

ツール：ZFS on Linux

コンピュータのメモリやCPUを限界まで利用するファイルシステム。LinuxのNFSとSMB（Server Message Block；LAN上の複数のコンピュータ間でファイル共有やプリンタ共有などを行うためのプロトコルおよび通信サービス）サーバと融合されている。
用語として、ZFSプールとZFSデータセットというのがあり、プールはデータセットの入れ物、データセットは大きな入れ物であるプールを小分けにして使いやすくした物、というイメージ。

ツール：autofs

8.4. autofs - Red Hat Customer Portal
9.4.2. autofs の設定 - Red Hat Customer Portal

Automount は、その名の通り NFS ファイルシステムの自動マウントおよび自動アンマウントをしてくれるシステム。
/etc/fstab を使用する場合、ユーザーが NFS でマウントしたファイルシステムにそれほど頻繁にはアクセスしなくても、システムにはその使用頻度に関係なくマウントしているファイルシステム専用のリソースを維持しなければならないという弱点がある。
これに対し、automount システムは自動的にマウント・アンマウントを行うので、システムのリソースを節約することができる。
autofs は、デフォルトの主要設定ファイルとして /etc/auto.master (マスターマップ) を使用する。

NFSサーバ側

動作確認

# exportfs  //方法１
# showmount -e  //方法２

実際のエクスポート状況を確認
ZFS on LinuxのNFSの機能を用いている場合でもこれでエクスポート状況を確認できる

# showmount -a

クライアントのマウント状況を確認
クライアントのホスト名とマウントされたディレクトリの両方を（host:dir形式）で表示
ZFS on LinuxのNFSの機能を用いている場合はこれではマウント状況を確認できない

# service nfs status

nfsの状況を確認

# zpool list

ZFSプールの状況を確認（共有ボリュームの状況を確認、という感じ）
NAME；プールの名前。SIZE；プールの合計サイズ。ALLOC；すべてのデータセットおよび内部メタデータに割り当てられた物理的容量。使用可能なファイルシステムの容量ではない。FREE；プール内で割り当てられていない容量。CAP (CAPACITY)；使用されているディスク容量。総ディスク容量に対するパーセントで表現されます。HEALTH；プールの現在の健全性状態。ALTROOT；プールの代替ルート (存在する場合)。

設定確認

# cat /etc/exports

エクスポート設定ファイルを確認
ZFS on LinuxのNFS機能を用いる場合はこのファイルは使わない

# cat /etc/rc.d/rc.local

ランレベルにかかわらず、システム起動時に毎回必ず起動するスクリプト、の確認。
ユーザが起動時に実行させるコマンドなどはこのスクリプトに登録するのが一般的らしい。
私の環境ではこのファイルにZFSのエクスポート設定コマンド（zfs set ...）などを記載している。

設定変更

上記２種類のファイルはお好みのエディタで編集可能。

# zfs set sharenfs="rw=@IPaddress,rw=..." PATHofShareDirectory

zfsによるエクスポート設定
rwはエクスポートオプションを示し、意味は rw = Read Write
接続許可クライアント（複数の場合はカンマ区切りで連ねる）と、共有ボリュームのパスを指定

起動・再起動

# exportfs -r

NFSによるエクスポートを行う。/var/lib/nfs/xtab を /etc/exports と同期させる。 /etc/exports から削除されたエントリを /var/lib/nfs/xtab からも削除し、既に無効になったエントリをカーネルのエクスポートテーブルから削除する。

# service nfs start

nfs起動

# chkconfig nfs on

nfs 自動起動

# zfs share PATHofShareDirectory

zfsによるエクスポートを行う。

NFSクライアント側で行うこと

動作確認

# df -h
# mount

マウント状況を確認

# mount -a

/etc/fstabに記載がある全てのデバイスをマウントする
autofsを用いる際は必要ない（と思う）

# service autofs status

autofsの状況を確認

設定確認

# cat /etc/fstab

mount -aによってマウントされるデバイスの情報が記載されている。
/etc/fstabファイルには、NFS サーバーのホスト名、エクスポートされるサーバーディレクトリー、および NFS 共有がマウントされるローカルマシンディレクトリーなどの設定が記載されている。
ブート時にこのファイルを自動的に読み込み、リモートファイルシステムが自動的にマウントされる。

$ cat /etc/auto.master

autofsの主要設定ファイルを確認する
書式はmount-point mount-nameで、mount-pointはマウントする場所のパス、mount-nameはマウント設定ファイルのパス
Mount-pointとして /- を指定すると、この特定のマップが直接マップであり、マップに関連付けられている特定のマウントポイントがないことを表している...とのことだが、これはいまいちよく分かっていない。

$ cat /etc/auto.mount

autofsによる、自動マウントのアクセス先設定ファイルを確認する
書式はmount-point [options] location。
ファイル名はauto.masterのmount-nameに依存。

2019-06-21

サーバ管理未経験者がNISサーバの保守のために勉強したことをまとめる

インフラメモ UNIX ネットワーク

ファイルパス等は私の保守対象に依存する

OS: Linux(Debian sarge)
CPU: GeodeNX1500

NIS

NIS（Network Information Service）は、LAN内のクライアントとシステムの設定情報を共有するためのシステム。
具体的には、NISサーバの/etc以下にある設定ファイル等がクライアントに共有される。
NIS クライアントは、バインドプロセスと呼ばれる方法で NIS サーバーから情報を取得する。

NISサーバ側で行うこと

NISの設定確認・変更

NISサーバ自体の設定をいじる機会はなかった。
NISサーバでユーザを追加するなどしてシステム設定情報を変更することはあったが、それはNISサーバの設定変更と言うよりシステムの設定変更なので、タイトルを分けて掲載することにする。

システムの設定確認

$ cat /etc/passwd

ユーザ一覧。
書式は、ユーザー名：ユーザー番号（UID）：グループ番号（GID）：コメント：ログインしたときに起動するシェルの場所

$ cat /etc/group

グループ一覧。
書式は、グループ名：xもしくは暗号化されたパスワード：グループID( GID )：サブグループとして所属しているユーザーアカウントのリスト

$ cat /etc/shadow

ユーザのパスワードを暗号化して格納するファイル。

$ id USERNAME

ユーザが登録されていれば、UID、GID等が表示される。
例えば、uid=1111(username) gid=2222(groupname) groups=2222(groupname),2223(groupname2)

システムの設定変更

上記３ファイルをエディタなどで直接編集することは無い。下記のadduserコマンドにより編集する。

# adduser --gid 2222 --uid 1111 username

新しいユーザーのログイン ID を作成。このコマンドを実行すると、NIS マスターサーバー上の /etc/passwd ファイルと /etc/shadow ファイルにエントリが自動的に作成される。
—gid；ユーザの所属グループ番号　（みんな一緒）
—uid；ユーザ番号　（被り不可）
username；任意のユーザ名（被り不可）
NISサーバ上でユーザを作ることで、NISの機能により、このユーザ情報が全NISクライアントに共有される。

システムの設定変更反映

# cd /var/yp
# make

新規ユーザを追加するなどしたあとに、これを行う。

NISクライアント側で行うこと

動作確認

$ id USERNAME

NISがきちんと機能していれば、NISサーバに登録されているユーザの情報が自動的に取得できる。

$ ypwhich

NISサーバとの接続を確認
今まで接続できていたのに接続できなくなった、という場合には、コンピュータを再起動すると治ったりする。

設定確認

$ cat /etc/nsswitch.conf

NISクライアントの設定を確認。
このファイルには、システム情報のうちのどの情報をNISサーバと共有するか等が書かれている。
基本的に、一番最初のセットアップ時にしか変更しないだろうファイル。

$ cat /etc/group

個々のクライアントでの記述は行なわない．
ファイル末尾に、NISサーバからグループ情報を取得するということを明示する下記の記述がされている。

-nogroup
+;;;

$ cat /etc/passwd

個々のクライアントでの記述は行なわない．ファイル末尾に、NIS サーバからユーザ情報を取得するということを明示する下記の記述がされている。

-nobody
+::::::

$ cat /etc/defaultdomain

デフォルトドメインなるものの設定。taurasと記載されているが、これはどういう意味だろうか。。

設定変更

既に運用されているNISクライアントの設定をいじる機会はこれまで無かった。

NISクライアントのセットアップも、これまで自分ではしたことがないが、先輩の記録が残っていたのでメモしておく。自分では動作を確認していないので注意。。。

# aptitude install nis
# vi /etc/passwd   //上記で説明した末尾２行を追加
# vi /etc/group   //上記で説明した末尾２行を追加
# vi /etc/defaultdomain   //上記で説明した通りtaurasに変更
# /etc/init.d/nis restart   //設定変更の反映
という流れ、らしい。

設定変更

# /etc/init.d/nis restart

NISクライアントを再起動
NISクライアント設定を変更した場合にのみ行う。

2019-06-20

サーバ管理未経験者がDHCPサーバの保守のために勉強したことをまとめる

インフラメモ UNIX ネットワーク

ファイルパス等は私の保守対象に依存する

OS: Linux(Debian sarge)
CPU: GeodeNX1500

DHCP

DHCP(Dynamic Host Configuration Protocol)とは、LAN上のクライアントが起動すると、その都度、IPアドレスなどのネットワーク利用に必要な設定情報をクライアントに提供するプロトコル。
各サーバで固有のIPアドレスを使いたい場合でも、各サーバが自分で固定IPを持っているのではなく、DHCPサーバによって固定的にIPアドレスを割り振るという方法も可能。

DHCPサーバ側

$ cat /etc/dhcpd.conf

DHCPサーバの設定ファイルを確認する
option domain-name “DOMAIN”；クライアントがホストの名前解決で使用するドメイン名を指定する。/etc/resolv.conf の search 行に相当。ドメイン名を指定するときには必ず、"" で囲む必要があるとのこと。
option domain-name-servers ipaddress [,ipaddress…]；DNS サーバーの IP アドレスを指定する。複数存在する場合はカンマで区切る。

DHCPクライアント側

$ cat /etc/network/interfaces

コンピュータのネットワーク設定ファイルを確認する
クライアント側の設定でIPアドレスを固定したい場合などに、このファイルを弄ることになる
ちなみにデフォルトでは以下のようになっている

auto lo
iface lo inet loopback

2019-06-19

サーバ管理未経験者がDNSサーバの保守のために勉強したことをまとめる

UNIX ネットワークインフラメモ

ファイルパス等は私の保守対象に依存する

OS: Linux(Debian sarge)
CPU: GeodeNX1500

DNS

DNS（Domain Name System）は、ドメイン名とIPアドレスの対応付けや、メールの宛先ホストを指示するためのシステム。
DNSサーバはドメイン名とIPアドレスの対応を答える役割を持ち、DNSクライアントはリゾルバというプログラムによってDNSサーバに問い合わせを行う。

ツール：BIND

BIND（Berkeley Internet Name Domain）は、いわゆるDNSサーバとリゾルバライブラリ、各種ツールの集合体なアプリケーション。
BIND の実体プログラムをnamed（ねーむでぃー）という。namedは通常デーモンとして稼動し、 FQDN から IPアドレスへ、またはその逆への名前解決を担っている。

DNSサーバ側

動作確認

$ ping IPaddress
$ ping domainName

pingコマンドは指定したコンピュータとの間でネットワークが疎通しているかどうかを調べるコマンド。
まず、IPaddressでpingしてみることで、ネットワーク自体が繋がっているか？を確かめられる。
次に、サーバのドメイン名宛にpingしてみることで、IPアドレス→ドメイン名への変換（DNS）が機能していることが確かめられる。

各種設定確認

$ cat /etc/bind/named.conf

DNSサーバの設定を確認する
BIND自体の基本設定ファイル。DNSサーバー自体の設定の他、正引き用設定ファイルや逆引き用設定ファイルのパスなどを指定する。

$ cat /etc/bind/domain2ip

ドメイン名→IPアドレスの対応（正引き）を確認する
正引き用設定ファイル（ファイル名domain2ipはnamed.confの内容に依存）

$ cat /etc/bind/ip2domain

IPアドレス→ドメイン名の対応（逆引き）を確認する
逆引き用設定ファイル（ファイル名ip2domainはnamed.confの内容に依存）

設定変更

お好みのエディタで上記３種のファイルを編集できる。

設定変更の反映

$ /etc/init.d/bind restart

DNSのデータベース(/etc/bind/以下)への変更を反映する。ファイルを編集しただけでは反映されないので注意。

$ ps aux | grep named. # プロセスID番号（以下PID）を確認
$ kill PID # 実行中のnamedを殺す
$ /usr/sbin/named -c /etc/bind/named.conf # BINDの起動
$ cd /usr/sbin
$ ./named # namedの再実行

/etc/bind/named.confを編集した場合は、namedの再起動を行う必要がある。
（このとき、外部DNSサーバのnamedはrootアカウントで実行すべきではなく、仮に不正侵入を許しても大丈夫なアカウントで実行させるのが約束事になっている、らしい）

DNSクライアント側

DNSの動作確認

$ ping IPaddress
$ ping domainName

DNSサーバの動作確認の項目と同じ。

設定確認

$ cat /etc/resolv.conf

リゾルバの設定ファイルを確認する
nameserver IPaddress；DNSサーバのIPアドレスを設定する
search localDomainName, ...；domainの複数版で、ローカルドメイン名を設定する。例えばping hogeしたときにping hoge.localDomainNameと自動で補ってくれるようになるらしい