2024 DNS kihada2 再構築ログ


  1. 昨年度の作業内容の保存
  2. インストールするもの
  3. インストール USB の作成
  4. Debian bullseye のインストール
  5. 日本語環境の設定
  6. ssh インストール
  7. DNS登録
  8. 作業用アカウントの作成
  9. sudo のインストール
  10. ssh の設定
  11. ntpdate の設定
  12. bind9 のインストール
  13. gate-toroku-system のインストール
  14. syslog-ng のインストール
  15. logwatch のインストール
  16. MTA(exim4)の設定
  17. ログ監視スクリプトの導入

昨年度の作業内容の保存(作業期間: 2024/01/10-01/24)

2023年度の作業内容をjoho09にrsyncした.

 # rsync -av -rsh="ssh -p 2222" / yoshis@joho9.ep.sci.hokudai.ac.jp:/BACKUP_kihada2/

rsyncしたjoho9:/BACKUP_kihada2/の容量を確認する.

 $ du -sh /BACKUP_kihada2/*
		2.1T	/BACKUP_kihada2/proc

procの容量だけやたら大きくなってしまった. 一時的に作られたファイルの容量が大きかったと推察される.

 ls -la /BACKUP_kihada2/proc/
		-rw-------  1 yoshis yoshis 2241721270272 1月 13 16:11 .kcore.SwNI42

lsで確認したところ, .kcore.SwNI42という非常に大きな容量のファイルが見つかった. ディスク容量を圧迫しない限りは削除しなくても問題ないと思われる.

インストールするもの

入れ替え後に yellow として稼働する kihada2 に以下のものをインストールする.なお、あらかじめインストールされているUSBを利用したため,以下のUSB作成に関しては参考に過ぎない。

インストールするOS

インストールするソフト

以下,特別な断りがない限り kihada2 で行う作業について記述する.

インストール USB の作成

kihada2 には CD-R ドライブがない.そのため OS インストールには USB メモリを使用する. 作成にあたっては aoi2で使用したものを再使用した.

Debian JP Project buster インストーラのページを開き,「小さな CD または USB メモリ」という項目の amd64 をダウンロードし,適当なディレクトリにおく.

USB メモリを挿し,デバイス名を確認

# fdisk -l

USB メモリに iso ファイルを焼く

# cat debian-12.4.0-amd64-netinst.iso > /dev/sdb
        ! デバイス名が /dev/sdb の場合.
# sync

なお,作成方法は情報実験 第 6 回 "ブート・Debian GNU/Linux インストール" の "Debian GNU/Linux インストールガイド" も参照のこと.

Debian のインストール

kihada2が立ち上がらず, 原因も不明であるため, kihadaの機材を用いて再構築を行うことにした.

前節の通り, joho09で作成したUSBメモリを挿入し, kihadaを起動.

false

先にBIOSを起動し, Boot欄内のBoot Option Prioritiesの順序を, UEFI: BUFFALO USB Flash Diskを1位としたが, これでSave & Exitしても再びdebianが立ち上がってしまった.
そこで, Save & Exit内のOverrideでUEFI: BUFFALO USB Flash Diskを選択すると, 下のように, Debian12の画面が映ってくれた.
Drive Managementを開き,Unconfigured goodを選択.

false

再起動

graphic installerを起動

言語

Japanese - 日本語 を選択

場所

日本

キーボード

日本語

ネットワークの設定

enol を選択

DHCP の設定が自動で開始されるのでキャンセル

ネットワークを手動で設定

IP アドレス
 133.87.45.114

ネットマスク
 255.255.255.0

ゲートウェイ
 133.87.45.1

ネームサーバアドレス
 133.87.45.70 133.87.45.66 133.87.1.11

ホスト名
 kihada

ドメイン名
 ep.sci.hokudai.ac.jp

root のパス

任意のパスワードを設定

root の本名

あなたの本名

アカウント名

任意のアカウント名

アカウントのパス

任意のパスワードを設定

ディスクのパーティショニング

UEFIインストールを強行しますか? - はいを選択

SCSI1(sda)とSCSI2(sdb)を選択して、あらかじめあるパーティションを消去しておき、 RAIDを組むよりも先に各HDDでパーティションを作る。 ESPを先に作る理由はgrub installの際にESP(EFIシステムパーティション)にインストールを邪魔されてしまうためである。
false true
2つの画像はそれぞれhttps://techacademy.jp/magazine/5827 を参考にした。ということでまずはESPから作っていく。

まずは, 2つのディスクのパーティションをフォーマットする。 false

どちらのディスクも空き領域のみにする
しかし, 2024/02/21現在, sda,sdbの2つのディスクのパーティションはフォーマットできたが, RAIDパーティションがはじめから残ってしまっており, 削除を試みても削除できなかった.

false

上画像と比較すると, RAIDパーティションがなぜか残ってしまい, 削除しようにもできない.

一旦ガイドによるパーティションをやり, Raidパーティションに展開した.

パーティショニング機構

sda 空き領域を選択
        
新しいパーティションの作成

新しいパーティションのサイズ
510MB
新しいパーティションの場所
先頭
パーティション設定 UEFI
   容量 : 510.0 MB
     名前: EFI boot partition
     利用方法 : EFI システムパーティション
     起動フラグ : オン
     ※他の設定はデフォルトでok
メインのdevian
   容量 : 490.0 GB
     名前 : Debian GNU/Linux 
     利用方法: ext4 ジャーナリングシステム
     マウントポイント : /
     マウントポジション : defaults
     ラベル : なし
     予約ブロック: 5%
     典型的な利用方法 : 標準
     起動フラグ : オフ
スワップ領域
     容量 : 8.4 GB
     名前 : swap
     利用方法 : スワップ領域
     起動フラグ : オフ
sdb 空き領域にも同様にパーティションを作る。

次にRAIDを設定する。

	ソフトウェア RAID の設定
	ディスクへの変更の書き込み
	

まずは、root パーティションを RAID にする

 mdデバイスの作成

ディスクのパーティショニング
 RAID1

RAID1 アレイのアクティブデバイス数
 2

RAID1 アレイのスペアデバイス数
 0


RAID デバイスの選択
/dev/sda2 (489999MB; ext4)
/dev/sdb2 (489999MB; ext4)

   true
2つのext4を選択してRAIDを組む

記憶デバイスへの変更を書き込み、 RAID を設定しますか?
 はい

RAID1 デバイス 0. のファイルシステムを ext4 にし,
 マウントポジションを / にする
次にswapパーティションをRAIDにする
ソフトウェア RAID の設定

ディスクへの変更の書き込み

md デバイス の作成

ディスクのパーティショニング
 RAID1

RAID1 アレイのアクティブデバイス数
 2

RAID1 アレイのスペアデバイス数
 0

RAID デバイスの選択
/dev/sda3 (8400MB; スワップ)
/dev/sdb3 (8400MB; スワップ)


記憶デバイスへの変更を書き込み、 RAID を設定しますか?
 はい

完了


RAID1 デバイス 1. のファイルシステムを スワップ領域にする

最終的に以下のようになっていればよい partition

パーティショニングの終了とディスクへの変更の書き込み

ディスクに変更を書き込みますか?

はい を選択

パッケージマネージャの設定

日本

Debian アーカイブミラー

dennou-k.gfd-dennou.org

HTTP プロキシの情報

空欄にしておく

Debian パッケージ利用調査に参加しますか?

いいえ

インストールするソフトウェアの選択

「標準システムユーティリティ」のみ

マスターブートレコードに GRUB ブートローダをインストールしますか?

はい(インストール先は sda)

※ここでGRUBインストールができなくなる時がある。その際はBIOSを起動し、ハードウェアRAIDが組まれていないかチェックする。 組まれていたらあらかじめ消してから再びインストールする。(RAIDがハード側で組まれている場合、パーティショニングの際に HDDが1つと認識されてしまうため、ESPをRAIDから外すことができなくなり、Grubインストールの際に 失敗してしまう。)

以上でインストール完了.USB メモリを抜き取り,再起動.

日本語環境の設定

$ export LC_ALL=C
$ export LANG=C
$ export LANGUAGE=C

ssh インストール

$ su
# apt-get install ssh

以後,遠隔ログインで作業可能.

※以下自分のパソコンにて・・・今回wwwを媒介してkihada2にログインしようとしたところ以下のような警告が出た。

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

この場合は.ssh/known_hostsに書かれている133.87.45.115を消すことで無事ログインできるようになった。

DNS登録

現行のDNSに以下の内容でkihada2を登録しておく。 partition
イーサネットアドレスは
root@kihada2# ip address show
で調べた。 大計ハブ番号とポート番号は同じハブに繋がっている機器と揃えた (今回はaoi2) 。

作業用アカウントの作成

adduserにPATHを通す

/bin/sbin以下にPATHが通ってなかったら以下を実行

export PATH=$PATH:/usr/sbin/

これでadduserを使えるようになった。

ルートからexitすると再び上記コマンドを打ち込む必要があるので、.bashrcにexport以下を書き込んで置くと良い.

※.bashrc内に以下を追加
 PATH="$PATH:/usr/sbin/"

作業用アカウントの作成

コアマネとの相談で mondo*を決める

# adduser --uid 40001 mondouehata
        ! 本年度は mondouehata だったので,以下 mondouehata として記述する.

sudo のインストール

# aptitude install sudo
# visudo 

mondouehata sudo 権限を追加

以後,mondouehataで作業する

ssh の設定

/etc/ssh/sshd_config の設定

X11Forwarding no
PermitRootLogin no

/etc/hosts.deny の編集

sshd: ALL

を追加.

/etc/hosts.allow の編集

sshd: .ep.sci.hokudai.ac.jp

を追加.
hosts.denyとhosts.allowの仕組みは以下。

1. /etc/hosts.allow に記述されたホストからのアクセスが許可される
2. 1.に該当しなかった場合、/etc/hosts.denyに記述されたホストからのアクセスが拒否される
3. 1.にも2.にも該当しなかった場合、アクセスはすべて許可される
2021/3/24 orangeからkihada2にアクセスできない

ntpdate の設定

# apt install ntpdate

/etc/default/ntpdate の編集

NTPDATE_USE_NTP_CONF=no
NTPSERVERS="ntp.hokudai.ac.jp"
と編集.

動作確認

# ntpdate-debian
現在の日付・時刻が表示されることを確認

crontab の編集

# crontab -e
00 6 * * * root         /etc/network/if-up.d/ntpdate
を追記. 編集エディタにはnanoを用いた。

bind9 のインストール

# apt install bind9

dnsutilのインストール

# apt install dnsutils

bind が機能しているか確認

/etc/resolv.conf のバックアップと編集

# cp /etc/resolv.conf /etc/resolv.conf_bk

resolv.conf を以下のように書き直す. (前の内容は削除した上で書き直す)

search ep.sci.hokudai.ac.jp
nameserver 127.0.0.1

dig で挙動を調べる

$ dig ep.sci.hokudai.ac.jp any
  
  ; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> ep.sci.hokudai.ac.jp any
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11931
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
  
  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 4096
  ; COOKIE: 5c616b68363dfe2544a24dc660586c571c05b4c3a6116445 (good)
  ;; QUESTION SECTION:
  ;ep.sci.hokudai.ac.jp.          IN      ANY
  
  ;; ANSWER SECTION:
  ep.sci.hokudai.ac.jp.   86400   IN      NS      yellow.ep.sci.hokudai.ac.jp.
  ep.sci.hokudai.ac.jp.   86400   IN      NS      blue.ep.sci.hokudai.ac.jp.
  ep.sci.hokudai.ac.jp.   86400   IN      MX      10 grey.ep.sci.hokudai.ac.jp.
  ep.sci.hokudai.ac.jp.   86400   IN      MX      20 orange.ep.sci.hokudai.ac.jp.
  ep.sci.hokudai.ac.jp.   86400   IN      SOA     yellow.ep.sci.hokudai.ac.jp. postmaster.ep.sci.hokudai.ac.jp. 2021032239 10800 3600 604800 86400
  
  ;; Query time: 599 msec
  ;; SERVER: 127.0.0.1#53(127.0.0.1)
  ;; WHEN: 月  3月 22 19:07:19 JST 2021
  ;; MSG SIZE  rcvd: 208

ゾーンファイル

ep.zone local.rev local.zone named.root を blue から持ってくる

# scp hogehoge@blue.ep.sci.hokudai.ac.jp:/var/cache/bind/ファイル名 /var/cache/bind/

bind9 の設定ファイル

/etc/bind/named.conf.local の書き換え

以下の記述を追加する.

zone "ep.sci.hokudai.ac.jp" {
      type master;
      file "/var/cache/bind/ep.zone";
};

yellow:/etc/bind/named.conf.option の書き換え

!!! yellow での作業 ここから !!!

yellow の /etc/bind/named.conf.options に以下の記述を追加して, kihada2 へのゾーンファイルの転送を許可する

allow-transfer { 133.87.45.66; 133.87.1.11; 133.87.45.135; 133.87.45.115};

この記述をしないと, ゾーンファイルの転送要請をすべて許可してしまう.

逆に, この記述を加えると明示的に許可していないところからの転送要請はすべて許可されなくなるので注意.

!!! yellow での作業 ここまで !!!

ログで DNS ゾーンファイルの読み込みを確認

bind の restart

# service bind9 restart

/var/log/daemon.log を見る

# lv /var/log/daemon.log

最終時刻の最初の方でbindが再起動しているのを確認する。 その後 ep.zone が読み込まれている事を確認する。
2021/03/23 ep.zone の読み込みが失敗している事を確認。 ログ
ep.zone の読み込みで syntax error になってしまっている。
2021/03/24 ep.zone を無事読み込んだ.
原因 : blueからscpしたep.zoneがバイナリファイル化していたため、正常に読み込めていなかった.
対処 : yellowから持ってきた.
補足 : バイナリファイルの生成行程がナゾ、blue単騎での正常な名前解決ができるか?以上2点を確認すべし.

/etc/resolv.conf に他の DNS サーバを書き加える

search ep.sci.hokudai.ac.jp
nameserver 127.0.0.1
nameserver 133.87.45.70
nameserver 133.87.1.11

とする.

gate-toroku-system のインストール

必要なパッケージのインストール

以上のパッケージは apt-get install すればよい.

作業用アカウントの作成

# adduser --uid 500 --disabled-password gate

管理者の名前は Administrator of gate-toroku-system とした.

gate グループに gate 管理者を加える.

ssh のノンパスワードログインに関する設定

.shosts の設定(kihada での作業)

.shosts 認証を可能にする. /etc/ssh/sshd_config を以下のように編集する.

(変更前)
# IgnoreRhosts yes
# HostbasedAuthentication no

(変更後)
IgnoreRhosts no
HostbasedAuthentication yes

ファイル編集後, ssh を再起動する.

# service ssh restart

gate ユーザになる.

$ sudo -u gate -s -H

/home/gate へ移動する.

$ cd /home/gate/

.shosts を作成する. ファイルに以下のように書きこむ.

orange.ep.sci.hokudai.ac.jp  gate

.shosts のパーミッションを変更し gate 以外のユーザが見れないようにする.

$ chmod 600 .shosts

.shosts の設定(www での作業.root 権限をもつ人に作業してもらう)

/usr/bin/ssh, /usr/bin/ssh-keygen の s ビットを立てる.

.shosts 認証を有効にするため, /etc/ssh/ssh_config を以下のように編集. 2022/01/19 変更点は無かった。

公開鍵を新たに作り直す

kihada で行う作業

2022/01/19 新blue, 新yellow含めて、wwwに公開鍵を置くことをしなかった。 必要が生じたら置く。 置き方は、yellowの.ssh/authorized_keyにorangeの公開鍵を追記する。 また、orangeの.ssh/authorized_keyにyellowの公開鍵を追記する。

gate ユーザになる.

$ sudo -u gate -s -H

orange の公開鍵が既に存在しているかを調べる.

$ ssh-keygen -F orange.ep.sci.hokudai.ac.jp

存在しないはずなので,orange の公開鍵を取得する.アドレスはフルドメインで入力する.

$ ssh orange.ep.sci.hokudai.ac.jp

ここで公開鍵を作るかどうかを聞かれるので yes と入力する.

Are you sure you want to continue connecting (yes/no)?

> yes

Ctrl + c で出る.

www での作業(root 権限をもつ人に作業してもらう)

gate ユーザになる.

$ sudo -u gate -s -H 

.ssh/known_hosts にローカルホストの公開鍵が存在するかを確認し,あれば削除する.

$ ssh-keygen -F kihada.ep.sci.hokudai.ac.jp

公開鍵を取得する. (アドレスはフルドメインで入力する)

$ ssh kihada.ep.sci.hokudai.ac.jp 

ここで公開鍵を作るかどうかを聞かれるので yes と入力する.

Ctrl + c で出る.

パッケージの取得と展開

パッケージの取得

# sftp hoge@orange.ep.sci.hokudai.ac.jp
sftp> cd /home/gate
sftp> ls (gate-toroku-system.tgzのファイル名を確認)
sftp> get gate-toroku-system.tgz
sftp> bye
# ls (gate-toroku-system.tgzがあることを確認) 

パッケージの展開

$ tar xvfz gate-toroku-system.tgz 
# cd gate-toroku-system_2018-05-10 

パッケージの設定

/home/gate/gate-toroku-system/include/gate.conf の設定

##  本気モードとデバックモード
#
        $DEBUG_CONFIG = 1;              # 0: 本気モード, 1: デバッグモード

となっていることを確認. 入れ替え直前に本気モードに変える.

- ディレクトリ構成の設定
               $VAR_NAMED_DIR = '/var/cache/bind';

に編集.

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

Config.mk の生成

$ exit (一般ユーザに戻る)
$ sudo -u gate -s -H    
$ cd /home/gate/gate-toroku-system_2018-05-10
$ perl ./config.pl

make によるコンパイル

$ make

インストール

$ exit (一般ユーザに戻る)
$ sudo -s (root ユーザになる)
# cd /home/gate/gate-toroku-system_2018-05-10
# cp include/gate.conf /etc/gate.conf
# make install

インストール終了後, プログラムファイル (gate-ip-accept 等)が /usr/local/bin, /usr/local/sbin, /usr/local/lib/gate にインストールされていることを確認する. また, /etc/passwd, /etc/shadow, /etc/group, /etc/sudoers が /ETC に存在していることを確認する.

デーモンの設定

デーモンモードで起動するための確認

となっていた.

gate-toroku-system 用のポートの作成

/etc/inetd.conf に以下の行を追加(1 行で書く)

gate stream tcp nowait root /usr/sbin/tcpd /usr/local/lib/gate/gate-daily -N 

gate 用に 8888 番 ポートを割り当てる. /etc/services に以下の行を追加する.

gate   8888/tcp

/etc/inetd を起動する.

# service inetutils-inetd start

TCPWrapper によるセキュリティ強化

gate のポートには登録サーバである orange 以外のホストはアクセスできないようにする. /etc/hosts.deny を以下のように編集して全てのホストに対して gate ポートへのアクセスを禁止する.

gate-daily: ALL [改行]

/etc/hosts.allow を以下のように編集して orange に対して gate ポートへのアクセスを許可する.

gate-daily: orange.ep.sci.hokudai.ac.jp [改行]

アクセスの確認

# tcpdmatch gate-daily [orange.ep.sci.hokudai.ac.jp 以外のホスト名]

access: denied と表示された.

# tcpdmatch gate-daily orange.ep.sci.hokudai.ac.jp

access: granted と表示された.

安全の確保

重要ファイルのバックアップ

# cp /etc/passwd ~/
# cp /etc/shadow ~/
# cp /etc/group ~/
# cp /etc/sudoers ~/  

# chmod 400 passwd shadow group sudoers (バックアップファイルの権限を変更)

root になった端末を残しておく

万一端末が動かなくなった時に作業ができるように root になった端末をもう一つ確保しておく.

動作確認

テストのため, /etc/gate.conf を一度以下のように書き換える

##  本気モードとデバックモード
#
        $DEBUG_CONFIG = 0;              # 0: 本気モード, 1: デバッグモード

!!! www での作業 ここから !!!

www サーバ (orange) から kihada2 の gate ポートに接続する.

$ telnet kihada2.ep.sci.hokudai.ac.jp 8888

!!! www での作業 ここまで !!!

正常に接続できたかを確認するには /etc/passwd, /etc/shadow などのファイルのタイムスタンプを確認すればよい.

しかしここでは, 確認したが更新されていなかった. reboot してから再度接続したらログインできなくなった。

(各サーバでチェック [www でじゃないよ!!])
$ date (現在時刻の確認)
$ ls -l /etc/passwd /etc/shadow

また, /etc/passwd の中身がユーザ ID の順番に並び変えられていればよい.

動作確認終了後/etc/gate.conf の設定を元に戻す

##  本気モードとデバックモード
#
        $DEBUG_CONFIG = 1;              # 0: 本気モード, 1: デバッグモード

syslog-ng のインストール

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

# apt-get install syslog-ng
name="label-47" id="label-47">logwatch の設定

logwatch のインストール

# apt-get install logwatch

logwatch の設定(実験)

$ cd /usr/share/logwatch/default.conf
  # emacs logwatch.conf

emacs がないといわれたのでインストール

# apt-get install emacs

再度編集

# emacs logwatch.conf

の部分を

MailTo = hogehoge@ep.sci.hokudai.ac.jp

に変更.

Range = Today

に変更。(実際はyesterday)

Detail = Low 

のまま.

MTA(exim4)の設定

"インターネットサイト: メールは SMTP を使って直接送受信される" を選択.

システムメール名:

kihada.ep.sci.hokudai.ac.jp に設定.

入力側 SMTP 接続をリスンする IP アドレス:

空にする.

kihada2.ep.sci.hokudai.ac.jp に設定.

メールをリレーするドメイン:

空にする.

メールをリレーするマシン:

空にする.

DNS クエリの数を最小限に留めますか(ダイヤルオンデマンド)?

<いいえ>を選択.

ローカルメールの配送方式:

"ホームディレクトリ内の Maildir 形式" を選択.

設定を小さなファイルに分割しますか?

<いいえ>を選択.

実際にメールが届くかどうか確認

# logwatch --mailto hogehoge@ep.sci.hokudai.ac.jp

すぐに届いた。 試しにメールではなく、画面に出してみる。

# logwatch
 # logwatch --service sshd
 
   ################### Logwatch 7.4.0 (03/01/11) ####################
   Processing Initiated: Tue Nov 8 16:16:00 2016
   Date Range Processed: today
   ( 2016-Nov-08 )
   Period is day.
   Detail Level of Output: 0
   Type of Output/Format: stdout / text
   Logfiles for Host: kihada
   ##################################################################
 
   --------------------- dpkg status changes Begin ------------------------
 
   Installed:
   acl:amd64 2.2.52-2
 
   :
   :
   :
 
   --------------------- Syslog-ng Begin ------------------------
 
 
   Syslog-ng started:                                   2 Time(s)
   Syslog-ng stopped:                                   1 Time(s)
   ---------------------- Syslog-ng End -------------------------
 
 
   --------------------- Disk Space Begin -----------------------
 
   Filesystem      Size  Used Avail Use% Mounted on
   /dev/sda1       143G  1.5G  134G   2% /
   udev             10M     0   10M   0% /dev
 
 
   ---------------------- Disk Space End -------------------------
   

   ###################### Logwatch End #########################
   
 

無事出力された.

試験的に変えた設定を元に戻す

/etc/cron.daily/00logwatch の編集

これだけでは cron でメールが送られないようだったので, /etc/cron.daily/00logwatch を編集

"#execute" の次の行を

/usr/sbin/logwatch --mailto epdns[@]ep.sci.hokudai.ac.jp

とした.

ログ監視スクリプトの導入

スクリプトの展開

スクリプトファイルを yellow から持ってきて展開する

# scp hogehoge@yellow.ep.sci.hokudai.ac.jp:/etc/cron.local /etc/

cron.local 以下のファイルの実行権限を確認

# ls -l /etc/cron.local/*
 
   /etc/cron.local/daily:
   合計 16
   -rwxr-xr-x 1 root root  75 11月  8 16:25 400_status-disks
   -rwxr-xr-x 1 root root 281 11月  8 16:25 420_status-network
   -rwxr-xr-x 1 root root  79 11月  8 16:25 430_status-rwho
   -rwxr-xr-x 1 root root 944 11月  8 16:25 800_authlog
 
   /etc/cron.local/weekly:
   合計 4
   -rwxr-xr-x 1 root root 149 11月  8 16:25 400_status-apt
   

 

権限が無ければ与える必要があるが,今回はあったのでその操作は不要

crontab の書き換え

crontabに以下の記述を追加する

# crontab -e
 
 25 6 * * *   root    cd /&&  run-parts --report /etc/cron.local/daily | mail -s "`hostname -f` daily run outputs" [送り先メールアドレス]
 47 6 * * 7   root    cd /&&  run-parts --report /etc/cron.local/weekly | mail -s "`hostname -f` weekly run outputs" [送り先メールアドレス]
 

cron デーモンを再起動する

# service cron restart