CentOS 7は、従来のCentOS 6.xの管理手法と異なる点が多々存在します。今回は、CentOS 7の管理者が最低限知っておくべき管理手法についてお伝えします。
CentOS 7のシステム管理基礎
CentOS 6系は、主にUNIX System V系のinitによるアーキテクチャを基にしたLinux OSであるのに対し、CentOS 7では、systemdを主体としたものになっています。従来のCentOS 5で採用されていたSysVinitやCentOS 6で採用されていたUpstartは様々なサービスの起動をシェルスクリプトで管理していました。しかし、これらCentOS 5やCentOS 6で採用されている起動スクリプト等の実行は並列に処理する概念が取り入れられていないため、OSの起動時間の増大を招いていました。CentOS 7で採用されているsystemdは、従来ではシェルスクリプト等を駆使した各種サービスの起動処理を一新し、起動に関連する一連の処理を高速に行う仕組みが取り入れられています。
ランレベルの廃止
CentOS 6系とCentOS 7系で大きく異なるのは、ランレベルの考え方です。CentOS 7では、ランレベルという概念が廃止され、「ターゲット」と呼ばれる概念が導入されています。CentOS 6系で利用されていたランレベルを管理する/etc/inittabファイルは、CentOS 7においてもはや利用されません。以下では、CentOS 6系でのランレベル3(CLI画面での運用)、ランレベル5(GUI画面での運用)、ランレベル1(シングルユーザーモード)に相当するCentOS 7での実際の運用管理を例示します。CentOS 6系では、/etc/inittabファイルの記述によってOS起動時のデフォルトのランレベルを変更し、runlevelコマンドによって現在稼働中のランレベルを表示していました。一方、CentOS 7においてデフォルトで設定されている状況を確認するには、systemctlコマンドを使います。
この状態は、CentOS 6系でのランレベル3に相当する状態です。OS起動時に自動的にGUIのログイン画面が表示される設定にする前に、利用可能なターゲットを確認してみます。
01 | # systemctl list-units --type=target --all --no-pager |
02 | UNIT LOAD ACTIVE SUB DESCRIPTION |
03 | basic.target loaded active active Basic System |
04 | cryptsetup.target loaded active active Encrypted Volumes |
05 | emergency.target loaded inactive dead Emergency Mode |
06 | final.target loaded inactive dead Final Step |
07 | getty.target loaded active active Login Prompts |
08 | graphical.target loaded inactive dead Graphical Interface |
09 | local-fs-pre.target loaded active active Local File Systems (Pre) |
10 | local-fs.target loaded active active Local File Systems |
11 | multi-user.target loaded active active Multi-User System |
12 | network-online.target loaded inactive dead Network is Online |
13 | network.target loaded active active Network |
14 | nfs.target loaded active active Network File System Server |
15 | nss-lookup.target loaded inactive dead Host and Network Name Lookups |
16 | nss-user-lookup.target loaded inactive dead User and Group Name Lookups |
17 | paths.target loaded active active Paths |
18 | remote-fs-pre.target loaded inactive dead Remote File Systems (Pre) |
19 | remote-fs.target loaded active active Remote File Systems |
20 | rescue.target loaded inactive dead Rescue Mode |
21 | shutdown.target loaded inactive dead Shutdown |
22 | slices.target loaded active active Slices |
23 | sockets.target loaded active active Sockets |
24 | sound.target loaded active active Sound Card |
25 | swap.target loaded active active Swap |
26 | sysinit.target loaded active active System Initialization |
27 | syslog.target not-found inactive dead syslog.target |
28 | time-sync.target loaded inactive dead System Time Synchronized |
29 | timers.target loaded active active Timers |
30 | umount.target loaded inactive dead Unmount All Filesystems |
32 | LOAD = Reflects whether the unit definition was properly loaded. |
33 | ACTIVE = The high-level unit activation state, i.e. generalization of SUB. |
34 | SUB = The low-level unit activation state, values depend on unit type. |
36 | 28 loaded units listed. |
37 | To show all installed unit files use 'systemctl list-unit-files'. |
上記に表示されている「graphical.target」が、CentOS 6系のランレベル5に相当します。それでは、OS起動時に自動的にGUIログイン画面が表示されるグラフィカルターゲットに設定します。
1 | # systemctl set-default graphical.target |
2 | rm '/etc/systemd/system/default.target' |
3 | ln -s '/usr/lib/systemd/system/graphical.target' '/etc/systemd/system/default.target' |
上記から、グラフィカルターゲットへの移行は、シンボリックリンクの貼り替えであることがわかります。OS起動時に自動的にGUIのログイン画面が表示されるか確認するため、CentOS 7を再起動します。
CentOS 7で定義されている各種ターゲットが、従来のどのランレベルに相当しているかの対応関係を確認することができます。
1 | # ls -l /lib/systemd/system/runlevel*target |
2 | lrwxrwxrwx. 1 root root 15 Sep 1 23:28 /lib/systemd/system/runlevel0.target -> poweroff.target |
3 | lrwxrwxrwx. 1 root root 13 Sep 1 23:28 /lib/systemd/system/runlevel1.target -> rescue.target |
4 | lrwxrwxrwx. 1 root root 17 Sep 1 23:28 /lib/systemd/system/runlevel2.target -> multi-user.target |
5 | lrwxrwxrwx. 1 root root 17 Sep 1 23:28 /lib/systemd/system/runlevel3.target -> multi-user.target |
6 | lrwxrwxrwx. 1 root root 17 Sep 1 23:28 /lib/systemd/system/runlevel4.target -> multi-user.target |
7 | lrwxrwxrwx. 1 root root 16 Sep 1 23:28 /lib/systemd/system/runlevel5.target -> graphical.target |
8 | lrwxrwxrwx. 1 root root 13 Sep 1 23:28 /lib/systemd/system/runlevel6.target -> reboot.target |
上記より、グラフィカルターゲットは、従来のランレベル5に相当することがわかります。
OS再起動無しでグラフィカルターゲットとマルチユーザーターゲットを切り替える
CentOS 6系では、telinitコマンドを使ってランレベルの変更を行っていました。CentOS 7では、systemctlコマンドで以下のようにして、X Windowが起動している状態とX Windowが起動せずにマルチユーザー環境の状態(CentOS 6系のランレベル5やランレベル3)を切り替えることができます。
X Windowが起動していないマルチユーザーモードの状態への変更は、以下のようにします。
1 | # systemctl isolate multi-user.target |
上記の操作は、CentOS 6系のtelinit 3に相当する操作です。
CentOS 6系のランレベル5に相当するX WindowによるGUIのログイン画面の状態に変更するには、以下のようになります。
1 | # systemctl isolate graphical.target |
上記の操作は、CentOS 6系のtelinit 5に相当する操作であるため、X Windowを利用したGUIログイン画面が起動しますが、OS起動時に自動的に設定されるデフォルトのターゲットが変更されたわけではありません。デフォルトのターゲットを確認してみます。
上記のように、現在稼働中のOSがグラフィカルターゲットであっても、OS起動時に自動的に設定されるデフォルトのターゲットとは異なりますので、現在のターゲットの状況と、OS起動時に自動的に設定されるデフォルトのターゲットの両方を確認するようにして下さい。
CentOS 7におけるシングルユーザーモードと緊急モード
システムに不具合やシステムの継続稼働が困難になった場合に、シングルユーザーモードや緊急モードに移行する必要がでてきます。CentOS 6系では、telinit 1などによりランレベル1になりシングルユーザーモードになっていましたが、CentOS 7では、systemdを使ってレスキューターゲットやエマージェンシーターゲットを指定することで状態を切り替えることができます。以下では、シングルユーザーモードと緊急モードへの切り替えとその場合のメンテナンスの基本を説明します。シングルユーザーモードになると、ネットワーク通信機能が切断されてしまいますので、telnet等の仮想端末で遠隔から操作している場合には、ローカルマシンでの作業に切り替える必要があります。または、ハードウェアベンダーが提供するサーバーに搭載された遠隔管理用のチップの仮想端末等を利用し、OSのネットワーク通信機能を利用しなくても遠隔管理できる仕組みを整えておく等の事前の対処が必要ですので、十分注意して下さい。シングルユーザーモードになるためには、コマンドラインから以下のように入力します。
1 | # systemctl isolate rescue.target |
下図は、サーバーの遠隔管理チップの仮想端末ウィンドウ上で、リモートにあるCentOS 7サーバーのシングルユーザーモードの画面を表示しています。シングルユーザーモードでは、rootアカウントのパスワードを入力します。
図1:CentOS 7のレスキューモード(クリックで拡大)
以下に、CentOS6系のSysVinitのランレベルとCentOS 7のsystemdターゲットの対応表を示します。
図2:CentOS 6系のランレベルの概念とそれに対応するCentOS 7のsystemdのコマンド(クリックで拡大)
systemdの仕組み
CentOS6系では、chkconfigコマンドによるサービスの有効化、無効化の切り替え、/etc/init.dディレクトリ配下のスクリプトに対してstart/stop/status等のパラメータを与えることで、様々なサービスの制御を行っていました。CentOS7においては、サービスの制御をsystemdによって行います。具体的には、管理者は、systemctlコマンドを使ってサービスの起動、停止、状態確認等を行います。CentOS 6までは、デーモンと起動スクリプトの集合体でサービスを管理していましたが、CentOS 7のsystemdでは、「ユニット」と呼ばれる単位で管理を行います。CentOS 5のSysVinitやCentOS 6のUpstartにおける起動スクリプトを使った処理が、CentOS 7では、複数の「ユニット」に分割されて、並列実行を行うことにより、OSの起動速度の高速化を実現しています。また、従来のデーモンと複雑な起動スクリプトの集合体では、スクリプトの記述がサービス毎に異なっており、管理が複雑化していましたが、systemdにより記述が標準化されており、複雑なスクリプト群をできるだけ排除する設計が見られます。systemdの管理の単位となるユニットには、以下に示す幾つかのタイプが存在します。
service | 各種デーモンやサービスの起動 |
target | 従来のランレベルに相当する起動プロセスをまとめたユニット群の処理に使用 |
mount | ファイルシステムのマウントポイント制御 |
device | ディスクデバイス |
socket | FIFO、UNIXドメインソケット、ポート番号等に関する通信資源 |
「service」は、OSの各種デーモンやサービスの起動に関連するユニットです。例えば、メールサービスで有名なpostfixであれば、「postfix.service」として管理されており、postfixサービスの制御に関わる設定ファイルは、/usr/lib/systemd/system/postfix.serviceです。
登録されているサービスのOS起動時における自動起動の有効化または無効化の設定状態を表示するには、ユニットの種類としては「service」を指定し、list-unit-filesを指定します。
01 | # systemctl -t service list-unit-files |
03 | abrt-ccpp.service enabled |
04 | abrt-oops.service enabled |
07 | vsftpd.service disabled |
08 | vsftpd@.service disabled |
09 | wacom-inputattach@.service static |
10 | wpa_supplicant.service disabled |
CentOS 7.0の時点では、全てのサービスがsystemdに移行している訳ではなく、旧来のCentOS 6系で使われていた/etc/init.dディレクトリ配下のサービス群が残っています。これらの一部のサービスについては、chkconfigコマンドを使ってサービスの有効化・無効化の設定を行って下さい。
以下では、例として、FTPサービスの起動、停止、状態確認、OS起動時の自動起動の有効化・無効化の設定を行ってみます。まずFTPサービスが、systemdのユニットにおいてどのような名前のサービスとして登録されているのかを確認します。
1 | # systemctl -t service list-unit-files |grep -i ftp |
4 | vsftpd@.service disabled |
FTPサーバーを実現するサービスは、「vsftpd.service」です。「vsftpd.service」の右側を見ると「disabled」と表示されていあす。これは、OS起動時に、「vsftpd.service」が自動的に起動しない設定になっていることを意味します。サービスの状態確認は、systemctlコマンドに「status」を指定します。また、systemctlコマンドの利用においては、サービス名の「.service」を省略することができます。
1 | # systemctl status vsftpd |
2 | vsftpd.service - Vsftpd ftp daemon |
3 | Loaded: loaded (/usr/lib/systemd/system/vsftpd.service; disabled) |
4 | Active: inactive (dead) |
上記の「Active:」の項目を見ると「inactive(dead)」と表示されていることから、vsftpdサービスは現在起動していないことがわかります。vsftpdサービスを起動してみます。
01 | # systemctl start vsftpd |
02 | # systemctl status vsftpd |
03 | vsftpd.service - Vsftpd ftp daemon |
04 | Loaded: loaded (/usr/lib/systemd/system/vsftpd.service; disabled) |
05 | Active: active (running) since Sun 2014-09-07 00:39:03 JST; 3s ago |
06 | Process: 19159 ExecStart=/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf (code=exited, status=0/SUCCESS) |
07 | Main PID: 19160 (vsftpd) |
08 | CGroup: /system.slice/vsftpd.service |
09 | `-19160 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf |
11 | Sep 07 00:39:03 centos70n01.jpn.linux.hp.com systemd[1]: Starting Vsftpd ftp d... |
12 | Sep 07 00:39:03 centos70n01.jpn.linux.hp.com systemd[1]: Started Vsftpd ftp da... |
13 | Hint: Some lines were ellipsized, use -l to show in full. |
上記の「Active: active」及びプロセスが正常起動している旨の出力から、vsftpdサービスが正常に起動していることがわかります。vsftpdサービスを停止してみます。
2 | # systemctl status vsftpd |
OSが起動した時に、vsftpdサービスが自動的に起動するように設定します。
1 | # systemctl enable vsftpd |
2 | ln -s '/usr/lib/systemd/system/vsftpd.service' |
3 | '/etc/systemd/system/multi-user.target.wants/vsftpd.service' |
OSが起動した時に、vsftpdサービスが自動的に起動するように設定されているかを確認します。
1 | # systemctl -t service is-enabled vsftpd |
以下に、CentOS 6系のSysVinitのコマンドと、CentOS 7で採用されているsystemdのコマンドの対応関係を表にまとめておきますので、参考にして下さい。
図3:CentOS 6系のserviceコマンドやchkconfigコマンドとCentOS 7のsystemdの対応関係(クリックで拡大)
ユニットの依存関係
systemdが管理するユニットには、依存関係が存在します。ユニットの依存関係は、あるユニットを有効にするために、他のユニットも有効にしないとうまく稼働しない場合、それらの複数のユニット間に依存関係があると判断します。ユニットに依存関係がない場合、それらのユニットは、個別に同時並列的に起動されることになり、CentOS 7のOS起動の高速化に貢献します。ユニットの依存関係は、CentOS 7で定義されているターゲットの設定ファイルの中身を見ると理解が深まります。例えば、graphical.targetファイルの中身を確認します。
1 | # cd /usr/lib/systemd/system |
4 | Requires=multi-user.target |
6 | Wants=display-manager.service |
上記の「Requires=multi-user.target」は、graphical.targetを起動するためには、multi-user.targetが必要であるという依存関係を示しています。さらに、「Wants=display-manager.service」も依存関係を示しています。従来のランレベル5に相当するgraphical.targetは、従来のランレベル3に相当するmulti-user.targetに依存していることになります。同様にmulti-user.targetの中身も確認してみます。
上記のとおり、multi-user.targetは、basic.targetに依存していることがわかります。このbasic.targetは、ランレベルに依存しないで起動するサービスに相当します。さらにbasic.targetの中身を確認してみます。
4 | Wants=sockets.target timers.target paths.target slices.target |
上記より、basic.targetは、sysinit.target、sockets.target、timers.target、paths.target、そして、slices.targeに依存していることがわかります。sysinit.targetは、従来のCentOS 6におけるrc.sysinitの処理に相当するターゲットです。最後にsysinit.targetの中身を確認してみます。
3 | Wants=local-fs.target swap.target |
上記より、sysinit.targetは、local-fs.targetとswap.targetに依存していることがわかります。すなわち、sysinit.targetの処理を行うには、ファイルシステムのマウントとスワップ領域の有効化の処理が前提となっていることがわかります。
ユニットの起動順序
ユニットには、依存関係の他に、起動順序の概念が存在します。例を見ながら解説します。今度は、サービスについての起動順序を確認します。例として、sshdサービスをあげます。sshdサービスの起動に関する設定ファイルは、/usr/lib/systemd/system/sshd.serviceです。中身を確認します。
6 | After=syslog.target network.target auditd.service |
上記設定ファイルに「After=syslog.target network.target auditd.service」と記述されています。これは、syslog.target、network.target、auditd.serviceの後にsshd.serviceが起動することを意味します。ここで、network.targetが指定されていることに注目します。起動順序において、ターゲットが指定されている場合は、そのターゲットの前後の起動順序において、一つ前のサービスの起動が完了してから、次のサービスの起動が開始することを保証することができます。上記の場合は、network.targetの後に、sshd.serviceが起動しますが、newtork.targetの前に起動するサービスを確認してみます。
02 | /usr/lib/systemd/system |
04 | # grep Before=network.target ./*.service |
05 | ./NetworkManager-wait-online.service:Before=network.target network-online.target |
06 | ./NetworkManager.service:Before=network.target network.service |
07 | ./arp-ethers.service:Before=network.target |
08 | ./firewalld.service:Before=network.target |
09 | ./netcf-transaction.service:Before=network.target |
10 | ./wpa_supplicant.service:Before=network.target |
上記では、サービスの設定ファイルに、「Before=network.target」を指定しているものを抽出しています。上記のNetworkManager.serviceは、「Before=network.target」が指定されていますので、network.targetの前に起動することになります。すなわち、先述のsshd.serviceとNetworkManager.serviceの間には、network.targetが介在しており、NetworkManager.serviceの構成が終了してから、sshd.serviceが起動することが保証されることになります。続いて、上記のauditd.serviceの起動順序も確認してみます。
8 | Before=sysinit.target shutdown.target |
上記より、auditd.serviceは、loca-fs.targetの後に起動する順序を持っていることがわかります。また、「Before=sysinit.target shutdown.target」の設定により、audit.serviceがsysinit.targetと shutdown.targetの前に起動することがわかります。このように、systemdは、依存関係や起動順序を設定ファイルに記述することで実現していることがわかります。CentOS 7では、systemdのデフォルトの設定ファイル群が、/usr/lib/systemd/system配下に格納されています。もし独自のルールを設定したい場合は、/etc/systemd/systemディレクトリ配下に設定ファイルとして記述します。/usr/lib/systemd/systemディレクトリ以下と/etc/systemd/systemディレクトリ以下に同じファイル名で存在する場合は、/etc/systemd/systemディレクトリ配下の設定ファイルが優先されます。実行時に一時的に作成されるようなランタイムデータは、/run/systemdディレクトリ配下に生成されます。
ドロップインによるユニットのカスタマイズ
systemdには、サービスの起動・停止の制御や依存関係、起動順序の制御だけでなく、プロセス管理の挙動に関するパラメータを詳細に設定することが可能となっています。例えば、Apache Webサーバーで有名なhttpdサービスのパラメータは以下で確認することが可能です。
1 | # systemctl show --all httpd |
様々なパラメータが設定可能であることがわかります。しかし、特定のパラメータについて明示的に設定を行う場合には、ユーザー独自の設定ファイルに特定のパラメータのみを記述しておくとアプリケーションやサービスの運用管理が煩雑化しにくくなります。ここでは、httpdサービスにパラメータを個別に指定して管理する方法を紹介します。まず、systemdでは、ユーザー独自のパラメータを指定するためのディレクトリを作成します。httpd.serviceの場合は、httpd.service.dという名前のディレクトリを/etc/systemd/systemディレクトリの下に作成します。
1 | # mkdir /etc/systemd/system/httpd.service.d/ |
次に、設定ファイルを作成します。今回は、10-httpd.confと言うファイル名にします。
1 | # cd /etc/systemd/system/httpd.service.d/ |
10-httpd.confファイルの先頭行に、[Service]を記述し、その下にパラメータを記述します。このパラメータは、man systemd.execやman systemd.serviceで確認することができます。今回は、下記3つを指定しました。
Restart=always | サービスの正常終了しかに関わらず、サービスを再起動 |
CPUAffinity=0 1 2 3 | 実行するプロセスのCPUアフィニティを設定(例はCPU0、1、2、3に固定) |
OOMScoreAdjust=-1000 | 「Out of Memory」発生時のプロセス制御(-1000でプロセスkillを無効) |
設定ファイルを記述したら、デーモンを再起動します。
1 | # systemctl daemon-reload |
httpdサービスの状態を確認します。すると下図のようになり、「Drop-In:」の行に、先程作成したディレクトリと設定ファイルが読み込まれていることが分かります。これはsystemdにおける「ドロップイン」と呼ばれており、ユーザー独自でパラメータを明示的に指定する場合に利用される仕組みです。
図4:systemdのドロップインが利用されている様子。作成した10-httpd.confファイルがロードされていることがわかる(クリックで拡大)
ドロップインを利用したパラメータ設定を行った後は必ず、systemctl daemon-reloadが必要になりますので、注意して下さい。
ロケール、キーボード設定、日付・時間・タイムゾーン設定
CentOS 7は、ロケール、キーボード設定、日付・時間・タイムゾーンなどの設定もCentOS 6系と大きく異なります。CentOS 7では、ロケール、キーボードを設定するlocalectlコマンド、日付・時間・タイムゾーンを設定するtimedatectlコマンドが用意されています。設定ファイルもCentOS 6系とは異なりますので注意して下さい。
ロケールの変更
システムのロケールの変更は、localectlコマンドで行います。現在のロケールの状態を確認します。
2 | System Locale: LANG=en_US.UTF-8 |
ロケールを日本語に設定し、変更されているかを確認します。
1 | # localectl set-locale LANG=ja_JP.utf8 |
3 | System Locale: LANG=ja_JP.utf8 |
ロケールの設定ファイルは、/etc/locale.confファイルになります。変更されているかどうかを確認します。
キーボード設定
キーボード設定も、localectlコマンドで行います。利用可能なキーマップを表示します。
01 | # localectl list-keymaps |
日本語のキーマップはjp106として利用可能です。 現在のキーボード設定を日本語106キーボードに設定します。
1 | # localectl set-keymap jp106 |
2 | [root@centos70n02 ~]# localectl |
3 | System Locale: LANG=ja_JP.utf8 |
7 | X11 Options: terminate:ctrl_alt_bksp |
キーマップの設定ファイルは、/etc/vconsole.confファイルになります。先述の設定が反映されているか確認してみます。
1 | # cat /etc/vconsole.conf |
日付、時刻、タイムゾーンの設定
CentOS 7では、日付、時刻の設定コマンドとして従来のdateコマンドやhwclockコマンドが存在しますが、新しくsystemdで制御されるtimedatectlコマンドが用意されています。timedatectlコマンドをオプション無しで実行すると、現在の日付、時刻、タイムゾーン、NTPの同期設定の有無等を表示します。
2 | Local time: 金 2014-09-05 19:41:11 JST |
3 | Universal time: 金 2014-09-05 10:41:11 UTC |
4 | RTC time: 金 2014-09-05 10:41:11 |
5 | Timezone: Asia/Tokyo (JST, +0900) |
日付を設定する場合は、timedatectlコマンドにset-timeオプションを指定します。以下は、2014年9月6日に設定する例です。
01 | # timedatectl set-time 2014-09-06 |
03 | Local time: 土 2014-09-06 00:00:00 JST |
04 | Universal time: 金 2014-09-05 15:00:00 UTC |
05 | RTC time: 金 2014-09-05 15:00:01 |
06 | Timezone: Asia/Tokyo (JST, +0900) |
時刻を設定する場合も、timedatectlコマンドにset-timeオプションを指定します。以下は、19時51分00秒に設定する例です。
01 | # timedatectl set-time 19:51:00 |
03 | Local time: 金 2013-09-06 19:51:00 JST |
04 | Universal time: 金 2013-09-06 10:51:00 UTC |
05 | RTC time: 金 2013-09-06 10:51:00 |
06 | Timezone: Asia/Tokyo (JST, +0900) |
日付と時刻を同時に設定する場合は、以下のように設定します。
01 | # timedatectl set-time "2014-09-06 19:55:00" |
03 | Local time: 土 2014-09-06 19:55:01 JST |
04 | Universal time: 土 2014-09-06 10:55:01 UTC |
05 | RTC time: 土 2014-09-06 10:55:01 |
06 | Timezone: Asia/Tokyo (JST, +0900) |
タイムゾーンの表示は、timedatectlコマンドにlist-timezoneオプションを付与して実行します。
1 | # timedatectl list-timezones |
タイムゾーンを変更するには、timedatectlコマンドにset-timezoneオプションを付与します。以下では、タイムゾーンとしてAsia/Tokyoを設定する例です。
1 | # timedatectl set-timezone Asia/Tokyo |
以上で、ランレベル、サービスの制御、ログ管理、ロケール、キーボード設定、日付・時間・タイムゾーン設定を紹介しました。これらは、すべてsystemdで提供される機能です。systemdがCentOS 7において、幅広いコンポーネントに渡って制御を行っていることが理解できます。systemdだけでも一冊の本になるぐらいの膨大な情報量になりますが、まずは、CentOS 5やCentOS 6系で自分が理解していた管理手法と同様のことをCentOS 7のsystemdで実現することを目指してみて下さい。
この連載が書籍になりました! |
古賀 政純 著
価格:3,000円+税
発売日:2015年2月25日発売
ISBN:978-4-8443-3753-9
発行:インプレスジャパン
|
本書は、CentOS 7を取り巻く市場動向、CentOS 7が利用されるサーバーシステムの選定、CentOS 7の基礎、システム設計、OS管理やCentOS 7に対応したアプリケーションサーバーの構築手順などの勘所をご紹介します。連載では書ききれなかった本の内容、見どころが満載!
- セキュリティ管理
- チューニング
- 自動インストール
- Hadoop構築
- GlusterFS
- Ceph
 
|