h-otterの備忘録

インフラを中心にコンピュータ関連をいいかんじにやっていきます

Hyper-V上のLinuxの解像度を変更する

Hyper-VゲストにはVirtual Machine Connectionというアプリケーションでアクセスできますが、解像度は基本固定になっています。今回は変更する方法を紹介します。

環境

方法

grubをいじって解像度を変更します。そのためディストリビューションによって方法が異なります。大分した、それぞれの紹介記事が以下のようになります。

RedHat系: typea.info

Debian系: statemachine.hatenablog.com

今回はDebian系を説明します。

  1. /etc/default/grubGRUB_CMDLINE_LINUX_DEFAULT=の行を以下のように書き換えます。
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=hyperv_fb:1366x768"
  1. grubを更新し、再起動します
$ sudo update-grub
$ sudo reboot now

環境として挙げた組み合わせではすべて確認しました。これで狭い解像度に悩まされずに作業ができますね。

sshのアクセスを制限する

sshはIPとログインユーザーによって制限をかけることができます。pamを使ってやります。

kazmax.zpp.jp

6.1. pam_access - logdaemon style login access control

といっても、以上の2つのサイトに書かれていることをやれば間違いないでしょう。/etc/security/access.confの構文はそのファイル自身に書いてある説明が一番わかりやすいと思います。要約だけ。

  • /etc/security/access.confの設定を行う
    • [permission(+ or -)] : [user] : [access_from(IP etc.)]といった構文でアクセスの許可と不許可を設定
    • EXCEPTで例外指定
  • sshdのpamで/etc/security/access.confを有効化
    • /etc/pam.d/sshdコメントアウトされているaccount required pam_access.soの行をアンコメント
  • sshの再起動
    • $ sudo service ssh restart
  • TEST

信頼関係とGPO

信頼関係を結んでいるリソースに適用されるGPOの関係です。以下のサイトがよくまとまっているので読んでみてください。

[AD] 信頼関係とフォレスト間のGPO適用について | インフラSEの運用・構築メモ

要約すると、

  • デフォルトではリソースの所属しているドメインのコンピュータポリシーとユーザーポリシーが適用される
  • 「フォレスト間のユーザー ポリシーおよび移動ユーザー プロファイルを許可する」を有効化するとユーザーが所属しているドメインのユーザーポリシーが適用される

という感じです。

Hyper-Vの第2世代

今更感がありますがWindows Server 2012 R2には第2世代という種類の仮想化ゲストが用意されています。いろいろ機能が拡張されていますが特にUEFIブートになったことが大きいです。自分が引っかかった第2世代に関することのまとめです。

Ubuntuのインストール

Ubuntuも第2世代にするといろいろな恩恵を受けられますがいくつか注意点があります。サポート情報などはMicrosoft Technetの以下のページを見るとよいでしょう。

Supported guest operating systems for Hyper-V virtual machines

Ubuntu virtual machines on Hyper-V

Secure Bootをオフにする

UEFIにはSecure BootというモードがありますがUbuntuは対応していません。ブートするにはオフにする必要があります。

Powershellにて以下のように入力するか、

Set-VMFirmware –VMName "VMname" -EnableSecureBoot Off

Hyper-V マネージャーの"設定"を開いてファームウェアの項目からセキュアブートを無効化します。

f:id:h-otter:20151029193614p:plain

シャットダウンができない

Ubuntuをうまくシャットダウンできないことがありました。リブートも同様です。

  • ゲスト側からシャットダウンするとシステムは落ちているのにホストは実行中の状態だと認識している。ホスト側からもう一度シャットダウンする必要がある。
  • ホスト側からシャットダウンするとシステムは落ちているのにホストが認識せずに5分間待たされる。もう一度ホスト側からシャットダウンする必要がある。

というような状態になっていました。Ubuntu 14.04.3 LTSになってからはちゃんとシャットダウンできているのでアップグレードするのがいいんじゃないでしょうか。原因はGRUBにあるようで以下のサイトには具体的な対処法が載っています。

山市良のえぬなんとかわーるど: Windows Server 2012 R2 Hyper-V and Ubuntu 14.04 LTS Guest

第1世代を第2世代に移行する

Windowsに限られますが第1世代の仮想化ゲストを第2世代に移行する方法があります。

  1. 仮想化ゲストのWinRM有効化します
  2. Windows Hyper-V generation 2 VM conversion utility (Convert-VMGeneration) sampleを仮想化ホストで実行します

やはり細かい設定などがあるようでクリーンインストールすることが推奨のようです。

動的メモリ

Ubuntuも対応している動的メモリですが注意が必要です。DBやWebフレームワークのようなメモリを大きく使うアプリケーションを動かしているサーバーには適していません。

ebi.dyndns.biz

自分はWSUSを動的メモリで運用していた時に同様にとても不安定になりました。使い分けが重要ですね。

/bootの空き容量がなくなった場合

/bootの空き容量がなくなるとlinuxイメージの更新ができなくなります。そのため、ユーザーは古いイメージを削除する必要がありますが今回稀有な例に遭遇したみたいなのでその解決法を書いていきたいと思います。

環境

一般的な解決方法

一般的には最新のlinuxイメージと念のため一つ前のイメージさえ用意しておけばよいそうです。以下のコマンドで削除します。

$ uname -a
Linux TEST 3.13.0-62-generic #102-Ubuntu SMP Tue Aug 11 14:29:36 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
$ dpkg --get-selections | grep linux-image
linux-image-3.13.0-32-generic                   install
linux-image-3.13.0-57-generic                   install
linux-image-3.13.0-58-generic                   install
linux-image-3.13.0-59-generic                   install
linux-image-3.13.0-61-generic                   install
linux-image-3.13.0-62-generic                   install
linux-image-3.13.0-63-generic                   install
linux-image-extra-3.13.0-32-generic             install
linux-image-extra-3.13.0-57-generic             install
linux-image-extra-3.13.0-58-generic             install
linux-image-extra-3.13.0-59-generic             install
linux-image-extra-3.13.0-61-generic             install
linux-image-extra-3.13.0-62-generic             install
linux-image-extra-3.13.0-63-generic             install
linux-image-extra-3.13.0-65-generic             install
$ sudo apt-get --purge autoremove linux-image-{linuxのバージョン}-generic

unameで今動いているイメージを確認し、dpkgで削除するイメージを決めます。あとはapt-getで削除するだけです。

今回の場合

今回何が起きたのか以下のようになりました。(仮想化ゲストすべて…)

$ sudo apt-get autoremove
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
これらを直すためには 'apt-get -f install' を実行する必要があるかもしれません。
以下のパッケージには満たせない依存関係があります:
 linux-image-extra-3.13.0-65-generic : 依存: linux-image-3.13.0-65-generic しかし、インストールされていません
 linux-signed-image-3.13.0-65-generic : 依存: linux-image-3.13.0-65-generic (= 3.13.0-65.105) しかし、インストールされていません
E: 未解決の依存関係があります。-f オプションを試してください

apt-getすべてにロックがかかっており、依存関係を解決しようにも/bootがいっぱいなので不可能でした。解決方法は案外簡単で、aptitudeを使ってイメージを削除しました。

$ sudo aptitude remove linux-image-{linuxのバージョン}-generic
$ sudo apt-get update
$ sudo apt-get autoremove
$ sudo apt-get upgrade

aptitudeをつかうと依存関係に障害をきたしているパッケージを削除してくれるので、古いイメージを削除できたようですね。あとは通常通り不必要なイメージを削除していけば大丈夫です。

今回得た教訓はこまめにapt-get autoremoveすることとzabbixの警告に耳を傾けることですね…。

inline関数などの評価

C++を最近勉強しているのですが、inline関数って本当に早いのか実験してみました。

環境

  • ubuntu 14.04.3 LTS
  • g++
  • 仮想化環境
    • i7 2600k
    • 24GB

正直こういう検証には適さない環境ですが許してください。

コード

cpp_test/inline at master · h-otter/cpp_test · GitHub

検証だけしたかったのでコピペの嵐です。(言い訳)もしコードをスマートにする方法があれば教えてください。

結果

TEST; InlineFunction()
duration = 0.870657sec.
TEST; StaticFunction()
duration = 0.834252sec.
TEST; ConstFunction()
duration = 0.94697sec.
TEST; DefaultFunction()
duration = 0.829023sec.
TEST; InlineFunction(long long int)
duration = 0.981507sec.
TEST; StaticFunction(long long int)
duration = 1.00625sec.
TEST; ConstFunction(long long int)
duration = 1.01302sec.
TEST; DefaultFunction(long long int)
duration = 1.00517sec.

f:id:h-otter:20150908224509p:plain f:id:h-otter:20150908224511p:plain

考察

  • 引数がなければinlineはむしろ遅い
  • 引数が多ければ多いほどinlineのほうが早い(理論的には納得)
  • 実はconstが一番遅い
  • staticと普通の関数に大きな変化はない

検証しているものが少ないですが、大体こんな感じにまとめられると思います。しかし、inlineを使うのは速度じゃなくてメモリのオーバーヘッドを減らすことが主な目的だと思うのでこの結果を鵜呑みにする必要はないですね。

pam_mountを使ってsshをする方法

h-otter.hatenablog.jp

以上の記事で説明した通りホームディレクトリにcifsの共有フォルダをマウントすると、ssh鍵がうまく認証されない問題が起こります。gitlabのcloneができなくて長時間悩みました。

具体的に言うとcifsでマウントしたファイルはchmodでパーミッションを変更することができません。しかしssh鍵を利用するためには秘密鍵パーミッションを最低限にする必要があり、もし最低限に設定されてない場合以下のようなエラーが発生してアクセスすることができません。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '/home/user/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /home/user/.ssh/id_rsa

今回はホームディレクトリに共有にアクセスするディレクトリを作成し、そこにマウントすることでsshキーのパーミッションの問題を解決しようと思います。

環境

クライアント

  • ubuntu 14.04.3 LTS
  • ホームディレクトリ構造
/home/user
├ .ssh
│ ├ id_rsa
│ ├ id_rsa.pub
│ └ known_hosts
└ private (ここにマウント)

ファイルサーバー

操作

pam_mountの更新

pam_mountを/home/user/privateにマウントするように変更します。

/etc/security/pam_mount.conf.xml

                <!-- Volume definitions -->
<volume
user="*"
server="file.domain.local"
path="private"
mountpoint="home"
fstype="cifs"
/>

<cifsmount>mount -t cifs //%(SERVER)/%(VOLUME)/%(USER) %(MNTPT)/%(USER)/private -o "user=%(USER),uid=%(USERUID),gid=%(USERGID)%(before=\",\" OPTIONS)"</cifsmount>

<umount>umount %(MNTPT)/%(USER)/private</umount>

                <!-- pam_mount parameters: General tunables -->

<!-- 下のほう -->
<mkmountpoint enable="1" remove="false" />

skelの変更

pamを設定しておけば初ログイン時に/etc/skelをひな形にして、ホームディレクトリを自動的に作成することができます。詳細は前述した記事を参考にしてください。今回はskelを変更し、マウントする先のディレクトリを前もって作っておきます。

$ sudo mkdir /etc/skel/private

以上で設定は完了です。

注意点

最初にログインしたときには共有フォルダがマウントされません。2回目以降は問題なくマウントされることから、マウントの処理→ホームディレクトリの作成という順で処理しているため最初はマウント先のディレクトリが用意されておらずうまくマウントされないのだと考えています。対策を考えているので後日また記事にするかもしれません。