SELinuxを有効にした状態でhttpdのDocumentRootを変える方法

昔からの慣例というか癖で、開発マシンの httpd の DocumentRoot を、/mine/www/というところに設定しているのですが、Fedora に SELinux という仕組みが搭載されてから、怒られるようになってしまいました。

調べてみると、新しく設定したドキュメントルートに、httpd がアクセスするための SELinux のラベルが設定されていないのが原因のようで、こちらの記事に対処方法が書いてありました。

基本的にはこの通り実行しただけなのですが、自分の環境だとラベルがちょっと違ったので、それも含めてメモしておきます。
なお、自分の環境は、Fedora 21 で、ドキュメントルートは/mine/www/です。

参考にさせてもらっている記事のやり方にならって、まずは、もともとドキュメントルートに設定されていた/var/www/の設定を見てみます。

$ ls --context /var/ | grep www
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 www/

$ ls --context /var/www/
drwxr-xr-x. root  root  system_u:object_r:httpd_sys_script_exec_t:s0 cgi-bin/
drwxr-xr-x. root  root  system_u:object_r:httpd_sys_content_t:s0 html/

参考元の記事と違って、最後にs0というラベルが付いていますね。
これも含めて、新しいドキュメントルートに対し、ラベルを設定します。

今回は Web の開発マシンということで、どこでも CGI が動くようにしたいので、cgi-binに設定されているラベルを適用したいと思います。

$ sudo chcon system_u:object_r:httpd_sys_script_exec_t:s0 /mine/www/ -R
$ ls --context /mine/ | grep www
drwxrwxr-x. root  developers  system_u:object_r:httpd_sys_script_exec_t:s0 www/

ちなみにs0無しでやってみたら、設定が適用されませんでした。

設定ができたら、httpd を再起動してみます。

$ sudo systemctl restart httpd.service

特に怒られなければ成功です。

(未解決) Windowsで起動時に自動ログインできない

Windows 8.1 で、OS の起動時に自動ログインさせる方法は、Windows 7 のときと同じで、netplwiz から行います。

上記サイト以外にもググればたくさん解説記事が出てくるので、ここで詳しくは書きませんが、「ファイル名を指定して実行」から、「netplwiz」 を実行して、「ユーザーがこのコンピューターを使うには、ユーザー名とパスワードの入力が必要(E)」のチェックを外すと、自動ログインされるようになるのです。

ところが、このチェックボックスが無くなってしまいました。

Windows 7から8.1にアプリケーションを引き継ぐ

普段家で使ってるマシンの OS を Windows 8.1 Update にアップグレードしました。

こちらの記事によると、Windows 7 から Windows 8 へのアップグレードでは、個人データもアプリケーションも引き継ぐことができるのですが、Windows 7 から直接 Windows 8.1 にアップグレードする場合、個人データは引き継がれるのですが、アプリケーションが引き継がれないため、使っていたアプリケーションを個々にインストールし直す必要があるそうです。

Windows のほとんどのアプリケーションは、設定をレジストリという Windows に備わった設定の保管庫に保存しているのですが、アプリケーションが引き継がれないということは、これも引き継がれないということなのか。
情報を探してみたのですが、このことについて上の記事以上に詳しく書かれたサイトを見付けられず、結局 Windows 8 を経由して Windows 8.1 Update にアップグレードすることにしました。

よく OS のアップグレード時には、クリーンインストールを勧める人も多いですが、隅々までカスタマイズした設定を全て破棄して、初めからやり直しだなんて面倒くさすぎます。

GNU Screenの上でSSHすると文字入力が変になるサーバーがある

普段作業マシンで GNU Screen を使っていて、もちろん .screenrc は秘伝のタレ状態で、その状態で他人の用意したサーバーに SSH でアクセスしたときの話。
文字入力がなんか変で、バックスペースが効かなかったり、カーソルキーを押すと直前の文字が繰り返し入力されたりということがたまにあります。

なんでだろうと思っていたら、SSH セッションを閉じたときに、次のように表示されました。

'screen-256color-bce': unknown terminal type.

どうもサーバーさんにscreen-256color-bceという定義が見付からないらしいです。

screen-256color-bceというのは、screen を起動したときにTERMという環境変数に設定される値で、おそらく .screenrc の以下の設定項目から作られています。

~/.screenrc
defbce on
term screen-256color

なんでこんな設定をしたかというと、vim で 256 色表示を使いたかったからなのですが、一時的に作業する他人のマシンでまでこの設定を維持する必要は無いので、ログインしたらすぐに

$ TERM=xterm

と入力すればTERMの値が変更されて、文字入力も希望している通りに認識されるようになります。

サーバーによってはxterm-256colorだったら受け入れてくれたりするので、

$ TERM=xterm-256color

も試してみる価値あるかも。

一度しかアクセスしないサーバーならこれでもいいけど、何度もこれやるのは面倒だなあと思ったら、SSH コマンドを打つときにTERMを指定する方法もあります。

$ TERM=xterm-256color ssh user@hostname -p 2222

相手のサーバーでTERMの値がscreen-256color-bceになってる理由は、まず screen が screen を実行したマシンのシェルの環境変数TERMを設定していて、これが SSH によってサーバーに渡されて、サーバー側のシェルの環境変数に設定されているので、SSH で繋ぐ直前にTERMの値を変えてしまおうというわけです。
コマンドを実行するときに代入した変数の値は、そのコマンドが終了すると破棄されるので、クライアント側のマシンには影響ありません。

この方法だったら、シェルの履歴からアクセスしたり、シェルスクリプト書いたり、エイリアス書いたりすれば入力が省略できますね。

他にも .screenrc をちゃんとする方法とか、~/.ssh/config を使った設定方法とかもありそうだけど、今回はここまで。

VAIO XでOffice2013の表示がバグる問題

Office 2013 の表示がバグってる様子
VAIO X に Office365 で手に入れた Microsoft Office 2013 をインストールしたのですが、インストール時に表示されるチュートリアルの表示もおかしかったし、インストール後にアプリケーションを起動すると、Word や Excel など、どのソフトでも表示がおかしくなってしまっていました。
上のスクリーンショットは、PowerPoint 2013 を起動した様子です。

調べたところ、ハードウェアアクセラレーションを利用しようとしてしまっているのが問題らしく、レジストリを書き換えることで回避できるとのことでした。

こちらのページに対処の仕方が書かれているのですが、初めに書かれた手順が間違っていたりするので、改めてここに手順を書き残しておこうと思います。

手順

  1. デスクトップ画面で Windows キー + R キーを押し、 [ファイル名を指定して実行] の画面を表示します。
  2. 「regedit」 と文字を入力し [OK] をクリックします。
  3. レジストリ エディターのウィンドウが開きます。ウィンドウの左側にフォルダーがいくつか表示されているので、フォルダーの左側にある△をクリックして以下の順に開き、階層を辿っていきます。

    HKEY_CURRENT_USER > Software > Microsoft > Office > 15.0 > Common
  4. Common の下に Graphics がない場合は、5 の手順に進みます。
    Common の下に Graphics がある場合は、7 の手順に進みます。
  5. Common の上で右クリックし [新規] - [キー] をクリック、名前を 「Graphics」と入力します。
  6. 作成した Graphics をクリックし、右側のウィンドウで右クリックし [新規] - [DWORD (32 ビット) 値] をクリックし、名前を「DisableHardwareAcceleration」と入力します。
  7. DisableHardwareAcceleration をダブルクリックし、値のデータを 1 に変更し [OK] をクリックします。

以上です。

Firefoxの検索バーのテキストボックスの幅を広くする

ページ内検索
Firefox でページ内検索するためのテキストボックスが狭くて使いづらかったので、広げてみました。
Firefox の UI は、XUL という HTML に似た言語で書かれているので、CSS で簡単にカスタマイズすることができます。

今回カスタマイズしようと思ったページ内検索のテキストボックスには、.findbar-textboxという class 名が付いているので、これに対してスタイルを指定します。
スタイルの指定は、C:\Users\yuuAn\AppData\Roaming\Mozilla\Firefox\Profiles\hoge.default\chrome\userChrome.cssで行います。
青文字のところは環境によって違うので、環境に合わせて読み替えてください)

userChrome.css
.findbar-textbox {
    width: 40em !important;
}

もともとが 14em だったので、40em に広げてみました。
本当はレスポンシブな指定をした方がいいんでしょうけど、面倒なので今日はここまで。

筆まめのフォントが原因でフォント選択で強制終了

ワードパッドのフォント選択
Windows 7 の ワードパッド など、フォントを選択するためのドロップダウンで、フォント名をそのフォントで描画しているソフトがありますが、このドロップダウンを表示させたとたん、ソフトが強制終了してしまう現象が起きていました。
初めはワードパッド固有の問題かと思っていたのですが、Windows 版の LINE でも同じ現象が起こっていたので、どうやらフォントの表示に問題があるようです。

調べてみると、筆まめに付属していたフォントが怪しいことがわかりました。

筆まめに付属している「CRC&G 流麗連綿体」というフォントと、「AR行楷連綿体L/H」というフォントが、筆まめ専用のフォントなのに C:\Windows\Fonts にインストールされていて、これを表示しようとした他のソフトがエラーを起こしているようでした。
これを消してしまうと、筆まめを使うときに困りますが、お正月はまだまだ先なので、バックアップを取りつつ削除したら、強制終了しなくなりました。

フォントに関しては、MacType というフォントを綺麗に見せるソフトを使っているので、もしかしたらそれの影響もあったのかもしれませんが……。