テクノロジー LINUX RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?

RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?

バックグラウンドまたは起動時にサービスを管理する方法を知りたいですか?

起動時にプロセスを管理および開始するメカニズムが変更されました。 RHEL/CentOS 6.x までは、/etc/init.d/ にスクリプトを作成し、 chkconfig を使用して有効にしていましたが、 RHEL 7 では状況が異なります。

これは systemd に置き換えられ、Linux のメジャー バージョンでは多かれ少なかれデフォルトのプロセス マネージャーであるため、他の種類に精通したシステム管理者にとっては安心できるでしょう。この記事では、 systemd とは何か、切り替えの理由、そして systemd を使用してバックグラウンド プロセスをセットアップ、実行、管理する方法について説明します。

RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?
RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?

システム化とは何ですか?

Linux のすべてのプロセスは透過的に表示されるので、 systemd がどこに潜んでいるか見てみましょう。私のシステムでは次のような結果が得られます。

  ~$ ps -ef | grep systemd
root         1     0  0 Nov11 ?        00:01:02 /lib/systemd/systemd --system --deserialize 22
message+   768     1  0 Nov11 ?        00:05:46 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
root       805     1  0 Nov11 ?        00:10:22 /lib/systemd/systemd-logind
ankush    1132     1  0 Nov11 ?        00:00:00 /lib/systemd/systemd --user
ankush    1176  1132  0 Nov11 ?        00:04:50 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
ankush    9772 20029  0 21:11 pts/6    00:00:00 grep --color=auto systemd
systemd+ 17298     1  0 Nov19 ?        00:00:12 /lib/systemd/systemd-resolved
systemd+ 17303     1  0 Nov19 ?        00:00:00 /lib/systemd/systemd-timesyncd
root     17307     1  0 Nov19 ?        00:00:02 /lib/systemd/systemd-journald
root     18182     1  0 Nov19 ?        00:00:00 /lib/systemd/systemd-udevd 

きっとすぐに気づいたんだと思います。リストの最初のプロセスはユーザー root として起動され、pid は 1 です。

案の定、これはシステムの起動時に起動される最初のプロセスでした。 systemd に挨拶します。 🙂

したがって、非常に簡単に言うと、 systemd 、システム内の他のプロセスを起動、管理、終了する「マザー」プロセスであり、ログやファイルシステムのステータスなどに関する情報を提供します。

ただし、名前についてのメモ。名前は確かに systemd であり、System D などではありません。 「d」はデーモンを表します。デーモンは、バックグラウンドで動作 (潜伏?) し、どのターミナル セッションにも接続されない標準 Linux プロセスです。

RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?
RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?

RHEL が systemd に切り替えた理由は何ですか?

すでに説明したように、systemd はシステムおよびプロセス マネージャーであり、RHEL 7 ではよく知られたプログラム Upstart を置き換えます。なぜ RHEL はこの決定を下したのでしょうか?これには十分な理由があるので、簡単に見てみましょう。

並列サービスの初期化

SysV init プログラムとは異なり、 systemd はサービスを並行して起動できます。対照的に、 init プログラムはそれらを 1 つずつ起動します。モバイル デバイスにもマルチコア CPU が搭載されている時代において、並列初期化の欠如は大きな問題です。

動的(ホット)サービス管理

USB ドライブは、Ubuntu や同様のディストリビューションでは自動的に開くのに、以前の Fedora システムでは明示的にマウントする必要があることに気づいた場合、その理由は systemd にあります。ハードウェアのライブ変更を検出し、必要に応じてサービスを終了/起動できます。それは不必要だと主張する人もいますが、多くの人にとって、認知的負担を軽減するものは大歓迎です。

サービス開始の延期

systemd 、サービスの起動を実際に必要なときまで遅らせることができるため、起動時間を短縮します。簡単な例としては、ネットワーク ファイル システム関連のサービスがあります。ネットワークに接続されたディスクが利用できない場合、サービスを稼働させても意味がありません。

プロセス通信の高速化

systemd の並列機能はプロセス間通信にも引き継がれます。 systemd ソケットとシステム バスへの並列アクセスを提供できるため、通信リソースのプロセス待機時間を大幅に短縮できます。

自動再起動

サービスがクラッシュした場合、 systemd それを検出し、再起動を試みます。ほとんどの場合、より根本的な問題がない限り、アプリケーションが再び機能し始めるために必要なのは、単純な再起動だけです。

とにかく、 systemd システム管理者の作業を楽にしてくれます。

RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?
RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?

RHEL7 の systemd – システム管理者にとっての変更点?

systemd すべての機能を備えたものになるわけではないと感じているのなら、それは正しいことです。 RHEL sysadmin に不意を突かれる可能性のある重大な非互換性がいくつかあります。早速見てみましょう。

限定的なランレベルのサポート

systemd のランレベルの認識とサポートはかなり不十分です。すべてのランレベルがサポートされているわけではなく、一部のターゲットではサポートされていない場合もあります。このような場合、 systemd runlevel コマンドへの応答として「N」を返し、このターゲットに対応するランレベルがないことを示します。全体として、Red Hat は runlevel コマンドを使用しないように (!) アドバイスしています。

カスタムコマンドはありません

こっちは傷つくよ。 SysV の大きな利点の 1 つは、プロセスを管理するためのより優れた機能を提供するカスタム コマンドを定義できることです。 systemd ではそのようなオプションはなく、 start stop status restart などで立ち往生します。

家族限定で非インタラクティブ

systemd (もちろん) 起動したプロセスを追跡し、その PID を保存します。ただし、課題は、 systemd 起動していないプロセスを systemd が処理できないことです。さらに、ユーザーは systemd によって開始されたプロセスと対話することはできません。すべての出力は /dev/null に送られるため、出力をキャプチャするという期待は実質的になくなります。

文脈がありません

init サービスとは異なり、 systemd によって起動されるサービスは、システム内のユーザーから環境を継承しません。つまり、 PATH やその他のシステム変数などの情報は利用できず、すべての新しいプロセスは空のコンテキストで起動されます。

この制限のリストを見て泣きそうになったとしても、繰り返しますが、あなたは一人ではありません。 systemd Linux の世界で二極化する勢力であり、「systemd 最悪」でグーグル検索すると、たくさんの読み物が見つかります。 😉

ダウン時にサービスを自動的に開始するにはどうすればよいですか?

デプロイメントにおける非常に一般的な使用例を次に示します。長時間実行されるプロセスを持たない言語、つまり PHP でプログラムをデーモン化する必要があります。受信 WebSocket 接続を処理するための PHP スクリプトを作成し (結局のところ、チャット アプリを構築しました!)、そのスクリプトが /home/ankush/chat_server/index.php に配置されていると仮定しましょう。

WebSocket 接続はいつでもサーバーにアクセスできるため、このプロセスは常に稼働しており、受信接続を監視する必要があります。 WebSocket はステートフル接続であり、スクリプトが終了すると接続はリストになるため、ここでは従来の PHP ライフサイクルを使用できません。とにかく、WebSocket で十分です。 systemd を介してこのスクリプトをデーモン化する方法を見てみましょう。

すべての systemd サービスは /etc/systemd/system に存在するため、そこに WebSocket サーバー スクリプトを記述するファイルを作成しましょう。 root ユーザーとしてログインしていると仮定します。

 # vi /etc/systemd/system/chat_server.service 

そして次のものが必要になります。

  [Unit]
Description=Chat Server Service
After=network.target

[Service]
Type=simple
User=ankush
ExecStart=php /home/ankush/chat_server/index.php
Restart=on-abort


[Install]
WantedBy=multi-user.target 

ファイルを保存し、次のステップでは systemd デーモンをリロードします。

  # systemctl daemon-reload 

そして、作成したばかりのサービスを開始するには、次のようにします。

  # systemctl start chat_server 

エラーが表示されなければ、それで完了です。

ファイル内のさまざまなディレクティブが何を意味するのかも簡単に見てみましょう。

  • [Unit] 部分は、 systemd の新しいサービス ユニットを定義します。 systemd 用語では、すべてのサービスはサービス ユニットと呼ばれます。
  • After ディレクティブは (予想通り) ネットワーキング サービスが起動された後にのみこのサービスを起動するように systemd に指示します (そうでなければ、ソケット接続の下位レベルの処理は誰が行うのでしょうか?!)。
  • Type=simple 、このサービスがそれ自体をフォークしないことを systemd に伝えます。つまり、常に 1 つのインスタンスのみが実行されます。
  • User=ankush 、こ​​のサービスがユーザー「ankush」として実行されることを意味します。これを「root」に変更することもできますが、セキュリティの観点からはあまりお勧めできません。
  • ご覧のとおり、 ExecStart は実際に実行するコマンドです。
  • Restart=on-abort サービスが中止されたときにサービスを再起動する必要があることを意味します。 PHP では、長時間実行されるプロセスによってメモリがリークされ、最終的には爆発するため、これが必要になります。
  • WantedBy= ディレクティブは、このサービスがどのターゲット (グループを考える) に属しているかを systemd に伝えます。これにより、そのターゲット内にサービスを指すシンボリック リンクが作成されます。

一般に、RHEL 7 で systemd を使用してバックグラウンド プロセスを実行するには、これで十分です。

再起動ロジックの追加オプション

上の例では、 Restart=on-abort を構成しましたが、これが唯一のオプションではありません。他にもありますので、要件に基づいて選択してください。

  • 失敗時 – 終了コードまたはシグナルがクリーンでない場合に再起動されます。
  • 常に – クリーンまたはクリーンな信号がダウンしていることが判明したら再起動します
  • on-abnormal – 汚れた信号、ウォッチドッグ、またはタイムアウト
  • 成功時 – クリーンなシグナルまたは終了コードによって停止された場合のみ

起動時にサービスを開始するように構成する

スクリプトに満足し、動作することを確認したら、次に起動時にトリガーされるように設定します。

/etc/systemd/system に移動し、以下のenableコマンドを実行します(.serviceファイル名を自分のものに変更することを忘れないでください)

  # systemctl enable chat_server.service 

シンボリックリンクが作成されたことを確認するメッセージが表示されます。

  Created symlink from /etc/systemd/system/multi-user.target.wants/chat_server.service to /etc/systemd/system/chat_server.service. 

サーバーを再起動すると、起動時にサービスが開始されるのが確認できるはずです。

それは簡単でした!そうじゃない?

RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?
RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?

ヘルプ!私は Upstart に多額の投資をしています。 🙁

あなたが私を信頼していることは理解しています、あなたのケースは例外ではなく標準です。 RHEL は長い間 Upstart を使用してきたため、この切り替えはほとんど裏切られたように感じられます。でもまあ、制度は変わり続けるのですから、些細なことで口論するべきではありません。 Red Hat は、多くの人が古いバージョンに行き詰まっていることを認識しており、必ず参照する必要がある 移行ガイドを 作成しました。

これらすべてにおける救いの 1 つは、 systemd が SysV init スクリプトと互換性があることです。そのため、ほとんどの場合、ファイルを移動するだけで同じサービスを実行できるようになります。

Linux の管理とトラブルシューティングについて詳しく知りたいですか?この オンラインコース をチェックしてください。

RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?
RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?

「 RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?」についてわかりやすく解説!絶対に観るべきベスト2動画

RHEL または CentOS 上の Systemctl を使用して起動時に開始するサービスを有効または無効にする
Packagekit | How to enable/disable automatic updates in RHEL/CentOS 7 | Linux tutorial for beginners

バックグラウンドまたは起動時にサービスを管理する方法を知りたいですか?

起動時にプロセスを管理および開始するメカニズムが変更されました。 RHEL/CentOS 6.x までは、/etc/init.d/ にスクリプトを作成し、 chkconfig を使用して有効にしていましたが、 RHEL 7 では状況が異なります。

これは systemd に置き換えられ、Linux のメジャー バージョンでは多かれ少なかれデフォルトのプロセス マネージャーであるため、他の種類に精通したシステム管理者にとっては安心できるでしょう。この記事では、 systemd とは何か、切り替えの理由、そして systemd を使用してバックグラウンド プロセスをセットアップ、実行、管理する方法について説明します。

RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?
RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?

システム化とは何ですか?

Linux のすべてのプロセスは透過的に表示されるので、 systemd がどこに潜んでいるか見てみましょう。私のシステムでは次のような結果が得られます。

  ~$ ps -ef | grep systemd
root         1     0  0 Nov11 ?        00:01:02 /lib/systemd/systemd --system --deserialize 22
message+   768     1  0 Nov11 ?        00:05:46 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
root       805     1  0 Nov11 ?        00:10:22 /lib/systemd/systemd-logind
ankush    1132     1  0 Nov11 ?        00:00:00 /lib/systemd/systemd --user
ankush    1176  1132  0 Nov11 ?        00:04:50 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
ankush    9772 20029  0 21:11 pts/6    00:00:00 grep --color=auto systemd
systemd+ 17298     1  0 Nov19 ?        00:00:12 /lib/systemd/systemd-resolved
systemd+ 17303     1  0 Nov19 ?        00:00:00 /lib/systemd/systemd-timesyncd
root     17307     1  0 Nov19 ?        00:00:02 /lib/systemd/systemd-journald
root     18182     1  0 Nov19 ?        00:00:00 /lib/systemd/systemd-udevd 

きっとすぐに気づいたんだと思います。リストの最初のプロセスはユーザー root として起動され、pid は 1 です。

案の定、これはシステムの起動時に起動される最初のプロセスでした。 systemd に挨拶します。 🙂

したがって、非常に簡単に言うと、 systemd 、システム内の他のプロセスを起動、管理、終了する「マザー」プロセスであり、ログやファイルシステムのステータスなどに関する情報を提供します。

ただし、名前についてのメモ。名前は確かに systemd であり、System D などではありません。 「d」はデーモンを表します。デーモンは、バックグラウンドで動作 (潜伏?) し、どのターミナル セッションにも接続されない標準 Linux プロセスです。

RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?
RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?

RHEL が systemd に切り替えた理由は何ですか?

すでに説明したように、systemd はシステムおよびプロセス マネージャーであり、RHEL 7 ではよく知られたプログラム Upstart を置き換えます。なぜ RHEL はこの決定を下したのでしょうか?これには十分な理由があるので、簡単に見てみましょう。

並列サービスの初期化

SysV init プログラムとは異なり、 systemd はサービスを並行して起動できます。対照的に、 init プログラムはそれらを 1 つずつ起動します。モバイル デバイスにもマルチコア CPU が搭載されている時代において、並列初期化の欠如は大きな問題です。

動的(ホット)サービス管理

USB ドライブは、Ubuntu や同様のディストリビューションでは自動的に開くのに、以前の Fedora システムでは明示的にマウントする必要があることに気づいた場合、その理由は systemd にあります。ハードウェアのライブ変更を検出し、必要に応じてサービスを終了/起動できます。それは不必要だと主張する人もいますが、多くの人にとって、認知的負担を軽減するものは大歓迎です。

サービス開始の延期

systemd 、サービスの起動を実際に必要なときまで遅らせることができるため、起動時間を短縮します。簡単な例としては、ネットワーク ファイル システム関連のサービスがあります。ネットワークに接続されたディスクが利用できない場合、サービスを稼働させても意味がありません。

プロセス通信の高速化

systemd の並列機能はプロセス間通信にも引き継がれます。 systemd ソケットとシステム バスへの並列アクセスを提供できるため、通信リソースのプロセス待機時間を大幅に短縮できます。

自動再起動

サービスがクラッシュした場合、 systemd それを検出し、再起動を試みます。ほとんどの場合、より根本的な問題がない限り、アプリケーションが再び機能し始めるために必要なのは、単純な再起動だけです。

とにかく、 systemd システム管理者の作業を楽にしてくれます。

RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?
RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?

RHEL7 の systemd – システム管理者にとっての変更点?

systemd すべての機能を備えたものになるわけではないと感じているのなら、それは正しいことです。 RHEL sysadmin に不意を突かれる可能性のある重大な非互換性がいくつかあります。早速見てみましょう。

限定的なランレベルのサポート

systemd のランレベルの認識とサポートはかなり不十分です。すべてのランレベルがサポートされているわけではなく、一部のターゲットではサポートされていない場合もあります。このような場合、 systemd runlevel コマンドへの応答として「N」を返し、このターゲットに対応するランレベルがないことを示します。全体として、Red Hat は runlevel コマンドを使用しないように (!) アドバイスしています。

カスタムコマンドはありません

こっちは傷つくよ。 SysV の大きな利点の 1 つは、プロセスを管理するためのより優れた機能を提供するカスタム コマンドを定義できることです。 systemd ではそのようなオプションはなく、 start stop status restart などで立ち往生します。

家族限定で非インタラクティブ

systemd (もちろん) 起動したプロセスを追跡し、その PID を保存します。ただし、課題は、 systemd 起動していないプロセスを systemd が処理できないことです。さらに、ユーザーは systemd によって開始されたプロセスと対話することはできません。すべての出力は /dev/null に送られるため、出力をキャプチャするという期待は実質的になくなります。

文脈がありません

init サービスとは異なり、 systemd によって起動されるサービスは、システム内のユーザーから環境を継承しません。つまり、 PATH やその他のシステム変数などの情報は利用できず、すべての新しいプロセスは空のコンテキストで起動されます。

この制限のリストを見て泣きそうになったとしても、繰り返しますが、あなたは一人ではありません。 systemd Linux の世界で二極化する勢力であり、「systemd 最悪」でグーグル検索すると、たくさんの読み物が見つかります。 😉

ダウン時にサービスを自動的に開始するにはどうすればよいですか?

デプロイメントにおける非常に一般的な使用例を次に示します。長時間実行されるプロセスを持たない言語、つまり PHP でプログラムをデーモン化する必要があります。受信 WebSocket 接続を処理するための PHP スクリプトを作成し (結局のところ、チャット アプリを構築しました!)、そのスクリプトが /home/ankush/chat_server/index.php に配置されていると仮定しましょう。

WebSocket 接続はいつでもサーバーにアクセスできるため、このプロセスは常に稼働しており、受信接続を監視する必要があります。 WebSocket はステートフル接続であり、スクリプトが終了すると接続はリストになるため、ここでは従来の PHP ライフサイクルを使用できません。とにかく、WebSocket で十分です。 systemd を介してこのスクリプトをデーモン化する方法を見てみましょう。

すべての systemd サービスは /etc/systemd/system に存在するため、そこに WebSocket サーバー スクリプトを記述するファイルを作成しましょう。 root ユーザーとしてログインしていると仮定します。

 # vi /etc/systemd/system/chat_server.service 

そして次のものが必要になります。

  [Unit]
Description=Chat Server Service
After=network.target

[Service]
Type=simple
User=ankush
ExecStart=php /home/ankush/chat_server/index.php
Restart=on-abort


[Install]
WantedBy=multi-user.target 

ファイルを保存し、次のステップでは systemd デーモンをリロードします。

  # systemctl daemon-reload 

そして、作成したばかりのサービスを開始するには、次のようにします。

  # systemctl start chat_server 

エラーが表示されなければ、それで完了です。

ファイル内のさまざまなディレクティブが何を意味するのかも簡単に見てみましょう。

  • [Unit] 部分は、 systemd の新しいサービス ユニットを定義します。 systemd 用語では、すべてのサービスはサービス ユニットと呼ばれます。
  • After ディレクティブは (予想通り) ネットワーキング サービスが起動された後にのみこのサービスを起動するように systemd に指示します (そうでなければ、ソケット接続の下位レベルの処理は誰が行うのでしょうか?!)。
  • Type=simple 、このサービスがそれ自体をフォークしないことを systemd に伝えます。つまり、常に 1 つのインスタンスのみが実行されます。
  • User=ankush 、こ​​のサービスがユーザー「ankush」として実行されることを意味します。これを「root」に変更することもできますが、セキュリティの観点からはあまりお勧めできません。
  • ご覧のとおり、 ExecStart は実際に実行するコマンドです。
  • Restart=on-abort サービスが中止されたときにサービスを再起動する必要があることを意味します。 PHP では、長時間実行されるプロセスによってメモリがリークされ、最終的には爆発するため、これが必要になります。
  • WantedBy= ディレクティブは、このサービスがどのターゲット (グループを考える) に属しているかを systemd に伝えます。これにより、そのターゲット内にサービスを指すシンボリック リンクが作成されます。

一般に、RHEL 7 で systemd を使用してバックグラウンド プロセスを実行するには、これで十分です。

再起動ロジックの追加オプション

上の例では、 Restart=on-abort を構成しましたが、これが唯一のオプションではありません。他にもありますので、要件に基づいて選択してください。

  • 失敗時 – 終了コードまたはシグナルがクリーンでない場合に再起動されます。
  • 常に – クリーンまたはクリーンな信号がダウンしていることが判明したら再起動します
  • on-abnormal – 汚れた信号、ウォッチドッグ、またはタイムアウト
  • 成功時 – クリーンなシグナルまたは終了コードによって停止された場合のみ

起動時にサービスを開始するように構成する

スクリプトに満足し、動作することを確認したら、次に起動時にトリガーされるように設定します。

/etc/systemd/system に移動し、以下のenableコマンドを実行します(.serviceファイル名を自分のものに変更することを忘れないでください)

  # systemctl enable chat_server.service 

シンボリックリンクが作成されたことを確認するメッセージが表示されます。

  Created symlink from /etc/systemd/system/multi-user.target.wants/chat_server.service to /etc/systemd/system/chat_server.service. 

サーバーを再起動すると、起動時にサービスが開始されるのが確認できるはずです。

それは簡単でした!そうじゃない?

RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?
RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?

ヘルプ!私は Upstart に多額の投資をしています。 🙁

あなたが私を信頼していることは理解しています、あなたのケースは例外ではなく標準です。 RHEL は長い間 Upstart を使用してきたため、この切り替えはほとんど裏切られたように感じられます。でもまあ、制度は変わり続けるのですから、些細なことで口論するべきではありません。 Red Hat は、多くの人が古いバージョンに行き詰まっていることを認識しており、必ず参照する必要がある 移行ガイドを 作成しました。

これらすべてにおける救いの 1 つは、 systemd が SysV init スクリプトと互換性があることです。そのため、ほとんどの場合、ファイルを移動するだけで同じサービスを実行できるようになります。

Linux の管理とトラブルシューティングについて詳しく知りたいですか?この オンラインコース をチェックしてください。

RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?
RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?

「 RHEL/CentOS 7 で起動時にサービスを自動開始するにはどうすればよいですか?」についてわかりやすく解説!絶対に観るべきベスト2動画

RHEL または CentOS 上の Systemctl を使用して起動時に開始するサービスを有効または無効にする
Packagekit | How to enable/disable automatic updates in RHEL/CentOS 7 | Linux tutorial for beginners