Open51

Server

Linux
DNS
samba
syslog
sakusaku

sambaの外付けHDD間で定期増分バックアップを実行させたい。

sakusaku

Ubuntu上でHDD1→HDD2への自動ミラーリング

#backup.shの作成
sudo vi backup.sh
    rsync -avud -delete /mnt/hdd1 /mnt/hdd2

#cronで定期実行（nano選択）
sudo crontab -e
1
#毎日3時に実行
0 3 * * * backup.sh > /var/log/cron.log 2>&1

#テスト実行
sudo bash backup.sh
sakusaku

-a アーカイブモード：ファイル属性を保持
-v 詳細モード：経過表示
-u 更新モード：宛先のファイルが新しい場合はコピーしない
-z 圧縮モード：転送データを圧縮し、帯域幅を節約
-delete ：宛先に存在し送信元に存在しないファイルは削除する（完全ミラー）
2>&1：1が標準出力で2がエラー出力。この場合はエラー出力も標準出力にいれて吐き出してと設定している

sakusaku

ZABBIXのインストール復習

・基本は説明書通りにインストール可能
・upkgで必要なデータが入っていない（デモデータ）→tarのファイルからsqlだけ引っ張ってくる
・Agent2はpassiveでまず確認する

sakusaku

とりあえずBINDの設定はできたようなのでメモ。

Windows側からも名前解決できている。
https://changineer.info/vmware/hypervisor/vmware_ubuntu_dns.html

#bindインストール
apt install bind9 bind9utils

# confファイルを編集
vi /etc/bind/named.conf
    include "/etc/bind/named.conf.local";
    // BIND設定オプションファイル
    include "/etc/bind/named.conf.options";
    // BINDゾーン情報ファイル
    include "/etc/bind/named.conf.default-zones";

# Ubuntuはnamed.conf.localで設定
sudo vi /etc/bind/named.conf.local
    zone "saku.XXX" {
        type master;
        file "/etc/bind/saku.XXX" ;
    };
    zone "1.23.172.in-addr.arpa" {
        type master;
        file "/etc/bind/1.23.172.db" ;
    };

# オプションの設定
vi /etc/bind/named.conf.options
// SUBNET
    acl internal-network {
        172.23.1.0/24;
        172.23.10.0/24;
    };

    options {
        directory "/var/cache/bind";
    forwarders {
            8.8.8.8; // Google Public DNS
            8.8.4.4; // Google Public DNS Secoundary
    };
    // ACLの指定
    allow-query {
            localhost;
            internal-network;
    };

    recursion yes;
    forward only;
    dnssec-validation auto;
    // いったんipv6は許可しない
    listen-on-v6 { none; };
    // バージョンは教えない
    version "I won't tell you my version.";
 };

# 正引きファイル
vi /etc/bind/saku.XXX
    $TTL 86400
    @       IN      SOA     ns.saku.XXX. root.saku.XXX. (
                    2024120501      ;Serial
                    3600            ;Refresh
                    1000            ;Retry
                    604800          ;Expire
                    86400           ;Minimum TTL
    );
    @       IN NS   ns.saku.com.
    @       IN A    172.23.1.1      ;DNSサーバーのIP
    ns      IN A    172.23.1.1
    saku-samba      IN CNAME        saku-Ubuntu1
    saku-Ubuntu1    IN A    172.23.1.1
    saku-zabbix     IN CNAME        saku-Ubuntu2
    saku-Ubuntu2    IN A    172.23.1.2

# 逆引きファイル
vi /etc/bind/1.23.172.db
    $TTL 86400
    @       IN      SOA     ns.saku.XXX.    root.saku.XXX.  (
                2024120501      ;Serial
                3600            ;Refresh
                1000            ;Retry
                604800          ;Expire
                86400           ;Minimum TTL

    );
    @       IN NS   ns.saku.XXX.
    1       IN PTR  ns.saku.XXX.
    2       IN PTR  saku-Ubuntu2.saku.XXX.

# UFWの許可
ufw allow 53/tcp
ufw allow 53/udp

# 設定の反映
systemctl restart bind9 bind9utls
systemctl status bind9

# 通信確認
dig saku.XXX @127.0.0.1
dig -x 172.23.1.1 @127.0.0.1

# ローカル側のDNS設定
vi /etc/netplan/99-cloud-init.yaml →nameserver変更
もしくは
vi /etc/resolv.conf →DNSserverのIPに変更
sakusaku

CNAMEで別名を作成したら

sudo:unable to resolve host saku-Ubuntu1: Name or service not known

と表示されて実行できなくなった。
どうやらホスト名が解決できなかったことが問題らしい。

vi /etc/hosts
    127.0.1.1 hostname.domainname saku-Ubuntu1

と変更したところ実行できた。この部分も変更しておいた方が良いのか？注意。

sakusaku

NTP(chrony)のセットアップ

メイン：ntp.nict.jp
バックアップ：0.jp.pool.ntp.org / 1.jp.pool.ntp.org / 2.jp.pool.ntp.org
jp.pool.ntp.orgは、NTP POOL PROJECTのNTPサーバのこと。
https://tech.willserver.asia/2022/12/23/lix-ubt2204-ntp-server/

# インストール
apt install chrony

# 有効化
systemctl enable chrony
systemctl start chrony

# confのバックアップ
cp -a /etc/chrony/chrony.conf /etc/chrony/chrony.conf.org

# confの編集、pool部分はコメントアウト
vi /etc/chrony/chrony.conf
    # pool ntp.ubuntu.com        iburst maxsources 4
    # pool 0.ubuntu.pool.ntp.org iburst maxsources 1]
    # pool 1.ubuntu.pool.ntp.org iburst maxsources 1
    # pool 2.ubuntu.pool.ntp.org iburst maxsources 2
    # minpollとmaxpollを指定するのがWANのNTPを指定する際のマナーらしい
    # ntpサーバーはメイン1台、バックアップ3台設定しておく
    server ntp.nict.jp minpoll 6 maxpoll 8
    server 0.jp.pool.ntp.org minpoll 6 maxpoll 8
    server 1.jp.pool.ntp.org minpoll 6 maxpoll 8
    server 2.jp.pool.ntp.org minpoll 6 maxpoll 8

    # 最終行に許可IPを設定
    # Allow IPs
        deny all
        allow 172.23.1.0/24
        allow 172.23.10.0/24

# サービスの再起動
systemctl restart chrony

# NTPサーバーとの通信確認
chronycc sources
sakusaku

<server / poll> <NTPサーバのホスト名> と記載することで、上位のNTPサーバを設定できます。
オプションで記載しているminpollとmaxpollは上位のNTPサーバに問い合わせを行う間隔です。
2の階乗秒の間隔で取得しに行きます。(minpoll 6であれば最小64秒間隔、maxpoll 10であれば最大1024秒間隔)
これについては、内部のNTPサーバを参照するのであれば特に気にする必要はありませんが、外部のNTPサーバに問い合わせを行う場合、マナーとして設定しておきましょう。

sakusaku

NTPサーバーの設置と適用が終わったのでTFTPサーバーを立てて、コンフィグとファームウェア置き場を作る。

# TFTPサーバーのインストール
apt install tftpd-hpa

#オプションファイルの編集（読み込み専用になっているため、オプションにCreateを追加）
vi /etc/default/tftpd-hpa
    TFTP_USERNAME="tftp"
    TFTP_DIRECTORY="/srv/tftp"
    TFTP_ADDRESS=":69"
    TFTP_OPTIONS="--secure --create"

# サービスの有効化
systemctl enable tftpd-hpa
systemctl restart tftpd-hpa
ystemctl status tftpd-hpa

# ファイアウォールの許可設定
ufw allow 69/udp

# Ciscoからコンフィグのアップロードテスト
copy running-config tftp
> 今回立てたサーバーのIP
> test-running-config

# サーバー側でアップロードされたか確認
ls -a /srv/tftp
sakusaku

cronが正常に動いていないようなので確認する。

実行自体がされていないよう。
"* * * * *"で実行したところfile not found.の表示が出たので、とりあえずディレクトリ変えてみた。

/home/XXX/backup.sh > /usr/local/crontab/backup.sh

bashとshは基本的には同じだが、拡張bashの実行時にshが拾いきれない動きがあるとのこと。可能ならbashで動かすのがいいのかも。

sakusaku

ZABBIX側のUbuntuにNTPクライアントの設定が入れられていなかった。

これでクライアントとしての設定も終了。

# chronyのインストール
apt install chrony

# chronyのコンフィグのバックアップ&編集
cp -a /etc/chrony/chrony.conf /etc/chrony/chrony.conf.org
vi /etc/chrony/chrony.conf

# 参照元を指定（poolの入っているものはコメントアウトして使わない）
pool 172.23.1.2 iburst　を追加

# サービスの再起動と有効化
systemctl enable chrony
systemctl restart chrony
systemctl status chrony
chronyc sources

# Cisco側の設定
ntp server 172.23.1.2
show ntp associations

# YAMAHA側の設定
schedule at 1 */* 00:00 * command ntpdate 172.23.1.2
sakusaku

外付けSSDが激安で手に入ったので、ここにSyslogサーバー立ててログ集約する。

sakusaku

SSHが何やっても繋がるようにならない。どうすればいいんだこれ。

sakusaku

結局色んな記事見て試したけど何をやってもだめだった。とりあえずパスワード認証で確認しようにもそこすら繋がらない。

sakusaku

Ubuntu IP固定の手順→NICでリンクアップしてないと表示されない。

cp /etc/netplan/50-cloud-init /etc/netplan/99-cloud-init.yaml
vi /etc/netplan/99-cloud-init.yaml
    dhcp4: false
    dhcp6: false
    addresses:
    - 172.23.1.3/24
    routes:
    - to: default
        via: 172.23.1.254
    nameservers:
        addresses:
        - 172.23.1.1
sakusaku

Ubuntu24.04LTS　SSHの設定（パスワード認証）

# opensshのインストール
apt install openssh-server
# 接続ユーザーの.sshディレクトリのパーミッション変更
chmod 700 /home/ユーザー名/.ssh
# sshd_config（サーバー側）の変更
vi /etc/ssh/sshd_config
    PermitRootLogin without-password
    PasswordAuthentication yes
    PermitEmptyPassword no
# サービスの再起動
systemctl restart sshd

OSの再インストールを行って同じ手順で2回目は成功。ホスト名の未設定っぽい。

sakusaku

外付けHDDのマウントとフォーマット

# 外付けHDDの確認
fdisk -l
# フォーマット
umount -a /dev/sda
mkfs -t ext4 /dev/sda
# UUIDの確認
blkid /dev/sda
# マウントディレクトリの作成
mkdir /mnt/hdd
chmod 744 /mnt/hdd
# マウントの記載
vi /etc/fstab
    UUID=<uuid> /mnt/loghdd/rsyslog ntfs defaults 0 0
# 再起動して確認
shutdown -r now
# うまくいかなかったら、以下で調整
mount -a
df -h
sakusaku

SSH接続時にWARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!と表示されてアクセス不可時

SSHで接続する際には接続先毎にローカルに情報が保管されるため、中身が別のサーバになったりしていると騙されてる？って怒られることになる。

ssh-keygen -R 172.23.1.3
sakusaku

DNSスレーブサーバーの設定。

local内に設定したのでこちらも同じ場所に設置中。

# マスターサーバーの設定変更
# named.conf.optionsに以下を追加
notify yes;
also-notify { 172.23.1.2; };
# named.conf.localにゾーンごとに以下を追加
allow-transfer { 172.23.1.2; };

# スレーブサーバーの設定変更
# BINDのインストール
apt install bind9 bind9utils
# named.cconf.optionsの設定
acl internal-network {
    172.23.1.0/24;
    172.23.10.-/24;
};
options {
    listen-on port 53 { 127.0.0.1; 172.23.1.2; };
    # 内部からの問い合わせ
    allow-query     { 
        localhost;
        internal-network;
    };
    # キャッシュサーバーなので再帰問い合わせ許可（noで使うのは権威サーバー）
    recursion       yes;

    # named.conf.local に追加
    # zoneの名前としてドメイン名を指定
    zone "saku.XXX" {
            # スレーブで操作させるのでslave
            type slave;
            masters { 172.23.1.1; };
            file "slaves/saku.XXX";
            allow-transfer { none; };
    };

    # IPv4逆引き
    zone "1.23.172.in-addr.arpa" {
            type slave;
            masters { 172.23.1.1; };
            file "slaves/1.23.172.db";
            allow-transfer { none; };
    };
};

    # スレーブされたゾーンファイルが書き込めないことがある。permission deniedの場合は以下の設定を追加（apparmorの設定変更）
    vi /etc/apparmor.d/usr.sbin.named
        /var/named/slaves/** rwk,

https://qiita.com/hm7/items/c165836b857ee656b27c

sakusaku

syslogサーバーの設定（rsyslog）

# ★受信側共通
# インストール
apt install rsyslog
# ファイアウォールの許可
ufw allow 514/tcp
ufw allow 514/udp
# 設定ファイル（/etc/rsyslog.conf）の変更
vi /etc/rsyslog.conf
    # MODULES設定
    module(load="imudp")
    input(type="imudp" port="514")
    module(load="imtcp")
    input(type="imtcp" port="514")
        # UDPに限定
    $AllowedSender UDP, 127.0.0.1, 172.23.1.0/24, 172.23.10.0/24
    # GLOBAL設定
    $template recievelog, "/var/log/rsyslog/%HOSTNAME%/%$year%-%$month%-%$day%.log"
    *.* ?recievelog
# 保存フォルダの作成
mkdir /var/log/rsyslog
# 権限の変更
chown syslog:syslog /var/log/rsyslog
# サービスの再起動
systemctl restart rsyslog

# ★送信側の設定
# インストール
apt install rsyslog
# ファイアウォールの許可
ufw allow 514/udp
ufw allow 514/udp
# 設定ファイル（/etc/rsyslog.conf）の変更
vi /etc/rsyslog.conf
    # MODULES設定
    module(load="imudp")
    input(type="imudp" port="514")
    module(load="imtcp")
    input(type="imtcp" port="514")
    # GLOBAL設定（ログ出力先の指定、全ログ対象）
    *.* @172.23.1.2:514
    # 最下部に追記
    action(type="omfwd" Target="172.23.1.2" Port="514" Protocol="udp")
# サービスの再起動
systemctl restart rsyslog

# ログのテスト送信
logger "test log: syslog delivered!"
#ログの確認
tail /var/log/rsyslog/%HOSTNAME%/日付.log

# rsyslogが正常に動作しているか確認
systemctl status rsyslog
journalctl -xeu rsyslog
# rsyslogでエラーが発生していないか確認
rsyslogd -N 1

# /etc/rsyslog.d/50-default.comfの編集
*.*     @172.23.1.2:514

これでもrsyslogのディレクトリ内にホスト名のディレクトリが作成されなかった。
以下の設定を投入したところ作成された。

# ホスト名の変更
vi /etc/hosts
    127.0.0.1 saku-Ubuntu1 localhost.localdomain localhost
    127.0.1.1 saku-Ubuntu1 hostname.domainname
sakusaku

rsyslogのHDDマウントが失敗しすぎてjournalのログが溢れて容量圧迫。
プロセス停止しようとしたが、syslog.socketがアクティブとなり停止できず、以下のコマンドで停止させられた。

journalctl　→HDDマウントのパーミッションエラーが連発
systemctl stop syslog.socket rsyslog.service
sakusaku

ディスク容量の空き具合を確認するコマンド。

# ディスクのパーティション単位の空き容量確認
df -h
# ディレクトリごとの容量確認（var内のディレクトリをMB単位で抽出、KBにするなら-m を-kにする、大きいものから10個）
sudo du -m /var/* | sort -rn | head -10
# ディレクトリごと直下以下も削除する
rm -rf /ディレクトリ名
sakusaku

syslogを外付けHDDに出力しようとしていたが、ずっとPermission Deniedと表示されてエラーが止まらなかったが、UbuntuのアプリケーションセキュリティであるAppArmorに弾かれていたと理解。以下の設定投入。

# AppArmorのアプリごとの設定ファイルを確認
ls -a /etc/apparmor.d

# 該当するファイルを開く（パーティション設定はusr.sbin.XXXの中に入れる）
vi /etc/apparmor.d/usr.sbin.rsyslog
    /mnt/loghdd/rsyslog/ r,
    /mnt/loghdd/rsyslog/** rwk,
sakusaku

Ubuntu24.04のタイムゾーン変更

# 現在の状態を確認
strings /etc/localtime
    TZif2
    TZif2
    UTC0　→UTCのままになってる

# タイムゾーンの変更
datetimectl set-timezone Asia/Tokyo
sakusaku

Q.すでにデータが入っているディレクトリに、HDDをマウントした場合どのような挙動をする？

A.マウントされたHDDのデータは閲覧できるが、もともとそのディレクトリに入っていたデータは閲覧できなくなる。
今回はデータが入った状態で誤ってマウント→どうしても容量が何やっても減らない→原因はもともとディレクトリに入っていたファイルの容量が大きかった、ということが発生。

ディレクトリパスも、マウントしたものと統合され存在自体が見えなくなってしまうため、データがないことを確認してからマウントしましょう…。

sakusaku

Syslogの出力量が多すぎて、一旦出力制御をしてみた。/etc/systemd/journald.confを編集する。

# journald.conf の編集
vi /etc/systemd/journald.conf
    # 1分で300回のログ発生があった場合は破棄する
    RateLimitInterval=1m
    RateLimitBurst=300
# サービスの再起動
systemctl restart systemd-journald
sakusaku

Ubuntu上でrm -rfでディレクトリごと消しても、容量が戻ってこないことがあった。
一旦すべてのマウントをやり直すことで改善するらしい。

# 対象のサービスをまず止める（今回はrsyslog）
systemctl stop syslog.socket rsyslog.service
# 消す
rm -rf /var/log/syslog
# すべてのマウント状態解除
umount -a
# すべて再マウント
mount
# 容量確認
df -h
sakusaku

Cronのログで以下のものが繰り返し表示され、ログを圧迫していた。

2024-12-13T14:17:01+09:00 saku-Ubuntu1 CRON[6717]: pam_unix(cron:session): session opened for user root(uid=0) by root(uid=0)
2024-12-13T14:17:01+09:00 saku-Ubuntu1 CRON[6717]: pam_unix(cron:session): session closed for user root
2024-12-13T17:05:01+09:00 saku-Ubuntu1 CRON[7512]: pam_unix(cron:session): session closed for user root
2024-12-13T14:25:01+09:00 saku-Ubuntu1 CRON[6753]: pam_unix(cron:session): session opened for user root(uid=0) by root(uid=0)
2024-12-13T14:25:01+09:00 saku-Ubuntu1 CRON[6753]: pam_unix(cron:session): session closed for user root

調べたところ、一応以下の手順で非表示にはできるとのこと。

# /etc/pam.d/common-session-noninteractive の編集
vi /etc/pam.d/common-session-noninteractive
# 以下のように編集
   # here are the per-package modules (the "Primary" block)
   session [default=1]                     pam_permit.so
   # here's the fallback if no module succeeds
   session requisite                       pam_deny.so
   # prime the stack with a positive return value if there isn't one already;
   # this avoids us returning an error just because nothing sets a success code
   # since the modules above will each just jump around
   session required                        pam_permit.so
   # and here are more per-package modules (the "Additional" block)
   ★この一行を追加
   session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid
   session required        pam_unix.so

おまじないなのか？時間を取って確認が必要。
https://iww.hateblo.jp/entry/20221025/cron

sakusaku

まだ改善せず表示されていそうな感じがする。

sakusaku

rsyslogのエラーは収束しそうなので、ログローテーションの設定を進めることに。

sakusaku

ログローテーションの設定

デフォルトの設定とサービス別の設定があるらしい。

# デフォルトの設定は以下
vi /etc/logrotate.conf
    Weekly → Daily
    rotate 4 → 1
# サービスごとの設定はもう一つ下の階層
vi /etc/logrotate.d/rsyslog
    Weekly → Daily
    rotate 4 → 1
sakusaku

rsyslogのディスククエリエラーの暫定対応

サーバー1台からのみ、以下のエラーがずっと出続けていた。

rsyslogd[40403]: rsyslogd: error starting up disk queue, using pure in-memory mode
rsyslogd[40403]: rsyslogd: action-9-builtin:omfwd queue: error creating disk queue - giving up.

一応キューの部分を対応したところ、今のところエラーが表示されなくなった。

# spoolのディレクトリの下層にrsyslogのディレクトリがあるので移動
cd /var/spool/rsyslog
# この下に書き込みができずスプールされたデータが多数存在していた
ls -a
    saku-Ubuntu1.saku.com.00000061
    saku-Ubuntu1.saku.com.00000062
    saku-Ubuntu1.saku.com.00000063
    saku-Ubuntu1.saku.com.00000064
    saku-Ubuntu1.saku.com.00000065
    saku-Ubuntu1.saku.com.qi　→本当はこれだけっぽい？
# 全部消してサービス再起動してみた
rm *
systamctl restart syslog.socket rsyslog.service

もっとLinuxに慣れたら仕組みを理解したい。
https://qiita.com/mokemokechicken/items/274d4bdbaf07c3321e18

sakusaku

ZABBIXのSNMP監視のためのテスト実施

SNMPでの監視を行う場合、マネージャとエージェントでSNMPの通信が取れているかを確認する。
手順は以下の通り。

#必要な機能をインストール
apt install net-snmp net-snmp-utils

#疎通ができているかを確認（バージョンv2c、コミュニティ名はrouter）
snmpwalk -v 2c -c router ＜監視先IP＞
sakusaku

VPN環境（Wireguard）の構築

WireguardをLinuxにインストールし、外部からVPNでリモートアクセスができるようにする。
https://note.com/rcat999/n/n78f23ad6ec2d

DDNSの設定

パブリックIPが動的IPなので、DDNS Nowを使用して対応することにした。

  1. DDNS Nowにアクセス
  2. 希望のホスト名とパスワードを入力
  3. マニュアルに沿って、cronで定期的に通信を出すようにしておく（https://ddns.kuku.lu/manual.php#cron )

Wireguardのインストール

今回はProxmox上にCTを作成し、そっちを経由して宅内へ接続する。

  1. ProxmoxでCTの作成（今回は？？？？を利用）

  2. Wireguardのインストール

     #インストール
 sudo apt install wireguard
 #秘密鍵と公開鍵の作成→メモ
wg genkey | tee /etc/wireguard/$HOSTNAME.private.key | wg pubkey > /etc/wireguard/$HOSTNAME.public.key
sudo apt install iptables →これでFW設定する

  3. 設定ファイルの作成

     #ディレクトリの移動
 cd /etc/wireguard
 #設定ファイルの追加と編集
 vi /etc/wireguard/wg0.conf　→設定ファイル名はインターフェースの名前と同じにすること
     [Interface]
         PrivateKey = ＜サーバーの秘密鍵＞
         Address = 10.0.0.1/24
         ListenPort = 51820
         PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0@if13（仮想） -j MASQUERADE
         PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0@if13（仮想） -j MASQUERADE
         Table = off
         
     [Peer]
         PublicKey = ＜接続側の公開鍵＞
         AllowedIPs = 10.0.0.2/32

  4. 設定ファイルへ追加設定
    仮想インターフェイスの部分は都度修正してね。

     #接続したWireguardサーバーを踏み台にして、LAN内端末へ接続できるようにする（削除時は消す）
 [Interface]に追加
     PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0@if13（仮想） -j MASQUERADE; iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE
     PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0@if13（仮想） -j MASQUERADE; iptables -t nat -D POSTROUTING -s 10.0.0.0/24 -j MASQUERADE
 #デフォルトではすべての通信をVPN先に向けているため、ローカルでインターネットアクセスを可能にする
 [Interface]に追加
     Table = off

 #カーネルパラメータを変更し、パケットフォワードができるようにする
 vi /etc/sysctl.conf
    net.ipv4.ip_forword=1 のコメントアウトを外して有効化する

  5. サービスの再起動

     #作成したインターフェースでWireguardを起動する
 systemctl enable wg-quick@wg0
 systemctl start wg-quick@wg0
 #ルートが作成されたか確認
 ip route

  6. システム再起動
    うまくいかない場合はシステムごと再起動してしまう。

sakusaku

VPNの構築（Wireguard）ネットワーク設定

内向きの通信になるため、静的NAPTの設定が必要になる。
今回はauひかりと891fjでの構成で設定をリマインド。
https://ibulog.me/blog/ix2207-au/

auひかりHGWの設定

今回はとりあえずDMZに設定を入れ、中へ通すようにする。

  1. HGWの設定画面に入る
  2. DMZホスト設定＞ONにし、IPアドレスにホスト側（今回は10.1.1.2）を入れる
  3. DHCPを無効にしておく

Cisco 891fjの設定

WANから届く特定のポートへの通信を特定のIPへ振り分ける。

    #静的NAPTの設定
    ip nat inside source static udp ＜WAN側IP＞ ＜WAN側ポート番号＞ interface ＜インターフェース名＞ ＜Wireguardサーバー側ポート番号＞
    #今回は
    ip nat inside source static udp 172.23.1.11 51281 interface gi8 51280

Android Wireguardの設定

  1. 空の状態から作成
  2. 以下のように設定
    ・名前…適当に
    ・秘密鍵…作成したクライアントの秘密鍵
    ・アドレス…wg0.confのpeerに入力したIP（今回は10.0.0.2/32）
    ・ポート…wg0.confのpeerに入力したポート（今回は51821）
    ・ピア側公開鍵…作成したサーバーの公開鍵
    ・ピア側AllowedIP…wg0.confのAllowedIPに入れた許可範囲IP（今回は0.0.0.0/0）
    ・エンドポイント…固定グローバルIPもしくはホスト名:接続ポート（今回はホスト名:51821）
  3. 接続し、送信と受信がどちらも値が増え、直近のハンドシェイクが更新されていれば成功
sakusaku

Wireguardへアクセスできるクライアントを増やす（Windows）

複数の端末で証明書を作成して、それぞれアクセスできるようにする。
https://mikolabo.net/index.php/2021/05/29/wireguard-win/

wg0.confの編集

wg genkey と wg pubkeyで追加クライアント用の秘密鍵と公開鍵を準備し、設定ファイルを編集。

#wg0.confを開く
vi /etc/wireguard/wg0.conf
#Peerの設定を追加する（Interfaceは変更しない）
[Peer]
PublicKey = ＜クライアントの公開鍵＞
AllowedIPs = 10.0.0.3/32

クライアント用証明書の作成

Windowsは面倒なのでサーバー上で作ってしまう。

wg genkey | tee /etc/wireguard/＜PC名＞.private.key | wg pubkey > /etc/wireguard/＜PC名＞.public.key

Windowsの設定

Wireguardのアプリケーションをインストールして、メモ帳などで以下の設定ファイルを作成する。

#メモ帳などで以下の内容を入力
[Interface]
Address = 10.0.0.3/32
PrivateKey = ＜クライアントの秘密鍵＞

[Peer]
PublicKey = ＜Wireguardサーバーの公開鍵＞
AllowedIPs = 0.0.0.0/0
Endpoint = ＜ホスト名＞:51821
PersistentKeepalive = 25

名称をwg0.confなどに変更し、「ファイルからインポート」を行うと設定を入れられる。
接続の可否はハンドシェイクができたかで判断できる。

IPは前回設定した1つしか使用できないわけではなく、Peerで追加していけば大丈夫のよう。

DNSの設定

この設定だとLAN内の通信だけしか通らないため、コントロールパネル＞ネットワーク＞wg0を選択し、
DNSを固定（うちの設定だと172.23.1.9と172.23.1.10）、もしくはDHCPに変更しておく。IPも固定とDHCPどっちでもよい。
そうするとインターネットにも出られるようになる。

sakusaku

プロキシサーバーの構築（Squid）

Proxmox上にプロキシサーバーを立てて、フォワードプロキシとして外向き通信で使用する。
IPは172.23.1.13、ポートはデフォルトの3128を使用する。（conf内で3128検索すれば表記出てくる）
https://qiita.com/nkojima/items/0d6bd71e9e66814c7951
https://ameblo.jp/shige2006/entry-12811211928.html

Firewalldのインストール

ノード内ファイアウォールとして今回はfirewalldを使用してみる。

#firewalldのインストール
apt install firewalld
#ファイアウォールの設定内容確認
firewall-cmd --list-all
    public
          target: default
          icmp-block-inversion: no
          interfaces: 
          sources: 
          services: dhcpv6-client ssh →ここにsquidを追加したい
          ports: 
          protocols: 
          forward: yes
          masquerade: no
          forward-ports: 
          source-ports: 
          icmp-blocks: 
          rich rules: 

#firewallを通すサービスとしてsquidを登録
firewall-cmd --add-service=squid --zone=public --permanent
firewall-cmd --add-service=squid --zone=public

Squidのインストールと設定

#Squidのインストール
apt install squid
#設定ファイルのバックアップ
cp -a /etc/squid/squid.conf /etc/squid/squid.conf.org
#設定ファイルの編集
vi /etc/squid/squid.conf
    #デフォルトで記載されているlocalnetのネットワークをそのまま使うが、http_accessの記載がないので追加
    http_access allow localnet
    #DNSの設定も入っていないので追加
    dns_nameservers 172.23.1.9 172.23.1.10 →コメントアウトされているのを外す

#LAN内のフォワードを許可する
vi /etc/sysctl.conf
#以下の行のコメントアウトを外す
net.ipv4.ip_forward=1

#サービスの有効化と再起動
systemctl enable squid
systemctl start squid

Windowsでプロキシの設定

  1. 設定＞プロキシの設定＞プロキシサーバーを使う

  2. プロキシIPをサーバーのもの、ポートは3128にする

  3. 接続し、インターネットに繋がるか確認する

  4. サーバー側で変換されているか確認するには、

     tail /var/log/squid/access.log　で確認できる
sakusaku

ドキュメント管理サーバーの構築（Paperless-ngx）

資料の置き場が欲しかったので、Paperless-ngxを立ち上げることにする。
練習でDocker上に立てる。
https://tkyonezu.com/os-linux-windows/almalinux/almalinux-第24回-rocky-linux-第11回「dockerのインストール」/
https://picockpit.com/raspberry-pi/ja/ラズベリーパイでペーパーレスオフィスを作る/

RHEL系のDockerインストール

RHEL系で使用できるdnfとyumを活用する。
今回はRocky Linux 9を使用。

#まずはyum-utilsパッケージのインストールし、Dockerのリポジトリを登録
dnf install -y yum-utils
yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

#Dockerのパッケージをインストール
dnf install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
#インストール中のGPG鍵が「060A 61C5 1B55 8A7F 742B 77AA C52F EB6B 621E 9F35」になっていることを確認して「y」で進める
 Fingerprint: 060A 61C5 1B55 8A7F 742B 77AA C52F EB6B 621E 9F35
 From       : https://download.docker.com/linux/centos/gpg
    これでよろしいですか? [y/N]: y

#Docker自動起動の設定
systemctl start docker.service
systemctl enable docker.service

#一般ユーザーの作成（※Paperless-ngxの立ち上げでは一般ユーザーからの起動が必要）
useradd xxx
passwd xxx　→パスワード指定
#Dockerグループを作成し、ユーザーを追加する
newgrp docker
usermod -aG docker xxx
#ユーザーが登録されているか確認
cat /etc/passwd

#一般ユーザー側でwgetを使うので、インストールしておく
dnf install wget

この後は作成した一般ユーザーに切り替える。

#Paperless-ngxのインストールを行う
bash -c "$(curl --location --silent --show-error https://raw.githubusercontent.com/paperless-ngx/paperless-ngx/main/install-paperless-ngx.sh)"
#インストールスクリプトでいくつか指定を求められる
    ・サイト名
    ・ポート番号
    ・ユーザー名とパスワード
    ・メールアドレス（そのままで大丈夫）

#Docker上でコンテナの作成が進む→結構時間がかかる

完了後、http://＜サーバーIP＞:8000 でアクセスするとサインイン画面が表示されるので、設定時に入力したIDパスワードでアクセスする。

結構GUIがいい感じ…、元がラズパイだから容量少ないのでどこかで足したい。
活用していきたい！PDF記事とかまとめて！

sakusaku

ストリーミングサーバーを作る（nginxとrtmp）

https://qiita.com/bellx2/items/4239bb2fc2f47469ee4d
Proxmox上のコンテナに設置。
ほぼ記載内容のままでOK。
ファイアウォールはufwを使用した。

めちゃくちゃ簡単なのに、スライド共有程度なら問題なく配信できている感じ。
（映像などはもちろん厳しい）
ここからチューンアップできたらもっと面白そう。

sakusaku

DifyをローカルのLinux上に構築→RAGを作ってみた

社内文書を参照するAIボットを作れるといいな、と思っていた矢先、Difyがローカルで立てるのは無料ということでやってみた。
・AlmaLinux9（Hyper-V上）
・例としてJリーグの運営規約等を使用
・Google Gemini AIのAPI（1.5 Flash）を使用（1分あたりのリクエスト数（RPM）が15、1分あたりのトークン数（TPM）が100万、1日あたりのリクエスト数（RPD）が1,500以内）
https://blog.future.ad.jp/dify

AlmaLinuxで基本設定

  1. アップデートをかけておく

     dnf -y update

  2. IPアドレスを固定する

     nmcli connection modify ipv4.addresses ＜サーバーIP/Prefix＞
 nmcli connection modify ipv4.gateway ＜ゲートウェイIP＞
 nmcli connection modify ipv4.dns ＜DNSサーバー＞
 nmcli connection modify ipv4.method manual

  3. 設定内容を確認

     ip a
 ※Docker内でも仮想NICにIPが振られるが、そのままでいい

AlmaLinuxでDifyをインストール

  1. Dockerをインストールするため、レポジトリをインストールしておく

     dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

  2. Dockerのインストールを行う

     dnf -y install docker-ce docker-ce-cli

  3. Dockerを起動し、自動起動を有効化する

     systemctl start docker
 systemctl enable docker

  4. Difyのインストールする際にGitからダウンロードが必要になるため、Gitコマンドをインストールする

     dnf -y install git

  5. DifyをGitからダウンロードし、インストールを実行

     #ディレクトリの移動
 cd /usr/local/src
 #gitでダウンロード
 git clone https://github.com/langgenius/dify.git
 #dockerファイルのあるディレクトリへ移動
 cd dify/docker
 #dockerの起動
 docker compose up -d

  6. コンテナが立ち上がってくるまで待つ

  7. コンテナが起動すれば完了

firewalldが有効になっている場合、サービスの登録等も必要なので注意。ufwならHTTP周りのポート開ける。

Gemini AI APIの設定

  1. https://aistudio.google.com/ にアクセスする
  2. Get API Keyをクリックし、キー作成画面へ移動
  3. すでにGoogle Cloudでプロジェクトを作成していれば、そのプロジェクトを選択（選択しないと新規作成になる
  4. APIキーの作成をクリックし、キーをコピーする

Difyの起動→RAGの作成

  1. http(s)://＜IPアドレス＞/install で管理画面へアクセス
  2. メールアドレス、ID、パスを入れる
  3. 作成したアカウントでサインイン
  4. 「ナレッジ」に参照したい文書をアップロードする（PDFなどもOK）
  5. 基本的にはそのままの設定でOK、取り込む
  6. 「設定」画面から、モデルプロバイダーを選択→Geminiを選び、先にコピーしていたキーを貼り付ける
  7. 変更を反映させる
  8. ボットを作成し、参照先としてアップロードした文書を指定
  9. あとは聞きたい内容を入れてみる
  10. 動作しない場合は、チャット画面上部の「モデル」→Gemini 1.5 Flashに変更する

注意事項

・Gemini AIは無料枠を使っているので、頻繁にリクエスト出しすぎるとお金がかかる。
・Google Cloud側で課金時に通知されるようにしている。（CE作成で設定済みだった）
・無料枠は機械学習に使われるので、利用する情報には要注意。
・一回目の構築ではDockerへのアクセスが非常に遅かった。原因はあまりわかっていない。

感想

Hyper-V上なので、かなりリソースを少なくしたがおおよそ問題なく動いていたし、Difyに関する商用利用もどうやらクリアしそうだった。
選択するクラウドサービスによって価格は変わるが、きちんとRAGとして動作するし好感触。
課金覚悟でもう少し掘り下げて、Difyでできる機能を試してみたい。
https://note.com/brave_quince241/n/n121312a7f161

sakusaku

ブラウザでの初期設定時に「Internal Server Error」と表示された。
以下の設定を行ったところ、改善。

#docker-compose.yamlを編集し、一部の値を変更する
CONSOLE_API_URL=https://api.console.dify.ai
CONSOLE_WEB_URL=https://console.dify.ai
SERVICE_API_URL=https://api.dify.ai
APP_API_URL=https://app.dify.ai
APP_WEB_URL=https://api.app.dify.ai
sakusaku

DifyにGPT-4o-miniでチャットボット作成

どうやらGPT-4o-miniが割と高速でコスパがよく、セキュリティも担保されているようで試してみる。

Open AIのアカウント登録

  1. https://chatgpt.com/ にアクセス
  2. 今回はGoogleアカウントで登録
  3. API Keysから、APIキーを作成（この時点でLLMの設定などはない）
  4. コピーしておく

Difyへの設定

  1. 設定から「モデルプロバイダー」を選択
  2. Open AI→セットアップを選択
  3. API Keysの部分に、先ほどコピーしたキーを貼り付けて進める

Difyへの登録時にエラーが出た場合

モデルプロバイダーにAPIキーを登録しようとすると、以下のエラーが表示されることがある。

RateLimitError: Error code: 429 - {'error': {'message': 'You exceeded your current quota, please check your plan and billing details. For more information on this error, read the

これは、クレジットに1円もチャージしていないことが原因だった。
その際は、

  1. https://platform.openai.com/settings/organization/billing/overview にアクセス
  2. クレジットカード登録とクレジットの追加をする（最低5ドル）
  3. APIキーを再作成する
  4. Dify側でも画面をリロードし、再度設定を試みる

これで解決するはず。

チャットボットの作成

  1. スタジオに移動し、新規からチャットボットを作成する
  2. ★チャット画面上部の「モデル」を確認し、「gpt-4o-mini」を選択する
  3. 必要なテキストや文書をナレッジに保存しておき、利用時に選択して参照させる

注意点

最後のチャットボットを動かす際、必ず「gpt-4o-mini」に切り替えてから実行すること。
APIキーの発行時にはどのモデルを使うかは選択しておらず、このチャットからリクエストを送る際に選択することになるので、要注意すること。
かなり課金額が違う（0.5ドルと0.015ドル）。

sakusaku

プロンプトに以下をいれれば、他の返信はしない。
あなたのタスクは、「テレワークセキュリティ注意点」に記載のある内容を引用しながら、ユーザーからの質問に返答することです。
必ず、「テレワークセキュリティ注意点」を参照して回答してください。

「テレワークセキュリティ注意点」に求めている回答に使える情報がない場合は、「すみません、情報がありません。」と回答するようにしてください。

sakusaku

LinuxでMACアドレスの確認（RHEL系）

MACアドレスフィルタに引っ掛かり、ネットワークに繋がらなくなった。
許可登録をするためにMACアドレスを調べる必要があったので、以下の方法で確認した。
※今回はRHEL系。

nmcli connection showで見る（DHCPのみ）

nmcli connection show ＜インターフェイス名＞
DHCP4.OPTION[1] : 01:＜MACアドレス＞　→これ

ip link show ＜インターフェイス名＞
    link/ether ＜MACアドレス＞ brd ff:ff:ff:ff:ff:ff

ワンライナーで表示する

上記のコマンドが変わっても使える。

cat `find /sys/devices/ -name ＜インターフェイス名＞`/address
    ＜MACアドレス＞が表示される

＜解説＞
・find /sys/devices/ -name ＜インターフェイス名＞を入れると、対象インターフェイスのディレクトリパスを表示する（/sys/devices/pci0000:00/0000:00:XX/net/＜インターフェイス名＞ になる）
・バッククォートの部分が上記のパスに変わり、真後ろに/addressをくっつけることで、対象インターフェイスのaddressファイルをcatで実行することになる
・この中にはMACアドレスが記載されているため、MACアドレスのみが戻ってくる

sakusaku

Difyチャットボット利用のコツ？

Difyでは、RAGとして使用できるナレッジを用意することが可能。
検索する際にいろいろな方法があるが、「ハイブリッド検索」が一番精度が出た。

また、「ウェイト設定」と「Rerankモデル」の2種類があるが、GeminiとかOpenAIは「Rerankモデル」が使えず、使用できるAIが限られる。
「ウェイト設定」だけでもかなり使える！キーワード検索とセマンティックマッチングでバランス調整するともっとブラッシュアップできる。

sakusaku

Linuxで再起動ができなくなった

自宅環境でいじっていたところ、途中で再起動をかけようとしたのだが、

Failed to set wall message, ignoring: Unit dbus-org.freedesktop.login1.service failed to load properly, please adjust/correct and reload service manager: File exists

Failed to schedule shutdown: Unit dbus-org.freedesktop.login1.service failed to load properly, please adjust/correct and reload service manager: File exists

と表示されて実行できなくなってしまった。

Geminiの回答

とりあえずGeminiに聞いてみたところ、いくつか試せるものを残してくれた。

このエラーメッセージは、Linuxシステムにおけるログイン、セッション、電源管理を担う重要なシステムサービスである dbus-org.freedesktop.login1.service ファイルに問題があることを示しています。根本的な問題は「ファイルが存在する」ことであり、これは設定ファイルの競合や破損を示唆しています。systemdがどのファイルを使用すればよいか分からなくなっている状態です。

エラーの理解

dbus-org.freedesktop.login1.service: これはsystemd-logindデーモンのsystemdサービスファイルです。systemd-logindは、ユーザーログイン、セッション管理、システムのシャットダウン/再起動などの処理を行います。
「正しくロードできませんでした...ファイルが存在します」: これは通常、サービスファイルの重複、サービスファイルの破損、またはsystemdが正しいファイルを正しくロードするのを妨げる設定上の問題があることを意味します。
トラブルシューティング手順

サービスファイルの重複を確認:

最も可能性が高いのは、サービスファイルの重複です。systemdは複数の場所でサービスファイルを検索します。「優先度の高い」ディレクトリにある重複ファイルは、正しいファイルを上書きする可能性があります。

一般的な場所:

/etc/systemd/system/ (ユーザーカスタマイズ)
/usr/lib/systemd/system/ (ディストリビューションのデフォルト)
/usr/local/lib/systemd/system/ (ローカルにインストールされたソフトウェア)
確認コマンド:

Bash

systemctl --user status dbus-org.freedesktop.login1.service
systemctl status dbus-org.freedesktop.login1.service
これらのコマンドは、systemdがサービスファイルをどこで検出しているかを示します。複数の場所が表示される場合は、それが問題です。

重複ファイルを特定して削除 (慎重に!):

バックアップ: 変更を行う前に、変更するファイルをバックアップしてください! これは、何か問題が発生した場合に非常に重要です。問題のファイルを安全な場所にコピーしてください。
正しいファイルを特定: /usr/lib/systemd/system/にあるファイルは通常、ディストリビューションによって提供される正しいファイルです。/etc/systemd/system/にあるファイルは、ユーザーによるオーバーライドまたは設定ミスである可能性があります。カスタマイズしたサービスがある場合は、/etc/systemd/system/が正しい可能性がありますが、可能性は低いです。
重複ファイルを削除: sudo rmを使用して、誤ったファイルを削除します。たとえば、重複ファイルが/etc/systemd/system/にある場合:
Bash

sudo rm /etc/systemd/system/dbus-org.freedesktop.login1.service
正しいファイルを削除していることを確認してください。間違ったファイルを削除すると、システムが壊れる可能性があります。
Systemdのリロード:

重複ファイルを削除した後 (またはサービスファイルを変更した場合)、systemdに設定をリロードするように指示します。

Bash

sudo systemctl daemon-reload
サービスを再起動:

systemd-logindサービスを再起動してみます。

Bash

sudo systemctl restart systemd-logind
状態を確認:

サービスが正しく開始されたことを確認します。

Bash

sudo systemctl status systemd-logind
エラーメッセージがないか確認します。「active (running)」と表示されていれば、実行中です。

再起動 (必要な場合):

変更が成功したと思われる場合は、システムを再起動して、すべてが期待どおりに動作していることを確認します。

Bash

sudo reboot
問題が解決しない場合:

ジャーナルログを確認: システムジャーナルで詳細なエラーメッセージを確認します。
Bash

journalctl -xe | grep dbus-org.freedesktop.login1.service
systemdを再インストール: まれに、systemdパッケージ自体が破損している可能性があります。ディストリビューションのパッケージマネージャー (例: apt、yum、pacman) を使用して再インストールしてみてください。
競合するソフトウェアを確認: 他のソフトウェアがsystemdに干渉している場合があります。最近インストールしたソフトウェアがある場合は、一時的に無効にして問題が解決するかどうかを確認してください。
リカバリーモードで起動: 通常どおりに起動できない場合は、リカバリーモードで起動してみてください。これにより、コマンドプロンプトにアクセスしてトラブルシューティング手順を実行できます。
重要な注意事項:

sudoの使用に注意: sudoを使用すると、root権限が付与されます。実行するコマンドを理解してから実行してください。
バックアップは必須: システム変更を行う前に、特にファイルを削除する前に、バックアップを作成してください!
ディストリビューションのドキュメントを参照: 特定の手順は、Linuxディストリビューションによって若干異なる場合があります。ディストリビューションのドキュメントまたはサポートフォーラムを参照して、詳細なガイダンスを入手してください。
Linuxディストリビューションや最近システムに加えた変更など、詳細な情報を提供していただければ、より具体的なアドバイスができるかもしれません。