sudo でユーザのPATHが引き継がれないとき - secure_path, env_keep
CentOS 6.5 で sudo コマンドを使ったとき、command not found になりました。その一般ユーザのパスにも、root ユーザのパスにも含まれているコマンドなのに。secure_path という機能で、sudo 時のパスを /etc/sudoers に明示されたパスに限定しているためです。
$ sudo bash -c 'echo $PATH'
/sbin:/bin:/usr/sbin:/usr/bin
visudo コマンドで /etc/sudoers の env_keep に PATH を追加して、secure_path を無効にすればユーザのパスが効くようになります。
Defaults env_reset
Defaults env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS"
Defaults env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
Defaults env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
Defaults env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
Defaults env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"
Defaults env_keep += "PATH" ←追加
#
Adding HOME to env_keep may enable a user to run unrestricted
commands via sudo.
#
Defaults env_keep += “HOME”
#Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin ← コメントアウト </code>
PHPのファイルからBOMを削除する
翻訳会社さんが英中韓に翻訳してくれたPHPのビュー部分のソースコードにBOMが付いていました。BOM というのは byte order mark の略で、ユニコードで記述されたファイルのエンディアンを識別するための目印です。これがファイルの先頭に付いているものをBOMあり、付いていないものをBOMなしと呼びます。
普段はBOMの有無など気にすることはないのですが、このビューファイルを使うと、画面上に不可解な空白が発生して、レイアウトが多少崩れるのです。原因を追ううちに、BOMを削ると正常に表示できることがわかりました。
調べてみると、PHP と BOM との相性はよくありません。例えば、header() や session_start() 関数を使う場合、BOMありのPHPファイルだと、HTTP のヘッダ部分が出力される前にBOMが出力されます。ヘッダ以外のものを出力した後にヘッダを出力することはHTTP上できないので、エラーになります。
BOMそのものは U+FEFF のユニコードキャラクタです。UTF-8の場合、ファイルの先頭3バイトが 0xEF, 0xBB, 0xBF にエンコーディングされます。
では、これをどう取り除くか。
$ sed -e '1s/^\xef\xbb\xbf//' text.txt
このsed版が一番短くて美しいでしょうか。
$ awk '{if(NR==1)sub(/^\xef\xbb\xbf/,"");print}' text.txt
今回はこれを使いました。NRは行番号ですね。
$ tail --bytes=+4 text.txt
強制的に先頭3バイトを取り除くので、確実にBOMが付いていることがわかっているUTF-8ファイルのみ利用可能です。
$ ruby -e 'data = File.read(ARGV.first).sub(/\A\xef\xbb\xbf/,""); File.open(ARGV.first, "w") { |f| f.write data }' /path/to/file
指定したファイルをそのまま変換可能なことがウリです。が、こんな長いコード、打ちたくありません。
参考 http://www.linuxask.com/questions/how-to-remove-bom-from-utf-8 http://www.linuxask.com/questions/how-to-remove-bom-from-utf-8-using-sed
#1548 - Cannot load from mysql.proc. The table is probably corrupted
MySQL のテーブルが壊れている、という意味の、初めて見るエラーメッセージに遭遇しました。
#1548 - Cannot load from mysql.proc. The table is probably corrupted
でも、check table しても問題はなし。
mysql> check table mysql.proc extended;
+------------+-------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+------------+-------+----------+----------+
| mysql.proc | check | status | OK |
+------------+-------+----------+----------+
1 row in set (0.00 sec)
念のためDBをダンプして、drop & create しても変化なし。こんなときは mysql_upgrade すればいいらしい。テーブルの構造や存在などの整合性を正してくれるとのこと。
正確には、このコマンドは「examines all tables in all databases for incompatibilities with the current version of MySQL Server」、つまり、MySQLサーバーのバージョンとデータとの不整合を正してくれる。「should be executed each time you upgrade MySQL」なので、本当は yum update で MySQl がバージョンアップされたときにやっておくべきなのでしょう(え、自動でやってくれないの?)。
mysql_upgrade
Looking for ‘mysql’ as: mysql Looking for ‘mysqlcheck’ as: mysqlcheck FATAL ERROR: Upgrade failed </code>
あ、失敗した。ユーザー名とパスワードが必要らしい。
mysql_upgrade -u root -p
Enter password: Looking for ‘mysql’ as: mysql Looking for ‘mysqlcheck’ as: mysqlcheck Running ‘mysqlcheck with default connection arguments Running ‘mysqlcheck with default connection arguments 〜 テーブル名がずらずら 〜 </code>
need PK compat. v5.1 (can do v2.1)
インドの人からSSHの秘密鍵をもらいました。暗号化zipで固めてあります。 が! Macで開けず。unzip コマンドも効かず! むー。何で作ったファイル?
$ unzip ~/Downloads/xxx.zip
Archive: /Users/takah/Downloads/xxx.zip
skipping: xxx.txt need PK compat. v5.1 (can do v2.1)
7z というコマンドで開けるようです。
$ brew install p7zip
$ 7z x Downloads/xxx.zip
7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=utf8,Utf16=on,HugeFiles=on,4 CPUs)
Processing archive: Downloads/xxx.zip
Extracting xxx.ppk Enter password (will not be echoed) :
Everything is Ok
Size: 139 Compressed: 268 </code>
中身はSSHの秘密鍵なのですが、PPKファイルでもらいました。PuTTY用のファイルです。昔、Winをメインで使ってたときに愛用していたこともあるけど、今は Mac のターミナルから直接 SSH なので、OpenSSH で使えるように、pem ファイルに変換します。
$ brew install putty
$ puttygen xxx.ppk -O private-openssh -o xxx.pem
これで気持ちよくSSHできるようになりました。
初代 Happy Hacking Keyboard を Mac OS X 10.7で使う
Apple の Wireless Keyboard が壊れました。まだ2年くらいしか使っていないはずなのに。「e」のキートップが、若干ずれて、eが入力しにくくなりました。押してもeが入らないこともしばしば。プログラムを書くのでもメールを書くのでもストレスを感じます。
そこで、1999年に買って以来ずっと使っている、初代 Happy Hacking Keyboard を引っ張り出してきました。Wireless Keyboard を買う前までは、これを使っていたのです。会社用に1台、そして自宅用に1台買ったので、手元に2台あります。
10年以上、毎日のように使っていても、ガタひとつありません。久しぶりにキーをたたいたら、気持ちよすぎて自然と笑みがこぼれました。ああ、これだよ、これ。
初代HHKはPS/2なので、今の Mac にはつながりません。そこで、サンワサプライの PS/2 → USB変換ケーブル USB-CVPS1 を買ってきました。それに、HHKPS2USBDriver for Snow Leopardを組み合わせて使います。
さらにKeyRemap4MacBookを組み合わせて、左右のコマンドキーで日本語モードと英数モードを切り替えられるようにした上で、さらに、Deleteキーが Forward Delete と認識されていたので、Forward Delete → Delete のマッピングをしたところ、超快適なキーボード環境ができあがりました。
本当は、USB変換アダプターではなくて Happy Hacking Keyboard を秋葉原のヨドバシに買いに出かけたのですが、最上位の Type-S は置いておらず、展示してあった HHK Professional 2 もイマイチでした。展示品だけの問題かはわかりませんが、キーの音がうるさかったんですよね。特に英語配列の長いスペースバー。
でも千円ちょっとの投資で最高の MacBook Air 作業用キーボード環境ができたので、HHK Pro2 が好みに合わなくて、結果としてよかったです。
もともと Apple の Wireless Keyboard と Wireless Trackpad はバッテリー消費が激しくて、いつか捨ててやろうと思っていたのです。見栄えは格好いいのですが、週に一度以上は電池交換している気がします。エネループを使っているとはいえ、手間がかかって仕方ありません。これらは見かけ倒しの失敗作です。おすすめできません。