# kdesvr1リプレースに伴う作業マニュアル
###### tags: `admin`
2022年10月4日00:04分に報告されたゲートウェイサーバ`kdesvr1.ccs.tsukuba.ac.jp`の障害が致命的であったため、リプレース作業を`leo`と共に行いました`natsuki`です。
このドキュメントを書いている2022年10月6日16:00分現在、新kdesvr1はglobal ipが割り当てられ外部からssh接続が可能になりました。また、kdesvr1を踏み台にすることで、計算用内部サーバへの接続も可能です。~~しかし、kdesvr1以外の**内部サーバから外部への通信はまだできません**。計算自体は動くので使っていただき、ファイルのやり取りはkdesvr1を経由して`sftp`や`rsync`等でしばらく行ってください。~~(2022/10/14金曜日の夜にkdesvr1のNAT設定を修正することで，kdesvr1以外の内部サーバでも適切にネットワークコネクション設定を行えば，外部へも接続をすることが可能になりました．115番, 116番と121番は，2022/10/14の夜に外部との接続が可能であることを確認し，残りの119番，122番, 123番も10月18日（火曜日）の夜に外部のサイトからpythonモジュールやdockerイメージのpullができるようになったことを確認しました．)
リプレースに伴って皆さんのアカウントを新しく作成しなおし、authorized_keysは既にあるマシンから取り出して設置しました。
つきましては、新しいアカウントを用いたssh接続のための作業マニュアルを通読し、実行してください。
`amagasa`は既にsudoersに追加しております。
## 作業マニュアル
:::info
Windowsをお使いの方はWSLを使うか、`~`を`C:\Users\ユーザ名`に置き換えてお読みください。また、winver:1903未満をお使いの方は `ProxyCommand ssh -W %h:%p`を
`ProxyCommand C:\Windows\System32\OpenSSH\ssh.exe -W %h:%p`に置き換えてください
:::
1. known_hostsをリセットする
- `ssh-keygen -R kdesvr1.ccs.tsukuba.ac.jp`
- `ssh-keygen -R 130.158.108.54`
- kdesvr1のfinger printが変わったため必要な処置です
2. `~/.ssh/config`を以下の例のように書き換える
- hpcsgitlabに関しては[後述のマニュアル](https://hackmd.io/QwL6KNUySNaqviIDlcmxIw?both#hpcsgitlab%E3%81%AE%E4%BD%BF%E3%81%84%E6%96%B9%EF%BC%88HPCS%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E5%A4%96%EF%BC%89)を参照ください
- 秘密鍵のパスフレーズ入力が苦痛な方は[ssh-agentのすすめ](https://hackmd.io/QwL6KNUySNaqviIDlcmxIw?view#ssh-agent%E3%81%AE%E3%81%99%E3%81%99%E3%82%81)も参照ください
```clike=
# ssh接続の自動切断を回避する
ServerAliveInterval 60
# ssh-agentを用いたときにログイン先でも登録秘密鍵で認証可能にする
ForwardAgent yes
Host kdesvr1
User <内部サーバのユーザ名>
# 学生はこちらの設定
IdentityFile ~/.ssh/<内部サーバの秘密鍵>
# 先生はこちらの設定
# IdentityFile ~/.ssh/<svr05の秘密鍵>
HostName kdesvr1.ccs.tsukuba.ac.jp
Host hpcs*
User <内部サーバのユーザ名>
IdentityFile ~/.ssh/<内部サーバの秘密鍵>
ProxyCommand ssh -W %h:%p kdesvr1
Host hpcs115
HostName 192.168.0.115
Host hpcs116
HostName 192.168.0.116
Host hpcs117
HostName 192.168.0.117
Port 11722
Host hpcs119
HostName 192.168.0.119
Host hpcs121
HostName 192.168.0.121
Host hpcs122
HostName 192.168.0.122
Host hpcs123
HostName 192.168.0.123
# ここの設定は使う人だけで大丈夫です。
Host hpcsgitlab
User git
IdentityFile ~/.ssh/id_rsa.hpcsgitlab
ProxyCommand ssh -W %h:%p kdesvr1
HostName 192.168.0.117
```
3. .ssh/*のパーミッションを他人に見られないものに変更する
- `chmod -R 700 ~/.ssh`
- 700はread,write,executeの権限を自分のみに与えるという意味です
- `-R`はリカーシブという意味のオプション
- `chmod 600 ~/.ssh/<private key name>`
- 秘密鍵の実行権限は自分であっても外して下さい
4. 新kdesvr1にログインする
- `ssh kdesvr1`
- パスワード認証は無効化されています。
- 上記設定の秘密鍵が適切に配置されているか確認ください
5. 内部サーバにログインできるか確認する
- `ssh hpcsXXX`
- XXXにはあなたが管理者に作ってもらったマシンの番号を入れてください
🎉お疲れさまでした．
2022/10/8追記，CentOS7ではadduserを行ったときに使い慣れているUbuntuの同一コマンドとは挙動が異なり，パスワード設定を求められなかった．そのため，ユーザは自分で空パスワードから変更できると誤解していた．
しかし現在，ユーザからパスワードを変更できないとの情報が複数上がってきた．
`/etc/shadow`(昔の/etc/passwd相当のハッシュ)を見てみても空なのにもかかわらず，である．
10分ほど調べてみたが，`man adduser`(useraddのaliasだった)には情報がなかった．
実際に`su 空パスワードのユーザ名`を実行して空パスワードを入力しても他人のアカウントに成りすますことはできなかった．
現状他人にアカウントを使われる恐れはなくなったが，`chsh -s /bin/zsh`などで公開鍵認証でなくパスワードを求められる場面があるかもしれない，その時はsudoersが`sudo passwd ${username}`でパスワードを上書きできるのでそのように対応することにする．
混乱を回避するため，しばらく元のドキュメントを残しておく．
```clike=
5. **重要: ⚠パスワードを設定する⚠**
- `passwd`とログイン先でコマンド入力してください
- Changing password for user ○○と聞かれます
- 英数字大文字小文字記号の入った8文字以上のパスワードを打ち込んでください
- 初回ログイン時にこれをやらないと以下の問題があります
- `su あなたの名前`でアカウントを他人に使われる
```
## `natsuki`が担当したアカウントのリスト
```clike=
# 先生 from svr05
amagasa
chiemi
hayase
kitagawa
shion
# 先生 from 115,116,119,121,122,123 重複はマージします
hayase
horie(2023/4/17 太田 公開鍵再登録)
# 学生 from 115,116,119,121,122,123
leo
natsuki
juan
fujiyama(2023/3/18 太田 公開鍵再登録)
hironori
mamba
miyamoto
nakata
omiya
ebata
tsumoto
yamada
yonai
```
このリストにない方は太田さんまで連絡をお願いします。
- 太田の担当したアカウント
```
juan: 追加で鍵を登録
felix(2022/11/22)
hanshuyan
mizotani(2022/10/12)
kokusho
naoi(2022/10/7鍵登録)
tsuihiji(2022/10/19鍵登録)
kyamada
kawabata(2023/4/4)
ogura(2023/4/28)
```
---
# 【管理者向け】2022/10/4 ゲートウェイサーバ(仮)への対応
## 荻野対応
### 自分は何をやるのか
GitLabサーバの117番をゲートウェイサーバ（仮）にしようとしたが、太田さんがまっさらなCentos7の118番を用意してくださったのでそちらをゲートウェイサーバ（仮）とする。
自分はkdesvr1に登録されていたユーザアカウントの復元・新規アカウント設定・公開鍵の登録を行う。
kdesvr1に保存されていたauthorized_keysは失われてしまったので、CCSの他のマシンやsvr05のものを一時的に代用する。異なるマシンに同じ公開鍵が登録されることが問題になる場合はユーザ側が新規のものに変更してもらうことで対応してもらう。
### 具体的な作業内容
以下のマシンに登録されている情報からユーザを作成し公開鍵を登録する。パスワードによるssh認証は無効にしてある．
- 学生： 115,116,119,121,122,123
- 先生： svr05
#### 学生側の<username,authorized_keys>の抽出
- 学生側は基本的に115,116,119,121,122,123から抽出する
##### `rescue_users.yml`
`tmuxp`を用いて各サーバのすべてのユーザの<username,authorized_keys>のペアを抽出し、natsuki_115などと保存してrsyncで回収するスクリプト。コアの処理は`sudo bash main.sh`と切り分けている。(後述)
```bash=
# 192.168.0.116:/data/fix_kdesvr1/rescue_users.ymlに置かれていることを想定。
# 使い方は下記のようにtmuxpをインストールして実行する
# $ pip install tmuxp
# $ tmuxp load /data/fix_kdesvr1/rescue_users.yml
# passwordが求められる場合はset synchronized-pane onにして全画面同時入力
# 一部natsukiのままになっているので自分のユーザ名に書き換えて実行してください．
session_name: rescue_users
windows:
- layout: tile
panes:
- shell_command:
- ssh hpcs115
- rsync -av hpcs116:/data/fix_kdesvr1/ ~/fix_kdesvr1/
- cd ~/fix_kdesvr1/
- sudo bash main.sh
- sudo chown natsuki:natsuki *
- rsync -av /home/${USER}/fix_kdesvr1/ hpcs116:/data/fix_kdesvr1/
- shell_command:
- ssh hpcs116
- rsync -av hpcs116:/data/fix_kdesvr1/ ~/fix_kdesvr1/
- cd ~/fix_kdesvr1/
- sudo bash main.sh
- sudo chown natsuki:natsuki *
- rsync -av /home/${USER}/fix_kdesvr1/ hpcs116:/data/fix_kdesvr1/
- shell_command:
- ssh hpcs119
- rsync -av hpcs116:/data/fix_kdesvr1/ ~/fix_kdesvr1/
- cd ~/fix_kdesvr1/
- sudo bash main.sh
- sudo chown natsuki:natsuki *
- rsync -av /home/${USER}/fix_kdesvr1/ hpcs116:/data/fix_kdesvr1/
- shell_command:
- ssh hpcs121
- rsync -av hpcs116:/data/fix_kdesvr1/ ~/fix_kdesvr1/
- cd ~/fix_kdesvr1/
- sudo bash main.sh
- sudo chown natsuki:natsuki *
- rsync -av /home/${USER}/fix_kdesvr1/ hpcs116:/data/fix_kdesvr1/
- shell_command:
- ssh hpcs122
- rsync -av hpcs116:/data/fix_kdesvr1/ ~/fix_kdesvr1/
- cd ~/fix_kdesvr1/
- sudo bash main.sh
- sudo chown natsuki:natsuki *
- rsync -av /home/${USER}/fix_kdesvr1/ hpcs116:/data/fix_kdesvr1/
- shell_command:
- ssh hpcs123
- rsync -av hpcs116:/data/fix_kdesvr1/ ~/fix_kdesvr1/
- cd ~/fix_kdesvr1/
- sudo bash main.sh
- sudo chown natsuki:natsuki *
- rsync -av /home/${USER}/fix_kdesvr1/ hpcs116:/data/fix_kdesvr1/
```
##### `main.sh`
各サーバですべてのユーザのauthorized_keysを収集するスクリプト
```bash=
#!/bin/bash
id=$(hostname -I|grep -oP '(?<=192.168.0.)\d*')
echo $id
for homedir in /home/* ; do
user=${homedir#/home/}
if [ -e "${homedir}/.ssh/authorized_keys" ]; then
cp "${homedir}/.ssh/authorized_keys" "./${user}_${id}"
echo ok "${user}"
else
echo ng "${user}"
fi
done
```
##### `merge.sh`
各ユーザ(例:natsuki)に対してnatsuki_115,natsuki_116…をマージして./merged/natsukiに保存するスクリプト。マージ後に重複を`sort|uniq`で省いた。
```bash=
#!/bin/bash
mkdir -p merged
for i in 115 116 119 121 122 123 ; do
for j in *_${i}; do
cat $j >> merged/${j%_${i}}
done
done
```
#### 先生側の<username,authorized_keys>の抽出
- 先生側は基本的にsvr05から抽出する
##### `main_sensei.sh`
名簿から先生のユーザ名を列挙して`sensei_list`に保存した。~/.sshにauthorized_keysが設置されているか確認してok,ngを出力し、されているなら./sensei/ユーザ名に保存する
このスクリプトはsvr05にて実行した。
```bash=
#!/bin/bash
cat sensei_list | while read user ; do
keys=/home/${user}/.ssh/authorized_keys
if [ -e "${keys}" ] ; then
cp "${keys}" "./sensei/${user}"
echo ok "${user}"
else
echo ng "${user}"
fi
done
cd sensei
chown natsuki:games *
```
##### `ok`だった先生のリスト
```bash=
amagasa
chiemi
hayase
kitagawa
shion
horie (2023/4/21 太田)
```
`hayase`先生のみ`115,（116,119,121,122,）123`（のいずれか）と`svr05`の両方にアカウントがあったので末尾に追記したのち`sort|uniq`した。
#### アカウントの作成、authorized_keysの設置
上記スクリプト群を用いて得られた./mergedと./senseiディレクトリからleo,natsuki,user,testを省いて./allディレクトリにコピーした。そののち、`sudo bash add_user.sh`を実行してリストのすべてのユーザを作成した。
##### `add_user.sh`
```bash=
#!/bin/bash
for user in all/* ; do
user=${user#all/}
echo "${user} start"
adduser "${user}"
su "${user}"
cat "/data/fix_kdesvr1/all/${user}" >> "/home/${user}/.ssh/authorized_keys"
echo "${user} end"
done
```
## 太田さん対応
## NMCLIによるコマンドラインインターフェースからのネットワーク設定変更
```
nmcli d # デバイス名の確認
nmcli con show # 全ての接続の確認
sudo nmcli con edit eth0 # 上記で調べたネットワークデバイス名の設定変更，WANと繋げ直す
# nmcli command line interface応答待ちプロンプト
print ipv4
set ipv4.addresses 130.158.108.54/24 # IPアドレスの再設定
set ipv4.gateway 130.158.108.254 # 最後の数字が３桁であることに注意
set ipv4.dns 130.158.108.3, 130.158.108.2
save
quit
sudo nmcli con edit eth1 # 上記で調べたネットワークデバイス名の設定変更，LANと繋げ直す．元々は，起動していなかった．
print ipv4
set ipv4.addresses 192.168.0.118/24 # IPアドレスの再設定
remove ipv4.gateway # ゲートウェイを設定していた場合は設定情報を削除
set ipv4.gateway 130.158.108.254
set ipv4.dns 130.158.108.3,130.158.108.2
save
quit
```
nmtuiでやった方が，変更しやすいと後でわかりました．変更内容は，NetworkManager, networkをsystemctlでrestartすると同期されます． sudo nmtuiと打って画面の選択項目をカーソルで移動し，Enterで選択して，内容を上書きしてください．
## ケーブル 繋ぎかえ
- 基幹（G5ラック上の方にあるスイッチ）からkdesvr1(ASUS RS700，黒，上から２台目)の接続
- おそらく２〜３mのLANケーブル（少しくすんでいて紫っぽい水色）
- kdesvr1(ASUS RS700)からハブ(G5ラック中間ぐらいにあるスイッチ)への接続
- とても長いLANケーブル（おそらく5~7m,少し白っぽい水色）
- 117は，G7ラックにあり，床下を通して繋ぎかえないといけない
- 基幹から本体への接続：元々，kdesvr1からハブにつながっていた水色の5~7mぐらいのLANケーブルを外して，繋ぎかえる
- 本体からハブへの接続：現在の4のラベルのケーブルをハブの左下のkdesvr1に繋がるケーブルを外して差し替える
* ケーブルを繋ぎかえた後に上記のNMCLIによるネットワークインターフェースデバイスの設定を実行しました．
* デュアルホームではルーティングやIPマスカレードを行うのでなく，ip routeの設定はしない．
```
sudo sysctl -w net.ipv4.conf.all.accept_source_route=0
sudo sysctl -w net.ipv4.conf.all.forwarding=0
```
2022年10月6日に荻野さんの指摘によって，内部から外への接続が遮断されて，新しいモジュールのダウンロードやデータセットのダウンロードにおいて不都合が生じると分かったため，パケットを中に入れるようにするためにaccept_source_routeとforwardingを１に変更する．
```
sudo sysctl -w net.ipv4.conf.all.accept_source_route=1
sudo sysctl -w net.ipv4.conf.all.forwarding=1
```
変更したが，まだ，ローカル内からは，ゲートウェイの外に出られていない．
sftpやrsyncは，ゲートウェイにつなげられればできるので，新しいpythonモジュールなどのインストールができない状況である．
* IP forwardingをして二つのネットワークをつなげるようにするための設定
```
vi /etc/sysctl.conf
# > 次の一行を末尾に挿入してください．
net.ipv4.ip_forward=1
```
再起動(sudo reboot)した後，以下を実行して設定が１に変更されているかどうかを確認してください．
```
cat /proc/sys/net/ipv4/ip_forward
```
* ゲートウェイなどの重要な設定後には，ネットワークマネージャの再起動をしました(2022/10/5)．ゲートウェイなどの設定を修正するたびに何回も再起動した．
```
sudo systemctl restart NetworkManager # CentOS, Ubuntu 共通
sudo systemctl restart network # CentOSのみ
sudo systemctl restart systemd-networkd # Ubuntuのみ
sudo systemctl restart networking # Ubuntuのみ
sudo netplan apply # Ubuntu 18.04 以降のみ (Ubuntu 16.04LTSのみ存在しない)
sudo reboot # ゲートウェイサーバ(130.158.108.54,192.168.0.118)か使用者がかなり限定されているもの(192.168.0.114,192.168.0.1２６)のみ
```
* tcpとudpを使用してポートをlistenしているプロセスを確認する
```
netstat -a | grep tcp # プロセス名も観れるので止めるべきサービスを探すgrep検索において便利
netstat -a | grep udp
netstat -tlnp # LISTENしているポート番号のtcpの一覧が見える．ポート番号で，22と53(udp)以外は以下の調査結果消すことができた．
ss -ltnp
```
* メール系のsmtpとportmap/NFS系のsunrpcとプリンタ系のippというプロセスが起動していたので，停止します．
```
#ps aux | grep smtp
#sudo lsof | grep smtp # メール送信プロトコルなのでメールが起動しているかもしれない
#sudo systemctl status postfix.service # メールが起動していることを確認：Postfix mail transport agent, active (running)
sudo systemctl stop postfix.service # メールを停止
#ps aux | grep sunrpc
#sudo lsof | grep sunrpc # portmap, nfsでport 111(sunrpc)が使用されます．
#sudo systemctl stop portmap # portmap.service not loaded. と返ってきたので，portmapはインストールされていない
sudo systemctl stop nfs # nfsで必要です
#sudo systemctl stop nfs-common # nfs-commonはないみたいです．
#sudo systemctl stop rpcbind # nfsで必要です
#sudo systemctl disable rpcbind # nfsで必要です
sudo systemctl stop rpcbind.socket # nfsで必要です
#ps aux | grep avahi-daemon
#sudo systemctl stop avahi-daemon
sudo systemctl stop avahi-daemon.socket
#ps aux | grep ipp
#sudo lsof | grep ipp # cupsというプリンタサーバと判明
sudo systemctl stop cups
sudo systemctl stop cups.path
sudo systemctl stop cups.socket
# port 53：xml２などがヒットすることもあるが，xml2というメールは入っていない．ファイアウォールでssh（22），DHCPV6-controller以外を使わせない．
```
再起動すると毎回，開いてしまいます．
shellscriptを作成して，再起動時には，毎回，不要なポートを使用するサービスを閉じるようにしました．
参考にしていただけますと幸いです．
* 使用しないブリッジは閉じる
```
nmcli d # DEVICEの名前を確認してTYPEがbridgeになっているものを閉じます．virbr0を閉じると53番ポートが閉じます．
sudo systemctl stop docker # ゲートウェイとして機能させる時は，負荷を軽減するために，dockerを停止しておきます．
sudo nmcli con down docker0
sudo nmcli con down virbr0 # これを閉じると，53番ポートが閉じます
```
再起動すると，現状では，毎回全てのブリッジが開いてしまいます．
自動起動しない設定することも検討中です．virbr0は閉じた後もnmcli dで起動しているように見えますが，53番ポートがnetstat -nltpをしてもLISTENしていないように変更されていれば，問題ありません．
* Firewallの起動
```
sudo systemctl status firewalld
sudo systemctl start firewalld
#sudo firewall-cmd --list-services --zone=public
```
* Firewallの設定によるNATの設定
外部に接続するために，ローカルIPアドレスをゲートウェイサーバのアドレスにしてポート番号を個別サーバにマッピングする仕組みをNATと呼びます．NATの設定をCentOSではFirewallで行うことができるので，以後，ゲートウェイサーバをセットアップされる方は，参考にしてください．
https://gist.github.com/walbert947/2abccf590cc32cf107da
```
sudo firewall-cmd --permanent --zone=external --list-all
sudo firewall-cmd --permanent --zone=external --remove-service=dhcpv6-client
sudo firewall-cmd --permanent --zone=internal --list-all
sudo firewall-cmd --permanent --zone=internal --remove-service=ipp-client
sudo firewall-cmd --permanent --zone=internal --remove-service=mdns
sudo firewall-cmd --permanent --zone=internal --remove-service=samba-client
sudo firewall-cmd --permanent --zone=internal --remove-service=dhcpv6-client
# This is the case for CentOS 7
#echo 'ZONE=external' >> /etc/sysconfig/network-scripts/ifcfg-eth0
# sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0として最後の行にZONE=externalを追加してください．
#echo 'ZONE=internal' >> /etc/sysconfig/network-scripts/ifcfg-eth1
# sudo vi /etc/sysconfig/network-scripts/ifcfg-eth1として最後の行にZONE=internalを追加してください．
sudo firewall-cmd --complete-reload
# WARNING: Next commands will drop traffic
sudo ifdown eth0(コネクション名)
sudo ifup eth0(コネクション名)
sudo ifdown eth1(コネクション名)
sudo ifup eth1(コネクション名)
sudo firewall-cmd --list-all --zone=external
sudo firewall-cmd --list-all --zone=internal
```
* NTP hostの設定
```
sudo vi /etc/chrony.conf # 設定ファイルをviエディタで開きます
# 最初に以下を追加しました． (cf. https://chrony.tuxfamily.org/examples.htmlの項目２．ローカルサーバを使用したクライアントとソフトウェアタイムスタンピング)
server 130.158.108.3 iburst minpoll 2 maxpoll 2 xleave
sudo systemctl restart chronyd
chrony -n tracking
chrony -n sources
# 登録したローカルNTPサーバのIPアドレスが見えるようになりました．
```
## ssh接続時の注意
~~次のようなエラーメッセージが出ると思います．
これは，ゲートウェイサーバのIPアドレスの機体を違うものと交換したことによるもので，機体を認証する鍵が変化したために，違う機体なので危険ですと，警告しています．~~
```
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:HKT+XgCMRcVXIpi2sInutRxXyUKt/lmbUFvDfc20NhI.
Please contact your system administrator.
Add correct host key in /Users/leoota/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /Users/leoota/.ssh/known_hosts:2
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
Agent forwarding is disabled to avoid man-in-the-middle attacks.
UpdateHostkeys is disabled because the host key is not trusted.
Last login: Thu Oct 6 01:47:44 2022 from 133.51.116.102
```
~~今回は，一時的に新しい機材が来るまでの装置で，次に緊急時に再び対応するかもしれないという状況なのですが，上記のエラーの場合は，機体が以前と同じゲートウェイサーバなのに，フィンガープリントのための秘密鍵fingerprint for the ECDSA keyと違う装置であることを指摘して，異常を伝えてくれています．~~
```
/Users/leoota/.ssh/known_hosts:2という部分が
~/.ssh/known_hostsの中の２行目にあることを示しています．
```
~~今回は，装置の故障のため，やむをなく新しい機材に変更したという事情がわかっているので，接続しても大丈夫です．
/Users/leoota/.ssh/known_hosts:2
と出ている場合は，~~
```
vi /Users/leoota/.ssh/known_hosts +2
```
~~でファイルを開いて，以前の装置のフィンガープリントが記録された行をddと打って削除していくと，エラーが出なくなり，~/.ssh/configで設定した多段SSH接続をしても，エラーが出なくなります．~~
接続する前に，以下を実行してください．
```
ssh-keygen -R 130.158.108.54
ssh-keygen -R kdesvr1.ccs.tsukuba.ac.jp
```
~~でも同様な効果がありますので，こちらを利用した方が，作業量が少なくて良いと思います．~~
お手数をおかけしますが，ご確認を宜しくお願い申し上げます．
## 個別のCCS内部サーバのゲートウェイとDNS設定について
以下のように設定してください．
- gateway: 130.158.108.54
- dns: 130.158.108.3, 130.158.108.2
具体的には，nmcuiとnmtuiで互いに一致するように設定されているかを確認することが必要です．
nmtuiによって，少しわかりやすく設定できます．デスクトップのGUIからもUbuntuなら，右上のネットワーク設定からある程度は行えます．
```
sudo nmtui # カーソルとエンターで対象のコネクションを選択し，上記のgatewayとdnsの設定をしてください．
```
~~nmcuiによるコネクションの設定も必要です．~~ NetworkManagerとNetworkをCentOSではsystemctlでrestartされると使えるようになります．
```
nmcli d # デバイスとコネクション情報が見られます．
ip addr show enp1s0f0(コネクション名) # IP addressは正しく設定できていますか？ subnetmaskは，255.255.255.0, ２４です．
ip link show enp1s0f0 # UPとなっていますか？なっていない時は，ケーブルが刺さってないです．
nmcli n # connected
nmcli n c # full
sudo nmcli con edit enp1s0f0(connection name)
print ipv4
remove ipv4.gateway
set ipv4.gateway 130.158.108.54
set ipv4.dns 130.158.108.3, 130.158.108.2
save
quit
```
上記が設定し終わったら，ネットワークマネジャーなどを再起動します．
```
sudo systemctl restart NetworkManager
sudo systemctl restart networking
sudo systemctl restart systemd-networkd
```
しばらく待つと，外部へも接続ができるようになると思います．
```
ping google.com
```
お疲れ様でした．
## 最後に
非常に優れたサーバなので，本当は，ストレージ容量も大きいですし，CPUコアもEPICの強い装置なので，うまく並列化すると，速く計算できると思います．
なので，災害時の対策用のゲートウェイ候補としていただけますと幸いです．
普段は，計算に使用した方がいいと思います．
参考にしていただけますと幸いです．
どうぞ宜しくお願い申し上げます．
---
# `hpcsgitlab`の使い方（HPCSネットワーク外）
## 事前要件
- 使用するPCの管理者権限を持っていること
- Windowsの場合，これから説明する設定・コマンドは[WSL](https://docs.microsoft.com/ja-jp/windows/wsl/about)上で行うこと．
- `ssh`コマンドが実行できること．
- PC上でwebサーバ等を実行しておらず，`80`番ポートが使われていないこと．
- `kdesvr1.ccs.tsukuba.ac.jp`へのアカウント登録及び公開鍵設置．
## `.ssh/config`の編集
### ゲートウェイサーバ用設定
`hpcsgitlab`はHPCSネットワーク内部に設置されているため，ゲートウェイサーバ`kdesvr1.ccs.tsukuba.ac.jp`へのアカウント登録及び公開鍵設置が必要です．お済み出ない方は天笠先生にお願いし，下記設定をローカルマシンの`.ssh/config`に追加してください．
```
Host kdesvr1
User ユーザ名
IdentityFile 登録した公開鍵に対応する秘密鍵の場所
HostName kdesvr1.ccs.tsukuba.ac.jp
```
### Git認証用公開鍵の作成
Gitリポジトリを`clone`，`push`，`pull`をする際の認証用公開鍵を作成します．
```bash
ssh-keygen -t rsa -N '' -f ~/.ssh/id_rsa.hpcsgitlab
```
これで秘密鍵`~/.ssh/id_rsa.hpcsgitlab`と公開鍵`~/.ssh/id_rsa.hpcsgitlab.pub`のペアが作成されます．これらの鍵を認証時に使用するよう，`.ssh/config`に下記設定を追記してください．
```
Host hpcsgitlab
User git
IdentityFile ~/.ssh/id_rsa.hpcsgitlab
ProxyCommand ssh -W %h:%p kdesvr1
HostName 192.168.0.117
```
---
`hpcsgitlab`が提供するWeb管理画面を使うには，HPCSネットワーク内で`192.168.0.117:80`で待ち受けているポートを`localhost:80`に転送する必要があります．
ここで注意すべきなのは，ユーザのインタラクション操作による推移で`hpcsgitlab`が返すURLは常に`http://hpcsgitlab/`から始まることです．
すなわち，ホスト名`hpcsgitlab`が`127.0.0.1（localhost）`へと解決されなければならない，かつ，管理者権限が必要な`80`番ポートまで転送しなければなりません．
### hostsファイルの編集
ホスト名を解決するために，管理者権限でエディタを起動し`hosts`ファイルの末尾に以下を追加してください．
```
127.0.0.1 hpcsgitlab
```
ファイルの場所は以下にあります.
*nix系OS：`/etc/hosts`
Windows：`C:\Windows\System32\drivers\etc\hosts`
Windowsの場合はWSL内の`/etc/hosts`も同様に編集してください．
### rootとのSSH設定同期
最後に，管理者特権を要求する`80`番ポートへの転送を行うため，今までの`.ssh/config`の設定をrootと同期させてください．
```bash
sudo su -
ls -lah /root/.ssh #上書きされるファイルがないか確認
cp -r /home/ユーザ名/.ssh /root/
chmod 700 -R /root/.ssh
```
注：Macでは`/var/root/.ssh`に読み替えてください．
WindowsユーザでローカルのVSCodeから`hpcsgitlab`の操作が行いたい方は
さらに`C:\Users\ユーザ名\.ssh`と設定を同期させた後`C:\Users\ユーザ名\.ssh\config`のすべての
```
ProxyCommand ssh -W %h:%p
```
から始まる行を
```
ProxyCommand C:\Windows\System32\OpenSSH\ssh.exe -W %h:%p
```
へと置換してください．
注：`winver`:`1903`以降は置換は不要
### `80`番ポート転送
すべての設定が終わったら以下のコマンドでポート転送を行います．
```bash
sudo ssh -NL 80:192.168.0.117:80 kdesvr1
```
ブラウザを開き次のURLにアクセスしてください．
```
http://hpcsgitlab/
```
ログイン画面が表示されれば設定はうまくいっています．
🎉お疲れさまでした．
---
## Web管理画面の使い方
### ユーザアカウント作成
Registerタブから各種情報を記入し，
緑色のRegisterボタンをクリックしてください．
既にGitHubを使っているなどで
```
git config --global user.name
git config --global user.email
```
を既に設定されている方は，指定したユーザ名・メールアドレスでアカウント作成するとコンフリクトを回避できます．
ここで設定したユーザ名，パスワードは
`git clone http://hpcsgitlab/ユーザ名/プロジェクト名`
の形式で`clone`することでGitのHTTP認証で使うことができます．
しかし，`clone,push,pull`の度にユーザ名，パスワードが聞かれ，とても不便なので後述する[Git認証用公開鍵の登録](https://hackmd.io/QwL6KNUySNaqviIDlcmxIw?both#Git%E8%AA%8D%E8%A8%BC%E7%94%A8%E5%85%AC%E9%96%8B%E9%8D%B5%E3%81%AE%E7%99%BB%E9%8C%B2)をして
`git clone git@hpcsgitlab:ユーザ名/プロジェクト名`
の形式でSSH認証することを**強くおすすめします．**
### 日本語化
### Git認証用公開鍵の登録
[Git認証用公開鍵の作成](https://hackmd.io/QwL6KNUySNaqviIDlcmxIw#Git%E8%AA%8D%E8%A8%BC%E7%94%A8%E5%85%AC%E9%96%8B%E9%8D%B5%E3%81%AE%E4%BD%9C%E6%88%90)で作成した公開鍵`~/.ssh/id_rsa.hpcsgitlab.pub`の内容をコピーして次のように登録してください．
### プロジェクト作成チュートリアル
画面上に見える[+]アイコンから新規プロジェクトをクリックしてください．
今回は`hello_world`をプロジェクト名にしたので，これ以降このプロジェクトは`http://hpcsgitlab/ユーザ名/hello_world`で管理されます．また，
Visibility Levelはプライベートにすると自分以外から全く見えないプロジェクトになります．一方，パブリックにしてもワールドワイドに公開されるということはなく，HPCSネットワーク内の`hpcsgitlab`サーバにアクセスできる人しか見えません．後からプロジェクトに参加する人のことを考えるとパブリックにしておくのが無難でしょう．
赤枠で囲った部分を例にプロジェクトの作成・操作を行ってください．
### 変更履歴の確認方法
選択したコミットの差分が表示されます．
## Git-LFS
Gitはテキストファイルの差分を保存していくファイル管理システムです．
そのため，モデルのような大きなバイナリファイルの管理には向いておらずプロジェクトの操作が重くなってしまいます．
この問題はGit-LFSが解決できます．
Git-LFSを用いるとバイナリファイルは`.git/lfs`に格納されそのポインタをGitで管理します．
`push`の段階で `hpcsgitlab`でホストされているファイルサーバにアップロードされ，`pull`した際にポインタが示すバイナリファイルが`.git/lfs`に存在しない場合は自動的にファイルサーバからダウンロードされます．
このように上記の問題を解消しつつバイナリファイルの変更をGitで管理できるようになります．
### Git-LFSのインストール
最新のインストール情報は[Git-LFS Wiki](https://github.com/git-lfs/git-lfs/wiki/Installation)を参照してください．
##### Ubuntu/WSLの場合
```
curl -s https://packagecloud.io/install/repositories/github/git-lfs/script.deb.sh | sudo bash
sudo apt-get install git-lfs
git lfs install
```
##### Macの場合
```
brew update
brew install git-lfs
git lfs install
```
### Git-LFSの使い方
出典：[Git-LFS Tutorial](https://github.com/git-lfs/git-lfs/wiki/Tutorial)
[プロジェクト作成](https://hackmd.io/QwL6KNUySNaqviIDlcmxIw?both#%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E4%BD%9C%E6%88%90%E3%83%81%E3%83%A5%E3%83%BC%E3%83%88%E3%83%AA%E3%82%A2%E3%83%AB)をした後リポジトリの中に入ります．
```
git clone git@hpcsgitlab:ユーザ名/hello_world
cd hello_world
```
次にGit-LFSで追跡するバイナリファイルを試しに作成してみます．
```
dd if=/dev/urandom of=cat.bin bs=1048576 count=1
dd if=/dev/urandom of=dog.bin bs=1048576 count=1
```
Git-LFSを使う場合はここで1ステップ入ります．
```
git lfs track '*.bin'
```
これで`.gitattributes`に
```
*.bin filter=lfs diff=lfs merge=lfs -text
```
という内容の設定ファイルが生成されました．
これ以降拡張子`.bin`のバイナリファイルは
```
git add cat.bin dog.bin
```
などとすると自動的にGit-LFSを介して管理されるようになります．
生成された`.gitattributes`はGit管理することでcloneした人が同様のルールに基づいて
Git-LFSを使うことができます．追加しましょう．
```
git add .gitattributes
```
現在の`git status`は次のようになります．
```
Your branch is up-to-date with 'origin/master'.
コミット予定の変更点:
(use "git reset HEAD <file>..." to unstage)
new file: .gitattributes
new file: cat.bin
new file: dog.bin
```
通常のGit操作と同様に`commit`，`push`できます．
```
git commit -m "コミットメッセージ"
git push
```
`push`した段階でGit-LFSが動き，バイナリファイルがアップロードされます．
```
Locking support detected on remote "origin". Consider enabling it with:
$ git config lfs.https://hpcsgitlab/ユーザ名/hello_world.git/info/lfs.locksverify true
Uploading LFS objects: 100% (2/2), 2.1 MB | 0 B/s, done.
Counting objects: 5, done.
Delta compression using up to 56 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 641 bytes | 0 bytes/s, done.
Total 5 (delta 0), reused 0 (delta 0)
To git@hpcsgitlab:ユーザ名/hello_world
72f3de3..70b0883 master -> master
```
# HPCSネットワーク内での使い方
HPCSネットワーク内のマシンは`hpcsgitlab`の`22`番及び`80`番ポートに到達可能ですのでこれらのマシンでは特にポート転送の設定は不要です．
特に，HPCSネットワーク内IPアドレス`192.168.0.`の末尾`114,115,116,117,119,121,122,123`のマシンは既に`/etc/hosts`に次の行を追加しており，ホスト名解決ができます．
```
192.168.0.117 hpcsgitlab
```
そのためこれらのマシンは**認証情報さえ設定**すれば，今までのHPCSネットワーク外の例と同様に`hpcsgitlab`で管理しているプロジェクトの操作が可能です．
```
git clone git@hpcsgitlab:ユーザ名/プロジェクト名 #基本はこちら
git clone http://hpcsgitlab/ユーザ名/プロジェクト名 #どうしても鍵転送ができない場合はこちら
git add ファイル名
git commit -m "メッセージ"
git push
```
## `ssh-agent`のすすめ
### `ssh-agent`とは
これらHPCSネットワーク内のマシンに[Git認証用公開鍵の作成](https://hackmd.io/QwL6KNUySNaqviIDlcmxIw?both#Git%E8%AA%8D%E8%A8%BC%E7%94%A8%E5%85%AC%E9%96%8B%E9%8D%B5%E3%81%AE%E4%BD%9C%E6%88%90)の章で説明した手順で秘密鍵を設置すれば当然SSH認証できるのですが，これでは通信経路上に秘密鍵が野ざらしになってしまい危険ですし，複数あるマシンに同様の設定をしに行くのは大変です．
そこで，これらの問題は`ssh-agent`を使うことで解決ができます．
`ssh-agent`とは事前に秘密鍵をエージェントに登録することでssh先でもローカルと同等の認証を実現できる仕組みです．
なお，登録されたパスフレーズがstripされた秘密鍵はローカルのメモリ上にのみ保管され，接続先サーバでこの鍵を用いた認証が要求されると認証クエリである平文をポートを通じてローカルで受け取り暗号化して返し認証を行うため秘密鍵を外に持ち出さず安全です．
### `ssh-agent`の使い方
まず[HPCSネットワーク外での使い方](https://hackmd.io/QwL6KNUySNaqviIDlcmxIw?both#hpcsgitlab%E3%81%AE%E4%BD%BF%E3%81%84%E6%96%B9%EF%BC%88HPCS%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E5%A4%96%EF%BC%89)の設定を済ませたマシンを用意してください．
`ssh`コマンドが入っていれば既に`ssh-agent,ssh-add`も入っていると思います．
`.ssh/config`にエージェント転送を有効化する設定を追加してください．
```
ForwardAgent yes
```
次のように使うことができます．
```bash
eval $(ssh-agent) # agent起動，ターミナルを終了するまで有効
ssh-add ~/.ssh/id_rsa.hpcsgitlab # Git認証の秘密鍵を登録
ssh-add -l # 登録した鍵の確認
ssh hpcs121 # HPCSネットワーク内のマシンにログイン
ssh-add -l # ローカルで登録した鍵が見えるはず
git clone git@hpcsgitlab:ユーザ名/プロジェクト名
# 無事認証できれば成功です．
```
---
# 以降管理者向けメモ
## GitLab導入ログ
### Dockerインストール
[How To Install and Use Docker on Ubuntu 18.04](https://www.digitalocean.com/community/tutorials/how-to-install-and-use-docker-on-ubuntu-18-04)
を参考にした.
```bash
sudo apt update
#依存の解決
sudo apt install -y \
apt-transport-https \
ca-certificates \
curl \
software-properties-common
#Dockerの公式GPG keyを追加する
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
#stableのリポジトリ追加
sudo add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
sudo apt install docker-ce
```
### docker-composeインストール
[docker-compose公式](https://docs.docker.com/compose/install)より．配布されているバイナリを`/usr/local/bin`に配置して実行権限を付与する．
```bash
sudo curl -L "https://github.com/docker/compose/releases/download/1.25.4/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod 0755 /usr/local/bin/docker-compose
```
### Dockerを使ったGitLabの立ち上げ方
[GitLab公式](https://docs.gitlab.com/omnibus/docker/#after-starting-a-container)に基本的に従う．ただし，環境変数`GITLAB_OMNIBUS_CONFIG`で`/etc/gitlab/gitlab.rb`の設定を渡している．
```
sudo docker run --detach \
--hostname gitlab.example.com \
--publish 443:443 --publish 80:80 --publish 22:22 \
--name gitlab \
--restart always \
--volume /srv/gitlab/config:/etc/gitlab \
--volume /srv/gitlab/logs:/var/log/gitlab \
--volume /srv/gitlab/data:/var/opt/gitlab \
gitlab/gitlab-ce:latest
```
### バックアップ
[公式バックアップガイド](https://docs.gitlab.com/ee/raketasks/backup_restore.html#storing-configuration-files)によると最小でも，
- 鍵情報：`/etc/gitlab/gitlab-secrets.json`
- 設定情報：`/etc/gitlab/gitlab.rb`
を手動バックアップせよと書いてある．
しかし今回はDockerを用い，設定情報は`docker run`する際の環境変数`GITLAB_OMNIBUS_CONFIG`で渡している．
そのため，`/etc/gitlab/gitlab.rb`はアプリケーションを起動した後もコメントアウトが外されていないテンプレートのまっさらなままだった．
従って`/etc/gitlab/gitlab.rb`のバックアップはとらなくてよい．
[Dockerで立ち上げたGitLabの定期バックアップ方法](https://qiita.com/TomoyukiSugiyama/items/e9da7c873654cb86a14d)がよくまとまっている
```
docker exec -t hpcsgitlab gitlab-backup create
```
### バックアップからの復元
https://docs.gitlab.com/ee/raketasks/backup_restore.html#restore-for-omnibus-gitlab-installations
Sign in with Wallet
Connect another wallet