My Blog

Category: Linux関連

  • DokuwikiをPHP8対応に更新

    Centos7上で、ローカル向けのwikiページ作成ツールとしてdokuwiki＋php7.4を使用していた。
    php7.4　のサポートが2022/11/28　で終了したので、セキュリティ保持の為にphp8.*　へバージョンアップした。健忘禄としてメモを残す。
    （外部に公開している訳では無いので、ほとんど自己満足ですが）

    ＜現在のphp　バージョンの確認＞
    # yum list installed php*

    読み込んだプラグイン:fastestmirror
    Loading mirror speeds from cached hostfile
    * base: download.nus.edu.sg
    　省略
    インストール済みパッケージ
    php.x86_64 7.4.33-2.el7.remi @remi-php74
    php-cli.x86_64 7.4.33-2.el7.remi @remi-php74
    php-common.x86_64 7.4.33-2.el7.remi @remi-php74
    php-json.x86_64 7.4.33-2.el7.remi @remi-php74
    php-mbstring.x86_64 7.4.33-2.el7.remi @remi-php74
    php-pecl-zip.x86_64 1.21.1-1.el7.remi.7.4 @remi-php74
    php-sodium.x86_64 7.4.33-2.el7.remi @remi-php74
    php-xml.x86_64 7.4.33-2.el7.remi @remi-php74
    #

    ＜事前準備　現状の保全等＞
    # cp -p /etc/php.ini /etc/php.ini-20230123

    # cp -p -r /var/www /var/www-20230124BK

    ＜dokuwiki　をバージョンアップする＞
    ワーク用のディレクトリで解凍する。

    # tar xvfz dokuwiki-a6b3119b5d16cfdee29a855275c5759f.tgz
    dokuwiki/.htaccess.dist
    dokuwiki/COPYING
    dokuwiki/README
    dokuwiki/SECURITY.md

    ファイルを上書きする
    # \cp -f -r -p ./* /var/www/html/dokuwiki/

    パーミッションを戻す
    # chown -R apache dokuwiki
    # chgrp -R apache dokuwiki

    ＜phpを更新　バージョンアップ＞
    7.4系を削除する

    # php -v
    PHP 7.4.33 (cli) (built: Dec 19 2022 13:32:43) ( NTS )
    Copyright (c) The PHP Group
    Zend Engine v3.4.0, Copyright (c) Zend Technologies

    # yum remove “php*”
    読み込んだプラグイン:fastestmirror
    依存性の解決をしています
    –> トランザクションの確認を実行しています。
    —> パッケージ php.x86_64 0:7.4.33-2.el7.remi を 削除

    途中省略

    トランザクションの要約

    削除 7 パッケージ

    インストール容量: 42 M
    上記の処理を行います。よろしいでしょうか？ [y/N]y
    Downloading packages:
    Running transaction check

    　以下省略

    # php -v
    -bash: /bin/php: そのようなファイルやディレクトリはありません

    # yum -y install –enablerepo=epel,remi,remi-php82 php php-cli php-common php-json php-mbstring php-pecl-zip php-sodium php-xml

    読み込んだプラグイン:fastestmirror

    Loading mirror speeds from cached hostfile

    • base: download.nus.edu.sg
    • epel: epel.mirror.angkasa.id
    • extras: download.nus.edu.sg
    • remi: fr2.rpmfind.net
    • remi-php74: fr2.rpmfind.net
    • remi-php82: fr2.rpmfind.net
    • remi-safe: fr2.rpmfind.net
    • updates: download.nus.edu.sg
      remi | 3.0 kB 00:00:00
      remi-php82 | 3.0 kB 00:00:00
      (1/2): remi-php82/primary_db | 168 kB 00:00:00
      (2/2): remi/primary_db | 3.4 MB 00:00:01
      パッケージ php-json は php-common によって不要になりました。代わりに php-common-8.2.1-1.el7.remi.x86_64 のインストールを試みています。
      依存性の解決をしています
      –> トランザクションの確認を実行しています。
      —> パッケージ php.x86_64 0:8.2.1-1.el7.remi を インストール
      —> パッケージ php-cli.x86_64 0:7.4.33-2.el7.remi を 更新
      —> パッケージ php-cli.x86_64 0:8.2.1-1.el7.remi を アップデート
      —> パッケージ php-common.x86_64 0:7.4.33-2.el7.remi を 更新
      —> パッケージ php-common.x86_64 0:8.2.1-1.el7.remi を 非推奨
      —> パッケージ php-json.x86_64 0:7.4.33-2.el7.remi を 不要
      —> パッケージ php-mbstring.x86_64 0:7.4.33-2.el7.remi を 更新
      —> パッケージ php-mbstring.x86_64 0:8.2.1-1.el7.remi を アップデート
      —> パッケージ php-pecl-zip.x86_64 0:1.21.1-1.el7.remi.7.4 を 更新
      —> パッケージ php-pecl-zip.x86_64 0:1.21.1-1.el7.remi.8.2 を アップデート
      —> パッケージ php-sodium.x86_64 0:7.4.33-2.el7.remi を 更新
      —> パッケージ php-sodium.x86_64 0:8.2.1-1.el7.remi を アップデート
      —> パッケージ php-xml.x86_64 0:7.4.33-2.el7.remi を 更新
      —> パッケージ php-xml.x86_64 0:8.2.1-1.el7.remi を アップデート
      –> 依存性解決を終了しました。

    依存性を解決しました

    ====================================================================================================
    Package アーキテクチャー バージョン リポジトリー 容量

    インストール中:
    php x86_64 8.2.1-1.el7.remi remi-php82 2.0 M
    php-common x86_64 8.2.1-1.el7.remi remi-php82 1.2 M
    php-json.x86_64 7.4.33-2.el7.remi を入れ替えます
    更新します:
    php-cli x86_64 8.2.1-1.el7.remi remi-php82 6.0 M
    php-mbstring x86_64 8.2.1-1.el7.remi remi-php82 573 k
    php-pecl-zip x86_64 1.21.1-1.el7.remi.8.2 remi-php82 70 k
    php-sodium x86_64 8.2.1-1.el7.remi remi-php82 97 k
    php-xml x86_64 8.2.1-1.el7.remi remi-php82 238 k
    トランザクションの要約

    インストール 2 パッケージ
    更新 5 パッケージ

    総ダウンロード容量: 10 M
    Downloading packages:
    Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
    (1/7): php-8.2.1-1.el7.remi.x86_64.rpm | 2.0 MB 00:00:00
    (2/7): php-common-8.2.1-1.el7.remi.x86_64.rpm | 1.2 MB 00:00:00
    (3/7): php-mbstring-8.2.1-1.el7.remi.x86_64.rpm | 573 kB 00:00:00
    (4/7): php-pecl-zip-1.21.1-1.el7.remi.8.2.x86_64.rpm | 70 kB 00:00:00
    (5/7): php-sodium-8.2.1-1.el7.remi.x86_64.rpm | 97 kB 00:00:00
    (6/7): php-xml-8.2.1-1.el7.remi.x86_64.rpm | 238 kB 00:00:00
    (7/7): php-cli-8.2.1-1.el7.remi.x86_64.rpm | 6.0 MB 00:00:01

    合計 7.8 MB/s | 10 MB 00:00:01
    Running transaction check
    Running transaction test
    　以下省略

    # php -v
    PHP 8.2.1 (cli) (built: Jan 3 2023 18:40:55) (NTS gcc x86_64)
    Copyright (c) The PHP Group
    Zend Engine v4.2.1, Copyright (c) Zend Technologies

    ＜動作確認＞
    ・マシンをreboot　する。
    ・dokuwiki　の動作を確認する。

    ＜その他＞
    ・作業時には関連するサービス（Apacheとかetc）を事前に停止する事。その手順等の記載は省略している。
    ・管理機能を有効にしているなら（プラグインの設定をコントロール出来るなら）、dokuwiki　はアップデートのプラグインが提供されているので、これの利用がお勧め。リスクが少ないので。
    　今回は、3面の環境を同居させている環境（ちょっと変な事をしている）なので、プラグインではうまく更新が出来ない（一部が更新されない）ので、上書きした。
    ・php8.*系に対応していない（dokuwiki　側が）場合のエラーは以下。

    [Tue Jan 24 16:57:37.602483 2023] [php:error] [pid 1604] [client 172.16.11.11:58467] PHP Fatal erro
    r: Array and string offset access syntax with curly braces is no longer supported in /var/www/html
    /dokuwiki1/inc/init.php on line 557

    ・現状で、ワーニングが結構記録される（Apahce　のエラーLogに）が未調査（取り敢えず動いているので）

    PHP再インストール　　２０２３０８２９追記

    yum　を使用してのアップデート時、エラーとなるようになったので、ｐｈｐを再インストールした。
    （リポジトリが壊れた事が原因みたいだが、面倒なので再インストール）

    ＜ワーニングの内容＞

    –> トランザクションの確認を実行しています。
    —> パッケージ libzip5.x86_64 0:1.9.2-3.el7.remi を 更新
    —> パッケージ libzip5.x86_64 0:1.10.1-1.el7.remi を アップデート
    —> パッケージ microcode_ctl.x86_64 2:2.1-73.15.el7_9 を 更新
    —> パッケージ microcode_ctl.x86_64 2:2.1-73.16.el7_9 を アップデート
    —> パッケージ php-pecl-zip.x86_64 0:1.21.1-1.el7.remi.8.2 を 更新
    —> パッケージ php-pecl-zip.x86_64 0:1.22.2-1.el7.remi.7.4 を アップデート
    –> 依存性の処理をしています: php(api) = 20190902-64 のパッケージ: php-pecl-zip-1.22.2-1.el7.remi.7.4.x86_64
    –> 依存性の処理をしています: php(zend-abi) = 20190902-64 のパッケージ: php-pecl-zip-1.22.2-1.el7.remi.7.4.x86_64
    –> 依存性解決を終了しました。
    エラー: パッケージ: php-pecl-zip-1.22.2-1.el7.remi.7.4.x86_64 (remi-php74)
    要求: php(api) = 20190902-64
    インストール: php-common-8.2.1-1.el7.remi.x86_64 (@remi-php82)
    php(api) = 20220829-64
    利用可能: php-common-5.4.16-48.el7.x86_64 (base)
    php(api) = 20100412-64
    利用可能: php-common-7.4.33-7.el7.remi.x86_64 (remi-php74)
    php(api) = 20190902-64
    利用可能: php-common-7.4.33-8.el7.remi.x86_64 (remi-php74)
    php(api) = 20190902-64
    エラー: パッケージ: php-pecl-zip-1.22.2-1.el7.remi.7.4.x86_64 (remi-php74)
    要求: php(zend-abi) = 20190902-64
    インストール: php-common-8.2.1-1.el7.remi.x86_64 (@remi-php82)
    php(zend-abi) = 20220829-64
    利用可能: php-common-5.4.16-48.el7.x86_64 (base)
    php(zend-abi) = 20100525-64
    利用可能: php-common-7.4.33-7.el7.remi.x86_64 (remi-php74)
    php(zend-abi) = 20190902-64
    利用可能: php-common-7.4.33-8.el7.remi.x86_64 (remi-php74)
    php(zend-abi) = 20190902-64
    問題を回避するために –skip-broken を用いることができます。
    これらを試行できます: rpm -Va –nofiles –nodigest

    ＜事前準備＞

    cp -p php.ini php.ini-20230829

    cp -p -r www/ www www-20230829BK

    systemctl stop httpd

    ＜ｐｈｐの再インストール＞

    # yum list installed php*

    base: ftp-srv2.kddilabs.jp

    epel: mirror.earthlink.iq

    extras: ftp-srv2.kddilabs.jp

    remi-php74: fr2.rpmfind.net

    remi-safe: fr2.rpmfind.net

    updates: ftp-srv2.kddilabs.jp
    インストール済みパッケージ
    php.x86_64 8.2.1-1.el7.remi @remi-php82
    php-cli.x86_64 8.2.1-1.el7.remi @remi-php82
    php-common.x86_64 8.2.1-1.el7.remi @remi-php82
    php-mbstring.x86_64 8.2.1-1.el7.remi @remi-php82
    php-pecl-zip.x86_64 1.21.1-1.el7.remi.8.2 @remi-php82
    php-sodium.x86_64 8.2.1-1.el7.remi @remi-php82
    php-xml.x86_64 8.2.1-1.el7.remi @remi-php82

    # yum remove “php*”

    読み込んだプラグイン:fastestmirror
    Loading mirror speeds from cached hostfile

    読み込んだプラグイン:fastestmirror
    依存性の解決をしています
    –> トランザクションの確認を実行しています。
    —> パッケージ php.x86_64 0:8.2.1-1.el7.remi を 削除
    —> パッケージ php-cli.x86_64 0:8.2.1-1.el7.remi を 削除
    —> パッケージ php-common.x86_64 0:8.2.1-1.el7.remi を 削除
    —> パッケージ php-mbstring.x86_64 0:8.2.1-1.el7.remi を 削除
    —> パッケージ php-pecl-zip.x86_64 0:1.21.1-1.el7.remi.8.2 を 削除
    —> パッケージ php-sodium.x86_64 0:8.2.1-1.el7.remi を 削除
    —> パッケージ php-xml.x86_64 0:8.2.1-1.el7.remi を 削除
    –> 依存性解決を終了しました。

    依存性を解決しました

    ===================================================================================================
    Package アーキテクチャー

    バージョン リポジトリー 容量

    削除中:
    php x86_64 8.2.1-1.el7.remi @remi-php82 5.8 M
    php-cli x86_64 8.2.1-1.el7.remi @remi-php82 24 M
    php-common x86_64 8.2.1-1.el7.remi @remi-php82 16 M
    php-mbstring x86_64 8.2.1-1.el7.remi @remi-php82 2.3 M
    php-pecl-zip x86_64 1.21.1-1.el7.remi.8.2 @remi-php82 265 k
    php-sodium x86_64 8.2.1-1.el7.remi @remi-php82 228 k
    php-xml x86_64 8.2.1-1.el7.remi @remi-php82 875 k

    トランザクションの要約

    削除 7 パッケージ

    インストール容量: 50 M
    上記の処理を行います。よろしいでしょうか？ [y/N]y
    Downloading packages:
    Running transaction check
    Running transaction test
    Transaction test succeeded
    Running transaction
    削除中 : php-8.2.1-1.el7.remi.x86_64 1/7
    削除中 : php-cli-8.2.1-1.el7.remi.x86_64 2/7
    削除中 : php-sodium-8.2.1-1.el7.remi.x86_64 3/7
    削除中 : php-xml-8.2.1-1.el7.remi.x86_64 4/7
    削除中 : php-pecl-zip-1.21.1-1.el7.remi.8.2.x86_64 5/7
    削除中 : php-mbstring-8.2.1-1.el7.remi.x86_64 6/7
    削除中 : php-common-8.2.1-1.el7.remi.x86_64 7/7
    検証中 : php-mbstring-8.2.1-1.el7.remi.x86_64 1/7
    検証中 : php-8.2.1-1.el7.remi.x86_64 2/7
    検証中 : php-pecl-zip-1.21.1-1.el7.remi.8.2.x86_64 3/7
    検証中 : php-xml-8.2.1-1.el7.remi.x86_64 4/7
    検証中 : php-sodium-8.2.1-1.el7.remi.x86_64 5/7
    検証中 : php-cli-8.2.1-1.el7.remi.x86_64 6/7
    検証中 : php-common-8.2.1-1.el7.remi.x86_64 7/7

    削除しました:
    php.x86_64 0:8.2.1-1.el7.remi php-cli.x86_64 0:8.2.1-1.el7.remi
    php-common.x86_64 0:8.2.1-1.el7.remi php-mbstring.x86_64 0:8.2.1-1.el7.remi
    php-pecl-zip.x86_64 0:1.21.1-1.el7.remi.8.2 php-sodium.x86_64 0:8.2.1-1.el7.remi
    php-xml.x86_64 0:8.2.1-1.el7.remi

    完了しました!

    ]# yum -y install –enablerepo=epel,remi,remi-php82 php php-cli php-common php-m bstring php-pecl-zip php-sodium php-xml
    読み込んだプラグイン:fastestmirror
    Loading mirror speeds from cached hostfile

    • base: ftp-srv2.kddilabs.jp
    • epel: mirror.earthlink.iq
    • extras: ftp-srv2.kddilabs.jp
    • remi: fr2.rpmfind.net
    • remi-php74: fr2.rpmfind.net
    • remi-php82: fr2.rpmfind.net
    • remi-safe: fr2.rpmfind.net
    • updates: ftp-srv2.kddilabs.jp
      remi | 3.0 kB 00:00:00
      remi-php82 | 3.0 kB 00:00:00
      (1/2): remi-php82/primary_db | 199 kB 00:00:00
      (2/2): remi/primary_db 25% [====== ] 0.0 B/s | 1.0 MB –:–:– ETA (2/2): remi/primary_db 60% [=============== ] 1.8 MB/s | 2.3 MB 00:00:00 ETA (2/2): remi/primary_db | 3.6 MB 00:00:01
      依存性の解決をしています
      –> トランザクションの確認を実行しています。
      —> パッケージ php.x86_64 0:8.2.9-2.el7.remi を インストール
      —> パッケージ php-cli.x86_64 0:8.2.9-2.el7.remi を インストール
      —> パッケージ php-common.x86_64 0:8.2.9-2.el7.remi を インストール
      —> パッケージ php-mbstring.x86_64 0:8.2.9-2.el7.remi を インストール
      —> パッケージ php-pecl-zip.x86_64 0:1.22.2-1.el7.remi.8.2 を インストール
      —> パッケージ php-sodium.x86_64 0:8.2.9-2.el7.remi を インストール
      —> パッケージ php-xml.x86_64 0:8.2.9-2.el7.remi を インストール
      –> 依存性解決を終了しました。

    依存性を解決しました

    ===================================================================================================
    Package アーキテクチャー

    バージョン リポジトリー 容量

    インストール中:
    php x86_64 8.2.9-2.el7.remi remi-php82 2.0 M
    php-cli x86_64 8.2.9-2.el7.remi remi-php82 6.1 M
    php-common x86_64 8.2.9-2.el7.remi remi-php82 1.2 M
    php-mbstring x86_64 8.2.9-2.el7.remi remi-php82 578 k
    php-pecl-zip x86_64 1.22.2-1.el7.remi.8.2 remi-php82 71 k
    php-sodium x86_64 8.2.9-2.el7.remi remi-php82 99 k
    php-xml x86_64 8.2.9-2.el7.remi remi-php82 246 k

    トランザクションの要約

    インストール 7 パッケージ

    総ダウンロード容量: 10 M
    インストール容量: 50 M
    Downloading packages:
    (1/7): php-8.2.9-2.el7.remi.x86_64.rpm | 2.0 MB 00:00:00
    (2/7): php-common-8.2.9-2.el7.remi.x86_64.rpm | 1.2 MB 00:00:00
    (4/7): php-mbstring-8.2.9-2.el7.re 42% [==========- ] 0.0 B/s | 4.4 MB –:–:– ETA (3/7): php-mbstring-8.2.9-2.el7.remi.x86_64.rpm | 578 kB 00:00:00
    (4/7): php-pecl-zip-1.22.2-1.el7.remi.8.2.x86_64.rpm | 71 kB 00:00:00
    (5/7): php-sodium-8.2.9-2.el7.remi.x86_64.rpm | 99 kB 00:00:00
    (6/7): php-xml-8.2.9-2.el7.remi.x86_64.rpm | 246 kB 00:00:00

    (7/7): php-cli-8.2.9-2.el7.remi.x8 73% [================== ] 4.3 MB/s | 7.6 MB 00:00:00 ETA (7/7): php-cli-8.2.9-2.el7.remi.x86_64.rpm | 6.1 MB 00:00:00

    合計 10 MB/s | 10 MB 00:00:00
    Running transaction check
    Running transaction test
    Transaction test succeeded
    Running transaction
    インストール中 : php-common-8.2.9-2.el7.remi.x86 [ ] 1/7 インストール中 : php-common-8.2.9-2.el7.remi.x86 [# ]

    　省略


    検証中 : php-common-8.2.9-2.el7.remi.x86_64 1/7
    検証中 : php-sodium-8.2.9-2.el7.remi.x86_64 2/7
    検証中 : php-mbstring-8.2.9-2.el7.remi.x86_64 3/7
    検証中 : php-cli-8.2.9-2.el7.remi.x86_64 4/7
    検証中 : php-pecl-zip-1.22.2-1.el7.remi.8.2.x86_64 5/7
    検証中 : php-8.2.9-2.el7.remi.x86_64 6/7
    検証中 : php-xml-8.2.9-2.el7.remi.x86_64 7/7

    インストール:
    php.x86_64 0:8.2.9-2.el7.remi php-cli.x86_64 0:8.2.9-2.el7.remi
    php-common.x86_64 0:8.2.9-2.el7.remi php-mbstring.x86_64 0:8.2.9-2.el7.remi
    php-pecl-zip.x86_64 0:1.22.2-1.el7.remi.8.2 php-sodium.x86_64 0:8.2.9-2.el7.remi
    php-xml.x86_64 0:8.2.9-2.el7.remi

    完了しました!

    http　を再起動して、動作を確認。OKなら、マシンを再起動して動作を確認。yum　を実行してワーニングが消える事を確認して終了。

  • Bash　の動作時の注意事項

    bash　の動作時の注意事項

    京都大学のスパコンのファイルが大量（77TBらしい）に削除されたことが話題になっている。

    ”bash は、シェルスクリプトの実行中に適時シェルスクリプトを読み込みます。この挙動による副作用を認識できておらず、実行中のスクリプトが存在している状態でスクリプトの上書きによりリリースしてしまったことで、途中から修正したシェルスクリプトの再読み込みが発生”（ネット記事から引用）　が原因として公開されているが、これ、以外とこの動作に対する認識が無い。

    要は、バイナリ等の実行と異なり、実行中でもスクリプトの変更が反映される場合が有る（実行時に逐次最新を読み込んで動くような動作（なので、何処まで実行されているか？によって反映されるかどうがが変わる）をする）事が異なります。

    UNIX系のOSでは、比較的常識ですが、つい忘れる。自戒を込めての投稿です。

    ※：根本的には、顧客の環境でメンテ作業（多分）を実施した時に、最後まで動作を監視していない事が問題。４３時間もファイルが削除され続けた事に気づかないとか有り得ん！（やりがちですけど）

  • samba設定のＴｉｐｓ

    ・設定は以下のファイルで実施する。

    　/etc/samba/smb.conf

    ・F/W　SELinux　については、デフォだと許容されていない。面倒なら一旦止める。

    ・設定したパラメータは、以下のコマンドで記述の正当性確認が出来る。

    　testparm

    　引数とかは不要。ワーニングとか表示されるようなら、設定内容が間違っています。

    　testparm -v ＜－　これでも可。

    ＜設定の詳細：サンプルです＞ ＜－　Ver 4.9 系でのサンプル

    [global]
    unix charset = UTF-8 ＜－　OSのコードセット指定
    dos charset = CP932 ＜－　Windows ファイルの設定。MSの標準を指定（MS-KANJI）

    workgroup = WORKGROUP ＜－　ワークグループの名称を指定（AD等で無い場合） security = user ＜－　セキュリティの方法を指定

    security = user ユーザー名とパスワードでローカル認証を行う設定 security = share パスワードだけで認証を行う設定

    security = domain ドメインコントローラにより認証を行う設定 security = server ほかのSMBサーバにより認証を行う設定 security = ads AD（アクティブディレクトリ）ドメインのドメインコントローラで認証を行う設定

    passdb backend = tdbsam

    assdb backend = tdbsam TDB（Trivial DataBase）を使用する passdb backend = ldapsam LDAPを使用する

    printing = cups

    printcap name = cups

    load printers = yes

    cups options = raw

    hosts allow = 127. 172.16.1.10 ＜－　アクセス対象をIPで絞る場合の指定 map to guest = Bad User ＜－　Sambaユーザとして存在しないユーザのアクセスをゲストアカウントとする指定

    Never 不正なパスワードによるユーザーのログイン要求を拒否する Bad User 不正なパスワードによるユーザーのログイン要求を拒否するが、指定されたユーザーが存在しなかった場合はゲストログインとして扱う。この場合、guest accountで指定したユーザーとなる

    Bad Password 不正なパスワードによるユーザーのログイン要求はゲストユーザーとして扱う。この場合、 guest accountで指定したユーザーとなる

    browseable = No ＜－　個別ユーザの共有領域をブラウジング禁止にする　（これをここに指定しないと、[homes] に指定しても表示される（Samba　の仕様））

    [homes]
    comment = Home Directories
    valid users = %S, %D%w%S
    browseable = No
    read only = No
    inherit acls = Yes

    [printers]
    comment = All Printers
    path = /var/tmp
    printable = Yes
    create mask = 0600
    browseable = No

    [print$]
    comment = Printer Drivers
    path = /var/lib/samba/drivers
    write list = @printadmin root
    force group = @printadmin
    create mask = 0664
    directory mask = 0775

    [Share] ＜－　この指定は実質的に無意味！。デフォで作成されるディレクトリなので、念の為。　（指定しなくても良い）
    path = /home/share
    writable = No
    browseable = No
    valid users = @users
    force create mode = 777
    force directory mode = 777

    [users] ＜－　ユーザ認証での指定例
    path = /home/users
    writable = Yes
    browseable = No
    valid users = @users
    force create mode = 777
    force directory mode = 777

    ＜Samba　のユーザ管理＞

    ※：大前提としてて、OS側にユーザの登録が必要。パスワード等の管理は別となるが、ユーザとしては、存在している必要が有る。
    　（Windowsの場合でも、ユーザ単位でアクセス権を管理しようとすると、ユーザの登録を行う事が前提となる）

    useradd -s /sbin/nologin users ＜－これではNG　グループを指定して設定が必要

    cat passwd | grep users

    users:x:1001:1001::/home/users:/sbin/nologin ＜－グループIDを指定しないので、新規のグループとなる。

    useradd -s /sbin/nologin -g users users ＜－これで指定するか、後で所属グループを変える事

    [root@localhost etc]# pdbedit -a -u users -f “users”
    new password:

    retype new password:
    Unix username: users
    NT username:

    以下省略

    [root@localhost etc]# pdbedit -L
    users:1001:users ＜－　設定されている事を確認する
    [root@localhost etc]#

    [root@localhost etc]# pdbedit -x users ＜－　ユーザの削除
    [root@localhost etc]# pdbedit -L
    [root@localhost etc]#

  • トレンドマイクロ　SPLX　の　KHM　更新

    初めに

    ＣｅｎｔＯＳ７とかＣｅｎｔＯＳ８で、ウイルス対策ソフトとしてトレンドマイクロ社のＳＰＬＸを使用している場合、リアルタイム検索用のモジュール（ＫＨＭ）は、検索エンジンやパターンファイルと異なり、自動で更新されせん。
    yum　等を利用して、ＯＳの更新を実施した場合、カーネルのバージョンが変更されＫＨＭのモジュールがアンマッチとなると、リアルタイム検索が動作しなくなるので、更新が必要となります。

    動作状況の確認

    動作状況の確認は、以下のコマンドで確認するか、管理コンソールで確認します。

    /etc/init.d/splx status

    実行結果

    [root@server init.d]# /etc/init.d/splx status
    splxmod module is running… 　　＜－　これがＫＨＭの動作状況
    vsapiapp (pid 10205) is running…
    entity (pid 10159 10153) is running…
    以下省略

    管理コンソールでの確認

    Scan Status　の項目で

    Real-time Scan: Enabled (Incoming files)

    Enabled と表示されると、動作しています。

    ＫＨＭの更新方法

    ＫＨＭのモジュールは、カーネルとバージョンが一致している必要が有ります。 以下で確認します。

    uname -a

    Linux server 3.10.0-1127.19.1.el7.x86_64 #1 SMP Tue Au ・・・・・

    ls /opt/TrendMicro/SProtectLinux/SPLX.module

    splxmod-3.10.0-1127.19.1.el7.x86_64.x86_64.o
    splxmod-3.10.0-1127.19.1.el7.x86_64.x86_64.o.md5

    上記の確認で一致していない場合は、トレンドマイクロのホームページから、一致するモジュールをダウンロードして配置します。 古いＫＨＭモジュールは、削除する必要は有りません（削除しても良いけど）。

    http://downloadcenter.trendmicro.com/index.php?clk=tbl&clkval=111&regs=NABU&lang_loc=1

    Kernel Support のタブから該当をダウンロードして

    /opt/TrendMicro/SProtectLinux/SPLX.module

    配下へ配置します。

    ＳＰＬＸを停止　－＞　再起動　します。

    /etc/init.d/splx stop

    /etc/init.d/splx start

    上記を実施後、status等を確認して、動作している事を確認します。

    ※：トレンドマイクロ社のホームページに於いて、該当するＫＨＭモジュールが公開されるのは結構遅れます（最新のカーネルが公開されて、一か月以上掛かる事が多い）。急ぐ場合は、自分でモジュールをビルドする（マニュアルが公開されているが、コンパイルが出来る環境を用意する必要が有る）事で対応します。横着をする場合は、近いバージョンのモジュールをrenameする事で暫定的に対応が可能です（保障は出来ませんが、大体、正常に動く）。

  • smartctl　の利用メモ

    情報の確認

    全ての情報確認

    smartctl -a /dev/sda

    １　　データ読み込み時に発生したエラーの数

    ５　　データを予備エリアに移動した不良セクタの数

    １９６　セクタの代替処理が発生した回数

    １９７　現在異常が有って代替処理を待つセクタ数

    １９８　オフラインテストで発見された回復不可能なセクタ数

    とかに注意

    smartctl -l error /dev/sda
    smartctl -l selftest /dev/sda

  • ターミナルの文字化け回復

    Linux ターミナルで間違ってバイナリをcat してしまって日本語どころか英数字も文字化けするようになってしまったなんてことよくあります。

    そんなときの対応方法

    1. viを起動して 「:q」 で終了する。

    vi有能･ω･

    2. echo Ctrl+V、ESC、c、Enterを押す。 画面上には echo ^[c と表示されます これで直ります。

    3. ALT +Fnで別のターミナルに切り替える 厳密には修正ではないですが、応急処置です パニくったときはお手軽です。

  • ssh認証の設定

    sshの認証設定

    ssh　を利用して、公開鍵を使用して認証を実現させる手順です。 パスワード認証に比べ、より強固な認証を実現出来ます。 鍵の作成時の指定により、パスフレーズ無しでの認証設定も可能です。cron　での実施する場合等で、応答要求を無くす事が可能です。rsync　等の自動バックアップなどで利用可能です。

    サーバ側の設定

    /etc/ssh/sshd_config　の設定を変更します。

    PermitRootLogin no　　＜－　設定を有効にし、root　でのLoginを禁止

    RSAAuthentication yes　　　＜－　RSA認証を有効にする。公開鍵の場所等を指定する。

    PubkeyAuthentication yes

    AuthorizedKeysFile .ssh/authorized_keys

    GSSAPIAuthentication no　＜－　GSSAPI認証は使用しない。（DNSの応答を待たない。）

    #GSSAPICleanupCredentials yes　＜－　コメントアウト。デフォルトはログアウト時に証明書のキャッシュを削除する。GSSAPI認証を使用しないので、余分な動作は止める。（yes　の方が安心！。負荷はほとんど無いので、そのままが良いか？）

    UseDNS no　　＜－　DNS認証は使用しない。（余り意味が無いけど）

    上記の変更後、サービスを再起動します。

    参考　特定のアドレスからの処理の記述

    特定のアドレスからのみ　root　Login　を許可する等の場合は、以下の記述で個別マッチの設定を行う

    Match Address XXX.XXX.XXX.XXX

    PermitRootLogin yes

    鍵の作成（キーペアの作成）

    この処理は、サーバ側で実施します。 SHA2　RSA　２０４８bitで作成します。

    $ ssh-keygen -t rsa

    上記を実行すると、ユーザのホームディレクトリ配下の　.ssh　配下へ以下の二つのファイルが作成されます。

    id_rsa　　　　＜－　秘密鍵（クライアント側に配置する）

    id_rsa.pub　 ＜－　公開鍵（サーバ側へ配置する）

    ※：作成時に、パスフレーズの入力を求められます。この時、パスフレーズを指定すると、ssh　等での接続時に、パスフレーズの入力を求められます。通常は、パスフレーズを指定して作成します（セキィリティの観点から）が、cron　等で実行する場合に使用する鍵を作成する場合は、パスフレーズを指定しないで作成します。

    公開鍵の配置

    公開鍵を指定の場所へ配置します（配置場所は、sshd_config で指定した場所です）。

    $ mv ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/authorized_keys

    秘密鍵の配置

    秘密鍵は、クライアント側へ配置します。

    ※：サーバ側の秘密鍵はセキュリティの観点から、配置終了後は削除する事が望ましいです。

    以下の操作は、クライアント側で実施します。

    scp　等で、サーバから秘密鍵をクライアント側へCopyします。 その後、指定の場所へ配置します。

    $ mv id_rsa ~/.ssh/id_rsa
$ chmod 600 ~/.ssh/id_rsa

    オーナ／グループについても、確認しておきます。

    動作確認

    クライアント側から、接続の確認を行います。

    $ ssh ユーザ名@サーバアドレス（サーバ名）

    これで、接続が出来ればＯＫです。

    ※：鍵を作成する時に、パスフレーズを指定した場合は、上記の接続時にパスフレーズの入力を求められます。

    rsync等で複数の鍵を使用する場合

    rsync　等で、複数の鍵を使用する場合（複数のユーザでバックアップを取得するとかの場合）は、明示的に秘密鍵の場所を指定します。

    $ /usr/bin/rsync -av --delete -e "ssh -i /home/abc/.ssh/id_rsa" abc@172.16.X.XX:/home/abc/samba/ /user/abc/

    上記のように、ssh　で、　-i　のオブションを指定して、明示的に秘密鍵の場所を指定して実行します。