macOSにVagrantとVirtualBoxを使用した仮想環境を構築し、その中にLinuxをインストールする方法の覚え書きです。

流れ

• Vagrant ダウンロード・インストール
• VirtualBox ダウンロード・インストール
• Linux インストール
• Linux を使う

Vagrant ダウンロード・インストール

https://www.vagrantup.com/downloads.html

VirtualBox ダウンロード・インストール

https://www.virtualbox.org/wiki/Downloads

セキュリティ環境設定でブロックされたら許可してから再度インストール。

Linux インストール

Linux仮想環境をインストールするためのディレクトリを作成

mkdir -p ~/vagrant/ubuntu64_16
cd ~/vagrant/ubuntu64_16

Vagrantを実行してLinuxを仮想環境にインストール

vagrant box add ubuntu/xenial64

上記のダウンロード元は「Vagrant Cloud」という以下のサイト
末尾にURLをつけなければ最新版がダウンロードされる
https://app.vagrantup.com/ubuntu/boxes/xenial64

Vagrantを実行して仮想マシンの設定ファイルを作成

vagrant init ubuntu/xenial64

Linuxを使う

Vagrantを実行して仮想マシン上のLinuxを起動

vagrant up

SSH接続

$ vagrant ssh
Welcome to Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-154-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

0 packages can be updated.
0 updates are security updates.

New release '18.04.2 LTS' available.
Run 'do-release-upgrade' to upgrade to it.


vagrant@ubuntu-xenial:~$ 

SSH接続切断

exit

Vagrantを実行して仮想マシン終了

vagrant halt

わたしは片手間に、サーバやネットワークを やらされております。
（専門外なのに・・・）
先日、サーバのネットワークが つながらなくて困りました。

困った現象

ある Linux(CentOS7) サーバについて、もともと次の設定で運用していました。
※ 以下のＩＰアドレス等は、架空のものです。

ifcfg-em1（未使用）
ifcfg-em2 (192.168.1.10)（ローカルアドレス。使用中。）

つまり、サーバは外部に公開せず、ローカルで使っていました。
これに、グローバルアドレスを追加で有効にしたのです。

ifcfg-em1 (12.34.56.78)（グローバルアドレス。使用開始！）
ifcfg-em2 (192.168.1.10)（ローカルアドレス。使用中。）

ところが、グローバルアドレスに対して PING が通らないのです。
グローバルの ifcfg-em1 は確かにＵＰしているのに、です。

PING で調べる

いろいろ調べると、不思議な現象を確認しました。
グローバルアドレスと同じセグメントからなら PING が通ることに気づきました。

例えば、設定したグローバルアドレスが 12.34.56.78 なら、
12.34.56.80 の別サーバからは PING が通るのです。

（しかしセグメント外の、例えば自分のＰＣからは PING が通りません。）

さらに不思議なことに、まったく同じ設定の別のサーバでは、
グローバルアドレスに PING が通るのです。

別のサーバというのは、ＯＳや基本設定（２種類のネットワークを使う）は
同じで、ＩＰアドレスだけが異なるサーバのことです。

私はこの正常サーバと、今回の異常サーバで何が違うのか、
いろんなコマンドを投入して調べました。

ファイル比較で相違点を発見

ようやく相違点を発見しました。
正常／異常サーバで、GENERAL.DEFAULT なるものが違っていました。

異常サーバのグローバルアドレス

# nmcli c s em1
    ：
GENERAL.DEVICES:  em1
GENERAL.STATE:    アクティベート済み
GENERAL.DEFAULT:  いいえ
    ：

同じく異常サーバのローカルアドレス

# nmcli c s em2
    ：
GENERAL.DEVICES:  em2
GENERAL.STATE:    アクティベート済み
GENERAL.DEFAULT:  はい
    ：

上記は異常サーバですが、正常サーバでは、
はい／いいえ がどちらも反転していたのです。
（グローバル側が「はい」、ローカル側が「いいえ」でした。）

さらに、ルーティングテーブル？（←ゴメン よく知らないの）の順番も
違うことに気づきました。（ローカル側が上に表示されていました。）

# ip route

default via 192.168.1.1 dev em2 proto static metric 102
default via 12.34.56.1 dev em1 proto static metric 101

これも正常サーバでは、順番が逆でした。

ＯＳによるゲートウェイ設定の違い

冒頭に述べたとおり、わたしは片手間にサーバを担当しています。

以前は CentOS5 を扱っていて、ゲートウェイの設定箇所は
/etc/sysconfig/network の１ヶ所でした。

今回の問題のサーバは CentOS7 で、ゲートウェイは
ネットワークごとに複数箇所で設定できるようです。つまり、
/etc/sysconfig/network-scripts/ifcfg-em1 でも設定できるし、
/etc/sysconfig/network-scripts/ifcfg-em2 でも設定できます。

なので、「グローバル／ローカル 両方にゲートウェイを設定するんだな」
と理解していました。実際それで、問題なく運用しているサーバもありました。

しかし もしかしたら、それは たまたま上手くいっていただけかもしれません。
よくよく考えたら、ゲートウェイが複数ってのは妙です。
サーバから外部に通信するとき、ゲートウェイは１つで十分だからです。

もし２つあれば、どちらかを優先して、もう一方は使われないんじゃないか・・・？
その使われないほうが、グローバルアドレスのゲートウェイなのでは・・・？
だから外部から PING が通らないんじゃないか・・・？

おぼろげながら原因が見えてきました。
ただ残念なことに、どんなコマンドで修正すればよいか分かりませんでした。

コマンドはあきらめ、設定ファイルを直接 修正することにしました。
（ネットでは、設定ファイルの直接の修正は非推奨で、
コマンドを使えとありましたが、私には それしか方法がありませんでした。）

/etc/sysconfig/network-scripts/ifcfg-em2（ローカルアドレス）の
ゲートウェイの行を削除し、サーバを再起動しました。

    ：
DEVICE=em2
ONBOOT=yes
IPADDR=192.168.1.10
PREFIX=24
GATEWAY=192.168.1.1   ← ← ← 削除
    ：

結果は・・・？

グローバルアドレスに対して PING が通りました！！
（よかったよかった）

やはりゲートウェイを複数 設定していて、ローカルの方が優先されていたから、
グローバルのほうが無視されていたようです。

それにしても、疑問が残ります。
複数のゲートウェイを設定していて、グローバルアドレスに つながるサーバもあります。
（この場合はローカル側のゲートウェイが無視されているはず。）

どちらを優先するか、どう決めているのでしょう？？？
そういえば、正常／異常サーバの違いがありました。

正常サーバでは、グローバル／ローカルアドレスを、最初から両方ＵＰしていました。
一方 異常サーバでは、最初 ローカルアドレスのみをＵＰしていて、
後でグローバルアドレスを追加でＵＰしました。違いといえば それくらいです。

この対応のために、１日無駄にしてしまいました。
サーバ専門の担当者を雇ってほしい・・・。

はじめに

sudoで実行ユーザのPATHを引き継ぐ方法を検索すると、こちらの記事などがヒットし、それで目標は達成できます。
なぜできるのかということについて調べ、より良い解決策を得たため、記録しておきます。

環境

Ubuntu xenial

本文

secure_path

そもそも、なぜPATH環境変数は引き継がれないのでしょうか。それを知るにはsudoersファイルを見てみましょう。
すると、やはりこの行があると思います。

Defaults      secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/
sbin:/bin:/snap/bin"

これは一体どういう意味なのか、sudoのmanページを見てみます。

デフォルト設定 (Defaults)
かなりの設定オプションが、 一行以上の Default_Entry 行を指定することで実行時にデフォルトの値から変更可能だ。

Default_Type ::= 'Defaults' |
                 'Defaults' '@' Host_List |
                 'Defaults' ':' User_List |
                 'Defaults' '!' Cmnd_List |
                 'Defaults' '>' Runas_List

Default_Entry ::= Default_Type Parameter_List

Parameter_List ::= Parameter |
                   Parameter ',' Parameter_List

Parameter ::= Parameter '=' Value |
              Parameter '+=' Value |
              Parameter '-=' Value |
              '!'* Parameter

つまり問題の行は、secure_path設定オプションを設定しているということです。ではsecure_path設定オプションとはなんなのか。

secure_path
sudo から実行されるあらゆるコマンドが使用するパス。 sudo を実行するユーザが、無難な PATH 環境変数 を使っているかどうか確信が持てないなら、 このオプションを使用するとよいだろう。もう一つの使用法は、 「root のパス」と「一般ユーザのパス」を別のものにしておきたい場合だ。 ユーザが exempt_group オプションで指定したグループに属していると、 そのユーザは secure_path の影響を受けない。 このオプションは、デフォルトではセットされていない。

ということで、これが設定されているとユーザのPATHが無視されるということですね。だから、これをコメントアウトしようという解決策が出るわけです。
しかし、このオプションは安全のために設定されているので、それをまるっと無視することは少しためらいます。
改めてmanページを見ますと、Defaults行について

その効果の及ぶ範囲は、あらゆるホストのすべてのユーザにすることもできるし、 ある特定のホストのすべてのユーザ、ある特定のユーザ、ある特定のコマンド、 ある特定のユーザとして実行するコマンドなどに限定することもできる。

とあるので、特定のユーザだけsecure_path設定オプションが適用されないようにするのがよいでしょう。更に、Defaults行の書式について

User_List ::= User |
              User ',' User_List

User ::= '!'* user name |
         '!'* #uid |
         '!'* %group |
         '!'* %#gid |
         '!'* +netgroup |
         '!'* %:nonunix_group |
         '!'* %:#nonunix_gid |
         '!'* User_Alias

とあるので、こう書くと良いでしょう。

Defaults:!exampleuser secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/
sbin:/bin:/snap/bin"

これでexampleuserだけsecure_path設定オプションが適用されないようになります。

他にやること

さて、secure_path設定オプションを外したわけですが、まだなにかやることがあるのでしょうか。よくある解決法としては次にenv_keep設定オプションでPATHが引き継がれるようにしていますが、これはなんなのか。

env_keep
env_reset オプションが有効になっているときでも、 ユーザの環境にそのまま保存される環境変数。このオプションによって、 sudo から生み出されるプロセスが受け取る環境を、 きめ細かく制御することが可能になる。このオプションの引き数は、 ダブルクォートで囲まれ、スペースで区切られたリストでもよく、 ダブルクォートなしの単一の値でもよい。 リストは、=, +=, -=, ! 演算子を使って、 それぞれ置き換えたり、追加したり、削除したり、無効にしたりすることができる。 保存される変数のグローバルなリストは、root ユーザが sudo に -V オプションを付けて実行したときに表示される。

とあります。確かに必要そうな気がしますが、ここはまずデフォルトの内容を確認しましょう。

$ sudo sudo -V

出力の「保護する環境変数」（ロケールによっては英語）を見てみますと、僕の環境では既にPATHが入っていました。つまり、env_keep設定オプションをいじる必要はないということです。
もし入っていない場合は設定する必要がありますが、ここでもユーザを絞っておきましょう。

Defaults:exampleuser    env_keep +=  "PATH"

まとめ

多分

Defaults:!exampleuser secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/
sbin:/bin:/snap/bin"

とするだけで十分です。

追記

linuxのexpandコマンドを使用することで、同等のことができます。
下記の内容は車輪の再発明でした。

タブをスペースに変換するスクリプト

作成理由など

複数のファイルのインデントを、タブ形式からスペース形式に変換する必要があった。
そのまま置換するだけではインデントが崩れてしまうため、自分でインデントが崩れないようにタブをスペースに変換するスクリプトを作成した。

なお、調べるとブラウザ上で同じ機能を持つものがあったが、ネット上にソースコード(仕事で使用するソースコード)を上げることはできないため、そちらの使用はできなかった。

ちなみに、pythonで記載した理由は、linuxで標準でインストールされているという話を聞き、私と同じようにタブをスペースに変換する必要がある人にとって使いやすいと思ったから。

スクリプト

import os
import sys
import glob

#==============================
TAB_CHAR     = "\t"
SPACE_CHAR   = ' '
TAB_WIDTH    = 4
IN_DIR_PATH  = sys.argv[1]
OUT_DIR_PATH = sys.argv[2]

#==============================
space_width = {}
for mod in range(TAB_WIDTH):
  space_width[mod] = TAB_WIDTH - mod

#==============================
def line_of_tab_to_space(line):
  if line.find(TAB_CHAR) == -1: return line
  replace_source_string      = line[0:(line.find(TAB_CHAR) + 1)]
  replace_destination_string = tab_char_to_space_char(replace_source_string)
  return line_of_tab_to_space(line.replace(replace_source_string, replace_destination_string, 1))

def tab_char_to_space_char(part_line):
  if part_line.find("\t") != len(part_line) - 1: raise Exception
  return part_line.replace(TAB_CHAR, SPACE_CHAR * space_width[(len(part_line) - 1) % TAB_WIDTH])

#==============================
for file_path in glob.glob(IN_DIR_PATH + '/*'):
  in_file  = open(file_path, 'r')
  out_file = open(OUT_DIR_PATH + '/' + os.path.basename(file_path), 'a')
  for line in in_file:
    out_file.write(line_of_tab_to_space(line))
  in_file.close()
  out_file.close()

使用方法

下記のように実行してください。
適当な名前のファイルに、上記スクリプトの内容をコピーして使用してください。
下記ではtab_to_space.pyというファイル名にしております。

python3 tab_to_space.py <変換したいファイルが存在するディレクトリ> <出力先ディレクトリ>

下記は使用例です。実行する際のディレクトリ構造と叩くコマンドを記載しておきます。

〇 ディレクトリ構造
├── in
│   ├── test.txt
│   └── test_1.txt
├── out
└── tab_to_space.py

〇 実行コマンド
python3 tab_to_space.py in out

rearで起動イメージとデータを1ISOにアーカイブしようとしたときに、ハマった点をめも。

• 1ISOファイルが4GB-1Byteを超えると、アーカイブに失敗する。

genisoimageパッケージの仕様らしい。
Xorrisofsというパッケージなら容量制限は突破できるらしいが、
バックアップを作れてもbootはできなかった、という記載もあった。

参考

https://bugzilla.redhat.com/show_bug.cgi?id=1462189

てわけで、以下の定義ファイルのように、1ISOに入れないようにした。

# Default is to create Relax-and-Recover rescue media as ISO image
# set OUTPUT to change that
# set BACKUP to activate an automated (backup and) restore of your data
# Possible configuration values can be found in /usr/share/rear/conf/default.conf
#
# This file (local.conf) is intended for manual configuration. For configuration
# through packages and other automated means we recommend creating a new
# file named site.conf next to this file and to leave the local.conf as it is.
# Our packages will never ship with a site.conf.
OUTPUT=ISO
OUTPUT_URL="file:///var/tmp/rescue"
BACKUP=NETFS
BACKUP_URL="file:///var/tmp/data"

コマンド実行は以下。

TMPDIR="/var/tmp" rear mkrescue
TMPDIR="/var/tmp" rear mkbackuponly

もしくは
TMPDIR="/var/tmp" rear mkbackup

rearバックアップ時の一時領域

通常であれば、/tmpが使われる。しかし、起動イメージ内にバックアップデータも含めたりすると、
/tmpが溢れてしまい、こんな感じになってしまう。

cp: cannot create regular file '/tmp/rear.vZcBEdh17zZY11r/tmp/isofs/backup/backup.log': No space left on device

回避策は以下。

TMPDIR="/var/tmp" rear mkbackup

TMPDIR変数をexportするのはだめらしい。最新だとできるのかもしれないが、試してない。

https://github.com/rear/rear/issues/967