Ubuntu上のVMPlayerでコミPo!を動かす

Ubuntu上のVMware Workstation 14 PlayerでWindowsを動かし、コミPo!を起動しようとしたんですが

「DirectXの初期化に失敗しました。デバイス能力が取得できません。(E21)」

とのエラーが出て動きませんでした。

環境
仮想ソフト:VMware Workstation 14 Player
ホストOS:Ubuntu 16.04
ゲストOS:Windows Server 2008 R2(Windows 7ベース)

これは仮想環境のスペックが足りてないだけだなとの勘が働き、以下のような設定をすることで無事起動するようになりました

コミPo!の推奨環境を超えていればいいんだと思いますが、結構与えてみました。
それでももっさりとしか動かないのが残念でした、はい。

Ubuntu上のVMPlayerで動いているWindowsに、ホストを介さずスマートカードリーダー(PC/SC, CCID)を接続する

Ubuntu上でWindowsを動かしており、Windowsでしか動かない細かい作業などをやらせているんですが、ホスト(Ubuntu)を介さずスマートカードリーダー(PC/SC, CCID)を繋ぎたくなりました。

デフォルトの設定だとホストとゲストがスマートカードリーダーを共有する設定になっており、ホストとゲストが同時にスマートカードリーダーにアクセスでき、これはこれで便利そうなのですが、なにしろWindows上で上手く動かないので直接繋ぎたくなった次第です。

環境
仮想ソフト:VMware Workstation 14 Player
ホストOS:Ubuntu 16.04
ゲストOS:Windows Server 2008 R2(Windows 7ベース)

ゲストと直接スマートカードリーダーを繋ぐ設定にすると、ホストとゲストとでスマートカードリーダーが排他利用になります。つまり、ゲストに繋いでいる間はホストからはアクセス不能です[1]。それでよければ下記設定をすると何かの役に立つかもしれません。

/etc/vmware/config に下の行を付け足し、VMPlayerを再起動します:

usb.generic.allowCCID = "TRUE"
usb.ccid.disable = "TRUE"

Windowsに直接スマートカードリーダーを挿している状態になるので、ドライバー(Windows上で使うWindowsバイナリ)を入れるのを忘れずに。

参考: Gemalpto Smart Card Reader only appears as "Shared" not "Passthrough"

Let's Encryptを使ってWordPressをSSLに対応させた

前回、Debian jessie + Apache をSSLに対応させたのですが、Let's Encryptがちゃんと使えてるのかしばらくテストしたかったので、WordPressのリンク等は当面書き換えずに様子見をしていました。

前回:Debian jessie + さくらのVPSでLet’s Encryptを使う

しかしもうそろそろ大丈夫なのではないかと思い、ブログを全体的にSSLに対応させました。

SSL化にあたり、主にこちらのページを参照いたしました。
https://www.blogging-life.com/wpsite-https-migration-guide/

ただ、うちは.htaccessを使っていないので、リダイレクトはdefault-ssl.confの設定で行いました。

参考:常時SSL化の為にやったこと riscascape.net

HSTSの設定は、まだ諸々整っていないためやめておきました。

ブログについては結構簡単にSSL化できました。おしまい。

Debian jessie + さくらのVPSでLet's Encryptを使う

どうやら最近SSL対応のサイトが増えているようで、「暗号化する必要あるんだろうか?」というどうでもいいサイトまでhttpにアクセスするとhttpsにリダイレクトされたりもします。
そうなってくると大手サイトがhttpを使っていると、まだSSL入れてなかったんかいなどと思ったりもします。

スマホもパソコンも速くなった今、全ての通信が暗号化されるのはいいことだと考えております。
かといって個人が証明書にお金払うのは微妙ですし(僕は前払ってましたけどもすごく微妙な気持ちになりました)、オレオレ証明書使うのは更に微妙です。

team2ch.orgもなんとなくSSLを入れてみたくなったので、2016年くらいから話題の「Let's Encrypt」を使って無料で認証局から証明書を発行してもらいました。
それをApache2で使えるようにするまでの手順を書きます。

続きを読む

ネットワークカードを交換したらeth0が使えなくなった時の対処法(Debian, Ubuntu)

Ubuntu 14.04とDebianの古いシステム(squeeze)のネットワークカードを変えたらeth0が上がってこなくなりました。
Intel純正のPCI-Eアダプタ(Intel GIGABIT CT DESKTOP ADAPTER)、オンボードのLAN(これもPCI-E接続のIntelチップ)共に上がってこないという状況でした。

つまり状況としては両OSとも

    lspci | grep Intel → PCI-Eアダプタ、オンボードのLAN共に認識されている
    lsmod | grep e1000e → loadされている
    /etc/network/interfaces → 特に問題なし

    ifconfig → loは出てくるがeth0が出てこない

という感じでした。

ググってみたら、MACアドレスとethxの対象関係は

    /etc/udev/rules.d/70-persistent-net.rules

に記述されていると分かりました。

なので、アナログな方法でネットワークカードのMACアドレスを調べて、NAME="eth0"を付けるカードを指定し直すことで問題解決しました。
分かれば簡単でしたが、半日ほどハマりました。

参考URL:Ubuntuでネットワークカードを変更した時

LinuxでAndroidのrootを取る方法(Get the root by using your Linux computer)

世間ではWindows上でOdinを使ってrootを取っているようです。(Almost the people which would like to get the root of his Android mobile use Odin on Windows.)

しかしWindowsでやるよりLinuxでやったほうが楽なので紹介します。(But by using Linux, there is easier way to get the root.)

まずOdinの代わりにheimdallとheimdall-frontendをインストールします。(First, you can install heimdall and heimdall-frontend instead of Odin.)

sudo apt-get install heimdall heimdall-frontend

heimdall-frontendを起動します。(Start heimdall-frontend.)

heimdall-frontend

その後、UtilitiesからDetect Deviceを押し、端末を認識させます。(After that push the "Utilities -> Detect Device" botton to recognize your device.)

確認できたらPrint PIT -> Printを押し、Androidのパーティション情報を手に入れます。(Check your device is recognized by heimdall, you push "Print PIT -> Print" to get partition information of your Android device.)

次に、Flash -> Options -> PITから先ほど保存したPITを指定します。(Next, you specify previous PIT file on "Flash -> Options -> PIT" .)

右下のAddボタンを押し、Partition Nameに焼きたい場所(recovery.imgならRECOVERY、system.imgならSYSTEM)、Fileに焼く.imgファイルを指定します。(Push the Add botton and choose Partition Name. Notes that if your .img file you want to burn was "recovery.img, you can choose RECOVERY. If it was system.img, you can choose SYSTEM. On Files blank, push Browse and find your .img.)

できたらStartを押して経過を眺めてください。(If there was no ploblem, you push Start botton.)

NEC MultiWriter 5000N (Xerox Docuprint 2020、Brother HL-2170W) をLinuxでネットワーク上から使う

NEC MultiWriter 5000Nというモノクロレーザープリンタを、7,980円という値段に惹かれて買いました。モノクロながらレーザーかつネットワーク対応でこの値段とは驚きです。
買ったはいいのですが、Linuxで動かすのに苦労したので使用方法を書いておきます。ディストリはUbuntu 12.04 64bit (Precise Pangolin)です。CUPSの問題なので他ディストリでも同様に動くと思われます。

NEC MultiWriter 5000NはXerox Docuprint 2020やBrother HL-2170Wと製造元/構造が同じです。いわゆるOEMというやつです。なので同じドライバで動くようです。
設定は、http://localhost:631/からしました。他のGUIからやっても同様だと思われます。
予めCUPSやFoomatic (Linuxのプリンタドライバ集のようなもの)がインストールされていることを前提にします。

方法:

1. まず、Windows向け付属ソフトウェアでプリンタに固定IPアドレスを割り振る必要があります。Windows機にCDを入れて上手いこと固定IPにしてください。

2. プリンタの設定画面を開き、URLに以下を書きます。THE_PRINTER_IP はWindows機で設定したプリンタのIPアドレスです。

ipp://THE_PRINTER_IP/ipp/port1

3. メーカーは「Brother」を選択します。

4. 機種は「Brother HL-2170W Foomatic/hl1250」を選びます。recommendedなどは全て無視してください。

5. その他の設定を必要に応じてやります。

以上です。Linuxから使えなかったら買い直しだったので危ないところでした。と言っても7,980円ですけどね。

プリンタ購入/導入時の参考になれば幸いです。

参考:Tutorial on installing the Brother HL-2170W (and the HL-2140) printer with CUPS on Arch Linux.

Debianのブートディスクを交換

ルーター機のブートドライブを300GのHDDから32GBのSSDに交換しました。
逆の場合であれば# dd で一発なのですが、ディスク容量が小さい方への移行なのでそうはいきません。なので地道にやってみました。OSはルータがDebian、母艦がUbuntuです。最悪、起動しなくても最初のほうでバックアップを取ってるので復旧は容易かと思われます。

・ファイルシステムのバックアップ
旧HDDを母艦に接続して丸ごとcp -R するだけです。

# 旧HDDのUUID (gpartedかなにかで調べられます)
HDD_UUID=732cf650-8bc9-44b0-b2fd-9aa1a7743f60

sudo cp -R /mount/${HDD_UUID} .

・新SSDのフォーマット
gpartedかなにかでやると楽です

・新SSDへファイルをコピー

# 新SSDのUUID (gpartedかなにかで調べられます)
SSD_UUID=3fe19005-d2cb-4dd7-ae79-858ca95de327

cd ./${HDD_UUID}
sudo cp -R . /media/${SSD_UUID}

・ブート領域を作ってあげる
僕が前に書いた記事GRUBを飛ばしてしまいシステムが起動しなくなったときの救出方法と同様のことをやります(再掲)
詳しくは元リンクを参考にしてください。

# /boot パーティションのUUID./ 上に/boot がある(救出先のシステムで/boot を切り分けてない)なら省略
BOOT_UUID=0e0670da-9711-4eab-8025-b26dba90d576

# 救出先システム上/ のUUID
SYS_UUID=21427729-aef2-4a52-8d28-d6e90804c659

sudo mount --bind /proc /media/${SYS_UUID}/proc
sudo mount --bind /sys /media/${SYS_UUID}/sys
sudo mount --bind /dev /media/${SYS_UUID}/dev
# / 上に/boot がある(救出先のシステムで/boot を切り分けてない)なら省略
sudo mount --bind /media/${BOOT_UUID} /media/${SYS_UUID}/boot

sudo chroot /media/${SYS_UUID}
# たとえば/dev/sdeに grub をインストールしたい時
grub-install /dev/sde
update-grub
exit

sudo umount /media/${SYS_UUID}/proc
sudo umount /media/${SYS_UUID}/sys
sudo umount /media/${SYS_UUID}/dev
# / 上に/boot がある(救出先のシステムで/boot を切り分けてない)なら省略
sudo umount /media/${SYS_UUID}/boot

・HOMEディレクトリのownerを元に戻す
HOMEの所有者を旧HDDシステムで使っていたユーザ名に戻してやります。やらないと、SSHが通らなかったり何かと不便です。


cd /media/${SSD_UUID}/home
sudo chown -R user:user ./user

・suが通るようにする
これもパーミッション設定なのですが、あまり見慣れない形式です。詳しくはsudo で 「sudo: must be setuid root」と怒られる - 不会忘記的一天に書いてあるとおりです

# chmod 4511 /usr/bin/sudo

・繋ぐ
SSDを繋いで起動することを確認。以上。

参考リンク
sudo で 「sudo: must be setuid root」と怒られる - 不会忘記的一天

GRUBを飛ばしてしまいシステムが起動しなくなったときの救出方法

GRUB のアップデートをした後や,Linux のインストール直後にGRUB Error が出てシステムが起動しないことがあります.そんなときの対処法を書いておきます.
なお,GRUBの設定ファイルは,GRUB2では/boot/grub/menu.lst が廃止され,/etc/default/grub# grub-install を実行したあとに生成される/boot/grub/grub.cfg になったようです.

まず,システムをLiveCDから起動するか,母艦のUSBにレスキューしたいハードディスクを繋ぎます.
/boot パーティションが/ と分けられている場合は別途mount してあげる必要がありますが,流れは全く同じです.
パーティションのUUIDは$ blkid で調べられます.よく分からなければgparted を使うといいかもしれません.
今回は/media/UUID に自動でmount されていることを仮定しています.

母艦の/ /boot と,レスキュー対象の/ /boot を混同しないように気を付けましょう.

# /boot パーティションのUUID./ 上に/boot がある(救出先のシステムで/boot を切り分けてない)なら省略
BOOT_UUID=0e0670da-9711-4eab-8025-b26dba90d576

# 救出先システム上 / のUUID
SYS_UUID=21427729-aef2-4a52-8d28-d6e90804c659

sudo mount --bind /proc /media/${SYS_UUID}/proc
sudo mount --bind /sys /media/${SYS_UUID}/sys
sudo mount --bind /dev /media/${SYS_UUID}/dev
# / 上に/boot がある(救出先のシステムで/boot を切り分けてない)なら省略
sudo mount --bind /media/${BOOT_UUID} /media/${SYS_UUID}/boot

sudo chroot /media/${SYS_UUID}
# たとえば/dev/sdeに grub をインストールしたい時
grub-install /dev/sde
update-grub
exit

sudo umount /media/${SYS_UUID}/proc
sudo umount /media/${SYS_UUID}/sys
sudo umount /media/${SYS_UUID}/dev
# / 上に/boot がある(救出先のシステムで/boot を切り分けてない)なら省略
sudo umount /media/${SYS_UUID}/boot

/media/${SYS_UUID}chroot を設定し,# update-grub を実行しています.
ただし,その為には(CHROOT_DIR 下に)/proc/sys/dev が必要なので,動いているシステムのものをそのままmount しています.ですので,LiveCDから起動した方がより堅実かもしれません ((そこまで気にすることもないと思いますが,AMD64の環境をIA-32のシステムでmount したらどうなるのだろう・・・試してないので分かりません)).
mount--bind オプションは,chroot 下でもmount 先にアクセスできるようにするためのものです.