【Docker 20.10.17】起動済みのコンテナのIPアドレスを変更する方法について

Dockerホストは、CentOS7を使用している。

　次のコマンドで、コンテナを起動した。

# docker run -dt --shm-size=256m --init --net mynetwork --ip 192.168.32.193 --dns 8.8.8.8 --name mycontainer image_centos7_20220812 /bin/bash

これによりコンテナは、mynetworkというDockerネットワークに属して、192.168.32.193というIPアドレスを持つことになる。

　ところが、後からIPアドレスを変更する必要が生じたとする。

それには次のようにすればよい。このとき、コンテナは起動中でもIPアドレスを変更できた。

# docker network disconnect mynetwork mycontainer

# docker network connect --ip 192.168.32.194 mynetwork mycontainer

いったん、ネットワーク接続を解除してから、新しいIPアドレスを指定してネットワーク接続を行うことでコンテナのIPアドレスを再セットできた。

＜参考＞

・How to change the IP address of a docker after creating it?

< https://stackoverflow.com/questions/48088832/how-to-change-the-ip-address-of-a-docker-after-creating-it > 2022年8月13日

【Linux CentOS 7】OpenLDAPのためにWEBベースクライアントphpLDAPAdminを導入する【phpLDAPAdmin 1.2.5】

　次のページのように、CentOS 7（特権動作Dockerコンテナ）にソースからOpenLDAP(2.5.12)をインストールし、さらに初期設定を済ませた。

【Docker Linux CentOS 7】ソースから導入したOpenLDAP(2.5.12)の初期設定【OpenLDAP 2.5.12】

https://akira-arets.blogspot.com/2022/07/linux-centos7-initialize-openldap2.5.12.html

　この環境において、phpLDAPAminというWEBベースのLDAPクライアントソフトウェアをインストールし、初期設定を行う。

■phpLDAPAdminのインストール

◯　インストール

・リポジトリの追加

# yum install epel-release

Installed:

  epel-release.noarch 0:7-11                                                    

Complete!

・phpldapadminパッケージのインストール

# yum install phpldapadmin

Installed:

  phpldapadmin.noarch 0:1.2.5-1.el7

Dependency Installed:

  apr.x86_64 0:1.4.8-7.el7              apr-util.x86_64 0:1.5.2-6.el7               caddy.x86_64 0:1.0.3-1.el7               centos-logos.noarch 0:70.0.6-3.el7.centos 

  httpd.x86_64 0:2.4.6-97.el7.centos.5  httpd-tools.x86_64 0:2.4.6-97.el7.centos.5  libedit.x86_64 0:3.0-12.20121213cvs.el7  libzip.x86_64 0:0.10.1-8.el7              

  mailcap.noarch 0:2.1.41-2.el7         php.x86_64 0:5.4.16-48.el7                  php-cli.x86_64 0:5.4.16-48.el7           php-common.x86_64 0:5.4.16-48.el7         

  php-ldap.x86_64 0:5.4.16-48.el7      

Complete!

◯　初期設定

# vi /etc/httpd/conf.d/phpldapadmin.conf

#

#  Web-based tool for managing LDAP servers

#

Alias /phpldapadmin /usr/share/phpldapadmin/htdocs

Alias /ldapadmin /usr/share/phpldapadmin/htdocs

<Directory /usr/share/phpldapadmin/htdocs>

  <IfModule mod_authz_core.c>

    # Apache 2.4

    #Require local

    Require all granted

  </IfModule>

  <IfModule !mod_authz_core.c>

    # Apache 2.2

    Order Deny,Allow

    Deny from all

    Allow from 127.0.0.1

    Allow from ::1

  </IfModule>

</Directory>

◯　接続テスト

・httpdを起動

# systemctl restart httpd

・ブラウザからマシンのアドレスにアクセスする。

http://IPアドレス/ldapadmin/

■phpLDAPAdminの設定と動作テスト

◯ phpLDAPadminがOpenLDAPサーバーに接続できるようにするための設定

・オリジナル設定ファイルのバックアップ

# cp /etc/phpldapadmin/config.php /etc/phpldapadmin/config.php.org

・設定ファイルの編集

# vi /etc/phpldapadmin/config.php

次の各項目を探してそれぞれ次のように編集を行う。

viのコマンド「:set number」で行番号が表示される。（行番号を消す場合は、:set nonumber）

291行目付近

(1)　管理対象するLDAPサーバーの名称

/* A convenient name that will appear in the tree viewer and throughout

   phpLDAPadmin to identify this LDAP server to users. */

// $servers->setValue('server','name','Local LDAP Server');

$servers->setValue('server','name','Local LDAP Server 1');

298行目付近

(2)　管理対象するLDAPサーバーのIPアドレス（phpLDAPAdminと同じホストなら127.0.01）

/* Examples:

   'ldap.example.com',

   'ldaps://ldap.example.com/',

   'ldapi://%2fusr%local%2fvar%2frun%2fldapi'

           (Unix socket at /usr/local/var/run/ldap) */

// $servers->setValue('server','host','127.0.0.1');

$servers->setValue('server','host','127.0.0.1');

301行目付近

(3)　管理対象するLDAPサーバーのTCPポート

/* The port your LDAP server listens on (no quotes). 389 is standard. */

// $servers->setValue('server','port',389);

$servers->setValue('server','port',389);

305行目付近

(4)　管理対象するLDAPサーバーのベースdn（ここで指定したou以下を管理対象とする）

/* Array of base DNs of your LDAP server. Leave this blank to have phpLDAPadmin

   auto-detect it for you. */

// $servers->setValue('server','base',array(''));

$servers->setValue('server','base',array('dc=example,dc=co,dc=jp'));

◯　動作テスト

・OpenLDAPサーバーの起動

# systemctl start slapd

・httpdを起動

# systemctl restart httpd

・ブラウザからマシンのアドレスにアクセスする。

http://IPアドレス/ldapadmin/

左欄のサーバー名の下にある「login」をクリックする。

すると、次のように「Authenticate to server Local LDAP Server 1」というダイアログが現れる。

ダイアログの「Anonymous」にチックを入れて、「Authenticate」ボタンをクリックする。

このとき、OpenLDAPサーバーが起動していなければ、次のエラーが出て接続できない。

Unable to connect to LDAP server Local LDAP Server 1

Error: Can't contact LDAP server (-1) for anon

error Failed to Authenticate to server

Invalid Username or Password.

うまく、phpLDAPAdminがOpenLDAPサーバーに接続できれば、次のように表示される。

Authenticate to server

Successfully logged into server.

また、指定したベースdnが未作成の場合は、次のように表示される。

This base cannot be created with PLA.

＜参考＞

・デージーネット. 入門LDAP/OpenLDAPディレクトリサービス導入・運用ガイド第3版. 秀和システム, 2017, 430p.

・Install and Configure phpLDAPAdmin on CentOS 7 / Ubuntu 16.04

< https://www.itzgeek.com/how-tos/linux/centos-how-tos/install-configure-phpldapadmin-centos-7-ubuntu-16-04.html > 2022年2月20日

・【LDAP基礎用語】DCとは？OUとは？バインドDN,ベースDN,サフィックスとは？匿名バインドとは？ldapsearchのオプション

< https://milestone-of-se.nesuke.com/l7protocol/ldap/binddn-basedn/ >

【Linux CentOS 7】ソースから導入したOpenLDAP(2.5.12)の初期設定と、エントリに関する理解【OpenLDAP 2.5.12】

　次のページ「CentOS 7にOpenLDAP(2.5.12)をソースファイルからインストールする手順」のつづきである。

https://akira-arets.blogspot.com/2022/07/linux-centos7-install-openldap2.5.12.html

　ここでは続いて、初期設定のみ行う。

　上記の手順で構築したコンテナに接続して初期設定を継続するか、上記の手順で作成したイメージから新しくコンテナを始動させて初期設定を行うこともできる。

◯　上記の手順で作成したコンテナを継続して設定する場合

・今回の作業に合うような名称に変更しておく

# docker rename ldap_justinstalled_centos7_priv  ldap_installed_initialized_centos7_priv

・コンテナを始動する

# docker start ldap_installed_initialized_centos7_priv

・コンテナに接続する

# docker exec -it ldap_installed_initialized_centos7_priv /bin/bash

[root@89192c461c39 /]#

◯　上記の手順で作成したイメージからコンテナを始動させる場合

　コンテナ名は、既存のものと重ならないようにすること。

# docker run --privileged -d --net MYNETWORK --dns 192.168.1.1 --name ldap_installed_initialized_centos7_priv image_centos7_openldap-ver-2.5.12_202207XX_justinstalled /sbin/init

[root@b34e14346f76 /]#

（以下の設定を行うためには必須）

--privileged　特権でコンテナを動作させる

/sbin/init　initを起動する。

（オプション）

--net MYNETWORK　指定したDockerネットワークを利用する。（リモート接続しないなら不要）

--dns 192.168.1.1　コンテナに利用させるリゾルバを指定する。（ホストのものを使うなら不要）

　初期設定には、LDAPディレクトリの基本的な考え方が必要である。

■　LDAPに登場するLDAPディレクトリの考え方

　これらのLDAPディレクトリはDIT（ディレクトリ情報ツリー）構造を持つ。

DIT内の各位置はエントリと呼ばれる。

　エントリは、FATファイルシステムなどでいうところの「ファイル」と「ディレクトリ」に似ている。エントリのうち一部は「ファイル」に相当し情報を保持する役割がある。「ディレクトリ」に相当するエントリは下位のエントリをまとめる役割があり、コンテナと呼ばれる。これらのエントリはDN（ディレクトリやファイルを指定するパスのようなもの）によって指定され他と区別される。

　エントリには「ファイル」と「ディレクトリ」の概念だけでは説明できない特徴もある。「ファイル」というものが型なしでシーケンシャルにデータを保存する一方で、エントリは型付きでデータを保存すると考えられる。

　すると、エントリはオブジェクト指向プログラミング言語の「参照」に似ている。情報を保持する「ファイル」に相当するエントリは、データ構造などを定義する「LDAPオブジェクトクラス（personなど）」の実体化をポイントしている「参照」と捉えられる。

　エントリには「LDAPオブジェクトクラス」が指定され、オブジェクトクラスの属性に対応する属性値としてデータがストアされる。どの属性を持つかはオブジェクトクラスによって違うし、オブジェクトクラスには継承という概念もあり親クラスの属性は引き継がれる。

　LDAPサーバーから情報を検索するアプリケーションが求める属性値に応じたオブジェクトクラスがエントリで指定される必要がある。

■　slapdの初期設定

（概要）

　LDAPサーバーは、本業のデータ管理用「データディレクトリ」と、自分自身の設定を管理する「設定用ディレクトリ」から成る。

　slapd.confファイルによる初期設定で、「データディレクトリ」と、「設定ディレクトリ」について初期設定を行う。（LDAPサーバーの運用後には、LDAPサーバーの設定はLDAPサーバーに統合された「設定用ディレクトリ」の内容変更によって行う。）

　さらに後で述べるように、「設定ディレクトリ」の具体化も別に行う必要がある。

（目次）

＜１＞　オリジナル設定ファイルのバックアップ

＜２＞　オリジナル設定ファイルの確認

＜３＞　初期設定ファイルの編集（オリジナル設定ファイルを基に作成する）

＜４＞　「設定ディレクトリ（config directory）」の作成

＜１＞　オリジナル設定ファイルのバックアップ

# cp /usr/local/etc/openldap/slapd.conf /usr/local/etc/openldap/slapd.conf.org

＜２＞　オリジナル設定ファイルの確認

　オレンジ（suffix項目、rootdn項目）と、黄色（rootpw項目）の各マーカーのところを環境に合わせて、後で述べるように変更する。

# cat /usr/local/etc/openldap/slapd.conf.org

#

# See slapd.conf(5) for details on configuration options.

# This file should NOT be world readable.

#

include /usr/local/etc/openldap/schema/core.schema

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory

# service AND an understanding of referrals.

#referral ldap://root.openldap.org

pidfile /usr/local/var/run/slapd.pid

argsfile /usr/local/var/run/slapd.args

# Load dynamic backend modules:

# modulepath /usr/local/libexec/openldap

# moduleload back_mdb.la

# moduleload back_ldap.la

# Sample security restrictions

# Require integrity protection (prevent hijacking)

# Require 112-bit (3DES or better) encryption for updates

# Require 63-bit encryption for simple bind

# security ssf=1 update_ssf=112 simple_bind=64

# Sample access control policy:

# Root DSE: allow anyone to read it

# Subschema (sub)entry DSE: allow anyone to read it

# Other DSEs:

# Allow self write access

# Allow authenticated users read access

# Allow anonymous users to authenticate

# Directives needed to implement policy:

# access to dn.base="" by * read

# access to dn.base="cn=Subschema" by * read

# access to *

# by self write

# by users read

# by anonymous auth

#

# if no access controls are present, the default policy

# allows anyone and everyone to read anything but restricts

# updates to rootdn.  (e.g., "access to * by * read")

#

# rootdn can always read and write EVERYTHING!

#######################################################################

# config database definitions

#######################################################################

database config

# Uncomment the rootpw line to allow binding as the cn=config

# rootdn so that temporary modifications to the configuration can be made

# while slapd is running. They will not persist across a restart.

# rootpw secret

#######################################################################

# MDB database definitions

#######################################################################

database mdb

maxsize 1073741824

suffix "dc=my-domain,dc=com"

rootdn "cn=Manager,dc=my-domain,dc=com"

# Cleartext passwords, especially for the rootdn, should

# be avoid.  See slappasswd(8) and slapd.conf(5) for details.

# Use of strong authentication encouraged.

rootpw secret

# The database directory MUST exist prior to running slapd AND 

# should only be accessible by the slapd and slap tools.

# Mode 700 recommended.

directory /usr/local/var/openldap-data

# Indices to maintain

index objectClass eq

#######################################################################

# monitor database definitions

#######################################################################

database monitor

＜３＞　初期設定ファイルの編集（オリジナル設定ファイルを基に作成する）

　下記に挙げる初期設定はLDAPサーバーの運用前に初期投入するものである。

「データディレクトリ」と「設定用ディレクトリ」の利用に必要な初期設定を盛り込んだ内容になっている。

・データディレクトリ管理用パスワードの決定とハッシュデータの作成

　これについて、予め、パスワードを決めておき、それのハッシュデータを作成した。

このハッシュは初期設定ファイルに記述する。

# slappasswd 

New password: YourPlainPassword

Re-enter new password:

{SSHA}HereLongStringsAsYourEncryptedPassword

・初期設定ファイルの編集

　オリジナル設定ファイルの内容をベースにしながら、次のように必要な設定を加えた。

設定内容の解説は下記の通り。

# vi /usr/local/etc/openldap/slapd.conf

include         /usr/local/etc/openldap/schema/core.schema

pidfile         /usr/local/var/run/slapd.pid

argsfile        /usr/local/var/run/slapd.args

database        config

rootdn          cn=admin,cn=config

access  to *

        by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage

        by * break by * none

database        mdb

maxsize         1073741824

suffix          "dc=example,dc=co,dc=jp"

rootdn          "cn=Manager,dc=example,dc=co,dc=jp"

rootpw          {SSHA}HereLongStringsAsYourEncryptedPassword

directory       /usr/local/var/openldap-data

index   objectClass     eq

（設定内容の説明）

　初期投入する初期設定ファイルでは、「database config」項目でLDAP設定用ディレクトリに関する初期設定を行い、「database mdb」項目でデータディレクトリに関する初期設定を行う。

「database config」項目について：

・　rootdn          cn=admin,cn=config

　これは「設定ディレクトリ」の特権（管理者）を表すDNである。（後に登場する「データディレクトリ」の管理者と区別すること。）ここで設定するDNは「設定ディレクトリ」DIT内の特定のエントリを指定するものであることから、エントリによって管理者ユーザー名を表すと考えられる。

　このように別個の外部ファイルにではなく、エントリでユーザーを定義する点が独特である。（LDAPサーバーが、ファイルシステムに似たLDAPディレクトリという仕組みを持つものでこういうことは自然なのかもしれない。）

　設定用ディレクトリのDITの頂上（トップ）にあるエントリは「cn=config」というDNで指定され、その下位にさらにエントリ（cn=admin）が置かれ、この「cn=admin」エントリが設定ディレクトリの管理者ユーザーを定義するということだと考えられる。

　ところで、この「設定ディレクトリ」の特権（管理者）は、ネットワーク経由でLDAPサーバーが設定されるときに使用される。実際の使用には別途パスワードの設定も行う必要がある。（この段階では、まだパスワードの設定はしていない。）

　通常は、ローカルのLDAPサーバーの設定ディレクトリへのアクセスは、ネットワーク経由でのアクセスでなく「UNIXドメインソケット」経由で行う。そこではアクセス時にこの特権DNを指定することはない。

・　access  to *

        by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage

　上で述べた「UNIXドメインソケット」経由での設定ディレクトリへのアクセスを許可している。

「access  to *」は、設定ディレクトリの全てのエントリが対象であることに言及。

「manage」は、管理者権限の付与について言及している。

「by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"」は、Linuxのrootユーザーへのその権限の付与を行うよう言及している。

　「UNIXドメインソケット」経由での設定ディレクトリへのアクセスを行う具体的なコマンドについては別に扱うことにする。

「database mdb」項目について：

　この項目では「データディレクトリ」の初期設定を定義している。

・　maxsize         1073741824

　データベースの最大サイズをbyte単位で定める。（約1GBを指定している。）

・　suffix          "dc=example,dc=co,dc=jp"

　「データディレクトリ」ツリーを識別するDNを定める。ルートディレクトリに名前が付いたようなものである。通常、組織のドメイン名を使う。データディレクトリ内のデータに関するエントリは、このDNで指定されるエントリ（dc=example）の配下に置かれる。したがって、それらのデータに関するエントリを指定するDNは、このDN（dc=example,dc=co,dc=jp）をサフィックスとして含むことになる。httpでデータにアクセスするためのURLの構造に似ている。

・　rootdn          "cn=Manager,dc=example,dc=co,dc=jp"

　「データディレクトリ」の特権ユーザーを表すエントリを定義している。これは特権DNと呼ばれる。（「設定ディレクトリ」の特権DNとは別に定義されていることに注意する。）

・　rootpw          {SSHA}HereLongStringsAsYourEncryptedPassword

　特権DNのパスワードのハッシュ値を設定している。（最初にslappasswd で生成したハッシュ値のことである。）

・　directory       /usr/local/var/openldap-data

　データベースを保存するファイルシステム上のディレクトリの指定

・　index   objectClass     eq

　データ検索の高速化に寄与するのがインデックス（いわゆる索引）というものである。インデックスを作成するため、元にする「属性」を指定する。

　ここでは、エントリが持つ「objectClass」という属性の属性値について、等価であるかどうかの判断を高速化を図るためのインデックスが定義されている。

　DIT（LDAPディレクトリツリー）にはいろいろなエントリにより構造化される。後で検索の対象となるデータを保持するエントリは「objectClass」属性を持ち、「objectClass」を指示している。「objectClass」はデータを格納する収納棚のようなもので、「objectClass」の種類によってその引き出しの数やラベリングが異なっている。

　だから、データ検索には、まずターゲットとする棚である「objectClass」を早く見つけることが大切だと考えられる。そのため、インデックス（索引）が「objectClass」に関してそのように作成されるのだと考えられる。

　（ここでは「objectClass」属性に対してのみインデックスを作成しているが、LDAPサーバーを利用するアプリケーションによっては、検索項目の属性についてもインデックスを作成した方が良いのだろうか。）

＜４＞　「設定ディレクトリ（config directory）」の作成

・必要なディレクトリの準備

# mkdir /usr/local/etc/openldap/slapd.d

# mkdir /usr/local/var/openldap-data

・設定ファイルをもとにして「設定ディレクトリ」を生成

# cd /usr/local/etc/openldap

# slaptest -f slapd.conf -F slapd.d

mdb_db_open: database "dc=example,dc=com" cannot be opened: No such file or directory (2). Restore from backup!

backend_startup_one (type=mdb, suffix="dc=example,dc=com"): bi_db_open failed! (2)

slap_startup failed (test would succeed using the -u switch)

　設定ディレクトリの作成に成功すれば次のようにファイルが作られている。

# ls /usr/local/etc/openldap/slapd.d

cn=config  cn=config.ldif

■　slapdのためのsystemdユニットファイルの作成

　ここの設定は、冒頭に挙げたインストール編で既に済ませている。

# vi /lib/systemd/system/slapd.service

[Unit]

Description=OpenLDAP Server

After=syslog.target network.target

[Service]

Type=forking

PIDFile=/usr/local/var/run/slapd.pid

ExecStart=/usr/local/libexec/slapd -h "ldap:/// ldapi:///"

ExecReload=/bin/kill -HUP $MAINPID

ExecStop=/bin/kill -TERM $MAINPID

[Install]

WantedBy=multi-user.target

# systemctl daemon-reload

■　slapd（OpenLDAP）の起動

# systemctl start rsyslog

                                                                                                              

# systemctl start slapd

# systemctl status slapd

● slapd.service - OpenLDAP Server

   Loaded: loaded (/usr/lib/systemd/system/slapd.service; disabled; vendor preset: disabled)

   Active: active (running) since Mon 2022-07-11 07:33:17 JST; 4s ago

  Process: 234 ExecStart=/usr/local/libexec/slapd -h ldap:/// ldapi:/// (code=exited, status=0/SUCCESS)

 Main PID: 235 (slapd)

   CGroup: /docker/b34e14346f76dea9f5b6ee70fd236c4c1718f2107973b5f6688c9852ad5f20e0/system.slice/slapd.service

           └─235 /usr/local/libexec/slapd -h ldap:/// ldapi:///

           ‣ 235 /usr/local/libexec/slapd -h ldap:/// ldapi:///

Jul 11 07:33:07 b34e14346f76 systemd[1]: Starting OpenLDAP Server...

Jul 11 07:33:07 b34e14346f76 slapd[234]: @(#) $OpenLDAP: slapd 2.5.12 (Jul  6 2022 07:01:28) $

                                                 root@89192c461c39:/root/Software/OpenLDAP/openldap-2.5.12/servers/slapd

Jul 11 07:33:17 b34e14346f76 systemd[1]: Started OpenLDAP Server.

# cat /usr/local/var/run/slapd.pid 

235

◯　自動的に起動するように設定しておく。

# systemctl enable slapd

■　基本となるエントリの作成

 ここではOpenLDAPサーバーの「データディレクトリ」に、基本である次の2つのエントリを作成する。

一つ目は、ディレクトリ空間のトップノードにあたるエントリである。

二つ目は、ルートDNのためのエントリである。

それぞれ、slapd.confで指定したデータディレクトリに関する内容（suffix、rootdn）と一致させておく。ここではslapd.confに次のように指定したのだった。

database        mdb

maxsize         1073741824

suffix          "dc=example,dc=co,dc=jp"

rootdn          "cn=Manager,dc=example,dc=co,dc=jp"

rootpw          {SSHA}HereLongStringsAsYourEncryptedPassword

directory       /usr/local/var/openldap-data

index   objectClass     eq

これにもとづいて、次のように設定用のldifファイルを作成してOpenLDAPサーバーにコマンドで登録する。

◯　設定用のldifファイルの作成

　まとめて、2つのエントリの情報を含めている。

　ファイル名は日付と通し番号をつけ、データディレクトリに関する設定であることと、その内容について簡単なメモを付けた。

　こういう設定用ldifファイルは、適当な専用のディレクトリにまとめるようにすると良いと思う。そうすれば、あとでファイル一覧で履歴として見ることができる。

# vi 202207XX-001_DATA_init.ldif

dn: dc=example,dc=co,dc=jp

objectClass: organization

objectClass: dcObject

o: Example Co., Ltd

dc: example

dn: cn=Manager,dc=example,dc=co,dc=jp

objectClass: organizationalRole

cn: Manager

＜設定の意味＞

　ここには私見、推測が含まれています。しかしエントリの設定について理解がしやすくなるので、次のようにエントリとその実体とに分けて考えています。エントリがエントリの実体をポイントしているととらえることと、ldifファイルではその両方をまとめて定めていると考えることが大切だと思います。

　ここでは、２つのエントリについて、エントリのディレクトリツリー上での位置とその実体について設定している。

まず、それぞれのエントリが位置するパスを示すDN（区別する名前という意味）を指定している。

dn: dc=example,dc=co,dc=jp

dn: cn=Manager,dc=example,dc=co,dc=jp

　このDNの末端（アンダーライン付きの要素）には「dc=example」と「cn=Manager」が指定されていて、これがそれぞれの（エントリの）実体を指し示すと考えられる。

　実体をポイントするDN末端の「dc=example」や「cn=Manager」には、（エントリの）実体が保持するオブジェクトクラスの属性とその値と同じ組が使われている。そのため、このDN末端の「dc=example」や「cn=Manager」に合うように、（エントリの）実体としてそれぞれ次のように、オブジェクトクラスとその属性とその値が定義される必要がある。

　オブジェクト指向プログラミングでは、このエントリは”参照”に相当すると考えられる。しかし、”参照”は任意の名称をもち階層構造にもなっていない。しかし、エントリはディレクトリツリーという階層構造中の一つであり、その名称は参照先の実体が持つ属性値と同じであるという特徴がある。その意味では、中途半端に参照（エントリ）とその実体が分かれており、文字通りわかりにくさがある。

（一つ目のエントリについての設定）

・dn: dc=example,dc=co,dc=jp

　設定するエントリに至るパス（DN）を指定する。

　

・objectClass: organization

　組織名を表す属性（o）を持つクラスである。

　同じエントリで「o: Example Co., Ltd」のようにこの属性を設定しておく。

・objectClass: dcObject

　ドメイン名を表す属性（dc）を持つクラスである。

　今、エントリ「dc=example（,dc=co,dc=jp）」の設定を行っているので、上で述べたように、（エントリの）実体にはdc属性は必須である。そのため、dc属性を提供するこのクラス「objectClass: dcObject」が必要である。（さらに、その属性値も、すぐ下の「dc: example」で説明しているように、エントリとして使われているdc=exampleに一致させる。）

・o: Example Co., Ltd

　「objectClass: organization」クラスの属性「o」の設定値である。

・dc: example

　「objectClass: dcObject」クラスの属性「dc」の設定値である。

　今、エントリ「dc=example（,dc=co,dc=jp）」の設定を行っているので、このdc属性値は「example」としておき、エントリ「dc=example（,dc=co,dc=jp）」と一致させておく。

（二つ目のエントリについての設定）

・dn: cn=Manager,dc=example,dc=co,dc=jp

　設定するエントリに至るパス（DN）を指定する。

・objectClass: organizationalRole

　役割（ロール）に関する情報を表すオブジェクトクラスで、名称を表す属性（cn）を持つクラスである。

　今、エントリ「cn=Manager（,dc=co,dc=jp）」の設定を行っているので、上で述べたように、（エントリの）実体にはcn属性は必須である。また、このエントリはロールに関する情報を扱うため、cn属性を提供し、ロールに関する情報を定めるクラス「objectClass: organizationalRole」が必要である。（さらに、その属性値も、すぐ下で説明しているようにエントリとして使われているcn=Managerに一致させる。）

・cn: Manager

　「objectClass: organizationalRole」クラスの属性「cn」の設定値である。

　今、エントリ「cn=Manager（,dc=co,dc=jp）」の設定を行っているので、このcn属性値は「Manager」としておき、エントリ「cn=Manager（,dc=co,dc=jp）」と一致させておく。

◯　OpenLDAPサーバーに設定内容を登録する。

　OpenLDAPサーバーを動作させておく。

# systemctl start slapd

　次のように追加用コマンドで、先程作成した設定ファイルを指定し、含まれる２つのエントリを追加する。尋ねられれるパスワードは、slapd.confでrootpw項目に記述したハッシュに対応するプレインパスワードを指定する。

# ldapadd -x -D "cn=Manager,dc=example,dc=co,dc=jp" -W -f 202207XX-001_DATA_init.ldif

Enter LDAP Password: PlainPassword 

adding new entry "dc=example,dc=co,dc=jp"

adding new entry "cn=Manager,dc=example,dc=co,dc=jp"

＜オプションの意味＞

・　-x

　認証にはSASLを使わない。（simple authenticationを使う）

・　-D "cn=Manager,dc=example,dc=co,dc=jp"

　認証するためにバインドするべきDNを指定する。

　LDAPでは、クライアントの認証にバインドという手続きを用いる。

　バインドによって認証されたクライアントはその権限の範囲でアクセスできる。

・　-W

　simple authenticationの際に、パスワードの入力をダイアログ形式で行う。（コマンドラインに入れない）

・　-f 202207XX-001_DATA_init.ldif

　エントリ変更用ファイルを指定する。（標準入力は使わない）

（エラーが出る場合）

・ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

　→　slapdが起動していないので、あらかじめ起動しておく。

・ldapadd: invalid format (line 2) entry: "dc=example,dc=co,dc=jp"

　→　指定されたエントリの記述に誤りがある。（イコール、コロンの使い間違いとか）

　以上で、基本的な初期設定は完了した。

　必要に応じて、次のようにphpLDAPAdminというWEBベースクライアントもインストールしておく。

【Docker Linux CentOS 7】OpenLDAPのためにWEBベースクライアントphpLDAPAdminを導入する【phpLDAPAdmin 1.2.5】

https://akira-arets.blogspot.com/2022/07/linux-centos7-install-phpldapadmin-for-openldap.html

　後は、OpenLDAPの各々の利用目的に応じた設定を行うことになる。

■　ここまで構築してきたコンテナのイメージを作成しておく

◯　イメージの作成

・コンテナを終了した。

[root@89192c461c39 /]# poweroff

・コミットコマンドを実行してイメージを作成した。（Dockerホストにおいて）

# docker commit ldap_installed_initialized_centos7_priv image_centos7_openldap-ver-2.5.12_202207XX_installed_initialized

ldap_

installed_initialized

_centos7_priv…ターゲットのコンテナ名称

image_centos7_openldap-ver-2.5.12_202207XX_installed_initialized

…作成するイメージにつける名前

・イメージの確認

# docker image list

REPOSITORY                                                         TAG       IMAGE ID       CREATED          SIZE

image_centos7_openldap-ver-2.5.12_202207XX_installed_initialized   latest    a8ab2cfbfe49   10 seconds ago   1.6GB

＜参考＞

・デージーネット. 入門LDAP/OpenLDAPディレクトリサービス導入・運用ガイド第3版. 秀和システム, 2017, 430p.

・Centralized authentication using OpenLDAP

< https://wiki.gentoo.org/wiki/Centralized_authentication_using_OpenLDAP/en > 2022年2月20

・そろそろLDAPにしてみないか？　第10回　OpenLDAPとACL

< https://gihyo.jp/admin/serial/01/ldap/0010 > 2022年4月6日

・サーバー管理の困った！を○○で解決　LDAPを使ったユーザー管理編

< https://www.nedia.ne.jp/blog/tech/2015/09/08/5570 > 2022年4月7日

・CentOS7 OpenLDAPの設定

< https://www.unix-power.net/networking/post-746 > 2022年2月20

・LDAP の設定と構成 / インデックス

< https://docs.oracle.com/cd/E19455-01/806-7089/6jg0449jq/index.html > 2022年4月7日

・OpenLDAPのindex設定

< https://qiita.com/morih90/items/0398f3dc4591b245a567 > 2022年4月7日

・OpenLDAPによるディレクトリサーバ運用（5） / ビシッと決めるチューニング：しっかり基本編

< https://atmarkit.itmedia.co.jp/ait/articles/1006/21/news102_3.html > 2022年4月7日

・OpenLDAP Manual Pages / ldapadd(1)

< https://www.openldap.org/software//man.cgi?query=ldapadd&sektion=1&apropos=0&manpath=OpenLDAP+2.4-Release > 2022年7月14日

・5.3.98. organizationalRole

< https://access.redhat.com/documentation/ja-jp/red_hat_directory_server/10/html/configuration_command_and_file_reference/organizationalrole > 2022年7月14日

【Linux CentOS 7】OpenLDAP(2.5.12)をソースファイルからインストールする手順【OpenLDAP 2.5.12】

CentOS 7にOpenLDAP(2.5.12)をソースファイルからインストールする手順

ここでは、Dockerコンテナを用いている。

CentOS 7といくつかのソフトウェアが動作するコンテナをベースとして、そこにOpenLDAPを追加した。

■　既存のDockerイメージから特権コンテナを動作させた

◯　次のページの方法で既にベースとなるコンテナは作成済みである。

https://akira-arets.blogspot.com/2022/06/docker-privileged-centos7-container-controlled-by-systemd.html

◯　上記の方法で作成したイメージからコンテナを始動させた。

# docker run --privileged -d --net MYNETWORK --dns 192.168.1.1 --name ldap_justinstalled_centos7_priv image_centos7_basic_priv /sbin/init

[root@89192c461c39 /]#

（以下の設定を行うためには必須）

--privileged　特権でコンテナを動作させる

/sbin/init　initを起動する。

（オプション）

--net MYNETWORK　指定したDockerネットワークを利用する。（リモート接続しないなら不要）

--dns 192.168.1.1　コンテナに利用させるリゾルバを指定する。（ホストのものを使うなら不要）

■　予め必要なものとして新しいバージョンのOpenSSLをインストール

　CentOS7に標準リポジトリから入れられるopensslのバージョンは古いため、OpenLDAPの要件を満たさない。そのため、ソースから新しいバージョンのOpenSSLを導入する。

◯　必要なパッケージをインストールした。

[root@89192c461c39 /]# yum install make gcc perl-core pcre-devel wget zlib-devel

Total download size: 55 M

Installed size: 126 M

◯　OpenSSL本体の導入作業

・OpenSSLのソースをダウンロードと展開

　適当な場所にOpenSSLディレクトリを作成しカレントディレクトリを移動した。

[root@89192c461c39 OpenSSL]# wget https://ftp.openssl.org/source/openssl-1.1.1q.tar.gz

[root@89192c461c39 OpenSSL]# tar zxvf openssl-1.1.1q.tar.gz

・OpenSSLのインストール

　展開済みのディレクトリにカレントディレクトリを移動してから、順にコマンドを実行していく。

[root@89192c461c39 OpenSSL]# cd openssl-1.1.1q

[root@89192c461c39 openssl-1.1.1q]# ./config

Operating system: x86_64-whatever-linux2

Configuring OpenSSL version 1.1.1q (0x1010111fL) for linux-x86_64

Using os-specific seed configuration

Creating configdata.pm

Creating Makefile

**********************************************************************

***                                                                ***

***   OpenSSL has been successfully configured                     ***

***                                                                ***

***   If you encounter a problem while building, please open an    ***

***   issue on GitHub <https://github.com/openssl/openssl/issues>  ***

***   and include the output from the following command:           ***

***                                                                ***

***       perl configdata.pm --dump                                ***

***                                                                ***

***   (If you are new to OpenSSL, you might want to consult the    ***

***   'Troubleshooting' section in the INSTALL file first)         ***

***                                                                ***

**********************************************************************

[root@89192c461c39 openssl-1.1.1q]# make

[root@89192c461c39 openssl-1.1.1q]# make test

　次の項目についてはskippedになっていたが、それ以外はすべてokだった。

../test/recipes/05-test_md2.t ...................... skipped: md2 is not supported by this OpenSSL build

../test/recipes/05-test_rc5.t ...................... skipped: rc5 is not supported by this OpenSSL build

../test/recipes/30-test_afalg.t .................... skipped: test_afalg not supported for this build

../test/recipes/90-test_gost.t ..................... skipped: No test GOST engine found

../test/recipes/90-test_overhead.t ................. skipped: Only supported in no-shared builds

../test/recipes/95-test_external_boringssl.t ....... skipped: No external tests in this configuration

../test/recipes/95-test_external_krb5.t ............ skipped: No external tests in this configuration

../test/recipes/95-test_external_pyca.t ............ skipped: No external tests in this configuration

All tests successful.

最後に次のように表示された。

Files=158, Tests=2641, 156 wallclock secs ( 3.23 usr  0.38 sys + 111.18 cusr 57.48 csys = 172.27 CPU)

Result: PASS

make[1]: Leaving directory `/root/Software/OpenSSL/openssl-1.1.1q'

[root@89192c461c39 openssl-1.1.1q]# make install

・リンクを張る（その１）

[root@89192c461c39 openssl-1.1.1q]# openssl version

openssl: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

[root@89192c461c39 openssl-1.1.1q]# ln -s /usr/local/lib64/libssl.so.1.1 /usr/lib64/

・リンクを張る（その２）

[root@89192c461c39 openssl-1.1.1q]# openssl version

openssl: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory

[root@89192c461c39 openssl-1.1.1q]# ln -s /usr/local/lib64/libcrypto.so.1.1 /usr/lib64/

・バージョン確認

[root@89192c461c39 openssl-1.1.1q]# openssl version

OpenSSL 1.1.1q  5 Jul 2022

■　OpenLDAPのインストール

◯　必要なパッケージをインストールした。

[root@89192c461c39 ~]# yum install gcc gcc-c++ libxml2 libxml2-devel openssl-devel ncurses-devel sqlite-devel newt-devel libuuid-devel uuid-devel make wget

◯　OpenSSL本体の導入作業

・OpenSSLのソースをダウンロードと展開

　適当な場所にOpenLDAPディレクトリを作成しカレントディレクトリを移動した。

[root@89192c461c39 OpenLDAP]# wget https://www.openldap.org/software/download/OpenLDAP/openldap-release/openldap-2.5.12.tgz

Length: 6444482 (6.1M)

[root@89192c461c39 OpenLDAP]# tar zxvf openldap-2.5.12.tgz

・OpenSSLのインストール

　さらに必要になるパッケージを予めインストールした。

[root@89192c461c39 openldap-2.5.12]# yum install cyrus-sasl-devel gnutls-devel systemd-devel file

　展開済みのディレクトリにカレントディレクトリを移動してから、順にコマンドを実行していく。

[root@89192c461c39 OpenLDAP]# cd openldap-2.5.12

[root@89192c461c39 openldap-2.5.12]# ./configure --with-tls --enable-crypt --with-cyrus-sasl --enable-rwm

Making servers/slapd/backends.c

    Add config ...

    Add ldif ...

    Add monitor ...

    Add mdb ...

    Add relay ...

Making servers/slapd/overlays/statover.c

    Add rwm ...

    Add syncprov ...

Please run "make depend" to build dependencies

[root@89192c461c39 openldap-2.5.12]# make depend

[root@89192c461c39 openldap-2.5.12]# make

[root@89192c461c39 openldap-2.5.12]# make test

6コアマシンで15分くらいかかった。

（略）

0 tests for mdb were skipped.

make[2]: Leaving directory `/root/Software/OpenLDAP/openldap-2.5.12/tests'

make[2]: Entering directory `/root/Software/OpenLDAP/openldap-2.5.12/tests'

run configure with --enable-balancer to run the Load Balancer tests

make[2]: Leaving directory `/root/Software/OpenLDAP/openldap-2.5.12/tests'

make[1]: Leaving directory `/root/Software/OpenLDAP/openldap-2.5.12/tests'

[root@89192c461c39 openldap-2.5.12]# make install

■　OpenLDAPを自動起動できるように設定

　最初、次のような起動用スクリプトが存在していた。

[root@89192c461c39 openldap-2.5.12]# cat /lib/systemd/system/slapd.service

[Unit]

Description=OpenLDAP Server Daemon

After=syslog.target network-online.target

Documentation=man:slapd

Documentation=man:slapd-config

Documentation=man:slapd-mdb

[Service]

Type=notify

Environment="SLAPD_URLS=ldap:/// ldapi:///" "SLAPD_OPTIONS="

EnvironmentFile=/etc/sysconfig/slapd

ExecStart=/usr/local/libexec/slapd -d 0 -h ${SLAPD_URLS} $SLAPD_OPTIONS

[Install]

WantedBy=multi-user.target

　しかし、これを用いても次のようにうまくLDAPサーバーは動作しなかった。

[root@89192c461c39 ~]# systemctl status slapd             

Job for slapd.service failed because the control process exited with error code. See "systemctl status slapd.service" and "journalctl -xe" for details.

[root@89192c461c39 ~]# systemctl status slapd

● slapd.service - OpenLDAP Server Daemon

   Loaded: loaded (/usr/lib/systemd/system/slapd.service; disabled; vendor preset: disabled)

   Active: failed (Result: resources)

     Docs: man:slapd

           man:slapd-config

           man:slapd-mdb

Jun 30 08:30:19 89192c461c39 systemd[1]: Failed to load environment files: No such file or directory

Jun 30 08:30:19 89192c461c39 systemd[1]: slapd.service failed to run 'start' task: No such file or directory

Jun 30 08:30:19 89192c461c39 systemd[1]: Failed to start OpenLDAP Server Daemon.

Jun 30 08:30:19 89192c461c39 systemd[1]: Unit slapd.service entered failed state.

Jun 30 08:30:19 89192c461c39 systemd[1]: slapd.service failed.

◯　 起動できるように設定

・次のようにリンクが張られていることを確認した。

[root@89192c461c39 ~]# ls /lib -al

lrwxrwxrwx 1 root root 7 Nov 13  2020 /lib -> usr/lib

　つまり、/libは、/usr/libディレクトリに繋がっている。

以下では、/libを指定してファイル操作を行う。

・念の為、オリジナルのバックアップを取った。

[root@89192c461c39 ~]# cp /lib/systemd/system/slapd.service /lib/systemd/system/slapd.service.org

・次のように編集した

[root@89192c461c39 ~]# vi /lib/systemd/system/slapd.service

[Unit]

Description=OpenLDAP Server

After=syslog.target network.target

[Service]

Type=forking

PIDFile=/usr/local/var/run/slapd.pid

ExecStart=/usr/local/libexec/slapd -h "ldap:/// ldapi:///"

ExecReload=/bin/kill -HUP $MAINPID

ExecStop=/bin/kill -TERM $MAINPID

[Install]

WantedBy=multi-user.target

[root@89192c461c39 ~]# systemctl daemon-reload

・起動を試行

　しかし、次のように起動が失敗した。

[root@89192c461c39 ~]# systemctl start slapd

Job for slapd.service failed because the control process exited with error code. See "systemctl status slapd.service" and "journalctl -xe" for details.

　失敗の原因を調べた。

[root@89192c461c39 ~]# systemctl status slapd

● slapd.service - OpenLDAP Server

   Loaded: loaded (/usr/lib/systemd/system/slapd.service; disabled; vendor preset: disabled)

   Active: failed (Result: exit-code) since Thu 2022-07-07 08:35:45 JST; 29min ago

Jul 07 08:35:45 89192c461c39 systemd[1]: Starting OpenLDAP Server...

Jul 07 08:35:45 89192c461c39 slapd[276]: @(#) $OpenLDAP: slapd 2.5.12 (Jul  6 2022 07:01:28) $

                                                 root@89192c461c39:/root/Software/OpenLDAP/openldap-2.5.12/servers/slapd

Jul 07 08:35:45 89192c461c39 slapd[276]: /usr/local/etc/openldap/slapd.conf: line 72: invalid path: No such file or directory

Jul 07 08:35:45 89192c461c39 slapd[276]: slapd stopped.

Jul 07 08:35:45 89192c461c39 slapd[276]: connections_destroy: nothing to destroy.

Jul 07 08:35:45 89192c461c39 systemd[1]: slapd.service: control process exited, code=exited status=1

Jul 07 08:35:45 89192c461c39 systemd[1]: Failed to start OpenLDAP Server.

Jul 07 08:35:45 89192c461c39 systemd[1]: Unit slapd.service entered failed state.

Jul 07 08:35:45 89192c461c39 systemd[1]: slapd.service failed.

　/usr/local/etc/openldap/slapd.confの72行目（directory       /usr/local/var/openldap-data）で指定されているパスにファイルが存在せず、起動が失敗しているとわかった。

まずは、初期設定を正しく行うことが必要であるとわかった。

◯　初期設定については次のページに、引き続き記述することにする。

【Docker Linux CentOS 7】ソースから導入したOpenLDAP(2.5.12)の初期設定と、エントリに関する理解【OpenLDAP 2.5.12】

https://akira-arets.blogspot.com/2022/07/linux-centos7-initialize-openldap2.5.12.html

■　ここまで構築してきたコンテナのイメージを作成しておく

　いったんインストール作業としてはここで完了として、Dockerコンテナのコミットしイメージ化することにした。

・作業の続きに備えて、OpenLDAPについて自動起動試行しないように設定した。

[root@89192c461c39 ~]# systemctl disable slapd

◯　イメージの作成

・コンテナを終了した。

[root@89192c461c39 /]# poweroff

・コミットコマンドを実行してイメージを作成した。（Dockerホストにおいて）

# docker commit ldap_justinstalled_centos7_priv image_centos7_openldap-ver-2.5.12_202207XX_justinstalled

ldap_justinstalled_centos7_priv

…ターゲットのコンテナ名称

image_centos7_openldap-ver-2.5.12_202207XX_justinstalled…作成するイメージにつける名前

・イメージの確認

# docker image list

REPOSITORY                                                         TAG       IMAGE ID       CREATED         SIZE

image_centos7_openldap-ver-2.5.12_202207XX_justinstalled           latest    xxxxxxxxxxxx   3 seconds ago   1.42GB

＜参考＞

・デージーネット. 入門LDAP/OpenLDAPディレクトリサービス導入・運用ガイド第3版. 秀和システム, 2017, 430p.

・デーモン管理をdaemontoolsからsystemdに移行させる

< https://techblog.kayac.com/advent-calendar-2019-daemontools-systemd > 2022年7月7日

・How to configure systemd to kill and restart a daemon on reload?

< https://serverfault.com/questions/767360/how-to-configure-systemd-to-kill-and-restart-a-daemon-on-reload > 2022年7月7日

・Installing OpenLDAP from Source on CentOS 7

< https://tylersguides.com/guides/install-openldap-source-centos-7/ > 2022年7月7日

【Docker Linux CentOS 7】systemctlによる制御が効くコンテナの作成と基本的サービスの追加

（概要）

イメージはCentOS7公式のものを利用し、特権で動作するDockerコンテナを起動する。

これにより、systemctlによる制御が効くコンテナが動作する。

さらに基本的なサービスをいくつか追加している。

（注意）

以下の手順では、安全なプライベートネットワーク内のホストマシンで行う。

■　システムの準備１〜コンテナ起動、アップデート、共通設定

◯　コンテナを起動（Dockerホストにおいて）

・centos:centos7公式イメージを利用し、コンテナを起動した。

# docker run --privileged -d --net MYNETWORK --dns 192.168.1.1 --name basic_centos7 centos:centos7 /sbin/init

（以下の設定を行うためには必須）

--privileged　特権でコンテナを動作させる

/sbin/init　initを起動する。

（オプション）

--net MYNETWORK　指定したDockerネットワークを利用する。（リモート接続しないなら不要）

--dns 192.168.1.1　コンテナに利用させるリゾルバを指定する。（ホストのものを使うなら不要）

「--net MYNETWORK」は、後でコンテナ外からSSH接続するため設定している。

予めDockerネットワークを作成しておく必要がある。（ここでは解説していない）

Dockerネットワークを使用しない場合、目的を達するためには別途PORTのオープンが必要になる。

PORTを開ける場合、LAN内の安全なネットワークに接続したホストマシンを使用する必要がある。

さもなければ、インターネット側にPORTが開いて攻撃を受けてしまう。

◯　起動したコンテナに接続（Dockerホストにおいて）

# docker exec -it basic_centos7 /bin/bash 

[root@6cbf3c357f18 /]#

◯　タイムゾーンの設定

 [root@6cbf3c357f18 ~]# ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

◯　システムの更新

・システムをアップデートした。

[root@6cbf3c357f18 /]# yum update -y

・一旦コンテナを終了した。

[root@6cbf3c357f18 /]# poweroff

・コンテナを再起動した。（Dockerホストにおいて）

# docker start basic_centos7

・コンテナに再接続した。（Dockerホストにおいて）

# docker exec -it basic_centos7 /bin/bash 

[root@6cbf3c357f18 /]#

■　システムの準備２〜基本的なソフトウェアの導入

◯　rsyslogのインストール

[root@6cbf3c357f18 ~]# yum install rsyslog

Installed:

  rsyslog.x86_64 0:8.24.0-57.el7_9.3

Dependency Installed:

  libestr.x86_64 0:0.1.9-2.el7                         libfastjson.x86_64 0:0.99.4-3.el7                         logrotate.x86_64 0:3.8.6-19.el7

Complete!

・自動起動設定〜起動〜状態の確認

[root@6cbf3c357f18 ~]# systemctl enable rsyslog

[root@6cbf3c357f18 ~]# systemctl start rsyslog

[root@6cbf3c357f18 ~]# systemctl status rsyslog

● rsyslog.service - System Logging Service

   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)

   Active: active (running) since Thu 2022-06-30 08:18:16 JST; 19s ago

     Docs: man:rsyslogd(8)

           http://www.rsyslog.com/doc/

 Main PID: 16658 (rsyslogd)

   CGroup: /docker/6cbf3c357f18b5b7f8c52e13295eeca959c9279da571b5d1260ac2850640962a/system.slice/rsyslog.service

           └─16658 /usr/sbin/rsyslogd -n

           ‣ 16658 /usr/sbin/rsyslogd -n

Jun 30 08:18:16 6cbf3c357f18 systemd[1]: Starting System Logging Service...

Jun 30 08:18:16 6cbf3c357f18 rsyslogd[16658]:  [origin software="rsyslogd" swVersion="8.24.0-57.el7_9.3" x-pid="16658" x-info="http://www.rsyslog.com"] start

Jun 30 08:18:16 6cbf3c357f18 systemd[1]: Started System Logging Service.

◯　postfixのインストール

[root@6cbf3c357f18 ~]# yum install postfix

Installed:

  postfix.x86_64 2:2.10.1-9.el7

Dependency Installed:

  mariadb-libs.x86_64 1:5.5.68-1.el7                                                 systemd-sysv.x86_64 0:219-78.el7_9.5

Complete!

・ipv6を利用しない設定を行った。

[root@6cbf3c357f18 ~]# postconf -e inet_protocols=ipv4

・自動起動設定〜起動〜状態の確認

[root@6cbf3c357f18 ~]# systemctl enable postfix

[root@6cbf3c357f18 ~]# systemctl start postfix

[root@6cbf3c357f18 ~]# systemctl status postfix

● postfix.service - Postfix Mail Transport Agent

   Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; vendor preset: disabled)

   Active: active (running) since Thu 2022-06-30 08:22:45 JST; 2s ago

  Process: 16742 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS)

  Process: 16741 ExecStartPre=/usr/libexec/postfix/chroot-update (code=exited, status=0/SUCCESS)

  Process: 16737 ExecStartPre=/usr/libexec/postfix/aliasesdb (code=exited, status=0/SUCCESS)

 Main PID: 16813 (master)

   CGroup: /docker/6cbf3c357f18b5b7f8c52e13295eeca959c9279da571b5d1260ac2850640962a/system.slice/postfix.service

           ├─16813 /usr/libexec/postfix/master -w

           ├─16814 pickup -l -t unix -u

           └─16815 qmgr -l -t unix -u

           ‣ 16813 /usr/libexec/postfix/master -w

Jun 30 08:22:44 6cbf3c357f18 systemd[1]: Starting Postfix Mail Transport Agent...

Jun 30 08:22:45 6cbf3c357f18 postfix/postfix-script[16811]: starting the Postfix mail system

Jun 30 08:22:45 6cbf3c357f18 postfix/master[16813]: daemon started -- version 2.10.1, configuration /etc/postfix

Jun 30 08:22:45 6cbf3c357f18 systemd[1]: Started Postfix Mail Transport Agent.

◯　crondのインストール

[root@6cbf3c357f18 ~]# yum install cronie

Installed:

  cronie.x86_64 0:1.4.11-24.el7_9

Dependency Installed:

  cronie-anacron.x86_64 0:1.4.11-24.el7_9                                            crontabs.noarch 0:1.11-6.20121102git.el7

Complete!

・自動起動設定〜起動〜状態の確認

[root@6cbf3c357f18 ~]# systemctl enable crond

[root@6cbf3c357f18 ~]# systemctl start crond

[root@6cbf3c357f18 ~]# systemctl status crond

● crond.service - Command Scheduler

   Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled)

   Active: active (running) since Thu 2022-06-30 08:28:42 JST; 3s ago

 Main PID: 16873 (crond)

   CGroup: /docker/6cbf3c357f18b5b7f8c52e13295eeca959c9279da571b5d1260ac2850640962a/system.slice/crond.service

           └─16873 /usr/sbin/crond -n

           ‣ 16873 /usr/sbin/crond -n

Jun 30 08:28:42 6cbf3c357f18 systemd[1]: Started Command Scheduler.

Jun 30 08:28:42 6cbf3c357f18 crond[16873]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 80% if used.)

Jun 30 08:28:42 6cbf3c357f18 crond[16873]: (CRON) INFO (running with inotify support)

◯　sshdのインストール

　コンテナ外部からsshによる接続をしない場合は不要である。

[root@6cbf3c357f18 ~]# yum install openssh-server

・自動起動設定〜起動〜状態の確認

[root@6cbf3c357f18 ~]# systemctl enable sshd

[root@6cbf3c357f18 ~]# systemctl start sshd

[root@6cbf3c357f18 ~]# systemctl status sshd

● sshd.service - OpenSSH server daemon

   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)

   Active: active (running) since Thu 2022-06-30 07:18:56 JST; 11s ago

     Docs: man:sshd(8)

           man:sshd_config(5)

 Main PID: 3820 (sshd)

   CGroup: /docker/6cbf3c357f18b5b7f8c52e13295eeca959c9279da571b5d1260ac2850640962a/system.slice/sshd.service

           └─3820 /usr/sbin/sshd -D

           ‣ 3820 /usr/sbin/sshd -D

Jun 30 07:18:56 6cbf3c357f18 systemd[1]: Starting OpenSSH server daemon...

Jun 30 07:18:56 6cbf3c357f18 sshd[3820]: Server listening on 0.0.0.0 port 22.

Jun 30 07:18:56 6cbf3c357f18 sshd[3820]: Server listening on :: port 22.

Jun 30 07:18:56 6cbf3c357f18 systemd[1]: Started OpenSSH server daemon.

・rootパスワードの設定

[root@6cbf3c357f18 ~]# passwd root

Changing password for user root.

New password:

◯　ネットワーク用ユーティリティのインストール

ip、nstatなどのコマンドが利用できるようになる。

[root@6cbf3c357f18 ~]# yum install iproute

■　ロケール関係のエラー回避のための作業

　あとで、ソースから何かインストール（たとえばOpenSSLのインストール）するときに次のように警告されることを回避するための作業である。

　警告とは次のようなものである。

perl: warning: Setting locale failed.

perl: warning: Please check that your locale settings:

        LANGUAGE = (unset),

        LC_ALL = (unset),

        LC_PAPER = "ja_JP.UTF-8",

        LC_ADDRESS = "ja_JP.UTF-8",

        LC_MONETARY = "ja_JP.UTF-8",

        LC_NUMERIC = "ja_JP.UTF-8",

        LC_TELEPHONE = "ja_JP.UTF-8",

        LC_IDENTIFICATION = "ja_JP.UTF-8",

        LC_MEASUREMENT = "ja_JP.UTF-8",

        LC_NAME = "ja_JP.UTF-8",

        LANG = "en_US.UTF-8"

    are supported and installed on your system.

perl: warning: Falling back to the standard locale ("C").

（回避策）

・次のようにファイル内の特定の行をコメントアウトしておく。

[root@e8394b6f7b13 /]# vi /etc/yum.conf

#override_install_langs=en_US.utf8

・さらに次のパッケージの再インストールを行っておく。

# yum reinstall glibc-common

Total download size: 12 M

Installed size: 216 M

Installed:

  glibc-common.x86_64 0:2.17-326.el7_9

Complete!

■　ここまで構築してきたコンテナのイメージを作成しておく

◯　イメージの作成

・コンテナを終了した。

[root@6cbf3c357f18 /]# poweroff

・コミットコマンドを実行してイメージを作成した。（Dockerホストにおいて）

# docker commit basic_centos7_priv image_centos7_basic_priv_202207XX

basic_centos7_priv…ターゲットのコンテナ名称

image_centos7_basic_priv_202207XX…作成するイメージにつける名前

・イメージの確認

# docker image list

REPOSITORY                                                         TAG       IMAGE ID       CREATED         SIZE

image_centos7_basic_priv_202207XX                                  latest    xxxxxxxxxxxx   9 seconds ago   648MB

◯　作成したイメージからコンテナを始動する方法（Dockerホストにおいて）

・作成したイメージを指定してコンテナの始動

　今回作成したイメージは特権で動作するコンテナのものなので、privilegedを付ける必要がある。また、冒頭のコンテナ作成手順の通り、initから起動する必要がある。

# docker run --privileged -d --net MYNETWORK --dns 192.168.1.1 --name newcontainer_centos7_priv image_centos7_basic_priv_202207XX /sbin/init

　パラメーターの意味は、冒頭のコンテナ作成手順と同じ。

・始動したコンテナに接続する

# docker exec -it ldap_centos7_priv /bin/bash 

[root@819dfc82f27a /]#

以上

＜参考＞

・6.50. IPRoute2-3.5.1

< http://linuxjf.osdn.jp/JFdocs/LFS-BOOK/chapter06/iproute2.html > 2022年7月4日

【Linux CentOS 7】ソースからOpenSSL（1.1.1m）を導入する手順【Dockerコンテナ】

　CentOS7の標準リポジトリが提供するOpenSSLは、次のコマンド結果が示すように、バージョン1.0.2kである。

# yum info openssl

Available Packages

Name        : openssl

Arch        : x86_64

Epoch       : 1

Version     : 1.0.2k

Release     : 24.el7_9

Size        : 494 k

Repo        : updates/7/x86_64

Summary     : Utilities from the general purpose cryptography library with TLS implementation

URL         : http://www.openssl.org/

License     : OpenSSL

Description : The OpenSSL toolkit provides support for secure communications between

            : machines. OpenSSL includes a certificate management tool and shared

            : libraries which provide various cryptographic algorithms and

            : protocols.

　そのため依存関係によりインストールできないソフトウェアがあった。

そこで、次のようにして、ソースからOpenSSL（1.1.1m）を導入した。

　以下で使用しているCentOS7は、特権Dockerコンテナで動作させている。

■Dockerコンテナの起動と接続

◯基本となるDockerコンテナを起動した。

　Dockerの基本イメージとして、「centos:centos7」を用いた。

ここでは構築済みDockerネットワーク「test_net 」を用いている。

このDockerネットワークの構築においてインターネット側から接続できないように留意した。

（Dockerネットワークを構築しない場合は、ホストからコンテナへのポートフォワーディングの指定がコンテナ起動コマンドで必要である。その場合、ホストがインターネットに直接に接続されていれば、デフォルトでインターネット側からコンテナへのアクセスを許してしまうので危険である。）

また、systemctlでサービスをコントロールしたいので、このコンテナには特権「--privileged」を与えて起動した。

コンテナの名称は「centos7-ssl_111」とした。

# docker run --privileged -d --net test_net --name centos7-ssl_111 centos:centos7 /sbin/init

◯起動したDockerコンテナに接続した。

# docker exec -it centos7-ssl_111 /bin/bash

[root@55873d35c547 /]#

Dockerコンテナに接続できたので以下では目的に応じた設定を行っていく。

■起動したDockerコンテナにおける基本設定を行った。

◯タイムゾーンをTokyoに設定した。

[root@55873d35c547 /]# ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

◯日本語ローケールを含むその他ロケールを利用できるように設定した。

・次の箇所のコメントアウト

[root@26ab42862322 /]# vi /etc/yum.conf

#override_install_langs=en_US.utf8

・yumによるアップデート

[root@55873d35c547 /]#yum update

・アップデート後にコンテナを一旦終了させた。

[root@55873d35c547 /]# poweroff

・再びコンテナを起動した。

# docker start centos7-ssl_111

・コンテナに再び接続した。

# docker exec -it centos7-ssl_111 /bin/bash

■openssl（1.1.1m）のコンパイルとインストールを行った。

◯コンパイル作業等で必要なパッケージを導入した。

[root@55873d35c547 /]#yum install make gcc perl-core pcre-devel wget zlib-devel

◯適当なディレクトリに、openssl（1.1.1m）のソースファイルをダウンロードし展開した。

・openssl-1.1.1m.tar.gzというファイルを記述のサイトからダウンロードした。

[root@55873d35c547 openssl]# wget https://ftp.openssl.org/source/openssl-1.1.1m.tar.gz

（1.1.1nは、https://ftp.openssl.org/source/openssl-1.1.1n.tar.gz）

・圧縮ファイルを展開した。

[root@55873d35c547 openssl]# tar zxvf openssl-1.1.1m.tar.gz

◯コンパイルとインストール作業を行った。

・展開されたソースファイルのあるディレクトリに移動した。

[root@55873d35c547 openssl]# cd openssl-1.1.1m

[root@7eeb5543f134 openssl-1.1.1m]# ./config --prefix=/usr --openssldir=/etc/ssl --libdir=lib shared

[root@55873d35c547 openssl-1.1.1m]# ./config shared

Operating system: x86_64-whatever-linux2

Configuring OpenSSL version 1.1.1m (0x101010dfL) for linux-x86_64

Using os-specific seed configuration

Creating configdata.pm

Creating Makefile

**********************************************************************

***                                                                ***

***   OpenSSL has been successfully configured                     ***

***                                                                ***

***   If you encounter a problem while building, please open an    ***

***   issue on GitHub <https://github.com/openssl/openssl/issues>  ***

***   and include the output from the following command:           ***

***                                                                ***

***       perl configdata.pm --dump                                ***

***                                                                ***

***   (If you are new to OpenSSL, you might want to consult the    ***

***   'Troubleshooting' section in the INSTALL file first)         ***

***                                                                ***

**********************************************************************

[root@55873d35c547 openssl-1.1.1m]# make

[root@55873d35c547 openssl-1.1.1m]# make test

（進捗の一部のみ抜粋　以下の行以外は... okと表示された。）

../test/recipes/05-test_md2.t ...................... skipped: md2 is not supported by this OpenSSL build

../test/recipes/05-test_rc5.t ...................... skipped: rc5 is not supported by this OpenSSL build

../test/recipes/30-test_afalg.t .................... skipped: test_afalg not supported for this build

../test/recipes/90-test_gost.t ..................... skipped: No test GOST engine found

../test/recipes/90-test_overhead.t ................. skipped: Only supported in no-shared builds

../test/recipes/95-test_external_boringssl.t ....... skipped: No external tests in this configuration

../test/recipes/95-test_external_krb5.t ............ skipped: No external tests in this configuration

../test/recipes/95-test_external_pyca.t ............ skipped: No external tests in this configuration

（最終結果）

All tests successful.

Files=158, Tests=2637, 111 wallclock secs ( 1.83 usr  0.19 sys + 85.76 cusr 31.99 csys = 119.77 CPU)

Result: PASS

make[1]: Leaving directory `/root/software/openssl/openssl-1.1.1m'

[root@55873d35c547 openssl-1.1.1m]# make install

◯共有ライブラリへのリンクを設定

１、インストール直後だと、次のエラーが発生した。

[root@55873d35c547 openssl-1.1.1m]# openssl version

openssl: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

このエラーに基づき、指定された共有ライブラリへのリンクを作成した。

[root@55873d35c547 openssl-1.1.1m]# ln -s /usr/local/lib64/libssl.so.1.1 /usr/lib64/

２、さらに次のエラーが発生した。

[root@55873d35c547 openssl-1.1.1m]# openssl version

openssl: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory

このエラーに基づき、指定された共有ライブラリへのリンクを作成した。

[root@55873d35c547 openssl-1.1.1m]# ln -s /usr/local/lib64/libcrypto.so.1.1 /usr/lib64/

以上で、エラーなくopensslのバージョン表示を確認できた。

[root@55873d35c547 openssl-1.1.1m]# openssl version

OpenSSL 1.1.1m  14 Dec 2021

以上で、openssl 1.1.1mのインストールが完了した。

◯インストールされた場所の確認

以下のように、「/usr/local」内にインストールされた。

これはOS標準外のソフトウェアとして扱うということである。

[root@55873d35c547 openssl-1.1.1m]# which openssl

/usr/local/bin/openssl

[root@55873d35c547 openssl-1.1.1m]# ls /usr/local/ssl/

certs  ct_log_list.cnf  ct_log_list.cnf.dist  misc  openssl.cnf  openssl.cnf.dist  private

（必要に応じて、次の設定も行う。）

■SSHをインストールして、リモートアクセスできるようにした。

◯パッケージのインストール

[root@55873d35c547 openssl-1.1.1m]# yum install openssh-server

Installed:

  openssh-server.x86_64 0:7.4p1-22.el7_9                                                                                                                                 

Dependency Installed:

  fipscheck.x86_64 0:1.4.1-6.el7         fipscheck-lib.x86_64 0:1.4.1-6.el7         openssh.x86_64 0:7.4p1-22.el7_9         tcp_wrappers-libs.x86_64 0:7.6-77.el7        

Complete!

◯サービスの開始

[root@55873d35c547 openssl-1.1.1m]# systemctl start sshd

[root@55873d35c547 openssl-1.1.1m]# systemctl status sshd

● sshd.service - OpenSSH server daemon

   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)

   Active: active (running) since Sat 2022-03-05 02:23:55 JST; 4s ago

     Docs: man:sshd(8)

           man:sshd_config(5)

 Main PID: 3779 (sshd)

   CGroup: /docker/55873d35c547090da8d057c2f025ef59c6b35c4970117d56fae9df422ea13704/system.slice/sshd.service

           └─3779 /usr/sbin/sshd -D

           ‣ 3779 /usr/sbin/sshd -D

Mar 05 02:23:55 55873d35c547 systemd[1]: Starting OpenSSH server daemon...

Mar 05 02:23:55 55873d35c547 sshd[3779]: Server listening on 0.0.0.0 port 22.

Mar 05 02:23:55 55873d35c547 sshd[3779]: Server listening on :: port 22.

Mar 05 02:23:55 55873d35c547 systemd[1]: Started OpenSSH server daemon.

◯サービスの自動起動を設定

[root@55873d35c547 openssl-1.1.1m]# systemctl enable sshd

以上

＜参考＞

（インストール方法について）

・How To Install OpenSSL 1.1.1 on CentOS 7

< https://gist.github.com/fernandoaleman/5459173e24d59b45ae2cfc618e20fe06 > 2022年3月5日

・Upgrade centos7 openssh to the latest version

< https://developpaper.com/upgrade-centos7-openssh-to-the-latest-version/ > 2022年3月5日

（その他）

・ダイナミックリンクとスタティックリンク

< https://atmarkit.itmedia.co.jp/ait/articles/1105/27/news111.html > 2022年3月5日

・Linuxで共有ライブラリの作成とダイナミックリンクをする方法

< https://www.koikikukan.com/archives/2016/10/27-000300.php > 2022年3月5日

・configureの設定を変更してみる

< https://atmarkit.itmedia.co.jp/ait/articles/1107/01/news139.html > 2022年3月5日

・OpenSSH / Installation instructions

< https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/INSTALL > 2022年3月5日

・8.48. OpenSSL-1.1.1k

< http://lfsbookja.osdn.jp/svn-sysdja/chapter08/openssl.html > 2022年3月5日

・OpenSSL 1.1. does not honor --libdir #5398

< https://github.com/openssl/openssl/issues/5398 > 2022年3月5日

・When do I need zlib in OpenSSL?

< https://stackoverflow.com/questions/23772816/when-do-i-need-zlib-in-openssl > 2022年3月5日

【Linux RaspiOS bullseye】Log2Ramを利用してログの記録先（/var/log）をRAM領域に変更した【log2ram 1.6.1】

　Raspberry pi 4 (4GB)に、Raspberry pi OS（32bit）を導入した。

OSのバージョンは、2021-10-30-raspios-bullseye-armhf-lite である。

通常通り、microSDを使用している。

次のページに記載の手順でシステムを準備した。

http://akira-arets.blogspot.com/2019/10/raspberry-pi-4-initial-setup-raspbian.html

　このRaspberry piによるシステムの運用に際して、SDカードの書き込み寿命が気になった。

いくら耐久性の高いカードを用いたとしても、刻々とログが書き込まれることを考えると、不安である。

　そこで、「/var/log」のパーティションとしてRAM領域が使用されるようにした。

これを実現する方法として、「Log2Ram」というパッケージを用いることにした。

　１、Log2Ramは、システム起動時に自動的に動作して、SDに保存されている「/var/log」の内容を、確保したRAM領域に保存し「/var/log」にマウントしなおす。

　２、以後、システムのログシステムはRAM領域にログを刻むことになる。

　３、システムの終了時や、Log2Ramの終了時、設定で指定したタイミングで、それまでRAM領域に保存されていた内容は、SDに保存され永続化される。

　このようなライフサイクルを繰り返す。

　

　以下はこの「Log2Ram」の導入手順と動作テストについて記述してある。

■　rootユーザーに切り替えた。

root@raspberrypi:/home/pi#  su

■　Log2Ramのインストール

◯リポジトリの設定

# echo "deb [signed-by=/usr/share/keyrings/azlux-archive-keyring.gpg] http://packages.azlux.fr/debian/ bullseye main" | sudo tee /etc/apt/sources.list.d/azlux.list

deb [signed-by=/usr/share/keyrings/azlux-archive-keyring.gpg] http://packages.azlux.fr/debian/ bullseye main

# wget -O /usr/share/keyrings/azlux-archive-keyring.gpg  https://azlux.fr/repo.gpg

(10.7 MB/s) - '/usr/share/keyrings/azlux-archive-keyring.gpg' saved [2255/2255]

◯パッケージのインストール

上記で設定したリポジトリからパッケージを導入する。

# apt update

Get:1 http://archive.raspberrypi.org/debian bullseye InRelease [23.5 kB]                                                                             

Get:2 http://raspbian.raspberrypi.org/raspbian bullseye InRelease [15.0 kB]                                                                          

Get:3 http://packages.azlux.fr/debian bullseye InRelease [3988 B]                         

Get:4 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages [13.2 MB]

Get:5 http://archive.raspberrypi.org/debian bullseye/main armhf Packages [249 kB]

Get:6 http://packages.azlux.fr/debian bullseye/main armhf Packages [3427 B]             

Fetched 13.5 MB in 10s (1384 kB/s)                                                                                                                                      

Reading package lists... Done

Building dependency tree... Done

Reading state information... Done

1 package can be upgraded. Run 'apt list --upgradable' to see it.

# apt install log2ram

The following NEW packages will be installed:               

  log2ram

0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.

Need to get 4204 B of archives.

After this operation, 0 B of additional disk space will be used.

Get:1 http://packages.azlux.fr/debian bullseye/main armhf log2ram all 1.6.1 [4204 B]

＜略＞

Unpacking log2ram (1.6.1) ...

Setting up log2ram (1.6.1) ...

Created symlink /etc/systemd/system/sysinit.target.wants/log2ram.service → /etc/systemd/system/log2ram.service.

Created symlink /etc/systemd/system/timers.target.wants/log2ram-daily.timer → /etc/systemd/system/log2ram-daily.timer.

#####         Reboot to activate log2ram         #####

##### edit /etc/log2ram.conf to configure options ####

■Log2Ramの設定

◯サービスが有効になっているか確認した。

# systemctl is-enabled log2ram

enabled

◯Log2Ramが使用するRAMの容量を設定した。

　次のduコマンドの結果から、/var/logのサイズが、109MBだとわかった。

これはほとんど、 /var/log/journal　が占めている容量である。

# du /var/log -h

4.0K    /var/log/runit/ssh

8.0K    /var/log/runit

152K    /var/log/apt

4.0K    /var/log/private

105M    /var/log/journal/********************************

105M    /var/log/journal

4.0K    /var/log/asterisk/cdr-csv

4.0K    /var/log/asterisk/cdr-custom

24K     /var/log/asterisk

109M    /var/log

そのため、この現状に合わせて次のように確保容量を次のように再設定した。

# nano /etc/log2ram.conf

（関係する部分のみ抜粋）

# Size for the ram folder, it defines the size the log folder will reserve into the RAM.

# If it's not enough, log2ram will not be able to use ram. Check you /var/log size folder.

# The default is 40M and is basically enough for a lot of applications.

# You will need to increase it if you have a server and a lot of log for example.

SIZE=150M

　これに関して、後でわかったことだが、/var/logよりもRamの確保容量が小さい場合、次のエラーが発生してLog2Ramは動作しなかった。

log2ram[299]: ERROR: RAM disk for "/var/hdd.log/" too small. Can't sync.

◯RamDiskからSDカードへの「定期的」な書き戻しは行わないようにした。

　これを設定すると、突然の電源遮断によりログがごっそりと消滅してしまう危険がある。

そのため、この設定は必要に応じて行うべきである。

# systemctl disable log2ram-daily.timer

Removed /etc/systemd/system/timers.target.wants/log2ram-daily.timer

　以上で基本的な設定は完了した。

　（他にも有用な設定があるので、参考サイトを参照してください。）

　後は、システムを再起動するか、log2ramをsystemctlでstartするだけで、Log2Ramは機能する。

■　Log2Ramの動作確認

◯Log2Ramの動作前後でのdfコマンドの結果の違いを確認した。

　再起動前、Log2Ramが動作する前は次のような状態だった。

# df -h

（Log2Ramが動作する前の状態）

Filesystem      Size  Used Avail Use% Mounted on

/dev/root        29G  1.5G   27G   6% /

devtmpfs        1.8G     0  1.8G   0% /dev

tmpfs           1.9G     0  1.9G   0% /dev/shm

tmpfs           768M  1.1M  767M   1% /run

tmpfs           5.0M  4.0K  5.0M   1% /run/lock

/dev/mmcblk0p1  253M   49M  204M  20% /boot

tmpfs           384M     0  384M   0% /run/user/1000

・システムの再起動

# reboot

　再起動後、Log2Ramは動作することになる。

　そして先程と同様に、dfコマンドの結果を確認した。

# df -h

（Log2Ramの動作後の状態）

Filesystem      Size  Used Avail Use% Mounted on

/dev/root        29G  1.5G   27G   6% /

devtmpfs        1.8G     0  1.8G   0% /dev

tmpfs           1.9G     0  1.9G   0% /dev/shm

tmpfs           768M  1.1M  767M   1% /run

tmpfs           5.0M  4.0K  5.0M   1% /run/lock

/dev/mmcblk0p1  253M   49M  204M  20% /boot

log2ram         150M   22M  129M  15% /var/log

tmpfs           384M     0  384M   0% /run/user/1000

　log2ramの領域として、指定したとおり150MBが確保され、/var/logにマウントされていた。

そのうち、22MBが使用されていることがわかった。

（ところで、初めに、/var/logは109MB専有していたのに、log2ramが動作後は、22MBに急減したのか。これについては後で考察した。）

　Log2Ramが動作していることは次のコマンドの結果からも確認できた。

# mount

一部のみ抜粋

log2ram on /var/log type tmpfs (rw,nosuid,nodev,noexec,noatime,size=153600k,mode=755)

tmpfsが使用されていることがわかった。

■　journaldの動作について

　少し上のところで疑問が生じたように、Log2Ramの動作前後で、/var/logの使用容量が109MBから22MBに急減したのか。

　/var/logが占めている容量について、Log2Ramの動作前後で確認したものを再掲する。

# du /var/log -h

（Log2Ramの動作前）

4.0K    /var/log/runit/ssh

8.0K    /var/log/runit

152K    /var/log/apt

4.0K    /var/log/private

105M    /var/log/journal/********************************

105M    /var/log/journal

4.0K    /var/log/asterisk/cdr-csv

4.0K    /var/log/asterisk/cdr-custom

24K     /var/log/asterisk

109M    /var/log

# du /var/log -h

（Log2Ramの動作後）

0 /var/log/runit/ssh

0 /var/log/runit

0 /var/log/private

16M /var/log/journal/********************************

16M /var/log/journal

0 /var/log/asterisk/cdr-custom

0 /var/log/asterisk/cdr-csv

16K /var/log/asterisk

144K /var/log/apt

22M /var/log

　このように、/var/log/journal　の占める領域が、105MBだったのが16MBばかりに減ったことがわかる。

　/var/log/journalは、journaldが全てのログを刻々とバイナリ保存している場所である。

journaldは、保存先ディレクトリのディスク空き容量の一部のみを使用するように制御されている。

 別のディストリビューションのArchLinuxの場合は、/var/log/journalのあるパーティションの10%だけが使用されるらしい。

◯そこで、次のように実験してみた。

　今、次のように、/var/log/journal/　が占める容量は約26MBである。

root@raspberrypi:/home/pi# du /var/log -h

4.0K /var/log/runit/ssh

8.0K /var/log/runit

152K /var/log/apt

4.0K /var/log/private

26M /var/log/journal/********************************

26M /var/log/journal

4.0K /var/log/asterisk/cdr-csv

4.0K /var/log/asterisk/cdr-custom

68K /var/log/asterisk

36M /var/log

これは、次のコマンドを使ってもわかる。

root@raspberrypi:/home/pi# journalctl --disk-usage

Archived and active journals take up 25.5M in the file system.

　次に、Log2Ramが確保するRAM容量を、50MBに減らした。

これによって、journaldが使用できる容量は制限される。

root@raspberrypi:/home/pi# nano /etc/log2ram.conf

（関係する部分のみ表示）

SIZE=50M

　ここで、システムを再起動し、Log2Ram、journaldを再起動した。

root@raspberrypi:/home/pi# reboot

　再起動後、次のように、Log2Ramが確保した50MB領域が/var/logにマウントされていることを確認した。

root@raspberrypi:/home/pi# df -h

Filesystem      Size  Used Avail Use% Mounted on

/dev/root        29G  1.5G   27G   6% /

devtmpfs        1.8G     0  1.8G   0% /dev

tmpfs           1.9G     0  1.9G   0% /dev/shm

tmpfs           768M  1.1M  767M   1% /run

tmpfs           5.0M  4.0K  5.0M   1% /run/lock

/dev/mmcblk0p1  253M   49M  204M  20% /boot

log2ram          50M   24M   27M  48% /var/log

tmpfs           384M     0  384M   0% /run/user/1000

　そして、journaldによるログサイズを確認した。

25MBだったものが、13.6MBにまで減っていた。

root@raspberrypi:/home/pi# journalctl --disk-usage

Archived and active journals take up 13.6M in the file system.

　これは、duコマンドの内容と一致した。

root@raspberrypi:/home/pi# du /var/log -h

0 /var/log/runit/ssh

0 /var/log/runit

0 /var/log/private

14M /var/log/journal/********************************

14M /var/log/journal

0 /var/log/asterisk/cdr-custom

0 /var/log/asterisk/cdr-csv

56K /var/log/asterisk

144K /var/log/apt

24M /var/log

　このように、/var/logの空き容量によって、journaldが使用できる容量が変化することがわかかった。

　Log2Ramを導入する前は、/var/logはルートディレクトリと同じパーティションにあったため、より多くの領域を使用することができた。

そのため、最初に示したとおり、/var/log/journalは、105MBもの容量を専有できていた。

　しかし、Log2Ramを導入した後は、RAM領域の150MBのみが/var/log/にマウントされたため、journaldが使用できるディスク容量は急減し、/var/log/journalが占める容量は105MBから16MBまで小さくされたと考えられる。journaldがこれら削減の作業を行ったと考えられる。

＜参考＞

◆「Log2Ramについて」

・azlux/log2ram

< https://github.com/azlux/log2ram >  2022年2月11日

・How To Write Log Files In RAM Using Log2ram In Linux

< https://ostechnix.com/how-to-write-log-files-in-ram-using-log2ram-in-linux/ > 2022年2月10日

・Using Log2RAM on the Raspberry Pi

< https://pimylifeup.com/raspberry-pi-log2ram/ > 2022年2月10日

・How log2ram works.

< https://linuxfun.org/en/2021/01/01/what-log2ram-does-en/ > 2022年2月10日

・Log2Ram: Extending SD Card Lifetime for Raspberry Pi LoRaWAN Gateway

< https://mcuoneclipse.com/2019/04/01/log2ram-extending-sd-card-lifetime-for-raspberry-pi-lorawan-gateway/ > 2022年2月10日

・Improve system performance by moving your log files to RAM Using Ramlog

< http://www.ubuntugeek.com/improve-system-performance-by-moving-your-log-files-to-ram-using-ramlog.html > 2022年2月10日

◆「 systemd journalについて」

・A Guide to systemd journal Maintenance [With Examples]

< https://www.debugpoint.com/2021/01/systemd-journald-clean/ > 2022年2月12日

・Arch Linux - journalctl ログの最大サイズを設定

< https://b.fugenjikko.com/archlinux/archlinux-journal-maxsize > 2022年2月12日

・CentOS 7のログ管理「journald」

< https://thinkit.co.jp/story/2014/12/18/5389?page=0%2C1 > 2022年2月12日

◆「tmpfsについて」

・Linux豆知識 111 / tmpfs

< https://linuc.org/study/knowledge/441/ > 2022年2月12日