仮想マシンの共有フォルダを有効にする
Windowsホスト上のフォルダーをゲストOSのSLES15.1と共有させたいときの設定方法。
VMware Workstation Proの設定は以下のサイトに記述。
主な作業画面は以下。
D:\vm\shredFolder が共有されるフォルダーのパス。
この設定だけでは、ゲストOS側から共有フォルダ―が見えなかったので、VMware Toolsのインストールを追加作業として実施(以下)。
- VMware Workstationウィンドウで、VM> VMware Toolsの再インストール
- ウィンドウの下に、tarで解凍してxx.plを実行する旨がポップアップ表示
- VMware Toolsのフォルダーがマウントされたディレクトリを調べる
- cd /run/media/root/VMware\ Tools/
tar xvfz VMwareTools-10.3.10-13959562.tar.gz --directory=/tmp - Toolsはvmwa-tools-distribディレクトリに展開される
- cd /mp/vmwa-tools-distrib
- ./vmware-install.pl
- 対話形式で入力要求が来るがほとんどデフォルト、但し、以下のhgfsに関するものについてはyesでoverwriteを選択した。
- completed successfully で終われば完了。
以上。(2019/10/18)
SLES15.1でrootのsshができないときの対処
SUSE Linux Enterprise Server for SAP Applications 15 SP1(以降SLES)をインストール直後にROOTによるSSHを可能にするための備忘録
> systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor p>
Active: active (running) since Wed 2019-10-16 21:10:50 JST; 3s ago
Docs: man:firewalld(1)
Main PID: 21954 (firewalld)
Tasks: 2 (limit: 19660)
CGroup: /system.slice/firewalld.service
└─21954 /usr/bin/python3 -Es /usr/sbin/firewalld --nofork --nopid
Oct 16 21:10:50 node01 systemd[1]: Starting firewalld - dynamic firewall daemon>
Oct 16 21:10:50 node01 systemd[1]: Started firewalld - dynamic firewall daemon.
動いているので、sshをサービスに加える。
> firewall-cmd --permanent --add-service=ssh
success
firewalldをリロード。
>firewall-cmd --reload
success
次にsshdの状態を確認。
> systemctl staus sshd
● sshd.service - OpenSSH Daemon● sshd.service - OpenSSH Daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; disabled; vendor prese>
Active: inactive (dead)
inactiveなので取り敢えず起動する。
> systemctl start sshd
sshdの状態を確認。
> systemctl staus sshd
● sshd.service - OpenSSH Daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; disabled; vendor prese>
Active: active (running) since Wed 2019-10-16 21:22:16 JST; 14s ago
Process: 22489 ExecStartPre=/usr/sbin/sshd -t $SSHD_OPTS (code=exited, status>
Process: 22486 ExecStartPre=/usr/sbin/sshd-gen-keys-start (code=exited, statu>
Main PID: 22490 (sshd)
Tasks: 1
CGroup: /system.slice/sshd.service
└─22490 /usr/sbin/sshd -D
Oct 16 21:22:16 node01 systemd[1]: Starting OpenSSH Daemon...
Oct 16 21:22:16 node01 sshd-gen-keys-start[22486]: Checking for missing server >
Oct 16 21:22:16 node01 sshd[22490]: Server listening on 0.0.0.0 port 22.
Oct 16 21:22:16 node01 sshd[22490]: Server listening on :: port 22.
Oct 16 21:22:16 node01 systemd[1]: Started OpenSSH Daemon.
次回OS起動時に自動的に立ち上がるようにする。
> systemctl enable sshd
reated symlink /etc/systemd/system/multi-user.target.wants/sshd.service → /usr/lib/systemd/system/sshd.service.
以上でroot以外はsshできるようになるので、rootのログインを可能にする。
>vi /etc/ssh/sshd_config
PermitRootLogin no
を
PermitRootLogin yes
に修正。
修正を有効にするためにリスタート。
> systemctl restart sshd
以上でsshできるようになるが、firewalldの設定ではなく、止めたいときは、
> systemctl stop firewalld
以上。
VMnet1とVMnet8の整理
VMwareのデスクトップ製品を使用していると、外部ネットワークとの接続方式の選択/設定に毎回とまどう割に場当たり的に済ましてきたしまった、これまで。VMware Workstation Proが標準インストールされるPCを配布されるような会社に入ったので、ここらでVMnet1とVMnet8あたりを整理。
VMware Workstaion ProをインストールしたWindowsでLANアダプターを見ると、ローカル エリア接続* 1などの通常のセットワーク接続に使用するアダプターとは別に、
といったアダプターが見られる。(↓)
これは、ホストOS(今回の場合はWindows)とゲストOSをネットワーク的に接続するためのホストOS側のネットワークアダプター。仮想マシン側のネットワークアダプターとは(イメージとして)10BaseTケーブルなどで物理接続されていると考えればよく、適切なIPアドレスをゲストOSに設定するとホストOS⇔ゲストOS間の通信ができる、というのが基本的な考え方。
ホストOS側のアダプターが複数あるのは、外部ネットワーク(ゲストOSから見たとき、ホストOSの向こう側)との接続方式を、アダプターの選択で切り替えられるようにしているから。つまり、デフォルトの状態では、ホストオンリーとNATという接続方式が有効になっているからそれぞれ専用のVMnet1(ホストオンリー)、VMnet8(NAT)がある。
だから、
- ホストOSと通信できれば良い、外部ネットワークとは繋がない、というときには、上記引用画像でいうと、VMnet1(192.168.174.1)と通信すればよいので、ゲストOS側ネットワークアダプターに192.168.174.2~192.168.174.255というIPアドレスを指定すればよい。
- 外部ネットワークとも通信する必要がある場合には、同じく上記画像でいうと、VMnet8(192.168.234.1)と通信すればよいので、ゲストOS側ネットワークアダプターに192.168.234.2~192.168.234.255というIPアドレスを指定すればよい。
ということになる。
ちなみに、ホストオンリー、NAT以外に
- ブリッジ
- カスタム
- LANセグメント(ゲストOS同志の接続のみしたい場合)
というのもあるが、考え方は基本的に同じ。
以上。
2019/10/16
AWS NATゲートウェイの基礎
NAT(ネットワークアドレス変換)ゲートウェイとは?
プライベートサブネットのインスタンスが、インターネット上のインスタンスやAWSの他のサービスにアクセスする必要があるけれども、外からはアクセスできないようにしたい場合に使用する。
課金
使用時間料金とデータ処理料金
概要
- パブリックサブネットを常駐先として指定する必要がある。
- Elastic IPアドレスを関連付ける必要がある。(これは変更できない。)
- プライベートサブネットのルーティングテーブルに、ルートを追加してNATゲートウェイに通信を向かせるようにする。
- (パブリックサブネットのルーティングテーブルは、当然、インターネットゲートウェイに通信が向かっている。)
あとは、以下を参照。
NAT ゲートウェイ - Amazon Virtual Private Cloud
以上。
AWS EC2でパブリックDNS/IPが割り当てられない
AWS EC2でデフォルトのVPCを使わない場合、つまり新しいVPCを作ってそのVPC内にEC2インスタンスを作成する場合、パブリックDNS/IPが割り当てられないことがある。
規定値では、パブリックDNS/IPが割り当てられないようになっているので以下の設定が必要。
- VPC作成時に、「DNS解決」と「DNSホスト名」を有効にする。
- VPCにルートテーブルを作成し、インターネット公開の設定を行う
- VPCにぶら下がるサブネット作成時に、パブリックアドレスの自動設定を有効にする。
- EC2インスタンスを作成時に「インスタンスの詳細設定画面」で、「パブリックIPの自動割り当て」で自動割り当てを有効に設定したサブネットを選択(または、「有効」を選択)
1.と2.については、https://qiita.com/mesaka/items/85ef45f7eb9618acbdfe
3.と4.については、https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip を参照。
2019/090/20
スコーンと頭に意味が入ってこなかった英文(その1)
対して難しくない英文なのに、瞬間的に意味が頭に浮かばな英文に出くわしたので備忘録。
Sexual harassment occurs when any such behaviour creates an intimidating, hostile or offensive environment for employment, for study or for social life.
一読して「性的嫌がらせのような振る舞いが、雇用、学習、社会生活にとって脅かし、敵対し、攻撃的であるような環境を作り出すとき性的嫌がらせは発生する。」と反射的に不思議な解釈してしまった。
文の構造がわかるように、改行・インデントを入れてみるとany such behaviourの指す方向を間違えてしまったことに気が付く。
Sexual harassment occurs
when any such behaviour creates
an intimidating, hostile or offensive environment
for employment,
for study or
for social life.
つまり、最初の誤った解釈では、語と語の距離が近いものだからany such behaviour=Sexual harassmentと短絡的に解釈してしまったが、実際は、
any such behaviour= any behaviours that creates an intimidating, hostile or offensive environment for employment, for study or for social life.
と理解すべき(?)。
そうすれば、「雇用、学習、社会生活を脅かし、敵対し、攻撃的であるような環境を作り出す(そんな)行為がおこなわれるときは必ず、性的嫌がらせがはびこる」と意味的にスコーンと腹落ちする解釈ができる気がする。
(了)
Mac上でUSBブートディスクを作る
- diskutil listでデバイス情報を得る。
- diskutil eraseDisk MS-DOS 'USB DISK' <device-name>で再フォーマット
- diskutil umountDisk /dev/diskN でアンマウント
- ddコマンドでisoイメージをUSBメモリーに書き込む
- diskutil eject /dev/diskNで取り外す
例