20201208のLinuxに関する記事は10件です。

RPMとは

PRM Package Manager(RPM)は、RHEL(Red hat enterprice linux = red hatが有償販売しているlinux)やcentosで使用できるパッケージ管理システムのこと。
ソフトウェアのインストールやアンインストールといったパッケージ管理が行える。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

DNFの略称

centos8 で使われるdnfコマンド
dnfはDandified yumの略
だんでぃふぁいど

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Linux ネットワークの設定ファイル

【Linux ネットワークの設定ファイル】

・ホスト名を設定(Debian系)

# cat /etc/hostname
Debian

・ホスト名を設定(RedHat系)

 ネットワーク機能の有効/無効やデフォルトゲートウェイ等も設定可能

# cat /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=CentOS
GATEWAY=192.168.1.1

・IPアドレスとホスト名の対応付け

# cat /etc/hosts
112.78.124.10   example.com
192.168.1.100   FileServer

・名前解決やサービス名解決の問い合わせ順序の指定

# cat /etc/nsswitch.conf
hosts:   files dns
services:   files

※hosts: の行にDNSの指定がないと名前解決されない。

・ドメイン名やDNSサーバの指定

DNSクライアントホスト上で、どのDNSサービスに対して、問い合わせを行うかを定義するファイル

# cat /etc/resolv.conf
domain   ping-t.com
nameserver   192.168.1.1

domain行には、このホストが属するドメイン名
search行には、ドメイン名が省略された場合に補完するドメイン名
nameserver行には、参照先のDNSサーバのIPアドレス

※複数指定する場合は、1行ずつ表記する。

・サービス名とポート番号の対応付け

# cat /etc/services
telnet   23/tcp
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

GCEインスタンスにおいてCloud Shell操作のみでスナップショットからリストアさせるには

概要

運用しているサーバが急にクラッシュなどを引き起こし、復旧させたい。
前提条件として、定期スナップショットを取得していること。

目標

  • インスタンス自体は変更せず、スナップショットから永続ディスクを作成し、インスタンスへディスクを差し替え、復旧させる
  • Cloud Shellからの操作で行う

環境

  • google compute engine(GCE)
  • CentOS 7
  • Cloud Shell

手順

1. Cloud Shellの実行

GCPのCloud ConsoleからCloud Shellを起動するには、Console画面右上の [Cloud Shell をアクティブにする] ボタンを使用します。*画像の赤丸の箇所
スクリーンショット 2020-12-08 15.30.55(2).jpg

2. インスタンスの停止

ディスクの差し替えを行うので、インスタンスは停止する必要があります。

$ gcloud compute instances stop [INSTANCE_NAMES]

3. スナップショットから新しいディスクに復元

復元したいスナップショットを確認します。

$ gcloud compute snapshots list

#発行例
NAME        DISK_SIZE_GB  SRC_DISK                      STATUS
snapshot-1  30            us-west1-a/disks/server01     READY

復元したいスナップショットが確認できたら、スナップショットから永続ディスクを作成します。

$ gcloud compute disks create [DISK_NAME] \
    --size [DISK_SIZE] \
    --source-snapshot [SNAPSHOT_NAME] \
    --type [DISK_TYPE]

#発行例
$ gcloud compute disks create server02 \
    --size 30 \
    --source-snapshot snapshot-1 \
    --type pd-standard

4. インスタンスから既存のディスクをデタッチする

以下のコマンドよりインスタンスから既存ディスクをデタッチします。

*公式リファレンスでは、ディスクをアンマウントせずにディスクを取り外すと、I / O操作が不完全になりデータが破損する可能性がありますと記述されていますので、注意が必要。
今回はクラッシュを引き起こしサーバにSSH接続すらできない状態を想定しているため、無視します(笑)

$ gcloud compute instances detach-disk [INSTANCE_NAME] \
    --disk [DISK_NAME]

5. 新しいディスクを既存のインスタンスへアタッチする

以下のコマンドより作成したディスクをインスタンスにアタッチします。

$ gcloud compute instances attach-disk [INSTANCE_NAME] \
    --disk [DISK_NAME]

6. インスタンスの起動

以下のコマンドよりインスタンスを起動し、完了です。

$ gcloud compute instances start [INSTANCE_NAMES]
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Linuxでファイルを実行したら「No such file or directory」と言われた時には?

What's?

Linux上で、ファイルを実行した時に「No such file or directory」と言われることがあります。

OSとファイルの想定しているアーキテクチャ(32bit or 64bit)が異なることが理由だったりするのですが、軽く見てみましょう。

環境

CentOS 8で確認します。

$ cat /etc/redhat-release 
CentOS Linux release 8.3.2011


$ uname -srvmpio
Linux 4.18.0-240.1.1.el8_3.x86_64 #1 SMP Thu Nov 19 17:20:08 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Liberica OpenJDKで確認

Liberica OpenJDKには、64bit用のものも32bit用のものもあるので、こちらで例を示しましょう。

Liberica OpenJDK Download Center

OpenJDK 11の64bit版をダウンロードして実行。

$ curl -sL -o - https://download.bell-sw.com/java/11.0.9.1+1/bellsoft-jdk11.0.9.1+1-linux-amd64.tar.gz | \
  tar zxvf -

$ ll jdk-11.0.9.1/bin/java
-rwxrwxr-x. 1 xxxxx xxxxx 13080 Nov  2 19:33 jdk-11.0.9.1/bin/java

$ jdk-11.0.9.1/bin/java --version
openjdk 11.0.9.1 2020-11-04 LTS
OpenJDK Runtime Environment (build 11.0.9.1+1-LTS)
OpenJDK 64-Bit Server VM (build 11.0.9.1+1-LTS, mixed mode)

こちらは、問題なく実行できます。

続いて、32bit版をダウンロードして同じことをしてみましょう。

※展開されるディレクトリ名は、64bit版と同じなので注意してください

$ curl -sL -o - https://download.bell-sw.com/java/11.0.9.1+1/bellsoft-jdk11.0.9.1+1-linux-i586.tar.gz | \
  tar zxvf -

$ ll jdk-11.0.9.1/bin/java
-rwxrwxr-x. 1 xxxxx xxxxx 7484 Nov  2 19:49 jdk-11.0.9.1/bin/java

$ jdk-11.0.9.1/bin/java --version
-bash: jdk-11.0.9.1/bin/java: No such file or directory

32bit版の場合は「No such file or directory」と言われて実行できません。

どうやって気づけばいい?

これ、けっこう不可解なんですけど「そんなファイルないよ」と言われている割には、実はファイル自体にはアクセスできています。

lsで見れていましたからね。

$ ll jdk-11.0.9.1/bin/java
-rwxrwxr-x. 1 xxxxx xxxxx 7484 Nov  2 19:49 jdk-11.0.9.1/bin/java

実際のところは、「実行できない」が正解です。

この状態は知らないとけっこう難しい気がしますが、fileコマンドの実行結果がヒントになります。

$ file jdk-11.0.9.1/bin/java
jdk-11.0.9.1/bin/java: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=8cd726d22f9eaf779fdd9aa466608bf20e61c63f, not stripped

ELF 32-bit LSB executableと言われているので、32bit版の実行ファイルです。

一方で64bit版は、こういう表示になります。

$ file jdk-11.0.9.1/bin/java
jdk-11.0.9.1/bin/java: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=ee4e2e08b65cabbedc10dfb7bca1bd52f9454e01, not stripped

というわけで、「あれ?」と思ったファイルには、たまにfileコマンドで見てみてもいいのではないでしょうか。

最後に、共有ライブラリへの依存を見るlddで確認してみましょう。

32bit版。実行可能ファイルじゃないよ、と言われます。

$ ldd jdk-11.0.9.1/bin/java
    not a dynamic executable

64bit版はこんな感じになります。

$ ldd jdk-11.0.9.1/bin/java
    linux-vdso.so.1 (0x00007ffc9c9f3000)
    libz.so.1 => /lib64/libz.so.1 (0x00007f7ef36ae000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7ef348e000)
    libjli.so => /home/xxxxx/jdk-11.0.9.1/bin/../lib/jli/libjli.so (0x00007f7ef327d000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f7ef3079000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f7ef2cb6000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f7ef3ac8000)

ちなみに、32bit版を32bit OSで実行するとこんな感じになります。

$ ldd jdk-11.0.9.1/bin/java
    linux-gate.so.1 =>  (0xb775d000)
    libz.so.1 => /lib/libz.so.1 (0xb773f000)
    libpthread.so.0 => /lib/libpthread.so.0 (0xb7724000)
    libjli.so => /home/xxxxx/jdk-11.0.9.1/bin/../lib/jli/libjli.so (0xb7712000)
    libdl.so.2 => /lib/libdl.so.2 (0xb770d000)
    libc.so.6 => /lib/libc.so.6 (0xb7541000)
    /lib/ld-linux.so.2 (0xb775e000)

OSは、こちらで確認。

$ cat /etc/redhat-release 
CentOS Linux release 7.9.2009 (AltArch)


$ uname -srvmpio
Linux 3.10.0-1160.6.1.el7.centos.plus.i686 #1 SMP Tue Nov 17 14:19:51 UTC 2020 i686 i686 i386 GNU/Linux
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

個人的によく使うeximコマンド

eximで個人的によく使うコマンドを書き留めておきます
なにかの参考になれば

  • eximのバージョン表示
$ exim -bV
  • メールキューの一覧を表示
$ exim -bp
  • キューIDの一覧
$ exim -bp | awk '{print $3}'
  • キューIDを指定して本文の表示
$ exim -Mvb キューID
  • キューIDを指定してヘッダーの表示
$ exim -Mvh キューID
  • キューIDを指定してログの表示
$ exim -Mvl キューID
  • キューを指定して再配送
$ exim -M キューID
  • 全メール再配送
$ exim -qff
  • キューIDを指定してメール削除
$ exim -Mrm キューID
  • 特定の送信元アドレスのメールを全削除
$ exim -bp | grep "送信元アドレス" | awk '{print $3}' | xargs -I {} exim -Mrm {}
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Linux環境でのスクリプトは`#!/usr/bin/env`から始める

Linux環境である言語のスクリプトを実行する場合、
シバン(スクリプトの1行目)には以下のように記載した方がいいです。

#!/usr/bin/env (command)

具体的には、

  • #!/usr/bin/env ruby
  • #!/usr/bin/env python

といった風に使います。

そもそもenvコマンドとは

envコマンドとは、環境変数の値を一時的に設定 or 削除してコマンドを実行することができるコマンドです。

例えば、dateコマンドで比較してみると以下のようになります。

# 通常時(LANG=ja_JP.UTF-8)のコマンド

$ date
2020年 12月 8日 火曜日 08時54分06秒 JST


# LANG=Cに設定したコマンド

$ env LANG=C date
Tue Dec  8 08:53:42 JST 2020


# bashの場合は、頭のenvは省略できる

$ LANG=C date
Tue Dec  8 08:53:47 JST 2020


# 環境変数LANGを一時的に設定せずにdateを実行

$ env -u LANG date
Tue Dec  8 08:59:18 JST 2020


# 全ての環境変数を一時的に設定せずにdateを実行

$ env - date
Tue Dec  8 08:59:21 JST 2020

また、引数なしでenvと実行すると環境変数一覧が表示されます。
これは printenv コマンドと同様の出力結果になります。

スクリプトへの活用

シバンとは、Linux環境でスクリプトの1行目に記述する特殊な文字列のことであり、
そのスクリプトを実行するインタープリタを示します。

シバンを #!/usr/bin/env command としてenvコマンドを使用することで、
PATH環境変数の通っている場所からcommandのインタープリタが検索されます。

pythonスクリプトの場合を比較してみます。

  • #!/usr/bin/python と記載した場合のデメリット
    • pythonのインストールパスが #!/usr/local/bin/python だった場合にエラーとなる
    • virtualenvなどの仮想環境で使用されるpythonパスではないため、仮想環境にてスクリプトを実行できない
  • #!/usr/bin/env pythonと記載した場合のメリット
    • PATH環境変数にpythonコマンドが通っていれば使用できる
    • 汎用性・システム間の移植性が高い
    • virtualenvなどの仮想環境上でも使用できる(仮想環境起動時にPATHがうわがかれ)

最後に

シェルスクリプトを使い場合には、おまじないのように#!/bin/bashと記載すれば問題なさそうですが、
他のプログラミング言語を使用するときには、 #!/usr/bin/env command を記載した方が良さそうです。

Reference

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

nlコマンドの論理ページ

nlコマンドには論理ページ(Logical pages)という概念があります。しかし、テキストに行番号をつけるだけなら気にする必要はなく、普段からページを意識してnlを使うことはほとんどありません。この記事では非常に影が薄い「論理ページ」について説明します。

論理ページの使い方

論理ページを簡単に要約すると、nlが読み込んだデータは「ヘッダー」「ボディ」「フッター」から構成される「ページ」として解釈されるということです。この機能を使えば「一部の行だけに行番号をつける」ということが実現できます。もちろん「ページ」は連続してドキュメントのような大きなデータを構成することができます。その場合、行番号はページごとにリセットされます。

ページ内のそれぞれのセクションは、先頭に配置される\:\:\:(ヘッダー) \:\:(ボディ) \:(フッター)という3つの文字列を使って「区切り」を識別します。そして「ヘッダー」と「フッター」には行番号を振りません。区切り文字列が指定されないデータは、すべてのデータが単一のボディとして解釈されます。実際には「すべて単一のボディ」とみなすnlの使い方がほとんどでしょう。

機能としての存在感はイマイチな論理ページですが、各nlのマニュアルでは論理ページについて多くのテキストを割いて説明しています。しかしながら、なんとなく読み飛ばしてしまうことがほとんどだと思いますので、あらためて眺めてみましょう。どれもほぼ同等の説明がされていますが、特筆すべきことはcoreutilsのnlでは「セクションの区切りは空行に置き換えられる」と明記されている点です。また、busyboxのnlは論理ページをサポートしていません。

info nl (GNU coreutils)

   ‘nl’ decomposes its input into (logical) page sections; by default,
the line number is reset to 1 at each logical page section.  ‘nl’ treats
all of the input files as a single document; it does not reset line
numbers or logical pages between files.

   A logical page consists of three sections: header, body, and footer.
Any of the sections can be empty.  Each can be numbered in a different
style from the others.

   The beginnings of the sections of logical pages are indicated in the
input file by a line containing exactly one of these delimiter strings:

‘\:\:\:’
     start of header;
‘\:\:’
     start of body;
‘\:’
     start of footer.

   The two characters from which these strings are made can be changed
from ‘\’ and ‘:’ via options (see below), but the pattern and length of
each string cannot be changed.

   A section delimiter is replaced by an empty line on output.  Any text
that comes before the first section delimiter string in the input file
is considered to be part of a body section, so ‘nl’ treats a file that
contains no section delimiters as a single body section.

man nl (BSD)

     The nl utility treats the text it reads in terms of logical pages.  Unless
     specified otherwise, line numbering is reset at the start of each logical
     page.  A logical page consists of a header, a body and a footer section;
     empty sections are valid.  Different line numbering options are independently
     available for header, body and footer sections.

     The starts of logical page sections are signalled by input lines containing
     nothing but one of the following sequences of delimiter characters:

           Line      Start of
           \:\:\:    header
           \:\:      body
           \:        footer

     If the input does not contain any logical page section signalling directives,
     the text being read is assumed to consist of a single logical page body.

POSIX

The nl utility views the text it reads in terms of logical pages. Line numbering shall be reset at the start of each logical page. A logical page consists of a header, a body, and a footer section. Empty sections are valid. Different line numbering options are independently available for header, body, and footer (for example, no numbering of header and footer lines while numbering blank lines only in the body).

The starts of logical page sections shall be signaled by input lines containing nothing but the following delimiter characters:

Line Start of
\:\:\: Header
\:\: Body
\: Footer

Unless otherwise specified, nl shall assume the text being read is in a single logical page body.

論理ページを試す

ページの表示

最初の記事から使用しているデータ「utl-kita」を少し編集して、1ページ目が「東海道線」2ページ目が「宇都宮線・高崎線」として、ヘッダーとフッターを追記したデータ「utl-doc」を作って試してみましょう。

coreutils
$ cat utl-doc
\:\:\:
【東海道線(JT)】
\:\:
東京
新橋
品川
川崎
横浜
戸塚
大船
\:
小田原方面へ直通
\:\:\:
【宇都宮線・高崎線(JU)】
\:\:
東京
上野
尾久
赤羽
浦和
さいたま新都心
大宮
\:
宇都宮線: 宇都宮方面へ直通
高崎線: 高崎方面へ直通

$ nl utl-doc

       【東海道線(JT)】

     1  東京
     2  新橋
     3  品川
     4  川崎
     5  横浜
     6  戸塚
     7  大船

       小田原方面へ直通

       【宇都宮線・高崎線(JU)】

     1  東京
     2  上野
     3  尾久
     4  赤羽
     5  浦和
     6  さいたま新都心
     7  大宮

       宇都宮線: 宇都宮方面へ直通
       高崎線: 高崎方面へ直通

coreutilsのnlでは、マニュアルに記載の通りセクションの区切り文字が空行に置き換えられています。一方、BSD系のnlでは区切りは空行に変換されず削除されるようです。

BSD
$ nl utl-doc
        【東海道線(JT)】
     1  東京
     2  新橋
     3  品川
     4  川崎
     5  横浜
     6  戸塚
     7  大船
        小田原方面へ直通
        【宇都宮線・高崎線(JU)】
     1  東京
     2  上野
     3  尾久
     4  赤羽
     5  浦和
     6  さいたま新都心
     7  大宮
        宇都宮線: 宇都宮方面へ直通
        高崎線: 高崎方面へ直通

番号のリセット

もう少し簡単な利用例を検討してみましょう。先ほどの例を参考に、路線で区切ったデータ「utl-doc2」を作って試してみます。ボディの区切り文字列\:\:を使うことで、途中で番号をリセットすることができます。

$ cat utl-doc2 
東京
新橋
品川
川崎
横浜
戸塚
大船
\:\:
東京
上野
尾久
赤羽
浦和
さいたま新都心
大宮
$ nl utl-doc2 
     1  東京
     2  新橋
     3  品川
     4  川崎
     5  横浜
     6  戸塚
     7  大船

     1  東京
     2  上野
     3  尾久
     4  赤羽
     5  浦和
     6  さいたま新都心
     7  大宮

coreutilsのnlで区切り文字列から変換される空行

前回の記事では、nlは入力された空行に行番号は付加しないが、出力後は空行ではなくなることについても説明しました。それでは「区切り文字列から変換された空行」は「真に空行」なのでしょうか。検証してみたいと思います。このnlを重ねる方法を応用すると、nlを用いて空行かどうかを判別することができます。

coreutils
$ echo '\:' | nl

$ echo '\:' | nl | nl

$ echo '\:' | nl | nl | nl
     1         

この結果によると「区切り文字列から変換された空行」は「真に空行」と言えそうです。

このコマンドの仕組みを説明しておくと、1つ目のnlechoから入力される区切り文字列を「検証される空行」に変換します。そして、2つ目のnlが「検証される空行」に行番号を付加した場合、何らかの不可視な文字列が含まれているとみなすことができます。この2行目の結果では何も表示されないため、空行とみなされて処理されていることがわかります。3つ目のnlは「検証される空行」が空行でなかったときの出力例として対照のため実行しています。


  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【ログ出力設定】logrotate

実施環境:RHEL8

ログローテーションとは・・・ログファイルを放置するとログファイルサイズが巨大化していきます。それを防ぐために一定のルールで古いログを削除したり、新しいログで上書きすること。

ログローテーションのイメージ(あくまで一例)

database.logという名前のログファイルを出力するようシステム運用しているとします。

ローテーションのタイミング:毎日
世代数:2世代
ローテーション後のファイル名:database.logの後に日付を付与

ファイルは以下のように管理されるでしょう。


12/1 ログローテーション実行直前(この日はlogが10MB吐かれたとします)
database.log ←10MB

12/2 ログローテーション実行直前(この日はlogが11MB吐かれたとします)
database.log ←11MB
database.log-20201201 ←10MB ※もちろん1日目のログ内容

12/3 ログローテーション実行直前(この日はlogが12MB吐かれたとします)
database.log ←12MB
database.log-20201201 ←10MB
database.log-20201202 ←11MB

12/4 ログローテーション実行直前(この日はlogが9MB吐かれたとします)
database.log ←9MB
database.log-20201202 ←11MB ※保存世代数のため、12/1のログは削除される。
database.log-20201203 ←12MB


なんて便利なんだ!!!

ログローテートは大きく2種類あります。

①アプリケーションがログローテーションを管理する方式
②Linuxがログローテーションを管理する方式

この記事では②のLinuxのログローテーションでよく使われるlogrotateについて記載します。

ログローテーションを実行できるサービス:logrotate

logrotateがインストールされていない場合は、yumやdnfなどでインストールしてください。

rpm -qa logrotate ←確認
yum install logrotate

設定・確認すべきファイル

①/etc/logrotate.conf
②/etc/logrotate.d/<設定ファイル>

設定ファイルの記述例

cat /etc/logrotate.d/database

/var/log/database.log {
    missingok
    daily
    dateext
    rotate 2
    notifempty
    postrotate
        /bin/kill -HUP 'cat /path/to/pidfile/database.pid 2> /dev/null` 2>/dev/null || true
    endscript
}

設定値↓↓↓

項目名 意味
create ローテーションを行った後、代わりに空の新規ログファイルを作る
missingok 指定のログファイルがなくても処理続行
daily 毎日実行する
dateext ローテート後のファイル名に日付を付与
rotate 世代数を指定
notifempty ログファイルが空ならスキップ
postrotate~endscript 記述されたコマンドをログローテーション後に実行

さらにオプションを色々みたい方は以下がお勧めです。
https://hackers-high.com/linux/man-jp-logrotate/#sharedscripts

なぜ上記設定例でpostrotate処理にkill -HUPしたのか

https://masudak.hatenablog.jp/entry/20110914/1315999265
↑こちらが参考になります。
簡潔に言うと、ログファイルをローテーションしたときに新しいログファイルをアプリケーション(データベース)が開き直してくれない時とかに必要だったり。logrotateを使ってアプリ(DB)をローテーションしたい場合は、そのアプリのマニュアルを確認し、必要な処理がないか、確認してみてください。

ログローテーションの手動実行

コマンド:
logrotate -f /etc/logrotate.d/database
もしくは
logrotate -f /etc/logrotate.conf(logrotate.confで/etc/logrotate.dがincludeされていることを確認してください)

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

エラー"No space left on device"の対処(linuxのゴミ箱の空にしかた)

このエラーは容量不足が原因なので、ゴミ箱を空にして容量を減らすことで解決した。

ゴミ箱(trash)を見つける
[hoge@localhost ~]$ find /home/hoge/ -name “*trash*”

ファイルの削除
[hoge@localhost ~]$ rm -f /home/hoge/.local/share/Trash/files/*

Is a directoryと表示される場合は、-f-rfに変更。

参考: linuxのゴミ箱(trash)はどこにある

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む