9月14日(月)3、4コマ目

 今日、やったこと

systemd版「一人でやってみよう」解説


今日のホワイトボード

その１　ユニット定義ファイルの有無確認

ユニット定義ファイルは以下にある。

パス 特徴
/usr/lib/systemd/system/ユニット名

OSがあらかじめ用意してあるユニット。

基本的にこのファイルは変更しない。
/etc/systemd/system/ユニット名

デフォルトから変更する場合や新規作成時はここに作成。
図　その１　ユニット定義ファイルの有無確認


その２　ユニットが自動起動になっているか？

自動起動にすると、OS起動時にsystemdによってプロセスが起動される。

図　その２　ユニットは自動起動になっているか？


その３　ユニットは起動中？

プロセスは起動中か？

systemdはプロセス起動後もプロセスをチェックしている。

図　その３　ユニットは起動中？


その４　依存関係

起動順序と似ているが、依存関係によって起動するユニットが決定される。

依存関係はユニット定義ファイルの「Wants」、「Requires」で指定する。

図　ユニット間の依存関係


その５　起動順序

まさにユニットの起動順序。

起動順序のユニット定義ファイルで設定する。

項目は「After」、「Before」。

図　ユニットの起動順序


その６　ユニット新規作成

ユニットを新規作成するには、ユニット定義ファイルを作成する。

ユニット定義ファイルへのパスはその１を参照。

ユニット定義ファイルの中身は

  • 起動するコマンドの指定（ExecStart)
  • 起動順序（After、Before)
  • 依存関係（Wants、Requires)
  • ターゲットへの組み込み（WantedBy、RequiredBy)

はおさえておいてください。


その７、８はすっとばして


その９

自動起動させるには

　systemctl enable ユニット名

を実行する。

実行すると、ユニット定義ファイルのWantedByまたはRequiredByに指定したターゲットに組み込まれ、ターゲット起動時に一緒に起動される。

ターゲットに組み込まれると

/etc/systemd/system/ターゲット名.watns/ディレクトリに

ユニット定義ファイルへのリンクが作成される。

図　自動起動設定すると


その１０　ユニット起動・停止・再起動

特にコメントなし。

図　ユニット起動・停止・再起動


その１１～１３　ターゲット変更

ターゲットの変更自体は

　systemctl isolate ターゲット名

でできる。

おさえてほしいのは

  • 起動時にはsystemdが起動するターゲットはdefault.target
  • default.targetは実体はない、他ターゲットへのリンク
  • 利用していたLinuxはgraphical.targetへのリンク
  • graphical.targetはマルチユーザー＋GUI
  • graphical.targetはmulti-user.targetへ依存
  • multi-user.targetはさらに別ターゲットに依存、起動順序指定あり

結局、依存関係を辿っていくとOSのベーシックな機能であり、そこから順に各機能を立ち上げていく。このへんの流れをおさえておいてください。

図　OS起動とターゲットの関係

次回はテストです。

コメント

新しいコメントは書き込めません。

このブログの人気の投稿

6月22日(月)3、4コマ目

イメージ
今日、やったこと ファイルの所有者・所有グループ ファイルのアクセス権 setUIDビット、setGIDビット、stickyビット 今日のホワイトボード ファイル・ディレクトリのデフォルトの所有者 作成者が所有者、作成者のプライマリグループが所有グループ。 ファイルのデフォルトのアクセス権 OS自体のデフォルトのアクセス権(666)から作成者のumask値を引く。 ディレクトリのデフォルトのアクセス権 OS自体のデフォルトのアクセス権(777)から作成者のumask値を引く。 一般ユーザーでのパスワードが変更できるのはなぜ？ パスワードは/etc/shadowに保存されている。 このファイルのアクセス権は  - ---------    root root /etc/shadow 特権ユーザー(root)以外はなにもアクセスできない。 コマンドは実行したユーザーの権限で動くため、本来なら特権ユーザー以外は/etc/shadowに書き込むことはできない。 しかしながら、root以外のユーザーでの書き込むことができている。これはpasswdコマンドはsetUIDビットがONになっているから。 -r- s r-xr-x  root   root  /usr/bin/passwd setUIDビットがONになっているファイルは、実行したユーザーの権限ではなく、ファイルの所有者の権限で実行される。 setUIDビット、setGUIDビット ls -lで表示されるファイルのパーミッションに3ビットのエリアがあるイメージ。 ここにsetUIDやsetGID、stickyビットのON、OFFがコントロールされている。 setUID、setGIDの付与 〇setUID（+で付与） 所有者に付与するため、 u+s。 　chmod u+s ファイル名 〇setUID(数字で付与) 以下のsetuidのビットをONにするイメージ。 setuid setgid stickyビット 所有者 所有グループ ...
続きを読む

6月8日(月)1,2コマ目(B班)、3,4コマ目(A班)

イメージ
今日、やったこと ワイルドカード 正規表現 パイプ 今日のホワイトボード こんなファイル構成 ワイルドカード* ＊は「0文字以上の任意の文字列」という意味。 ただし、.で始まる隠しファイルは対象外。 *単体ではなく、 abc*・・・ファイル名がabcで始まる *cfg・・・ファイル名がcfgで終わる のように組み合わせて使うこともできる。 ワイルドカード[] []は「[]内のいずれかの文字」という意味。 ＊と組わせて使うことも可能。 パイプ パイプをつかうことで、コマンドAの結果をコマンドBで使って、さらのその結果をコマンドCで使ってのように、コマンドを連携して使うことができる。 意外とこれでやりたいことはほとんどできてしまう。 grepコマンド 検索対象の各行を検索条件にマッチするかチェックする、文字列検索コマンド。 検索条件に正規表現が使える。 正規表現 ワイルドカードと同じ記号を使っているため、ごっちゃになりやすい。 ワイルドカードの*と同意になるのは.*（厳密には違うが）。 そもそもワイルドカードは コマンド実行前にワイルドカードの展開が行われる 。 コマンドは展開後の引数を使って処理を行う。 ls *を実行すると、 lsコマンドが*にマッチするファイルを探すわけではない。 lsコマンド実行時には*はカレントディレクトリのファイル名に置き換わっている。 やってみよう「ワイルドカードと正規表現」 ファイル構成 おまけ grepコマンドの第2引数以降は検索対象ファイル名を指定。もちろん、ワイルドカードも使える。
続きを読む

9月28日(月)3、4コマ目

今日のテスト systemdに確認テストを行いました。 問１ Unit起動順に関する問題。 Unit起動順は以下の2項目があります。 項目 説明 before 指定ユニットの 前 に起動。 例　BEFORE=A B このユニットは ユニットA、Bの前に起動する 言い換えれば、ユニットA、Bはこのユニットのあとに起動する after 指定ユニットの 後 に起動。 例　AFTER=A B このユニットは ユニットA、Bの後に起動する 言い換えれば、ユニットA、Bはこのユニットのまえに起動する 問題はUnit定義ファイルから、Unit起動後に起動するUnitを調べる問題。よって、beforeで指定されたUnitが対象。 だが、beforeは未指定なので、答えはなし。 問２ ユニットhttpd.serviceが自動起動するか確認するためのコマンド。 systemctl is-enabled httpd.service 問３ ユニットfirewalld.serviceを自動起動するように設定するためのコマンド。 systemctl enable firewalld.service 問４ systemdでマシンをシャットダウン。 起動しているターゲットの変更を行うことで、GUI付きマルチユーザーモード(graphical.target)からCUIマルチユーザーモード(multi-user.target)やシングルユーザーモード(rescue.target)に変更することができる。 systemctl isolate poweroff.target 問５ ユニットdovecot.serviceに対して、 systemctl en...
続きを読む